Re: AX25 help site
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Matti Aarnio wrote:
On Tue, Sep 01, 2009 at 03:59:15PM -0700, Dave Platt wrote: ...The soundmodem will transmit the required number of complete bytes, padding out the last encoded byte with zero bits, before it encodes and sends the FLAG which starts the next packet. As a result, a back-to-back packet transmission looks like FLAG-packet1-FLAG-zeros-FLAG-packet2-FLAGThe modulation leader (synch-up) is best sent as all zeros, but inter-packet gaps should be subsequent FLAGs. Of course a real receiver notes that "a back to back frame, but it has bad CRC, discard it."
Correct. The receiver is required (a "MUST" in the spec) to detect and discard any frame which is either too short, has a bad CRC, or is not an integral number of bytes (after the HDLC de-stuffing is performed). A fully-robust receiver will reject the few extra zero-bits of zero that the soundmodem may insert, for all three reasons... this "frame" is too short, an odd number of bits, and has no valid CRC. Three thumbs-down ought to be enough :-) The initial version of the TNC-X firmware was "confused" by the extra zero bits, and didn't resynchronize immediately with the second FLAG. It did reject the short "packet" as having a bad CRC, but its loss of sync meant that it didn't parse the second packet at all. I believe that this shortfall has been corrected (or at least greatly improved) in the current TNC-X firmware.
zeros - FLAG - packet1 - FLAG (- FLAG ...) packet2 - FLAG - FLAG...
Agreed - that's the way it's best done, I think.
And by the way, things are not at byte-boundaries after transmission, but they should be back again after HDLC de-stuffing.
Yes - if they aren't, then the resulting packets are bad, and the spec says that they must be discarded. -- To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html