[aprssig] AX.25 RR bit test - Holy Grail (reply)

[Lynn W. Deffenbaugh (Mr)]

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 [00] suggestion):

W9ZTH-9[00]>RX5S9P[10],K4OZS-10*[11],WIDE1*[01],WC4PEM-14*[11],WX4MLB-3*[00],WIDE2*[00]:`n2El*q>/]"4+}Mon 
146.52/446.00

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 
KISS-received packets.