[aprssig] Error checking within APRS packets

[Guido Trentalancia]

On 21/06/2011 21:11, Lynn W. Deffenbaugh (Mr) wrote:
> I think you all need to read carefully and completely the AX.25 
> specification paying particular attention to the framing characters 
> and their relationship to bit stuffing.  I suspect you'll find that a 
> tilde in the middle of an AX.25 packet actually does NOT look like a 
> framing character because the framing character really isn't a 
> "character" per se, but is actually a bit pattern.  And with bit 
> stuffing, there are defined bit sequences that are NOT allowed to 
> appear in the bit stream representation of a packet, but characters 
> that may cause confusion within a packet have extra bits stuffed (and 
> removed) on the air, but you'll never see such things in any byte-wise 
> representation of the packet.

Done. Yes, I agree it's important to read that 
(http://www.tapr.org/pub_ax25.html#2.2.6). But it's not vital if someone 
is just interested in APRS.

Because it doesn't change much for APRS as the protocol itself forbids 
using 01111110, 0x7e, tilde or whatever you like to call it.

So, at this point my question is why did APRS forbid to use that 
bit-pattern (you like it that way, I call it that way) if the bottom 
layer could accommodate in some way through a trick (called bit-stuffing) ?

First hypothesis: APRS names that "TNC Stream Switch". From this I might 
suspect that the same bit-pattern is also used elsewhere (that is not as 
clever) than in AX.25 start/end flag. And vaguely I remember something 
about TNCs... but my memory is not helping me any further now.

What do you say ?

Guido, IZ6RDB

> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> On 6/21/2011 3:04 PM, Guido Trentalancia wrote:
>> Actually I have to correct myself here and take the opportunity to 
>> suggest a minor improvement to the AX.25 protocol itself (say for a 
>> whole-new second generation of AX.25 and APRS because it won't be 
>> backwards compatible):
>>
>> tilde is widely used for example to represent Unix home directories 
>> and therefore it is also widely used in URLs (when they are hosted on 
>> Unix-like platforms) as in very popular ones:
>>
>> http://www.baycom.org/~tom/ham/soundmodem/
>>
>> So one ham that needs to send to another ham the HTTP link to Tom's 
>> Soundmodem software (supposedly under his own Unix-like home 
>> directory on Unix-like host www.baycom.org) would not be able to do 
>> that...
>>
>> It's not that common nowadays, but it still happens often enough to 
>> potentially cause troubles.
>>
>> One of the first 32 unprintable ASCII values or something beyond 127 
>> would perhaps do a better job (ideally something which changes more 
>> often to bring other advantages as well, as 0x7e is 7 consecutive 
>> ones and only one zero at the end).
>>
>> Guido, IZ6RDB