[OZAPRS] RE: [aprssig] TNC Trace mode

[Darryl Smith]

Because X25 is shifted :-)

The longer answer is that the bytes are NOT shifted, since there is no such
thing as a byte in AX25. We deal with octets, since we are talking about a
serial stream of data. We only need 7 bits for the Callsign so we only deal
send 7 bits in the Callsign.

Remember that there were no LSI or VLSI chips when X25 was decided on. It
was all done with some sort of bit bashing - either in hardware or software.
If done in software you want to stop processing the packet ASAP if you don't
want to deal with it so that CPU power could be transferred to other tasks. 

There is a classic example of a uni professor who got a something like 90%
speed increase on a TCP router by dealing with all the normal cases before
the special cases. Same logic applies here.

Darryl

---------
Darryl Smith, VK2TDS   POBox 169 Ingleburn NSW 2565 Australia
Mobile Number 0412 929 634 [+61 4 12 929 634 International] 
www.radio-active.net.au\blog\ - www.radio-active.net.au\web\tracking
 

-----Original Message-----
From: ozaprs-bounces at marconi.ics.mq.edu.au
[mailto:ozaprs-bounces at marconi.ics.mq.edu.au] On Behalf Of Andrew Rich
Sent: Saturday, 4 September 2004 11:52 AM
To: Henk de Groot; TAPR APRS Mailing List; Ozaprs at Marconi.Ics.Mq.Edu.Au;
TAPR APRS Special Interest Group
Subject: [OZAPRS] RE: [aprssig] TNC Trace mode

Henk why is ax25 shifted ?


-----Original Message-----
From: Henk de Groot [mailto:henk.de.groot at hetnet.nl]
Sent: Saturday, 4 September 2004 7:50 AM
To: vk4tec at tech-software.net; TAPR APRS Mailing List;
Ozaprs at Marconi.Ics.Mq.Edu.Au; TAPR APRS Special Interest Group
Subject: Re: [aprssig] TNC Trace mode


Hello Andrew,

At 19:27 3-9-2004 +1000, Andrew Rich wrote:
>How do i break this down ?
>
> >> 82A0AA646A9C60 AC9668A88A8660 A48A9882B24060 AE92888A404061 03F00D
>VK4TEC>APU25N,RELAY,WIDE: <UI>:

Using the AX25 protocol specification?

Let me do the one above for you:

Hex string: 82A0AA646A9C60 AC9668A88A8660 A48A9882B24060 AE92888A404061
03F00D

The first 7 bytes are the destination-callsign. It's build up from 6
shifted ASCII characters and a 7th byte with the SSID and flags.

So the destination call:

82 -> shifted right -> 41 -> 'A'
A0 -> shifted right -> 50 -> 'P'
AA -> shifted right -> 55 -> 'U'
64 -> shifted right -> 32 -> '2'
6A -> shifted right -> 35 -> '5'
9C -> shifted right -> 4E -> 'N'
60 -> 01100000 binary:
       |\/\--/\_ 0 = not the final call
       | |  \___ 0000 = SSID 0
       |  \_____ 11 = reserved, should be 11
        \_______ 0 = Command/Response bit part 1 - looks like
                     a response (on next call must be 1, otherwise
                     it is an AX.25 version 1 frame).

Next is the source call, coded the same way:

AC -> shifted right -> 56 -> 'V'
96 -> shifted right -> 4B -> 'K'
68 -> shifted right -> 34 -> '4'
A8 -> shifted right -> 54 -> 'T'
8A -> shifted right -> 45 -> 'E'
86 -> shifted right -> 43 -> 'C'
60 -> 01100000 binary:
       |\/\--/\_ 0 = not the final call
       | |  \___ 0000 = SSID 0
       |  \_____ 11 = reserved, should be 11
        \_______ 0 = Command/Response bit part 2 - expected 1
                     (it is an old AX.25 version 1 frame).

Next is the first digipeater call, coded almost the same way:

A4 -> shifted right -> 52 -> 'R'
8A -> shifted right -> 45 -> 'E'
98 -> shifted right -> 4C -> 'L'
82 -> shifted right -> 41 -> 'A'
B2 -> shifted right -> 59 -> 'Y'
40 -> shifted right -> 20 -> ' '
60 -> 01100000 binary:
       |\/\--/\_ 0 = not the final call
       | |  \___ 0000 = SSID 0
       |  \_____ 11 = reserved, should be 11
        \_______ 0 = Not used in digipeating yet

Next is the second digipeater call, coded the same way:

AE -> shifted right -> 57 -> 'W'
92 -> shifted right -> 49 -> 'I'
88 -> shifted right -> 44 -> 'D'
8A -> shifted right -> 45 -> 'E'
40 -> shifted right -> 20 -> ' '
40 -> shifted right -> 20 -> ' '
61 -> 01100001 binary:
       |\/\--/\_ 1 = final call
       | |  \___ 0000 = SSID 0
       |  \_____ 11 = reserved, should be 11
        \_______ 0 = Not used in digipeating yet

This was the last call, so next is the protocol byte:

03 = UI-frame with reset P/F bit

Next is the protocol ID, that is if it is an UI or I type frame

F0 = Plain-text. With Opentrac you find 0x77 here, that's why APRS
      and Opentrac can co-exist on the same channel (others are CC
      for an IP datagram, CD for an ARP packet (for TCP/IP) and CF
      for NetRom type packets).

Finaly there is the payload

0D = Only a carriage return in this case.

I hope this helped, I leave the other to you to decode... I wonder what
device produced this however, AX.25 version 1 was outdated in 1982!
Aparently the one who wrote the code did not understand how to set the
Command/Response bits.

Note: the above you find some bits marked "reserved". That is not quite
true, some of these are used for DAMA and Extended AX.25, but that never
ended up in the official protocol specification.

Kind regards,

Henk.




_______________________________________________
ozaprs mailing list
ozaprs at marconi.ics.mq.edu.au
http://marconi.ics.mq.edu.au/cgi-bin/mailman/listinfo/ozaprs