kgoba / ft8_lib

FT8 library
MIT License
211 stars 69 forks source link

Broken encoding for 'CQ VU3CER/P MK68' message #24

Closed kholia closed 1 year ago

kholia commented 2 years ago

The output of gen_ft8 is different from ft8code's output for CQ VU3CER/P MK68 message.

$ ./gen_ft8 "CQ VU3CER/P MK68" test.wav
Packed data: 2c 91 5b 12 cd cd 03 e1 be 00 
FSK tones: 3140652121106220565471600740474017503140652375257614567012355434063216343140652
$ ft8code "CQ VU3CER/P MK68"
    Message                               Decoded                             Err i3.n3
----------------------------------------------------------------------------------------------------
 1. CQ VU3CER/P MK68                      CQ VU3CER/P MK68                         2.  EU VHF Contest              

Source-encoded message, 77 bits: 
00000000000000000000000000100111000111110011011011011100110101100010001100010

14-bit CRC: 
01110010001000

83 Parity bits: 
01000000100011010000010001001100110000110011101100011011000011100010111000000110100

Channel symbols (79 tones):
  Sync               Data               Sync               Data               Sync
3140652 00000000114175444716205205710 3140652 51005230311540426522025370045 3140652
$ ./decode_ft8 test.wav 
Sample rate 12000 Hz, 180000 samples, 15.000 seconds
Block size = 1920
Subblock size = 960
N_FFT = 3840
Max magnitude: -6.0 dB
000000  34 +1.36 1000 ~  CQ VU3CER/P M
Decoded 1 messages
$ jt9 -8 test.wav
000000  85  0.7 1000 ~  CQ VU3CER/P M                           
<DecodeFinished>   0   1        0

It seems that gen_ft8 is generating bad output for CQ VU3CER/P MK68 message.

Thanks for the help in debugging this problem.

kholia commented 2 years ago

It seems CQ VU3CER/P MK68 is not a Standard msg in WSJT-X world. Overall, I think this ticket can be closed without further action.

kgoba commented 2 years ago

I checked the FT8 documentation and it seems that CQ [call]/P [grid] should be a valid message and can be encoded. What I see from my code is that the text message packing is still in very basic form, not supporting this. In this case the encoder interprets it as free-text message, which is wrong (and thus the truncated output at decoding). However, decoding should pick up messages with /P in callsign(s). We can keep this ticket open as a reminder.

kholia commented 2 years ago

https://github.com/rtmrtmrtmrtm/weakmon/blob/d3e202a3fbd7b9ab6a9f7addfdffdaf87a52ec7f/ft8.py#L4540

It seems weakmon doesn't support /P in callsign as well.

kholia commented 2 years ago

Another message for which the encoding seems broken:

$ ft8code "CQ POTA VU3CER ML76"
    Message                               Decoded                             Err i3.n3
----------------------------------------------------------------------------------------------------
 1. CQ POTA VU3CER ML76                   CQ POTA VU3CER ML76                      1.  Standard msg                

Source-encoded message, 77 bits: 
00000000010011111110111011110111000111110011011011011100100101100011111000001

14-bit CRC: 
00101101110000

83 Parity bits: 
00000101001011010110001111101011110101100100100010010110111101100110010100010000000

Channel symbols (79 tones):
  Sync               Data               Sync               Data               Sync
3140652 00057764764175444711207403347 3140652 00061234176246555334765435300 3140652
kholia commented 1 year ago

The CQ VU3CER/P MK68 encoding problem is fixed in https://github.com/kgoba/ft8_lib/tree/update_to_0_2 branch.

So I am closing this issue.