[aprssig] Error checking within APRS packets

[Rud Merriam]

The software reading packets should be looking for two framing 
characters as the indication of an end of one message and the start of 
another. If the software sees a single 0x7E, as a result of two packets 
colliding, it should be really careful with either of the two possible 
packets.

The FCS should cause the first to be rejected. In the highly unlikely 
chance that it passes that check the parsing of the packet is going to 
fail if the packet header is incomplete, i.e. everything up through the 
protocol ID has to parse correctly. Specifically the 0x03, 0xF0 sequence 
must appear for the control and protocol fields. If all that happens, 
the APRS parsing of the Information Field has to be valid.

In summary, IMO the chances of correct "TNC" software passing a bad 
packet is close to zero. In turn, incorrect "TNC" software would 
probably be passing a large number of bad packets. I put "TNC" in quotes 
since it really refers to any software processing packets received from 
RF, which would include sound card packet.

Based on my decades of software debugging experience, including 
communications protocols, I would start debugging this somewhere else in 
the processing chain. Or, at least, gather a lot more information to 
confirm or deny this failure mode.

In addition, the RF is going to be noisy during the overlap period as 
one station is keying up over the other. For many milliseconds the first 
packet is going to be corrupted and unlikely to be decoded. Again, I'd 
look elsewhere before spending much time on this possibility.

- 73 -
*Rud Merriam K5RUD
Emergency Coordinator
/Montgomery County ARES® <http://www.wa5eoc.org/> /
* /Mystic Lake Software <http://mysticlakesoftware.com/>
/

On 6/20/2011 10:35 PM, Gregg Wonderly wrote:
>
> That is my hope, and so I'm asking these silly questions to see if 
> there is something I missed in some discussion that would otherwise 
> demonstrate that there are some failure modes of TNCs that are not 
> always seen except in circumstances that are rarely happening.  It 
> seems that the general issues of how the 0x7e and the CRC-16 work is 
> well known, and they take care of keeping "bad" data from being 
> accepted by the TNC from the X.25 layer and passed to the user.  If 
> there are two overlapping packets as I described, the flag byte should 
> at least cause the beginning packet to be tossed.  I believe the 2 CRC 
> bytes come before the terminating flag.  If so, the TNC could, 
> determine that what follows the terminating flag was not a starting 
> flag and thus assume that the scenario I described was happening, and 
> successfully copy the second packet.
>
> This scenario, I think, illustrates why AX.25 degrades so quickly.  As 
> time between packets decreases and the disappears, only the absolutely 
> loudest stations will be successful, and only in particular time 
> sequences.
>
>
> Gregg
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20110621/cee7e451/attachment.html>