Porting to H743 MCU

[BitLoose]

Is a port available or in the pipeline to an MCU, like the H743? What minimum resources would be needed for RAM?

[Chris-AC9KH]

No port is available, and none is planned. The base decoder alone will not fit in 2MB flash firmware due to structural C++ overhead, multi-layered inheritance, abstraction libraries and large, complex processing pipelines. The C++ signal filtering and FFT logic would have to be completely stripped out - it makes heavy usage of standard C++ templates (std::vector, std::map), runtime type information, and standard exceptions pulls that a arm cortex compiler is not going to understand.

[BitLoose]

I agree with you that the GUI overhead would need to be dropped, the core FT8-derived encoder/decoder and JS8 message processing I am sure would fit in < 1MB flash, the MCU has a double float DSP core with 1024 MIPS, plenty enough for the task. Maybe as you take the project forward keeping the core well segregated might be good for future ports to embedded devices, just an idea

[Chris-AC9KH]

While the encoder/decoder was originally FT8-derived, that is no longer the case. The FT8 encoder/decoder is Fortan-based and runs as a separate spawned process. The JS8 encoder/decoder is completely written in C++, integrated into the C++ threading model with Qt handling internal signal routing, timing, and multi-threading. It only happens to use the same interval timing as FT8 in JS8 Normal mode (15 second interval). But JS8 utilizes variable timing and symbol rates that FT8 does not have. We have a considerably more complex DSP pipeline than FT8 and it will not compile and fit in 2MB flash.

The JS8 spec is open, but you would have to write your own implementation of a JS8 encoder/decoder for a STM32 microcontroller. The JS8 decoding process requires dynamic memory reallocation and significant raw RAM bandwidth, completely exceeding standard microcontroller linear DMA buffers on STM32 chips.

Have you looked at the JS8 code?

[Chris-AC9KH]

I'll put some stuff here you can look at to realize JS8 is not FT8. In JS8's encoder, JS8 Fast mode packFastDataMessage uses the full 72 bits for data with no reserved frame-type prefix bits the way normal mode's packDataMessage does:

QString Varicode::packDataMessage(const QString &input, int *n) {
    ...
    huffFrame = packHuffMessage(input, {true, false}, &huffChars);
    ...
    compressedFrame = packCompressedMessage(input, {true, true}, &compressedChars);

JS8 Normal mode reserves 2 bits per frame just to flag "this is a data frame" / "this is compressed" ({true, false} or {true, true}), leaving 70 usable bits. Fast mode's frames are flagged via the JS8CallData submode marker at a different layer instead, so packFastDataMessage gets the full 72 bits per frame for actual content:

compressedFrame = packCompressedMessage(input, {}, &compressedChars);

This is an example of the complexity of the JS8 encoder/decoder compared to FT8. And why it would require a complete rewrite to get it to fit in the flash on a STM32 microcontroller. There is no such thing as "segregating the core" for embedded devices since it is such a complex DSP pipeline compared to what FT8 uses. Even if were possible you would lose the advanced signal processing in the soft_combiner, whitening_processor and ldpc_feedback Kalman-style filters that improve decode probability to get us down in the -28 dB decode range. Meaning it would be crippled on STM32 chips.

JS8 relies heavily on frame accumulation. If a message spans multiple frames and encounters deep fades, the soft combiner merges the soft-decision bit probabilities across time. On an STM32, storing and processing these probabilistic matrices across multiple time intervals would absolutely choke the available RAM and bus bandwidth.

JS8's low-SNR performance relies on iterative decoding. Running Low-Density Parity-Check (LDPC) feedback loops requires massive matrix multiplications. On desktop CPUs, this is trivial. On a microcontroller, without heavy hard-coded lookup tables (which would eat up your 2 MB flash instantly), the CPU cycles required for iterative LDPC convergence would cause the decoder to miss the next timing window.

Tracking phase, time-drift, and frequency offsets in a -28 dB SNR environment requires continuous statistical state estimation. A Kalman-style filter requires constant floating-point matrix inversions.

So in summary, while not impossible, this is something the JS8Call-improved project is not going to do. It would require a completely separate fork, with a completely re-written encoder/decoder designed from the ground up for STM32 microcontrollers. Our codebase could only be used as a guideline as to how to design it.

[BitLoose]

That's all standard stuff for me, porting would be a chore of course in this case due to the necessary translation of fortran to C++ on the MCU. Extra memory isn't a problem unless 128 GB isn't enough, and the MCU is more than fast enough. Hopefully though therre is a more modern JS8 implementation that is C or C++ based without legacy fortran ;)

[Chris-AC9KH]

@BitLoose you have lost something in context, or don't understand. JS8 is NOT Fortran-based. It is C++. FT8 is Fortran-based.

[BitLoose]

Not all FT-8 libs are fortran, some of the best known are C. Anyway, at least the code is fairly simple, if a little laborious.

[BitLoose]

Just a note, I loaded JS8Call-improved, the official android port, onto my cell phone (Android 16) and it seems incomplete, with the last update back in February. What's the current status of that? There seems to be very little JS8 activity which I think is unfortunate given that it seema an excellent idea to have a freer text messaging channel.

[Chris-AC9KH]

Summertime, many of the developers are busy and don't have time for it. The Android port is managed by Kelly, it is currently experimental.

I'm not sure of the parallel you are attempting to draw with FT8. JS8 was originally based on FT8, that is no longer the case.