[aprssig] Error checking within APRS packets

[Guido Trentalancia]

Hi Gregg !

On 20/06/2011 20:38, 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?

A buffer usually has a pre-defined static dimension (especially in this 
particular case, as it would probably be pointless to use buffers of 
dynamic size when the protocol dictates a maximum length for packets).
So, if a packet is too long and does not fit the maximum allocated 
dimension of the buffer on the TNC, then the packet should be discarded 
as it is no longer compliant with the protocol (it's not a valid APRS 
packet if it exceeds the maximum length for an APRS packet as defined in 
the protocol). And from there, start over (for example, clear the buffer 
from previously received junk and wait for the next packet)...

It all depends on the specific implementation in some way (brand-A TNC 
might behave somewhat differently from brand-B TNC), but in any case I 
doubt there will ever be a corrupted buffer in any implementation. And 
the differences would be limited to how internally the TNC would abort 
the decoding of such invalid packet and start over. To the end user, 
they shall all behave the same: do not pass invalid packets from RF.

In very few words: if a packet is "too long" that it exceeds the maximum 
packet length as defined in the protocol then that packet is not a valid 
packet and should be discarded. If a packet is a valid APRS packet (it 
does not exceeds the maximum packet length as defined in the APRS 
protocol, amongst other requirements), then it can only be "too long" on 
a broken implementation (and I don't think this is the case that you 
were referring to).

> Will the start of the "loud" packet result in an end of packet 
> recognition of the "quiet TX" packet.

If a louder packet steps in the middle of the transmission of another 
packet that is being received somewhere, common APRS receivers would not 
be able to distinguish the two packets (basically the receiver would 
believe it is just one packet and so it would just wait for its end). A 
similar situation would be that of two hams having exactly the same 
voice and a listener that is not paying any attention to the content of 
the message but just to predefined markers at the beginning and at the 
end (e.g. "over")...

Example (CRC-16-CCITT calculated with initial value 0xFFFF is appended 
at the end after the pipe "|"):

this is a normal packet which ends here|0x7886
                  THIS IS A LOUD INTERFERER PACKET WHICH BEGINS A BIT 
LATER THAN THE "NORMAL" PACKET AND WHICH IS SO LOUD THAT YOU CANNOT 
FINISH READING THE "NORMAL" PACKET|0x520A

time flows from left to right. What the receiver would decode is: "this 
is a nTHIS IS A LOUD INTERFERER PACKET WHICH BEGINS A BIT LATER THAN THE 
"NORMAL" PACKET AND WHICH IS SO LOUD THAT YOU CANNOT FINISH READING THE 
"NORMAL" PACKET|0x520A".

However there is the CRC at the end of each packet, so the 
wrongly-decoded (say "combined") packet won't be passed from the decoder 
to the user and it would be discarded because each packets ends with its 
own CRC and the wrongly decoded packet would bear the CRC of the loud 
packet and not what would be its own CRC (0x81FB). There is only one 
chance that the wrongly-decoded packet would pass such quite strict 
check: the CRC of the loud packet is exactly the same as what would be 
the CRC of the wrongly-decoded packet. The CRC is two bytes and although 
it cannot be exactly unique for every different possible packet, there 
are very little chances of collision because of the way CRC have been 
designed.

Not convinced yet ? Try by yourself:

http://zorc.breitbandkatze.de/crc.html
http://www.lammertbies.nl/comm/info/crc-calculation.html

> How does all of this play out to indicate that there are failure modes 
> that we've seen but not been able to identify the cause of?

It sounds pretty impossible that there are failures (of man-made 
devices) with unidentified causes. I suppose this is more likely due to 
the fact that such failures have not been shared with others (for 
example on this list).

I hope somewhat I have replied to your question... If not, please let me 
know, there might be chances that I misunderstood your question.

> Gregg Wonderly
> W5GGW
73,

Guido IZ6RDB

>
> On 6/20/2011 1:25 PM, Guido Trentalancia wrote:
>> On 19/06/2011 13:57, Jason KG4WSV wrote:
>>>
>>>
>>> On Sun, Jun 19, 2011 at 3:08 AM, Max Harper <kg4pid at yahoo.com
>>> <mailto:kg4pid at yahoo.com>> wrote:
>>>
>>>     What type of error checking does APRS have to prevent corrupt data?
>>>
>>>
>>> APRS doesn't have any, but APRS is transmitted in AX.25 packets (on 
>>> VHF,
>>> anyway), and AX.25 has a 16 bit checksum (known as the FCS) to 
>>> verify the data.
>> And one day perhaps we should add the ability to also correct such 
>> errors ? For
>> example, the day when we have all moved to speeds greater than 1200 
>> (or at most
>> 9600) bits/s...
>>> -Jason
>>> kg4wsv
>> 73,
>>
>> Guido IZ6RDB
>>
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>