Closed kholia closed 1 year 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.
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.
https://github.com/rtmrtmrtmrtm/weakmon/blob/d3e202a3fbd7b9ab6a9f7addfdffdaf87a52ec7f/ft8.py#L4540
It seems weakmon doesn't support /P
in callsign as well.
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
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.
The output of gen_ft8 is different from ft8code's output for
CQ VU3CER/P MK68
message.It seems that gen_ft8 is generating bad output for
CQ VU3CER/P MK68
message.Thanks for the help in debugging this problem.