Re: [wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[Kevin McQuiggin]

Hi Steve and Bill:

FYI, I get a similar error when changing to MSK144 mode.   My terminal listing:

iMac:MacOS mcquiggi$ ./wsjtx
At line 2 of file /Users/bill/wsjtx-prefix/src/lib/hspec.f90
Fortran runtime error: Actual string length is shorter than the declared one 
for dummy argument 'mycall' (-4294967284/12)
iMac:MacOS mcquiggi$

Hope this helps,

Kevin


> On Jul 21, 2019, at 11:44 AM, Steven Franke via wsjt-devel 
>  wrote:
> 
>> On Jul 21, 2019, at 12:58 PM, John Nelson via wsjt-devel 
>>  wrote:
>> 
>> Hi Bill,
>> 
>> I managed to get someone to run the code from a Terminal window.  It exits 
>> with:
>> 
>> “At line 1 of file /Users/bill/wsjtx-prefix/src/lib/gen65.f90
>> Fortran runtime error: Actual string length is shorter than the declared on 
>> for dummy argument ‘msgsent’ (-216172782113783786/22)”
>> 
>> — John G4KLA___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> Hi John,
> 
> I’ve lost track of which issue your report pertains to. It seems that there 
> are 3 possibly unrelated issues at play on MacOS.
> 
> 1. Crash related to reading the LoTW user file. Bill has identified the cause 
> of this problem.
> 2. Kevin, VE7DS’s report of a crash related to MSK144 mode. I have tried, but 
> have not yet been able to reproduce this here.
> 3. George, KF2T’s report of a crash on startup when running a beta version of 
> MacOS. I have not tried to reproduce this.
> 
> Which one does your report address?  Or is your report yet another problem?
> 
> Steve k9an
> 
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Contest confusion

[Ed Muns]

Great tip, Laurie.

This is a good technique if one can reasonably assume that the majority of
QSO partners sending a signal report will not complete the QSO, or log it,
if the contester only sends a Grid Square.

IOW, if a contester set to NA VHF Contest mode connects up with a
"non-contester" set to normal mode (Special Activity unchecked), and both
are configured for Auto Seq, then the QSO will complete without any operator
intervention.  However, the contester will not have sent a signal report to
the non-contester.  That may be an issue, because the non-contester may
continue to send his SNR message, hoping to elicit an SNR in return.  Or, he
may not log the contact because he never received an SNR from the contester.
This may not be a problem for the contester, because the non-contester is
unlikely to submit a Cabrillo log, so the contester will avoid a NIL.

Back to your tip of setting up two instances of WSJT-X, one with NA VHF
Contest mode enabled and one with Special Activity unchecked.  This is a
good technique for the contester to get another QSO in the log that
otherwise would not happen, IF the assumption is the majority of "mixed"
QSOs as described above will not complete successfully because the
non-contester is concerned that he didn't receive a signal report.

The contester has to decide whether to power through the QSO in the NA VHF
Contest mode, or to on-the-fly switch to his "SNR Configuration" that uses
the standard non-contest message sequence and indeed sends an SNR message to
the non-contester.

Ed W0YK

-Original Message-
From: Laurie, VK3AMA <_vk3a...@vkdxer.net> 
Sent: 21 July, 2019 16:04
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Contest confusion

On 22/07/2019 7:16 am, Jim Brown wrote:
> so I quickly switched out of contest mode to work him. :)
>
> What I WOULD like is to able to do this without going to Settings 
> Advanced. All those clicks loses a TX cycle.
>
> 73, Jim K9YC 

Simple and only requires a single mouse click. Setup two configurations 
in WSJT-X, one for you desired contest and the other non-contest. Once 
setup, it is a single click using the "Configuration" menu to switch 
between contest and non-contest.

de Laurie VK3AMA



___
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] Contest confusion

[Laurie, VK3AMA]

On 22/07/2019 7:16 am, Jim Brown wrote:

so I quickly switched out of contest mode to work him. :)

What I WOULD like is to able to do this without going to Settings 
Advanced. All those clicks loses a TX cycle.


73, Jim K9YC 


Simple and only requires a single mouse click. Setup two configurations 
in WSJT-X, one for you desired contest and the other non-contest. Once 
setup, it is a single click using the "Configuration" menu to switch 
between contest and non-contest.


de Laurie VK3AMA



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

Re: [wsjt-devel] Contest confusion

[Ed Muns]

Hi Andy.

 

What if you did receive a signal report from a station participating in the
contest?  Would you then be ambivalent to whether your QSO partner was "in
the contest" or not?

 

For example, if your QSO partner is in contest mode but also had the ability
to manually initiate a SNR message, he could adapt to anyone sending him an
SNR message.  Yes, that "slows" the contester down, but many times the rate
is low anyway.  In any case, it is an incremental QSO for the contester and
it would be nice to have the choice.

 

My vision is that someday contests can provide activity for contesters and
non-contesters alike, with complete transparency.  The FT modes are
well-suited for this.  I'm interested to understand the current limitations
and what it will take to achieve the vision.

 

73,

Ed W0YK

 

From: Andy Durbin  
Sent: 21 July, 2019 10:18
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Contest confusion

 

I chose not to participate in the RTTY contest but still wished to make FT8
QSO on 6 meters.  I called  CQ K3WYC DM33 thus indicating I was not in the
contest.  Multiple stations answered me and replied to my report with "R
grid".  Since these stations provided no report they were not logged.

 

There needs to be a better way of separating contest participants from those
with no interest in the contest.  The contest cannot be allowed to take over
standard FT8 frequencies.

 

(I am not anti-contest.  I have worked many CW contests and a quite a few
phone and RTTY contests.  I simply choose not to use WSJT-X modes for
contesting)

 

73,

Andy, k3wyc

 

 

 

 

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

Re: [wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[Bill Somerville]

On 21/07/2019 19:44, Steven Franke via wsjt-devel wrote:

On Jul 21, 2019, at 12:58 PM, John Nelson via 
wsjt-devel  wrote:

Hi Bill,

I managed to get someone to run the code from a Terminal window.  It exits with:

“At line 1 of file /Users/bill/wsjtx-prefix/src/lib/gen65.f90
Fortran runtime error: Actual string length is shorter than the declared on for 
dummy argument ‘msgsent’ (-216172782113783786/22)”

— John G4KLA___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Hi John,

I’ve lost track of which issue your report pertains to. It seems that there are 
3 possibly unrelated issues at play on MacOS.

1. Crash related to reading the LoTW user file. Bill has identified the cause 
of this problem.
2. Kevin, VE7DS’s report of a crash related to MSK144 mode. I have tried, but 
have not yet been able to reproduce this here.
3. George, KF2T’s report of a crash on startup when running a beta version of 
MacOS. I have not tried to reproduce this.

Which one does your report address?  Or is your report yet another problem?

Steve k9an


Hi Steve,

it looks like there's a common thread emerging with strings passed 
between C++ and Fortran. I squashed one of these before the release but 
it seems there are others. I think it is related to a Fortran compiler 
upgrade on my build machine. The problem is almost certainly that some 
of our code is using techniques for passing C strings to Fortran that 
are not guaranteed to be well defined and the later versions of gfortran 
are not assuming that those techniques should work. I do have a 
background branch in progress to move all C++/Fortran boundary crossing 
code to more robust use of ISO_C_BINDING, I guess that will have to be 
promoted to a higher priority.


73
Bill
G4WS.

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

Re: [wsjt-devel] Contest confusion

[Jim Brown]

On 7/21/2019 10:17 AM, Andy Durbin wrote:
I chose not to participate in the RTTY contest but still wished to make 
FT8 QSO on 6 meters.  I called CQ K3WYC DM33 thus indicating I was not 
in the contest.  Multiple stations answered me and replied to my report 
with "R grid".  Since these stations provided no report they were not 
logged.


I don't understand the problem, Andy. Participation in any contest is 
simply a matter of how you choose which stations to work and whether you 
send in a log. During a contest, most operators will be USING contest 
mode, which simply speeds up the exchange, but it doesn't put you "in 
the contest." It is, by the way, common for rare grid expeditions to use 
contest mode for the same reason. When most stations are using contest 
mode and you're not, it's sort of like running up the down escalator. :) 
The only thing that contest mode costs you is a signal report, but 
that's pretty meaningless in telling you about how your station is doing 
because it's based on how much receive noise the other station has.


While I am a contester, I find it difficult to view VHF contests as 
contests. I was quite active throughout, but my only objective was 
working new grids. My only new one was a JA who wasn't in contest mode, 
so I quickly switched out of contest mode to work him. :)


What I WOULD like is to able to do this without going to Settings 
Advanced. All those clicks loses a TX cycle.


73, Jim K9YC


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

Re: [wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[Adam Bartlett]

Relating to Kevin VE7DS's issue with MSK144 selection on OS X (my machine
is running Mojave 10.14.4)

iMac:~ adamb$ /Applications/wsjtx.app/Contents/MacOS/wsjtx
At line 2 of file /Users/bill/wsjtx-prefix/src/lib/hspec.f90
Fortran runtime error: Actual string length is shorter than the declared
one for dummy argument 'datadir' (-4294966784/512)

On Sun, Jul 21, 2019 at 1:46 PM Steven Franke via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> > On Jul 21, 2019, at 12:58 PM, John Nelson via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
> >
> > Hi Bill,
> >
> > I managed to get someone to run the code from a Terminal window.  It
> exits with:
> >
> > “At line 1 of file /Users/bill/wsjtx-prefix/src/lib/gen65.f90
> > Fortran runtime error: Actual string length is shorter than the declared
> on for dummy argument ‘msgsent’ (-216172782113783786/22)”
> >
> > — John G4KLA___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> Hi John,
>
> I’ve lost track of which issue your report pertains to. It seems that
> there are 3 possibly unrelated issues at play on MacOS.
>
> 1. Crash related to reading the LoTW user file. Bill has identified the
> cause of this problem.
> 2. Kevin, VE7DS’s report of a crash related to MSK144 mode. I have tried,
> but have not yet been able to reproduce this here.
> 3. George, KF2T’s report of a crash on startup when running a beta version
> of MacOS. I have not tried to reproduce this.
>
> Which one does your report address?  Or is your report yet another
> problem?
>
> Steve k9an
>
>
>
>
> ___
> 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] MacOS WSJT-X v2.1.0 users please read

[Steven Franke via wsjt-devel]

> On Jul 21, 2019, at 12:58 PM, John Nelson via wsjt-devel 
>  wrote:
> 
> Hi Bill,
> 
> I managed to get someone to run the code from a Terminal window.  It exits 
> with:
> 
> “At line 1 of file /Users/bill/wsjtx-prefix/src/lib/gen65.f90
> Fortran runtime error: Actual string length is shorter than the declared on 
> for dummy argument ‘msgsent’ (-216172782113783786/22)”
> 
> — John G4KLA___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Hi John,

I’ve lost track of which issue your report pertains to. It seems that there are 
3 possibly unrelated issues at play on MacOS.

1. Crash related to reading the LoTW user file. Bill has identified the cause 
of this problem.
2. Kevin, VE7DS’s report of a crash related to MSK144 mode. I have tried, but 
have not yet been able to reproduce this here.
3. George, KF2T’s report of a crash on startup when running a beta version of 
MacOS. I have not tried to reproduce this.

Which one does your report address?  Or is your report yet another problem? 

Steve k9an




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

Re: [wsjt-devel] Help! Ft857d, signalink, Windows 7 and ft8

[George J Molnar]

What are you using for CAT control? The Signalink only handles audio and PTT. 

George J Molnar
Arlington, Virginia USA
Office: ‪(202) 618-1077‬
Mobile: (702) 767-5420

> On Jul 21, 2019, at 1:34 PM, Robert Anthony  
> wrote:
> 
> 
> Anyone using the above and getting it to work? I can't get them to work in 
> the f/h mode. Get a error message. 
> 
> W8om Bob Anthony 
> 
> 
> 
> Sent from my Galaxy Tab® A
> ___
> 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] Help! Ft857d, signalink, Windows 7 and ft8

[Robert Anthony]

I have a ft2000 and it works also, but the 857D is or has been a problem.TNX 
for your reply maybe someone will have a answer for me W8om Bob Sent from my 
Galaxy Tab® A
 Original message From: Tom Ramberg via wsjt-devel 
 Date: 7/21/19  1:44 PM  (GMT-05:00) To: WSJT 
software development  Cc: Tom Ramberg 
 Subject: Re: [wsjt-devel] Help! Ft857d, signalink, Windows 7 
and ft8 For what it's worth, at OH2K club station we use Signalink, FT1000MP (I 
realise it's a different rig) and Windows 7 64 bit, and have had no problem 
with F/H. This isn't very helpful, I suppose.OH6VDA Tom21. jul. 2019 kl. 20:32 
skrev Robert Anthony :Anyone using the above and 
getting it to work? I can't get them to work in the f/h mode. Get a error 
message. W8om Bob Anthony Sent from my Galaxy Tab® 
A___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

Re: [wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[John Nelson via wsjt-devel]

Hi Bill,

I managed to get someone to run the code from a Terminal window.  It exits with:

“At line 1 of file /Users/bill/wsjtx-prefix/src/lib/gen65.f90
Fortran runtime error: Actual string length is shorter than the declared on for 
dummy argument ‘msgsent’ (-216172782113783786/22)”

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Contest confusion

[Andy Durbin]

I chose not to participate in the RTTY contest but still wished to make FT8 QSO 
on 6 meters.  I called  CQ K3WYC DM33 thus indicating I was not in the contest. 
 Multiple stations answered me and replied to my report with "R grid".  Since 
these stations provided no report they were not logged.

There needs to be a better way of separating contest participants from those 
with no interest in the contest.  The contest cannot be allowed to take over 
standard FT8 frequencies.

(I am not anti-contest.  I have worked many CW contests and a quite a few phone 
and RTTY contests.  I simply choose not to use WSJT-X modes for contesting)

73,
Andy, k3wyc




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

Re: [wsjt-devel] Help! Ft857d, signalink, Windows 7 and ft8

[Tom Ramberg via wsjt-devel]

For what it's worth, at OH2K club station we use Signalink, FT1000MP (I realise 
it's a different rig) and Windows 7 64 bit, and have had no problem with F/H. 
This isn't very helpful, I suppose.

OH6VDA Tom
> 21. jul. 2019 kl. 20:32 skrev Robert Anthony :
> 
> Anyone using the above and getting it to work? I can't get them to work in 
> the f/h mode. Get a error message. 
> 
> W8om Bob Anthony 
> 
> 
> 
> Sent from my Galaxy Tab® A
> ___
> 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

[wsjt-devel] Ft857d, signalink, Windows 7

[Robert Anthony]

Anyone using ft857d, signalink, and Windows 7 and getting them to work? I can't 
use f/h mode get a error message. W8om Bob Anthony Sent from my Galaxy Tab® A
 Original message From: George Molnar  Date: 
7/21/19  7:33 AM  (GMT-05:00) To: WSJT software development 
 Subject: Re: [wsjt-devel] MacOS WSJT-X 
v2.1.0 users please read Thanks for the effort, Bill. Unfortunately, no change 
on MacOS Catalina beta. Still crash on launch.73
George J MolnarArlington, Virginia, USA

On Jul 21, 2019, at 6:34 AM, Bill Somerville  wrote:
  


  
  
Hi all,


some of you have reported a
  crash on startup, thanks to those who have provided the crash
  report.


I can confirm there is a
  defect which appears to be in the underlying Qt library we use for
  cross platform portability. The issue is fixed in Qt v5.11 but
  using that will entail dropping support for macOS Yosemite
  (10.10), that will probably happen at the next release of WSJT-X.


In the meantime there is a
  workaround with some minor loss of functionality. The crash
  happens in code to read the LoTW user file downloaded from the
  ARRL LoTW web site. WSJT-X will function without that file but
  without highlighting of known LoTW user's CQ calls. To avoid the
  issue delete following file:


~/Library/"Application
Support"/WSJT-X/lotw-user-activity.csv
  Once deleted you should not
use the "Preferences->Colors->Logbook of the World user
Validation->Fetch" button until this issue is resolved.Note that this 
issue is not
affecting all users, if you are not seeing this crash then you
may be able to continue using WSJT-X v2.1.0 without taking the
action.
73
  Bill
  G4WJS.
  

___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] Help! Ft857d, signalink, Windows 7 and ft8

[Robert Anthony]

Anyone using the above and getting it to work? I can't get them to work in the 
f/h mode. Get a error message. W8om Bob Anthony Sent from my Galaxy Tab® A___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[Bill Somerville]

Hi Kevin,

I did see your report of this issue, I have yet to reproduce it. Several 
macOS WSJT-X v2.1.0 users have reported crashes that do not generate a 
crash report and only leave a trace in the console log of launchd with 
exit code 2. Exit code 2 is normally a file not found error but I don't 
know if that is the case here or what file it may be failing to find. I 
am waiting for someone who can reproduce this error to try running 
WSJT-X from a console terminal command line like this:


/Applications/wsjtx.app/Contents/MacOS/wsjtx

i.e. not using open that uses launchd in turn. I am hoping a more 
helpful error message may be forthcoming.


73
Bill
G4WJS.

On 21/07/2019 17:19, Kevin McQuiggin (SFU) wrote:

Bill, thanks for this info!

The crashes I have seen are related to selection of MSK144 mode.  This 
invariably causes the app to crash.  Sometimes MSK144 mode will “come 
up” in the UI, but in that case any interaction with the UI elements 
will cause the app to crash.  I submitted a report about this to the 
list several days ago.  The only message in the system log says 
something about launched and “abnormal exit code 2”.


I am not at my machine but can provide whatever specific info you 
need.  Thanks to the team for all the great work on he apps!


73,

Kevin VE7ZD

Sent from my iPad

On Jul 21, 2019, at 03:34, Bill Somerville > wrote:



Hi all,

some of you have reported a crash on startup, thanks to those who 
have provided the crash report.


I can confirm there is a defect which appears to be in the underlying 
Qt library we use for cross platform portability. The issue is fixed 
in Qt v5.11 but using that will entail dropping support for macOS 
Yosemite (10.10), that will probably happen at the next release of 
WSJT-X.


In the meantime there is a workaround with some minor loss of 
functionality. The crash happens in code to read the LoTW user file 
downloaded from the ARRL LoTW web site. WSJT-X will function without 
that file but without highlighting of known LoTW user's CQ calls. To 
avoid the issue delete following file:


~/Library/"Application Support"/WSJT-X/lotw-user-activity.csv

Once deleted you should not use the "Preferences->Colors->Logbook of 
the World user Validation->Fetch" button until this issue is resolved.


Note that this issue is not affecting all users, if you are not 
seeing this crash then you may be able to continue using WSJT-X 
v2.1.0 without taking the action.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Wrong date/time using NA VHF Contest mode

[Don Hill AA5AU]

When double-clicking into the Date & Time field of the Contest Log, the
entry changes to 1/1/1970 00:00:00 and you can't change it.

 

Don AA5AU

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, July 21, 2019 11:59 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Wrong date/time using NA VHF Contest mode

 

Hi Don,

 

I am not sure what you are reporting here. Is it that you are unable to edit
date and time fields in the contest log window, or is it that when you
double click a field to edit it you get some incorrect value?

 

Can you explain listing exactly the steps taken please, and the results you
see that arr incorrect.

 

73

Bill
G4WJS.

 

On 21/07/2019 17:23, Don Hill AA5AU wrote:

I see what happened. It actually logged it correctly, but when I
accidentally double-clicked it in the Contest Log, it changed the Date and
Time to what is shown. I did it to another correct entry and it changed it
to 1/1/1970 and 00:00:00.

 

Definitely a bug.

 

Don AA5AU

 

From: Don Hill AA5AU [mailto:aa...@bellsouth.net] 
Sent: Sunday, July 21, 2019 11:21 AM
To: 'WSJT software development'
Subject: Wrong date/time using NA VHF Contest mode

 

Working the CQ VHF contest today and everything was fine until I logged
KK6NTL with a time of 00:00:00 and date of 1/1/1970 in the Contest log and
it won't allow me to edit it to the correct time and date. It will allow me
to edit it, but it doesn't change the entry.

 

wsjt-x-aa5au01.jpg

 

The entry in wsjtx_log.adi seems correct.

 

KK6NTL DM95 FT8  -07
20190721 160830 20190721
160930 6m 50.315022 AA5AU
EL49XU 

 

Don AA5AU

 

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

Re: [wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[Kevin McQuiggin (SFU)]

Bill, thanks for this info!

The crashes I have seen are related to selection of MSK144 mode.  This 
invariably causes the app to crash.  Sometimes MSK144 mode will “come up” in 
the UI, but in that case any interaction with the UI elements will cause the 
app to crash.  I submitted a report about this to the list several days ago.  
The only message in the system log says something about launched and “abnormal 
exit code 2”.

I am not at my machine but can provide whatever specific info you need.  Thanks 
to the team for all the great work on he apps!

73,

Kevin VE7ZD 

Sent from my iPad

> On Jul 21, 2019, at 03:34, Bill Somerville  wrote:
> 
> Hi all,
> 
> some of you have reported a crash on startup, thanks to those who have 
> provided the crash report.
> 
> I can confirm there is a defect which appears to be in the underlying Qt 
> library we use for cross platform portability. The issue is fixed in Qt v5.11 
> but using that will entail dropping support for macOS Yosemite (10.10), that 
> will probably happen at the next release of WSJT-X.
> 
> In the meantime there is a workaround with some minor loss of functionality. 
> The crash happens in code to read the LoTW user file downloaded from the ARRL 
> LoTW web site. WSJT-X will function without that file but without 
> highlighting of known LoTW user's CQ calls. To avoid the issue delete 
> following file:
> 
> ~/Library/"Application Support"/WSJT-X/lotw-user-activity.csv
> Once deleted you should not use the "Preferences->Colors->Logbook of the 
> World user Validation->Fetch" button until this issue is resolved.
> 
> Note that this issue is not affecting all users, if you are not seeing this 
> crash then you may be able to continue using WSJT-X v2.1.0 without taking the 
> action.
> 
> 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] Wrong date/time using NA VHF Contest mode

[Bill Somerville]

Hi Don,

I am not sure what you are reporting here. Is it that you are unable to 
edit date and time fields in the contest log window, or is it that when 
you double click a field to edit it you get some incorrect value?


Can you explain listing exactly the steps taken please, and the results 
you see that arr incorrect.


73
Bill
G4WJS.

On 21/07/2019 17:23, Don Hill AA5AU wrote:


I see what happened. It actually logged it correctly, but when I 
accidentally double-clicked it in the Contest Log, it changed the Date 
and Time to what is shown. I did it to another correct entry and it 
changed it to 1/1/1970 and 00:00:00.


Definitely a bug.

Don AA5AU

*From:*Don Hill AA5AU [mailto:aa...@bellsouth.net]
*Sent:* Sunday, July 21, 2019 11:21 AM
*To:* 'WSJT software development'
*Subject:* Wrong date/time using NA VHF Contest mode

Working the CQ VHF contest today and everything was fine until I 
logged KK6NTL with a time of 00:00:00 and date of 1/1/1970 in the 
Contest log and it won't allow me to edit it to the correct time and 
date. It will allow me to edit it, but it doesn't change the entry.


wsjt-x-aa5au01.jpg

The entry in wsjtx_log.adi seems correct.

KK6NTL DM95 FT8  
-07 20190721 160830 
20190721 160930 6m 
50.315022 AA5AU EL49XU 


Don AA5AU



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

Re: [wsjt-devel] Wrong date/time using NA VHF Contest mode

[Don Hill AA5AU]

I see what happened. It actually logged it correctly, but when I
accidentally double-clicked it in the Contest Log, it changed the Date and
Time to what is shown. I did it to another correct entry and it changed it
to 1/1/1970 and 00:00:00.

 

Definitely a bug.

 

Don AA5AU

 

From: Don Hill AA5AU [mailto:aa...@bellsouth.net] 
Sent: Sunday, July 21, 2019 11:21 AM
To: 'WSJT software development'
Subject: Wrong date/time using NA VHF Contest mode

 

Working the CQ VHF contest today and everything was fine until I logged
KK6NTL with a time of 00:00:00 and date of 1/1/1970 in the Contest log and
it won't allow me to edit it to the correct time and date. It will allow me
to edit it, but it doesn't change the entry.

 

wsjt-x-aa5au01.jpg

 

The entry in wsjtx_log.adi seems correct.

 

KK6NTL DM95 FT8  -07
20190721 160830 20190721
160930 6m 50.315022 AA5AU
EL49XU 

 

Don AA5AU

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

[wsjt-devel] Wrong date/time using NA VHF Contest mode

[Don Hill AA5AU]

Working the CQ VHF contest today and everything was fine until I logged
KK6NTL with a time of 00:00:00 and date of 1/1/1970 in the Contest log and
it won't allow me to edit it to the correct time and date. It will allow me
to edit it, but it doesn't change the entry.

 

wsjt-x-aa5au01.jpg

 

The entry in wsjtx_log.adi seems correct.

 

KK6NTL DM95 FT8  -07
20190721 160830 20190721
160930 6m 50.315022 AA5AU
EL49XU 

 

Don AA5AU

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

[wsjt-devel] tx4 RR73 bug

[Black Michael via wsjt-devel]

There's an inconsistency in double-clicking Tx4 selector.I assume txb4 should 
be same as txrb4 for the FT4 RR73 settings.
void MainWindow::on_txrb4_doubleClicked (){  // RR73 only allowed if not a type 
2 compound callsign  auto const& my_callsign = m_config.my_callsign ();  auto 
is_compound = my_callsign != m_baseCall;  m_send_RR73 = !((is_compound && 
!shortList (my_callsign)) || m_send_RR73);  if(m_mode=="FT4" and 
(m_config.special_op_id()==SpecOp::RTTY)) m_send_RR73=true;  genStdMsgs 
(m_rpt);}

void MainWindow::on_txb4_doubleClicked(){  // RR73 only allowed if not a type 2 
compound callsign  auto const& my_callsign = m_config.my_callsign ();  auto 
is_compound = my_callsign != m_baseCall;  m_send_RR73 = !((is_compound && 
!shortList (my_callsign)) || m_send_RR73);  if(m_mode=="FT4") m_send_RR73=true; 
 genStdMsgs (m_rpt);}
de Mike W9MDB___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[Bill Somerville]

On 21/07/2019 12:33, George Molnar wrote:
Thanks for the effort, Bill. Unfortunately, no change on MacOS 
Catalina beta. Still crash on launch.


73


*George J Molnar*
Arlington, Virginia, USA


Hi George,

the crash with macOS 10.15 beta is a different one. For that I will wait 
until 10.15 goes live, by then either Apple will have fixed some issue 
or Qt team will have fixed some issue that resolves this. Sorry, but 
running pre-release software is always likely to reveal issues.


73
Bill
G4WJS.

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

Re: [wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[George Molnar]

Thanks for the effort, Bill. Unfortunately, no change on MacOS Catalina beta. 
Still crash on launch.

73


George J Molnar
Arlington, Virginia, USA





> On Jul 21, 2019, at 6:34 AM, Bill Somerville  wrote:
> 
> Hi all,
> 
> some of you have reported a crash on startup, thanks to those who have 
> provided the crash report.
> 
> I can confirm there is a defect which appears to be in the underlying Qt 
> library we use for cross platform portability. The issue is fixed in Qt v5.11 
> but using that will entail dropping support for macOS Yosemite (10.10), that 
> will probably happen at the next release of WSJT-X.
> 
> In the meantime there is a workaround with some minor loss of functionality. 
> The crash happens in code to read the LoTW user file downloaded from the ARRL 
> LoTW web site. WSJT-X will function without that file but without 
> highlighting of known LoTW user's CQ calls. To avoid the issue delete 
> following file:
> 
> ~/Library/"Application Support"/WSJT-X/lotw-user-activity.csv
> Once deleted you should not use the "Preferences->Colors->Logbook of the 
> World user Validation->Fetch" button until this issue is resolved.
> 
> Note that this issue is not affecting all users, if you are not seeing this 
> crash then you may be able to continue using WSJT-X v2.1.0 without taking the 
> action.
> 
> 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

[wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[Bill Somerville]

Hi all,

some of you have reported a crash on startup, thanks to those who have 
provided the crash report.


I can confirm there is a defect which appears to be in the underlying Qt 
library we use for cross platform portability. The issue is fixed in Qt 
v5.11 but using that will entail dropping support for macOS Yosemite 
(10.10), that will probably happen at the next release of WSJT-X.


In the meantime there is a workaround with some minor loss of 
functionality. The crash happens in code to read the LoTW user file 
downloaded from the ARRL LoTW web site. WSJT-X will function without 
that file but without highlighting of known LoTW user's CQ calls. To 
avoid the issue delete following file:


~/Library/"Application Support"/WSJT-X/lotw-user-activity.csv

Once deleted you should not use the "Preferences->Colors->Logbook of the 
World user Validation->Fetch" button until this issue is resolved.


Note that this issue is not affecting all users, if you are not seeing 
this crash then you may be able to continue using WSJT-X v2.1.0 without 
taking the action.


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