APRS is characterised by a lack of standards or guidance, but mostly by a lack of compliance with those standards and a lack of understanding and common sense.
VK2UWP is travelling around the countryside and from the look of it, setting up a WIDE2 digipeater in the local caravan parks without regard to its dysfunction. Continue reading The mobile APRS W2 digi left town this morning
A very quick trial of aprx v2.08 was concluded in less than 24 hours. Continue reading Headless aprx server – trial wrapup
In the continuing trials of APRS digi+iGate servers, an aprx server running on a RPi.
Continue reading Headless aprx server trial
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
Headless javAPRSSrvr described a trial iGate+digi based on javAPRSSrvr v4.1b5. This article wraps up the trial. Continue reading Headless javAPRSSrvr – trial wrap up
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
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
This article documents an open squelch data carrier detect (OSDCD) for a Flash Packet Radio Control Board (VK6) TNC-2. Continue reading Open squelch data carrier detect for Flash Packet Radio Control Board (VK6)
I have been doing some research on APRS recently, and Brian, VK2AH, kindly donated a 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
This article describes a trial of javAPRSSrvr on a Raspberry Pi (RPi) as a headless system (ie without integrated screen and keyboard).
Above 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