ft8_lib as a library

[F5OEO]

(Not an issue!)
Thank you for this amazing library, making an easy way to transmit FT8. I would like to use it for a simple Tx with Raspberry pi HF transmitting (https://github.com/F5OEO/rpitx/tree/v2beta).

I know you are still heavily working on the protocol v2, but just a suggestion : making a library could be usefull (.a) in the makefile.

Best 73

[kgoba]

Hi F5OEO,

Thanks for the support! Indeed I am actively working on this code, and it still lacks structure somewhat. The library is currently left as an exercise to the reader :) I hope it's clear what it does and how it does from the code alone. I will try to improve this in future.

73s

[F5OEO]

Incredible work ! Just tested with Raspberry Tx, and it works perfectly ! https://twitter.com/F5OEOEvariste/status/1058361794891259906

[m0nka]

Hey,

I just saw your project in my feed. Good work and thanks for sharing! I have also started on this, 1-2 months ago, but still nowhere. But i have tried to directly port the Fortran files to C, too bad it will take long time. Maybe i will have some free time and help out on your project!

73!

[kgoba]

Hi Chris! I have your McHF on the table working but still lacking a proper enclosure. Great work! (Though I would have done the layout of the controls differently)

Regarding FT8, did you get stuck on encoding or decoding? I have a decoder in the works at the moment which is pretty decent, though it would still be weaker on a microcontroller than WSJT-X due to processing power. It decodes perhaps 70-80% of what WSJT-X normally does. Haven't really put it down in C/C++ yet, but getting there. I intend to make it work on a F746G-DISCO board one day.

[m0nka]

Hello,

Wow, great that you have the mcHF, but what version ? ;) I haven't done much on FT8 front, i was in a hospital for two weeks and just had my laptop with me, so out of boredom, did some work, but since i didn't have any equipment with me, plus very low energy, i couldn't complete it. You have done so much!

Yes, i see in the sources that FT8 would be much more challenging than wspr for decode. With WSPR, at least there is no time limit, where FT8 requires fast decode, to 'catch' next 15s slot. So not only CPU power and lots of RAM, but also super fast, optimized code.

I have been constantly re-designing the mcHF to meet my original goal - to have WSPR decoder, in the radio, standalone. Right now i am trying two cpu design, the original mcHF CPU as dedicated as DSP, SSB, FFT, audio, etc, the usual processing you find in the audio_driver.c file, and then broadcast all data via fast SPI to second, much faster chip for SD card storage, WSJT processing, etc. Maybe i should port the wspr decoder first, as we already have it in C.

Anyway, all this is not easy, but fun the same time. I hope you have some fun as well with Fortran ;)

73!

[ast]

Code looks amazing! Great job! Please think about doing receive DSP as float32, or at least leave room for that as an option. We have a high dynamic range SDR transciever we are working on and we could really squeeze some extra performance out by not reducing to 16 bits.

[kgoba]

I have basic decoding working at the moment (check decode_ft8.cpp, though it's still not updated to v2), and it's using 32-bit floating point for FFT computation, which should be the fastest on an ARM Cortex-M7 core. However, the bulk of memory is actually needed for storing the 15-second FT8 message window data, so I have to resort to 8-bit values for FFT magnitudes in order to keep RAM requirements under 256 KB or so. I checked the impact of reducing to 8-bit values, and it doesn't seem to affect much.

Regarding your SDR project, at least in HF there's pretty much never a dynamic range of signals (after AGC, i.e. above the noise floor) for which 16 bits would be insufficient (it's roughly 96 dB!). I would bet you wouldn't really squeeze anything out by using 32 bit values or floating point, however, it might be just more convenient to stick to standard floating point.

[kgoba]

In any case, watch this space, I will update soon(ish) with decode routines for v2 FT8 and an example project for the 32F746GDISCOVERY kit that will have some decode functionality.

[ast]

You are absolutely right about the dynamic range. I'm working on the raspberry pi where memory is not so constrained and float operations are quite fast using neon SIMD. Keeping 32 bits would eliminate the need for any form of agc in our system and that would be quite interesting. Still, in practice, 16 bits is of course sufficient.

The reason for the huge dynamic range is that our transciever is built for use with microwave transverters in mind. We are aiming for 18-20enobs at the input.

Check out tujasdr.com for more info.

[ast]

I will probably attempt a port optimized for the raspberry pi when you release... Your code looks very well though through, well commented and modular.. so hopefully it shouldn't be too difficult?

I assume you are using quadrature input?

[ast]

It would also be very interesting if the decoding code potentially could be threaded... I realize you can't do this on the 32F746GDISCOVERY but it would be nice if ported.

[m0nka]

I have basic decoding working at the moment (check decode_ft8.cpp, though it's still not updated to v2), and it's using 32-bit floating point for FFT computation, which should be the fastest on an ARM Cortex-M7 core. However, the bulk of memory is actually needed for storing the 15-second FT8 message window data, so I have to resort to 8-bit values for FFT magnitudes in order to keep RAM requirements under 256 KB or so. I checked the impact of reducing to 8-bit values, and it doesn't seem to affect much.

Regarding your SDR project, at least in HF there's pretty much never a dynamic range of signals (after AGC, i.e. above the noise floor) for which 16 bits would be insufficient (it's roughly 96 dB!). I would bet you wouldn't really squeeze anything out by using 32 bit values or floating point, however, it might be just more convenient to stick to standard floating point.

hey!

Thanks for the update! I have added the files, will convert to C and glue somehow to my project. Will try to test and let you know. Honestly have no clear clue how to spread out the code, as i have dual CPU design, but is more than amazing start!

73!

[kgoba]

You're welcome and good luck! I know I stated the code is in C++, but actually it's not too C++ specific, so it should be easily convertible to C. The reasons for my choice are a) it was easier to transplant the code from Fortran initially, where everything is about routines, b) I haven't come up yet with an elegant way of structuring things and using modern C++ types yet keeping the code MCU-friendly, and c) I just hate overwhelming use of C macros.

[m0nka]

Absolutely no problem! Thanks for your effort! My only limitation now is time, as i am quite busy, but will try to make it running in the next few days. The emWin libs i use allow for very easy adding of controls (well easy if one has done Win32 event/messaging app coding in windows), so i already have a menu where i can glue it.

[f4goh]

Great job.
I try to run it into an arduino. compilation ok, but symbols seems corrupted.

[kgoba]

f4goh, I'll see if I can find the bug, but in meantime, could you compare it step by step with a desktop version? Are the packed bits/bytes different, or is it a problem with the tone sequence?

[lu7did]

Hello, nice piece of work. Are you considering to feed the ft8 enconder from standard input instead of a .wav file. A fair number of interesting alternatives fan out of such capability, specially when paired with F5OEO's rpitx latest commit.
73 de Pedro, LU7DID

[f4goh]

when i generate CQ F4GOH JN07 that's décode 5XK71SWT 9B O (under wsjtx 2.0). can you add your executable file into github. Tks.

[F5OEO]

Check if your FSK tones are OK :

"pi@raspberrypi:~/rpitx $ ./pift8 -m "CQ F4GOH JN07" -f 14.063e6
Message CQ F4GOH JN07
Standard message
Packed data: 00 00 00 20 46 e9 81 11 18 c8
FSK tones: 3140652000000001005226150310520420043140652724525677151065343266637614453140652"

[f4goh]

Ok, Thanks i have the same in Arduino UNO. i check tones.73