FT8 transmit dies with segmentation fault.

[wb2osz]

The builtin FT8 receive works great but I have not been able to transmit.

Power supply is 20A. Transmit power 10W.
Antenna tuner was adjusted for low SWR using antenna analyzer before connecting to sBitx.
The application was updated today.

I entered my callsign and grid square.

Clicking a station calling CQ and using the reply button, causes the application to terminate.
Same thing happens if I try using the FT8 CQ button.

This is what gdb has to say about the situation:

[Detaching after fork from child process 4266]
Sample rate 12000 Hz, 180000 samples, 15.000 seconds
Block size = 1920
Subblock size = 960
N_FFT = 3840
Max magnitude: -11.6 dB
Decoded 14 messages
[Detaching after fork from child process 4269]
Sample rate 12000 Hz, 180000 samples, 15.000 seconds
Block size = 1920
Subblock size = 960
N_FFT = 3840
Max magnitude: -11.5 dB
Decoded 14 messages
[Detaching after fork from child process 4271]
Sample rate 12000 Hz, 180000 samples, 15.000 seconds
Block size = 1920
Subblock size = 960
N_FFT = 3840
Max magnitude: -10.8 dB
Decoded 15 messages
transmitting on 753
[Detaching after fork from child process 4273]
Packed data: e6 ed ee e7 38 a9 a1 1f aa 48

FSK tones: 3140652716447647142536160317463333253140652204551215173603670207123617723140652

Thread 1 "sbitx" received signal SIGSEGV, Segmentation fault.
0xb5e9cd80 in __GI__IO_fread (buf=0x90adc <ft8_tx_buff>, size=4, count=180000, fp=0x0) at iofread.c:37
37 iofread.c: No such file or directory.
(gdb)

(gdb) backtrace
#0 0xb5e9cd80 in __GI__IO_fread (buf=0x90adc <ft8_tx_buff>, size=4, count=180000, fp=0x0) at iofread.c:37
#1 0x000250a4 in ft8_tx (message=0xbeffeafc "WA4KBM WB2OSZ -10 ", freq=2140) at modems.c:261
#2 0x0001d718 in do_macro (f=0x56410 <main_controls+93016>, gfx=0x0, event=4, a=22, b=421) at sbitx_gtk.c:2224
#3 0x0001ef84 in on_mouse_press (widget=0x3898b0, event=0x394c80, data=0x0) at sbitx_gtk.c:2618
#4 0xb6936b8c in () at /usr/lib/arm-linux-gnueabihf/libgtk-3.so.0
(gdb)

[wb2osz]

Here's the problem, in modems.c:

The FT8 audio file is generated with:

sprintf(cmd, "/home/pi/ft8_lib/gen_ft8 "%s" /tmp/ft_tx.wav %d",
...

A little later, it is trying to read a different file which does not exist:

pf = fopen("/home/pi/sbitx/ft8tx_float.raw", "r");

There is no check for NULL so the following fread dies.

FIX PART 1:

Check for failed fopen and produce an error message rather than crashing the application:

-       pf = fopen("/home/pi/sbitx/ft8tx_float.raw", "r");
-       ft8_tx_nsamples = fread(ft8_tx_buff, sizeof(float), 180000, pf);
-       fclose(pf);
+       pf = fopen("/dev/shm/ft_tx.wav", "r");
+  if (pf != NULL) {
+         ft8_tx_nsamples = fread(ft8_tx_buff, sizeof(float), 180000, pf);
+         fclose(pf);
+  }
+  else {
+    write_console(FONT_LOG_TX, "ERROR - Could not open ft8 tx audio file.\n");
+  }

FIX PART 2:

Read the same file that gen_ft8 produces. Included in above.

Closer but it's still not right.

When transmitting, horrible noises come out of the speaker.
Somewhat random yellow blocks go flashing in the upper right region.

FIX PART 3:

I threw another improvement in there.
/tmp resides on the SD memory card.
I used /dev/shm to hold the temporary file instead.
This is a RAM disk so we are not beating on the SD memory card as much and shortening its lifespan.

This would be even more important for /tmp/ftrx.raw.

[afarhan]

That code is hairy and I am nervous about it. The clean thing to do is take the ft8_lib's library and run the encode within our own process space. I think it would be best to do this in a separate ft8..c file. The ft8 modem is probably the most important modem on sbitx. It can also be used for js8call. However, I am not happy with the js8call user interface. It would be nice to have it appear like "facebook" or whatsapp as a single stream of threaded conversions. I have been looking at that code to see how we can slice and dice the ft8 library. Another problem is that we dont report the signal strength correctly. We just fake -10 db. Let us work on this in the next few days. - f

…

On Thu, Aug 4, 2022, 4:57 AM wb2osz ***@***.***> wrote: Here's the problem, in modems.c: The FT8 audio file is generated with: sprintf(cmd, "/home/pi/ft8_lib/gen_ft8 "%s" /tmp/ft_tx.wav %d", ... A little later, it is trying to read a different file which does not exist: pf = fopen("/home/pi/sbitx/ft8tx_float.raw", "r"); There is no check for NULL so the following fread dies. FIX PART 1: Check for failed fopen and produce an error message rather than crashing the application: - pf = fopen("/home/pi/sbitx/ft8tx_float.raw", "r"); - ft8_tx_nsamples = fread(ft8_tx_buff, sizeof(float), 180000, pf); - fclose(pf); - pf = fopen("/dev/shm/ft_tx.wav", "r"); - if (pf != NULL) { - ft8_tx_nsamples = fread(ft8_tx_buff, sizeof(float), 180000, pf); - fclose(pf); - } - else { - write_console(FONT_LOG_TX, "ERROR - Could not open ft8 tx audio file.\n"); - } FIX PART 2: Read the same file that gen_ft8 produces. Included in above. Closer but it's still not right. When transmitting, horrible noises come out of the speaker. Somewhat random yellow blocks go flashing in the upper right region. FIX PART 3: I threw another improvement in there. /tmp resides on the SD memory card. I used /dev/shm to hold the temporary file instead. This is a RAM disk so we are not beating on the SD memory card as much and shortening its lifespan. This would be even more important for /tmp/ftrx.raw. — Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFYXOGIW3SOITAIOZIRIA3VXL57XANCNFSM55PYQSJA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[wb2osz]

A modular architecture has advantages. Components can be tested separately or even replaced with a different implementation.

For example, I ran the ft8 audio file generator, without sbitx being involved, and examined the file it created. It creates a .wav format file with 16 bit integer samples. the modems.c code is written like it is expecting a file with floating point values. (It also did not use binary mode read.) I wrote a little function to read the .wav format file and produce an array of floating point values as expected by the code. It now transmits (something) but never returns to receive. This needs more work to switch back to receive.

Another problem we have is that the FT8 transmit audio file is a full 15 seconds. It should be less than 13 so we are back into receive mode in time to hear stations that start sending a second too early for their time slot. See https://github.com/wb2osz/technightradio/blob/master/poc/WSJT-X-Transmit-with-DDS.docx for my earlier research into this. the next step would be to find out why the audio file is too long. Hopefully it will just be extra silence appended to the end. That should be easy to fix.

[afarhan]

Got it! Here is my proposal: 1. Do away with using a separate process for the ft8 encode and decode. We move the entire library into our git, move and simplify the code of gen_ft8.c and decode_ft8.c. this eliminates the file open and close altogther, we can also move to 12 second slots. 2. The ft8 state machine is in ft8_interpret(). Do you think that is good to go? 3. When replying to someone's CQ should we transmit on their frequency? Right now, we do. - f

…

On Sat, Aug 6, 2022, 6:52 AM wb2osz ***@***.***> wrote: A modular architecture has advantages. Components can be tested separately or even replaced with a different implementation. For example, I ran the ft8 audio file generator, without sbitx being involved, and examined the file it created. It creates a .wav format file with 16 bit integer samples. the modems.c code is written like it is expecting a file with floating point values. (It also did not use binary mode read.) I wrote a little function to read the .wav format file and produce an array of floating point values as expected by the code. It now transmits (something) but never returns to receive. This needs more work to switch back to receive. Another problem we have is that the FT8 transmit audio file is a full 15 seconds. It should be less than 13 so we are back into receive mode in time to hear stations that start sending a second too early for their time slot. See https://github.com/wb2osz/technightradio/blob/master/poc/WSJT-X-Transmit-with-DDS.docx for my earlier research into this. the next step would be to find out why the audio file is too long. Hopefully it will just be extra silence appended to the end. That should be easy to fix. — Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFYXOHJXWAFBJHW5JQUSZ3VXW44RANCNFSM55PYQSJA> . You are receiving this because you commented.Message ID: ***@***.***>

[wb2osz]

(1,2) I don't know the code well enough yet to have an informed opinion.
(3) IMHO, responding on the same frequency is not the best approach. Imagine the mess if everyone who heard the CQ responded on the same frequency at the same time! More experienced FT8 operators taught me to watch the waterfall for a couple cycles and manually set the TX frequency to an unused spot. I was under the assumption that the red line was the FT8 transmit frequency.

[afarhan]

Understood, an update is coming up. Yes, the red line should be transmit freq. I changed it recently. I will revert back to the original. - f

…

On Sat, Aug 6, 2022, 7:21 PM wb2osz ***@***.***> wrote: (1,2) I don't know the code well enough yet to have an informed opinion. (3) IMHO, responding on the same frequency is not the best approach. Imagine the mess if everyone who heard the CQ responded on the same frequency at the same time! More experienced FT8 operators taught me to watch the waterfall for a couple cycles and manually set the TX frequency to an unused spot. I was under the assumption that the red line was the FT8 transmit frequency. — Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFYXOEBUN7DUCHYYJ4LYR3VXZUXBANCNFSM55PYQSJA> . You are receiving this because you commented.Message ID: ***@***.***>

[afarhan]

I have rewritten this entirely to directly use the ft8_lib. Do a git pull to get the latest build