[aprssig] "Best" packet decoder solution

Tue Dec 28 09:40:40 EST 2010

Ohhh I get it... you guys are talking about an error dectection system 
(checksum) and trying to make it an error recovery system (FEC).  Hmm.... 
dopplegänger packets anyone?  Two IDENTICAL packets back to back.  At first 
blush you get the benefit of a 2nd shot at decoding a packet.  Take it a 
step further and you could simply compare the lesser confidence bits from 
one packe to the next.  Didn't RTTY do this?  By interleaving the bits? 
Here we'd have 100% interleave.

It's *really* a shame that AX25 doesn't support FEC at level 2.  Layer two 
only checks CRC.  But woulnd't it be neat if we could sneak FEC into level 
1?  I mean, doesn't level 1 do bit stuffing (5 0's in a row) and not pass 
that skipped/flipped bit to level 2 upon receipt?  In other words (unless 
I'm really off base), level one is not just modulating 1's and 0's onto a 
physical medium, it does intelligent things with those bits (bit stuffing), 
so why wouldn't level 1 do FEC?  Wouldn't it be slick if we could have a 
level one that did FEC for us?  That should/would be compatible (in rx) 
automatically with/without FEC?

Of course there'd be no fix for legacy TNCs like kenwoods(tasco), kpc3 and 
the like.  But currently supported TNCs like Argent data or Byonics could 
include RX either way and a config setting for TX FEC enable.

For the benefit of those who may not know, ax25 was derived from a wire line 
protocol x.25 which only allowed source and destination callsigns.  The "A" 
was added by "A"mateurs and permitted 7 digipeaters.  I don't think any 
thought was given to error correction when it was adapted to radio use.

----- Original Message ----- 
From: "Phil N6TCT" <phil_aprssig at lapsley.org>
To: "TAPR APRS Mailing List" <aprssig at tapr.org>
Sent: Monday, December 27, 2010 9:22 PM
Subject: Re: [aprssig] "Best" packet decoder solution

> It's CRC, see 
> http://www.billnewhall.com/TechDepot/AX25CRC/CRC_for_AX25.pdf
>
> To be clear, I was engaging in a little bit of hyperbole.  I wasn't
> really suggesting that we flip every single bit until we get a CRC
> match.  :-)  More like: flip 1 or 2 of the lowest confidence bits and
> give up if that doesn't help you.  While there is a cost to having too
> high a bar (i.e., not decoding a packet that could have been decoded),
> there is, as you rightly point out, also a cost to "trying to hard" and
> decoding that which was actually undecodable.
>
> Phil
>
> Lynn W. Deffenbaugh (Mr) wrote:
>> The "soft decoding" might be safe to do if it's actually a CRC, but I
>> believe AX.25 uses a simple 8 bit XOR Checksum.  Flipping "least
>> confidence" bits might actually land on the right one, but flip any
>> set of bits within a byte and you're likely to match a checksum but be
>> completely off base on the actually content of the packet.
>>
>> I could be wrong about the checksum vs CRC in AX.25 over-the-air,
>> though.  But remember a single bit in a coordinate digit can put you
>> 1/2 way across the planet.
>>
>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>>
>> Phil N6TCT wrote:
>>> That's awesome, Scott!
>>>
>>> The two things I've wanted to see in an APRS decoder for a while have
>>> been adaptive equalization and soft decoding.
>>>
>>> Adaptive equalization would take care of "twist" and the
>>> pre-emphasis/de-emphasis problem: as the receiver is syncing up it
>>> figures out what kind of spectral equalization it needs to apply to
>>> address this particular transmitter.
>>>
>>> For soft decoding, you don't make "hard" (1/0) decisions for each
>>> received bit.  Rahter, you make a soft 1/0 guess for each bit and keep
>>> track of the confidence values of each.  Then when it's time to do a CRC
>>> check, if the packet passes, great.  If it fails, you find the bit
>>> you're least confident of, flip it, and run the CRC check again.  Repeat
>>> this process until you run out of time and/or bits.  :-)
>>>
>>> Of course, both of these approaches demand lots of MIPS and aren't
>>> trivial to implement, but they will increase successful decode rate and
>>> make things more robust.
>>>
>>> Phil
>>>
>>> Scott Miller wrote:
>>>
>>>> The OTUSB does use DSP for demodulation... so does the OT1+, but in a
>>>> more simplistic way.  The algorithm is stripped down a bit to use the
>>>> HCS08's 8x8 unsigned multiply, but it does pretty well against the
>>>> test track - I got over 930 decoded.
>>>>
>>>> The 32-bit system will have better dynamic range, and will have enough
>>>> horsepower that I could have it run multiple algorithms in parallel in
>>>> case one's better in certain circumstances.
>>>>
>>>> Scott
>>>> N1VG
>>>>
>>>> On 12/27/2010 3:39 PM, Keith VE7GDH wrote:
>>>>
>>>>> Andrew VK4TEC wrote...
>>>>>
>>>>>
>>>>>> DSP ?
>>>>>>
>>>>> That stands for Digital Signal Processing. The TT4 uses DSP.
>>>>> I understand that Scott N1VG has an evaluation board with a 32-bit MCU
>>>>> capable of 76 MIPS that has some DSP instructions,
>>>>> but mentioned that it will take some months to finish developing
>>>>> the code. Someone said to Scott "now that you have gone all DSP
>>>>> on us..." I'm not sure if that meant that the OTUSB already uses
>>>>> DSP. I haven't seen any direct reference indicating that it did.
>>>>>
>>>>> http://en.wikipedia.org/wiki/Digital_signal_processing
>>>>> http://en.wikipedia.org/wiki/Digital_signal_processor
>>>>>
>>>>> Incidentally, Scott sent me an OTUSB a few days ago. I've played
>>>>> with a bit, but will have time to give it more of a workout in a few
>>>>> days. It was a pleasant surprise to find it in the mailbox without
>>>>> having actually ordered one!
>>>>>
>>>>> 73 es cul - Keith VE7GDH
>>>>> -- 
>>>>> "I may be lost, but I know exactly where I am!"
>>>>>
>>>>> _______________________________________________
>>>>> aprssig mailing list
>>>>> aprssig at tapr.org
>>>>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> aprssig mailing list
>>>> aprssig at tapr.org
>>>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>>>
>>>
>>> _______________________________________________
>>> aprssig mailing list
>>> aprssig at tapr.org
>>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>>
>>>
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 