callsign with prefix #44
Comments
ec1oud
added a commit
to ec1oud/ft8_lib
that referenced
this issue
Oct 6, 2024
The code was there already, but ftx_message_encode_std() needs to fail, so that ftx_message_encode() will fall through and call ftx_message_encode_nonstd(). This is the same check as in packjt77.f90 line 1144: if(nwords.eq.2 .and. (.not.ok2 .or. index(w(2),'/').ge.2)) RETURN And test.c tests ftx_message_encode(); however, a lot of messages have the nonstandard callsign hashed then. Not sure if that's correct or if we should expect the test to expand the hashed callsigns. Might fix kgoba#44
ec1oud
added a commit
to ec1oud/ft8_lib
that referenced
this issue
Oct 6, 2024
The code was there already, but ftx_message_encode_std() needs to fail, so that ftx_message_encode() will fall through and call ftx_message_encode_nonstd(). This is the same check as in packjt77.f90 line 1144: if(nwords.eq.2 .and. (.not.ok2 .or. index(w(2),'/').ge.2)) RETURN And test.c tests ftx_message_encode(); however, a lot of messages have the nonstandard callsign hashed then. Not sure if that's correct or if we should expect the test to expand the hashed callsigns. Might fix kgoba#44
ec1oud
added a commit
to ec1oud/ft8_lib
that referenced
this issue
Oct 7, 2024
The code was there already, but ftx_message_encode_std() needs to fail, so that ftx_message_encode() will fall through and call ftx_message_encode_nonstd(). This is the same check as in packjt77.f90 line 1144: if(nwords.eq.2 .and. (.not.ok2 .or. index(w(2),'/').ge.2)) RETURN And test.c tests ftx_message_encode(); however, a lot of messages have the nonstandard callsign hashed then. Not sure if that's correct or if we should expect the test to expand the hashed callsigns. Might fix kgoba#44
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm American and operating in Norway under the CEPT agreement for now, so I need to use a prefix (my callsign is LA/K7IHZ). So far, something is wrong with the encoding. If I add my callsign to the list in test/test.c, the test fails:
Do the
<>brackets mean it's always hashed?Also, if I use gen_ft8 to encode a wav file with this callsign,
jt9 -8 file.wav(the tool that comes with wsjt-x) does not successfully decode it, whereas it can decode if the callsign has no prefix.When testing with ft8code (comes with wsjt-x), it seems like a plain CQ with my callsign but no grid will use the type 4 nonstandard call format, but in many other cases probably it's getting hashed and put into a type 1 standard message.
The text was updated successfully, but these errors were encountered: