Order Tray | Contact Us | Home | SIG Lists

[aprssig] IGate wildcards/Telpac data

Henk de Groot henk.de.groot at hetnet.nl
Tue Feb 15 20:01:14 UTC 2005


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 them 
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 and 
a bunch of flags, The meaning of the flags depend on which address you are 
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 a 
hyphen and a SSID number. In some cases also other parts of this 7th byte 
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 SSID 0 
for example by omitting the hyphen and SSID in that case (the 7th byte is 
always there so every address has an SSID, wether you see it or not in the 
monitor).

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

An anology. Not being able to use an IP adres like 240.138.12.23.23 is NOT 
a limitation of your network card, it is the IP protocol that enforces the 
limitation, this is because the value is send as 32 bit binary in the IP 
packet. Now if I write an application I could allow for 240.138.12.23.23 
to appear as an (ASCII) IP number. But then stating that it cannot be used 
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 representation 
of an AX.25 address on the IS you can do things to it that you can't do in 
AX.25. But these can never be send in an AX.25 packet, just like my 5 byte 
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 in 
accordance with AX.25, what is the rationale to stick to only 9 bytes? If 
you don't care less about the AX.25 addressing rules, why limit yourself 
to another limitation just because TAPR decided to use a certain 
representation in the monitor...

Kind regards,

Henk.





More information about the aprssig mailing list