Category: APRS

TNC-X – DCD behaviour

I have been investigating ‘lost APRS packets’, a result of many root causes.

One is a perception that when I drive in the local area, I often do not hear my own digi ‘echo’ yet I find that it did receive a packet and submit it to APRS-IS. This problem is much more apparent using a TNC-X that with any other KISS TNC in its place.

A possible explanation is that it did echo but I did not hear it due to collision with another digi.

So that led me to explore whether TNC-X fails to quickly detect the other digi already transmitting. Continue reading TNC-X – DCD behaviour

Last update: 8th April, 2019, 8:17 AM

Latency in APRS networks

APRS-IS depends very much on a timestamp created at the time that a record from an  iGate is received.

Very few stations transmit a timestamp in the packet header even though accurate time is usually available when the GPS provides valid position data.

So in a network where packets are carried through many digipeaters (a result of the end user supplying an inappropriate PATH), and many of these digipeaters having several iGates listening, there is a need to weed out duplicates.

The mechanism to discard duplicates falls down when the duplicate submission is delayed significantly, and some network infrastructure is notorious for latency.

Continue reading Latency in APRS networks

Last update: 25th August, 2014, 7:46 PM

Should you use MIC-E compression in your APRS tracker

At first, the MIC-E compressed packets might seem to have advantage in reducing channel utilisation and improving the probability of successful packet transmission… but it comes at a cost.

The linux iGate daemon aprsd 2.2.5-15 has had a problem with corruption of MIC-E packets for more than ten years resulting in occasional gross errors in position reports processed by those nodes. Continue reading Should you use MIC-E compression in your APRS tracker

Last update: 26th August, 2014, 6:05 AM

MFJ-1270B TNC review

MFJ1270BFront

I have been doing some research on APRS recently, and Brian, VK2AH, kindly donated a MFJ-1270B.

MFJ-1270B Over the years I have heard so many reports that the MFJ-1270B does not accommodate twist (an amplitude / frequency slope usually the result of lack of pre-emphasis, usually the result of audio overdrive of the transmitter, and usual for hams). More detailed discussion is at The extent to which APRS works is often an accident.

There is no shortage of bad signals to test the tolerance of the TNC, with two local overdriven digis, and travellers through the area. Continue reading MFJ-1270B TNC review

Last update: 13th November, 2014, 8:18 AM

Headless javAPRSSrvr

This article describes a trial of javAPRSSrvr on a Raspberry Pi (RPi) as a headless system (ie without integrated screen and keyboard).

HeadlessJavaprssrvrAbove is the RPi sitting on a TNC-X KISS TNC connected to the TNC’s USB port. In this case, javAPRSSrvr uses the supplied KISS interface, it does not use Linux kernel support for AX.25. Continue reading Headless javAPRSSrvr

Last update: 16th April, 2015, 3:46 AM

Argent Data T3-135 review

I was handed an Alinco DR-135 + T3-135 to troubleshoot. The reported symptoms were that it “never repeated the owner’s Foxtrak based mobile station”.

t2-135-installed

The T3-135 is an OT3 tracker/TNC built on a card to fit inside the Alinco DR-135 in the place provided for their own EJ-41U TNC. The rear DE9 port provides data access to the T3-135’s A and B serial data channels.
Continue reading Argent Data T3-135 review

Last update: 12th May, 2016, 8:38 AM

Open squelch data carrier detect for TNC-2

This article documents an open squelch data carrier detect (OSDCD) for TNC-2.

The TNC commonly derives Data Carrier Detect (DCD) from its modem chip (often a broadband energy detector is used in modem chips). DCD is used to enable decoding of incoming Receive Data (RD), and to block transmission whilst the channel is busy. Continue reading Open squelch data carrier detect for TNC-2

Last update: 26th August, 2014, 8:01 PM

Foxtrak review

A few weeks ago I built up a Foxtrak kit, see Foxtrak build.

During testing, I noted that VK2ZEN-5 occasionally corrupts Foxtrak packets, or more generally MIC-E encoded packets. It is a known problem with aprsd which has not been fixed in more than 10 years.

As a result of the fact that one local digi (OT3) never decoded the Foxtrak (DK7IN firmware), I tried aprstracker0.11 and original TinyTrak(1) firmware.

The aprstracker evaluation is described at Review of APRSTRACKER v0.11 firmware, it was unsuitable.

The TinyTrak(1) firmware didn’t work with the OT3 digi either.

The matter of Foxtrak / OT3 interoperatibility is discussed in more detail at:

A TinyTrak3+ was also evaluated, see TinyTrak3 v1.42 review.

Considering quality, price and performance, the Foxtrack works with most digis types but not OT3s, the DK7IN firmware has more feature than the original TinyTrak, but the combination is nowhere near as capable as the TinyTrack3+ which is less than double the price as landed in Australia.

Last update: 24th August, 2014, 4:11 PM