Allow compilation on Android as ISO C++ code #17
Conversation
|
Thanks, man! There are still some things in the code yet in progress (currently the whole frequency range 0 .. Fnyquist/2 is monitored, and f_min/f_max is not properly implemented), but with the next wave of boredom I will probably move it forward again. I added FT4 encoding/decoding though, and checked that it works with about 75% decoding recall compared to WSJTX. Funny thing is that I get 3-5% extra decodes consistently that WSJTX misses completely. |
|
Thanks! I use I also built a small HF PA for getting some power out on the air - https://github.com/kholia/HF-PA-v4/. |
|
@kholia Looks nice!! Good job. Did you also implemented GFSK on your board? |
|
@Guenael Thanks! I just have plain n-FSK going on I think. I will take a look at generating GFSK soon. |
|
@kgoba Quick question about one of your comment:
I didn't read the Fortran code of the official FT8 decoder, but WSPRD was using coherent decoding and it's a powerful approach get a perfect sync with a candidate signal. I don't think you can do this with your actual decoder, because you loose the phase information during the initial magnitude computation for your waterfall array. I would love to spend more time on all this stuff, but it's so time-consuming, and there are so many dragons :D |
|
Yes, indeed, WSJT-X uses quite advanced decoding since it has a lot of processing power at its use. The signal is first processed in a similar manner to my approach in order to find the candidates, but after that for each candidate the signal is frequency shifted, lowpassed and downsampled to narrow down the search, and then fine search of time and frequency offset is done on that signal. The decoding is done coherently as you mention, in multiple passes, subtracting the recovered messages in order to pick up weak signals that are "overwritten" by stronger ones close in frequency. It all should be very accurate, but what surprises me is that is still misses some quite normal signals that I decode. From the DSP point of view I think there could be some overlooked issue in the chain, some frequency aliasing or similar that has never been really pinpointed in WSJTX since in general it still works very well. |
|
@kgoba Fully agree with you. And finding a compromise between the detection ratio and processing power cover a very useful spot, specially for embedded devices. |
This PR contains a bunch of trivial fixes:
The
size_tvariables require%zuspecifier.The return of malloc calls are properly type casted.
Small whitespace fixes in
Makefile.This PR also fixes the following warnings:
The
_GNU_SOURCEdefinition is now guarded properly. This fixes a compilation warning on Android.Thanks! 👍