<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#330099">
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<div class="moz-signature"><font color="#000080" face="Comic Sans
MS">
<br>
- 73 - <br>
<b> Rud Merriam K5RUD<br>
Emergency Coordinator<br>
<i> <a href="http://www.wa5eoc.org/">Montgomery County ARES<font
size="2">®</font></a> </i> <br>
</b> <i> <a href="http://mysticlakesoftware.com/">Mystic Lake
Software</a><br>
</i>
</font></div>
<br>
On 6/20/2011 10:35 PM, Gregg Wonderly wrote:
<blockquote cite="mid:4E001190.7040305@wonderly.org" type="cite"><br>
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.
<br>
<br>
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.
<br>
<br>
<br>
Gregg
<br>
<br>
<br>
_______________________________________________
<br>
aprssig mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
<br>
</blockquote>
</body>
</html>