Re: [wsjt-devel] Interesting feature. Bug can be reproduced

[Saku]

It might be so.
But testing a program is to find all possible odd cases users may create 
(you'll never complete that !) and find fixes for them.


This case upcase shift should be done just before message is prepared 
for transmit, always.
Or prevent typing with low case to edit boxes (run upcase shift every 
time content changes in edit box).

I do not know QT, but Lazarus has event for this.

Seasons greetings to all!

--
Saku
OH1KH


WB5JJJ kirjoitti 23.12.2018 klo 22.23:
All you need to do is to TAB or CLICK ANYWHERE outside the TX6 dialog 
box and they will change to Upper Case during the Enable Tx cycle.  
The same thing happens if you enter lower case in the DX Call or DX 
Grid boxes.  However, Tx5 does automatically take lower case 
keystrokes and enter as upper case.


On Sun, Dec 23, 2018 at 2:04 PM Saku > wrote:


Tested this again with rigctld -r 1  (dummy)



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug when responding to K3ZK CQ

[tmp1]

Thanks for the feedback Bill !

I appreciate it.

 

73

Phil, F5FDV

 

Envoyé: dimanche 23 décembre 2018 à 19:04
De: "Bill Somerville" 
À: wsjt-devel@lists.sourceforge.net
Objet: Re: [wsjt-devel] Bug when responding to K3ZK CQ

On 23/12/2018 16:16, t...@gmx.fr wrote:
> Something strange happened when I tried reply to a K3ZK's CQ.
> As usual, I double clicked on the CQ messsage to set up the QSO
> information.
> In the "Gen msg" window the sequence  ZS1/F5FDV appeared as
> expected but, when I turned "Enable Tx" on, the sequence 
> ZS1/F5FDV appeared in the "Rx Frequency" window.
> I turned "Enable Tx" off and on again with the same result.
> So I gave up and after several QSOs with other OMs that went well, I
> responded again to another CQ of K3ZK. The same issue happened again.

Hi Phil,

this is a known issue with WSJT-X v2.0.0, it is related to the use of
hash codes to represent callsigns in messages when making QSOs with
stations with complex callsigns like yours. The phenomenon is due to a
hash code collision where two of more callsigns map to the same hash
code, in this case K3ZK and NQ6C. The correct message is being
transmitted but the print of it at your end is inserting the wring
callsign, one that was inserted into the hash table from some previous
message. You may have been able to proceeded with the QSO, taking care
to check that the correct callsign is logged.

A fix for this issue is being worked on for the next release. You do
have a workaround, by closing down WSJT-X and restarting you will clear
the hash table and messages should print correctly, at least until
another hash collision occurs.

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




 

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] bug in 77-bit message packing

[Bill Somerville]

On 24/12/2018 02:34, Bill Somerville wrote:

The change is attached as a diff for your review.


Hi Igor,

that patch has a defect, the attached needs to be applied as well to fix 
that.


73
Bill
G4WJS.

commit de9990bb60f3cefcefa5a994ade9fa60d3a1d2a4
Author: Bill Somerville 
Date:   Mon Dec 24 03:52:06 2018 +

Fix a mangled edit and an incorrect exit condition

diff --git a/lib/77bit/packjt77.f90 b/lib/77bit/packjt77.f90
index 818ad6366..1ee37f5c1 100644
--- a/lib/77bit/packjt77.f90
+++ b/lib/77bit/packjt77.f90
@@ -816,14 +816,18 @@ subroutine pack77_02(nwords,w,i3,n3,c77)
   if(nwords.ge.2) read(w(nwords-1),*,err=2) nx
 2 if(nx.lt.520001 .or. nx.gt.594095) return  !Exchange between 520001 - 
594095
   if(.not.is_grid6(w(nwords)(1:6))) return   !Last word must be a valid 
grid6
-  i=index(w(1)//' ','/P ')
-  if(i.lt.4) return !Only exactly a trailing /P allowed
 
 ! Type 0.2:   PA3XYZ/P R 590003 IO91NP   28 1 1 3 12 25   70   EU VHF 
contest
   i3=0
-  n3=21
-  ip=1
-  c13=w(1)(1:i-1)
+  n3=2
+  i=index(w(1)//' ','/P ')
+  if(i.ge.4) then
+ ip=1
+ c13=w(1)(1:i-1)
+  else
+ ip=0
+ c13=w(1)
+  end if
   call pack28(c13,n28a)
   ir=0
   if(w(2)(1:2).eq.'R ') ir=1
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] bug in 77-bit message packing

[Bill Somerville]

On 22/12/2018 18:45, Joe Taylor wrote:

i3.n3 Err Message to be encoded Decoded message
 


 1.   *   DU6/VA3AAA K9ABC RRR  VA3AAA K9ABC RRR
 2.   *   DU6/PA3AAA K9ABC RRR  PA3AAA/P K9ABC RRR
 1.    K9ABC RRR  K9ABC RRR
 2.    K9ABC RRR  K9ABC RRR


Hi Igor,

further to Joe's comments above the last line I have quited is a defect 
although the message will be encoded and decoded without issue. We will 
make changes to ensure this message and ones like it are encoded with 
i3==1 as it should be. The change is attached as a diff for your review.


Thanks for catching this subtle issue.

73
Bill
G4WJS.


commit e4700b449e694be01017cb7f7686990063607f1d
Author: Bill Somerville 
Date:   Mon Dec 24 02:22:39 2018 +

Make checks for /P and /R exact and only for trailing suffixes

diff --git a/lib/77bit/packjt77.f90 b/lib/77bit/packjt77.f90
index 7dd541a13..958c4af09 100644
--- a/lib/77bit/packjt77.f90
+++ b/lib/77bit/packjt77.f90
@@ -816,17 +816,14 @@ subroutine pack77_02(nwords,w,i3,n3,c77)
   if(nwords.ge.2) read(w(nwords-1),*,err=2) nx
 2 if(nx.lt.520001 .or. nx.gt.594095) return  !Exchange between 520001 - 
594095
   if(.not.is_grid6(w(nwords)(1:6))) return   !Last word must be a valid 
grid6
+  i=index(w(1)//' ','/P ')
+  if(i.lt.4) return !Only exactly a trailing /P allowed
 
 ! Type 0.2:   PA3XYZ/P R 590003 IO91NP   28 1 1 3 12 25   70   EU VHF 
contest
   i3=0
-  n3=2
-  ip=0
-  c13=w(1)
-  i=index(w(1),'/P')
-  if(i.ge.4) then
- ip=1
- c13=w(1)(1:i-1)//' '
-  endif
+  n3=21
+  ip=1
+  c13=w(1)(1:i-1)
   call pack28(c13,n28a)
   ir=0
   if(w(2)(1:2).eq.'R ') ir=1
@@ -967,11 +964,13 @@ subroutine pack77_1(nwords,w,i3,n3,c77)
 ! 1 WA9XYZ/R KA1ABC/R R FN42   28 1 28 1 1 15   74   Standard msg
 ! 2 PA3XYZ/P GM4ABC/P R JO22   28 1 28 1 1 15   74   EU VHF 
contest  
 
-10 if(nwords.eq.2 .or. nwords.eq.3 .or. (nwords.eq.4 .and.   &
-w(3)(1:2).eq.'R ')) then
+10 i1psuffix=index(w(1)//' ' ,'/P ')
+  i2psuffix=index(w(2)//' ','/P ')
+  if(nwords.eq.2 .or. nwords.eq.3 .or. (nwords.eq.4 .and.   &
+   w(3)(1:2).eq.'R ')) then
  n3=0
  i3=1  !Type 1: Standard message, possibly with 
"/R"
- if(index(w(1),'/P').ge.4 .or. index(w(2),'/P').ge.4) i3=2  !Type 2, with 
"/P"
+ if (i1psuffix.ge.4.or.i2psuffix.ge.4) i3=2 !Type 2, with "/P"
   endif
   c13=bcall_1//'   '
   if(c13(1:3).eq.'CQ_' .or. w(1)(1:1).eq.'<') c13=w(1)
@@ -981,8 +980,8 @@ subroutine pack77_1(nwords,w,i3,n3,c77)
   call pack28(c13,n28b)
   ipa=0
   ipb=0
-  if(index(w(1),'/P').ge.4 .or. index(w(1),'/R').ge.4) ipa=1
-  if(index(w(2),'/P').ge.4 .or. index(w(2),'/R').ge.4) ipb=1
+  if(i1psuffix.ge.4.or.index(w(1)//' ','/R ').ge.4) ipa=1
+  if(i2psuffix.ge.4.or.index(w(2)//' ','/R ').ge.4) ipb=1
   
   grid4=w(nwords)(1:4)
   if(is_grid4(grid4)) then
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Mobile operation

[Chris Knox]

Is there a way to have the program automatically update your grid square based 
on input from a GPS?  Second can I use a GPS for the clock updates?
I am thinking of operating in many grid squares throughout my travels
Chris
KI1P

Get Outlook for iOS
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Interesting feature. Bug can be reproduced

[WB5JJJ]

All you need to do is to TAB or CLICK ANYWHERE outside the TX6 dialog box
and they will change to Upper Case during the Enable Tx cycle.  The same
thing happens if you enter lower case in the DX Call or DX Grid boxes.
However, Tx5 does automatically take lower case keystrokes and enter as
upper case.

On Sun, Dec 23, 2018 at 2:04 PM Saku  wrote:

> Tested this again with rigctld -r 1  (dummy)
>
> 1)   Start wsjt-x
> 2)   Place cursor to TX6 edit box between CQ and YOURCALL
> 3)   Write 2 letters with low case (e.x.  na)
> 4)   Enable TX
> 5)   When TX fires, letters will change to upcase (ex. NA). That is ok.
> 6)   During TX period, or during following RX period wipe letters away
> (ex. NA) replace with 2 low case letters (ex. oc). Keep TX enabled.
> 7)   Next TX period will transmit those letters and cq in angle brackets
> and space replaced with _   (ex. )
> 8)   During TX period, or during following RX period wipe letters away
> (ex. oc) replace with 2 upcase letters (ex. EU)
> 9)   Next TX period will send CQ EU in upcase. That is ok.
> 10) During TX period, or during following RX period wipe letters away (ex.
> EU) replace with 2 low case letters (ex. af)
> 11) Next TX period will transmit first used low case letters and cq in
> angle brackets and space replaced with _   (ex. ) again.
>
> Repeat this what ever low case letters you like. Result is always the
> first low case letters pair you used in CQ.
> Stop wsjt-x.
> On next start it does not remember them any more, but this can be
> reproduced. It will remember the first low case letter pair you now use.
> Until the end of program run.
>
>
> Conclusion:
>
>  Converting to upcase works only in first time (TX enabled pressed). If TX
> is kept enabled all the time while editing TX6 upcase conversion does not
> happen again.
> With low case letters it generates some kind of CQ hash code (?) that it
> will remember until the end of program.
>
>
> --
> Saku
> OH1KH
>
>
> Saku kirjoitti 23.12.2018 klo 16.10:
>
>
> While keeping cursor at TX6 box (before my call) I did change directed cq
> between JA and AS.
> All went ok if I had CAPS on (shift pressed).
>
> Few times I missed shift and wrote "ja" instead of "JA". Results can be
> seen below.
> Typing "as" or "AS" did not make any difference.
>
> When I started to test this I did not get it happen any more () May be
> related to time of period when this "ja" is typed (?)
> Or otherwise full TX period must be waited before new change.
>
> If stopping TX and try to change "ja" and "JA"  and restart TX it does not
> make any difference.
> That was the way I tried to quick test it more.
>
>
> v2.0.0 (x64.rpm)  Fedora 28
>
> --
> Saku
> OH1KH
>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Interesting feature. Bug can be reproduced

[Saku]

Tested this again with rigctld -r 1 (dummy)

1)   Start wsjt-x
2)   Place cursor to TX6 edit box between CQ and YOURCALL
3)   Write 2 letters with low case (e.x.  na)
4)   Enable TX
5)   When TX fires, letters will change to upcase (ex. NA). That is ok.
6)   During TX period, or during following RX period wipe letters away 
(ex. NA) replace with 2 low case letters (ex. oc). Keep TX enabled.
7)   Next TX period will transmit those letters and cq in angle brackets 
and space replaced with _   (ex. )
8)   During TX period, or during following RX period wipe letters away 
(ex. oc) replace with 2 upcase letters (ex. EU)

9)   Next TX period will send CQ EU in upcase. That is ok.
10) During TX period, or during following RX period wipe letters away 
(ex. EU) replace with 2 low case letters (ex. af)
11) Next TX period will transmit first used low case letters and cq in 
angle brackets and space replaced with _   (ex. ) again.


Repeat this what ever low case letters you like. Result is always the 
first low case letters pair you used in CQ.

Stop wsjt-x.
On next start it does not remember them any more, but this can be 
reproduced. It will remember the first low case letter pair you now use. 
Until the end of program run.



Conclusion:

 Converting to upcase works only in first time (TX enabled pressed). If 
TX is kept enabled all the time while editing TX6 upcase conversion does 
not happen again.
With low case letters it generates some kind of CQ hash code (?) that it 
will remember until the end of program.



--
Saku
OH1KH


Saku kirjoitti 23.12.2018 klo 16.10:



While keeping cursor at TX6 box (before my call) I did change directed 
cq between JA and AS.

All went ok if I had CAPS on (shift pressed).

Few times I missed shift and wrote "ja" instead of "JA". Results can 
be seen below.

Typing "as" or "AS" did not make any difference.

When I started to test this I did not get it happen any more () 
May be related to time of period when this "ja" is typed (?)

Or otherwise full TX period must be waited before new change.

If stopping TX and try to change "ja" and "JA"  and restart TX it does 
not make any difference.

That was the way I tried to quick test it more.


v2.0.0 (x64.rpm)  Fedora 28

--
Saku
OH1KH


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjt-devel Digest, Vol 58, Issue 306

[Rick]

Good afternoon all,

A rather simplistic solution might be to have your location (by 
callsign) identified in the city.dat file as "CHECK THE GRID". This 
would work for anyone that is roving (whether in the local geographical 
area, or across the Pacific).


73,

Rick

NM3G


... It was funny -- I recently worked someone on 160 who told me that he "soiled his 
adult diaper when he heard my AH6 call sign."? That pretty well sums up the call 
issue.




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] grid square & nonstandard callsign

[DX Jami via wsjt-devel]

Jim,
Our calls are valid anywhere worldwide ... but I understand your point.
Respectfully - a K9 or any standard CONUS amateur call is rather vanilla.  
Probably wisely so, the FCC does not require "call by call area" any longer as 
you well know.  With our mobile society ... we all have heard a hog-podge of 
calls not matching actual locations.  On the east coast, it seems like half of 
the New England ham population now lives in Florida ... and I am sure things 
are similar elsewhere.  

There is little need for most US "vanilla" stations to accurately ID exact call 
area or location - grid; maybe a different situation.  The ARRL DXCC - USA is 
not a greatly sought after, rare DX entity.  Hawaii, Alaska, Guam, Puerto Rico 
to an extent, etc are somewhat different.  They may not be rare ... but they 
are sought after by some for various reasons.  It was funny -- I recently 
worked someone on 160 who told me that he "soiled his adult diaper when he 
heard my AH6 call sign."  That pretty well sums up the call issue.
The situation is much different when working DX.  For me, it is almost a "must" 
to accurately ID call and location ... which is easily done by using a 
non-standard compound call sign.  You would be surprised at some of the hate 
FT8 anonymous comments I sometimes receive because of my call.  It is easy of 
course to track down these folks by tracking the nasty response frequency back 
to a previous transmission when the station used a call sign.  

So respectfully Jim - no ... operating K9 from K6-land is not like operating 
AH6 from W4-land.

In case you did not see my latest response to Bill and others ... here is an 
extract of my most recent email / posting related to that issue.
But in closing -- checked out your QRZ page ... used to listen to WLW - a 
landmark station on AM ... and visited the R.L. Drake factory shortly after the 
tornado wiped out Xenia several years ago.  My first really good SW receiver 
was the Drake SW-4 - fantastic.  Now the extract.
    Best Regards,    Danny    W4/AH6FX

On SSB and RTTY I always sign asAH6FX/W4 to control expectations.  When using 
versions 1.8.* and 1.9.* I signW4/AH6FX on FT8 to, again, control expectations 
– people seem to recognize theW4/ first and recognize my locations.  
Butexpectations are sometimes hard to control as you can imagine.  I do notwant 
anyone thinking they are working Hawaii when I am in northern Virginia. 
Although the FCC does not requireUS stations to sign /[slash] portable, etc … 
the FCC does not prohibit us from doing so.  I use an “adapted”call sign 
protocol specified in CFR Part 97.  Say I was a Canadianstation operating in 
Virginia … FCC says that station should sign as, forexample, VE1ABC/W4 
Nokesville.  I have never heard a foreignstation include the nearest town, as 
required by the FCC, but I certainlyhave heard them properly sign VE1ABC/W4 or 
whatever.  That is the problemI often have, and stubborn me - I am adapting the 
FCC guidance to my situation. Although I am not a foreign station operating in 
the USA, tomany hams I am DXCC-Hawaii when in fact I am DXCC-USA … Virginia to 
be exact. My adaption of the /W4 or W4/ is my attempt to inform folks in am 
inW4-land.  ...

On Friday, December 21, 2018 2:07 PM, Jim Brown 
 wrote:
 

 On 12/21/2018 8:44 AM, DX Jami via wsjt-devel wrote:
> nonstandard call signs such as mine - W4/AH6FX ... or AH6FX/W4

Hi Danny,

US callsigns, with no / identifiers, are valid anywhere in the US. While 
using one is legal, it is completely un-necessary. Your call is AH6FX 
anywhere in the US, and I view it as a nuisance. I live in California, 
and my call is K9YC anywhere in the US.

The only time that you or I have a good reason to sign /anything would 
be if we were operating in a contest from a different DXCC entity than 
our prefix implied.

73, Jim K9YC



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


   ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] grid square & nonstandard callsign

[DX Jami via wsjt-devel]

Roger - understand Gary.  But what are the other viable work-arounds or fixes.  
After all, not a big issue with versions 1.8.* and 1.9.*?

    Danny    W4/AH6FX


On Friday, December 21, 2018 2:05 PM, Gary McDuffie  
wrote:
 
> On Dec 21, 2018, at 09:44, DX Jami via wsjt-devel 
>  wrote:
> 
> can extra bits be obtained by omitting the worked station's call sign?

This can really cause problems when trying to confirm that the report is from 
the station you think it is from.  The idea is to make sure you don’t get a 
bogus report.  This is especially important when working MSK144 as often there 
are several stations o the same frequency at the same time.  Integrity of the 
exchange comes into question when you leave the “from” field out of the report.

Gary - AG0N

   ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] grid square & nonstandard callsign

[DX Jami via wsjt-devel]

Bill & Others, Thanks very much for yourresponses.  Too bad AD1C’s CTY.DAT 
fixwill not work since I go back and forth to Hawaii.  Shucks – nothing is 
simple these days.  Please keep in mind I am not the only personwith this 
problem.  Just wait until theDXpedition and DX-vacation season picks up after 
the holidays. The /W4 option as suggested is not good for manyreasons – the 
ones in my previous email/forum posting ... and these below whichsum up the 
overall issue. I am one of those guys who just cannot give up his Hawaiian call 
sign which I have had for over 35 of my 40years as a ham.  Many people believe 
I amoperating from Hawaii when I call CQ because "Hawaii" shows up in theDXCC 
column of the Band Activity screen, despite my FM18 set-up entry[pre-version 2 
situation mostly].  Version 2 corrects some of this problembut the new version 
2 presents new problems as defined in my initial message afew days ago – 
W4/AH6FX compound call not showing grid ... or AH6FX indicatingHawaii to some 
despite FM18 grid.  This problem not in versions 1.8.* and 1.9.*.
 If it was not for the ARRL DXCCentity list, everything would be ok; but Hawaii 
and USA are separate DXCCentities ... unlike FCC's view of all call signs being 
USA. [Having said that,an inordinate number of foreign hams think I am in 
Hawaii regardless ... althosometimes I am.]  I prefer to follow the “DXCC-ARRL 
‘inferred” CFR Part 97guidance and sign my call W4/AH6FX [like a foreign 
station ... or in this case,a non-USA DXCC entity station {{AH6FX}} operating 
as a USA DXCC entity {{/W4}}]to illustrate operating from W4-land and not 
Hawaii.  With the new version 2, MANY people believe Iam in Hawaii because they 
do not see my FM18 grid ... not that everybody looksfor that stuff.  Also many 
folks seem notto have the “Show DXCC entity and worked before ...” box checked 
and do not seemy operating entity. On SSB and RTTY I always sign asAH6FX/W4 to 
control expectations.  When using versions 1.8.* and 1.9.* I signW4/AH6FX on 
FT8 to, again, control expectations – people seem to recognize theW4/ first and 
recognize my locations.  Butexpectations are sometimes hard to control as you 
can imagine.  I do notwant anyone thinking they are working Hawaii when I am in 
northern Virginia. Although the FCC does not requireUS stations to sign 
/[slash] portable, etc … the FCC does not prohibit us from doing so.  I use an 
“adapted”call sign protocol specified in CFR Part 97.  Say I was a 
Canadianstation operating in Virginia … FCC says that station should sign as, 
forexample, VE1ABC/W4 Nokesville.  I have never heard a foreignstation include 
the nearest town, as required by the FCC, but I certainlyhave heard them 
properly sign VE1ABC/W4 or whatever.  That is the problemI often have, and 
stubborn me - I am adapting the FCC guidance to my situation. Although I am not 
a foreign station operating in the USA, tomany hams I am DXCC-Hawaii when in 
fact I am DXCC-USA … Virginia to be exact. My adaption of the /W4 or W4/ is my 
attempt to inform folks in am inW4-land.   It would be unwise for me to say 
theW4/AH6FX - thing is perhaps a “receiving ham’s” problem of not 
payingattention to detail.  I believe I have a major roll in properly 
IDingstation and location.  So I occasionally send littlereminders like “Aloha 
fm VA” from the TX5 “free play” line. Then I still get emails from stations 
wanting me to QSL Hawaii, etc., etc. I will say I can change my callsign … but 
I return to Hawaii several times each year.  Thank goodness JT Alert helps sort 
out theCONUS station locations, but not everyone uses JT Alert.  Sooo … back to 
my originalquestion - how can I show my compound call sign W4/AH6FX or AH6FX/W4 
in FM18? Thanks and Season’s Greetings to Youand Yours, Danny 
W4/AH6FX– Nokesville, Virginia, USA 

On Friday, December 21, 2018 12:30 PM, Bill Somerville 
 wrote:
 

 On 21/12/2018 16:57, Bill Somerville wrote:
> I am not fully up to date on FCC regulations but I believe you don't 
> need to sign /W4 with your call. 

Hi Danny,

having read your bio on QRZ.COM I do see that my suggestion may not be 
such a good idea with Jim, AD1C's, CTY.DAT database as you do operate 
from Hawaii occasionally, nevertheless sending a grid without the /W4 
suffix may still be the best option if it is legal to do so.

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


   ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug when responding to K3ZK CQ

[Bill Somerville]

On 23/12/2018 16:16, t...@gmx.fr wrote:

Something strange happened when I tried reply to a K3ZK's CQ.
As usual, I double clicked on the CQ messsage to set up the QSO 
information.
In the "Gen msg" window the sequence  ZS1/F5FDV appeared as 
expected but, when I turned "Enable Tx" on, the sequence  
ZS1/F5FDV appeared in the "Rx Frequency" window.

I turned "Enable Tx" off and on again with the same result.
So I gave up and after several QSOs with other OMs that went well, I 
responded again to another CQ of K3ZK. The same issue happened again.


Hi Phil,

this is a known issue with WSJT-X v2.0.0, it is related to the use of 
hash codes to represent callsigns in messages when making QSOs with 
stations with complex callsigns like yours. The phenomenon is due to a 
hash code collision where two of more callsigns map to the same hash 
code, in this case K3ZK and NQ6C. The correct message is being 
transmitted but the print of it at your end is inserting the wring 
callsign, one that was inserted into the hash table from some previous 
message. You may have been able to proceeded with the QSO, taking care 
to check that the correct callsign is logged.


A fix for this issue is being worked on for the next release. You do 
have a workaround, by closing down WSJT-X and restarting you will clear 
the hash table and messages should print correctly, at least until 
another hash collision occurs.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ADI file scanning

[Bill Somerville]

On 23/12/2018 14:10, Thomas Kocourek wrote:
Thank you Bill. I am staying away from Yahoo Groups. My apologies for 
using the developer list.


Hi Thomas,

no apologies necessary for posting issues with WSJT-X here. I was just 
pointing that the issue and that it was a known defect had been 
discussed here and on the Yahoo wsjtgroup previously.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Interesting feature

[Saku]

While keeping cursor at TX6 box (before my call) I did change directed 
cq between JA and AS.

All went ok if I had CAPS on (shift pressed).

Few times I missed shift and wrote "ja" instead of "JA". Results can be 
seen below.

Typing "as" or "AS" did not make any difference.

When I started to test this I did not get it happen any more () May 
be related to time of period when this "ja" is typed (?)

Or otherwise full TX period must be waited before new change.

If stopping TX and try to change "ja" and "JA"  and restart TX it does 
not make any difference.

That was the way I tried to quick test it more.


v2.0.0 (x64.rpm)  Fedora 28

--
Saku
OH1KH

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ADI file scanning

[Thomas Kocourek]

Thank you Bill. I am staying away from Yahoo Groups. My apologies for using
the developer list.

On Sun, Dec 23, 2018 at 7:22 AM Bill Somerville 
wrote:

> On 23/12/2018 12:11, Thomas Kocourek wrote:
> > I noticed a new error after upgrading wsjt-x to the 2.0 GA version. I
> > was getting an invalid ADIF file error window pop up. However, there
> > was no additional information.
> >
> > So, I inspected my wsjtx_log.adi file and could not see anything
> > obviously wrong. As a last resort, I deleted the blank lines which I
> > use to separate the session QSOs. LO and behold, the error disappeared.
> >
> > In the previous versions of wsjt-x, the blank lines were never a
> > problem. Why is the new version of wsjt-x having problems with
> > additional blank lines?
> >
> > I use the lines as a visual delineation for a session of QSOs.
> > This delineation allows me to copy the entries into a new file for
> > uploading the QSOs to the Logbook Of The World. Why waste time
> > uploading duplicate QSOs, just send the new ones.
>
> Hi Thomas,
>
> there is a known defect in WSJT-X v2.0.0 that has been discussed several
> times both here and on the Yahoo Group wsjtgroup. To work around it all
> you need do is delete any blank lines *at the end* of the ADIF file. The
> defect is fixed for the next release.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ADI file scanning

[Bill Somerville]

On 23/12/2018 12:11, Thomas Kocourek wrote:
I noticed a new error after upgrading wsjt-x to the 2.0 GA version. I 
was getting an invalid ADIF file error window pop up. However, there 
was no additional information.


So, I inspected my wsjtx_log.adi file and could not see anything 
obviously wrong. As a last resort, I deleted the blank lines which I 
use to separate the session QSOs. LO and behold, the error disappeared.


In the previous versions of wsjt-x, the blank lines were never a 
problem. Why is the new version of wsjt-x having problems with 
additional blank lines?


I use the lines as a visual delineation for a session of QSOs. 
This delineation allows me to copy the entries into a new file for 
uploading the QSOs to the Logbook Of The World. Why waste time 
uploading duplicate QSOs, just send the new ones.


Hi Thomas,

there is a known defect in WSJT-X v2.0.0 that has been discussed several 
times both here and on the Yahoo Group wsjtgroup. To work around it all 
you need do is delete any blank lines *at the end* of the ADIF file. The 
defect is fixed for the next release.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] ADI file scanning

[Thomas Kocourek]

I noticed a new error after upgrading wsjt-x to the 2.0 GA version. I was
getting an invalid ADIF file error window pop up. However, there was no
additional information.

So, I inspected my wsjtx_log.adi file and could not see anything obviously
wrong. As a last resort, I deleted the blank lines which I use to separate
the session QSOs. LO and behold, the error disappeared.

In the previous versions of wsjt-x, the blank lines were never a problem.
Why is the new version of wsjt-x having problems with additional blank
lines?

I use the lines as a visual delineation for a session of QSOs.
This delineation allows me to copy the entries into a new file for
uploading the QSOs to the Logbook Of The World. Why waste time uploading
duplicate QSOs, just send the new ones.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel