FT8: answering (by clicking on) "CQ POTA xx" will send "POTA MYCALL MYGRID"

[ec1oud]

It looks like the software may be looking for word breaks in a full-text message, instead of getting specific fields from ft8_lib (the calling station in this case). (I didn't really try to figure out why just yet.)

Likewise I noticed a while back that if I want to repeat a message that I already sent, by clicking on it, I will end up calling myself, which no doubt looks quite silly to everyone.

[drexjj]

I am seeing something a little different with the macro on v4.4.. I set the macro to "CQ test mycallsign mygrid" and got this...

[ec1oud]

What's that you are showing a screenshot from? Some phone app that decodes from the microphone?

wsjt-x and ft8_lib both include ways of generating and decoding wav files. I was just testing with prefix/suffix callsigns (as discussed on the list: different issue than this one!) and it seems like it should work. So anyway, that's another way to see whether a particular message can be encoded.

$ cd path/to/wsjtx-source-folder (assuming you built it already)
$ ./ft8sim "CQ TEST LB2JK JO59" 1500.0 0.0  0.1 1.0   10   -18

      Decoded message: CQ TEST LB2JK JO59                      i3.n3: 1.0
f0: 1500.000   DT:  0.00   TxT:  12.6   SNR: -18.0  BW:50.0

          mycall                         hiscall                    hisgrid
0000000001100001010111111001 0 1001110010111110110010101011 0 0 100010011111011 001

Channel symbols:
3140652000406275614374436210574426343140652616465621621672273072171235633140652

   1   0.00 1500.00  -18.0  000000_000001.wav  -17.99
   2   0.00 1500.00  -18.0  000000_000002.wav  -18.02
   3   0.00 1500.00  -18.0  000000_000003.wav  -18.00
   4   0.00 1500.00  -18.0  000000_000004.wav  -18.01
   5   0.00 1500.00  -18.0  000000_000005.wav  -18.00
   6   0.00 1500.00  -18.0  000000_000006.wav  -17.99
   7   0.00 1500.00  -18.0  000000_000007.wav  -17.99
   8   0.00 1500.00  -18.0  000000_000008.wav  -17.99
   9   0.00 1500.00  -18.0  000000_000009.wav  -18.00
  10   0.00 1500.00  -18.0  000000_000010.wav  -17.99

Then I can decode that in the wsjtx gui by File | Open and picking one of those wav files. Surprisingly, it works. I would have thought that message is too long to fit.

Now with ft8_lib:

$ cd ../ft8_lib
$ ./decode_ft8 ../wsjt-wsjtx/000000_000001.wav
Sample rate 12000 Hz, 180000 samples, 15.000 seconds
Block size = 1920
Subblock size = 480
N_FFT = 3840
#############################################################################################
Max magnitude: -70.2 dB
num_candidates: 11
Decoded 0 messages, callsign hashtable size 0

$ ./gen_ft8 "CQ TEST LB2JK JO59" cq-test-square.wav
Packed data: 00 00 00 20 2d cb 53 1f ac c8
FSK tones: 3140652000000001003471235417465425223140652575276736100775002354020614103140652
$ ./decode_ft8 cq-test-square.wav
Sample rate 12000 Hz, 180000 samples, 15.000 seconds
Block size = 1920
Subblock size = 480
N_FFT = 3840
#############################################################################################
Max magnitude: -6.0 dB
num_candidates: 17
000000    22  0.8 1000 ~  CQ <...> +00
Decoded 1 messages, callsign hashtable size 0

So apparently it decided to hash my callsign because the message is too long. Doesn't really look like gen_ft8 encoded the whole message though; and wsjt-x won't decode that wav file that it generated. And I'm using the gdyuldin fork which AFAICT does have some good fixes for the non-standard callsigns. It seems to me the QSOs that I attempted today should have worked better than they actually did, from attempting more encode-decode comparisons between the tools like that.

[drexjj]

Interesting.. I will be completely honest with you. I do not have any interest in fixing or enhancing the built-in FT8 mode by fixing the external library. If someone else wants to take a crack at it, then I will incorporate it here and give them credit. We have other workarounds in place of which I am comfortable with.

[drexjj]

I was using FT8CN developed for Android.

[ffurano]

Uhm, it seems I can't reproduce this issue in the 'snr' branch (currently active, 29th of Sept, 2025). At least in the Web interface. Maybe it got fixed?

[ec1oud]

Cool if so; but I was using the GTK interface at the time.

After kgoba/ft8_lib@9fec6ca it's possible to update the sbitx/zbitx software to get the field types for ranges of text so that the front-end doesn't have to tokenize and understand the text on its own. I.e. when decoding a packet containing "CQ POTA M7KMM IO93", ftx_message_decode() can populate the ftx_message_offsets_t struct, which should tell you that the FTX_FIELD_CALL field begins at character 8. Some of my branches make use of this information already. Maybe some fixes got done in drexjj's branches. But lately I'm using my sbitxd branch (the daemon: no more GTK, because it's not useful on zbitx) and slowly working on client apps. (Whether I will want the GTK front-end again on sbitx depends how successful I am with writing a Qt client to replace it. Gotta have something nice on that touchscreen...)

[ffurano]

I think I agree with the shortcomings you found in the code. A more structured approach could also accommodate improvements for things that today are difficult to tackle, e.g. the callsign hashing

[drexjj]

resolved and added in dev