date:20200529


Hi Ryan,

thanks for the issue report. I have tracked down the problem which only 
happens when the primary UI language is 'en-US', there are no other 'en' 
languages installed, and another language is installed. I had missed it 
because I always had 'en-GB' installed. It is fixed for the next release.


73
Bill
G4WJS.

On 29/05/2020 17:25, Ryan Woolley wrote:

Hi Bill and team,

I note that the release notes for rc3 includes "Load language 
translations only when matching primary language", so I wanted to let 
you know that I'm continuing to observe this behavior in rc3.  If you 
meant that it will be fixed in the non-rc version, then my apologies 
for the duplicate report.


With Spanish enabled in the OS (but not primary), rc3 opens in Spanish.

As with Catalan in rc2, removing Spanish from the OS under Languages 
and Regions causes a return to English and re-adding Spanish causes a 
return to Spanish.  (Out of curiosity, I re-added Catalan so that both 
Catalan and Spanish were available, and rc3 opens in Spanish.)


73,
Ryan KC7RW


*From:* Bill Somerville 
*Sent:* Monday, May 25, 2020 9:41 AM
*To:* wsjt-devel@lists.sourceforge.net 
*Subject:* Re: [wsjt-devel] WSJT-X 2.2.0-rc2 on macOS defaults to Catalan
Hi Ryan,

thanks for that clarification. I'm not sure why your system has so 
many languages enabled. The issue is a WSJT-X defect anyway, it is 
trying to do something clever to make life easier for potential 
translators and the code isn't quite right. It will be sorted out for 
the next release.


Thanks for the issue report.

73
Bill
G4WJS.



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

Re: [wsjt-devel] RC3 Erase button bug




On 5/29/2020 3:53 PM, Rich Zwirko - K1HTV wrote:
I just downloaded and installed RC3. With the RxFrequency column in 
focus, the Erase button works, but with the Band Activity side in focus 
the Erase button has no effect. However, using a right click and then 
selecting 'Erase' does work OK on both sides.


I reloaded RC2 and found that it has the same bug. Is it my system or 
are others seeing this anomaly?


As far as I can see, the Erase button works as it always has.  Click 
once to erase the Right window, double-click to erase both tet windows.


-- Joe, K1JT


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

Re: [wsjt-devel] wsjtx_2.2.0-rc2_amd64.deb install fails on wsjtx_icon.png

2020-05-29 Thread jeff millar

Hi BIll and Christoph...

This is the pleasures of the bleeding edge...when will I ever learn?

jeff

On Fri, May 29, 2020 at 3:57 PM Bill Somerville 
wrote:

> Hi Jeff,
>
> you have two viable options, build from sources, or wait for the package
> maintainers to make WSJT-X 2.2.0 available for your distribution version.
> We, the WSJT-X development team, only build a single package targeted at
> one commonly used distribution version. Currently Ubuntu 20.4.0 has no easy
> upgrade path, nor are users of earlier versions informed that there is an
> upgrade available. That happens at the .1 release when we will switch to
> building our release package targeting 20.04.1 LTS.
>
> Building from sources is not hard, much easier than the option many will
> suggest of installing packages like libgfortran3 on a system that comes
> with libgfortran5.
>
> 73
> Bill
> G4WJS.
>
> On 29/05/2020 18:05, jeff millar wrote:
>
> Hi Bill and Christoph,
>
> Thanks for the help.
>
> Removing all the wsjtx packages improved the situation.  dpkg now installs
> wsjtx incompletely and leaves a broken package.  Ubuntu 20.04 has
> libgfortran5 by default, 4 is available and 3 is not.  For libreadline, 8
> is the default and 5 is available.
>
> Is there a way to fix this?
>
> jeff, wa1hco
>
> jeff@jeff-MS-7C02:~/Downloads$ sudo dpkg -i wsjtx_2.2.0-rc3_amd64.deb
> (Reading database ... 259031 files and directories currently installed.)
> Preparing to unpack wsjtx_2.2.0-rc3_amd64.deb ...
> Unpacking wsjtx (2.2.0-rc3) over (2.2.0-rc3) ...
> dpkg: dependency problems prevent configuration of wsjtx:
>  wsjtx depends on libgfortran3 (>= 4.8.2); however:
>   Package libgfortran3 is not installed.
>  wsjtx depends on libreadline7 (>= 6.0); however:
>   Package libreadline7 is not installed.
>
> dpkg: error processing package wsjtx (--install):
>  dependency problems - leaving unconfigured
> Processing triggers for gnome-menus (3.36.0-1ubuntu1) ...
> Processing triggers for desktop-file-utils (0.24-1ubuntu2) ...
> Processing triggers for mime-support (3.64ubuntu1) ...
> Processing triggers for man-db (2.9.1-1) ...
> Errors were encountered while processing:
>  wsjtx
> (
>
> On Thu, May 28, 2020 at 6:17 AM Christoph Berg  wrote:
>
>> Re: Bill Somerville
>> > that looks like you have some other package installed in /usr/local
>> called
>> > wsjtx-data2.1.2+repack-2build1, I have no idea what that is, but
>> suggest you
>> > uninstall that package before trying to install our amd64 package.
>>
>> The Debian package is split into wsjtx, wsjtx-data, and wsjtx-doc.
>>
>> This specific version is the one included in Ubuntu focal.
>>
>> Christoph
>>
>
> ___
> 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] RC3 Erase button bug


On 29/05/2020 20:53, Rich Zwirko - K1HTV wrote:
I just downloaded and installed RC3. With the RxFrequency column in 
focus, the Erase button works, but with the Band Activity side in 
focus the Erase button has no effect. However, using a right click and 
then selecting 'Erase' does work OK on both sides.


I reloaded RC2 and found that it has the same bug. Is it my system or 
are others seeing this anomaly?


73,
Rich - K1HTV


Hi Rich,

the "Erase" button has dual-action, single-click to clear the Rx 
Frequency window, double-click to clear both windows. keyboard focus has 
no bearing on this. It's been that way for many versions. The tool tip 
you get when hovering the mouse pointer over the "Erase" button says 
what it does.


73
Bill
G4WJS.



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

Re: [wsjt-devel] RC3 Erase button bug

2020-05-29 Thread Christoph Berg

Re: Rich Zwirko - K1HTV
> I just downloaded and installed RC3. With the RxFrequency column in focus,
> the Erase button works, but with the Band Activity side in focus the Erase
> button has no effect. However, using a right click and then selecting
> 'Erase' does work OK on both sides.

Double-click the erase button to erase the band activity window.

Christoph


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

Re: [wsjt-devel] wsjtx_2.2.0-rc2_amd64.deb install fails on wsjtx_icon.png

Hi Jeff,

you have two viable options, build from sources, or wait for the package 
maintainers to make WSJT-X 2.2.0 available for your distribution 
version. We, the WSJT-X development team, only build a single package 
targeted at one commonly used distribution version. Currently Ubuntu 
20.4.0 has no easy upgrade path, nor are users of earlier versions 
informed that there is an upgrade available. That happens at the .1 
release when we will switch to building our release package targeting 
20.04.1 LTS.

Building from sources is not hard, much easier than the option many will 
suggest of installing packages like libgfortran3 on a system that comes 
with libgfortran5.

73
Bill
G4WJS.

On 29/05/2020 18:05, jeff millar wrote:

Hi Bill and Christoph,

Thanks for the help.

Removing all the wsjtx packages improved the situation. dpkg now 
installs wsjtx incompletely and leaves a broken package.  Ubuntu 20.04 
has libgfortran5 by default, 4 is available and 3 is not.  For 
libreadline, 8 is the default and 5 is available.

Is there a way to fix this?

jeff, wa1hco

jeff@jeff-MS-7C02:~/Downloads$ sudo dpkg -i wsjtx_2.2.0-rc3_amd64.deb
(Reading database ... 259031 files and directories currently installed.)
Preparing to unpack wsjtx_2.2.0-rc3_amd64.deb ...
Unpacking wsjtx (2.2.0-rc3) over (2.2.0-rc3) ...
dpkg: dependency problems prevent configuration of wsjtx:
 wsjtx depends on libgfortran3 (>= 4.8.2); however:
  Package libgfortran3 is not installed.
 wsjtx depends on libreadline7 (>= 6.0); however:
  Package libreadline7 is not installed.

dpkg: error processing package wsjtx (--install):
 dependency problems - leaving unconfigured
Processing triggers for gnome-menus (3.36.0-1ubuntu1) ...
Processing triggers for desktop-file-utils (0.24-1ubuntu2) ...
Processing triggers for mime-support (3.64ubuntu1) ...
Processing triggers for man-db (2.9.1-1) ...
Errors were encountered while processing:
 wsjtx
(

On Thu, May 28, 2020 at 6:17 AM Christoph Berg > wrote:

Re: Bill Somerville
> that looks like you have some other package installed in
/usr/local called
> wsjtx-data2.1.2+repack-2build1, I have no idea what that is, but
suggest you
> uninstall that package before trying to install our amd64 package.

The Debian package is split into wsjtx, wsjtx-data, and wsjtx-doc.

This specific version is the one included in Ubuntu focal.

Christoph

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

[wsjt-devel] RC3 Erase button bug

2020-05-29 Thread Rich Zwirko - K1HTV

I just downloaded and installed RC3. With the RxFrequency column in focus,
the Erase button works, but with the Band Activity side in focus the Erase
button has no effect. However, using a right click and then selecting
'Erase' does work OK on both sides.

I reloaded RC2 and found that it has the same bug. Is it my system or are
others seeing this anomaly?

73,
Rich - K1HTV
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjtx_2.2.0-rc2_amd64.deb install fails on wsjtx_icon.png

2020-05-29 Thread Christoph Berg

Re: jeff millar
> Removing all the wsjtx packages improved the situation.  dpkg now installs
> wsjtx incompletely and leaves a broken package.  Ubuntu 20.04 has
> libgfortran5 by default, 4 is available and 3 is not.  For libreadline, 8
> is the default and 5 is available.
> 
> Is there a way to fix this?

2.2.0~rc packages would be available in Ubuntu groovy, and Debian
bullseye. (Both being development branches that have not been released
yet.)

Christoph


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

Re: [wsjt-devel] wsjtx_2.2.0-rc2_amd64.deb install fails on wsjtx_icon.png

2020-05-29 Thread jeff millar

Hi Bill and Christoph,

Thanks for the help.

Removing all the wsjtx packages improved the situation.  dpkg now installs
wsjtx incompletely and leaves a broken package.  Ubuntu 20.04 has
libgfortran5 by default, 4 is available and 3 is not.  For libreadline, 8
is the default and 5 is available.

Is there a way to fix this?

jeff, wa1hco

jeff@jeff-MS-7C02:~/Downloads$ sudo dpkg -i wsjtx_2.2.0-rc3_amd64.deb
(Reading database ... 259031 files and directories currently installed.)
Preparing to unpack wsjtx_2.2.0-rc3_amd64.deb ...
Unpacking wsjtx (2.2.0-rc3) over (2.2.0-rc3) ...
dpkg: dependency problems prevent configuration of wsjtx:
 wsjtx depends on libgfortran3 (>= 4.8.2); however:
  Package libgfortran3 is not installed.
 wsjtx depends on libreadline7 (>= 6.0); however:
  Package libreadline7 is not installed.

dpkg: error processing package wsjtx (--install):
 dependency problems - leaving unconfigured
Processing triggers for gnome-menus (3.36.0-1ubuntu1) ...
Processing triggers for desktop-file-utils (0.24-1ubuntu2) ...
Processing triggers for mime-support (3.64ubuntu1) ...
Processing triggers for man-db (2.9.1-1) ...
Errors were encountered while processing:
 wsjtx
(

On Thu, May 28, 2020 at 6:17 AM Christoph Berg  wrote:

> Re: Bill Somerville
> > that looks like you have some other package installed in /usr/local
> called
> > wsjtx-data2.1.2+repack-2build1, I have no idea what that is, but suggest
> you
> > uninstall that package before trying to install our amd64 package.
>
> The Debian package is split into wsjtx, wsjtx-data, and wsjtx-doc.
>
> This specific version is the one included in Ubuntu focal.
>
> Christoph
>
>
> ___
> 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-X 2.2.0-rc3 rigctld-wsjtx still not working with IC7300 or IC703

2020-05-29 Thread Kari


Hi Mike,

On 29.5.2020 19.11, Black Michael via wsjt-devel wrote:

What do you get from these commands?

ldd rigctld-wsjtx | grep hamlib
ldd wsjtx | grep hamlib


I get no output.

FYI, I compiled rc3 from sources ( if that makes any difference ... )

'Kari


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

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 on macOS defaults to Catalan

2020-05-29 Thread Ryan Woolley

Hi Bill and team,

I note that the release notes for rc3 includes "Load language translations only 
when matching primary language", so I wanted to let you know that I'm 
continuing to observe this behavior in rc3.  If you meant that it will be fixed 
in the non-rc version, then my apologies for the duplicate report.

With Spanish enabled in the OS (but not primary), rc3 opens in Spanish.

As with Catalan in rc2, removing Spanish from the OS under Languages and 
Regions causes a return to English and re-adding Spanish causes a return to 
Spanish.  (Out of curiosity, I re-added Catalan so that both Catalan and 
Spanish were available, and rc3 opens in Spanish.)

73,
Ryan KC7RW


From: Bill Somerville 
Sent: Monday, May 25, 2020 9:41 AM
To: wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 on macOS defaults to Catalan

Hi Ryan,

thanks for that clarification. I'm not sure why your system has so many 
languages enabled. The issue is a WSJT-X defect anyway, it is trying to do 
something clever to make life easier for potential translators and the code 
isn't quite right. It will be sorted out for the next release.

Thanks for the issue report.

73
Bill
G4WJS.

On 25/05/2020 14:33, Ryan Woolley wrote:
Hi Bill,

Yes.  Although I haven't specifically installed any additional languages, I see 
33 languages listed in System Preferences -> Language and Region including 
Catalan.  English is the only one selected as primary.  It's possible these 
were installed by the Xcode installer -- that is the only thing I can think of 
that's remarkable about this machine.  I checked two other Macs without Xcode, 
and those have only English listed in Languages and Regions.  On a second Mac 
with Xcode, I installed rc2 and saw the same behavior (default to Catalan).  
After removing Catalan as an option in Language and Region (by selecting it and 
hitting "-"), then re-launching rc2, it returned to English.  Re-adding Catalan 
caused rc2 to return to using Catalan.  So, the behavior I'm observing seems to 
be: when Catalan support is installed in the OS, rc2 defaults to Catalan.

73,
Ryan KC7RW


From: Bill Somerville 
Sent: Monday, May 25, 2020 6:26 AM
To: wsjt-devel@lists.sourceforge.net 

Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 on macOS defaults to Catalan

On 25/05/2020 04:07, Ryan Woolley wrote:
After installing rc2 over rc1 on 10.15.4, the language defaults to Catalan.  
Launching from Terminal with -l en or -l en-us has no effect, and System 
Preferences -> Language and Region -> Apps -> wsjtx reports "wsjtx doesn't 
support additional languages", so no apparent way to shift back to English.

Thanks,
Ryan KC7RW


Hi Ryan,

do you have the Catalan language pack installed, even if it is not the selected 
primary language?

73
Bill
G4WJS.

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

Re: [wsjt-devel] RC3 with OmniRig


On 29/05/2020 16:54, Andy Durbin wrote:
I changed from 2.2.1 Win 64 bit to 2.2.0-rc3 Win 64 bit.   RC3 would 
not connect to OmniRig using the TS-590 file I had been using with ver 
2.2.1.  It also would not connect with the default OmniRig TS-590 file.


However, when I closed RC3 and re-started with the default OmniRig 
TS-590 file, it connected ok.  I was than able to change OmniRig back 
to the revised TS-590 rig file.  Shut down and re-start of RC3 gave a 
normal connection to OmniRig.


It would appear there is an OmniRig connection problem the first time 
RC3 is run after installation.  The problem was not reproduced by 
stopping RC3, starting 2.2.1, stopping 2.2.1, starting RC3.


While investigating the OmniRig connection problem I intentionally set 
RC3 to use OmniRig Rig 2 which is not defined.  This gave an RC3 error 
- "wsjt-x.exe has stopped working".  This appears to be repeatable as 
follows:


Configure RC3 to use a valid OmniRig Rig 1 configuration
Verify normal rig connection
Select an undefined OmniRig Rig 2 - observe "Rig control error" 
followed immediately by "wsjt-x has stopped working"

Select "close program"
Restart RC3 - program does not shut down and Rig 1 can be selected
Re-select an undefined OmniRig Rig 2 - observe "Rig control error" 
followed immediately by "wsjt-x has stopped working"


The previously reported problem that my TS-590S is set to the wrong 
frequency when WSJT starts is still present in RC3. (frequency 
resolution test leaves TS-590 on wrong frequency).


73,
Andy, k3wyc


Hi Andy,

thanks for the issue reports. There have been minor changes to the 
WSJT-X Omni-Rig interface, they were to fail more gracefully on systems 
where Omni-Rig is not installed. It would seem that has caused some 
issues with talking to Omni-Rig with no rig file selected. I'll see if I 
can reproduce that here and sort it out.


73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJT-X 2.2.0-rc3 rigctld-wsjtx still not working with IC7300 or IC703


On 29/05/2020 17:11, Black Michael via wsjt-devel wrote:

What do you get from these commands?

ldd rigctld-wsjtx | grep hamlib
ldd wsjtx | grep hamlib

Mike W9MDB


Mike,

that won't tell you  anything as in both cases Hamlib is statically linked.

73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X 2.2.0-rc3 rigctld-wsjtx still not working with IC7300 or IC703

2020-05-29 Thread Black Michael via wsjt-devel

What do you get from these commands?
ldd rigctld-wsjtx | grep hamlibldd wsjtx | grep hamlib
Mike W9MDB


 

On Friday, May 29, 2020, 10:43:10 AM CDT, Kari  wrote:  
 
   Hello,

I'm still getting "Feature not available while getting current VFO" error
on my Ubuntu 18.04.4 LTS systmem(s) when trying to use "rigctld-wsjtx"
with either IC7300 or IC-703 rigs.

73's de Kari, oh2gqc

IC7300 trace below:

karza@carole:~/ham/wsjtx/wsjtx220-rc3/bin$ ./rigctld-wsjtx  -m 3073 -r 
/dev/ic7300 -s 19200  -v
main: #1 vfo_mode=0
Recommend using --vfo switch for rigctld if client supports it
rigctl and netrigctl will automatically detect vfo mode
rigctld Hamlib 4.0~git
Last commit was Thu May 28 20:30:08 2020 +0100
Report bugs to 

rig_init called
initrigs4_icom: _init called
rig_register called
rig_register: rig_register (3055)
rig_register called
rig_register: rig_register (3009)
rig_register called
rig_register: rig_register (3010)
rig_register called
rig_register: rig_register (3011)
rig_register called
rig_register: rig_register (3013)
rig_register called
rig_register: rig_register (3014)
rig_register called
rig_register: rig_register (3015)
rig_register called
rig_register: rig_register (3019)
rig_register called
rig_register: rig_register (3020)
rig_register called
rig_register: rig_register (3021)
rig_register called
rig_register: rig_register (3022)
rig_register called
rig_register: rig_register (3067)
rig_register called
rig_register: rig_register (3023)
rig_register called
rig_register: rig_register (3046)
rig_register called
rig_register: rig_register (3024)
rig_register called
rig_register: rig_register (3028)
rig_register called
rig_register: rig_register (3030)
rig_register called
rig_register: rig_register (3026)
rig_register called
rig_register: rig_register (3027)
rig_register called
rig_register: rig_register (3047)
rig_register called
rig_register: rig_register (3057)
rig_register called
rig_register: rig_register (3063)
rig_register called
rig_register: rig_register (3029)
rig_register called
rig_register: rig_register (3062)
rig_register called
rig_register: rig_register (3045)
rig_register called
rig_register: rig_register (3056)
rig_register called
rig_register: rig_register (3075)
rig_register called
rig_register: rig_register (3060)
rig_register called
rig_register: rig_register (3070)
rig_register called
rig_register: rig_register (3061)
rig_register called
rig_register: rig_register (3073)
rig_register called
rig_register: rig_register (3078)
rig_register called
rig_register: rig_register (3031)
rig_register called
rig_register: rig_register (3012)
rig_register called
rig_register: rig_register (3016)
rig_register called
rig_register: rig_register (3032)
rig_register called
rig_register: rig_register (3034)
rig_register called
rig_register: rig_register (3044)
rig_register called
rig_register: rig_register (3068)
rig_register called
rig_register: rig_register (3035)
rig_register called
rig_register: rig_register (3081)
rig_register called
rig_register: rig_register (3069)
rig_register called
rig_register: rig_register (3077)
rig_register called
rig_register: rig_register (3036)
rig_register called
rig_register: rig_register (3058)
rig_register called
rig_register: rig_register (3080)
rig_register called
rig_register: rig_register (3037)
rig_register called
rig_register: rig_register (3038)
rig_register called
rig_register: rig_register (3039)
rig_register called
rig_register: rig_register (3040)
rig_register called
rig_register: rig_register (3041)
rig_register called
rig_register: rig_register (3042)
rig_register called
rig_register: rig_register (3079)
rig_register called
rig_register: rig_register (3043)
rig_register called
rig_register: rig_register (3066)
rig_register called
rig_register: rig_register (3003)
rig_register called
rig_register: rig_register (3004)
rig_register called
rig_register: rig_register (3006)
rig_register called
rig_register: rig_register (3007)
rig_register called
rig_register: rig_register (3002)
rig_register called
rig_register: rig_register (3052)
rig_register called
rig_register: rig_register (3053)
rig_register called
rig_register: rig_register (3051)
rig_register called
rig_register: rig_register (3064)
rig_register called
rig_register: rig_register (3065)
rig_register called
rig_register: rig_register (3054)
rig_register called
rig_register: rig_register (3083)
rig_register called
rig_register: rig_register (3084)
rig_register called
rig_register: rig_register (3082)
rig_register called
rig_register: rig_register (3071)
rig_register called
rig_register: rig_register (3072)
rig_register called
rig_register: rig_register (3074)
rig_register called
rig_register: rig_register (3076)
icom_init called
icom_init: done
rig_open called
port_open called
serial_open called
serial_open: OPEN before
serial_open: OPEN after
serial_open: serial_setup before
serial_setup called
serial_setup: tcgetattr
serial_setup: cfmakeraw
serial_setup: cfsetispeed
serial_setup:

[wsjt-devel] RC3 with OmniRig

2020-05-29 Thread Andy Durbin

I changed from 2.2.1 Win 64 bit to 2.2.0-rc3 Win 64 bit.   RC3 would not 
connect to OmniRig using the TS-590 file I had been using with ver 2.2.1.  It 
also would not connect with the default OmniRig TS-590 file.

However, when I closed RC3 and re-started with the default OmniRig TS-590 file, 
it connected ok.  I was than able to change OmniRig back to the revised TS-590 
rig file.  Shut down and re-start of RC3 gave a normal connection to OmniRig.

It would appear there is an OmniRig connection problem the first time RC3 is 
run after installation.  The problem was not reproduced by stopping RC3, 
starting 2.2.1, stopping 2.2.1, starting RC3.

While investigating the OmniRig connection problem I intentionally set RC3 to 
use OmniRig Rig 2 which is not defined.  This gave an RC3 error - "wsjt-x.exe 
has stopped working".  This appears to be repeatable as follows:

Configure RC3 to use a valid OmniRig Rig 1 configuration
Verify normal rig connection
Select an undefined OmniRig Rig 2 - observe "Rig control error" followed 
immediately by "wsjt-x has stopped working"
Select "close program"
Restart RC3 - program does not shut down and Rig 1 can be selected
Re-select an undefined OmniRig Rig 2 - observe "Rig control error" followed 
immediately by "wsjt-x has stopped working"

The previously reported problem that my TS-590S is set to the wrong frequency 
when WSJT starts is still present in RC3. (frequency resolution test leaves 
TS-590 on wrong frequency).

73,
Andy, k3wyc






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

Re: [wsjt-devel] WSJT-X 2.2.0-rc3 rigctld-wsjtx still not working with IC7300 or IC703


On 29/05/2020 16:37, Kari wrote:

Hello,

I'm still getting "Feature not available while getting current VFO" error
on my Ubuntu 18.04.4 LTS systmem(s) when trying to use "rigctld-wsjtx"
with either IC7300 or IC-703 rigs.

73's de Kari, oh2gqc


Hi Kari,

you report and others seem to conform that there are still some 
regression issues in the Hamlib library for some Icom rigs. Looking into 
it now, thanks for the issue report.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Corrupted WSJT-X.ini file

Joe,

The advice that you have issued is against what any academic or trade educator 
would EVER recommend as sound practise to our trainees / clients / researchers 
etc. 

One always starts with a clean slate and then introduces changes - especially 
when testing and evaluating. That is "Scientific Method".

Yes in the case of WSJTX your advice is noted; advisories in release notes as 
to whether configuration files may need to be altered may be appreciated in the 
future by many :-)

As I said in my post "It’s a reminder  " .  Let's leave the discussion at 
this on that subject as no good for The HAM community can come from it !

Keep up the great work with the software. 73.

Steve I
VK3VM / VK3SIR

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

[wsjt-devel] WSJT-X 2.2.0-rc3 rigctld-wsjtx still not working with IC7300 or IC703

2020-05-29 Thread Kari


Hello,

I'm still getting "Feature not available while getting current VFO" error
on my Ubuntu 18.04.4 LTS systmem(s) when trying to use "rigctld-wsjtx"
with either IC7300 or IC-703 rigs.

73's de Kari, oh2gqc

IC7300 trace below:

karza@carole:~/ham/wsjtx/wsjtx220-rc3/bin$ ./rigctld-wsjtx  -m 3073 -r 
/dev/ic7300 -s 19200  -v
main: #1 vfo_mode=0
Recommend using --vfo switch for rigctld if client supports it
rigctl and netrigctl will automatically detect vfo mode
rigctld Hamlib 4.0~git
Last commit was Thu May 28 20:30:08 2020 +0100
Report bugs to 

rig_init called
initrigs4_icom: _init called
rig_register called
rig_register: rig_register (3055)
rig_register called
rig_register: rig_register (3009)
rig_register called
rig_register: rig_register (3010)
rig_register called
rig_register: rig_register (3011)
rig_register called
rig_register: rig_register (3013)
rig_register called
rig_register: rig_register (3014)
rig_register called
rig_register: rig_register (3015)
rig_register called
rig_register: rig_register (3019)
rig_register called
rig_register: rig_register (3020)
rig_register called
rig_register: rig_register (3021)
rig_register called
rig_register: rig_register (3022)
rig_register called
rig_register: rig_register (3067)
rig_register called
rig_register: rig_register (3023)
rig_register called
rig_register: rig_register (3046)
rig_register called
rig_register: rig_register (3024)
rig_register called
rig_register: rig_register (3028)
rig_register called
rig_register: rig_register (3030)
rig_register called
rig_register: rig_register (3026)
rig_register called
rig_register: rig_register (3027)
rig_register called
rig_register: rig_register (3047)
rig_register called
rig_register: rig_register (3057)
rig_register called
rig_register: rig_register (3063)
rig_register called
rig_register: rig_register (3029)
rig_register called
rig_register: rig_register (3062)
rig_register called
rig_register: rig_register (3045)
rig_register called
rig_register: rig_register (3056)
rig_register called
rig_register: rig_register (3075)
rig_register called
rig_register: rig_register (3060)
rig_register called
rig_register: rig_register (3070)
rig_register called
rig_register: rig_register (3061)
rig_register called
rig_register: rig_register (3073)
rig_register called
rig_register: rig_register (3078)
rig_register called
rig_register: rig_register (3031)
rig_register called
rig_register: rig_register (3012)
rig_register called
rig_register: rig_register (3016)
rig_register called
rig_register: rig_register (3032)
rig_register called
rig_register: rig_register (3034)
rig_register called
rig_register: rig_register (3044)
rig_register called
rig_register: rig_register (3068)
rig_register called
rig_register: rig_register (3035)
rig_register called
rig_register: rig_register (3081)
rig_register called
rig_register: rig_register (3069)
rig_register called
rig_register: rig_register (3077)
rig_register called
rig_register: rig_register (3036)
rig_register called
rig_register: rig_register (3058)
rig_register called
rig_register: rig_register (3080)
rig_register called
rig_register: rig_register (3037)
rig_register called
rig_register: rig_register (3038)
rig_register called
rig_register: rig_register (3039)
rig_register called
rig_register: rig_register (3040)
rig_register called
rig_register: rig_register (3041)
rig_register called
rig_register: rig_register (3042)
rig_register called
rig_register: rig_register (3079)
rig_register called
rig_register: rig_register (3043)
rig_register called
rig_register: rig_register (3066)
rig_register called
rig_register: rig_register (3003)
rig_register called
rig_register: rig_register (3004)
rig_register called
rig_register: rig_register (3006)
rig_register called
rig_register: rig_register (3007)
rig_register called
rig_register: rig_register (3002)
rig_register called
rig_register: rig_register (3052)
rig_register called
rig_register: rig_register (3053)
rig_register called
rig_register: rig_register (3051)
rig_register called
rig_register: rig_register (3064)
rig_register called
rig_register: rig_register (3065)
rig_register called
rig_register: rig_register (3054)
rig_register called
rig_register: rig_register (3083)
rig_register called
rig_register: rig_register (3084)
rig_register called
rig_register: rig_register (3082)
rig_register called
rig_register: rig_register (3071)
rig_register called
rig_register: rig_register (3072)
rig_register called
rig_register: rig_register (3074)
rig_register called
rig_register: rig_register (3076)
icom_init called
icom_init: done
rig_open called
port_open called
serial_open called
serial_open: OPEN before
serial_open: OPEN after
serial_open: serial_setup before
serial_setup called
serial_setup: tcgetattr
serial_setup: cfmakeraw
serial_setup: cfsetispeed
serial_setup: cfsetospeed
serial_setup: tcsetattr TCSANOW
serial_open: serial_setup after
serial_open: serial_flush before
serial_flush called
serial_flush: tcflush
serial_open: serial_flush

Re: [wsjt-devel] WSJT-X 2.2.0-rc3


On 29/05/2020 16:07, Sam W2JDB via wsjt-devel wrote:

Hi Joe,

Just downloaded  RC3. Restoring minimized windows works. Thanks.
Minor bug, Started WSJTX rc3. Radio (power) was not on. Canceled WSJTX.
Turned on the radio. Started WSJTX rc3, brought up settings screen, 
changed input, output from default to USB, clicked Ok. Input was 
working properly, saw signals on waterfall and with proper decoding. 
Output went to PC speakers. Shut down WSJT-X rc3. Brought it up again 
and both input and output worked properly.


Using Win10/64,  WSJT-X/32

Hope this is the only bug report you get between now and GA release.

Great job and many thanks.

Stay safe and healthy.

73,

Sam W2JDB



Hi Sam,

thanks for the comments. It is becoming obvious that ongoing or pending 
Windows updates are often a source of misbehaving audio configurations. 
A reboot often sorts things out although you may find that you have to 
reconfigure the audio device settings in WSJT-X after the Windows update 
has completed.


73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJT-X 2.2.0-rc3

2020-05-29 Thread Sam W2JDB via wsjt-devel

Hi Joe,
Just downloaded  RC3. Restoring minimized windows works. Thanks.Minor bug, 
Started WSJTX rc3. Radio (power) was not on. Canceled WSJTX.Turned on the 
radio. Started WSJTX rc3, brought up settings screen, changed input, output 
from default to USB, clicked Ok. Input was working properly, saw signals on 
waterfall and with proper decoding. Output went to PC speakers. Shut down 
WSJT-X rc3. Brought it up again and both input and output worked properly. 
Using Win10/64,  WSJT-X/32 
Hope this is the only bug report you get between now and GA release.
Great job and many thanks.
Stay safe and healthy.   

73,

Sam W2JDB

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

Re: [wsjt-devel] Corrupted WSJT-X.ini file


On 29/05/2020 15:20, David Reinhart wrote:

Hello,

I tried to put in a bug report earlier about a problem I and a lot of 
others are having with the software just stopping to decode with no 
apparent reason. Good thing it was rejected because the membership 
list hadn't caught up, because I found out what's going on.


One of the things I did was reinstall the SW, but when I launched it I 
noticed the settings hadn't changed. That jingled a bell (eventually) 
from my years in SW test, so I went back and renamed the .ini file, 
started the program up, and put in my configuration information. 
Bingo, it worked.


I am attaching the bad .ini file and my current one. If I was running 
Linux and had diff I'd compare them myself, but I'm not.


David Reinhart, W4DSR 


Hi David,

please do not attribute your setup issues with other reports of issues 
without any evidence they are related.


Your settings file is not corrupt, I suggest you restore it and then 
consider the following settings issues:


 * Your Tx audio device is the Windows default audio device, that is
   rarely a correct choice
 * Your "Menu->Decode" depth setting is "Normal", unless you have a
   slow CPU you might consider using "Deep"
 * You have the "Ref Spec" option checked on the Wide Graph window
   controls, unless you have recorded a reference spectrum that will
   not be a correct setting.

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

Re: [wsjt-devel] WSJT-X 2.2.0-rc3

Bill,

Thanks for the comments ... still working here on a Ubuntu 20.04 release

> Note that the LTS releases of Qt have little bearing on Qt open source users 
> since for them support always ends at the date of the next release. 

All Noted and :-)

BUT we are aware of some grief across toolkit versions; You have identified an 
issue with code portability with the 5.14.x stream and MacOS; Qt 5.13 has 
general issues with what we do with Windows... and despite what many say Qt 
Version 5.5 and 5.9 of the past set different sound-card levels on many 
machines (and I have proved this multiple times in the past) !

Therefore perhaps the best strategy is only to release to the latest and best 
LTE releases that obviously commercial users have had extensive feedback into?

It makes life s much easier for us all to standardise to the same toolsets. 
Many times the problems are NOT our software - but it's the toolkits themselves 
! 

Yet likewise we cannot remain static and held to one toolset as technology and 
library efficiencies often do improve (i.e. Hamlib !!!). The Linux kernel 
integration into the Windows 20.1 (and I am looking into that now) is going to 
have massive benefits for our projects and their portability !

That's my thoughts anyway. 

73 and back here to multiple projects while I cannot sleep !

Steve I
VK3VM / VK3SIR



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

Re: [wsjt-devel] Corrupted WSJT-X.ini file


On 5/29/2020 11:00 AM, Stephen VK3SIR wrote:

It’s a good reminder for us all... New software versions (and especially JT-software) 
should start with a fresh, clean wsjtx.ini file. Yes we get used to our screen settings 
etc... but once the new "default" wsjtx.ini file is in place we can cut and 
paste across identical settings as long as they are in similar formats.


This statement is NOT correct.

In general there is usually no need to start with default settings. 
Installing and starting a new release of WSJT-X will automatically carry 
forward all of your customary Settings and Configurations.


-- 73, Joe, K1JT


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

Re: [wsjt-devel] Corrupted WSJT-X.ini file

David,

It’s a good reminder for us all... New software versions (and especially 
JT-software) should start with a fresh, clean wsjtx.ini file. Yes we get used 
to our screen settings etc... but once the new "default" wsjtx.ini file is in 
place we can cut and paste across identical settings as long as they are in 
similar formats.

73

Steve I
VK3VM / VK3SIR

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

Re: [wsjt-devel] WSJT-X 2.2.0-rc3

On 29/05/2020 15:07, Stephen VK3SIR wrote:

Joe, Bill and Steve,

A great job with rc3 ! It compiles almost without message under the Windows 3.1
x64 JTSDK. I have yet to test it with the Ubuntu 20.04 LTE release yet.

Also I note the comments regarding releasing code under Qt 5.12.8 - required due to Mac-deployment
issues. Qt 5.12.8 is the most "mature" version of the Long Term Supported Qt SDK's; in
addition many distros such as Ubuntu (in their just released 20.04 LTE stream) release packages
"native" for Qt 5.12.8 are supplied.

Therefore perhaps Qt 5.12.8 (or its successor in the 5.12 line) as standard
should be used for current releases?

As information for many here, the Qt 5.15. stream has just been released. From
a Windows perspective the main change for us that I can see at this point is to
the deployed MingW environ with it being upgraded from Version 7.30 to 8.10. I
am yet to fully test these changes (that will flow into Qt v6 which has also
just been announced) along with integration with the MSYS2-environment-build
Hamlib (though I can foresee few issues).

Again well done team. I am testing on-air (40m) now.

Steve I
VK3VM / VK3SIR

Hi Steve,

thanks for your comments.

Note that the LTS releases of Qt have little bearing on Qt open source
users since for them support always ends at the date of the next
release. The only benefit of the LTS release numbers for Qt open source
users is that it is a little more likely that defect repairs fixed in
later releases might be back ported to an older LTS release number, but
even then they would also be back ported to any current intermediate
releases as well.

73
Bill
G4WJS.

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

[wsjt-devel] RC2 ft8 Decode freeze up

2020-05-29 Thread Al


(2.2.0-rc2 )

With RC2 I have been having random(?) cases where the Decode button 
hangs up highlighted in blue.
The wide graph is still active but there are no further decodes and GUI 
inputs are unresponsive.

Requires closing and restarting WSJT-X to recover.
Most of there freezes have happened while monitoring 6m when there was 
little or no activity and were not noticed until after the fact.

I did have one of these events while I was actively engaged in 20m qso's.

more details if you wish.

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

[wsjt-devel] Corrupted WSJT-X.ini file

2020-05-29 Thread David Reinhart


Hello,

I tried to put in a bug report earlier about a problem I and a lot of 
others are having with the software just stopping to decode with no 
apparent reason. Good thing it was rejected because the membership list 
hadn't caught up, because I found out what's going on.


One of the things I did was reinstall the SW, but when I launched it I 
noticed the settings hadn't changed. That jingled a bell (eventually) 
from my years in SW test, so I went back and renamed the .ini file, 
started the program up, and put in my configuration information. Bingo, 
it worked.


I am attaching the bad .ini file and my current one. If I was running 
Linux and had diff I'd compare them myself, but I'm not.


David Reinhart, W4DSR

[Configuration]
window\geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x3\0\0\0\0\0}\0\0\0\x1f\0\0\x2\xa6\0\0\x2Q\0\0\0}\0\0\0\x1f\0\0\x2\xa6\0\0\x2Q\0\0\0\0\0\0\0\0\x5\0\0\0\0}\0\0\0\x1f\0\0\x2\xa6\0\0\x2Q)
MyCall=W4DSR
MyGrid=FM17OI
Field_Day_Exchange=
RTTY_Exchange=
Font="MS Shell Dlg 2,8.25,-1,5,50,0,0,0,0,0"
DecodedTextFont="Courier,10,-1,5,50,0,0,0,0,0"
IDint=0
nTrials=6
TxDelay=0.2
Aggressive=0
RxBandwidth=2500
PTTMethod=@Variant(\0\0\0\x7f\0\0\0\x1eTransceiverFactory::PTTMethod\0\0\0\0\xfPTT_method_CAT\0)
PTTport=COM5
SaveDir=C:/Users/w4dsr/AppData/Local/WSJT-X/save
AzElDir=C:/Users/w4dsr/AppData/Local/WSJT-X
SoundInName=Microphone (USB Audio CODEC )
SoundOutName=Speakers (USB Audio CODEC )
AudioInputChannel=Mono
AudioOutputChannel=Both
Type2MsgGen=@Variant(\0\0\0\x7f\0\0\0\x1b\x43onfiguration::Type2MsgGen\0\0\0\0\x12type_2_msg_3_full\0)
MonitorOFF=false
MonitorLastUsed=false
PSKReporter=false
After73=false
TxQSYAllowed=false
Macros=TNX 73 GL
FrequenciesForRegionModes="@Variant(\0\0\0\x7f\0\0\0!FrequencyList_v2::FrequencyItems\0\0\0\0\x84\0\0\0\0\0\x3\x5p\0\0\0\bFreqCal\0\0\0\0\x3R1\0\0\0\0\0\0L;\xa0\0\0\0\bFreqCal\0\0\0\0\x3R1\0\0\0\0\0\0\x98\x86\xe0\0\0\0\bFreqCal\0\0\0\0\x3R1\0\0\0\0\0\0\xe4\xd2
 \0\0\0\bFreqCal\0\0\0\0\x3R1\0\0\0\0\0\0\n\x12 
\0\0\0\bFreqCal\0\0\0\0\x3R2\0\0\0\0\0\0\rm\x80\0\0\0\bFreqCal\0\0\0\0\x3R2\0\0\0\0\0\0\x12v\x90\0\0\0\bFreqCal\0\0\0\0\x3R2\0\0\0\0\0\0&%\xa0\0\0\0\bFreqCal\0\0\0\0\x4\x41LL\0\0\0\0\0\0\x32\xcf\xd0\0\0\0\bFreqCal\0\0\0\0\x4\x41LL\0\0\0\0\0\0LK@\0\0\0\bFreqCal\0\0\0\0\x4\x41LL\0\0\0\0\0\0w\xc8\x10\0\0\0\bFreqCal\0\0\0\0\x4\x41LL\0\0\0\0\0\0\x98\x96\x80\0\0\0\bFreqCal\0\0\0\0\x4\x41LL\0\0\0\0\0\0\xdf\xd8\xb0\0\0\0\bFreqCal\0\0\0\0\x4\x41LL\0\0\0\0\0\0\xe4\xe1\xc0\0\0\0\bFreqCal\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\x31-\0\0\0\0\bFreqCal\0\0\0\0\x4\x41LL\0\0\0\0\0\0\x2\x13@\0\0\0\x5WSPR\0\0\0\0\x4\x41LL\0\0\0\0\0\0\x2\x13\xc2\0\0\0\x5JT65\0\0\0\0\x4\x41LL\0\0\0\0\0\0\x2\x13\xc2\0\0\0\x4JT9\0\0\0\0\x4\x41LL\0\0\0\0\0\0\a\xc0\0\0\0\x4JT9\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\x14>\xc0\0\0\0\x4\x46T4\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\x14\x41\x18\0\0\0\x5WSPR\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\x41\x90P\0\0\0\x4\x46T8\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\x41\x98
 
\0\0\0\x5JT65\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\x41\x9f\xf0\0\0\0\x4JT9\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\x41\xe0\xc8\0\0\0\x5WSPR\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\x42\x92
 
\0\0\0\x4\x46T4\0\0\0\0\x4\x41LL\0\0\0\0\0\x1|,8\0\0\0\x4\x46T8\0\0\0\0\x4\x41LL\0\0\0\0\0\x1|4\b\0\0\0\x5JT65\0\0\0\0\x4\x41LL\0\0\0\0\0\x1|;\xd8\0\0\0\x4JT9\0\0\0\0\x4\x41LL\0\0\0\0\0\x1|;\xd8\0\0\0\x4\x46T4\0\0\0\0\x4\x41LL\0\0\0\0\0\x1|Q\xb8\0\0\0\x5WSPR\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\xac`\x10\0\0\0\x4\x46T8\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\xacg\xe0\0\0\0\x5JT65\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\xaco\xb0\0\0\0\x4JT9\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\xad%\xb8\0\0\0\x5WSPR\0\0\0\0\x4\x41LL\0\0\0\0\0\x1\xad\xfe
 
\0\0\0\x4\x46T4\0\0\0\0\x4\x41LL\0\0\0\0\0\x2\xfd\xfd\xc0\0\0\0\x5\x45\x63ho\0\0\0\0\x4\x41LL\0\0\0\0\0\x2\xff&\xa0\0\0\0\x5JT65\0\0\0\0\x3R2\0\0\0\0\0\x2\xff&\xa0\0\0\0\x5JT65\0\0\0\0\x3R3\0\0\0\0\0\x3\0\xbc\xe0\0\0\0\aMSK144\0\0\0\0\x3R1\0\0\0\0\0\x2\xfe\xe8
 \0\0\0\aMSK144\0\0\0\0\x3R2\0\0\0\0\0\x2\xfe\xe8 
\0\0\0\aMSK144\0\0\0\0\x3R3\0\0\0\0\0\x2\xffi\b\0\0\0\x5WSPR\0\0\0\0\x3R2\0\0\0\0\0\x2\xffi\b\0\0\0\x5WSPR\0\0\0\0\x3R3\0\0\0\0\0\x2\xff\xabp\0\0\0\x5JT65\0\0\0\0\x4\x41LL\0\0\0\0\0\x2\xff\xb3@\0\0\0\x4JT9\0\0\0\0\x4\x41LL\0\0\0\0\0\x2\xff\xb7(\0\0\0\x4\x46T8\0\0\0\0\x4\x41LL\0\0\0\0\0\x2\xff\xca\xb0\0\0\0\x4\x46T4\0\0\0\0\x4\x41LL\0\0\0\0\0\x2\xff\xde\x38\0\0\0\x4\x46T8\0\0\0\0\x4\x41LL\0\0\0\0\0\x4-\xa4

Re: [wsjt-devel] WSJT-X 2.2.0-rc3

Joe, Bill and Steve,

A great job with rc3 ! It compiles almost without message under the Windows 3.1 
x64 JTSDK. I have yet to test it with the Ubuntu 20.04 LTE release yet.

Also I note the comments regarding releasing code under Qt 5.12.8  - required 
due to Mac-deployment issues. Qt 5.12.8 is the most "mature" version of the 
Long Term Supported Qt SDK's; in addition many distros such as Ubuntu (in their 
just released 20.04 LTE stream) release packages "native" for Qt 5.12.8 are 
supplied.

Therefore perhaps Qt 5.12.8 (or its successor in the 5.12 line) as standard 
should be used for current releases?

As information for many here, the Qt 5.15. stream has just been released. From 
a Windows perspective the main change for us that I can see at this point is to 
the deployed MingW environ with it being upgraded from Version 7.30 to 8.10.  I 
am yet to fully test these changes (that will flow into Qt v6 which has also 
just been announced) along with integration with the MSYS2-environment-build 
Hamlib (though I can foresee few issues).

Again well done team. I am testing on-air (40m) now.

73

Steve I
VK3VM / VK3SIR


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

Re: [wsjt-devel] WSJT-X 2.2.0-rc3


Hi John,

the documentation is correct. For v2.2.0 RC1 & RC2 we use Qt v5.14, but 
proved to be premature and a couple of issues forced us to revert to 
using Qt v5.12. That has allowed macOS 10.12 back in as a supported 
platform, for now.


73
Bill
G4WJS.

On 29/05/2020 14:33, Joe Taylor wrote:

Hi John,

Please check with Bill.  He believes RC3 should be OK on macOS 10.12.

-- Joe

On 5/29/2020 9:30 AM, John Nelson via wsjt-devel wrote:

Hi Joe,

Thanks for rc3.   The web-site reports:

*Version 2.2.0-rc3 for macOS 10.12 and 
newer: wsjtx-2.2.0-rc3-Darwin.dmg*

*
*
Should this refer to 10.13 and newer to avoid confusion. 
  wsjtx-2.2.0-rc3 does not load on 10.12


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

Re: [wsjt-devel] WSJT-X 2.2.0-rc3


Hi John,

Please check with Bill.  He believes RC3 should be OK on macOS 10.12.

-- Joe

On 5/29/2020 9:30 AM, John Nelson via wsjt-devel wrote:

Hi Joe,

Thanks for rc3.   The web-site reports:

*Version 2.2.0-rc3 for macOS 10.12 and newer: wsjtx-2.2.0-rc3-Darwin.dmg*
*
*
Should this refer to 10.13 and newer to avoid confusion.   
  wsjtx-2.2.0-rc3 does not load on 10.12


— John G4KLA


___
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-X 2.2.0-rc3

2020-05-29 Thread John Nelson via wsjt-devel

Hi Joe,

Thanks for rc3.   The web-site reports:

Version 2.2.0-rc3 for macOS 10.12 and newer: wsjtx-2.2.0-rc3-Darwin.dmg

Should this refer to 10.13 and newer to avoid confusion.wsjtx-2.2.0-rc3 
does not load on 10.12

— 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] WSJT-X 2.2.0-rc3

Thanks to all who have provided reports on their testing of WSJT-X
2.2.0-rc1 and -rc2. Special thanks to Mike, W9MDB, for his dedicated
work on several Hamlib problems.

A third candidate release for WSJT-X 2.2.0, WSJT-X 2.2.0-rc3, is now
available for download and beta testing. Most users will notice very
little difference from the RC2 release. A few users affected by reported
program defects in RC2 should now find those defects corrected.

We expect that RC3 is very close to what will become the General
Availability (GA) release of WSJT-X 2.2.0. The GA release will likely
be made in the first week of June.

Be sure to read the Release Notes,
https://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt ,
which has a cumulative list of program changes.

When upgrading there is no need to uninstall a previous version or move
any files. You might want to install to a different directory from your
WSJT-X 2.1.2 installation.

Links to installation packages for Windows, Linux, and Macintosh are
available here:

http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
Scroll down to find "Candidate release: WSJT-X 2.2.0-rc3".

You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.

WSJT-X is licensed under the terms of Version 3 of the GNU General
Public License (GPL). Development of this software is a cooperative
project to which many amateur radio operators have contributed. If you
use our code, please have the courtesy to let us know about it. If you
find bugs or make improvements to the code, please report them to us in
a timely fashion.

We hope you will enjoy using this beta release of WSJT-X 2.2.0. One of
your responsibilities as a beta tester is to report bugs by following
instructions found here in the User Guide:

http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0-rc3.html#_bug_reports

-- 73 from Joe, K1JT, Steve, K9AN, and Bill, G4WJS,
for the entire WSJT Development Group

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

Re: [wsjt-devel] wsjt-x v2.2..0 rc-1 Decode locks on

2020-05-29 Thread viv



Hi Bill,
Will do and thanks for quick reply.

Best Regards

Viv





On Friday 29/05/2020 at 13:51:40, Bill Somerville  wrote:

On 29/05/2020 13:41, v...@vpwilliams.com wrote:


Hi All,
 For your information  I have experienced another example of
wsjt-x stopping decoding of incoming signals.  Wsjt-x was running for
around 3 hours.  It was being used only  to monitor with no TX
activity. Suddenly  no decodes appeared in the  window. The Decode
button was continuously lit  apart from around the 11 second mark in
each slot when it it flashes once. All the menu functions appeared to
operate as normal so the program appears to be running. Switching the
monitor  button on and off had not effect . Waterfall appears normal
during this period and  wav files were saved as normal,  At the time
it stopped wsjt was just monitoring with no operator actions .
Stopping and started wsjt cleared the problem. If I run a saved wav
file from the problem period it now decodes correctly .

PC is running Windows 10 Pro 64 bit.

This has only happened twice  in the last two weeks  during
approximately 50 hours of use. Once on rc1 and once on rc2 so a low
level issue. If  any further information would be helpful please let
me know.


Best Regards

Viv

M0IEP


Hi Viv,

when testing beta release candidates of WSJT-X you should keep up to
date with the releases, RC2 is released and RC3 will be available very
soon. We are aware of a couple of cul de sacs the FT8 decoder can get
stuck in, to help with this there is a new hotkey Alt+Z which should 
get

things going again without having to restart WSJT-X.

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] wsjt-x v2.2..0 rc-1 Decode locks on