The default delay between executions is 100ms (RestartSec) which causes the rate limit to be reached very fast.
Just using Restart and RestartSec is not enough: systemd services have start rate limiting enabled by default. If service is started more than StartLimitBurst times in StartLimitInterval/StartLimitIntervalSec seconds is it not permitted to start any more.
Add RestartSec=5 in the service section
Add StartLimitInterval=0 in the unit section
There is a new version of RMSGateway. This is at the moment in Beta test. See the mail of Basil N7NIX.
If you like to test the new code. Just mail N7NIX. basil (@) pacabunga.com
The new code (version 2.5.0) has been running on a few machines for the last couple of days. I would like to get a few more sites to try out the new code before it is released.
If you would like to help please contact me directly & I will give you instructions on how to install the new code. Only the python scripts & xml files changed to support the latest Winlink Web Services.
For the website I am looking for people who want to write and post something on the site. They can be configuration examples, an explanation of how you did something. Updates from packet software. And so on. Are there people who feel like it please let me know via the contact form or via e-mail. pd9q (@) packet-radio.net. Thanks.
With the help of the config file of Jerry, N9LYA and some help from John, G8BPQ I have setup a Winmor port on my Linbpq.I use a Microham USB II as soundcard device connected to my Windows PC and a direct Cat kabel from my Linux PC to control the TRX.
Here is the section for the Winmor port. (BPQ32.CFG)
If you happen to have a Kantronics KPC-3+ TNC, please do not use it for your APRS igate. It appears to have a software bug which causes delays of over 10 minutes when receiving packets from the radio and then forwarding them to the computer, which then forwards them to the Internet (or possibly retransmits the old packets back to the radio channel, if digipeating).
This is a very bad thing to do, as the greatly delayed packets cause network overload and make moving vehicles jump back and forth between their current positions and the past positions. Looks very funny when aprs.fi tries to draw a track line between the received positions.
For years there have been anecdotal stories and suggestions about a possible problem. Yesterday Alan (radionerd1) has uploaded three videos to Youtube demonstrating the problem. This serves as a nice technical proof that the problem is real, and demonstrably a problem of the KPC-3+. There have been hints that the bug could be in UI-View32 (when using it with the KPC-3+), but Alan demonstrated the problem without involving UI-View.
Alan ran APRSIS32 on a computer, and connected it to two APRS receivers. One used a KPC-3+ and one used AGW packet engine (sound card packet decoder). At first, the two ports received the same packets at the same time. After about a week the KPC-3+ started to misbehave – the received packets were given to the computer only after they had been held as hostage for over 10 minutes. Some people have reported that it can go in this delaying mode within hours or days – it might be due to bad luck, or due to the amount of traffic received. The KPC-3+ did put out a KISS packet to the computer every time a packet was heard from the radio, but it was an old one. When the TNC was reset, it started performing well again.
My guess, as a programmer, would be that the KPC-3+ looses count of the packet it should be transmitting on the serial port. It receives a packet on the radio port, puts it in the received packets buffer, and then prints the wrong packet on the serial port. It might be the oldest packet in the buffer, or thereabouts. The amount of perceived delay would depend on the amount of traffic received in your area.
So, I repeat: If you have a KPC-3+ on your igate in KISS mode, please switch it to something else as soon as possible (KPC-3, OpenTracker, TinyTrak, TNC2 clones, whatever). If you wish to continue using it later, please contact Kantronics at firstname.lastname@example.org and ask them to fix the software bug.
It has been said that the problem only exists in KISS mode. So if you’re using the KPC-3+ as a stand-alone digipeater, it should be fine (in this respect). If you’re using it as a digipeater in KISS mode, with the digipeating happening on the computer (digipeating enabled in UI-View32 or APRSIS32), the effects are seriously bad, as you’re transmitting old packets on the radio channel.
I was working with Kantronics support on this issue and I seem to have solved it by shorting the RTS and CTS pins together within my serial cable. (PINS 4/5 on DB25 and PINS 7/8 on DB9) I simply ran a jumper between the two. This appears to be an issue with how the APRS software and/or the AX.25 stack controls the RTS pin and shorting the RTS and CTS together prevents the software from holding the RTS pin low. If the RTS pin is at low voltage the KPC3+ will start buffering and does not get caught back up. I have been running mine for several weeks without showing this behavior again. Before I made the change it would happen after about 12 hours.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.