From: Dave Platt <dplatt@radagast.org>
To: Matti Aarnio <matti.aarnio@zmailer.org>
Cc: Linux-Hams <linux-hams@vger.kernel.org>
Subject: Re: AX25 help site
Date: Sat, 05 Sep 2009 11:14:16 -0700 [thread overview]
Message-ID: <4AA2AA78.5000605@radagast.org> (raw)
In-Reply-To: <20090905160400.GH3807@mea-ext.zmailer.org>
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-FLAG
>
> The 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.
next prev parent reply other threads:[~2009-09-05 18:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-31 14:27 AX25 help site Douglas Cole
2009-08-31 22:48 ` Curt, WE7U
2009-09-01 1:06 ` Bob Nielsen
2009-09-01 22:06 ` w8iss
2009-09-01 22:59 ` Dave Platt
2009-09-05 1:32 ` Curt, WE7U
2009-09-05 16:04 ` Matti Aarnio
2009-09-05 18:14 ` Dave Platt [this message]
2009-09-06 1:01 ` Fldigi and RTTY decodes David A. Ranch
2009-09-06 2:43 ` Dave Platt
2009-09-06 3:29 ` David A. Ranch
2009-09-06 4:52 ` Dave Platt
2009-09-05 20:40 ` AX25 help site David Ranch
2009-09-05 22:20 ` Dave Platt
2009-09-05 1:01 ` Curt, WE7U
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AA2AA78.5000605@radagast.org \
--to=dplatt@radagast.org \
--cc=linux-hams@vger.kernel.org \
--cc=matti.aarnio@zmailer.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox