[ax25-layer2] 7-byte address proposal

[Barry White]

Yes, I realise that. That is why I suggested setting one of the R bits 
to zero to flag the need to decode the ssid as the 4th suffix character.
Looking at the way it would work in a practical manner, the operator 
would enter the MYCALL cmd with VK2AABA, the new eprom would see a 
character between A & Z instead of -n and insert the lower four bits of 
the character into the ssid field and reset an R bit.
If it was a 6 character callsign nothing would change.
An un-updated eprom in the TNC would get confused, but only on 7 char 
callsigns, it would however still work and decode the packet as 
VK2AAB-1. The user could insert his full call into the data field from 
time to time.
However that only applies to un-updated eproms, updated eproms would 
display correctly.

It is not ideal but I believe as a quick interum fix it is better than 
any other suggestion I have seen. Its backward compatibility is the main 
advantage. That is important as there will be only a small number of 7 
char callsigns for some time and hopefully ver 3 will have variable 
length address fields before too long.

73 Barry VK2AAB

Jason Winningham wrote:

> 
> On Aug 2, 2006, at 6:38 PM, Barry White wrote:
> 
>> As an interum step between AX25 ver 2 and version 3  could we not  
>> accomodate 7 char callsigns by using the ssid position in the  address 
>> field ?
> 
> 
> IIRC, the SSID doesn't have a position - it is stored in the low bit  of 
> 4 of the characters.  A bit of the SSID is shifted in, which is  why the 
> nominally printable callsign characters aren't really  printable when 
> you see a raw packet.
> 
> -Jason
> kg4wsv
> 
> 
> 
> 
> _______________________________________________
> ax25-layer2 mailing list
> ax25-layer2 at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/ax25-layer2
> 
> 



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.5/406 - Release Date: 2/08/2006