Linux HAM/Amateur Radio development
 help / color / mirror / Atom feed
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.


  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