All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.