[aprssig] "Best" packet decoder solution

[Lynn W. Deffenbaugh (Mr)]

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
>
>