On 17/10/2014 20:25, Joe Taylor wrote: > Hi all, Hi Joe, > > 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. Oops, so my answer was partially incorrect and I should have suggested that as another alternative.
Also that particular example response you give is valid as a free text message. > > 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? Factoring out common code has been on my list for a while. I was planning to do some investigation after the 1.4 release and after I check in my current work on merging wsjtx and jt9. The later involves among other things giving the Fortran decoding code a C/C++ interface and it occurs to me that a Python interface might be valuable too, given the amount of Python code used in some of the WSJT projects. So common library implementation is closely related to merging wsjtx and jt9 as well. I would like to see any common libraries built with CMake, this is because CMake has powerful tools for exporting library code for use in other CMake built projects. This doesn't make them any less useful for non-CMake projects. For me the biggest issue after learning about internals of all the clients using any proposed common libraries is the repository layout. I am currently working on a git-svn configuration that can successfully map a conventional trunk/branches/tags layout onto our off kilter "trunk in branches" layout with some success but it is horribly complex and I'm not yet sure it works. This is important to me because I would not give up the huge advantages of using git-svn over raw svn. I suspect no one else is using git-svn so I may be out on a limb here :( > > -- Joe, K1JT 73 Bill G4WJS. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
