[aprssig] Error checking within APRS packets

[Derek Love]

Guido:
The bit-stuffing process should mean that an bit field of 01111110 on the
ASCII side gets translated to 011111010 over-the-air and  so can never get
confused with a start/end flag.

I note that some people on the list seem to think that the AX-25 protocol is
robust and eminently suitable for radio use. I have to disagree, having
spent the last 10 years messing around with it, I absolutely hate it. There
are many, many better protocols and coding systems out there that perform
far better (in my opinion) and when we DO decide on the next generation of
APRS, I sincerely hope that AX-25 will NOT be a component of it.

Derek Love, Applied Technology UK
+44 1749 881130


-----Original Message-----
From: Guido Trentalancia [mailto:iz6rdb at trentalancia.com]
Sent: 21 June 2011 21:40
To: TAPR APRS Mailing List
Subject: Re: [aprssig] Error checking within APRS packets


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

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


Registered Office- Oval Park. Hatfield Road. Langford. Maldon. CM9 6WG
Registered in England and Wales. Registered No. 02847065. VAT No. 368 6007 36
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CML Group Disclaimer.txt
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20110622/5a5a2292/attachment.txt>