[aprssig] Error checking within APRS packets

Wed Jun 22 12:00:51 EDT 2011

Hi Derek !

Thanks for your time...

On 22/06/2011 10:39, Derek Love wrote:
> 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.

Yes, sure. That's pretty clear at this moment, even to me, after 
revising it briefly under Lynn's advice...

The point is that APRS is not taking advantage of that trick. Because 
APRS is explicitly forbidding that pattern to occur anywhere in the 
information field of its packets.

So, for plain AX.25 or other applications it definitely makes sense and 
it definitely sounds important to remember that, but for APRS 
specifically it seems to me that it doesn't even matter remembering that 
because it's not going to be directly exploited by APRS.

To be more precise, it could only be used (in APRS) for the FCS field 
(the well-known two-bytes CRC field just before then 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.

Not necessarily.

>   I have to disagree, having
> spent the last 10 years messing around with it, I absolutely hate it.

Yes, of course, I agree that with greater experience as you have 
compared to me it might also come greater disappointment with this or that.

>   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.

Yes, I agree. Even the same AX.25 could be improved. For example, I 
would be quite keen to see proper FEC in place of CRC. Also, as I 
already noted elsewhere, better sync with a more rapidly varying pattern 
for the flag. And better flag as that one could be used from ASCII tilde 
from human user input in the information field which would not be 
uncommon for URLs and in a computer science context.

But, in my opinion, most imporantly is the layer 1 that should be 
improved as it could bring most benefits. So, I suppose it would be even 
better if FEC is introduced there as more powerful schemes could be used 
and also the upper layers would be indipendent and it could optionally 
use different levels of FEC adaptively as needed.

What do you say ?

> Derek Love, Applied Technology UK
> +44 1749 881130

But, do you not have a callsign ?

73,

Guido IZ6RDB

> -----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 hostwww.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
>