[aprssig] IGate wildcards/Telpac data

[Robert Bruninga]

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.
Bob

>>> 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
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.


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