Hi all, Over the weekend I made some changes to the way WSJT-X generates suggested user messages when a compound callsign is involved. I also made a minor change in the way the encoder decides when to use the free-text format in a message. These changes are intended to make compound callsigns more convenient, when needed.
The original specification of the JT65 protocol included a list of 339 DXCC prefixes, supposedly the most commonly used ones, plus 12 common single-character suffixes. As described in Section 7.3 of the WSJT-X User Guide, they can be used to make "Type 1" compound callsigns. Other arbitrary prefixes (up to 4 characters) and suffixes (up to 3 characters) may be used in "Type 2" compound callsigns, with different restrictions in usage. WSJT-X generates suggested messages automatically when the user clicks "Generate Std Msgs" on Tab 1 or one of the six buttons on Tab 2. Here's a brief summary of what messages are affected by compound-callsign usage. 1. When "MyCall" is a Type 1 compound callsign, messages 1 and 6 contain the compound callsign as the second word. Examples: K1ABC ZL/W9XYZ (Tx1, also "Grid" button on Tab 2) CQ ZL/W9XYZ (Tx6, also "CQ" button on Tab 2) All other messages use the base callsigns only (no prefix/suffix). 2. When "MyCall" is a Type 2 compound callsign, messages 2, 5, and 6 contain the compound callsign as the second word. Examples: DE W9XYZ/VE1 (Tx2) DE W9XYZ/VE1 73 (Tx5, also "73" on Tab 2) CQ W9XYZ/VE1 FN75 (Tx6, also "CQ" on Tab 2) Message numbers 1 ("Grid" on Tab 2), 3 ("R+dB") , and 4 ("RRR") use the base callsigns only. 3. When "HisCall" is a Type 1 compound callsign, message 1 uses it as the first word. Example: ZL/K1ABC W9XYZ (Tx1, also "Grid" on Tab 2) All other messages use the base callsigns only. 4. When "HisCall" is a Type 1 compound callsign, message 5 uses it as the first word. Example: K1ABC/VE1 73 (Tx5, also "73" on Tab 2) All other messages use the base callsigns only. [In the rare case where both MyCall and HisCall are compound, automatic message generation is not very useful. Operators will need to edit messages manually, to be sure they will both know the full callsign of the station being worked.] What happens if a user tries to send a message similar to the one in item #3 above, but with a prefix or suffix NOT in the short list? For example, suppose the message is "XL/K1ABC W9XYZ". Since "XL" is not in the short list, "XL/K1ABC" is a Type 2 compound callsign. But the first word in a message with a Type 2 compound callsigns must be CQ, QRZ, or DE. Since the attempted message fails to satisfy either Type 1 or Type 2 criteria, subroutine packmsg() encodes the first 13 characters as free text and sends "XL/K1ABC W9XY". This procedure may be useful for those with short callsigns. These changes were made in the development branch, .../branches/wsjtx. Should they be merged back into wsjtx-1.4? This is a policy question, and I'm not sure or the proper answer. The changes don't exactly fix a bug in v1.4-rc2; rather, they correct a perceived flaw in the way that version chose to generate messages automatically. Your views on this matter would be welcome. I would also appreciate any comments on whether you think the new code makes the best possible compromises for handling compound callsigns. -- 73. Joe, K1JT ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel