Hi Hansi,
Sorry to be slow in getting back to your earlier message. I have been
meaning to look into the JT65v1/JT65v2 encoding issue, but it has not
yet reached the top of my "To Do" list. It seems that you have already
solved the problem, and in just the way that I was intending to do it --
so I am very grateful for your message.
Yes, by all means send me your modified code. I will put it into the
SVN repository.
-- 73, Joe, K1JT
On 1/17/2014 4:49 PM, Hansi Reiser wrote:
Hi Joe,
in a previous message I mentioned some strange behaviour
regarding callsigns with prefixes in wsjtx. I did not
get any feedback so far on this issue, so I had a brief
look at it myself after stumbling on the problem again
yesterday in a QSO with EA8/RW3DO.
Seems like wsjtx *always* uses JT65v2 encoding for prefixes,
which works fine for "CQ pfx/call" (and QRZ/DE ...), but
not in other situations ("pfx/call1 call2", "call1 pfx/call2",
"pfx/call1 73"). A straigtforward fix seems to be to use v1
encoding in these sitations if pfx is v1-encodable and
text encoding otherwise.
Now I do not know if there are any specific reasons for why
things are done the way they are at the moment. A simple
fix for the observed problem would be removing the
"Always use JT65v2" line from getpfx1.f90 and choosing
text encoding if the getpfx1 call in packmsg.f90 returns
a nonzero value in junk. I can send you or post here a full
diff of these suggested changes, which seem to work fine for
me so far (but it implies using v1 encoding even for those
sitationes that have both a v1 and v2 encodign...).
73, Hansi, dl9rdz
_______________________________________________
Wsjt-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/wsjt-devel
_______________________________________________
Wsjt-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/wsjt-devel
