About FT8 mode implementation on F7

[szjdb]

Dear Sir,
As the old digital mode like RTTY and PSK is few on air now, the new FT8 mode become the hotest digital mode in HF band. Can we merge them into the new UHSDR project base on F7 or even H7?

Best Regards,
BG7LJ

[df8oe]

Hi,

of course this is on our roadmap. But it will not be an easy task and we do have many, many other places of work which have a much higher priority. So it is on time plan for next year - hopefully...

73
Andreas

[G3WKW]

Important to note the WSJT roadmap which shows a significant change of format not backwards compatible coming later this year. Emerging technologies are often hindered by clones and copies which are not in sync with the mainstream. This was posted by Joe Taylor last Thursday. http://physics.princeton.edu/pulsar/k1jt/wsjt-x_v2.0.txt Bob Thornton

…

On 28 Jul 2018, at 09:08, DF8OE ***@***.***> wrote: Hi, of course this is on our roadmap. But it will not be an easy task and we do have many, many other places of work which have a much higher priority. So it is on time plan for next year - hopefully... 73 Andreas — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[df8oe]

Hi Bob,

of course. We are working in a "clean" GPLv3 project and e.g. freedv API is updated if there is a new version. WDSP AGC also. And other integrations are done with respect in standing compatible with the sources of the developers. Of course it makes thing much easy if other sources are hosted on GitHub/GitLab, too ;)

Regarding FT8:
It will definitely impossible to integrate this in any F4 MCU. It does not have enough RAM and horsepower to be successful. F7 or H7 might work - we will see. Integration of WSPR and relatd modes are pending, too. May be it will work. But firstly we must implement support of OVI40 hardware where many I2C devices are driving the modules. There will be much work which has highest priority.

vy 73
Andreas

[DD4WH]

Hi Bob
thanks for the link! I was unaware if that.
I am not sure how we will be dealing with Weak signal mode decoding.
Most decoders are really complex and we would have to implement several of them working simultaneously. The detailed description of the FT8 decoder has not even been published, because the mode is so new.
So I would like to significantly dampen all the expectations concerning weak signal mode decoding!
Encoding is a totally different story! WSPR and the like should be feasible as an encoding version, but at the moment noone is actively working on this yet. Everyone is invited to contribute here :-).
All the best 73s
Frank DD4WH

[G3WKW]

With each new release of the WSJTX software there have been several release candidates with minor tweaks in procedure or interface and there are always users who don’t like a particular improvement and stay back. Some of these have caused problems with the flow of those that have migrated and followed the release plan. Clearly the next release will need a lot more effort from the release team to manage the “great unwashed” who take pride in not reading the manual. For me the answer is a bolt on Raspberry Pi and TeamViewer on my iPad. Perhaps the hardware developers should be considering an interface to provide the necessary 5v power for the future. CAT and audio down the single USB is great, could we provide the power as well I wonder? Something to look at. Bob Thornton

…

On 28 Jul 2018, at 11:30, DD4WH ***@***.***> wrote: Hi Bob thanks for the link! I was unaware if that. I am not sure how we will be dealing with Weak signal mode decoding. Most decoders are really complex and we would have to implement several of them working simultaneously. The detailed description of the FT8 decoder has not even been published, because the mode is so new. So I would like to significantly dampen all the expectations concerning weak signal mode decoding! Encoding is a totally different story! WSPR and the like should be feasible as an encoding version, but at the moment noone is actively working on this yet. Everyone is invited to contribute here :-). All the best 73s Frank DD4WH — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[db4ple]

Hi,
I also think that using an Raspberry Pi or a cheap Windows tablet plus an USHDR TRX is much better suited for FT8 than the implementation of FT8 inside the UHSDR TRX. I think transmitting is not such a big deal but receiving and selecting a QSO partner is already difficult with a big screen.

Anyway, implementing FT8 TX&RX would still be an accomplishment and is a challenge.
73
Danilo

[szjdb]

Dear Sir,
Yes I agree with you that it is easy to play FT8 with the tablet connecting to UHSDR. But I used to encounter some adjustion or connecting issues when playing with FREEDV on my PC. Having another tablet companion often make it difficult to use by large amount of people. I think that might be the reason your team have merged the FREEDV to UHSDR. Without easy using , it can not have a lot of ham to play and the mode will disappear sooner or later, including the FREEDV or the PSK31.

I also agree that the FT8 is too new and in frequency changing. It might need to wait for the steady version to port to UHSDR. The F7 or even the H7 should have the horsepower when using the external SDRAM. However it is still a big chanllenge to port , the same with the FREEDV 700D mode. Hope you will be successful !

Best Regards ,
73 DE BG7LJ

[sp9bsl]

Hi,
a year ago I tried to use old Atom based Netbook with screen resolution of 1024x600. For the decode/transmit it worked fine, but the display resolution was too low to work comfortably. For UHSDR we now use 480x320 and working on new 800x480 which is definitelly too low for the way we work with WSJT-X. So if someone wants to do it in similar way - it will be really challenging to squeeze the screen (layout) to be useable.

73
Slawek

[szjdb]

Hi sp9bsl,
GUI should not be a big problem as we can display only 1 working channel each time. The difficult is the RAM and the MIPS cost. As the FREEDV, the auther successfully ported the 1600 version to SM1000(F4 inside) ,but failed to do on the low SNR version 700C/D. The cohpsk or OFDM modem inside the mode cost huge resource which MCU can not offer.

Best Regards,
73 DE BG7LJ

[G3WKW]

Another issue to remember is the need for accurate time sync, generally requiring internet connectivity or gps. It is one of the common requests from users, why doesn’t Wsjt include time synch. Basically for the same reason it doesn’t make coffee. There are other fine tools to do the job. On the subject of FreeDV, it isn’t obvious to UHSDR users that the embedded software is only using one of several modes that are available to users of the PC software. Flexradio has the same issue and worse in that it always uses upper sideband in common with digital modes whereas the convention is to follow the voice sideband rules allowing easy switch to analogue. I am sure this makes a few users rubbish the mode unfairly. Bob Thornton

…

On 30 Jul 2018, at 10:40, szjdb ***@***.***> wrote: Hi sp9bsl, GUI should not be a big problem as we can display only 1 working channel each time. The diificult is the RAM and the MIPS cost. As the FREEDV, the auther successfully ported the 1600 version to SM1000(F4 inside) ,but failed to do on the low SNR version 700C/D. The cohpsk or OFDM modem inside the mode cost huge resource which MCU can not offer. Best Regards, 73 DE BG7LJ — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[szjdb]

Hi, everybody,
Is there any update on the FT8 porting? This mode became the hotest mode on HF data communication than PSK/RTTY. Could we port the FT8 linux version to UHSDR?

Best Regards,

[sp9bsl]

Hi, no. There is no progress in this topic. We've described the reasons above.
I remember that Chris (M0NKA) worked on this some time ago but this is not UHSDR...

vy73
Slawek

[szjdb]

Hi, sp9bsl ，
Many Thanks !
I am dreaming of play FT8 with UHSDR when in the field day without carrying more equipment.

Best Regards,

[rogerclarkmelbourne]

@szjdb

See the comment by df8oe about CPU power required to support this.

Unless you have hardware with a STM32F7 or STM32H7 CPU (MCU) in it, then its never going to be able to support this mode.

Most of the RS918 etc, from China have the SMT32F4 MCU in them, and you can only get a radio with the STM32H7 or STM32H7 in it, if you place a special order and pay $$$

[szjdb]

Hi, rogerclarkmelbourne,
Many Thanks!
I agree with you . The price of F7/H7 becomes cheaper and cheaper. It is worth to replace the F4 to F7/H7 for better hardware platform. Still wish the porting of FT8 , EVEN for the basic function. As the TX power is always the limitation in the field operation, FT8 might be the best mode for it beside the CW.

Best Regards,

[df8oe]

This wish always will be a wish, because of it is technical impossible.

[db4ple]

I think, we all agree, the actual transmission is not the problem. Receiving and decoding, however is. With reduced input (smaller processed frequency range) it may be possible. But if the current FT8 algorithms are really scalable in this way, only experts will know (I am not an expert).

RAM to hold the 15 seconds of samples could be available on the H7 internally (depending on required bitwidth and sample frequency), but external SPI RAM would probably have to be used for F7.

I think, it is a neat challenge, but none most of us would have a chance to master.

[szjdb]

Hi, df8oe and db4ple,
Thanks for your kindly reply.
Maybe someone could do it base on the F7/H7, like the 700D mode of Freedv ,which is impossible ever before. After some kind of simplifying and trade- off , it worked even on the F4.

Best Regards,

[martinling]

I just saw an interesting proof of concept of FT8 decoding working on an F7: video of working implementation by Charlie W5BAA, based on https://github.com/kgoba/ft8_lib by Karlis YL3JG.

[db4ple]

That is interesting, someone should have look into this. Especially what HW capabilites beside the processor are required (RAM specifically to keep the recorded data).

[martinling]

The code was apparently available at https://github.com/chillmf/STM32F769-FT8-Transceiver but this repo has been removed or made private since. There was a thread announcing it on the Austin QRP group.

[rogerclarkmelbourne]

I checked archive.org and it only had one snapshot of that repo, back in 2020

https://web.archive.org/web/20200918134153/https://github.com/chillmf/STM32F769-FT8-Transceiver

Someone forked the repo in 2020

https://github.com/ve7it/STM32F769-FT8-Transceiver

And those files are idential to the files in archive.org

There a file in that repo called velvet_V1.0.bin, which looks like its a STM32 binary, i.e the begining of the file has the normal STM32 vector table addresses in it

I suspect the author never released source code, and only released a compile binary and only some basic details of how to build the hardware