[aprssig] Error checking within APRS packets

[Guido Trentalancia]

On 22/06/2011 18:43, Bill V WA7NWP wrote:
>>> 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.
>> 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.
> The APRS spec says to never use a tilde in the text field?   If it's
> true, that's silly.   It's just another ASCI character.  The
> bit-stuffing magic happens at the hardware packet level and is totally
> independent of what we put in the packet data -- for APRS or any other
> packet application.

There is also the pipe "|". But that's really useless in the context of 
human communications. Just used in computer science.

If Bob removed that restriction on the tilde, configurable TNCs could be 
still switched by the pipe (which usually is the default). And we could 
send ALL URLs.

>>>   There
>> . Even the same AX.25 could be improved. For example, I would be
>> quite keen to see proper FEC in place of CRC.
>>   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.
> Check out the presentations on FAX.25 (or something by a similar name...)

Already done before you wrote me.

Interesting, but that's FEC at layer 2. I think FEC at layer 1 is better 
so that layer 2 stays lean and independent of radio channel. And another 
reason is that errors should be corrected as soon as possible where they 
take place. If errors take place at the physical layer, why delaying and 
demanding detection and correction at another upper layer ?

> AX25 is 'good enough' for what we're doing now.  The real need is
> something better to do with it...  :-)

More or less, that's my same opinion. And if something could be 
improved, it would be better done at the bottom (beginning with proper 
multi-level modulation, then FEC).

> 73,
> Bill - WA7NWP

73,

Guido IZ6RDB