Towards a reliable APRS iGate

An APRS iGate necessitates some form of computer in the centre of the configuration.

Over recent weeks, I have evaluated a number of configurations for VHF based on Windows and Linux (RPi) to assess their reliability, though it is doubtful that a configuration to rival UIDIGI reliability and availability is likely.

Server

Though fundamentally, Linux is not a high availability platform, and in my experience RPi has been fairly flaky, the winning configuration is javAPRSSrvr on RPi (Raspbian at current maintenance) and a real TNC for radio access.

TNC

TNCs are seen as old world devices, and there are some modern implementations, some using DSP techniques (though rather crude) rather than modem chips, but old world modem chips gave the best performance.

For best channel performance, the TNC needs a true Data Carrier Detect, often called Open Squelch Data Carrier Detect (OSDCD). Two TNCs were trialled, a MFJ-1270B which has OSDCD, and a Paccomm Tiny-2 Mk-2 with Open squelch DCD for Paccomm Tiny2 Mk2. This not only assists in reducing collisions, but it reduces the chance that a TNC gets DCD stuck on due to interference or squelch drift and bottles up a buffer full of traffic which is released later when it is quite stale so corrupting the APRS-IS feed as these are not recognised as duplicates.

Most modern TNCs and most modern software have converged on the KISS protocol, even though it had a number of weaknesses:

  • lack of error protection;
  • lack of commands for audio level lineup;
  • lack of compelled command / response for the host to verify that the thing is responding.

There is a further problem that most modern implementations do not fully support the defined KISS commands, especially those for controlling channel access (PPersist, SLOTTIME, TXDELAY).

The preferred server converged on javAPRSSrvr, and it appears to have facilities for configuring the KISS TNC but they are not an effective means of configuring a multi mode TNC into KISS mode.

For part of the reliability study, a KISS ONLY TNC image was used, a dual EPROM bank switched to either Paccomm v5.0 or SMACK v1.3. When switched to the SMACK image, the modem is always in KISS mode irrespective of TNC configuration memory / battery, and across power failures so it is a resilient solution.

SmackChip

The deficiencies in KISS include lack of facility for tx audio lineup, so the second part of the EPROM image supports the traditional CAL command for lineup.

Multimode TNCs

The project has ranged onto finding a robust solution for Multimode TNCs. The possible solution undergoing reliability trials is a expect based scripting integrated into the SysV init script used for starting and stopping the server. Initial results look promising.

At this point, power can be pulled of the server and TNC and it restarts properly. This is a backstop for a remote device that doesn't respond, a remotely operated power off/on cycle.

The KISS protocol does not allow the server to ‘ping' the TNC, and javAPRSSrvr lacks any checks that the TNC hasn't lost contact (such as the timeout in aprx). (An external agent may be written to monitor the log port and cycle the init script if nothing received for a time, and there are other possibilities.)

More as the trial progresses.