FT8 decoding

[lu7did]

Hello,

I've been not successful to decode FT8 using .wav files taken from elsewhere. Could U place some .wav samples you are sure that works or that you use as part of your test as part of the package?

73 de Pedro, LU7DID

[kgoba]

Hi Pedro LU7DID,

Make sure you have well aligned the WAV files with the 15 second time mark. The decoder searches through time offsets within about a second, but still you have to be quite exact on the 15 second frame. The audio length should be 15 seconds. The decoder should work with any sample rate that is integer multiple of 6.25 Hz, but I have only tested 12000 Hz and 6400 Hz.

Do your own WAV files decode with WSJT-X (there's an option File->Open to decode from WAV)?

I have been thinking of putting up some test files indeed that I have recorded from WebSDR. I thought perhaps it's not nice to put up information containing callsigns etc, but I guess it's public information anyway, so I will do that soon.

[lu7did]

Thank you! The files I'd tried to use are the ones posted along with the ft8basic package, which when used with that package decodes fairly well. I didn't tested them with WSJT-X program no used samples from it with your program, but few samples that works ok for you would be a nice "smoke test" to ensure that everything is installed and set properly with your package. Thanks! 73 de Pedro, LU7DID

[kgoba]

If you mean https://github.com/rtmrtmrtmrtm/basicft8, then the samples there are still version 1 of the FT8 protocol, which is already phased out (it was used in WSJT-X versions prior to 2.0.0). The basicft8 repository has not been updated to the latest version of FT8. However, author's other repository https://github.com/rtmrtmrtmrtm/weakmon has been updated, though it does not contain any samples.

decode_ft8 does not support FT8 protocol version 1. There are routines however in the code for the old protocol if anyone is curious.

[kgoba]

I have added some test WAV files recorded from WebSDR in Europe. You can also find the messages as decoded by WSJT-X in a corresponding TXT file. I will later add a test utility that can automatically score the results against WSJT-X. So far it's decoding about 70-80% of what WSJT-X can decode, and even some occasional messages that WSJT-X misses.

[lu7did]

Hi, You're right! The files points to the "old" FT8 format. TU to add your own set, it would be very helpful.

If I'm not mistaken what is left in your decoder to enable it as a receiver is to allow input thru stdin and to have some way to sync itself with the FT8 15 secs windows, right?

Having these two plus some implementation of the rtl-sdr receiver, plus some data manipulation with csdr plus ntp running plus and you should have a fully operational FT8 receiving chain.

73 de Pedro, LU7DID

[lu7did]

Hi,

I'm getting segment violation when executing decode_ft8 with any of the sample .wav files, both from wsjtx or your test suit; cloned and rebuild the package and still does that.
Any idea?
73 de Pedro LU7DID

[kgoba]

That's strange indeed. What OS do you have? I have checked on Mac OSX, Ubuntu 14.04 and Mint 18.3, and I have no errors.

[lu7did]

My mistake

sudo ./decode_ft8 ./tests/websdr_test13.wav
92 blocks, 960 bins
N_FFT = 3840
FFT work area = 38676
Max magnitude: -19.4 dB
000000 146 0.3 1544 ~ PD3JO IZ2ODN R-13
000000 183 0.5 900 ~ CQ IK4LZH JN54
000000 141 0.6 2828 ~ CQ F8IJV/P IN97
000000 129 0.6 1122 ~ KA5M SV2FPI -13
000000 165 0.6 1428 ~ CQ 9A7DA JN86
000000 204 0.4 1881 ~ CQ PD1ECA JO32
000000 182 -1.1 306 ~ EA8BEV LU3DW RR73
000000 227 0.6 1319 ~ R7EL VE9FI R-07
000000 199 0.6 1650 ~ CQ HA1RB JN86
000000 291 -0.8 2600 ~ K2DSW IU8LLZ R-16
Decoded 10 messages

73 de Pedro, LU7DID

[lu7did]

Hi,

Following on previous posts I would like to share that I'd processed some few thousand .wav files from the repository left by the wsjt-x program in my main station (FT2000+4 El Yagui+PC Intel i7 4x4 GHz+)

Pending to complete a more rigorous analysis of the results I can say that the ratio of successful decoding by the decode_ft8 program is close to the 50% of the cases; which I found remarkable given the vast computing power difference between the machine where wsjt-x runs and the raspberry pi Model 3 where the evaluation where performed.

Computing time averages 1.2 secs per file; however when excluding files where no decoding where made the number goes up to close to 2 secs per file, again on a raspberry pi environment.

I found, as said, both results good and remarkable.

I believe that if the development roadmap includes to feed from live audio for a true receiver somewhere in the near future some optimization in the processing time needs to be made as the average time taken exceeds the 1.52 secs (theoretical, best case scenario) before the new window starts. However a quick overview of the code shows several spots where optimizations can be made with reasonably small effort.

Really very good implementation work so far.

73 de Pedro, LU7DID

[kgoba]

Hi Pedro,

thank you for the excellent report!

1. It would be super interesting to compare the decodes with WSJT-X run on RPi itself. As I understand, it's possible, but I wonder how much the decode quality would suffer.

2. My original intent was to aim for ARM Cortex M series microcontrollers, and that's why some design decisions have been made (conserve RAM, do only single pass), but now I see that people are very keen to try this on "desktop", that is RPi at least. I now wonder if I should think of further development in this new light, but before that I would still like to reach my original goal and to have the first FT8 decoded on a MCU, and a full QSO would be even better.

3. I am keen to learn about your observations on potential optimizations. I kept the initial implementation reasonably balanced in terms of readability, closeness to the original WSJT-X approach and optimization. (Also, a dumb question, but did you run your tests with -O3 compilation flag enabled?)

4. Occasionally my implementation decodes messages that for some reason WSJT-X does not decode even on the deep setting. It can be seen in one of the test files in the repository (can't remember now which one). The extra decoded message seems perfectly valid and not a false decode, but WSJT-X does not see it. In terms of DSP the WSJT-X code has some dubious approaches (e.g. computing FFT without proper windowing), so that might be related to that. Would be interesting if you could run your comparison experiment and count the errors in both ways.

[kgoba]

Also, note that the decode time can be adjusted by changing the number of candidates (kMax_candidates) and LDPC iterations (kLDPC_iterations). Perhaps they can even be lowered to speed things up without losing quality. It's subject to investigation, and your data is actually very helpful, so if you're interested and have time for that, I would be happy to learn what you can observe by changing the decode parameters.

[lu7did]

Sure do these parameters would influence the data. Also, if I'm not mistaken an optimization is pending to sort the candidates by order or likelihood. I didn´t observed in the code a hard time limit, which would be very handy. Although evaluations can be made out of .wav files nothing is better than real signals, so the ability to get a live stream would be very beneficial. I'd forked the package but didn't attempt any modification as I'm not sure what part of the code are you working with or plan to work with.
73 de Pedro LU7DID

[lu7did]

Hi Pedro,

thank you for the excellent report!

Interested in your package, eager to contribute!

1. It would be super interesting to compare the decodes with WSJT-X run on RPi itself. As I understand, it's possible, but I wonder how much the decode quality would suffer.

I ran this, but with far fewer cases. However, wsjt-x in the RBPI saves only files with some decoding, so it's easy to count the number of hits (actual files where something was decoded/total number of files).

2. My original intent was to aim for ARM Cortex M series microcontrollers, and that's why some design decisions have been made (conserve RAM, do only single pass), but now I see that people are very keen to try this on "desktop", that is RPi at least. I now wonder if I should think of further development in this new light, but before that I would still like to reach my original goal and to have the first FT8 decoded on a MCU, and a full QSO would be even better.

I think light is good as a first approach, but as mentioned in the previous response, process only .wav files limits the usefulness of the package; externalizing some of the processing chain would be a good option IMHO so perhaps just receiving the stream of S15-LE mono thru standard input should be a very flexible approach.

3. I am keen to learn about your observations on potential optimizations. I kept the initial implementation reasonably balanced in terms of readability, closeness to the original WSJT-X approach and optimization. (Also, a dumb question, but did you run your tests with -O3 compilation flag enabled?)

Yes

4. Occasionally my implementation decodes messages that for some reason WSJT-X does not decode even on the deep setting. It can be seen in one of the test files in the repository (can't remember now which one). The extra decoded message seems perfectly valid and not a false decode, but WSJT-X does not see it. In terms of DSP the WSJT-X code has some dubious approaches (e.g. computing FFT without proper windowing), so that might be related to that. Would be interesting if you could run your comparison experiment and count the errors in both ways.

Assumed that possibility would be an outlier (2x 3x std dev off) so didn't actually counted them.

73 de Pedro, LU7DID

[m0nka]

I would still like to reach my original goal and to have the first FT8 decoded on a MCU, and a full QSO would be even better.

i think i am getting there. At least the encode is done. But to realise that, i had to use one of my video buffers(about 1.7 MB) in external SDRAM. Haven’t tried decode or real time decode/yet(very little free time atm).

[chillmf]

Dear Karliss,

I am happy to report that after a lot of gnashing of teeth I have gotten your decode software to work on an STM32f769 Disco board.

Thanks for sharing your work.

Charley, W5BAA