[aprssig] Error checking within APRS packets

Thu Jun 23 07:11:34 EDT 2011

Yes, I think I agree with everything you say!

A proper synch sequence (16 or 24 bits), proper packetisation and a proper
FEC would improve the efficiency of the system immensely!

G7ORK

Derek Love, Applied Technology UK
+44 1749 881130

-----Original Message-----
From: Guido Trentalancia [mailto:iz6rdb at trentalancia.com]
Sent: 22 June 2011 17:01
To: aprssig at tapr.org; Derek Love
Subject: Re: [aprssig] Error checking within APRS packets

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
>

_______________________________________________
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/20110623/59868c73/attachment.txt>