Re: R1CBU / R2RFE - FT8 issue with prefixed callsign
|
After a deeper analysis of the issue, I¡¯ve come to the conclusion that with ft8_lib, smaller or larger problems with encoding/decoding a callsign may occur whenever a QSO involves callsigns longer than 6 characters. In such cases, ft8_lib employs various data compression strategies to fit the information into the FT8 frame.
?
While investigating the issue, I noticed that even WSJT-X is unable to properly encode a callsign like SV9/SP9HGN/P - it truncates part of the callsign, which results in an incomplete frame being transmitted over the air. In my case, it was: ¡°CQ SV9/SP9HGN/¡± - missing the final "P":
?
As part of my proposed solution, I implemented two things:
- I added logic to detect the use of a callsign with a country prefix (e.g., SV9/SP9HGN). In such cases, whether in CQ or in a response to someone¡¯s call, the application will skip appending the grid locator to save precious data bits.
- I added a warning that appears when a callsign longer than 6 characters is set. For callsigns longer than 6 characters (e.g., HF100IARU), the application will be forced to use hashes in QSO, which may also be problematic (see:
Pull request:
I think, @Georgy, that would be good to cover such scenario with unit tests - I see your tests in repo, but I had some issues with executing them locally. I know it's rude to left someone with unit tests implementation, but if you'd have some free time, please, take a look on my changes and help me with writing units for them :)
Generally speaking, encoding long callsigns - especially those with prefixes or suffixes - in FT8 is a far more complex issue than I initially thought. To be on the safe side, a good practice is not to go overboard and stick to callsigns that do not exceed 6 characters.
Cheers!
73 de Jarek SP9HGN
?
|
