Second build sold out. Message will appear here when store is ready for third build ordering.

Performance enhancements for DREAM on KiwiSDR?

edited January 2020 in General Chat
Somebody told me on Twitter that my FEC software decoders are now used in three separate places in the KiwiSDR: reading satellite navigation messages, decoding WSPR transmissions and now in the DRM30 decoder. Cool; I didn't know this before. Always nice to know it's of use.

How is performance? Since the Beaglebone has an ARM CPU, it can't benefit from all the work I did using the Intel/AMD x86 SSE vector instructions to speed up my Viterbi decoder. Ergo, you must be using my portable implementation in C, which is much slower (on the x86) than the vectorized version. On the other hand, the data rates in GNSS and DRM are so slow that this may not make much difference.

Can anybody comment on whether a version of my Viterbi decoder for the ARM Neon vector set would be worthwhile? Thanks.

Comments

  • Hi Phil. Yeah, I had tweeted you about that ()

    I haven't done any serious performance measurement on the DRM code yet, except to determine that the Viterbi stuff was taking less than 7% of the time for the particular DRM configuration used by my test recording. It's quite possible it would be more significant in other cases.

    I did a quick check a few weeks ago and found some Neon Viterbi implementations on Github. So at some point I may look at those.

    What made DRM work on the Kiwi/Beagle was throwing the switch from using doubles everywhere to floats, lol. Fortunately, the way that code was written, it was a single change in a header file.
  • edited January 2020
    Oh yes, doubles are terrible (and totally unnecessary) for DSP even on the x86. I use 32-bit floats for all data samples. Frequencies and quadrature oscillators still use doubles.
Sign In or Register to comment.