Hello All,
On 10/17/2014 02:05 PM, Bill Somerville wrote:
> 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.
Unless you plan on coveting WSJT and / or WSPR over to Cmake, I
wouldn’t' want to deal with this at all, WSPR may not factor in, but
still. The builds for those two packages are already hybrids, adding a
third layer would compound things further. I'm sure there is a long list
of reasons why X is better that Y, but, seems to me, there are plenty of
fish to fry, so no urgent need to go throw a line in the water :-)
I would think, fixing MAP65 and WSPR-X, the other two CMake projects,
would be higher in priority rather than adding complexity to the
non-Cmake projects, maybe they need to move in parallel, I don't know.
I certainly see the benefits of having a common library set, but if
that's to be done, do them all, not just one or two for a particular
need. Clearly a roadmap of some kind could be beneficial here, maybe
include long term integration plans for all the apps, if that is on the
cards.
A few months back, 6+ or so, I tried to do some commonality checks
between the different .F90 / .f90 files. I found allot of delta's, but I
had no way of knowing which file was truth, so, kinda of gave up on that
adventure. I think this would be benifical for sure, but do them all,
and publish the libs.
> 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 :(
I have philosophical issues with Git, it's origin, and current
implementation, so I don't use it full stop. I suppose that's not 100%
true, I do preform check-out's, pull's or whatever the terms are called,
but only when I have no other choice. Sorta like going to the petrol
station, if all they sell is 85 octane, not much choice, but if there is
a choice, run the other direction.
-- 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
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
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
