[aprssig] AX.25 RR bit test - Holy Grail (reply)
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Fri Nov 30 16:19:05 EST 2012
On 11/30/2012 3:07 PM, Robert Bruninga wrote:
> So few of us can actually generate an AX.25 packet at the bit level, that
> this testing can only be done by people who can test their AX.25
> transmitting code. Maybe Byonics or Argilent, or any of the software TNC
> authors can take a crack at testing it.
Actually, since the KISS packet is fully formed in the client with only
bit-stuffing provided by the TNC, then any KISS-literate software can
play with these bits.
As a matter of fact, just for curiosity, I think the next dev version of
APRSISCE/32 will show the state of these bits in the internal trace log
diagnostics. Something like [nn] on each of the path components might
do nicely? My proposed diagnostic addition might show something like
(springboarding on Bob's  suggestion):
Once the question of whether these bits break anything, we'd need to
further determine if every digipeater out there PRESERVES these bits on
(at least) the used path components. Otherwise something that set the
bits early on might lose the bits by the time the packet arrives at the
interested station. I know that the digi logic inside APRSISCE/32 will
drop these bits because the packet goes into TNC2 format, gets the path
processed and appended, and re-generates the AX.25 header as updated.
The RR bits are most likely 00 for every piece of every packet coming
out of a KISS interface to APRSISCE/32.
Now where did I put that AX.25 spec so that I can figure out just which
bits we're talking about...
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
PS. This isn't a vote in favor or against the proposal, but a way that
some of us can start seeing what these bits actually ARE in our
More information about the aprssig