Hi all,
Bill responded to a recent query on wsjtgroup about the use of compound
callsigns.
As we all know, these are bit of a nuisance in JT65, JT9, and JT4, in
part because of the need to maintain backward compatibility with the
original JT65 protocol specification, defined more than ten years ago.
The original question posed by KE4PT was this:
> Suppose I am operating as ZL/KE4PT.
> Suppose I hear: CQ N8PR EL96 calling and SNR = -20
>
> I wish to "generate message", and expect to find the generated message:
> N8PR ZL/KE4PT
> in the "Grid" button, or the "TX2" message, but instead WSJT-X 1.4 generates:
> N8PR KE4PT -20
> thus N8PR never knows that ZL/KE4PT answered his CQ.
Of course, a savvy user would edit the automatically generated message
so that "N8PR ZL/KE4PT" is sent. That's a legal message, because "ZL"
is one of the 339 "standard" prefixes defined in pfx.f90. They are
legitimate for the compound-callsign messages we call "Type 1" in the
WSJT-X User Guide.
However, suppose the authorities in ZL required him to sign his call as
ZL3/KE4PT. ZL3 is not in the list of standard prefixes, so he must use
Type 2 messages. The automatic message-generating facility in WSJT-X
assumes that Type 2 messages will be used.
In fact we could do slightly better for users. The program could
generate Type 1 messages when possible, and Type 2 otherwise. I would
see about making such a change... but it occurs to me that now might be
the right time to do something that we have been putting off.
For consistency it would be better, by far, to put all the pack/unpack
routines (and a few support routines) in a separate library of their
own. That library should be used by our Qt-based programs (WSJT-X and
MAP65) and also by the Python-based WSJT -- in short, by any program
that uses the 72-bit compressed messages pioneered by JT65.
I would be happy to hear opinions from others about how best to organize
the code for such a separate library. I suppose it should be something
like making a new SVN branch, say "packmsg", for the pack/unpack source
code, and having the relevant build scripts go there to build the
library. Does this sound right?
-- 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
