[aprssig] DireWolf error correction?

[Scott Miller]

I tried that on the OpenTracker years ago, but wound up setting it aside 
because of the concern for false positives.  I suppose I could resurrect 
it and make it an optional setting with the additional sanity checks, 
but I wouldn't make it the standard setting.

If you've got additional data from your discriminator you can start with 
the bits closest to the threshold.  That would be easier with straight 
FSK rather than AFSK, I think.

Scott
N1VG

On 6/12/2013 10:09 AM, Steve Daniels wrote:
> Here is the relevant section of what WB2OSZ has written
>
> My original attempt at receiving APRS signals performed the HDLC decoding real time on the bits from the AFSK demodulator. If the FCS was wrong, the frame was discarded. The original bit stream was gone. No second chances.
> In version 0.6, the HDLC decoder was rearranged to operate in two different phases. The first phase only looked for the special 01111110 “flag” patterns surrounding the frames. The raw received data was stored in an array of bits without undoing the “bit stuffing” at this time. This stream of bits was then processed in the second phase. This provides an opportunity to give it another try if it didn’t go well the first time.
> For single bit errors, we can try to invert each of the bits – one at a time! – and recompute the FCS. My experimentation found this recovered a lot of packets that would normally be discarded. Experimental results are summarized in a table later.
> What about two or three adjacent bits getting clobbered along the way? If something is good, then more must be better. Right? The next experiment was to try modifying groups of two or three adjacent bits.
> Why stop at modifying only adjacent bits? What about two non-adjacent (or “separated”) single bit errors? This also allowed a fair number of additional frames to be decoded but at a much larger cost. The processing time is proportional to the square of the number of bits so it climbs rapidly with larger packets. This often takes several seconds rather than the couple milliseconds for all the others.
> There is one little problem with flipping various bits trying to find a valid FCS. We get a lot of false positives on the FCS check and end up with bogus data. Callsigns contain punctuation characters. The information part has unprintable characters.
> The 16 bit FCS has 65,536 different possible values. Even if totally random data goes into the checking process, you will end up with a valid FCS one out of every 65,536 times. When you try hundreds or even thousands of bit flipping combinations and process lots of packets, a fair number will just happen to get past the FCS check and produce bad data.
> My solution was to run the results through an additional sanity check. A valid AX.25 frame will have:
>  An address part that is a multiple of 7 bits.
>  Between 2 and 10 addresses.
>  Only upper case letters, digits, and space in the addresses.
>  For APRS, the information part has only printable ASCII characters or these:
> o 0x0a line feed
> o 0x0d carriage return
> o 0x1c used by MIC-E
> o 0x1d used by MIC-E
> o 0x1e used by MIC-E
> o 0x1f used by MIC-E
> o 0x7f used by MIC-E
> Page 34
> o 0x80 seen in "{UIV32N}<0x0d><0x9f><0x80>"
> o 0x9f seen in "{UIV32N}<0x0d><0x9f><0x80>"
> o 0xb0 degree symbol, ISO Latin1
> (Note: UTF-8 uses two byte sequence 0xc2 0xb0.)
> o 0xbe invalid MIC-E encoding.
> o 0xf8 degree symbol, Microsoft code page 437
> After applying this extra step of validity checking, no bad data was ever observed for the single bit fixing case. In very large sample sizes, there were a few cases of bad data getting thru when flipping more than one bit.
>
> Steve Daniels
> Amateur Radio Callsign G6UIM
> Torbay Freecycle  Owner
> http://uk.groups.yahoo.com/group/torbay_freecycle
> APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com
>
> -----Original Message-----
> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf Of Robert Bruninga
> Sent: 12 June 2013 16:14
> To: aprssig at tapr.org
> Subject: [aprssig] DireWolf error correction?
>
>> Yesterday I had a chance to try substituting 'Dire Wolf' for AGWPE.>
>> The Dire Wolf is only a software emulation of a hardware TNC....
>> There is no place to enter the PASSALL command
>> but the error correction in Dire Wolf visibly improved performance.
>
> I wonder how that works?  There is a lot of redundancy in APRS formats in
> many cases using only 36 of the 256 bit character set meaning there is a
> good way to guess at some mangled bits...  I always wanted to play with
> some techniques, but never got around to it...
>
> Anyone know more about this?
>
> Bob, WB4APR
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>