[aprssig] "Best" packet decoder solution

[Phil N6TCT]

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