[aprssig] Error checking within APRS packets

Guido Trentalancia iz6rdb at trentalancia.com
Tue Jun 21 15:04:07 EDT 2011

On 21/06/2011 04:44, Guido Trentalancia wrote:
> On 21/06/2011 00:24, Gregg Wonderly wrote:
>> On 6/20/2011 4:32 PM, Lynn W. Deffenbaugh (Mr) wrote:
>>> On 6/20/2011 2:38 PM, Gregg Wonderly wrote:
>>>> Do we have any real examples of how the quiet TX 1/2 through packet 
>>>> followed
>>>> by loud TX complete packet can result in a "packet" too long that 
>>>> would
>>>> corrupt internal TNC buffers?
>>>> Will the start of the "loud" packet result in an end of packet 
>>>> recognition of
>>>> the "quiet TX" packet.
>>> AX.25 packets on the air not only carry a CRC-16 (which is the error 
>>> checking
>>> that PASSALL ignores), but also carry framing bits that positively 
>>> identify the
>>> start and end of a packet. "Bit-stuffing" is used to ensure that a 
>>> framing bit
>>> sequence doesn't occur within a packet. So, if a TNC is receiving a 
>>> packet and
>>> another packet stomps over it, the framing is the first line of 
>>> defense to drop
>>> the first packet and restart receiving with the new packet. When the 
>>> start/end
>>> framing sequences have been identified, then the CRC-16 is used to 
>>> ensure that
>>> everything within the frame is good (hence the name FCS for Frame 
>>> Check Sequence).
> Excellent explanation Lynn !
> I would perhaps just add: and go, find out.... the framing or "flag" 
> byte is 0x7e which coincidentally corresponds in ASCII to  ~ (tilde, 
> almost never used by humans in normal communications) but most 
> importantly it's forbidden everywhere else in the packet (other than 
> at its beginning and end) by the protocol itself !

Actually I have to correct myself here and take the opportunity to 
suggest a minor improvement to the AX.25 protocol itself (say for a 
whole-new second generation of AX.25 and APRS because it won't be 
backwards compatible):

tilde is widely used for example to represent Unix home directories and 
therefore it is also widely used in URLs (when they are hosted on 
Unix-like platforms) as in very popular ones:


So one ham that needs to send to another ham the HTTP link to Tom's 
Soundmodem software (supposedly under his own Unix-like home directory 
on Unix-like host www.baycom.org) would not be able to do that...

It's not that common nowadays, but it still happens often enough to 
potentially cause troubles.

One of the first 32 unprintable ASCII values or something beyond 127 
would perhaps do a better job (ideally something which changes more 
often to bring other advantages as well, as 0x7e is 7 consecutive ones 
and only one zero at the end).

Guido, IZ6RDB

More information about the aprssig mailing list