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
