Order Tray | Contact Us | Home | SIG Lists

[ax25-layer2] 7-byte address proposal

Robert Bruninga bruninga at usna.edu
Thu Aug 3 15:38:08 UTC 2006


Pete,
Can you clarify the playing field so I dont have to go look all th is
up again..   Here are my recollections and understandings of the 
AX.25 address field?
1) The LSB is the extension bit, leaving 7 bits for address
2) AX.25 says we will -transmit- only Uppercase Alpha-Numerics.
3) These are bit shifted left

So we end up only "transmitting" using 36 possible alphanumerics 
in a potential address space of 128?

So the question is what existing TNC implementations will actually
"receive" something besides only the uppercase/numeric codes?
Maybe someone with a handy test setup could transmit all of
the codes to some common TNC's and see what they decode.
If most of them ignore all but the 36 uppercase/numerics, then
I guess this is a less exciting project.   But if a majority of them 
do "receive" some additional code space, maybe we can exploit it.

Probably not worth going much further until we know what TNC's
will decode.  And since KPC-3's are the major APRS installed
infrastructure in the USA, it would be nice to know (and easy for
anyone to test) what they do...

Bob

>>> pete at ae5pl.net 08/03/06 9:35 AM >>>
Unfortunately, nothing restricts 7 character calls to be alphabetic in
all but the third position.  The World Cup callsigns were a good example
of this (DQ2006A to DQ2006Z).  Also, nothing restricts countries like
the USA with single letter prefixes from using a 1x5 format (K5AAAAA for
instance).

As you have pointed out, anything done to accommodate the 7 character
callsigns within the current 7 octet address format will be a kluge with
inherent difficulties.  While a de facto standard should probably be
arrived at, we need to recognize IMO that it should not be part of the
specification due to the inherent conflicts of each proposed method.

If the header format is changed to accommodate 7 character callsigns,
then we are looking at a header format that is incompatible with the
entire install base of AX.25 2.x compliant devices and further
investigation into this needs to be addressed along with other protocol
"breaking" ideas for a new version.  It might be possible to use the PID
to indicate an extended header which would be compatible with current
devices.  If some devices or applications do not consider the PID in
their decoding, then (as was stated by someone else on this list) they
are not compliant with AX.25 2.x (2.0, 2.1, or 2.2).  For instance,
setting a PID of 0x30 (just pulled this number out of the air) might
indicate AX.25 3.0.  This would tell AX.25 2.x devices that this
protocol is not one they are looking to decode.  It would tell 3.0
devices that there are further header octets to be decoded before the
I-Field.  Those header octets could contain the real PID, extra address
octets, or any other defined header information not currently contained
in the 2.x header.

Using any of the two R bits in an address field to indicate a different
type of address is problematic from the standpoint that those bits have
already been used by other people to indicate extended packet numbering
and some other implementation features.  While neither is technically
2.x compliant, preference must be given to installed implementations for
channel compatibility.

Summary: Any 7 character callsign accommodation within the current six 7
bit characters + one 4 bit SSID addressing scheme is a kluge but a
necessary interim step that should be developed as a de fact standard
instead of part of the specification.  Before adopting a de facto
standard, we should look at (as I did previously) the plus and _minuses_
of any such scheme.  The 7 character callsigns might best be handled
long term by a variable length header denoted by a unique PID in future
versions of the specification which would not exclude using the
thousands of currently deployed devices and applications.

73,

Pete Loveall AE5PL 

> -----Original Message-----
> From: Robert Bruninga
> Sent: Thursday, August 03, 2006 7:42 AM
> To: ax25-layer2 at lists.tapr.org 
> Subject: Re: [ax25-layer2] 7-byte address proposal
> 
> > That is why I suggested setting one of the R bits to zero 
> to flag the 
> >need to decode the ssid as the 4th suffix character.
> 
> But we still need up to 16 variants under the same call.  
> Hams need lots of address space under their own call.  
> 
> Here is my latest tweak to my original idea of using the case 
> of the 6 bytes to carry a supplementary bit.
> That is:
> 
> - Case of each of the 6 characters indicates an added
>   bit of 0 if upper and 1 if lower.  This gives us 6 extra bits.
> 
> - Ignore the bit in the 3rd position.  This gives us 5 bits
>   for the 7th letter of the callsign.
> 
> - SSID is unchanged and gives each call up to 16 SSID's
> 
> The advantage of this is that the original call  except for 
> 7th letter is backwards compatible to most? existing systems? 
>  We do not have to do any "shifiting" of the 3rd byte (often 
> numeric).  If any other byte is numeric it is not a 7 byte 
> call so there is no shifting.
> 
> This makes the assumption that all 7 character calls are
> of the form XX#XXXX.    For example, WB4APRS-15
> becomes wB4Apr-15 but the mixed case combination yields 10011 
> which is "S" for a deocde of WB4APRS-15.
> 
> Just a thought?
> Bob, WB4APR

_______________________________________________
ax25-layer2 mailing list
ax25-layer2 at lists.tapr.org 
https://lists.tapr.org/cgi-bin/mailman/listinfo/ax25-layer2




More information about the ax25-layer2 mailing list