FT8 demod for monitoring #1561
Comments
|
Might not be ready yet, but couldn't resist giving it a try :) On Ubuntu 22.04 with 2m preset, I get: ft8/unpack0.cpp:53: uint64_t FT8::un64(int*, int, int): Assertion `len < (int)sizeof(x) * 8 && start >= 0 && start + len <= 63' failed. #7 0x00007fff6ec299b4 in FT8::un64(int*, int, int) () at /opt/install/sdrangel/lib/sdrangel/libft8.so If I disable the assertion, I can receive packets though. Nice! |
|
Just saw this assertion: /opt/build/srcejon/sdrangel/ft8/fft.cpp:97: FT8::FFTEngine::Plan* FT8::FFTEngine::get_plan(int, const char*): Assertion `p->fwd_' failed. Although has only happened once (whereas the above is pretty frequent) |
|
I see quite a few issues with "their" implementation of FFT. I might try to use "my" FFT factory instead (with some adaptations). Moreover it does not seem to use a wisdom file which can result in a very slow startup on Raspberry Pi (not tried yet). And yes... assertions were OK for a standalone program but not suitable here. I might have to do some cleanup in that sense. |
|
I worked on using FT8 and HAMLIB interfacing with sdrangel version 4.08 using the REST interface. I did this by modifying HAMLIB to add a strangle rig and then to send and receive the commands to SDRAngel with REST. After getting things to function I found the turnaround time required by the WSJT-X code could not be reached and had to abandoned the effort. I posted a few comments about this work here. I tried to get the FT8 maintainers to allow a bit more turnaround time and they said no and to go find a different rig.
The turn around time is critical for FT8 so keep this in mind when moving forward.
I do wish you success in this effort.
Bob N5BRG
On Jan 23, 2023, at 7:58 AM, Edouard Griffiths ***@***.******@***.***>> wrote:
I see quite a few issues with "their" implementation of FFT. I might try to use my FFT factory instead (with some adaptations).
—
Reply to this email directly, view it on GitHub<https://url.emailprotection.link/?buEq4eyNl9NRYRhKUfm4VcLZguVGjqmEIbG64xeogqXsBnIENfDonR9xz7F_UmFAxaGMUdCyjW3symDQecn7HlLl8pfZ3GCPaHWPphFimzOwYIhbUrRCQPkNWQZ4-0FQN>, or unsubscribe<https://url.emailprotection.link/?bjfpl1gdwV0owUrv_O4w1FNdWxxd0XCyds-yymWyO5IA1eL1_qLbd9205HEMz9-7r7TltS41r_Q_U7dU6x4vvN2sWXK9dMqCJq1MKveCfBZqzfYBestDA3tqAodNFjc3yEZn9X_R4_Pjpopr_krEKQqt9wQT1qG9AvnUWOhuT4e8~>.
You are receiving this because you are subscribed to this thread.M essage ID: ***@***.***>
|
Well... hence the "for monitoring" in the title. For now it is not intended for traffic. In order to do this you need a modulator and a feature to do the QSO logic to control the Rx/Tx sequence. This may be done in a later step. For now with a decoding time budget of 0.5s results are comparable if not better than the with the original WSJT-X code thanks to Robert Morris, AB1HL code . 0.5s is not bad but the time budget in the protocol is very tight even without considering the buffering that will occur both in the Rx and the Tx path:
This leaves 2.36s of turnaround time but you have to accommodate some slack for late messages. Not much time even for human decision so if one day traffic mode is implemented it will be only automatic. For now let's observe how it goes in receiving mode with 15s buffers. For real traffic the decoding should start ahead of time with a shorter portion of real samples padding the end of the buffer with zeros.
As demonstrated above you cannot really move the walls with the FT8 protocol so this probably explains. |
|
Actually on the transmission side (TBD) it is possible to benefit from the first sync period which is a fixed sequence (Costas sequence) thus this adds an extra slack of 7 symbols that is 1.12 seconds. |
|
Implemented in v7.9.0 |
I've been playing with FT8 reception recently connecting the audio output of the SSB plugin to the WSJT-X program which is an easy set up. Then I could analyze the CALLxxx.TXT file(s) to get statistics and a visualization of the received locator squares using a Python Jupyter notebook.
However there are some shortcomings when you would like to go a bit further...
Having a FT8 demod plugin would also make it possible to collect data from multiple receivers in a specific FT8 feature plugin (not covered in this issue) so as to be able to collate results in a single file with the correct frequencies. This would be a bit similar to what the AIS demod / AIS feature couple does. In addition this opens the possibility to display locator squares live on a map.
At least for now the plugin would not be intended for real traffic. There is a significant delay induced with data buffering that makes it difficult to handle Rx and Tx. Moreover you have a delay in each way. It is easy to overcome the Rx delay if you do Rx only because you can start the 15s recording arbitrarily but for Tx-ing with only a reasonable delay you would need to anticipate. This leaves very little time for decision even if since the first CQ all the information is available. You still need to know if the answer to the CQ was received or not.
There is a very interesting port of the original Fortran WSJT-X code in c++ here: https://github.com/rtmrtmrtmrtm/ft8mon Moreover it seems that the core process resides in only one FT8 class which would facilitate integration. However it uses standard threads so for portability it may be necessary to rewrite parts of the code using QThreads. Also this seems to work as well or better than the original WSJT-X code.
The text was updated successfully, but these errors were encountered: