Update RMSGateway 2.5.0.0

Finally i found some time to update the RMSGateway to RMS 2.5.0.0 with Winlink V5 CMS Web Services support. I only found the issue that if have to edit the sysop.xml and add the password. I dont have read that anywhere.

Thanks to /Basil n7nix we are good to go again.

More then 50 People of the 72 needs to update there software.

Instructions on how to update RMSGateway

Instructions on how to update to the latest scripts supporting Winlink
V5 CMS Web Services.

You need to complete this update soon as Winlink is switching its Web
Services over to only support their latest version. Note that no C
files changed for this upgrade just python scripts & the
/etc/rmsgw/hosts file.

First check your python version:

python –version

The new scripts have a requirement of python version 2.7.9 or above.
If you are running a Debian distribution then wheezy will not work,
jessie, stretch & sid are OK.

Second check that you have an /etc/rmsgw/sysop.xml file.

If you don’t have a sysop.xml file then read the admin/README.md file
https://github.com/nwdigitalradio/rmsgw/blob/master/admin/README.md

Note that the getsysop.py & mksysop.py scripts currently do not work
for the new Winlink Web Services because the SysopGet web service is
not enabled for our key. This may change in the future. If you do not
have a sysop.xml file you can use mksysop.py BEFORE you do the update.

If your system passed the python version test then you can easily
upgrade like this:

git clone https://github.com/nwdigitalradio/rmsgw
cd rmsgw/admin
# become root & run this command
…/admin-update.sh

Verify that the update is working

# As root run the test script in the admin directory

…/testwlapi.sh

# Search the log file for any errors
# The log file grabs some of the rms.debug log file and you are only
# concerned with errors found after you ran the test script

grep -i error /root/tmp/debuglog.txt

Now go to winlink.org (https://winlink.org/RMSChannels) and look at
the Winlink Packet RMS Map/RMS List/Gateway Versions sections.
Search for your call sign.

For more information read the README.md file in the rmsgw/admin
directory here:
https://github.com/nwdigitalradio/rmsgw/blob/master/admin/README.md

/Basil n7nix

Systemd RestartSec/StartLimitInterval/StartLimitIntervalSec

Systemd

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

Run

 

 

RMSGateway New version

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.

Thanks,
/Basil n7nix

Looking for Constibutor / Author

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.

O Yes, it`s a hobby, so there is no cash 🙂

LinBPQ with Winmor port.

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)

WINMOR TNC.ini

Winmor Status screen from Linbpq

Winmor

Tnx for the help Jerry and John.

Remote Packet Station

I’m busy building a remote packet station.

  1. Airgrid AG-HP-5G23 For remote control the Pi 5Ghz Point to Point
  2. USB DC-DC step down module 4,5V-40V to 5 Volt 2A USB – Power for the Pi
  3. W1401 12V Digital Thermostat Temperature Controller Switch Module NTC Sensor
  4. Power supply Mean Well (150W, 12V,12.5A)
  5. 3x Fan 80x80x25 mm 12 volt
  6. Raspberry Pi 2
  7. 3D Sound card
  8. 2x Ground loop isolater
  9. Trx President Lincoln 2
  10. Antenna  Siro tornado 27 5/8
  11. 10Mtr EcoFlex 15

Connect the Pi to the Trx

Kantronics KPC3+ KISS considered harmful

I was reading on the aprs.fi blog and came across some interesting things.

http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html

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 service@kantronics.com 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.

Solution

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.