Re-Examining Ambiguities in the Automatic Packet Reporting System
In 2014, Kenneth W. Finnegan wrote and important paper called Examining Ambiguities in the Automatic Packet Reporting System. A search for that title will find dozens of copies and references scattered around. He starts with the problem and attempts to provide a solution:
… This is proving to be problematic due to the loss of institutional knowledge as older amateur radio operators who designed and built APRS and other AX.25-based packet networks abandon the hobby or pass away. The purpose of this document is to collect and curate a sufficient body of knowledge to ensure the continued usefulness of the APRS network, and re-examining the engineering decisions made during the network’s evolution to look for possible improvements and identify deficiencies in documentation of the existing network.
He was absolutely correct in his assessment of the problem. Unfortunately, he made many mistakes in collecting and curating some of the institutional knowledge. The result could be spreading misinformation which others will then propagate. I would like to offer some corrections.
The OSI network model as applied to APRS
Kenneth broke it down like this:
Lumping HDLC into Layer 1 violates the definition.
· Layer 1 - Physical - Refers to a raw bit stream over a physical media. This would be the modem and radio. By the way, the AX.25 and APRS specifications say nothing about the type of modem to be used. In the previous Century, three TNC manufacturers allowed 2400 bps with designs including the EXAR XR-2123 PSK modem chip which implements the V.26 / Bell 201 standard. Some TNCs, Kenwood & Yaesu radios are capable of 9600 bps.
· Layer 2 - Data Link - Refers to transmission of data frames between two nodes connected by a physical layer. HDLC belongs here. Forward Error Correction (FEC) also belongs here because it is applied to frames. AX.25 is a lot of stuff mushed together so it does not fit neatly into one layer.
· Layer 3 - Network - Deals with routing. AX.25 was not designed with the OSI model in mind but, if you try to squeeze it into that mold, the AX.25 digipeater addresses would fall into this category.
· Layer 7 - Application - APRS data types, encoded in the AX.25 frame Information part, would fit here.
This is all academic. Let’s get back to the practical considerations.
AX.25 Frame Format
In the previous Century, everyone just bought a special purpose box, called a Terminal Node Controller (TNC), from a small number of manufacturers. Few needed to worry about all of the nitty gritty details of what was going on inside. In more recent years software TNCs, simple KISS TNC devices, and various microprocessor based gadgets abound. It is important that all developers understand the rules so all the devices can play well with each other.
Kenneth wrote:
There is a good reason for “leading 0x00 octets” being rarely mentioned. The AX.25 specification, clearly states, in section 3.11:
Whenever it is necessary for a TNC to keep its transmitter on while not actually sending frames, the time between frames should be filled with contiguous flags.
Kenneth wrote:
The octet 0x7E is used to indicate the beginning and end of HDLC frames. There is little guidance on the number of flag octets needed before or after frames …
It is permissible to encode multiple frames per transmission, yet there is no guidance as to how many octets of 0x7E should be included between them; most modems insert several 0x7E octets between frames …
The AX.25 protocol spec makes this clear, in section 3.1:
Because the flag delimits frames, it occurs at both the beginning and end of each frame. Two frames may share one flag, which would denote the end of the first frame and the start of the next frame.
So there it is, straight from the horse’s mouth. A single flag pattern can be shared by two frames, indicating the end of one frame and the beginning of the next.
It would probably be a good idea to stick at least 2 flag patterns between frames because some implementations might not handle a single flag between them properly.
This is now mentioned explicitly in Chapter 3 of APRS12c.pdf found here.
Carrier Sense Multiple Access (CSMA)
The discussion is fundamentally correct but setting SLOTTIME to 300 milliseconds (mS) seems rather extreme. Remember that this is not the total delay, but the increment which is usually repeated several times.
The APRS protocol spec says nothing about transmit timing, probably because this is part of the referenced AX.25. At the time everyone was using hardware TNCs and they took care of the details.
The AX.25 v2.2 specification doesn’t say much about this:
6.7.1.6 Slot Time Timer T102 (p-persistence)
T102, the Slot Time Timer, randomly delays stations before they begin transmitting immediately after the channel becomes clear. This helps prevent several stations from beginning to transmit at the same time and causing collisions
We need to depend on institutional knowledge for this. The Kantronics KPC-3+ manual is very helpful.
I would like to offer this more detailed explanation for the canonical collection…
Transmit timing is determined by 4 parameters with these traditional names and typical default values.
SLOTTIME 10 x 10 mSec per unit = 100 mSec.
PERSIST 63 probability for transmitting after each slottime.
TXDELAY 30 x 10 mSec per unit = 300 mSec.
TXTAIL 10 x 10 mSec per unit = 100 mSec.
Some implementations could use milliseconds so RTFM if not using the defaults.
When a frame is ready for transmission, we first have to wait until the channel is clear. The technical term for this is Carrier Sense Multiple Access (CSMA). In plain English, if you want to say something, wait until no one else is speaking. You should also wait a random time, before starting to speak, to minimize the chance of multiple people talking at the same time.
· For digipeated frames the transmission should begin immediately after the channel is clear. Having multiple digipeaters transmit at the same time is intentional to minimize the amount of time taken for the same packet. The strongest one will win due to the FM capture effect.
· For other frames, SLOTTIME and PERSIST are used to generate a random delay to minimize the chances of two different stations starting to transmit at the same time. The process is:
(a) Wait for channel to be clear (i.e. no signal detected by modem)
(b) Wait for SLOTTIME.
(c) If the channel is busy (i.e. signal detected by the modem), go back to step (a).
(d) Generate a random number in the range of 0 to 255. If it is less than or equal to PERSIST, start to transmit. Otherwise go back to step (b).
For the typical default values, we have delays with the following probabilities:
Delay, mSec Probability
100 .25 = 25%
200 .75 * .25 = 19%
300 .75 * .75 * .25 = 14%
400 .75 * .75 * .75 * .25 = 11%
500 .75 * .75 * .75 * .75 * .25 = 8%
600 .75 * .75 * .75 * .75 * .75 * .25 = 6%
700 .75 * .75 * .75 * .75 * .75 * .75 * .25 = 4%
etc. ...
The Push to Talk (PTT) control line is asserted.
The data can’t be sent immediately because the transmitter takes a little while to stabilize and reach full power after being activated. This varies by type of transmitter so there is not a universal optimal value. Some people might decrease TXDELAY until another station can’t decode the packet and then make it a little longer. This is asking for trouble. Some receiving stations might use squelch which will chop off the beginning of incoming transmissions. When TXDELAY is too short, one station might be able to decode your signal, but another one might not.
The HDLC “flag” pattern (01111110) is sent for a time period of TXDELAY. For historical reasons, going back to the 1980s, the times are often expressed in 10 millisecond (mS) units so 30 actually means 300 milliseconds.
When sending with a hardware modem, you know exactly when the audio for the frame is finished so the transmitter can be turned off fairly soon after that. TXTAIL can be very small.
When sending audio out through a “soundcard” there is latency between sending an audio waveform to the output device and when the sound comes out. We can’t be sure precisely when the queued up sound has been completed so we need to keep the PTT on a little longer. Some modern radios, with DSP in the audio transmit chain, can delay the audio. After the modem audio is finished, the HDLC “frame” pattern is also sent during this time to keep the channel busy. A TXTAIL of 10 (x10 mSec = 100 mSec) is probably safe.
This is now mentioned explicitly in Chapter 3, Channel Access section, of APRS12c.pdf found here.
AX.25
Kenneth wrote:
I was very pleased to see the first field described as “TNC Description” rather than “Destination” which causes a lot of confusion. If all the APRS literature did this we would have fewer people putting APRS, CQ, or BEACON in there.
It should be noted that the MIC-E format is an exception and uses this field for part of the location.
Digital Repeater Routing Behavior
IMHO, everyone should stop talking about RELAY and WIDE. They have been obsolete since around 2004. There are already enough places to read about the history. Keep it simple for those who want to know how it works nowadays.
I recently noticed a couple stations, in my logs, still using “RELAY,WIDE.”
Kenneth wrote:
A WIDEn-N alias represents multiple WIDE aliases by using two numbers, represented by n and N. The first n represents the originally requested number of WIDE hops, where the trailing N represents the remaining number of hops that have not yet been consumed.
Not exactly. The first number is not the original hop count.
· WIDE1-N is generally processed by low range (usually residential) “fill-in” digipeaters. (Replacement for the original obsolete RELAY.)
· WIDE2-N is also processed by wide area digipeaters. (Replacement for the original obsolete WIDE.)
“WIDE1-1,WIDE2-1” is a typical path used.
The APRS protocol spec doesn’t explain how digipeaters should work. For this, we have to rely on institutional knowledge of the 20th century legacy TNCs and update for the WIDEn-N paradigm introduced around 2004. APRS-Digipeater-Algorithm.pdf, found here , is my attempt to clear up the confusion.
Deduplication Behavior
Kenneth wrote:
When a new packet with hops remaining in the path are received, a hash of the source callsign and Information Field are compared against the hash table to check if the same packet had been recently transmitted.
The comparison should be on source, destination, and information fields, i.e. all but the digipeater path. Consider the case of a moving station sending MIC-E position reports. The “destination” field will be changing and these should not be considered duplicates.
Using a hash value is a popular implementation to reduce memory and compare time. However, comparing strings, with the digipeater part removed, would also be a valid, less efficient approach.
Routing Aliases
A couple issues here, and in other examples:
First, it is mixing long obsolete RELAY with the new WIDEn-N form since around 2004.
The TNC-2 monitoring format requires that an asterisk (*) appear no more than once in the digipeater path. When one address is marked as being used, all preceding addresses are implied as being used. There should never be a case where there is a used address after an unused address.
The TNC-2 Monitoring format is explained in the APRS Protocol specification and “Understanding APRS Packets” found here.
Conclusion
Kenneth wrote:
By most measures, Amateur Bell 202 is a very poor performing modulation to be used by amateurs for packet operations. One-bit symbols cause Bell 202 to suffer from poor spectral efficiency, HDLC lacks any error correcting codes so single-bit errors cause entire frames to be dropped, and 1200 bits per second is a remarkably low data rate …
… The public APRS networking is deeply entrenched in using Amateur Bell 202, so exploring future enhancements to the Amateur Bell 202 modem is a topic that begs for further examination.
1200 bps AFSK happened by accident. One of the Canadian packet radio groups happed to acquire a pile of surplus Bell 202 modems for $0.75 each. Using an external modem made the TNC design simpler and more flexible
At the time, 1200 bps AFSK was considered to be a quick and dirty temporary solution that would soon be replaced by something better.
The AX.25 and APRS protocol specifications say nothing about the type of modem. The TAPR TNC-1 and TNC-2 were designed to handle much higher speeds and had a connector that allowed the internal AFSK modem to be disconnected and to use a higher speed external modem instead.
In the 1980s we had multiple 9600 bps modem designs. Some companies produced TNC models with 9600 bps capability. The problem is that this requires wider audio bandwidth not available with the microphone or speaker connector. Kenwood and Yaesu APRS radios have 9600 bps modems built in.
There were designs for 56k bps data radios.
Back in the 1990s there were at least three commercial TNCs that allowed 2400 bps PSK: MFJ-2400 (which is an optional board for the MFJ-1270 or MFJ-1274), AEA PK232-2400 , and Kantronics KPC-2400, using modem chips for the V.26 / Bell 201 standard. Some modern software TNCs include this 2400 bps PSK modem.
In 2005, the Stensat Group came up with a clever way to add Forward Error Correction to AX.25 while maintaining complete backward compatibility with existing equipment. It was originally developed for satellites. Now, FX.25 capability is available in at least three modern TNCs. Regular AX.25 fails when even a single bit is corrupted. FX.25 can fix up to 32 bytes (that’s bytes, not bits!!!) in a corrupted frame. FX.25 keeps going strong long after regular AX.25 is completely useless.
Better solutions have been available for a long time, and continue to be developed, but few take advantage of them.
The disappointment in lack of progress is nothing new.
In the author’s opinion, the future of Amateur packet radio urgently requires a move to higher Baud rates for both the end-user and backbone links. …
It is somewhat of a surprise and a disappointment to the original developers of the TNC to see that almost seven years later, in 1986 that almost all packet radio operation is done at speeds no higher than 1200 Baud.
-- Features of the VADCG TNC+, Douglas Lockhart, VE7APU, 1986