Re: [wsjt-devel] Bug Report WSJT-X 2.7.0-RC2: Rig Control Error pops up when adjusting TX slot frequency

[Black Michael via wsjt-devel]

New hamlib for installation directions

#1 Shut down WSJTX

#2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit version of 
WSJTX -- hopefully your browser doesn't block it but may warn you multiple 
times.

If you can do a "Save As" you can save it directly in the appropriate WSJTX 
directory
C:\WSJT\WSJTX\bin and replace the libhamlib-4.dll that is there.

http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll

http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll

Linux/Unix/Mac users need to compile the latest tar file from 
http://n0nb.users.sourceforge.net
Note: If compiling on Unix-like systems please uninstall any Hamlib package you 
have before installing the new build

#3 If you don't save directly you need to open a file browser and move the file 
that way.

If you're not familiar with that here's a video on the file browser - 
https://www.youtube.com/watch?v=AyVqCJrs9dk

Once installed on Linux do "ldconfig".

rigctl --version should then show a relatively recent date of the download


Then if you still have the problem...
Please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0

C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location

For Linux put it in  
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X

For MacOS put it in
/Users/[username]/Library/Preferences
 
Restart WSJT-X and duplicate the problem.
Shut down WSJT-X

Then send me the WSJT-X_RigControl.log file
Mike W9MDB





On Monday, August 28, 2023 at 02:45:23 AM CDT, Mark Galbraith via wsjt-devel 
 wrote: 





  


When using Shift-click on the waterfall to set the TX frequency, the “Rig 
Control Error” popup is displayed.  Clicking the “Show Details…” button shows 
the following error information:


Hamlib error: port_wait_for_data_direct(733): timeout=1,0

port_wait_for_data_direct(742): timeout=1,0

read_string_generic(): RX 1 characters, direct=1

 3b ; 

newcat_set_cmd_validate: cmd validation failed, 'MD1C;'!=';', try#8

9:newcat.c(10969):newcat_set_cmd_validate returning(-8) Protocol error

 

newcat_set_cmd: set_cmd_validate failed

8:newcat.c(11010):newcat_set_cmd returning(-8) Protocol error

 

7:newcat.c(1528):newcat_set_mode returning(-8) Protocol error

 

6:rig_set_split_mode: elapsed=806ms

6:rig.c(4647):rig_set_split_mode returning(-8) Protocol error

 

5:rig_set_split_freq_mode: elapsed=911ms

5:rig.c(5022):rig_set_split_freq_mode returning(-8) Protocol error

 

Protocol error

Protocol error

while setting split TX frequency and mode

 

Timestamp: 2023-08-28T02:28:24.231Z

 

 

This error has not occurred using WSJT-X 2.6.1.  My configuration is as follows:

Radio: Yaesu FT-710

Software stack:

 
* Win4YaesuSuite (latest version)
 
* Software control of the radio.  Also provides virtual COM ports 
(using com0com) to allow additional software to access the CAT control stream.
* CAT connection to radio on COM3.  Provides CAT virtual CAT 
connections on COM7, COM9, COM11, COM13, and COM15.
* 3rd party software connections are mentioned below.  COM13 and COM15 
connections are used for unrelated programs not involved in FT8/FT4 operation.

* DXLabs Suite (latest version)
 
* Has additional software control features for the radio but lacked the 
virtual COM support.  Control program needed to support additional functions of 
the suite.
* Used for general logging and other functions.
* Connects to CAT interface on COM9

* N1MM+ (latest version)
 
* Used for contest logging.
* Connects to CAT interface on COM11

* WSJT-X
 
* Normally use 2.6.1.  Downloaded 2.7.0-RC2 to check out some of the 
new features.
* Connects to CAT interface on COM7

* JTAlert for WSJT-X (latest version)
 
* Better visual representation of decodes.


 

The DXLabs and N1MM+ portions of the stack are not involved in this error as 
they are not in the stack between WSJT-X and the radio.  They are shown for 
completeness. 

 

Please let me know if you have any questions or need more information to help 
track this down.  For now I have reverted back to v2.6.1 so I can continue 
working FT8/FT4.

 

 

73

-.. . / -- .- .-. -.- / -. --... -.-- -..

DE  MARK  N7YD

 



___
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] Bug Report WSJT-X 2.7.0-RC2: Rig Control Error pops up when adjusting TX slot frequency

[Mark Galbraith via wsjt-devel]

When using Shift-click on the waterfall to set the TX frequency, the "Rig 
Control Error" popup is displayed.  Clicking the "Show Details..." button shows 
the following error information:

Hamlib error: port_wait_for_data_direct(733): timeout=1,0
port_wait_for_data_direct(742): timeout=1,0
read_string_generic(): RX 1 characters, direct=1
 3b ;
newcat_set_cmd_validate: cmd validation failed, 'MD1C;'!=';', try#8
9:newcat.c(10969):newcat_set_cmd_validate returning(-8) Protocol error

newcat_set_cmd: set_cmd_validate failed
8:newcat.c(11010):newcat_set_cmd returning(-8) Protocol error

7:newcat.c(1528):newcat_set_mode returning(-8) Protocol error

6:rig_set_split_mode: elapsed=806ms
6:rig.c(4647):rig_set_split_mode returning(-8) Protocol error

5:rig_set_split_freq_mode: elapsed=911ms
5:rig.c(5022):rig_set_split_freq_mode returning(-8) Protocol error

Protocol error
Protocol error
while setting split TX frequency and mode

Timestamp: 2023-08-28T02:28:24.231Z


This error has not occurred using WSJT-X 2.6.1.  My configuration is as follows:

Radio: Yaesu FT-710
Software stack:

  *   Win4YaesuSuite (latest version)
 *   Software control of the radio.  Also provides virtual COM ports (using 
com0com) to allow additional software to access the CAT control stream.
 *   CAT connection to radio on COM3.  Provides CAT virtual CAT connections 
on COM7, COM9, COM11, COM13, and COM15.
 *   3rd party software connections are mentioned below.  COM13 and COM15 
connections are used for unrelated programs not involved in FT8/FT4 operation.
  *   DXLabs Suite (latest version)
 *   Has additional software control features for the radio but lacked the 
virtual COM support.  Control program needed to support additional functions of 
the suite.
 *   Used for general logging and other functions.
 *   Connects to CAT interface on COM9
  *   N1MM+ (latest version)
 *   Used for contest logging.
 *   Connects to CAT interface on COM11
  *   WSJT-X
 *   Normally use 2.6.1.  Downloaded 2.7.0-RC2 to check out some of the new 
features.
 *   Connects to CAT interface on COM7
  *   JTAlert for WSJT-X (latest version)
 *   Better visual representation of decodes.

The DXLabs and N1MM+ portions of the stack are not involved in this error as 
they are not in the stack between WSJT-X and the radio.  They are shown for 
completeness.

Please let me know if you have any questions or need more information to help 
track this down.  For now I have reverted back to v2.6.1 so I can continue 
working FT8/FT4.


73
-.. . / -- .- .-. -.- / -. --... -.-- -..
DE  MARK  N7YD

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

Re: [wsjt-devel] Bug Report

[Black Michael via wsjt-devel]

How is your shack grounded?  
You'll find some adaptors on my QRZ page which you can use that can help.In the 
FT-991A case you can use the USB A-B adaptor which will break the USB shield 
connection to the rig and then you can use a-a cables instead like USB 3.0 
cables which have better shielding.
If you would can you test to see if there is a short between pin 4 on the 
FT-991 and the shield?  Probably is shorted.  Would like to add it to my list.
Mike W9MDB

 

On Monday, May 9, 2022, 10:13:56 AM CDT, W2JDM via wsjt-devel 
 wrote:  
 
 
Perfect!
 
  
 
That seems to be the issue.  Set power down to 5W with no issues at all.  Back 
up to 50W or above, and problems again.  Ordered some ferrites and should be 
good to go!  Didn’t even think of this as I have been very careful about 
grounding everything.  Both the radio and tuner are grounded.  Proves that RF 
can leak in even in a grounded system.
 
  
 
From: David Tiller 
Date: Monday, May 9, 2022 at 10:33 AM
To: WSJT software development 
Cc: W2JDM 
Subject: Re: [wsjt-devel] Bug Report
 
  
 
Jason,
 
  
 
This sounds like a textbook example of RFI getting into your computer or USB 
cable. I had a similar issue on 80m and found that a few well-placed ferrites 
on my USB cable fixed the issue.
 
  
 
Search for "FT8 RFI" for other folks advice.
 
  
 
To verify, try transmitting into a dummy load or at _very_ low power. If it 
doesn't happen, you've proven it's due to RFI.
 
  
 



 

On May 9, 2022, at 10:25 AM, W2JDM via wsjt-devel 
 wrote:
 
  
 
 
 
WSJTX Version: 2.5.4
 
OS – Mac Monterey 12.3.1
 
Radio – Yaesu 991A
 
SiliconLabs Driver – 6.0.2 for Mac
 
 
 
When tuned to 40m (and only 40m), using FT8, the software loses CAT control 
shortly after transmitting.  The symptoms are that it will hold the transmit 
too long and eventually show ORANGE status in WSJTX.  It will reset and 
reconnect, but not after losing the QSO due to timing issues.  This occurs each 
and every time I transmit on 40m, including when using TUNE.  I want to 
emphasize that it seems to ONLY occur on 40m and not any other band.  I use 
other software that also has CAT control over the 991A and it works as designed.
 
 
 
I have also changed the mode to FT4 and 40m behaves normally.  It seems 
isolated to only when using FT8 and 40m.
 
 
 
Please let me know if you need any additional details.
 
 
 
73
 
Jason – W2JDM
 
 
 
___
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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug Report

[W2JDM via wsjt-devel]

Perfect!

That seems to be the issue.  Set power down to 5W with no issues at all.  Back 
up to 50W or above, and problems again.  Ordered some ferrites and should be 
good to go!  Didn’t even think of this as I have been very careful about 
grounding everything.  Both the radio and tuner are grounded.  Proves that RF 
can leak in even in a grounded system.

From: David Tiller 
Date: Monday, May 9, 2022 at 10:33 AM
To: WSJT software development 
Cc: W2JDM 
Subject: Re: [wsjt-devel] Bug Report

Jason,

This sounds like a textbook example of RFI getting into your computer or USB 
cable. I had a similar issue on 80m and found that a few well-placed ferrites 
on my USB cable fixed the issue.

Search for "FT8 RFI" for other folks advice.

To verify, try transmitting into a dummy load or at _very_ low power. If it 
doesn't happen, you've proven it's due to RFI.



On May 9, 2022, at 10:25 AM, W2JDM via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:


WSJTX Version: 2.5.4
OS – Mac Monterey 12.3.1
Radio – Yaesu 991A
SiliconLabs Driver – 6.0.2 for Mac

When tuned to 40m (and only 40m), using FT8, the software loses CAT control 
shortly after transmitting.  The symptoms are that it will hold the transmit 
too long and eventually show ORANGE status in WSJTX.  It will reset and 
reconnect, but not after losing the QSO due to timing issues.  This occurs each 
and every time I transmit on 40m, including when using TUNE.  I want to 
emphasize that it seems to ONLY occur on 40m and not any other band.  I use 
other software that also has CAT control over the 991A and it works as designed.

I have also changed the mode to FT4 and 40m behaves normally.  It seems 
isolated to only when using FT8 and 40m.

Please let me know if you need any additional details.

73
Jason – W2JDM

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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 Report

[Koen Bijl via wsjt-devel]

That’s a question of RFI !

Op ma 9 mei 2022 om 17:03 schreef David Tiller via wsjt-devel <
wsjt-devel@lists.sourceforge.net>

> Jason,
>
> This sounds like a textbook example of RFI getting into your computer or
> USB cable. I had a similar issue on 80m and found that a few well-placed
> ferrites on my USB cable fixed the issue.
>
> Search for "FT8 RFI" for other folks advice.
>
> To verify, try transmitting into a dummy load or at _very_ low power. If
> it doesn't happen, you've proven it's due to RFI.
>
>
> On May 9, 2022, at 10:25 AM, W2JDM via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>
> WSJTX Version: 2.5.4
> OS – Mac Monterey 12.3.1
> Radio – Yaesu 991A
> SiliconLabs Driver – 6.0.2 for Mac
>
> When tuned to 40m (and only 40m), using FT8, the software loses CAT
> control shortly after transmitting.  The symptoms are that it will hold the
> transmit too long and eventually show ORANGE status in WSJTX.  It will
> reset and reconnect, but not after losing the QSO due to timing issues.
> This occurs each and every time I transmit on 40m, including when using
> TUNE.  I want to emphasize that it seems to ONLY occur on 40m and not any
> other band.  I use other software that also has CAT control over the 991A
> and it works as designed.
>
> I have also changed the mode to FT4 and 40m behaves normally.  It seems
> isolated to only when using FT8 and 40m.
>
> Please let me know if you need any additional details.
>
> 73
> Jason – W2JDM
>
> ___
> 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
>
-- 
Koen Bijl
Goudvinkhaga 26
3993 bc Houten
The Netherlands
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug Report

[David Tiller via wsjt-devel]

Jason,

This sounds like a textbook example of RFI getting into your computer or USB 
cable. I had a similar issue on 80m and found that a few well-placed ferrites 
on my USB cable fixed the issue.

Search for "FT8 RFI" for other folks advice.

To verify, try transmitting into a dummy load or at _very_ low power. If it 
doesn't happen, you've proven it's due to RFI.


> On May 9, 2022, at 10:25 AM, W2JDM via wsjt-devel 
>  wrote:
> 
>  
> WSJTX Version: 2.5.4
> OS – Mac Monterey 12.3.1
> Radio – Yaesu 991A
> SiliconLabs Driver – 6.0.2 for Mac
>  
> When tuned to 40m (and only 40m), using FT8, the software loses CAT control 
> shortly after transmitting.  The symptoms are that it will hold the transmit 
> too long and eventually show ORANGE status in WSJTX.  It will reset and 
> reconnect, but not after losing the QSO due to timing issues.  This occurs 
> each and every time I transmit on 40m, including when using TUNE.  I want to 
> emphasize that it seems to ONLY occur on 40m and not any other band.  I use 
> other software that also has CAT control over the 991A and it works as 
> designed.
>  
> I have also changed the mode to FT4 and 40m behaves normally.  It seems 
> isolated to only when using FT8 and 40m.
>  
> Please let me know if you need any additional details.
>  
> 73
> Jason – W2JDM
>  
> ___
> 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 Report

[W2JDM via wsjt-devel]

WSJTX Version: 2.5.4
OS – Mac Monterey 12.3.1
Radio – Yaesu 991A
SiliconLabs Driver – 6.0.2 for Mac

When tuned to 40m (and only 40m), using FT8, the software loses CAT control 
shortly after transmitting.  The symptoms are that it will hold the transmit 
too long and eventually show ORANGE status in WSJTX.  It will reset and 
reconnect, but not after losing the QSO due to timing issues.  This occurs each 
and every time I transmit on 40m, including when using TUNE.  I want to 
emphasize that it seems to ONLY occur on 40m and not any other band.  I use 
other software that also has CAT control over the 991A and it works as designed.

I have also changed the mode to FT4 and 40m behaves normally.  It seems 
isolated to only when using FT8 and 40m.

Please let me know if you need any additional details.

73
Jason – W2JDM

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

Re: [wsjt-devel] Bug report from v2.4.0 on FT8 and Kenwood TS-590SG

[Bill Somerville via wsjt-devel]

Hi Marco,

thanks for the update, glad you are up and running correctly now.

73
Bill
G4WJS.

On 14/10/2021 19:23, Marco Monari via wsjt-devel wrote:

Problem solved overwriting with the new libhamlib-4.dll, many thanks!

73
Marco
IK4PLZ

On 14/10/2021 16:34, Bill Somerville via wsjt-devel wrote:

On 14/10/2021 14:25, Marco Monari via wsjt-devel wrote:

Version 2.4.0 and 2.5.0
OS: Windows 10 64 bit

All versions previous 2.4.0 work perfectly, 2.4.0 and also latest 
2.5.0 both show this problem.

Conditions: FT8 mode with a Kenwood TS-590SG
Switching between bands VFO RX frequency change correctly but TX 
frequency in VFO radio doesn't change.

Rolling back to 2.3.0 all work perfectly without settings changes.
I also tested 2.4.0 and 2.5.0 in a different PC with a clean Windows 
10 but the problem is the same.


No hurry, thanks in advance
Marco Monari (IK4PLZ) 


Hi Marco,

I am informed that this is due to a recent Hamlib regression that has 
been repaired. As you are using Windows the procedure detailed in 
this message will get you an updated version of Hamlib:


https://wsjtx.groups.io/g/main/message/29447

Please try it and let us know if it fixes the issue for you?

73
Bill
G4WJS. 


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

Re: [wsjt-devel] Bug report from v2.4.0 on FT8 and Kenwood TS-590SG

[Marco Monari via wsjt-devel]

Problem solved overwriting with the new libhamlib-4.dll, many thanks!

73
Marco
IK4PLZ

On 14/10/2021 16:34, Bill Somerville via wsjt-devel wrote:

On 14/10/2021 14:25, Marco Monari via wsjt-devel wrote:

Version 2.4.0 and 2.5.0
OS: Windows 10 64 bit

All versions previous 2.4.0 work perfectly, 2.4.0 and also latest 
2.5.0 both show this problem.

Conditions: FT8 mode with a Kenwood TS-590SG
Switching between bands VFO RX frequency change correctly but TX 
frequency in VFO radio doesn't change.

Rolling back to 2.3.0 all work perfectly without settings changes.
I also tested 2.4.0 and 2.5.0 in a different PC with a clean Windows 
10 but the problem is the same.


No hurry, thanks in advance
Marco Monari (IK4PLZ) 


Hi Marco,

I am informed that this is due to a recent Hamlib regression that has 
been repaired. As you are using Windows the procedure detailed in this 
message will get you an updated version of Hamlib:


https://wsjtx.groups.io/g/main/message/29447

Please try it and let us know if it fixes the issue for you?

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 report from v2.4.0 on FT8 and Kenwood TS-590SG

[Bill Somerville via wsjt-devel]

On 14/10/2021 14:25, Marco Monari via wsjt-devel wrote:

Version 2.4.0 and 2.5.0
OS: Windows 10 64 bit

All versions previous 2.4.0 work perfectly, 2.4.0 and also latest 
2.5.0 both show this problem.

Conditions: FT8 mode with a Kenwood TS-590SG
Switching between bands VFO RX frequency change correctly but TX 
frequency in VFO radio doesn't change.

Rolling back to 2.3.0 all work perfectly without settings changes.
I also tested 2.4.0 and 2.5.0 in a different PC with a clean Windows 
10 but the problem is the same.


No hurry, thanks in advance
Marco Monari (IK4PLZ) 


Hi Marco,

I am informed that this is due to a recent Hamlib regression that has 
been repaired. As you are using Windows the procedure detailed in this 
message will get you an updated version of Hamlib:


https://wsjtx.groups.io/g/main/message/29447

Please try it and let us know if it fixes the issue for you?

73
Bill
G4WJS.



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

[wsjt-devel] Bug report from v2.4.0 on FT8 and Kenwood TS-590SG

[Marco Monari via wsjt-devel]

Version 2.4.0 and 2.5.0
OS: Windows 10 64 bit

All versions previous 2.4.0 work perfectly, 2.4.0 and also latest 2.5.0 
both show this problem.

Conditions: FT8 mode with a Kenwood TS-590SG
Switching between bands VFO RX frequency change correctly but TX 
frequency in VFO radio doesn't change.

Rolling back to 2.3.0 all work perfectly without settings changes.
I also tested 2.4.0 and 2.5.0 in a different PC with a clean Windows 10 
but the problem is the same.


No hurry, thanks in advance
Marco Monari (IK4PLZ)



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

Re: [wsjt-devel] Bug Report

[Kari Sillanmäki via wsjt-devel]

On 11.8.2021 13.51, Jose Montano via wsjt-devel wrote:


Hi

this problem is still present, have you been able to duplicate it?


Jose, for the 'lowercase X" issue see my reply:

https://sourceforge.net/p/wsjt/mailman/message/37326983/

Have you contacted the translator???

IIRC your second issue is not a bug but a feature.

73's de Kari, oh2gqc




 Mensaje reenviado 
Asunto: Bug Report
Fecha:  Tue, 27 Jul 2021 19:37:10 -0300
De: Jose Montano 
Para:   wsjt-devel@lists.sourceforge.net



-WSJT-X 2.5.0-rc5 4030b0

-OS GNU/Linux Debian testing


-In the button "TX1" the letter "X" is lowercase.

-When I call CQ, and someone answers me, for example with a dB-19 
signal, the software responds giving the report -19, but if for some 
reason, the station does not give me my report and calls me again, and 
its signal is different, for example -15, the software does not update 
the report and continues to respond with -19, even if I double click 
on the station that is calling me.


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

[wsjt-devel] Bug Report

[Jose Montano via wsjt-devel]

Hi

this problem is still present, have you been able to duplicate it?



 Mensaje reenviado 
Asunto: Bug Report
Fecha:  Tue, 27 Jul 2021 19:37:10 -0300
De: Jose Montano 
Para:   wsjt-devel@lists.sourceforge.net



-WSJT-X 2.5.0-rc5 4030b0

-OS GNU/Linux Debian testing


-In the button "TX1" the letter "X" is lowercase.

-When I call CQ, and someone answers me, for example with a dB-19 
signal, the software responds giving the report -19, but if for some 
reason, the station does not give me my report and calls me again, and 
its signal is different, for example -15, the software does not update 
the report and continues to respond with -19, even if I double click on 
the station that is calling me.


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

Re: [wsjt-devel] Bug Report

[Kari Sillanmäki via wsjt-devel]

Hi Jose,

you did not tell us your callsign, but from the screenshot I assume you 
are using Spanish.

TxN buttons


This seems to be an translation issue.

In file "wsjtx_es.ts" we can see that the translator has translated TxN  
to TXN...


     line="1850"/>     Tx 2     TX 
2 


...except for Tx1 which is trnaslated verbatim.

     line="1958"/>     Tx 1     Tx 
1  



So you may want to take this issue up with whoever made the Spanish 
translation.



73's de Kari, oh2gqc


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

Re: [wsjt-devel] Bug Report

[Reino Talarmo via wsjt-devel]

Hi Jose,
Interesting, how you did it?
73, Reino OH3mA

>El 27/7/21 a las 19:46, Bill Somerville via wsjt-devel escribió:
>> TxN buttons



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

Re: [wsjt-devel] Bug Report

[Jose Montano via wsjt-devel]

El 27/7/21 a las 19:46, Bill Somerville via wsjt-devel escribió:

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

Re: [wsjt-devel] Bug Report

[Bill Somerville via wsjt-devel]

On 27/07/2021 23:37, Jose Montano via wsjt-devel wrote:

-WSJT-X 2.4.0+repack-1 (experimental branch)

-OS GNU/Linux Debian testing


-In the button "TX1" the letter "X" is lowercase.

-When I call CQ, and someone answers me, for example with a dB-19 
signal, the software responds giving the report -19, but if for some 
reason, the station does not give me my report and calls me again, and 
its signal is different, for example -15, the software does not update 
the report and continues to respond with -19, even if I double click 
on the station that is calling me. 


Hi Jose,

all the TxN buttons have a lowercase 'x'.

Reports are now fixed when first sent, this is important to facilitate 
message averaging.


73
Bill
G4WJS.



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

[wsjt-devel] Bug Report

[Jose Montano via wsjt-devel]

-WSJT-X 2.4.0+repack-1 (experimental branch)

-OS GNU/Linux Debian testing


-In the button "TX1" the letter "X" is lowercase.

-When I call CQ, and someone answers me, for example with a dB-19 
signal, the software responds giving the report -19, but if for some 
reason, the station does not give me my report and calls me again, and 
its signal is different, for example -15, the software does not update 
the report and continues to respond with -19, even if I double click on 
the station that is calling me.




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

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Mike Cizek W0VTT]

Thanks Mike.  I’ll install it, play with it and get back to you some time 
tomorrow.

 



73,

Mike Cizek W0VTT

 

From: Black Michael via wsjt-devel  
Sent: Saturday, 20 March, 2021 16:19
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Try this one please...your K3S is taking a long time to recognize a PTT change 
so I'm disabling the ptt confirmation.

That should take it back to the 2.3.0 status.

 

https://www.dropbox.com/s/xhaaaikqsfulykn/wsjtx-2.4.0-rc3-win64.exe?dl=0

 

 

 

 

On Saturday, March 20, 2021, 10:28:11 AM CDT, Mike Cizek WØVTT 
mailto:mgci...@gmail.com> > wrote: 

 

 

Further testing with the version Mike W9MDB sent me the other day:

 

Split Operation > Fake It still does not work correctly.  Examples:

FT8 - transmit dF 2000Hz; radio moves up 1 kHz to transmit (should only go up 
500 Hz?), but down only 500 Hz each cycle

MSK144 - calling CQ 263, starts out OK, reverts to all .260 after a few cycles.

 

Split Operation > Rig works correctly, but the frequency display flashes 
between different readings (too fast to identify) at the end of each transmit 
sequence.  

 

Tried rc2 - Split Operation > Rig; freq display only flashes once before 
settling back down.

 

Re-installed v2.3.0 to confirm that it still works properly, and it does.

 

Back to v2.4.0 rc3b, the one Mike MDB sent the other day.  

Split Operation > Fake It - FT8 - if I answer a CQ and use a transmit dF that 
requires shifting my freq, it behaves properly.  If I CALL CQ with a transmit 
dF that requires a shift, the radio will move up 1 kHz to transmit, but back 
down only 500 Hz. To receive.

 

Hope this helps and doesn’t confuse things!

 

Thank you.

 

73,

Mike Cizek WØVTT





On Mar 18, 2021, at 4:55 PM, Mike Cizek W0VTT mailto:mgci...@gmail.com> > wrote:



Thanks Bill,

 

Using Split Operating > Rig seems to work fine on FT8.  I can’t find anyone on 
meteors right now to test it split on MSK144.

 

Mike W9MDB – will download and install that new version now and report back.

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville mailto:g4...@classdesign.com> > 
Sent: Thursday, 18 March, 2021 15:56
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Hi Mike,

 

thanks Mike, I asked because the K3 series have known issues with getting 
confused if they have multiple PTT sources.

 

Please try "Settings->Radio->Split Operating->Rig" and let me know if that 
improves things. If it does then I will need to get some diagnostic info from 
you to find out what is going wrong with "Fake It" split mode.

 

73
Bill
G4WJS.

 

On 18/03/2021 20:08, Mike Cizek W0VTT wrote:

Hello Bill,

 

No, there is no VOX.  PTT is provided via the USB cable.

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  <mailto:g4...@classdesign.com>  
Sent: Thursday, 18 March, 2021 11:05
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Mike,

 

it is certainly possible, but there need be no doubt. When you K3s is in USB 
DATA A mode is the VOX indicator showing on the K3s display panel?

 

73
Bill
G4WJS.

 

On 18/03/2021 15:58, Mike Cizek W0VTT wrote:

Hello Bill,

 

Highly unlikely, and maybe not possible.  The “audio” between the rig and 
computer is all digital; sound card is built in to the radio.  As noted, v2.3.0 
and earlier all worked fine.

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  <mailto:g4...@classdesign.com>  
Sent: Thursday, 18 March, 2021 10:49
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Hi Mike,

thanks for that. Could the K3s be getting PTT from another source as well, DATA 
VOX enabled for example?

 

73
Bill
G4WJS.

 

On 18/03/2021 15:44, Mike Cizek W0VTT wrote:

Hello Bill,

 

Guess I should have included all settings:

 

Baud Rate: 38400

Data Bits, stop bits, handshake: Default

PTT Method : CAT

Mode: Data/Pkt

Split Operation: Fake It

 

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  <mailto:g4...@classdesign.com>  
Sent: Thursday, 18 March, 2021 10:19
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

On 18/03/2021 15:15, Mike Cizek W0VTT wrote:

Greetings,

 

Frequency control problems in v2.4.0 rc2 and rc3. (did not try rc1)  v2.3.0 and 
earlier worked fine.

 

FT8 or Q65 – when transmitting at audio dF that requires shifting the transmit 
freq (df 2000Hz), WSJT will move the radio up 500 Hz, but does not always 
return to the original receive freq.  Radio will “walk” up (or down

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Black Michael via wsjt-devel]

Try this one please...your K3S is taking a long time to recognize a PTT change 
so I'm disabling the ptt confirmation.That should take it back to the 2.3.0 
status.
https://www.dropbox.com/s/xhaaaikqsfulykn/wsjtx-2.4.0-rc3-win64.exe?dl=0


 

On Saturday, March 20, 2021, 10:28:11 AM CDT, Mike Cizek WØVTT 
 wrote:  
 
 Further testing with the version Mike W9MDB sent me the other day:
Split Operation > Fake It still does not work correctly.  Examples:FT8 - 
transmit dF 2000Hz; radio moves up 1 kHz to transmit (should only go up 500 
Hz?), but down only 500 Hz each cycleMSK144 - calling CQ 263, starts out OK, 
reverts to all .260 after a few cycles.
Split Operation > Rig works correctly, but the frequency display flashes 
between different readings (too fast to identify) at the end of each transmit 
sequence.  
Tried rc2 - Split Operation > Rig; freq display only flashes once before 
settling back down.
Re-installed v2.3.0 to confirm that it still works properly, and it does.
Back to v2.4.0 rc3b, the one Mike MDB sent the other day.  Split Operation > 
Fake It - FT8 - if I answer a CQ and use a transmit dF that requires shifting 
my freq, it behaves properly.  If I CALL CQ with a transmit dF that requires a 
shift, the radio will move up 1 kHz to transmit, but back down only 500 Hz. To 
receive.
Hope this helps and doesn’t confuse things!
Thank you.

73,Mike Cizek WØVTT

On Mar 18, 2021, at 4:55 PM, Mike Cizek W0VTT  wrote:




Thanks Bill,

  

Using Split Operating > Rig seems to work fine on FT8.  I can’t find anyone on 
meteors right now to test it split on MSK144.

  

Mike W9MDB – will download and install that new version now and report back.

  



73,

Mike Cizek W0VTT

  

From: Bill Somerville  
Sent: Thursday, 18 March, 2021 15:56
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

  

Hi Mike,

  

thanks Mike, I asked because the K3 series have known issues with getting 
confused if they have multiple PTT sources.

  

Please try "Settings->Radio->Split Operating->Rig" and let me know if that 
improves things. If it does then I will need to get some diagnostic info from 
you to find out what is going wrong with "Fake It" split mode.

  

73
Bill
G4WJS.

  

On 18/03/2021 20:08, Mike Cizek W0VTT wrote:


Hello Bill,

 

No, there is no VOX.  PTT is provided via the USB cable.

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  
Sent: Thursday, 18 March, 2021 11:05
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Mike,

 

it is certainly possible, but there need be no doubt. When you K3s is in USB 
DATA A mode is the VOX indicator showing on the K3s display panel?

 

73
Bill
G4WJS.

 

On 18/03/2021 15:58, Mike Cizek W0VTT wrote:


Hello Bill,

 

Highly unlikely, and maybe not possible.  The “audio” between the rig and 
computer is all digital; sound card is built in to the radio.  As noted, v2.3.0 
and earlier all worked fine.

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  
Sent: Thursday, 18 March, 2021 10:49
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Hi Mike,

thanks for that. Could the K3s be getting PTT from another source as well, DATA 
VOX enabled for example?

 

73
Bill
G4WJS.

 

On 18/03/2021 15:44, Mike Cizek W0VTT wrote:


Hello Bill,

 

Guess I should have included all settings:

 

Baud Rate: 38400

Data Bits, stop bits, handshake: Default

PTT Method : CAT

Mode: Data/Pkt

Split Operation: Fake It

 

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  
Sent: Thursday, 18 March, 2021 10:19
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

On 18/03/2021 15:15, Mike Cizek W0VTT wrote:


Greetings,

 

Frequency control problems in v2.4.0 rc2 and rc3. (did not try rc1)  v2.3.0 and 
earlier worked fine.

 

FT8 or Q65 – when transmitting at audio dF that requires shifting the transmit 
freq (df 2000Hz), WSJT will move the radio up 500 Hz, but does not always 
return to the original receive freq.  Radio will “walk” up (or down) the band 
in 500 Hz steps.  I can see the freq display on the K3s flicker when changing 
from transmit to receive.

 

MSK144 – Calling CQ 266 on 50.260, the radio will sometimes behave properly, 
sometimes revert to calling and listening on 50.260.

 

WSJT-X v2.4.0 rc3; Mode = Data/Pkt; Split Operation = Fake It

Elecraft K3s with internal sound card; single USB cable for both audio and rig 
control

Lenovo ThinkpadX390; i7 CPU;  WIN10 Pro

 

Thank you.

 



73,

Mike Cizek W0VTT


Hi Mike,

which option do you have for "Settings->Radio->PTT Method"?

73
Bill
G4WJS.




  

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

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Mike Cizek WØVTT]

Further testing with the version Mike W9MDB sent me the other day:

Split Operation > Fake It still does not work correctly.  Examples:
FT8 - transmit dF 2000Hz; radio moves up 1 kHz to transmit (should only go up 
500 Hz?), but down only 500 Hz each cycle
MSK144 - calling CQ 263, starts out OK, reverts to all .260 after a few cycles.

Split Operation > Rig works correctly, but the frequency display flashes 
between different readings (too fast to identify) at the end of each transmit 
sequence.  

Tried rc2 - Split Operation > Rig; freq display only flashes once before 
settling back down.

Re-installed v2.3.0 to confirm that it still works properly, and it does.

Back to v2.4.0 rc3b, the one Mike MDB sent the other day.  
Split Operation > Fake It - FT8 - if I answer a CQ and use a transmit dF that 
requires shifting my freq, it behaves properly.  If I CALL CQ with a transmit 
dF that requires a shift, the radio will move up 1 kHz to transmit, but back 
down only 500 Hz. To receive.

Hope this helps and doesn’t confuse things!

Thank you.

73,
Mike Cizek WØVTT

> On Mar 18, 2021, at 4:55 PM, Mike Cizek W0VTT  wrote:
> 
> 
> Thanks Bill,
>  
> Using Split Operating > Rig seems to work fine on FT8.  I can’t find anyone 
> on meteors right now to test it split on MSK144.
>  
> Mike W9MDB – will download and install that new version now and report back.
>  
> 
> 73,
> Mike Cizek W0VTT
>  
> From: Bill Somerville  
> Sent: Thursday, 18 March, 2021 15:56
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control
>  
> Hi Mike,
>  
> thanks Mike, I asked because the K3 series have known issues with getting 
> confused if they have multiple PTT sources.
>  
> Please try "Settings->Radio->Split Operating->Rig" and let me know if that 
> improves things. If it does then I will need to get some diagnostic info from 
> you to find out what is going wrong with "Fake It" split mode.
>  
> 73
> Bill
> G4WJS.
>  
> On 18/03/2021 20:08, Mike Cizek W0VTT wrote:
> Hello Bill,
>  
> No, there is no VOX.  PTT is provided via the USB cable.
>  
> ----
> 73,
> Mike Cizek W0VTT
>  
> From: Bill Somerville  
> Sent: Thursday, 18 March, 2021 11:05
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control
>  
> Mike,
>  
> it is certainly possible, but there need be no doubt. When you K3s is in USB 
> DATA A mode is the VOX indicator showing on the K3s display panel?
>  
> 73
> Bill
> G4WJS.
>  
> On 18/03/2021 15:58, Mike Cizek W0VTT wrote:
> Hello Bill,
>  
> Highly unlikely, and maybe not possible.  The “audio” between the rig and 
> computer is all digital; sound card is built in to the radio.  As noted, 
> v2.3.0 and earlier all worked fine.
>  
> 
> 73,
> Mike Cizek W0VTT
>  
> From: Bill Somerville  
> Sent: Thursday, 18 March, 2021 10:49
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control
>  
> Hi Mike,
> thanks for that. Could the K3s be getting PTT from another source as well, 
> DATA VOX enabled for example?
>  
> 73
> Bill
> G4WJS.
>  
> On 18/03/2021 15:44, Mike Cizek W0VTT wrote:
> Hello Bill,
>  
> Guess I should have included all settings:
>  
> Baud Rate: 38400
> Data Bits, stop bits, handshake: Default
> PTT Method : CAT
> Mode: Data/Pkt
> Split Operation: Fake It
>  
>  
> 
> 73,
> Mike Cizek W0VTT
>  
> From: Bill Somerville  
> Sent: Thursday, 18 March, 2021 10:19
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control
>  
> On 18/03/2021 15:15, Mike Cizek W0VTT wrote:
> Greetings,
>  
> Frequency control problems in v2.4.0 rc2 and rc3. (did not try rc1)  v2.3.0 
> and earlier worked fine.
>  
> FT8 or Q65 – when transmitting at audio dF that requires shifting the 
> transmit freq (df 2000Hz), WSJT will move the radio up 500 Hz, but does not 
> always return to the original receive freq.  Radio will “walk” up (or down) 
> the band in 500 Hz steps.  I can see the freq display on the K3s flicker when 
> changing from transmit to receive.
>  
> MSK144 – Calling CQ 266 on 50.260, the radio will sometimes behave properly, 
> sometimes revert to calling and listening on 50.260.
>  
> WSJT-X v2.4.0 rc3; Mode = Data/Pkt; Split Operation = Fake It
> Elecraft K3s with internal sound card; single USB cable for both audio and 
> rig control
> Lenovo ThinkpadX390; i7 CPU;  WIN10 Pro
>  
> Thank you.
>  
> 
> 73,
> Mike Cizek W0VTT
> Hi Mike,
> 
> which option do you have for "Settings->Radio->PTT Method"?
> 
> 73
> Bill
> G4WJS.
> 
>  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Mike Cizek WØVTT]

G4WJS - Found a local to test with on MSK144.  The CQ 266 seems to work OK, but 
I still see the freq display on the K3s flicker when switching from transmit to 
receive.

W9MDB - Installed the version you sent me.  I’m calling it rc3b.  Split 
Operation > Fake It.  FT8 50.313, call CQ tx dF 2100 Hz; radio goes up to .314 
to transmit, down to 313.5 for receive.  Each time up 1 kHz, back down 500 Hz.  
Transmit dF 700 Hz; radio moves down 1 kHz, back up only 500 Hz.  Transmit dF 
1800 Hz, no freq change, but the freq display still flickers when changing from 
TX to RX.  This did not happen in v2.3.0 or earlier.
Split Operation > Rig.  Radio behaves properly but freq display still flickers 
when changing from TX to R|X.

K1JT - Hi Joe!   Still remember hoisting cold 807s with you in the hospitality 
suite at W9DXCC a few years back.  That was cool!

Once again:
K3s with internal sound card.  1 USB cable for both audio and rig control
Lenovo Thinkpad WIN10 Pro

THANK YOU!

Just decoded a CQ from Z8RRUFL09OW.  That’s some SERIOUS DX!

73,
Mike Cizek WØVTT

> On Mar 18, 2021, at 5:43 PM, Bill Somerville  wrote:
> 
> 
>> On 18/03/2021 22:25, Joe Taylor wrote:
>> Hi Mike, 
>> 
>> On 3/18/2021 5:55 PM, Mike Cizek W0VTT wrote: 
>> 
>>> Using Split Operating > Rig seems to work fine on FT8.  I can’t find anyone 
>>> on meteors right now to test it split on MSK144. 
>> 
>> "Split" is not used (and not relevant) in MS144 mode. 
>> 
>> -- Joe, K1JT
> Hi Mike, and Joe,
> 
> I will qualify that with, split is used to call for replies on a different 
> working frequency, it is not used to optimize away audio harmonics since the 
> MSK144 signal fills a typical SSB passband.
> 
> 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 Report v2.4.0 rc3 K3s Freq Control

[Bill Somerville]

On 18/03/2021 22:25, Joe Taylor wrote:

Hi Mike,

On 3/18/2021 5:55 PM, Mike Cizek W0VTT wrote:

Using Split Operating > Rig seems to work fine on FT8.  I can’t find 
anyone on meteors right now to test it split on MSK144.


"Split" is not used (and not relevant) in MS144 mode.

-- Joe, K1JT 


Hi Mike, and Joe,

I will qualify that with, split is used to call for replies on a 
different working frequency, it is not used to optimize away audio 
harmonics since the MSK144 signal fills a typical SSB passband.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Joe Taylor]

Hi Mike,

On 3/18/2021 5:55 PM, Mike Cizek W0VTT wrote:

Using Split Operating > Rig seems to work fine on FT8.  I can’t find 
anyone on meteors right now to test it split on MSK144.


"Split" is not used (and not relevant) in MS144 mode.

-- Joe, K1JT


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

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Mike Cizek W0VTT]

Thanks Bill,

 

Using Split Operating > Rig seems to work fine on FT8.  I can’t find anyone on 
meteors right now to test it split on MSK144.

 

Mike W9MDB – will download and install that new version now and report back.

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  
Sent: Thursday, 18 March, 2021 15:56
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Hi Mike,

 

thanks Mike, I asked because the K3 series have known issues with getting 
confused if they have multiple PTT sources.

 

Please try "Settings->Radio->Split Operating->Rig" and let me know if that 
improves things. If it does then I will need to get some diagnostic info from 
you to find out what is going wrong with "Fake It" split mode.

 

73
Bill
G4WJS.

 

On 18/03/2021 20:08, Mike Cizek W0VTT wrote:

Hello Bill,

 

No, there is no VOX.  PTT is provided via the USB cable.

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  <mailto:g4...@classdesign.com>  
Sent: Thursday, 18 March, 2021 11:05
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Mike,

 

it is certainly possible, but there need be no doubt. When you K3s is in USB 
DATA A mode is the VOX indicator showing on the K3s display panel?

 

73
Bill
G4WJS.

 

On 18/03/2021 15:58, Mike Cizek W0VTT wrote:

Hello Bill,

 

Highly unlikely, and maybe not possible.  The “audio” between the rig and 
computer is all digital; sound card is built in to the radio.  As noted, v2.3.0 
and earlier all worked fine.

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  <mailto:g4...@classdesign.com>  
Sent: Thursday, 18 March, 2021 10:49
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Hi Mike,

thanks for that. Could the K3s be getting PTT from another source as well, DATA 
VOX enabled for example?

 

73
Bill
G4WJS.

 

On 18/03/2021 15:44, Mike Cizek W0VTT wrote:

Hello Bill,

 

Guess I should have included all settings:

 

Baud Rate: 38400

Data Bits, stop bits, handshake: Default

PTT Method : CAT

Mode: Data/Pkt

Split Operation: Fake It

 

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  <mailto:g4...@classdesign.com>  
Sent: Thursday, 18 March, 2021 10:19
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

On 18/03/2021 15:15, Mike Cizek W0VTT wrote:

Greetings,

 

Frequency control problems in v2.4.0 rc2 and rc3. (did not try rc1)  v2.3.0 and 
earlier worked fine.

 

FT8 or Q65 – when transmitting at audio dF that requires shifting the transmit 
freq (df 2000Hz), WSJT will move the radio up 500 Hz, but does not always 
return to the original receive freq.  Radio will “walk” up (or down) the band 
in 500 Hz steps.  I can see the freq display on the K3s flicker when changing 
from transmit to receive.

 

MSK144 – Calling CQ 266 on 50.260, the radio will sometimes behave properly, 
sometimes revert to calling and listening on 50.260.

 

WSJT-X v2.4.0 rc3; Mode = Data/Pkt; Split Operation = Fake It

Elecraft K3s with internal sound card; single USB cable for both audio and rig 
control

Lenovo ThinkpadX390; i7 CPU;  WIN10 Pro

 

Thank you.

 



73,

Mike Cizek W0VTT

Hi Mike,

which option do you have for "Settings->Radio->PTT Method"?

73
Bill
G4WJS.

 

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

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Bill Somerville]

Hi Mike,

thanks Mike, I asked because the K3 series have known issues with 
getting confused if they have multiple PTT sources.


Please try "Settings->Radio->Split Operating->Rig" and let me know if 
that improves things. If it does then I will need to get some diagnostic 
info from you to find out what is going wrong with "Fake It" split mode.


73
Bill
G4WJS.

On 18/03/2021 20:08, Mike Cizek W0VTT wrote:


Hello Bill,

No, there is no VOX.  PTT is provided via the USB cable.



73,

Mike Cizek W0VTT

*From:* Bill Somerville 
*Sent:* Thursday, 18 March, 2021 11:05
*To:* wsjt-devel@lists.sourceforge.net
*Subject:* Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

Mike,

it is certainly possible, but there need be no doubt. When you K3s is 
in USB DATA A mode is the VOX indicator showing on the K3s display panel?


73
Bill
G4WJS.

On 18/03/2021 15:58, Mike Cizek W0VTT wrote:

Hello Bill,

Highly unlikely, and maybe not possible.  The “audio” between the
rig and computer is all digital; sound card is built in to the
radio.  As noted, v2.3.0 and earlier all worked fine.



73,

Mike Cizek W0VTT

*From:* Bill Somerville 
<mailto:g4...@classdesign.com>
*Sent:* Thursday, 18 March, 2021 10:49
*To:* wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
    *Subject:* Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

Hi Mike,

thanks for that. Could the K3s be getting PTT from another source
as well, DATA VOX enabled for example?

73
Bill
G4WJS.

On 18/03/2021 15:44, Mike Cizek W0VTT wrote:

Hello Bill,

Guess I should have included all settings:

Baud Rate: 38400

Data Bits, stop bits, handshake: Default

PTT Method : CAT

Mode: Data/Pkt

Split Operation: Fake It



73,

Mike Cizek W0VTT

*From:* Bill Somerville 
<mailto:g4...@classdesign.com>
*Sent:* Thursday, 18 March, 2021 10:19
*To:* wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
*Subject:* Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

On 18/03/2021 15:15, Mike Cizek W0VTT wrote:

Greetings,

Frequency control problems in v2.4.0 rc2 and rc3. (did not
try rc1) v2.3.0 and earlier worked fine.

FT8 or Q65 – when transmitting at audio dF that requires
shifting the transmit freq (df 2000Hz), WSJT will move the
radio up 500 Hz, but does not always return to the
original receive freq.  Radio will “walk” up (or down) the
band in 500 Hz steps.  I can see the freq display on the
K3s flicker when changing from transmit to receive.

MSK144 – Calling CQ 266 on 50.260, the radio will
sometimes behave properly, sometimes revert to calling and
listening on 50.260.

WSJT-X v2.4.0 rc3; Mode = Data/Pkt; Split Operation = Fake It

Elecraft K3s with internal sound card; single USB cable
for both audio and rig control

Lenovo ThinkpadX390; i7 CPU;  WIN10 Pro

Thank you.



73,

Mike Cizek W0VTT

Hi Mike,

which option do you have for "Settings->Radio->PTT Method"?

73
Bill
G4WJS.



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

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Mike Cizek W0VTT]

Hello Bill,

 

No, there is no VOX.  PTT is provided via the USB cable.

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  
Sent: Thursday, 18 March, 2021 11:05
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Mike,

 

it is certainly possible, but there need be no doubt. When you K3s is in USB 
DATA A mode is the VOX indicator showing on the K3s display panel?

 

73
Bill
G4WJS.

 

On 18/03/2021 15:58, Mike Cizek W0VTT wrote:

Hello Bill,

 

Highly unlikely, and maybe not possible.  The “audio” between the rig and 
computer is all digital; sound card is built in to the radio.  As noted, v2.3.0 
and earlier all worked fine.

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  <mailto:g4...@classdesign.com>  
Sent: Thursday, 18 March, 2021 10:49
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Hi Mike,

thanks for that. Could the K3s be getting PTT from another source as well, DATA 
VOX enabled for example?

 

73
Bill
G4WJS.

 

On 18/03/2021 15:44, Mike Cizek W0VTT wrote:

Hello Bill,

 

Guess I should have included all settings:

 

Baud Rate: 38400

Data Bits, stop bits, handshake: Default

PTT Method : CAT

Mode: Data/Pkt

Split Operation: Fake It

 

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  <mailto:g4...@classdesign.com>  
Sent: Thursday, 18 March, 2021 10:19
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

On 18/03/2021 15:15, Mike Cizek W0VTT wrote:

Greetings,

 

Frequency control problems in v2.4.0 rc2 and rc3. (did not try rc1)  v2.3.0 and 
earlier worked fine.

 

FT8 or Q65 – when transmitting at audio dF that requires shifting the transmit 
freq (df 2000Hz), WSJT will move the radio up 500 Hz, but does not always 
return to the original receive freq.  Radio will “walk” up (or down) the band 
in 500 Hz steps.  I can see the freq display on the K3s flicker when changing 
from transmit to receive.

 

MSK144 – Calling CQ 266 on 50.260, the radio will sometimes behave properly, 
sometimes revert to calling and listening on 50.260.

 

WSJT-X v2.4.0 rc3; Mode = Data/Pkt; Split Operation = Fake It

Elecraft K3s with internal sound card; single USB cable for both audio and rig 
control

Lenovo ThinkpadX390; i7 CPU;  WIN10 Pro

 

Thank you.

 



73,

Mike Cizek W0VTT

Hi Mike,

which option do you have for "Settings->Radio->PTT Method"?

73
Bill
G4WJS.

 

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

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Bill Somerville]

Mike,

it is certainly possible, but there need be no doubt. When you K3s is in 
USB DATA A mode is the VOX indicator showing on the K3s display panel?


73
Bill
G4WJS.

On 18/03/2021 15:58, Mike Cizek W0VTT wrote:


Hello Bill,

Highly unlikely, and maybe not possible.  The “audio” between the rig 
and computer is all digital; sound card is built in to the radio.  As 
noted, v2.3.0 and earlier all worked fine.




73,

Mike Cizek W0VTT

*From:* Bill Somerville 
*Sent:* Thursday, 18 March, 2021 10:49
*To:* wsjt-devel@lists.sourceforge.net
*Subject:* Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

Hi Mike,

thanks for that. Could the K3s be getting PTT from another source as 
well, DATA VOX enabled for example?


73
Bill
G4WJS.

On 18/03/2021 15:44, Mike Cizek W0VTT wrote:

Hello Bill,

Guess I should have included all settings:

Baud Rate: 38400

Data Bits, stop bits, handshake: Default

PTT Method : CAT

Mode: Data/Pkt

Split Operation: Fake It



73,

Mike Cizek W0VTT

*From:* Bill Somerville 
<mailto:g4...@classdesign.com>
*Sent:* Thursday, 18 March, 2021 10:19
*To:* wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
*Subject:* Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

On 18/03/2021 15:15, Mike Cizek W0VTT wrote:

Greetings,

Frequency control problems in v2.4.0 rc2 and rc3. (did not try
rc1) v2.3.0 and earlier worked fine.

FT8 or Q65 – when transmitting at audio dF that requires
shifting the transmit freq (df 2000Hz), WSJT will move the
radio up 500 Hz, but does not always return to the original
receive freq.  Radio will “walk” up (or down) the band in 500
Hz steps.  I can see the freq display on the K3s flicker when
changing from transmit to receive.

MSK144 – Calling CQ 266 on 50.260, the radio will sometimes
behave properly, sometimes revert to calling and listening on
50.260.

WSJT-X v2.4.0 rc3; Mode = Data/Pkt; Split Operation = Fake It

Elecraft K3s with internal sound card; single USB cable for
both audio and rig control

Lenovo ThinkpadX390; i7 CPU;  WIN10 Pro

Thank you.



73,

Mike Cizek W0VTT

Hi Mike,

which option do you have for "Settings->Radio->PTT Method"?

73
Bill
G4WJS.



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

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Mike Cizek W0VTT]

Hello Bill,

 

Highly unlikely, and maybe not possible.  The “audio” between the rig and 
computer is all digital; sound card is built in to the radio.  As noted, v2.3.0 
and earlier all worked fine.

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  
Sent: Thursday, 18 March, 2021 10:49
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

Hi Mike,

thanks for that. Could the K3s be getting PTT from another source as well, DATA 
VOX enabled for example?

 

73
Bill
G4WJS.

 

On 18/03/2021 15:44, Mike Cizek W0VTT wrote:

Hello Bill,

 

Guess I should have included all settings:

 

Baud Rate: 38400

Data Bits, stop bits, handshake: Default

PTT Method : CAT

Mode: Data/Pkt

Split Operation: Fake It

 

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  <mailto:g4...@classdesign.com>  
Sent: Thursday, 18 March, 2021 10:19
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

On 18/03/2021 15:15, Mike Cizek W0VTT wrote:

Greetings,

 

Frequency control problems in v2.4.0 rc2 and rc3. (did not try rc1)  v2.3.0 and 
earlier worked fine.

 

FT8 or Q65 – when transmitting at audio dF that requires shifting the transmit 
freq (df 2000Hz), WSJT will move the radio up 500 Hz, but does not always 
return to the original receive freq.  Radio will “walk” up (or down) the band 
in 500 Hz steps.  I can see the freq display on the K3s flicker when changing 
from transmit to receive.

 

MSK144 – Calling CQ 266 on 50.260, the radio will sometimes behave properly, 
sometimes revert to calling and listening on 50.260.

 

WSJT-X v2.4.0 rc3; Mode = Data/Pkt; Split Operation = Fake It

Elecraft K3s with internal sound card; single USB cable for both audio and rig 
control

Lenovo ThinkpadX390; i7 CPU;  WIN10 Pro

 

Thank you.

 



73,

Mike Cizek W0VTT

Hi Mike,

which option do you have for "Settings->Radio->PTT Method"?

73
Bill
G4WJS.

 

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

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Bill Somerville]

Hi Mike,
thanks for that. Could the K3s be getting PTT from another source as 
well, DATA VOX enabled for example?


73
Bill
G4WJS.

On 18/03/2021 15:44, Mike Cizek W0VTT wrote:


Hello Bill,

Guess I should have included all settings:

Baud Rate: 38400

Data Bits, stop bits, handshake: Default

PTT Method : CAT

Mode: Data/Pkt

Split Operation: Fake It



73,

Mike Cizek W0VTT

*From:* Bill Somerville 
*Sent:* Thursday, 18 March, 2021 10:19
*To:* wsjt-devel@lists.sourceforge.net
*Subject:* Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

On 18/03/2021 15:15, Mike Cizek W0VTT wrote:

Greetings,

Frequency control problems in v2.4.0 rc2 and rc3. (did not try
rc1) v2.3.0 and earlier worked fine.

FT8 or Q65 – when transmitting at audio dF that requires shifting
the transmit freq (df 2000Hz), WSJT will move the radio up 500 Hz,
but does not always return to the original receive freq. Radio
will “walk” up (or down) the band in 500 Hz steps.  I can see the
freq display on the K3s flicker when changing from transmit to
receive.

MSK144 – Calling CQ 266 on 50.260, the radio will sometimes behave
properly, sometimes revert to calling and listening on 50.260.

WSJT-X v2.4.0 rc3; Mode = Data/Pkt; Split Operation = Fake It

Elecraft K3s with internal sound card; single USB cable for both
audio and rig control

Lenovo ThinkpadX390; i7 CPU;  WIN10 Pro

Thank you.



73,

Mike Cizek W0VTT

Hi Mike,

which option do you have for "Settings->Radio->PTT Method"?

73
Bill
G4WJS.



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

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Mike Cizek W0VTT]

Hello Bill,

 

Guess I should have included all settings:

 

Baud Rate: 38400

Data Bits, stop bits, handshake: Default

PTT Method : CAT

Mode: Data/Pkt

Split Operation: Fake It

 

 



73,

Mike Cizek W0VTT

 

From: Bill Somerville  
Sent: Thursday, 18 March, 2021 10:19
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

 

On 18/03/2021 15:15, Mike Cizek W0VTT wrote:

Greetings,

 

Frequency control problems in v2.4.0 rc2 and rc3. (did not try rc1)  v2.3.0 and 
earlier worked fine.

 

FT8 or Q65 – when transmitting at audio dF that requires shifting the transmit 
freq (df 2000Hz), WSJT will move the radio up 500 Hz, but does not always 
return to the original receive freq.  Radio will “walk” up (or down) the band 
in 500 Hz steps.  I can see the freq display on the K3s flicker when changing 
from transmit to receive.

 

MSK144 – Calling CQ 266 on 50.260, the radio will sometimes behave properly, 
sometimes revert to calling and listening on 50.260.

 

WSJT-X v2.4.0 rc3; Mode = Data/Pkt; Split Operation = Fake It

Elecraft K3s with internal sound card; single USB cable for both audio and rig 
control

Lenovo ThinkpadX390; i7 CPU;  WIN10 Pro

 

Thank you.

 



73,

Mike Cizek W0VTT

Hi Mike,

which option do you have for "Settings->Radio->PTT Method"?

73
Bill
G4WJS.

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

Re: [wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Bill Somerville]

On 18/03/2021 15:15, Mike Cizek W0VTT wrote:


Greetings,

Frequency control problems in v2.4.0 rc2 and rc3. (did not try rc1)  
v2.3.0 and earlier worked fine.


FT8 or Q65 – when transmitting at audio dF that requires shifting the 
transmit freq (df 2000Hz), WSJT will move the radio up 500 Hz, but 
does not always return to the original receive freq.  Radio will 
“walk” up (or down) the band in 500 Hz steps.  I can see the freq 
display on the K3s flicker when changing from transmit to receive.


MSK144 – Calling CQ 266 on 50.260, the radio will sometimes behave 
properly, sometimes revert to calling and listening on 50.260.


WSJT-X v2.4.0 rc3; Mode = Data/Pkt; Split Operation = Fake It

Elecraft K3s with internal sound card; single USB cable for both audio 
and rig control


Lenovo ThinkpadX390; i7 CPU;  WIN10 Pro

Thank you.



73,

Mike Cizek W0VTT


Hi Mike,

which option do you have for "Settings->Radio->PTT Method"?

73
Bill
G4WJS.

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

[wsjt-devel] Bug Report v2.4.0 rc3 K3s Freq Control

[Mike Cizek W0VTT]

Greetings,

 

Frequency control problems in v2.4.0 rc2 and rc3. (did not try rc1)  v2.3.0 and 
earlier worked fine.

 

FT8 or Q65 – when transmitting at audio dF that requires shifting the transmit 
freq (df 2000Hz), WSJT will move the radio up 500 Hz, but does not always 
return to the original receive freq.  Radio will “walk” up (or down) the band 
in 500 Hz steps.  I can see the freq display on the K3s flicker when changing 
from transmit to receive.

 

MSK144 – Calling CQ 266 on 50.260, the radio will sometimes behave properly, 
sometimes revert to calling and listening on 50.260.

 

WSJT-X v2.4.0 rc3; Mode = Data/Pkt; Split Operation = Fake It

Elecraft K3s with internal sound card; single USB cable for both audio and rig 
control

Lenovo ThinkpadX390; i7 CPU;  WIN10 Pro

 

Thank you.

 



73,

Mike Cizek W0VTT

 

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

Re: [wsjt-devel] Bug report WSJT-X v2.4.0 rc1

[Bill Somerville]

On 04/02/2021 13:25, David Schmocker wrote:


Good morning:

Operating system:  Mac OS Mojave 10.14.6

Software version: WSJT-X v 2.4.0 rc1

Issue/behavior:  Program self closes (all windows) and

    Unable to move outside of 15 second 
periods for this mode


Steps required to repeat this:

 1. Launch WSJT-X
 2. Mode: select Q65
 3. Band select 6m (50.210) region 2
 4. Wide graph: select Q65_Sync option
 5. Software goes into Monitor (despite Monitor Off at startup on
general setup tab)
 6. Then just wait 30 seconds and WSJT-X Quits automatically.


Hi David,

although the symptoms are different from other reporting this sort of 
instability on macOS, I think it may be the same issue discussed in this 
post:


https://sourceforge.net/p/wsjt/mailman/message/37212133/

73
Bill
G4WJS.

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

Re: [wsjt-devel] bug report

[Bill Somerville]

On 01/02/2021 15:49, kb8u vhf wrote:
Hello, I have noticed a bug while operating FST4.  I am currently 
running v2.3.0-rc4 ef3630


To reproduce:

Make a QSO with auto sequencing enabled and RR73 configured to be 
sent.  While RR73 is being sent, select CQ Next checkbox (expecting to 
receive 73 from the other station).


After 73 is received, the sequencing incorrectly changes to send 73 
instead of sending CQ.


Russ  KB8U


Hi Russ,

what happens in that situation is determined by the "Auto Seq" check 
box, the "Settings->Reporting->Clear DX call and grid after logging". 
The "Auto Seq" behaviour will send a 73 message in response to a 73 
message unless the QSO is finished by hitting ESC or logging the QSO 
with the above setting checked.


73
Bill
G4WJS.

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

[wsjt-devel] bug report

[kb8u vhf]

Hello, I have noticed a bug while operating FST4.  I am currently running 
v2.3.0-rc4 ef3630

To reproduce:

Make a QSO with auto sequencing enabled and RR73 configured to be sent.  While 
RR73 is being sent, select CQ Next checkbox (expecting to receive 73 from the 
other station).

After 73 is received, the sequencing incorrectly changes to send 73 instead of 
sending CQ.

Russ  KB8U


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

Re: [wsjt-devel] BUG Report for WSJT-X Ver 2.2.2 - 64 bit

[bergeracb--- via wsjt-devel]

Just downloaded and installed V.2.2.2, made a contact and checked my wsjtx_log 
file.It had the correct (WSJT-X ADIF Export) header. No problem?Al, N4AB,  
73
In a message dated 6/24/2020 15:18:44 Eastern Standard Time, 
g4...@classdesign.com writes:

On 24/06/2020 19:17, Joe WA6AXE wrote:
> I need to report a BUG in the newest ver 2.2.2. (64 bit) ...
>
> When the program MAKES the wsjtx_log.adi file .. There is an ERROR in the
> beginning of the adi file ..
> The current version 2.2.2 writes:
> WSJT-X ADIF Export
> it SHOULD be written as:
> WSJT-X ADIF Export
>
>
> The  is currently shown as 
>
> This is causing some problem when 3rd party BRIDGE programs try to 
> IMPORT the INFO from the adi file ...
> Can we pse correct this?? TIA!!
>
> 73 Joe wa6axe

Hi Joe,

thanks for the issue report. I can confirm this is a defect which is 
only in v2.2.2, it is corrected for the next release. You can work 
around it by editing the wsjtx_log.adi file to correct the end of header 
marker. The header is only written when a new file is created, which 
should only be when a new installation is set up. Sorry for the 
inconvenience.

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 Report for WSJT-X Ver 2.2.2 - 64 bit

[Joe WA6AXE]

Thank YOU Bill!!  I have worked around the problem - by making my
WSJT-X BRIDGE to look for either  or  .. That cured the problem
quickly.. Tnx agn Bill!

73 Joe wa6axe


From: Bill Somerville 
Sent: Wednesday, June 24, 2020 2:15 PM
To: wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] BUG Report for WSJT-X Ver 2.2.2 - 64 bit

On 24/06/2020 19:17, Joe WA6AXE wrote:
> I need to report a BUG in the newest ver 2.2.2. (64 bit) ...
>
> When the program MAKES the wsjtx_log.adi file .. There is an ERROR in the
> beginning of the adi file ..
> The current version 2.2.2 writes:
> WSJT-X ADIF Export
> it SHOULD be written as:
> WSJT-X ADIF Export
>
>
> The  is currently shown as 
>
> This is causing some problem when 3rd party BRIDGE programs try to
> IMPORT the INFO from the adi file ...
> Can we pse correct this?? TIA!!
>
> 73 Joe wa6axe

Hi Joe,

thanks for the issue report. I can confirm this is a defect which is
only in v2.2.2, it is corrected for the next release. You can work
around it by editing the wsjtx_log.adi file to correct the end of header
marker. The header is only written when a new file is created, which
should only be when a new installation is set up. Sorry for the
inconvenience.

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 Report for WSJT-X Ver 2.2.2 - 64 bit

[Bill Somerville]

On 24/06/2020 19:17, Joe WA6AXE wrote:

I need to report a BUG in the newest ver 2.2.2. (64 bit) ...

When the program MAKES the wsjtx_log.adi file .. There is an ERROR in the
beginning of the adi file ..
The current version 2.2.2 writes:
WSJT-X ADIF Export
it SHOULD be written as:
WSJT-X ADIF Export


The  is currently shown as 

This is causing some problem when 3rd party BRIDGE programs try to 
IMPORT the INFO from the adi file ...

Can we pse correct this?? TIA!!

73 Joe wa6axe


Hi Joe,

thanks for the issue report. I can confirm this is a defect which is 
only in v2.2.2, it is corrected for the next release. You can work 
around it by editing the wsjtx_log.adi file to correct the end of header 
marker. The header is only written when a new file is created, which 
should only be when a new installation is set up. Sorry for the 
inconvenience.


73
Bill
G4WJS.



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

[wsjt-devel] BUG Report for WSJT-X Ver 2.2.2 - 64 bit

[Joe WA6AXE]

I need to report a BUG in the newest ver 2.2.2. (64 bit) ...

When the program MAKES the wsjtx_log.adi file .. There is an ERROR in the
beginning of the adi file ..
The current version 2.2.2 writes:
WSJT-X ADIF Export
it SHOULD be written as:
WSJT-X ADIF Export


The  is currently shown as 

This is causing some problem when 3rd party BRIDGE programs try to IMPORT the 
INFO from the adi file ...
Can we pse correct this?? TIA!!

73 Joe wa6axe

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

Re: [wsjt-devel] Bug Report: Four Letter Suffix in WSPR

[Joe Taylor]

Hi Onno,

On 6/19/2020 3:53 PM, Onno Benschop VK6FLAB wrote:

Frankly that makes no sense.

All the JT modes have evolved over time. Even WSPR has evolved. Compound 
callsigns were introduced with WSPR 2.00 (r1714) Nov 19, 2009 - 
http://physics.princeton.edu/pulsar/K1JT/WSPR_Changelog.TXT


Just because it wasn't designed with a four character suffix callsign in 
mind doesn't mean it cannot be changed.


That's why I lodged a bug report.


Bugs are program features that don't work as intended.  Your message is 
not a bug report, but rather feature request.


Supporting four-character suffixes for supposedly standard callsigns 
would require 5 additional bits for every callsign and 10 additional 
bits for nearly all messages.  It would require complete redesign of 
every presently supported message type for all of the WSJT-X modes 
except ISCAT.  It would break WSJT, MAP65, and WSPR as well as WSJT-X. 
Weak signal performance of all modes would be degraded for everybody, 
and occupied bandwidths would increase.


The results would (1) require a huge amount of work, and (2) provide 
only negative benefits for probably 99.9% of all users and potential QSOs.


Sorry, it's not going to happen.

I would think this restriction would provide a good incentive to upgrade 
your license.


-- 73, Joe, K1JT


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

Re: [wsjt-devel] Bug Report: Four Letter Suffix in WSPR

[Onno Benschop]

Frankly that makes no sense.

All the JT modes have evolved over time. Even WSPR has evolved. Compound
callsigns were introduced with WSPR 2.00 (r1714) Nov 19, 2009 -
http://physics.princeton.edu/pulsar/K1JT/WSPR_Changelog.TXT

Just because it wasn't designed with a four character suffix callsign in
mind doesn't mean it cannot be changed.

That's why I lodged a bug report.
--
finger painting on glass is an inexact art - apologies for any errors in
this scra^Hibble

()/)/)() ..ASCII for Onno..

On Sat., 20 Jun. 2020, 02:27 Frode Igland,  wrote:

> Onno,
> There is nothing wrong with your call sign of four characters in the
> suffix. It is just too long to fit within the restrictions of WSJT-X if you
> want to use WSJT-X in the standard way.  Mind you, you can still use
> WSJT-X, just not in the standard way.
>
> WSJT-X was never created to work smoothly with all legal call signs, only
> those consisting of up to two characters in the prefix + a digit + up to
> three characters in the suffix (2 x 3 type call sign). In the WSJT-X  2.2.1
> User Guide
> https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.1.html#PROTOCOLS
> you will find more about how the protocols have been worked out, whilst
> https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.1.html#COMP-CALL
> will tell you more about non-standard call signs. The add-on letter/numbers
> are like "VP9/" or /P (rover station) or numbered portable designators like
> "/3" or "/6". The Help menu shows the approved Type 1 prefixes and suffixes.
>
> The WSJT-X development team's focus is to offer a protocol that can be
> used for weak signals. That involves a number of compromises, or priorities
> if you like, and covering all call signs (even if they are perfectly legal
> and in accordance with international call sign rules) did not make it to
> the priority list for standard operation, and most likely will not. I guess
> your desire to use WSJT-X in the standard way is faster and safer achieved
> by a shorter call sign (license upgrade?), than waiting for WSJT-X to
> accommodate four character suffixes for standard operation. Sorry, but such
> has the world become. :-(
>
> 73 Frode LA6VQ
>
> fre. 19. jun. 2020 kl. 11:06 skrev Onno Benschop :
>
>> Today I attempted to TX using WSPR and learned that my callsign (VK6FLAB)
>> which I've held for nearly a decade isn't considered a "standard" callsign
>> - this format was introduced in 2005.
>>
>> According to the ITU[1], my callsign is a perfectly legal callsign (and
>> has been since 2003) (*emphasis* mine):
>>
>> *19.67 Amateur and experimental stations*
>> *19.68 § 30 1)*
>> - one character (provided that it is the letter B, F, G, I, K, M, N, R or
>> W) and a single digit (other than 0 or 1), followed by a group of not more
>> than *four characters*, the last of which shall be a letter, or
>> - two characters and a single digit (other than 0 or 1), followed by a
>> group of not more than *four characters*, the last of which shall be a
>> letter. (WRC-03)
>> *19.68A 1A)* On special occasions, for temporary use, administrations
>> may authorize use of call signs with more than the four characters referred
>> to in No. 19.68. (WRC-03)
>> *19.69 2)* However, the prohibition of the use of the digits 0 and 1
>> does not apply to amateur stations.
>>
>>
>> [1]
>> https://www.itu.int/en/ITU-R/terrestrial/fmd/Documents/fxm-art19-sec3.pdf
>>
>>
>> I also investigated using an extended (type 2) message which allows
>> (according to the WSJT-X manual):
>>
>> Add-on prefixes can be up to three alphanumeric characters; add-on
>> suffixes can be a single letter or one or two digits.
>>
>>
>> I could theoretically use VK6FLA/B as my WSPR callsign, but I'm sure that
>> the owner of VK6FLA would not be happy about this. Another "creative"
>> implementation could be "VK6/F0LAB", but I'm sure that the French station
>> owner of F0LAB would be surprised that they're transmitting from VK6.
>>
>> I'm raising this now because it wasn't legal for me to use my callsign on
>> any digital mode until September last year and I've only just managed to
>> get HF running at my QTH..
>>
>> I realise that this report is likely to require a fundamental change in
>> the WSPR protocol and I suspect that other JT modes will be affected to
>> more or lesser degree. I should probably also flag that any reporting,
>> API, database, etc. might also be affected by this issue.
>>
>> I'm currently using WSJT-X v2.0.0 under Debian 10. I've not yet managed
>> to compile or run a later version.
>>
>> Look forward to your feedback and comments.
>>
>> de Onno VK6FLAB
>> --
>> Onno Benschop
>>
>> ()/)/)()..ASCII for Onno..
>> |>>?..EBCDIC for Onno..
>> --- -. -. ---   ..Morse for Onno..
>>
>> If you need to know: "What computer should I buy?" http://goo.gl/spsb66
>>
>> ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219    -
>> o...@itmaze.com.au
>> ___
>> wsjt-devel 

Re: [wsjt-devel] Bug Report: Four Letter Suffix in WSPR

[Frode Igland]

Onno,
There is nothing wrong with your call sign of four characters in the
suffix. It is just too long to fit within the restrictions of WSJT-X if you
want to use WSJT-X in the standard way.  Mind you, you can still use
WSJT-X, just not in the standard way.

WSJT-X was never created to work smoothly with all legal call signs, only
those consisting of up to two characters in the prefix + a digit + up to
three characters in the suffix (2 x 3 type call sign). In the WSJT-X  2.2.1
User Guide
https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.1.html#PROTOCOLS
you will find more about how the protocols have been worked out, whilst
https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.1.html#COMP-CALL
will tell you more about non-standard call signs. The add-on letter/numbers
are like "VP9/" or /P (rover station) or numbered portable designators like
"/3" or "/6". The Help menu shows the approved Type 1 prefixes and suffixes.

The WSJT-X development team's focus is to offer a protocol that can be used
for weak signals. That involves a number of compromises, or priorities if
you like, and covering all call signs (even if they are perfectly legal and
in accordance with international call sign rules) did not make it to the
priority list for standard operation, and most likely will not. I guess
your desire to use WSJT-X in the standard way is faster and safer achieved
by a shorter call sign (license upgrade?), than waiting for WSJT-X to
accommodate four character suffixes for standard operation. Sorry, but such
has the world become. :-(

73 Frode LA6VQ

fre. 19. jun. 2020 kl. 11:06 skrev Onno Benschop :

> Today I attempted to TX using WSPR and learned that my callsign (VK6FLAB)
> which I've held for nearly a decade isn't considered a "standard" callsign
> - this format was introduced in 2005.
>
> According to the ITU[1], my callsign is a perfectly legal callsign (and
> has been since 2003) (*emphasis* mine):
>
> *19.67 Amateur and experimental stations*
> *19.68 § 30 1)*
> - one character (provided that it is the letter B, F, G, I, K, M, N, R or
> W) and a single digit (other than 0 or 1), followed by a group of not more
> than *four characters*, the last of which shall be a letter, or
> - two characters and a single digit (other than 0 or 1), followed by a
> group of not more than *four characters*, the last of which shall be a
> letter. (WRC-03)
> *19.68A 1A)* On special occasions, for temporary use, administrations may
> authorize use of call signs with more than the four characters referred to
> in No. 19.68. (WRC-03)
> *19.69 2)* However, the prohibition of the use of the digits 0 and 1 does
> not apply to amateur stations.
>
>
> [1]
> https://www.itu.int/en/ITU-R/terrestrial/fmd/Documents/fxm-art19-sec3.pdf
>
>
> I also investigated using an extended (type 2) message which allows
> (according to the WSJT-X manual):
>
> Add-on prefixes can be up to three alphanumeric characters; add-on
> suffixes can be a single letter or one or two digits.
>
>
> I could theoretically use VK6FLA/B as my WSPR callsign, but I'm sure that
> the owner of VK6FLA would not be happy about this. Another "creative"
> implementation could be "VK6/F0LAB", but I'm sure that the French station
> owner of F0LAB would be surprised that they're transmitting from VK6.
>
> I'm raising this now because it wasn't legal for me to use my callsign on
> any digital mode until September last year and I've only just managed to
> get HF running at my QTH..
>
> I realise that this report is likely to require a fundamental change in
> the WSPR protocol and I suspect that other JT modes will be affected to
> more or lesser degree. I should probably also flag that any reporting,
> API, database, etc. might also be affected by this issue.
>
> I'm currently using WSJT-X v2.0.0 under Debian 10. I've not yet managed to
> compile or run a later version.
>
> Look forward to your feedback and comments.
>
> de Onno VK6FLAB
> --
> Onno Benschop
>
> ()/)/)()..ASCII for Onno..
> |>>?..EBCDIC for Onno..
> --- -. -. ---   ..Morse for Onno..
>
> If you need to know: "What computer should I buy?" http://goo.gl/spsb66
>
> ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219    -
> o...@itmaze.com.au
> ___
> 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 Report: Four Letter Suffix in WSPR

[Matt VK3FDLL]

Hi Onno,

I was enquiring about this in February this year too -
https://sourceforge.net/p/wsjt/mailman/message/36929030/

> With various tests, I can hear my WSPR transmissions away from my station
and WSJT-X can even decode my transmissions. However the decoding only
occurs on transmissions where my callsign is hashed (Type 3 message, I
believe?)Transmissions where my full, 7 digit callsign (and 4 digit grid
squarelocator) are transmitted are not decoded by WSJT-X.

I'll be watching this thread with interest.

On Fri, 19 Jun 2020 at 19:03, Onno Benschop  wrote:

> Today I attempted to TX using WSPR and learned that my callsign (VK6FLAB)
> which I've held for nearly a decade isn't considered a "standard" callsign
> - this format was introduced in 2005.
>
> According to the ITU[1], my callsign is a perfectly legal callsign (and
> has been since 2003) (*emphasis* mine):
>
> *19.67 Amateur and experimental stations*
> *19.68 § 30 1)*
> - one character (provided that it is the letter B, F, G, I, K, M, N, R or
> W) and a single digit (other than 0 or 1), followed by a group of not more
> than *four characters*, the last of which shall be a letter, or
> - two characters and a single digit (other than 0 or 1), followed by a
> group of not more than *four characters*, the last of which shall be a
> letter. (WRC-03)
> *19.68A 1A)* On special occasions, for temporary use, administrations may
> authorize use of call signs with more than the four characters referred to
> in No. 19.68. (WRC-03)
> *19.69 2)* However, the prohibition of the use of the digits 0 and 1 does
> not apply to amateur stations.
>
>
> [1]
> https://www.itu.int/en/ITU-R/terrestrial/fmd/Documents/fxm-art19-sec3.pdf
>
>
> I also investigated using an extended (type 2) message which allows
> (according to the WSJT-X manual):
>
> Add-on prefixes can be up to three alphanumeric characters; add-on
> suffixes can be a single letter or one or two digits.
>
>
> I could theoretically use VK6FLA/B as my WSPR callsign, but I'm sure that
> the owner of VK6FLA would not be happy about this. Another "creative"
> implementation could be "VK6/F0LAB", but I'm sure that the French station
> owner of F0LAB would be surprised that they're transmitting from VK6.
>
> I'm raising this now because it wasn't legal for me to use my callsign on
> any digital mode until September last year and I've only just managed to
> get HF running at my QTH..
>
> I realise that this report is likely to require a fundamental change in
> the WSPR protocol and I suspect that other JT modes will be affected to
> more or lesser degree. I should probably also flag that any reporting,
> API, database, etc. might also be affected by this issue.
>
> I'm currently using WSJT-X v2.0.0 under Debian 10. I've not yet managed to
> compile or run a later version.
>
> Look forward to your feedback and comments.
>
> de Onno VK6FLAB
> --
> Onno Benschop
>
> ()/)/)()..ASCII for Onno..
> |>>?..EBCDIC for Onno..
> --- -. -. ---   ..Morse for Onno..
>
> If you need to know: "What computer should I buy?" http://goo.gl/spsb66
>
> ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219    -
> o...@itmaze.com.au
> ___
> 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] Bug Report: Four Letter Suffix in WSPR

[Onno Benschop]

Today I attempted to TX using WSPR and learned that my callsign (VK6FLAB)
which I've held for nearly a decade isn't considered a "standard" callsign
- this format was introduced in 2005.

According to the ITU[1], my callsign is a perfectly legal callsign (and has
been since 2003) (*emphasis* mine):

*19.67 Amateur and experimental stations*
*19.68 § 30 1)*
- one character (provided that it is the letter B, F, G, I, K, M, N, R or
W) and a single digit (other than 0 or 1), followed by a group of not more
than *four characters*, the last of which shall be a letter, or
- two characters and a single digit (other than 0 or 1), followed by a
group of not more than *four characters*, the last of which shall be a
letter. (WRC-03)
*19.68A 1A)* On special occasions, for temporary use, administrations may
authorize use of call signs with more than the four characters referred to
in No. 19.68. (WRC-03)
*19.69 2)* However, the prohibition of the use of the digits 0 and 1 does
not apply to amateur stations.


[1]
https://www.itu.int/en/ITU-R/terrestrial/fmd/Documents/fxm-art19-sec3.pdf


I also investigated using an extended (type 2) message which allows
(according to the WSJT-X manual):

Add-on prefixes can be up to three alphanumeric characters; add-on suffixes
can be a single letter or one or two digits.


I could theoretically use VK6FLA/B as my WSPR callsign, but I'm sure that
the owner of VK6FLA would not be happy about this. Another "creative"
implementation could be "VK6/F0LAB", but I'm sure that the French station
owner of F0LAB would be surprised that they're transmitting from VK6.

I'm raising this now because it wasn't legal for me to use my callsign on
any digital mode until September last year and I've only just managed to
get HF running at my QTH..

I realise that this report is likely to require a fundamental change in the
WSPR protocol and I suspect that other JT modes will be affected to more or
lesser degree. I should probably also flag that any reporting, API,
database, etc. might also be affected by this issue.

I'm currently using WSJT-X v2.0.0 under Debian 10. I've not yet managed to
compile or run a later version.

Look forward to your feedback and comments.

de Onno VK6FLAB
-- 
Onno Benschop

()/)/)()..ASCII for Onno..
|>>?..EBCDIC for Onno..
--- -. -. ---   ..Morse for Onno..

If you need to know: "What computer should I buy?" http://goo.gl/spsb66

ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219    -
o...@itmaze.com.au
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Bug Report: WSJT-X Tx audio disconnects from Flex DAX after sitting idle

[Geoffrey Mendenhall]

Problem: WSJT-X Tx audio disconnects from Flex DAX after sitting idle

Current software configuration: WSJT-x v 2.2.0, Flex DAX v 2.6.2.50, Windows 10 
Pro v 1909.
FlexRadio 6600M transceiver running v 2.6.2.50 software.

After WSJT-x in FT8 mode sits in a receive/monitor condition for several hours, 
the Tx audio connection via Flex DAX to the Flex 6600M transceiver is lost.
DAX is still connected to the radio, but the connection from WSJT-x is broken.
The Rx audio connection from the Flex 6600M via DAX remains working OK.

This problem with the loss of Tx audio has existed over the past several 
versions of WSJT-x and DAX.
Several other FlexRadio users are having exactly the same problem using Flex 
6700 radios.

The problem can be fixed by shutting down WSJT-x and restarting it which causes 
the current activity window to be lost which is inconvenient
or without restarting WSJT-x by going to the WSJT-x FILE/SETTINGS/AUDIO/OUTPUT 
menu and changing from the "DAX AUDIO TX" selection to another selection and 
clicking OK,
then going back through the FILE/SETTINGS/AUDIO/OUTPUT menu and changing back 
to "DAX AUDIO TX" selection and then clicking OK.
73,
Geoff - W8GNM


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

Re: [wsjt-devel] bug report for WSJT-X 2.2.0-rc2

[Joe Taylor]

Hi Bruce,

On 5/25/2020 5:44 PM, Bruce H. Bern K3NQ wrote:


Program version: (beta) WSJT-X 2.2.0-rc3;  My system: Win 10 Pro X64; Intel
Core i7-3930K; CPU@3.2 GHz; RAM=24Gb; Radio Kenwood TS-990, Baud rate:
115,200; data bits, stop bits, handshake all default
Precis of problem: If a transmit frequency of <200 Hz is selected by holding
shift and clicking below 200 Hz, the transmit frequency will move no lower
than 200Hz. If a target station has already been selected, and his/her call
sign already double-clicked (transmit enabled), any attempt to move the
transmit frequency by holding shift and double clicking below 200Hz results
in loss of the recorded waterfall display (as well as moving the transmit
frequency no lower than 200 Hz). The waterfall remains functional, but
starts again as if the program was just opened. I've attached a
less-than-perfect video. I am very much enjoying the rapid decoding.


Thanks for the additional information.  I still have not been able to 
reproduce the behavior you describe.


It is intentional that the Tx audio frequency cannot be set lower than 
200 Hz.  This is because you might not be using Split=Rig or
Split=Fake It, and in that case the very low requested audio frequency 
would be sent to your SSB transmitter.  Most likely the audio frequency 
would be outside your Tx filter's passband.


If I shift+click on the waterfall at a frequenct below 200 Hz, the Tx 
freq is set to 200 Hz.  If I decode a signal below 200 Hz and 
double-click on the decoded text, the Tx freq is set to 200 Hz.  I 
haven't found anything that on my system "results in loss of the 
recorded waterfall display".


If I have overlooked something important, or if your system behaves 
different from mine, please give me an exact list of steps that will 
result in loss of the waterfall display.



On a side note, I worked you a few months back. Excited by my brush with ham
royalty, I called over and over with an appropriate power of 30-40 watts.
Finally, I switched on the linear assuming the problem was my since-replaced
and long overdue for maintenance antenna. You gave me a -03dB report- I gave
you a -14 dB report. I was embarrassed at the realization I was using ten
times more power than necessary. I had meant to apologize for my violation
of the spirit of WSJT.


No problem at all!  It's not always easy to choose appropriate Tx power; 
QSB and QRM often determine how strong and how copyable a signal may be.


-- 73, Joe, K1JT


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

Re: [wsjt-devel] bug report for WSJT-X 2.2.0-rc2

[Joe Taylor]

Hi Bruce,

On 5/25/2020 2:53 PM, Bruce H. Bern K3NQ wrote:
Using latest Win-10, if attempting to place the transmit frequency below 
200 Hz, the display crashes


I can't reproduce the effect you describe.

If it's reproducible for you, please follow instructions for bug reports 
here in the User Guide:


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

To be useful, bug reports should include at least the following information:

 - Program version

 - Operating system

 - Concise description of the problem

 - Exact sequence of steps required to reproduce the problem

-- 73, Joe, K1JT


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

[wsjt-devel] bug report for WSJT-X 2.2.0-rc2

[Bruce H. Bern]

Using latest Win-10, if attempting to place the transmit frequency below 200
Hz, the display crashes

Thanks,

Bruce K3NQ

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

Re: [wsjt-devel] Bug report in mainwindow.cpp

[Yukio JG1APX]

Hi Joe

Thank you.
I am glad to hear that.

73
Yukio JG1APX


On Sat, 23 May 2020 09:11:20 -0400
Joe Taylor  wrote:

> Hi Yukio-san,
> 
> Thanks for alerting us to the omission of a mode-label color definition for 
> FT4, and the typo.  They will be corrected in the next release!
> 
>   -- Joe, K1JT
> ___
> 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 report in mainwindow.cpp

[Joe Taylor]

Hi Yukio-san,

Thanks for alerting us to the omission of a mode-label color definition 
for FT4, and the typo.  They will be corrected in the next release!


-- Joe, K1JT

On 5/22/2020 8:52 PM, Yukio JG1APX wrote:

Hello all

I have noticed minor things in mainwindow.cpp source code.  If they are
already known, sorry about this.

v2.2.0 rc1 mainwindow.cpp :

1. FT4 background color of mode lable depends on previous mode.
 The background color difinition is missing in setup_status_bar
(bool vhf) at line 2275 :

if ("ISCAT" == m_mode) {
 mode_label.setStyleSheet ("QLabel{background-color: #ff9933}");
   } else if ("JT9" == m_mode) {
 mode_label.setStyleSheet ("QLabel{background-color: #ff6ec7}");
   } else if ("JT4" == m_mode) {
 mode_label.setStyleSheet ("QLabel{background-color: #cc99ff}");
   } else if ("Echo" == m_mode) {
 mode_label.setStyleSheet ("QLabel{background-color: #66}");
   } else if ("JT9+JT65" == m_mode) {
 mode_label.setStyleSheet ("QLabel{background-color: #66}");
   } else if ("JT65" == m_mode) {
 mode_label.setStyleSheet ("QLabel{background-color: #66ff66}");
   } else if ("QRA64" == m_mode) {
 mode_label.setStyleSheet ("QLabel{background-color: #99ff33}");
   } else if ("MSK144" == m_mode) {
 mode_label.setStyleSheet ("QLabel{background-color: #ff}");
   } else if ("FT8" == m_mode) {
 mode_label.setStyleSheet ("QLabel{background-color: #6699ff}");
   } else if ("FreqCal" == m_mode) {
 mode_label.setStyleSheet ("QLabel{background-color: #ff9933}");  }

2. m_send_RR73 from readSettings() at line 1203 :
   m_send_RR73=m_settings->value("RR73",37).toBool();
   '37' maybe typo.  True or false for Bool() instead.

73
Yukio JG1APX



___
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] Bug report in mainwindow.cpp

[Yukio JG1APX]

Hello all

I have noticed minor things in mainwindow.cpp source code.  If they are
already known, sorry about this. 

v2.2.0 rc1 mainwindow.cpp :

1. FT4 background color of mode lable depends on previous mode. 
The background color difinition is missing in setup_status_bar
(bool vhf) at line 2275 :

if ("ISCAT" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #ff9933}");
  } else if ("JT9" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #ff6ec7}");
  } else if ("JT4" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #cc99ff}");
  } else if ("Echo" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #66}");
  } else if ("JT9+JT65" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #66}");
  } else if ("JT65" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #66ff66}");
  } else if ("QRA64" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #99ff33}");
  } else if ("MSK144" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #ff}");
  } else if ("FT8" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #6699ff}");
  } else if ("FreqCal" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #ff9933}");  }

2. m_send_RR73 from readSettings() at line 1203 :
  m_send_RR73=m_settings->value("RR73",37).toBool();
  '37' maybe typo.  True or false for Bool() instead.

73
Yukio JG1APX



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

Re: [wsjt-devel] Bug Report - 2.2rc1 - ISCAT Mode

[Kevin McQuiggin]

Thank you Joe, glad to help, if even with a little-used mode.

As others have said, we have a small group of ISCAT users here in the west, so 
we may have further info for you as time progresses.

We need to thanks James K7KQA for this as he is the driver out here for getting 
people to try out ISCAT.

Additional info is that the bug also exists in Windows.  As I stated I run 
WSJT-X on an iMac.

73 and thanks for all your (and the development group’s) great work.

Kevin VE7ZD/KN7Q

Sent from my iPhone

> On May 22, 2020, at 08:55, Joe Taylor  wrote:
> 
> Hi Kevin,
> 
>> On 5/22/2020 10:45 AM, Kevin McQuiggin VE7ZD/KN7Q wrote:
>> 
>> In ISCAT mode, if one double-clicks a message in the left hand RX signals 
>> pane this presents a dialog box “Double clicking is not supported in ISCAT 
>> mode”.  When this dialog box is dismissed, the app crashes.
> 
> Many tThanks for reporting this bug.  Who knows how many years it must have 
> been present?  It will be fixed in the coming "RC2" release of WSJT-X 2.2.0.
> 
>-- 73, Joe, K1JT



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

Re: [wsjt-devel] Bug Report - 2.2rc1 - ISCAT Mode

[Joe Taylor]

Hi Kevin,

On 5/22/2020 10:45 AM, Kevin McQuiggin VE7ZD/KN7Q wrote:


In ISCAT mode, if one double-clicks a message in the left hand RX signals pane 
this presents a dialog box “Double clicking is not supported in ISCAT mode”.  
When this dialog box is dismissed, the app crashes.


Many tThanks for reporting this bug.  Who knows how many years it must 
have been present?  It will be fixed in the coming "RC2" release of 
WSJT-X 2.2.0.


-- 73, Joe, K1JT


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

[wsjt-devel] Bug Report - 2.2rc1 - ISCAT Mode

[Kevin McQuiggin]

Hi All:

In ISCAT mode, if one double-clicks a message in the left hand RX signals pane 
this presents a dialog box “Double clicking is not supported in ISCAT mode”.  
When this dialog box is dismissed, the app crashes.

I am running rc1 on MacOS version 10.14.6 Mojave.

If you need further info then please email me.

73,

Kevin VE7ZD/KN7Q




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] Bug Report V 2.2.0 RC1

[Bill Somerville]

On 13/05/2020 00:44, Dave Anderson, K4SV via wsjt-devel wrote:

Hi Everyone,

I am new to the group here and not sure where to make a bug report 
other than what the WSJTX site suggests, which is here.


Overall software runs very well.  Using it for 630 meter WSPR at the 
moment.


Bug
After setting the transmit power level it transmits correctly but if 
the application is closed and reopened it forgets the previous power 
setting and reverts to a level of 0.


Win 7
WSJTX V2.2.0  rc1

Thanks in advance,

PS Please advise if bug reports should be reported differently.

Best 73

*Dave Anderson, K4SV*
*Tryon, NC*


Hi Dave,

thanks for the issue report, I can confirm it is a defect which will be 
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] Bug Report V 2.2.0 RC1

[Dave Anderson, K4SV via wsjt-devel]

Hi Everyone,
I am new to the group here and not sure where to make a bug report other than 
what the WSJTX site suggests, which is here.
Overall software runs very well.  Using it for 630 meter WSPR at the moment.
BugAfter setting the transmit power level it transmits correctly but if the 
application is closed and reopened it forgets the previous power setting and 
reverts to a level of 0.
Win 7WSJTX V2.2.0  rc1
Thanks in advance,
PS Please advise if bug reports should be reported differently.
Best 73
Dave Anderson, K4SVTryon, NC WWW.K4SV.NET

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

[wsjt-devel] Bug Report : May not match UTC time log(All.txt) and screen display

[jh7wnv]

Hi WSJT-X Developers.
I am Yoshi JH7WNV.

Thanks for all. and I enjoy using WSJT-X every day.
When I creating log(ALL.TXT) file analyze tool, I found a bug in WSJT-X log 
file.
Please check this problem. and fix.

•Program version
  WSJT-X v2.1.0 x64

•Operating system
  OS: Windows 7 x64
  CPU: Intel Core i7-2700K 3.50GHz
  RAM: 12.0GB

•Concise description of the problem
  UTC time written in All.txt may deviate from WSJT-X screen display.

•Exact sequence of steps required to reproduce the problem
  
   With conditions and bands that can receive more than 20 stations at a time 
receive.
 
   1) Waiting for Decode.
   2) When decoding is complete, the ALL.TXT file open.
   3) All.TXT is opened with Notepad, and the bottom edge is displayed with 
CTRL+END key.
 
   UTC time written in All.txt may deviate from WSJT-X screen display.

   All.TXT
   -
   190902_133300    14.074 Rx FT8    -14  0.0  964 CQ DX HA3HV JN86
   190902_133300    14.074 Rx FT8      2  0.2  526 CQ UA0LKD PN53
   190902_133300    14.074 Rx FT8     14  0.2  689 R9HCF RU0LL R-12
   190902_133300    14.074 Rx FT8      1 -2.2  783 YC5YZ R6DCN -07
   190902_133300    14.074 Rx FT8      2 -0.0  834 JA1GRM D1DX RR73
   190902_133300    14.074 Rx FT8    -10 -0.2  963 HA3HV DS1PEG PM37
   190902_133300    14.074 Rx FT8     -8  0.0 1078 VU3ONG LZ3CQ -16
   190902_133300    14.074 Rx FT8     -9  0.2 1098 YB9KA R7DX KN84
   190902_133300    14.074 Rx FT8    -14  0.4 1248 CQ RV6F LN14
   190902_133300    14.074 Rx FT8     -8 -0.0 1494 YC6RMT UA6LQZ -12
   190902_133300    14.074 Rx FT8    -13  0.1 1644 BG5HKI YO7YO KN25
   190902_133300    14.074 Rx FT8     12  0.0 1727 9A2TN HL3EQE R-18
   190902_133300    14.074 Rx FT8      4  0.0 2087 HA3HV HL1BX PM37
   190902_133300    14.074 Rx FT8    -11  0.3 2147 CQ RO7L LN06
   190902_133300    14.074 Rx FT8    -12  0.0 2548 YB0MWM SV2AEL -24
   190902_133300    14.074 Rx FT8    -21  0.1 2571 CQ A41ZZ LL93
   190902_133300    14.074 Rx FT8    -22 -0.9  301 HA3HV BD7LMA OL63
   190902_133300    14.074 Rx FT8    -22  0.1  394 RA3LJ IK4LZH RR73
   190902_133315    14.074 Rx FT8     -8  1.5 1145 CQ R7BL LN06         <- 
133300(GUI Displayed UTC)
   190902_133315    14.074 Rx FT8    -24  0.1 1511 CQ 9K2HQ LL49        <- 
133300(GUI Displayed UTC)
   190902_133315    14.074 Rx FT8    -21 -0.0 1595 F4HQL RA9LL -20      <- 
133300(GUI Displayed UTC)
   -
              ^^
   # No appear this problem in receive less than 15 stations at time receive.


thanks for reading my poor english.

73 Yoshi JH7WNV



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

[wsjt-devel] Bug report: WAV file storage

[Dave Pascoe]

New to the list...I couldn't find a bug tracker online so I will report
this here for now.

WSJT-X version 2.0.1 (GA Release)
Windows 10 Pro 64-bit

Issue: Even when Save->None is selected the app continues to accumulate
large numbers of WAV files in ...\AppData\Local\WSJT-X\save (SaveDir)

This requires periodic cleaning by using File->Delete all .wav & .c2 files
in SaveDir. For those of us running FT8 skimmer stations and operating
"headless" systems with little human interaction, it is a little
unreasonable to have to perform manual tasks like this, especially if the
application isn't supposed to be doing it in the first place. :-) Of
course, deleting the files via scripting is possible, but it seems like a
poor solution to the problem.

In searching the mailing list archives it seems this was reported earlier
but still remains a bug.

Thanks for listening and 73,
Dave KM3T
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug report: WSJT-X fails to output sound after several minutes idle

[Jim Nuytens via wsjt-devel]

Oh, also running W10 1809 and WSJT-X 2.1.0 RC7.

On 6/16/2019 04:01, Jim Nuytens via wsjt-devel wrote:
I'm not a programmer or developer, but I'd like to know the precise 
hardware configuration of those having this issue. Down to the minute 
details of motherboard, sound interface, etc.


I do not see anything like this at all, and my system runs for days at 
a time. Sometimes the system runs for a week or more straight with 
WSJT-X running constantly. I generally leave the system running 
overnight on either 80m or 160m, and most of the day monitoring 17m 
thru 6m.


The system here:

ASRock A320M-HDV motherboard
AMD Ryzen 3 2200G APU with Radeon Vega 8 Graphics
16GB RAM
ADATA SU800 256GB SSD
12 year old US Interface Navigator USB (before they were bought out by 
Timewave)

10 year old K3/100




---
This email has been checked for viruses by AVG.
https://www.avg.com



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

Re: [wsjt-devel] Bug report: WSJT-X fails to output sound after several minutes idle

[Jim Nuytens via wsjt-devel]

I'm not a programmer or developer, but I'd like to know the precise 
hardware configuration of those having this issue. Down to the minute 
details of motherboard, sound interface, etc.


I do not see anything like this at all, and my system runs for days at a 
time. Sometimes the system runs for a week or more straight with WSJT-X 
running constantly. I generally leave the system running overnight on 
either 80m or 160m, and most of the day monitoring 17m thru 6m.


The system here:

ASRock A320M-HDV motherboard
AMD Ryzen 3 2200G APU with Radeon Vega 8 Graphics
16GB RAM
ADATA SU800 256GB SSD
12 year old US Interface Navigator USB (before they were bought out by 
Timewave)

10 year old K3/100


On 6/15/2019 19:13, Steve Masticola via wsjt-devel wrote:

Program version: 2.0.1 7ddcb7

Operating system: Windows 10, ver. 1809 (OS Build 17763.503)

Description: After sitting idle with Monitor on for several minutes, 
WSJT-X will key the transceiver on Tune or transmit, but does not 
generate sound to the soundcard. I have confirmed that the issue is in 
WSJT-X, not Windows or the soundcard. Confirmation was by testing the 
soundcard with the Windows Speaker Properties popup to eliminate 
Windows or the soundcard as the cause. 100% reproducible for users who 
are seeing this. Have identified a small number of other users who are 
affected. Can obtain additional logs if helpful. Please advise.


Sequence of steps to repeat:

N*ote: Only a small number of users reproduce this AFAICT.*

1. Disable Windows screen saver and all USB power-saving options.
2. Start WSJT-X.
3. Confirm proper operation of Tune control.
4. Let WSJT-X idle for 10-30 minutes.
5. Key the Tune control. Rig will be placed in transmit mode but no 
audio will go to the soundcard.




---
This email has been checked for viruses by AVG.
https://www.avg.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug report: WSJT-X fails to output sound after several minutes idle

[Gene Marsh via wsjt-devel]

Check your Windows 10 updates first.  I had the same issue.  Now, no problem. 

73 de W8NET Miles / “Gene”
Secretary, Portage County Amateur Radio Service (PCARS)
3905 Century Club - Master #47
DV2/W8NET in the Philippines
Licensed since 1974

> On Jun 15, 2019, at 6:41 PM, Tom M0LTE  wrote:
> 
> This happens to me from time to time.
> 
>> On Sat, 15 Jun 2019 at 22:43, Steve Masticola via wsjt-devel 
>>  wrote:
>> Program version: 2.0.1 7ddcb7
>> 
>> Operating system: Windows 10, ver. 1809 (OS Build 17763.503)
>> 
>> Description: After sitting idle with Monitor on for several minutes, WSJT-X 
>> will key the transceiver on Tune or transmit, but does not generate sound to 
>> the soundcard. I have confirmed that the issue is in WSJT-X, not Windows or 
>> the soundcard. Confirmation was by testing the soundcard with the Windows 
>> Speaker Properties popup to eliminate Windows or the soundcard as the cause. 
>> 100% reproducible for users who are seeing this. Have identified a small 
>> number of other users who are affected. Can obtain additional logs if 
>> helpful. Please advise.
>> 
>> Sequence of steps to repeat:
>> 
>> Note: Only a small number of users reproduce this AFAICT. 
>> 
>> 1. Disable Windows screen saver and all USB power-saving options.
>> 2. Start WSJT-X.
>> 3. Confirm proper operation of Tune control.
>> 4. Let WSJT-X idle for 10-30 minutes.
>> 5. Key the Tune control. Rig will be placed in transmit mode but no audio 
>> will go to the soundcard.
>> 
>> ___
>> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug report: WSJT-X fails to output sound after several minutes idle

[Tom M0LTE]

This happens to me from time to time.

On Sat, 15 Jun 2019 at 22:43, Steve Masticola via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Program version: 2.0.1 7ddcb7
>
> Operating system: Windows 10, ver. 1809 (OS Build 17763.503)
>
> Description: After sitting idle with Monitor on for several minutes,
> WSJT-X will key the transceiver on Tune or transmit, but does not generate
> sound to the soundcard. I have confirmed that the issue is in WSJT-X, not
> Windows or the soundcard. Confirmation was by testing the soundcard with
> the Windows Speaker Properties popup to eliminate Windows or the soundcard
> as the cause. 100% reproducible for users who are seeing this. Have
> identified a small number of other users who are affected. Can obtain
> additional logs if helpful. Please advise.
>
> Sequence of steps to repeat:
>
> N*ote: Only a small number of users reproduce this AFAICT.*
>
> 1. Disable Windows screen saver and all USB power-saving options.
> 2. Start WSJT-X.
> 3. Confirm proper operation of Tune control.
> 4. Let WSJT-X idle for 10-30 minutes.
> 5. Key the Tune control. Rig will be placed in transmit mode but no audio
> will go to the soundcard.
>
> ___
> 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] Bug report: WSJT-X fails to output sound after several minutes idle

[Steve Masticola via wsjt-devel]

Program version: 2.0.1 7ddcb7
Operating system: Windows 10, ver. 1809 (OS Build 17763.503)
Description: After sitting idle with Monitor on for several minutes, WSJT-X 
will key the transceiver on Tune or transmit, but does not generate sound to 
the soundcard. I have confirmed that the issue is in WSJT-X, not Windows or the 
soundcard. Confirmation was by testing the soundcard with the Windows Speaker 
Properties popup to eliminate Windows or the soundcard as the cause. 100% 
reproducible for users who are seeing this. Have identified a small number of 
other users who are affected. Can obtain additional logs if helpful. Please 
advise.
Sequence of steps to repeat:
Note: Only a small number of users reproduce this AFAICT. 

1. Disable Windows screen saver and all USB power-saving options.
2. Start WSJT-X.3. Confirm proper operation of Tune control.4. Let WSJT-X idle 
for 10-30 minutes.5. Key the Tune control. Rig will be placed in transmit mode 
but no audio will go to the soundcard.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug report

[Bill Somerville]

On 02/06/2019 21:50, DG2YCB wrote:


WSJT-X v2.1.0 RC6 32-bit version starts normal on my Windows 10 64 bit 
computer. Only issue there was that CAT connection to my Ft-991 (via 
OmniRig) got lost at least ten times within three minutes. I didn't 
have such issues with all earlier versions including 2.1.0-rc-5. Will 
do some further tests tomorrow. Not yet fully sure whether it is 
caused allone by the new rc-6 version or if it is better after 
rebooting the computer. However, I started v2.0.1 for comparison, and 
with that I saw no CAT control issues so far.



Hi Uwe,

can you help me with gathering some trace information on the Omni-Rig 
stability issues in WSJT-X v2.1.0 RC6 please?


Here is an instrumented version of WSJT-X:

https://www.dropbox.com/s/g0x554ey5vj1b0x/wsjtx-2.1.0-rc7-win64-CAT_trace.exe?dl=0

Install it over the version of WSJT-X v2.1.0 you have, no need to 
uninstall, then run a minimal test that demonstrates the issue. Once the 
issue occurs quit WSJT-X. It will have produced a trace log file:


"%Temp%\WSJT-X_trace.log"

send that to me for analysis. If the file is too big to send then try 
deleting it and repeating the reproduction test in the shortest time 
possible.


The easiest way to locate the trace log file is to open Windows File 
Explorer and type %Temp% and ENTER into the location bar at the top, the 
trace file will be near the end of the directory listing that opens.


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

Re: [wsjt-devel] Bug report

[Al]

It appears to me that the problem with rc6 failing to start is related 
to an existing wsjt_log.adi..

delete  or rename the wsjt_adi.log file and try again..

AL, K0VM

On 6/2/2019 4:52 PM, Hasan al-Basri wrote:
Same here, 64 bit win won't start and does not show up as an installed 
program. The files are in the install directory, but it neither 
starts, nor does is show up in the start program list.


N0AN
Hasan


On Sun, Jun 2, 2019 at 2:00 PM Jari A > wrote:


win 7 64 bit

Does not start, reboot does not help.

FYI

Best rgds,

:Jari / oh2fqv


---


Problem signature:
  Problem Event Name: APPCRASH
  Application Name: wsjtx.exe
  Application Version: 0.0.0.0
  Application Timestamp: 5cf07e87
  Fault Module Name: wsjtx.exe
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp: 5cf07e87
  Exception Code: c005
  Exception Offset: 0027cc44
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 1035
  Additional Information 1: deed
  Additional Information 2: deed2ee1fb10a9245a68e6f47ba9b087
  Additional Information 3: e981
  Additional Information 4: e98176a476e5df4a870310674973c595
___
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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug report

[Anders LA9NKA]

v2.1.0-RC6 also crashes on my Ubuntu 18.04.2 64bit installation.

I have uploaded the Ubuntu crash report to my dropbox:
https://www.dropbox.com/s/ocaibp3dfbajdyh/_usr_bin_wsjtx.1001.crash?dl=0

If starting the program with the -r parameter (wstjx -r test) everything 
starts fine. Starting with -c parameter (-c test) still causes crash.


Removing exisiting wsjt-x.ini file (renaming to wsjt-x.ini.old) makes no 
difference. A new ini-file is created, only containing two lines:


   /[MultiSettings]//
   //CurrentName=Default//
   /

Hopefully the crash report may contain something useful...


*73... Anders, LA9NKA*
E-mail: la9...@kvalvaag.net 


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

Re: [wsjt-devel] Bug report

[Hasan al-Basri]

Same here, 64 bit win won't start and does not show up as an installed
program. The files are in the install directory, but it neither starts, nor
does is show up in the start program list.

N0AN
Hasan


On Sun, Jun 2, 2019 at 2:00 PM Jari A  wrote:

> win 7 64 bit
>
> Does not start, reboot does not help.
>
> FYI
>
> Best rgds,
>
> :Jari / oh2fqv
>
>
> ---
>
>
> Problem signature:
>   Problem Event Name: APPCRASH
>   Application Name: wsjtx.exe
>   Application Version: 0.0.0.0
>   Application Timestamp: 5cf07e87
>   Fault Module Name: wsjtx.exe
>   Fault Module Version: 0.0.0.0
>   Fault Module Timestamp: 5cf07e87
>   Exception Code: c005
>   Exception Offset: 0027cc44
>   OS Version: 6.1.7601.2.1.0.256.48
>   Locale ID: 1035
>   Additional Information 1: deed
>   Additional Information 2: deed2ee1fb10a9245a68e6f47ba9b087
>   Additional Information 3: e981
>   Additional Information 4: e98176a476e5df4a870310674973c595
> ___
> 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 report

[Jari A]

Hi Bill,

RC6 32 bit came with:

Problem signature:
  Problem Event Name: APPCRASH
  Application Name: wsjtx.exe
  Application Version: 0.0.0.0
  Application Timestamp: 07211a30
  Fault Module Name: wsjtx.exe
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp: 07211a30
  Exception Code: c005
  Exception Offset: 00297743
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 1035
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Rgds,

:Jari


On Mon, Jun 3, 2019 at 12:16 AM Bill Somerville 
wrote:

> On 02/06/2019 21:50, DG2YCB wrote:
>
> Hi Bill,
> WSJT-X v2.1.0 RC6 32-bit version starts normal on my Windows 10 64 bit
> computer. Only issue there was that CAT connection to my Ft-991 (via
> OmniRig) got lost at least ten times within three minutes. I didn't have
> such issues with all earlier versions including 2.1.0-rc-5. Will do some
> further tests tomorrow. Not yet fully sure whether it is caused allone by
> the new rc-6 version or if it is better after rebooting the computer.
> However, I started v2.0.1 for comparison, and with that I saw no CAT
> control issues so far.
>
> 73 de DG2YCB,
> Uwe
>
> Hi Uwe,
>
> there were some fairly extensive changes to the Omni-Rig interface at the
> last minute to try and fix issues reported by Alex, VE3NEA. Looks like I
> have screwed things up somewhere. I will try and find and fix the problem
> quickly. Sorry for the inconvenience.
>
> 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 report

[Bill Somerville]

On 02/06/2019 21:50, DG2YCB wrote:


Hi Bill,
WSJT-X v2.1.0 RC6 32-bit version starts normal on my Windows 10 64 bit 
computer. Only issue there was that CAT connection to my Ft-991 (via 
OmniRig) got lost at least ten times within three minutes. I didn't 
have such issues with all earlier versions including 2.1.0-rc-5. Will 
do some further tests tomorrow. Not yet fully sure whether it is 
caused allone by the new rc-6 version or if it is better after 
rebooting the computer. However, I started v2.0.1 for comparison, and 
with that I saw no CAT control issues so far.


73 de DG2YCB,
Uwe


Hi Uwe,

there were some fairly extensive changes to the Omni-Rig interface at 
the last minute to try and fix issues reported by Alex, VE3NEA. Looks 
like I have screwed things up somewhere. I will try and find and fix the 
problem quickly. Sorry for the inconvenience.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Bug report

[Richard Lamont]

Ubuntu MATE 18.04 LTS amd64

rc6 segfaults at startup.

It's OK if I start from shell using --test-mode

73,
Richard G4DYA



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

Re: [wsjt-devel] Bug report

[Fred Price]

Mike,
Here is requested in I file.

Fred

On Jun 2, 2019 4:46 PM, Black Michael  wrote:
So please send in your regular WSJT-X.ini file and the team can likely figure 
out the problem.

Mike




On Sunday, June 2, 2019, 3:45:11 PM CDT, Fred Price  wrote:


Mike,
Stating with WSJT -r test let me run RC6. Otherwise it doesn't open without the 
new config.
Windows 7 Ultimate
WSJT-X 2.1.0RC6 64 bit

Thanks
Fred
N2XK

On Jun 2, 2019 4:33 PM, Black Michael via wsjt-devel 
 wrote:
Hmmm...64-bit version RC6 working here.

Can you try starting yours with a new config and see if that fixes it?
e.g.
wsjtx -r test

de Mike W9MDB


On Sunday, June 2, 2019, 3:11:48 PM CDT, DG2YCB, Uwe  wrote:



Same here. Win 10 64 bit version not starting.



73 de Uwe, DG2YCB



Von: Jari A [mailto:oh2...@gmail.com]
Gesendet: Sonntag, 2. Juni 2019 20:55
An: WSJT software development
Betreff: [wsjt-devel] Bug report



win 7 64 bit



Does not start, reboot does not help.



FYI



Best rgds,



:Jari / oh2fqv





---





Problem signature:

  Problem Event Name: APPCRASH
  Application Name: wsjtx.exe
  Application Version: 0.0.0.0
  Application Timestamp: 5cf07e87
  Fault Module Name: wsjtx.exe
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp: 5cf07e87
  Exception Code: c005
  Exception Offset: 0027cc44
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 1035
  Additional Information 1: deed
  Additional Information 2: deed2ee1fb10a9245a68e6f47ba9b087
  Additional Information 3: e981
  Additional Information 4: e98176a476e5df4a870310674973c595

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




WSJT-X.ini
Description: WSJT-X.ini
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug report

[DG2YCB]

Hi Bill,
WSJT-X v2.1.0 RC6 32-bit version starts normal on my Windows 10 64 bit
computer. Only issue there was that CAT connection to my Ft-991 (via
OmniRig) got lost at least ten times within three minutes. I didn't have
such issues with all earlier versions including 2.1.0-rc-5. Will do some
further tests tomorrow. Not yet fully sure whether it is caused allone by
the new rc-6 version or if it is better after rebooting the computer.
However, I started v2.0.1 for comparison, and with that I saw no CAT
control issues so far.

73 de DG2YCB,
Uwe
_
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB




Am 2. Juni 2019 22:41:25 schrieb Bill Somerville :


HI Jari and Uwe,

so I can get some data points on this issue, can you both try the WSJT-X
v2.1.0 RC6 32-bit Windows version to see if that works any better for you?

73
Bill
G4WJS.

On 02/06/2019 21:07, DG2YCB, Uwe wrote:


Same here. Win 10 64 bit version not starting.

73 de Uwe, DG2YCB

*Von:*Jari A [mailto:oh2...@gmail.com]
*Gesendet:* Sonntag, 2. Juni 2019 20:55
*An:* WSJT software development
*Betreff:* [wsjt-devel] Bug report

win 7 64 bit

Does not start, reboot does not help.

FYI

Best rgds,

:Jari / oh2fqv






--
___
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 report

[Black Michael via wsjt-devel]

So please send in your regular WSJT-X.ini file and the team can likely figure 
out the problem.
Mike

 

On Sunday, June 2, 2019, 3:45:11 PM CDT, Fred Price  
wrote:  
 
 Mike,Stating with WSJT -r test let me run RC6. Otherwise it doesn't open 
without the new config.Windows 7 UltimateWSJT-X 2.1.0RC6 64 bit
ThanksFredN2XK
On Jun 2, 2019 4:33 PM, Black Michael via wsjt-devel 
 wrote:

Hmmm...64-bit version RC6 working here.
Can you try starting yours with a new config and see if that fixes it?e.g.wsjtx 
-r test
de Mike W9MDB

On Sunday, June 2, 2019, 3:11:48 PM CDT, DG2YCB, Uwe  wrote: 


Same here. Win 10 64 bit version not starting.

 

73 de Uwe, DG2YCB 

 

Von: Jari A [mailto:oh2...@gmail.com]
Gesendet: Sonntag, 2. Juni 2019 20:55
An: WSJT software development
Betreff: [wsjt-devel] Bug report

 

win 7 64 bit

 

Does not start, reboot does not help.

 

FYI

 

Best rgds,

 

:Jari / oh2fqv

 

 

---

 

 

Problem signature:

  Problem Event Name: APPCRASH
  Application Name: wsjtx.exe
  Application Version: 0.0.0.0
  Application Timestamp: 5cf07e87
  Fault Module Name: wsjtx.exe
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp: 5cf07e87
  Exception Code: c005
  Exception Offset: 0027cc44
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 1035
  Additional Information 1: deed
  Additional Information 2: deed2ee1fb10a9245a68e6f47ba9b087
  Additional Information 3: e981
  Additional Information 4: e98176a476e5df4a870310674973c595
___
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 report

[Fred Price]

Mike,
Stating with WSJT -r test let me run RC6. Otherwise it doesn't open without the 
new config.
Windows 7 Ultimate
WSJT-X 2.1.0RC6 64 bit

Thanks
Fred
N2XK

On Jun 2, 2019 4:33 PM, Black Michael via wsjt-devel 
 wrote:
Hmmm...64-bit version RC6 working here.

Can you try starting yours with a new config and see if that fixes it?
e.g.
wsjtx -r test

de Mike W9MDB


On Sunday, June 2, 2019, 3:11:48 PM CDT, DG2YCB, Uwe  wrote:



Same here. Win 10 64 bit version not starting.



73 de Uwe, DG2YCB



Von: Jari A [mailto:oh2...@gmail.com]
Gesendet: Sonntag, 2. Juni 2019 20:55
An: WSJT software development
Betreff: [wsjt-devel] Bug report



win 7 64 bit



Does not start, reboot does not help.



FYI



Best rgds,



:Jari / oh2fqv





---





Problem signature:

  Problem Event Name: APPCRASH
  Application Name: wsjtx.exe
  Application Version: 0.0.0.0
  Application Timestamp: 5cf07e87
  Fault Module Name: wsjtx.exe
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp: 5cf07e87
  Exception Code: c005
  Exception Offset: 0027cc44
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 1035
  Additional Information 1: deed
  Additional Information 2: deed2ee1fb10a9245a68e6f47ba9b087
  Additional Information 3: e981
  Additional Information 4: e98176a476e5df4a870310674973c595

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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 report

[Bill Somerville]

HI Jari and Uwe,

so I can get some data points on this issue, can you both try the WSJT-X 
v2.1.0 RC6 32-bit Windows version to see if that works any better for you?


73
Bill
G4WJS.

On 02/06/2019 21:07, DG2YCB, Uwe wrote:


Same here. Win 10 64 bit version not starting.

73 de Uwe, DG2YCB

*Von:*Jari A [mailto:oh2...@gmail.com]
*Gesendet:* Sonntag, 2. Juni 2019 20:55
*An:* WSJT software development
*Betreff:* [wsjt-devel] Bug report

win 7 64 bit

Does not start, reboot does not help.

FYI

Best rgds,

:Jari / oh2fqv



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

Re: [wsjt-devel] Bug report

[Black Michael via wsjt-devel]

Hmmm...64-bit version RC6 working here.
Can you try starting yours with a new config and see if that fixes it?e.g.wsjtx 
-r test
de Mike W9MDB 

On Sunday, June 2, 2019, 3:11:48 PM CDT, DG2YCB, Uwe  wrote: 
 
 
 
Same here. Win 10 64 bit version not starting.

  

73 de Uwe, DG2YCB 

  

Von: Jari A [mailto:oh2...@gmail.com] 
Gesendet: Sonntag, 2. Juni 2019 20:55
An: WSJT software development
Betreff: [wsjt-devel] Bug report

  

win 7 64 bit

  

Does not start, reboot does not help.

  

FYI

  

Best rgds,

  

:Jari / oh2fqv

  

  

---

  

  

Problem signature:

  Problem Event Name: APPCRASH
  Application Name: wsjtx.exe
  Application Version: 0.0.0.0
  Application Timestamp: 5cf07e87
  Fault Module Name: wsjtx.exe
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp: 5cf07e87
  Exception Code: c005
  Exception Offset: 0027cc44
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 1035
  Additional Information 1: deed
  Additional Information 2: deed2ee1fb10a9245a68e6f47ba9b087
  Additional Information 3: e981
  Additional Information 4: e98176a476e5df4a870310674973c595
___
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] Bug report

[Jari A]

win 7 64 bit

Does not start, reboot does not help.

FYI

Best rgds,

:Jari / oh2fqv


---


Problem signature:
  Problem Event Name: APPCRASH
  Application Name: wsjtx.exe
  Application Version: 0.0.0.0
  Application Timestamp: 5cf07e87
  Fault Module Name: wsjtx.exe
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp: 5cf07e87
  Exception Code: c005
  Exception Offset: 0027cc44
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 1035
  Additional Information 1: deed
  Additional Information 2: deed2ee1fb10a9245a68e6f47ba9b087
  Additional Information 3: e981
  Additional Information 4: e98176a476e5df4a870310674973c595
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug Report

[Bill Somerville]

On 03/05/2019 01:27, Morris Wideman via wsjt-devel wrote:
Why would I want to call another station on top of someone else. If 
the TX/RX freqs are suppose to locked together thats what they should 
do, I do sometimes operate split but I try not to get on top of 
another station. 73 WA4MIT Morris


On Thursday, May 2, 2019, 5:44:44 PM CDT, Ron Koenig 
 wrote:



Why would you want to TX on his frequency ?

On Thu, 2 May 2019 at 15:30, Morris Wideman via wsjt-devel 
> wrote:


Many thanks to the development team for sharing FT4 with us all.
This faster FT should really help the DXpeditions and Contesters I
think it works great. Thank you all very much.
I do not believe this bug has been previously reported. When you
have answered a CQ (station 1) but get no response then proceed to
call a new station (2) and now station 1 answers you. When you
double click on his call to change to station 1 frequency the
receive channel changes to his freq but the TX does not it will
remain on present freq. Holding down the Ctrl key while double
clicking on station 1 will move both TX & RX and no I did not have
the Hold TX Freq selected it is doing this when it should be
locked together. Included 2 screen shots of this happening. Second
is a late return call from an EK station I have circled my return
to him at this time I was calling the TA station on another freq
as you see my return was on the TA freq not where the EK called me.
Otherwise I have managed to use FT4 RC5 with much success even it
seems to the contrary of the less sensitivity I seem to be reaching EU
with better results using less power?.
My Best 73 Morris WA4MIT


Hi Morris,

WSJT-X assumes you are still in the first QSO, if you want it to release 
the Tx frequency hold that is implicit in a QSO you must tell it you 
have abandoned the QSO. ESC to abort if you are transmitting or F4 is 
sufficient if you are not.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Bug Report

[Morris Wideman via wsjt-devel]

 Why would I want to call another station on top of someone else. If the TX/RX 
freqs are suppose to locked together thats what they should do, I do sometimes 
operate split but I try not to get on top of another station. 73 WA4MIT Morris 
On Thursday, May 2, 2019, 5:44:44 PM CDT, Ron Koenig  
wrote:  
 
 Why would you want to TX on his frequency ? 

On Thu, 2 May 2019 at 15:30, Morris Wideman via wsjt-devel 
 wrote:

Many thanks to the development team for sharing FT4 with us all. This faster FT 
should really help the DXpeditions and Contesters I think it works great. Thank 
you all very much.I do not believe this bug has been previously reported. When 
you have answered a CQ (station 1) but get no response then proceed to call a 
new station (2) and now station 1 answers you. When you double click on his 
call to change to station 1 frequency the receive channel changes to his freq 
but the TX does not it will remain on present freq. Holding down the Ctrl key 
while double clicking on station 1 will move both TX & RX and no I did not have 
the Hold TX Freq selected it is doing this when it should be locked together. 
Included 2 screen shots of this happening. Second is a late return call from an 
EK station I have circled my return to him at this time I was calling the TA 
station on another freq as you see my return was on the TA freq not where the 
EK called me.Otherwise I have managed to use FT4 RC5 with much success even it 
seems to the contrary of the less sensitivity I seem to be reaching EUwith 
better results using less power?.My Best 73 Morris 
WA4MIT___
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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug Report

[Ron Koenig]

Why would you want to TX on his frequency ?

On Thu, 2 May 2019 at 15:30, Morris Wideman via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Many thanks to the development team for sharing FT4 with us all. This
> faster FT should really help the DXpeditions and Contesters I think it
> works great. Thank you all very much.
> I do not believe this bug has been previously reported. When you have
> answered a CQ (station 1) but get no response then proceed to call a new
> station (2) and now station 1 answers you. When you double click on his
> call to change to station 1 frequency the receive channel changes to his
> freq but the TX does not it will remain on present freq. Holding down the
> Ctrl key while double clicking on station 1 will move both TX & RX and no I
> did not have the Hold TX Freq selected it is doing this when it should be
> locked together. Included 2 screen shots of this happening. Second is a
> late return call from an EK station I have circled my return to him at this
> time I was calling the TA station on another freq as you see my return was
> on the TA freq not where the EK called me.
> Otherwise I have managed to use FT4 RC5 with much success even it seems to
> the contrary of the less sensitivity I seem to be reaching EU
> with better results using less power?.
> My Best 73 Morris WA4MIT
> ___
> 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 report? Compound callsign

[Lorin Hollander]

Hi Mike 

Thanks again for your rapid reply, and for the information ..I suspected this 
would be corrected in the next release.

Take care

Lorin

> On Jan 23, 2019, at 12:11 PM, Black Michael via wsjt-devel 
>  wrote:
> 
> It's a bug in the 2.0.0 version where the "Retain" checkbox is not being 
> honored.
> 
> It's been fixed for the next version.
> 
> de Mike W9MDB
> 
> 
> 
> 
> On Wednesday, January 23, 2019, 2:07:38 PM CST, Lorin Hollander 
>  wrote:
> 
> 
> Hi Bill,  Mike and the others who kindly answered my question and addressed 
> this issues so well.  Thank you all for your time and care,  it means a lot. 
> 
> I have returned to the practice of sending CQ DX WA1PGB CM88, and that is 
> working fine.   Thank you again.
> 
> Please, can you help me address the other issue? It is about  the empty  
> Comment and Power fields in the "Log QSO”  pop-up window, Although the 
> windows is now configured differently in vs/ 2.0., is thee a way to autofill 
> these two fields, fields that used to be, at least partially,  autofilled by 
> the program? It is not big deal, but would be faster. 
> 
> Again Many thanks
> 
> Lorin
> 
>> On Jan 23, 2019, at 10:46 AM, Bill Somerville > > wrote:
>> 
> 
> On 23/01/2019 16:24, Lorin Hollander wrote:
>> When sending a CQ DX from the drop down entry box No 5 where I have 
>> previously entered my call  in F2 “Settings “, as the compound WA1PGB/6
> Hi Lorin, sorry clicked "Send" prematurely. Let's try again:
> 
> the way non-standard callsigns are handled in WSJT-X for the new 77-bit FT8 
> and MSK144 modes has completely changed. You have a few options, firstly you 
> do not need to sign /6 when operating from CA, that gives most flexibility as 
> you can use messages like:
> CQ DX WA1PGB CM88
> this both allows you to use directional CQ messages like CQ DX ... or CQ 
>  ..., it also meets the criteria for receiving 
> stations to spot you to PSK Reporter since it has your callsign and a 
> gridsquare.
> 
> If you must use a /6 suffix then you cannot use directional CQ messages nor 
> include you grid in a CQ message. You can only use:
> 
> CQ WA1PGB/6
> If you wish to be spotted on PSK Reporter using your /6 suffix then you must 
> either send a message like:
> 
> G4WJS  CM88
> after a QSO, this this important as your call is encoded as a hash code which 
> can only be translated back to your full callsign if your full callsign has 
> been copied in full recently. You can also get spotted to PSK Reporter when 
> calling CQ by alternating between CQ calls and a message including your 
> gridsquare like this:
> 
> CQ WA1PGB/6
> then in the next Tx slot send:
> 
> DE  CM88
> that combination will ensure that stations receiving both messages will spot 
> you if they have PSK Reporter spotting enabled. You can save this second 
> message as a Tx5 macro for convenient recall with a couple of mouse clicks.
> 
> Sorry if this seems inconvenient compared with previous versions but the 
> uniform way of handling non-standard calls allows many more holders of such 
> calls to use FT8 and MSK144 modes where they simply could not do so 
> previously.
> 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 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 report? Compound callsign

[Black Michael via wsjt-devel]

It's a bug in the 2.0.0 version where the "Retain" checkbox is not being 
honored.
It's been fixed for the next version.
de Mike W9MDB

 

On Wednesday, January 23, 2019, 2:07:38 PM CST, Lorin Hollander 
 wrote:  
 
 Hi Bill,  Mike and the others who kindly answered my question and addressed 
this issues so well.  Thank you all for your time and care,  it means a lot. 
I have returned to the practice of sending CQ DX WA1PGB CM88, and that is 
working fine.   Thank you again.
Please, can you help me address the other issue? It is about  the empty  
Comment and Power fields in the "Log QSO”  pop-up window, Although the windows 
is now configured differently in vs/ 2.0., is thee a way to autofill these two 
fields, fields that used to be, at least partially,  autofilled by the program? 
It is not big deal, but would be faster. 
Again Many thanks
Lorin


On Jan 23, 2019, at 10:46 AM, Bill Somerville  wrote:
 
 On 23/01/2019 16:24, Lorin Hollander wrote:
  
When sending a CQ DX from the drop down entry box No 5 where I have previously 
entered my call  in F2 “Settings “, as the compound WA1PGB/6

Hi Lorin, sorry clicked "Send" prematurely. Let's try again:
 the way non-standard callsigns are handled in WSJT-X for the new 77-bit FT8 
and MSK144 modes has completely changed. You have a few options, firstly you do 
not need to sign /6 when operating from CA, that gives most flexibility as you 
can use messages like: CQ DX WA1PGB CM88

this both allows you to use directional CQ messages like CQ DX ... or CQ 
 ..., it also meets the criteria for receiving 
stations to spot you to PSK Reporter since it has your callsign and a 
gridsquare.

If you must use a /6 suffix then you cannot use directional CQ messages nor 
include you grid in a CQ message. You can only use:
 CQ WA1PGB/6

If you wish to be spotted on PSK Reporter using your /6 suffix then you must 
either send a message like:
 G4WJS  CM88

after a QSO, this this important as your call is encoded as a hash code which 
can only be translated back to your full callsign if your full callsign has 
been copied in full recently. You can also get spotted to PSK Reporter when 
calling CQ by alternating between CQ calls and a message including your 
gridsquare like this:
 CQ WA1PGB/6

then in the next Tx slot send:
 DE  CM88

that combination will ensure that stations receiving both messages will spot 
you if they have PSK Reporter spotting enabled. You can save this second 
message as a Tx5 macro for convenient recall with a couple of mouse clicks.

Sorry if this seems inconvenient compared with previous versions but the 
uniform way of handling non-standard calls allows many more holders of such 
calls to use FT8 and MSK144 modes where they simply could not do so previously.
 

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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug report? Compound callsign

[Bill Somerville]

On 23/01/2019 20:02, Lorin Hollander wrote:
Please, can you help me address the other issue? It is about  the 
empty  Comment and Power fields in the "Log QSO”  pop-up window, 
Although the windows is now configured differently in vs/ 2.0., is 
thee a way to autofill these two fields, fields that used to be, at 
least partially,  autofilled by the program? It is not big deal, but 
would be faster. 


Hi Lorin,

those fields have an option to retain their prior values, there is a 
known defect in WSJT-X v2.0.0 that means they don't pick up new values 
typed in, this 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

Re: [wsjt-devel] Bug report? Compound callsign

[Lorin Hollander]

Hi Bill,  Mike and the others who kindly answered my question and addressed 
this issues so well.  Thank you all for your time and care,  it means a lot. 

I have returned to the practice of sending CQ DX WA1PGB CM88, and that is 
working fine.   Thank you again.

Please, can you help me address the other issue? It is about  the empty  
Comment and Power fields in the "Log QSO”  pop-up window, Although the windows 
is now configured differently in vs/ 2.0., is thee a way to autofill these two 
fields, fields that used to be, at least partially,  autofilled by the program? 
It is not big deal, but would be faster. 

Again Many thanks

Lorin

> On Jan 23, 2019, at 10:46 AM, Bill Somerville  wrote:
> 
> On 23/01/2019 16:24, Lorin Hollander wrote:
>> When sending a CQ DX from the drop down entry box No 5 where I have 
>> previously entered my call  in F2 “Settings “, as the compound WA1PGB/6
> Hi Lorin, sorry clicked "Send" prematurely. Let's try again:
> 
> the way non-standard callsigns are handled in WSJT-X for the new 77-bit FT8 
> and MSK144 modes has completely changed. You have a few options, firstly you 
> do not need to sign /6 when operating from CA, that gives most flexibility as 
> you can use messages like:
> CQ DX WA1PGB CM88
> this both allows you to use directional CQ messages like CQ DX ... or CQ 
>  ..., it also meets the criteria for receiving 
> stations to spot you to PSK Reporter since it has your callsign and a 
> gridsquare.
> 
> If you must use a /6 suffix then you cannot use directional CQ messages nor 
> include you grid in a CQ message. You can only use:
> 
> CQ WA1PGB/6
> If you wish to be spotted on PSK Reporter using your /6 suffix then you must 
> either send a message like:
> 
> G4WJS  CM88
> after a QSO, this this important as your call is encoded as a hash code which 
> can only be translated back to your full callsign if your full callsign has 
> been copied in full recently. You can also get spotted to PSK Reporter when 
> calling CQ by alternating between CQ calls and a message including your 
> gridsquare like this:
> 
> CQ WA1PGB/6
> then in the next Tx slot send:
> 
> DE  CM88
> that combination will ensure that stations receiving both messages will spot 
> you if they have PSK Reporter spotting enabled. You can save this second 
> message as a Tx5 macro for convenient recall with a couple of mouse clicks.
> 
> Sorry if this seems inconvenient compared with previous versions but the 
> uniform way of handling non-standard calls allows many more holders of such 
> calls to use FT8 and MSK144 modes where they simply could not do so 
> previously.
> 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 report? Compound callsign

[Bill Somerville]

On 23/01/2019 16:24, Lorin Hollander wrote:
When sending a CQ DX from the drop down entry box No 5 where I have 
previously entered my call  in F2 “Settings “, as the compound WA1PGB/6


Hi Lorin, sorry clicked "Send" prematurely. Let's try again:

the way non-standard callsigns are handled in WSJT-X for the new 77-bit 
FT8 and MSK144 modes has completely changed. You have a few options, 
firstly you do not need to sign /6 when operating from CA, that gives 
most flexibility as you can use messages like:


CQ DX WA1PGB CM88

this both allows you to use directional CQ messages like CQ DX ... or CQ 
 ..., it also meets the criteria for 
receiving stations to spot you to PSK Reporter since it has your 
callsign and a gridsquare.


If you must use a /6 suffix then you cannot use directional CQ messages 
nor include you grid in a CQ message. You can only use:


CQ WA1PGB/6

If you wish to be spotted on PSK Reporter using your /6 suffix then you 
must either send a message like:


G4WJS  CM88

after a QSO, this this important as your call is encoded as a hash code 
which can only be translated back to your full callsign if your full 
callsign has been copied in full recently. You can also get spotted to 
PSK Reporter when calling CQ by alternating between CQ calls and a 
message including your gridsquare like this:


CQ WA1PGB/6

then in the next Tx slot send:

DE  CM88

that combination will ensure that stations receiving both messages will 
spot you if they have PSK Reporter spotting enabled. You can save this 
second message as a Tx5 macro for convenient recall with a couple of 
mouse clicks.


Sorry if this seems inconvenient compared with previous versions but the 
uniform way of handling non-standard calls allows many more holders of 
such calls to use FT8 and MSK144 modes where they simply could not do so 
previously.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Bug report? Compound callsign

[Bill Somerville]

On 23/01/2019 16:24, Lorin Hollander wrote:
When sending a CQ DX from the drop down entry box No 5 where I have 
previously entered my call  in F2 “Settings “, as the compound WA1PGB/6


Hi Lorin,

the way non-standard callsigns are handled in WSJT-X for the new 77-bit 
FT8 and MSK144 modes has completely changed. You have a few options, 
firstly you do not need to sign /6 when operating from CA, that gives 
most flexibility as you can use messages like:


CQ DX WA1PGB CM88

this both allows you to use directional CQ messages like CQ DX ... or CQ 
 ..., it also meets the criteria for 
receiving stations to spot you to PSK Reporter since it has your 
callsign and a gridsquare.


If you must use a /6 suffix then you cannot use directional CQ messages 
nor include you grid in a CQ message. You can only use:


CQ WA1PGB/6

If you wish to be spotted on PSK Reporter using your /6 suffix then you 
must either send a message like:


G4WJS  CM88

after a QSO, this this important as your call is encoded as a hash code 
which can only be translated back to your full callsign if your full 
callsign has been copied in full recently. You can also get spotted to 
PSK Reporter when calling CQ by alternating between CQ calls and a 
message including your gridsquare like this:


CQ WA1PGB/6

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

Re: [wsjt-devel] Bug report? Compound callsign

[Claude Frantz]

On 1/23/19 5:46 PM, Roy Gould wrote:

Hi Roy & all,

This happens to me once in a while. I don't know what call sign was 
supposed to be there so I delete the whole record and save the file and 
then everything seems to be OK.


When you reread an ADIF file, it should not contain obvious errors, of 
course. Zero length fields are superfluous, but they can induce the 
reading software in error, if the software is unstable.


If I understand well, there is a bug in release 2.0.0 which produces an 
unexpected behaviour when reading blank lines in an ADIF file. In such a 
case, simply suppress any empty line.


Please allow we to point to the software package named adifmerg. 
Unfortunately it's not more maintained at the present time. There is a 
function allowing to test an ADIF file. This package is highly portable 
because it's using PERL.


Best wishes,
Claude (DJ0OT)


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

Re: [wsjt-devel] Bug report? Compound callsign

[Black Michael via wsjt-devel]

I can confirm "CQ DX WA1PGB/6" works in 1.9.1 but not 2.0.0...you're solution 
right now is to drop the "DX" and the grid.  The grid doesn't work either and 
drops the suffix.  In 1.9.1 it dropped the grid and kept the suffix.
C:\WSJT\wsjtx\bin>ft8code.exe "CQ WA1PGB/6 EM49"    Message                     
          Decoded                             Err 
i3.n3
 1. CQ WA1PGB/6 EM49                      CQ WA1PGB EM49                        
*  1.  Standard msg
Message 
bits:001001110011011100110111110001001
Channel symbols 
(tones):31406521142250227405100337453140652213105746034570264251142501673140652

C:\WSJT\wsjtx191\bin>ft8code.exe "CQ DX WA1PGB/6"    Message                
Decoded              Err? 
Type
 1. CQ DX WA1PGB/6         CQ DX WA1PGB/6           0 3 Type 1 sfx
Call1: 010101100010010011111001    Call2: 110110100010011001101001Grid: 
 000011101101   3Bit: 000    CRC12: 11101110
Channel 
symbols:2560413072463555156352103016455366002560413254223034732114772274355073402560413
C:\WSJT\wsjtx191\bin>ft8code.exe "CQ DX WA1PGB/6"
C:\WSJT\wsjtx191\bin>cd ..\..\wsjtx\bin
C:\WSJT\wsjtx\bin>ft8code.exe "CQ DX WA1PGB/6"    Message                       
        Decoded                             Err 
i3.n3
 1. CQ DX WA1PGB/6                        CQ DX WA1PGB/                         
*  0.0 Free text
Message 
bits:001011001001000100100111011100011001001011001001011000101
Channel symbols 
(tones):3140652121105573040043343351060007153140652415165641711443042512754712473140652

de Mike W9MDB
 

On Wednesday, January 23, 2019, 10:28:28 AM CST, Lorin Hollander 
 wrote:  
 
 Hello,
I have been successfully using FT-8 in vs 1.9 for several months with no 
problems or issues.  I have now been using vs. 2.0 in the latest iteration, I 
believe, and have run into what seems like a bug, although I cannot be sure. 
   
   -  I am running WSJT-X 2.0 on a MacBook Pro with OS X High Sierra, within 
Parallels Desktop 13.  And Windows 10. 64 bit.   
The Issue:    
When sending a CQ DX from the drop down entry box No 5 where I have previously 
entered my call  in F2 “Settings “, as the compound WA1PGB/6 - something I did 
without problem in vs 1.9. When this CQ DX is sent,  it appears in the right  
“Transmitted" window as 'WA1PGB/   ‘  blank, unfinished, without “6” or any 
number appearing after the  ‘/ ‘.  (See screenshot below) This conforms, of 
course, to the 13 character limit,  but I do not remember it  behaving  this 
way, for me at least, in the previous version. I was always able to send “CQ DX 
WA1PGB/6 complete, even though it is 14 characters . And I have routinely 
decoded a number of other stations calling “CQ DX KK5XXX/5 “ even including 
“CM88” in the left hand decoded window. I have checked that the “My Call”  is 
entered correctly everywhere it is called upon in the documentation  to enter, 
both in the F2 Setup panels as well as in the “on the fly” TX  No. 5 drop down 
menu.   This  leaving out  of, or blank final 14th final space appears to be, 
in fact,  intermittent. As occasionally the transmission will indeed go out ( 
at least will appear to go out) with 14 or even with 19  characters including 
the Grid square. .    
Also, I have checked in PSK reporter  - which has frequently displayed wide 
reception of my FT8 transmissions, and the results are very unpredictable : 
when checking  for “WA1PGB/6” there will often be  no reception reports at all 
If I enter only “WA1PGB” there will be far more  reception reports.   And if I 
enter WA1PGB/ , the way it appears in the righthand column, there will be zero 
reception reports. Other times PSK REP distinguishes between reports for the 
call with and without “/6. “ displaying different times and reception reports.  
  
Please let me know if there is a workaround  for the compound call, a way to 
transmit CQ DX WA1PGB/6 (and even to include “CM88” . I have received messages, 
and emails from fellow Amateurs that inform me that it is “confusing” to them 
to see “WA1PGB" without the “/6” suffix as they believe I am still located at  
my Maine home location despite my use of the accurate grid square.    
Many thanks for your assistance.     
Lorin Hollander   
WA1PGB    
   

___
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 report? Compound callsign

[Black Michael via wsjt-devel]

It appears that was just one record where you didn't have the callsign in the 
"DX Call" box in WSJT-X.
That first field is your QSO partner's callsign.
Mike 

On Wednesday, January 23, 2019, 10:31:26 AM CST, Lorin Hollander 
 wrote:  
 
 Many thanks Mike for this information and advice. 
And as to where I should enter station snd personal information so that this 
will be included as autofill in the Log Window fields?  Where do I enter that 
data? 
Thanks again
Lorin

Sent from my iPhone
On Jan 23, 2019, at 7:45 AM, Black Michael via wsjt-devel 
 wrote:


The error tells you -- that record has no call sign.  Edit the log file and 
remove the record.
The ADIF parsing has been relaxed for the next version but not sure what it 
will do a record like this.
Perhaps Bill knows.
de Mike W9MDB

 

On Wednesday, January 23, 2019, 9:40:35 AM CST, Lorin Hollander 
 wrote:  
 
 Hello,

I am a new member of this group.

I receive the following error (see screenshot below) when starting WSJT-X  FT8 
vs 2.0 in Windows 10.    What is the process to correct this. Also,  the 
previous versions always autofilled most of the fields in the Log Contact 
window (Power - etc.) and now, after a few hours they are mostly blank,  Where 
do I enter this station data so that I return to having these autofilled? Is 
this related to the error mentioned above?

Many thanks

Lorin 

WA1PGB












Sent from my iPhone
___
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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug report? Compound callsign

[Lorin Hollander]

Many thanks Mike for this information and advice. 

And as to where I should enter station snd personal information so that this 
will be included as autofill in the Log Window fields?  Where do I enter that 
data? 

Thanks again

Lorin

Sent from my iPhone

> On Jan 23, 2019, at 7:45 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> The error tells you -- that record has no call sign.  Edit the log file and 
> remove the record.
> 
> The ADIF parsing has been relaxed for the next version but not sure what it 
> will do a record like this.
> 
> Perhaps Bill knows.
> 
> de Mike W9MDB
> 
> 
> 
> 
> On Wednesday, January 23, 2019, 9:40:35 AM CST, Lorin Hollander 
>  wrote:
> 
> 
> Hello,
> 
> I am a new member of this group.
> 
> I receive the following error (see screenshot below) when starting WSJT-X  
> FT8 vs 2.0 in Windows 10.What is the process to correct this. Also,  the 
> previous versions always autofilled most of the fields in the Log Contact 
> window (Power - etc.) and now, after a few hours they are mostly blank,  
> Where do I enter this station data so that I return to having these 
> autofilled? Is this related to the error mentioned above?
> 
> Many thanks
> 
> Lorin 
> 
> WA1PGB
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Sent from my iPhone
> ___
> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Bug report? Compound callsign

[Lorin Hollander]

Hello,

I have been successfully using FT-8 in vs 1.9 for several months with no 
problems or issues.  I have now been using vs. 2.0 in the latest iteration, I 
believe, and have run into what seems like a bug, although I cannot be sure. 

 I am running WSJT-X 2.0 on a MacBook Pro with OS X High Sierra, within 
Parallels Desktop 13.  And Windows 10. 64 bit.

The Issue: 

When sending a CQ DX from the drop down entry box No 5 where I have previously 
entered my call  in F2 “Settings “, as the compound WA1PGB/6 - something I did 
without problem in vs 1.9. When this CQ DX is sent,  it appears in the right  
“Transmitted" window as 'WA1PGB/   ‘  blank, unfinished, without “6” or any 
number appearing after the  ‘/ ‘.  (See screenshot below) This conforms, of 
course, to the 13 character limit,  but I do not remember it  behaving  this 
way, for me at least, in the previous version. I was always able to send “CQ DX 
WA1PGB/6 complete, even though it is 14 characters . And I have routinely 
decoded a number of other stations calling “CQ DX KK5XXX/5 “ even including 
“CM88” in the left hand decoded window. I have checked that the “My Call”  is 
entered correctly everywhere it is called upon in the documentation  to enter, 
both in the F2 Setup panels as well as in the “on the fly” TX  No. 5 drop down 
menu.   This  leaving out  of, or blank final 14th final space appears to be, 
in fact,  intermittent. As occasionally the transmission will indeed go out ( 
at least will appear to go out) with 14 or even with 19  characters including 
the Grid square. . 

Also, I have checked in PSK reporter  - which has frequently displayed wide 
reception of my FT8 transmissions, and the results are very unpredictable : 
when checking  for “WA1PGB/6” there will often be  no reception reports at all 
If I enter only “WA1PGB” there will be far more  reception reports.   And if I 
enter WA1PGB/ , the way it appears in the righthand column, there will be zero 
reception reports. Other times PSK REP distinguishes between reports for the 
call with and without “/6. “ displaying different times and reception reports. 

Please let me know if there is a workaround  for the compound call, a way to 
transmit CQ DX WA1PGB/6 (and even to include “CM88” . I have received messages, 
and emails from fellow Amateurs that inform me that it is “confusing” to them 
to see “WA1PGB" without the “/6” suffix as they believe I am still located at  
my Maine home location despite my use of the accurate grid square. 

Many thanks for your assistance.  

Lorin Hollander

WA1PGB 



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

Re: [wsjt-devel] Bug report? Compound callsign

[Black Michael via wsjt-devel]

The error tells you -- that record has no call sign.  Edit the log file and 
remove the record.
The ADIF parsing has been relaxed for the next version but not sure what it 
will do a record like this.
Perhaps Bill knows.
de Mike W9MDB

 

On Wednesday, January 23, 2019, 9:40:35 AM CST, Lorin Hollander 
 wrote:  
 
 Hello,

I am a new member of this group.

I receive the following error (see screenshot below) when starting WSJT-X  FT8 
vs 2.0 in Windows 10.    What is the process to correct this. Also,  the 
previous versions always autofilled most of the fields in the Log Contact 
window (Power - etc.) and now, after a few hours they are mostly blank,  Where 
do I enter this station data so that I return to having these autofilled? Is 
this related to the error mentioned above?

Many thanks

Lorin 

WA1PGB












Sent from my iPhone
___
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] Bug report? Compound callsign

[Lorin Hollander]

Hello,

I am a new member of this group.

I receive the following error (see screenshot below) when starting WSJT-X  FT8 
vs 2.0 in Windows 10.What is the process to correct this. Also,  the 
previous versions always autofilled most of the fields in the Log Contact 
window (Power - etc.) and now, after a few hours they are mostly blank,   Where 
do I enter this station data so that I return to having these autofilled? Is 
this related to the error mentioned above?

Many thanks

Lorin 

WA1PGB













Sent from my iPhone
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] : Bug report - non urgent- WSJT-X V2.0.0 build 784f75 - comments and power not sticky.

[Black Michael via wsjt-devel]

Known bug.  Already fixed in next version.
de Mike W9MDB

 

On Thursday, December 27, 2018, 6:36:41 AM CST, VE3FBZ  
wrote:  
 
 

Begin forwarded message:


From: VE3FBZ 
Date: December 26, 2018 at 12:50:54 PM EST
To: wsjtgr...@yahoogroups.com
Subject: Bug report  - non urgent- WSJT-X V2.0.0 build 784f75 - comments and 
power not sticky.



I have found both comments and power level shown on logging window are not 
sticky although checked.
Comments can be changed but revert back on next log report.

Comments are always what is in the config file section - 
[LogQSO]
SaveTXPower=true
SaveComments=true.
LogComments=xx - whatever text.

Changing comments here will appear on all log window pop up regardless how they 
have been modified from QSO to QSO. 

I have closed the Pgm with exit,X or with JTALERT  with no change in behavior.

If mentioned before, apologize for another notification. 


Keep up the good work. Kudos.

Happy New Year.

Regards and 73s
VE3FBZ
London Amateur Radio Club
www.larc.ca 




 Regards and 73sVE3FBZLondon Amateur Radio Clubwww.larc.ca 




___
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] : Bug report - non urgent- WSJT-X V2.0.0 build 784f75 - comments and power not sticky.

[VE3FBZ]

Begin forwarded message:

> From: VE3FBZ 
> Date: December 26, 2018 at 12:50:54 PM EST
> To: wsjtgr...@yahoogroups.com
> Subject: Bug report  - non urgent- WSJT-X V2.0.0 build 784f75 - comments and 
> power not sticky.
> 
> I have found both comments and power level shown on logging window are not 
> sticky although checked.
> Comments can be changed but revert back on next log report.
> 
> Comments are always what is in the config file section - 
> [LogQSO]
> SaveTXPower=true
> SaveComments=true.
> LogComments=xx - whatever text.
> 
> Changing comments here will appear on all log window pop up regardless how 
> they have been modified from QSO to QSO. 
> 
> I have closed the Pgm with exit,X or with JTALERT  with no change in behavior.
> 
> If mentioned before, apologize for another notification. 
> 
> 
> Keep up the good work. Kudos.
> 
> Happy New Year.
> 
> Regards and 73s
> VE3FBZ
> London Amateur Radio Club
> www.larc.ca 
> 
> 

 Regards and 73s
VE3FBZ
London Amateur Radio Club
www.larc.ca 




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

Re: [wsjt-devel] Bug Report

[Bill Somerville]

On 20/12/2018 14:23, Gene H wrote:


A friend of mine also has same issue with his ICOM IC-7600 using Fake 
It. He went back to Split to get around the issue.


73 Gene K5PA


Hi Gene,

problems with Icom CAT control are often due to not disabling "CI-V 
Transceive Mode" on the rig.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Bug Report

[Gene H]

A friend of mine also has same issue with his ICOM IC-7600 using Fake 
It. He went back to Split to get around the issue.


73 Gene K5PA

On 12/20/2018 8:15 AM, Steven Greer wrote:
Hey bill last time we touched base on this was right after release and 
you mentions you could send me a build with CAT trace enabled, if you 
could that would be great.  I did notice that another user was using 
ft-857d interface and had the same problem.  I have been able to 
connect directly to the interface with wsjt-x and also while using 
rigctl.  Both ways have the same outcome, jumps freqs when using fake 
split.  I tried to enable a mirror to see what was passing however 
wsjtx won't connect to the radio because it's not responding fast 
enough.  I'm using Debian 9 64bit


On 12/10/18 10:17 AM, Bill Somerville wrote:

On 10/12/2018 15:12, Steven Greer wrote:
It has whatever I put into serial debug, however I have to you a 
serial monitor to listen in between. I can tell it println vfo when 
PTT changes.  It's my own compilation, the ft857 Library is kinda 
separate, it is just a primer to getting started with the Library 
it's self.  I'm working on trying to get the native split working 
however I'm more of a novice coder so I spend a lot of trial and 
error testing making things work by using examples.


Hi Steven,

RR, if you can isolate the CAT sequence that causes the unexpected 
jump that would help. Otherwise I can send you a build of WSJT-X with 
CAT trace enabled which may help.


73
Bill
G4WJS.



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



--
Gene Hinkle
2026 Spyglass Hill, Leander, TX 78641
e-mail to Gene:  ghin...@gmail.com
cell phone or text messaging:  (512) 413-9251
--




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

Re: [wsjt-devel] Bug Report

[Bill Somerville]

On 20/12/2018 14:15, Steven Greer wrote:
I tried to enable a mirror to see what was passing however wsjtx won't 
connect to the radio because it's not responding fast enough.


Hi Steven,

some emulators use a device with a built in bootloader that is active 
for a second or two after a chip reset, these can cause Hamlib to reject 
an initial connection because retries are exhausted before the 
bootloader jumps to the emulation. We can help with this within reason 
by either adding more retries in Hamlib or possibly an extended delay on 
start up.


I will send you a direct e-mail with details of how to enable trace 
since you are building yourself on Debian 9.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Bug Report

[Steven Greer]

Hey bill last time we touched base on this was right after release and 
you mentions you could send me a build with CAT trace enabled, if you 
could that would be great.  I did notice that another user was using 
ft-857d interface and had the same problem.  I have been able to connect 
directly to the interface with wsjt-x and also while using rigctl.  Both 
ways have the same outcome, jumps freqs when using fake split.  I tried 
to enable a mirror to see what was passing however wsjtx won't connect 
to the radio because it's not responding fast enough.  I'm using Debian 
9 64bit


On 12/10/18 10:17 AM, Bill Somerville wrote:

On 10/12/2018 15:12, Steven Greer wrote:
It has whatever I put into serial debug, however I have to you a 
serial monitor to listen in between.  I can tell it println vfo when 
PTT changes.  It's my own compilation, the ft857 Library is kinda 
separate, it is just a primer to getting started with the Library 
it's self.  I'm working on trying to get the native split working 
however I'm more of a novice coder so I spend a lot of trial and 
error testing making things work by using examples.


Hi Steven,

RR, if you can isolate the CAT sequence that causes the unexpected 
jump that would help. Otherwise I can send you a build of WSJT-X with 
CAT trace enabled which may help.


73
Bill
G4WJS.



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


--
Steven Greer
KM4OUS
OMISS #10630

NOTE: This e-mail was made with 100% recycled electrons.  No electrons were 
harmed, No trees were destroyed, No animals were killed, and No political 
correctness was observed in making or sending this message.



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