[aprssig] TNC Trace mode

[Henk de Groot]

Hello Andrew,

At 11:52 4-9-2004 +1000, Andrew Rich wrote:
>Henk why is ax25 shifted ?

I don't know the reason the original designers had, but I can guess. This 
makes recognizing the header from the rest of the packet very easy. This 
way a lot of processing power can be saved, which was especially usfull for 
the processors used in the '80s.

It works like this: You only have to look at bit 0 of every received octed. 
As soon as it turns from 0 to 1 you captured the complete header and the 
code can look at the primitive and protocol byte directly following the 
header. If it is a packet that doesn't need further processing then you can 
drop it. If it needs processing, then the processor can start to decode the 
header. So it can delay the decoding of the header and save processor time 
that way.

To clear byte 0 the ASCII callsign is shifted left by one. To undo this a 
shift right is needed, but these are usually very cheap operations for 
microprocessor (its a basic operation).

It is true that the physical layer of AX.25 is just a bit-stream, but its 
frame structure organised in octets nevertheless; this is because AX.25 was 
derived from X.25, a WAN protocol defined by standaard ISO/IEC 3309. This 
original standard had only 1 8-bit adres specifying either the destination 
or the source, depending if it was a command or response packet.

For amateur radio use the adress part had to be extended, basically the 
only thing altered was to use amateur-calls as addresses and including both 
source and destination in all packets. Additionaly the ability digipeater 
calls was added. Since presense or absense of digipeater calls made the 
address-block variable length the indication in bit 0 was added to flag the 
end of the address-block.

One oversight in AX.25 V1.0 was that is was no longer visible if a packed 
was a command packet or a response packet. To fix that two reserved bits 
from the source and desitination adres were used. In all existing 
implementations at that time these bits were either both '0' or both '1', 
so the solution was to use complementary pairs, 1-0 and 0-1 for command and 
response; this is AX.25 V2.0 which exists since 1982.

Note that the AX.25 framestructure is independent of the physical layer. 
There is nothing preventing to use AX.25 on a QPSK channel.

Also note that there are some limitations in de AX.25 protocol standard 
which are just there to set limits to enable interoperablility. For example 
the framestructure does not impose any limitation on the ammount of 
digipeaters, you can have as many as you want. To be able to keep it all in 
memory the standard allows a maximum of 8. The same goes for the packet 
size. There is no limit set by the structure, the data can go on until an 
end-flag is received. Also here to enable practial implementations on 8 bit 
processors the limit is set to 256 octets.

Of course there is technially nothing to prevent you from using another 
frame structure. There are however 2 major problems with that. First is 
interoperability, if you transmit another format none of the existing 
implementations can read it, and without a specification it is hard for 
other developers to build a complient implementation of your protocol. 
Secondly there is a legal matter. Bodies like the FCC need to be able to 
identify the source of a transmission. AX.25 is well known so they accept 
that as station identification. If you make something else you have to 
throw in CW-id's or some kludge like that to enable tracability for the FCC 
guys.

I hope this answers your question. Kind regards,

Henk.