[aprssig] IGate wildcards/Telpac data

Robert Bruninga bruninga at usna.edu
Tue Feb 15 14:36:02 CST 2005

I stand by my statement.  "such a callsign cannot
be "originated" by a raw TNC, but that is a limitation
of the TNC."  If you want more elaboration, then I will
refer you to the APRS spec where the 9 byte APRS
callsign field is defined as the typical TAPR-2 Clone
standard way of displaying a callsign in monitor mode.

>>> henk.de.groot at hetnet.nl 2/15/2005 3:01:14 PM >>>
Robert Bruninga schreef:
> is just fine.  Such a callsign cannot be "originated"
> by a raw TNC, but that is a limitation of the TNC,

No, it is NOT a limitation of the TNC, it is a limitation of the AX.25

protocol. Every address in AX.25 is encoded in 7 bytes (not 9), 6 of
are uppercase ASCII which is binary shifted left one bit to clear the 
lowest bit as "end" marker. The 7th byte is divided up in a 4 bit SSID
a bunch of flags, The meaning of the flags depend on which address you
looking at, but bit 0 is still the "end" marker.

With 4 bits the SSID can have a value between 0 and 15.

So that's it, if you want to use the AX.25 protocol you are stuck with

this and no TNC maker can change it unless they invent a new protocol.

Now where does this "9" characters come from while it it only 7 bytes?

Simple, the 7th byte needs a readable text representation to be able to

show up in the TNC monitor and TAPR aparently decided to depict them as
hyphen and a SSID number. In some cases also other parts of this 7th
is encoded, for example the "*" character on digipeater call represents

one of these flags. This is an arbitrary choice, they could have chosen

any representation for this. They already did something special for
for example by omitting the hyphen and SSID in that case (the 7th byte
always there so every address has an SSID, wether you see it or not in

Anyway, it is by no means a limitation of the TNC, its just the
specification that detemines what you can and cannot use.

An anology. Not being able to use an IP adres like is
a limitation of your network card, it is the IP protocol that enforces
limitation, this is because the value is send as 32 bit binary in the
packet. Now if I write an application I could allow for 
to appear as an (ASCII) IP number. But then stating that it cannot be
because of a limitation of the network card is a bit silly IMHO.

CCCCCC-WL may be an address, but its not necesarily an AX.25 address. 
Since APRS claims to use AX.25 UI frames implies that the addresses are

AX.25 addresses. It is true that because you use the ASCII
of an AX.25 address on the IS you can do things to it that you can't do
AX.25. But these can never be send in an AX.25 packet, just like my 5
IP address can never be used in an IP packet.

Now, if on the IS it is allowed do things to the address that are not
accordance with AX.25, what is the rationale to stick to only 9 bytes?
you don't care less about the AX.25 addressing rules, why limit
to another limitation just because TAPR decided to use a certain 
representation in the monitor...

Kind regards,


aprssig mailing list
aprssig at lists.tapr.org 

More information about the aprssig mailing list