Order Tray | Contact Us | Home | SIG Lists

[aprssig] "Best" packet decoder solution

Scott Miller scott at opentrac.org
Tue Dec 28 19:30:18 UTC 2010


I sent you some details on the algorithm off-list, Phil.  It's pretty 
simple.  It could do soft decision, though.  I've thought about that in 
the past, but didn't have confidence values to work with and now that I 
do, I probably don't have the clock cycles to spare for it.  Not to 
mention the RAM.  I'm going to have to wait for the 32-bit platform for 
that.

Adaptive equalization would be great.  Afraid I don't know how to go 
about doing that in a resource-constrained system, though.

Scott
N1VG

On 12/27/2010 5:02 PM, 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
>
>




More information about the aprssig mailing list