[wsjt-devel] where is 2.1.0-rc5 in git repo?

[Christopher Hoover]

I don't see 2.1.0-rc5 in the git at the https://git.code.sf.net/p/wsjt/wsjtx

Am I doing something wrong?  (I use git professionally everyday so I think
I've pulled the remote properly.)

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

Re: [wsjt-devel] Possible bug in WSJTX 2.1.0-RC5 Log-Qso

[Matthew Miller]

Not a bug?  Why has a simple user interface been made very non-user friendly?

I have reasonably good vision and it trips me up, it seems like an 
accessibility nightmare for anyone with less than perfect vision.  If the 
buttons have to move around, it seems like some other accessibility change 
should be made, such as color coding them (also taking into account what colors 
people who may be colorblind can differentiate).

For a mode that seems like it’s intended for contests this sounds like a good 
way to lose a lot of contacts.  I know how hard it is keeping straight 
macro-buttons that don’t dance around while trying to stay awake thru the night 
on field day, I can only imagine how hard it is to hit a moving target.
-Matt / KK4NDE

From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Monday, April 29, 2019 10:34 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Possible bug in WSJTX 2.1.0-RC5 Log-Qso

On 30/04/2019 02:39, Matthew Miller wrote:
I’ve been attempting to test the FT4 mode out tonight  and I think I got it 
working but I think there’s a bug in the logging window, it seems the OK and 
Cancel buttons randomly change positions.  I didn’t really notice until several 
QSOs in and about the time my finger was releasing the mouse button my brain 
processed “wait that thing you clicked was too long to be OK maybe it was 
cancel”.

After stopping for a few minutes to review my log and my scrollback sure enough 
I had missed one qso completely and had to hand re-create it from the message 
history.

Sure enough, after carefully taking note of the next few QSOs not only do the 
buttons bounce around left/right in the window but they also sometimes swap 
positions as to whether OK is to the right or left of Cancel.

-Matt / KK4NDE

Hi Matt,

it is not a bug.

73
Bill
G4WJS.


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

Re: [wsjt-devel] Possible bug in WSJTX 2.1.0-RC5 Log-Qso

[Bill Somerville]

On 30/04/2019 02:39, Matthew Miller wrote:


I’ve been attempting to test the FT4 mode out tonight  and I think I 
got it working but I think there’s a bug in the logging window, it 
seems the OK and Cancel buttons randomly change positions.  I didn’t 
really notice until several QSOs in and about the time my finger was 
releasing the mouse button my brain processed “wait that thing you 
clicked was too long to be OK maybe it was cancel”.


After stopping for a few minutes to review my log and my scrollback 
sure enough I had missed one qso completely and had to hand re-create 
it from the message history.


Sure enough, after carefully taking note of the next few QSOs not only 
do the buttons bounce around left/right in the window but they also 
sometimes swap positions as to whether OK is to the right or left of 
Cancel.


-Matt / KK4NDE


Hi Matt,

it is not a bug.

73
Bill
G4WJS.

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

[wsjt-devel] Possible bug in WSJTX 2.1.0-RC5 Log-Qso

[Matthew Miller]

I’ve been attempting to test the FT4 mode out tonight  and I think I got it 
working but I think there’s a bug in the logging window, it seems the OK and 
Cancel buttons randomly change positions.  I didn’t really notice until several 
QSOs in and about the time my finger was releasing the mouse button my brain 
processed “wait that thing you clicked was too long to be OK maybe it was 
cancel”.

After stopping for a few minutes to review my log and my scrollback sure enough 
I had missed one qso completely and had to hand re-create it from the message 
history.

Sure enough, after carefully taking note of the next few QSOs not only do the 
buttons bounce around left/right in the window but they also sometimes swap 
positions as to whether OK is to the right or left of Cancel.

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

Re: [wsjt-devel] K4SHQ audio question

[Dan Malcolm]

Yep.  I have already done that and found you are right.  Problem fixed.  I 
still have an echo problem with Audio Enhancements Off.  But that’s not a 
problem for this forum.

Thanks Bill

__
Dan – K4SHQ

From: Bill Turner via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Sent: Monday, April 29, 2019 7:29 PM
To: WSJT software development 
Cc: Bill Turner 
Subject: [wsjt-devel] K4SHQ audio question

Sounds like an update issue, time to reboot the computer.

Bill, W4WNT

On Monday, April 29, 2019, 8:01:13 PM EDT, Dan Malcolm 
mailto:k4...@outlook.com>> wrote:


Voicemeeter Banana

__
Dan – K4SHQ


-Original Message-
From: Bill Somerville 
[mailto:g4...@classdesign.com]
Sent: Monday, April 29, 2019 4:52 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.1.0-rc5

On 29/04/2019 22:43, Dan Malcolm wrote:
> Just installed WSJT-X 2.1.0 RC5 x64 on my Win10 x64 machine.  Tx works and 
> seems to be OK, but something rerouted audio from VMB to my system speakers.  
> No audio received by WSJT-X (either in RC5 or 2.0.2 ) , but I can sure hear 
> the caterwauling in the speakers.  The best I can tell, Win10's wonderful 
> audio routing system (App volume and device preferences) is set correctly.  
> FWIW I am running VMB 2.0.4.7.
>
> Prior to installing RC5 everything was working fine.
>
> __
> Dan – K4SHQ

Hi Dan,

what is VMB?

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] WSJT-X 2.1.0-rc5

[Dan Malcolm]

All is not without problems.  I didn't have any know pending updates, and 
WSJT-X 2.0.1 is working again but I am left with an echo.  Audio enhancements 
are turned off, and the echo persists.  Unless you have something off the top 
of your head, I rather not eat up forum bandwidth on this issue.  I will find a 
fix somewhere.

Thanks Bill

__
Dan – K4SHQ

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Monday, April 29, 2019 7:19 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.1.0-rc5

Hi Dan,

glad to here that as I have nothing else! Windows 10 seems to behave very badly 
when there are pending updates to install.

73
Bill
G4WJS.

On 30/04/2019 01:15, Dan Malcolm wrote:
> Should have done this before asking. A reboot of the computer did the trick.  
> Thanks Bill.
>
> __
> Dan – K4SHQ
>
> -Original Message-
> From: Dan Malcolm [mailto:k4...@outlook.com]
> Sent: Monday, April 29, 2019 6:58 PM
> To: 'WSJT software development' 
> Subject: Re: [wsjt-devel] WSJT-X 2.1.0-rc5
>
> Voicemeeter Banana
>
> __
> Dan – K4SHQ
>
>
> -Original Message-
> From: Bill Somerville [mailto:g4...@classdesign.com]
> Sent: Monday, April 29, 2019 4:52 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] WSJT-X 2.1.0-rc5
>
> On 29/04/2019 22:43, Dan Malcolm wrote:
>> Just installed WSJT-X 2.1.0 RC5 x64 on my Win10 x64 machine.  Tx works and 
>> seems to be OK, but something rerouted audio from VMB to my system speakers. 
>>  No audio received by WSJT-X (either in RC5 or 2.0.2 ) , but I can sure hear 
>> the caterwauling in the speakers.  The best I can tell, Win10's wonderful 
>> audio routing system (App volume and device preferences) is set correctly.  
>> FWIW I am running VMB 2.0.4.7.
>>
>> Prior to installing RC5 everything was working fine.
>>
>> __
>> Dan – K4SHQ
> Hi Dan,
>
> what is VMB?
>
> 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] Halt Tx Button

[Neil Zampella]

Hi all,

trying to stop a Tx by clicking the Halt Tx button, it stopped the rig,
but did NOT reset the Enable Tx, and actually caused a couple of entries
in the RxFrequency window when I clicked it twice.

Tested it under FT8 mode, and it works normally there. V2.1.0-RC5 64 bit.

Neil, KN3ILZ


---
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] WSJT-X 2.1.0-rc5

[V. Scott Moore via wsjt-devel]

Gents:

Thanks for the responses.  Will put that one in the trash and go to quiet mode 
till the next release . . . . 

Scott
W1SSN

> On Apr 29, 2019, at 20:15, David Tiller  wrote:
> 
> To avoid the OS X crash, manually enter a fake 3 character grid and then the 
> call of the other station. At that point everything works as expected 
> (generate msgs, etc). 
> 



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[David Tiller]

To avoid the OS X crash, manually enter a fake 3 character grid and then the 
call of the other station. At that point everything works as expected (generate 
msgs, etc). 

> On Apr 29, 2019, at 20:00, Dan Malcolm  wrote:
> 
> Voicemeeter Banana
> 
> __
> Dan – K4SHQ
> 
> 
> -Original Message-
> From: Bill Somerville [mailto:g4...@classdesign.com] 
> Sent: Monday, April 29, 2019 4:52 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] WSJT-X 2.1.0-rc5
> 
>> On 29/04/2019 22:43, Dan Malcolm wrote:
>> Just installed WSJT-X 2.1.0 RC5 x64 on my Win10 x64 machine.  Tx works and 
>> seems to be OK, but something rerouted audio from VMB to my system speakers. 
>>  No audio received by WSJT-X (either in RC5 or 2.0.2 ) , but I can sure hear 
>> the caterwauling in the speakers.  The best I can tell, Win10's wonderful 
>> audio routing system (App volume and device preferences) is set correctly.  
>> FWIW I am running VMB 2.0.4.7.
>> 
>> Prior to installing RC5 everything was working fine.
>> 
>> __
>> Dan – K4SHQ
> 
> Hi Dan,
> 
> what is VMB?
> 
> 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] wsjtx 2.1.0-rc5 Mac version

[Bill Somerville]

On 30/04/2019 01:23, V. Scott Moore via wsjt-devel wrote:

Anyone having issues with the Mac version?


Hi Scott,

welcome to the group!

There is a known issue with the macOS version of WSJT-X v2.1.0 RC5 
crashing when a DX Grid is entered. We are working on diagnosis and a 
fix. Apologies for defect.


73
Bill
G4WJS.



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

[wsjt-devel] K4SHQ audio question

[Bill Turner via wsjt-devel]

 Sounds like an update issue, time to reboot the computer.
Bill, W4WNT

On Monday, April 29, 2019, 8:01:13 PM EDT, Dan Malcolm  
wrote:  
 
 Voicemeeter Banana

__
Dan – K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Monday, April 29, 2019 4:52 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.1.0-rc5

On 29/04/2019 22:43, Dan Malcolm wrote:
> Just installed WSJT-X 2.1.0 RC5 x64 on my Win10 x64 machine.  Tx works and 
> seems to be OK, but something rerouted audio from VMB to my system speakers.  
> No audio received by WSJT-X (either in RC5 or 2.0.2 ) , but I can sure hear 
> the caterwauling in the speakers.  The best I can tell, Win10's wonderful 
> audio routing system (App volume and device preferences) is set correctly.  
> FWIW I am running VMB 2.0.4.7.
>
> Prior to installing RC5 everything was working fine.
>
> __
> Dan – K4SHQ

Hi Dan,

what is VMB?

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] WSJT-X 2.1.0-rc5

[rjai...@gmail.com]

Hi Joe and team,

So far so good. Testing remote with my Flex-6700 and using remote DAX,
under Parallels in Windows. You definitely notice the sensitivity
drop. But I made some QSOs on 80m. So far so good. I see PSKReporter
is taking and parsing the reports as well without issue.

73
Ria, N2RJ

On Mon, 29 Apr 2019 at 14:09, Joe Taylor  wrote:
>
> To:   Users of WSJT-X -- especially those interested in radio contesting
> From: WSJT Development Group
>
> By now most of you know about the FT4 protocol under development for
> eventual release in WSJT-X 2.1.0.  The new mode is particularly
> optimized for use in radio contesting.
>
> FT4 is mostly like FT8, but is 2.5 x faster, uses 1.8 x the bandwidth,
> and is 4.6 dB less sensitive.  Many other details are summarized in "The
> FT4 Protocol for Digital Contesting", available here:
> http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf
> Links to translations in other languages are available on the WSJT-X web
> page:
> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>
> Release candidate WSJT-X 2.1.0-rc5 is intended for beta-testing through
> June 7, 2019.  Please note that the FT4 mode should NOT be used in the
> ARRL June VHF QSO Party (June 8-10) or ARRL Field Day (June 22-23).
>
> We have done our best to provide suggested operating frequencies for the
> test period consistent as far as possible with world-wide band plans and
> existing usage.  Please note that thanks to good user feedback, some of
> these frequencies are different from those suggested in the document
> linked above.
>
> Default frequencies currently recommended for FT4 are as follows:
>
> Band   MHzNotes
> -
> 803.575   (3.568 MHz in Region 3)
> 407.047
> 30   10.140
> 20   14.080
> 17   18.104
> 15   21.140
> 12   24.919
> 10   28.180
>   6   50.318
>   2  144.170
>
> FT4 is designed for contesting, but it will likely find some use for
> normal QSOs as well, especially during the beta test period.  In the
> coming month we hope to receive useful feedback on the user interface,
> message sequencing, interaction with logging programs, etc.  Probably
> it's best to use "normal" (non-contest) messages except during the
> mock-contest practice sessions scheduled for  - 0100 UTC on May 9
> and May 14, and (if needed) June 5.
>
> Downloadable installation packages for WSJT-X 2.1.0-rc5 under Windows,
> Linux, and macOS are available on the WSJT-X web page:
>
> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>
> Windows users will discover that WSJT-X v2.1.0 has been made available
> as a 64-bit MS Windows build for 64-bit versions of Windows since Vista.
> This veraion has one known defect. The audio input device level will be
> reset to 100% when WSJT-X is started, when the input audio device is
> changed, and when switching to a new configuration. This is a Qt
> framework defect that we have reported and is being fixed in a future
> release; until then users should take care to set the device audio level
> back to 0dB or lower depending on requirements. Note that many sound
> cards and chips have real gain ahead of the ADC, as much as 14dB, which
> will be turned to the maximum due to this defect and is usually
> undesirable when using WSJT-X.
>
> Despite this annoying defect, we recommend the 64-bit version of WSJT-X
> on MS Windows as it has significant advantages in decoding speed.
>
> -- 73 from Joe, K1JT; Steve, K9AN; and Bill, G4WJS
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



-- 
Ria Jairam, N2RJ
Director, Hudson Division
ARRL - The national association for Amateur Radio™
+1.973.594.6275
https://hudson.arrl.org
n...@arrl.org


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

Re: [wsjt-devel] Unsubscribe

[Neil Zampella]

I believe this is at the bottom of most messages, and the top of the digest:

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Head there to unsubscribe.

Neil, KN3ILZ

On 4/29/2019 5:46 PM, Lester Sousley wrote:



--
Lester Sousley
509-378-2501


Virus-free. www.avast.com






---
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] 7047 Khz QRM to/from Who??

[James Shaver]

One tiny CW frequency in a 3kHz passband should not be much of an issue if you 
have a notch filter - try to notch it out and see if that helps. 

> On Apr 29, 2019, at 7:58 PM, Rich Zwirko - K1HTV  wrote:
> 
> Well,
>Guess what station is on 7047 KHz, the new 40 Meter FT4 frequency and what 
> are they doing? Would you believe W1AW transmits CW Bulletins on 7047 MHz. 
> And they are 30dB over 9 here in VA this evening.   Oooops. Not a good 
> frequency!  Back to the drawing board for another 40M FT4 frequency.
> 
> 73,
> Rich - K1HTV
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Dan Malcolm]

Voicemeeter Banana

__
Dan – K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Monday, April 29, 2019 4:52 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.1.0-rc5

On 29/04/2019 22:43, Dan Malcolm wrote:
> Just installed WSJT-X 2.1.0 RC5 x64 on my Win10 x64 machine.  Tx works and 
> seems to be OK, but something rerouted audio from VMB to my system speakers.  
> No audio received by WSJT-X (either in RC5 or 2.0.2 ) , but I can sure hear 
> the caterwauling in the speakers.  The best I can tell, Win10's wonderful 
> audio routing system (App volume and device preferences) is set correctly.  
> FWIW I am running VMB 2.0.4.7.
>
> Prior to installing RC5 everything was working fine.
>
> __
> Dan – K4SHQ

Hi Dan,

what is VMB?

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] WSJTX 2.1 RC5 - 80m Crash

[Edfel Rivera]

Hi:

Setup Kenwood 590SG, Windowa 10 64bit.  Program crashes everytime I try to
CQ at the 80m band.  It popups configuration window.

73'

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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Bill Somerville]

On 30/04/2019 00:17, Ron Koenig wrote:
I understand the Reason for the moving buttons... But the box is 
jumping between 3 screens, not just the buttons.. Never going to work 
out in a contest. 


Hi Ron,

that's not supposed to happen. Are you saying that each time the "Log 
QSO" dialog pops up it is on a different monitor?


73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Ron Koenig]

I understand the Reason for the moving buttons... But the box is jumping
between 3 screens, not just the buttons.. Never going to work out in a
contest.

On Mon, Apr 29, 2019, 4:54 PM Bill Somerville  wrote:

> On 29/04/2019 22:43, Dan Malcolm wrote:
> > Just installed WSJT-X 2.1.0 RC5 x64 on my Win10 x64 machine.  Tx works
> and seems to be OK, but something rerouted audio from VMB to my system
> speakers.  No audio received by WSJT-X (either in RC5 or 2.0.2 ) , but I
> can sure hear the caterwauling in the speakers.  The best I can tell,
> Win10's wonderful audio routing system (App volume and device preferences)
> is set correctly.  FWIW I am running VMB 2.0.4.7.
> >
> > Prior to installing RC5 everything was working fine.
> >
> > __
> > Dan – K4SHQ
>
> Hi Dan,
>
> what is VMB?
>
> 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] Bugies in 2.1.0

[James Shaver]

I can read between the lines and I think it’s fantastic. 

> On Apr 29, 2019, at 5:58 PM, Jim Nuytens via wsjt-devel 
>  wrote:
> 
> There's always a more determined LID. ;-)
> 
>> On 4/29/2019 17:29, Bill Somerville wrote:
>> Christoph,
>> 
>> not disagreeing but there are reasons for this that I can't reveal. Let's 
>> just say it is to deter LIDs. Sorry.
>> 
>> 73
>> Bill
>> G4WJS.
>> 
> 
> 
> ---
> 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


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

[wsjt-devel] WSJTX 2.1 RC5 - Not seems to be logging QSO

[Edfel Rivera]

Hi:

Not sure if missing something from guide, Contest Log not showing new QSO
with FT4.  RC5 Windows 10 64bit.

73'

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

[wsjt-devel] Great job! Was: Bugies in 2.1.0

[iw1ayd - Salvatore Irato]

Hi all.

First of all, English is not my native or primary language, I would not 
like to seem not polite or rude. I am not.


So a BIG thanks to the whole development team, great work, but you all 
know how much more work would be needed. Anyway, the modulation and 
messages schema is good.


Also the idea to leave mixable contest and non contest modes, that's not 
a silly point. It's an attempt to automate configuration on the fly?



What I have seen after some operation is:
- Each time I get out from File>Setup with [OK] wstjt-x reset mode to FT 
and change frequency on the radio 7047 >>> 7074, that toy is a IC7610 BTW.


- Over 3 dozens of QSO done, 40m tonight - thanks to all, almost two 
went lost even having a big RX signal from the other side ... but DT > 
0.4 and some apparently drift of the signal, almost ~6/8 Hz stepped 1/2 
Hz - let me be silly: tight AFC?


- Inside the log sub window, maybe due to contesting setup of 
correspondents, the [OK] exchanged suddenly position with [cancel]... 
better to have automated log, isn't?


- the Band Activity window scroll call as it like, shows almost half 
line of the first call line and then some more, forcing manually back/up 
show some more usefull ... five 5 s are 5 s


- the Band Activity window keep redrawing only current/last_period RXed 
lines - no matter about setup picks - really not that useful for 
contesting ...~no cluster/bandmap/call_on_waterfall, no received call 
table, no multiplier table, nothing, we will get lost after hour of 
heavy work


- other visual/operative behavior may have to do with my subjective 
view- I wish to keep all those for myself, not all that is repeatable I 
suspect.


DT seems not afflict it all that heavy, I have seen - recognized - at 
worst DT -0,4 .it maybe that drifting is worse.


Out of the great, pretty fast, well known and steady QSO schema, I 
wouldn't try to have 44 hours out of 48 of Contest with it on a single 
radio and this.I would not have opted for a start-when-you wont schema: 
never. Time is a part of the messaging technique, why not use that to 
have perfect slices?


I didn't saved that much but in any case my all.txt is here.
BTW it will be much better having files created using a named contest 
schema, select a contest create a subdir and place there all the stuff 
...And a way to recover more simply that dreaded Cabrillo or ADI from 
the base log ... all that for a some more user driven environment. I 
know that it is dangerous :-{


Again thanks for the efforts, you and several of us will never regret to 
play with the results! Personally I care.


    73 de iw1ayd Salvo



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

Re: [wsjt-devel] Bugies in 2.1.0

[Jim Nuytens via wsjt-devel]

There's always a more determined LID. ;-)

On 4/29/2019 17:29, Bill Somerville wrote:

Christoph,

not disagreeing but there are reasons for this that I can't reveal. 
Let's just say it is to deter LIDs. Sorry.


73
Bill
G4WJS.




---
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] WSJT-X 2.1.0-rc5 Configuration Settings is a "Mess"

[Marco Calistri]

Il 29/04/19 18:35, Bill Somerville ha scritto:
> On 29/04/2019 22:28, Marco Calistri wrote:
>> I've compiled and installed WSJT-X 2.1.0-rc5.tgz without any issue on a
>> opensuse Tumbleweed system, but all my attempts of cloning my standard
>> release settings, have caused me just frustration!
> 
> Hi Marco,
> 
> this tells me you are probably using a KDE desktop. See item 9 in the
> v2.1.0 RC5 User Guide FAQ chapter:
> 
> http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.1.0-rc5.html#FAQ
> 
> 
> Let me know if it sorts out your issues please?
> 
> 73
> Bill
> G4WJS.

Hi Bill,
Thanks for your fast response!

No, I'm using XFCE Desktop, not KDE and I have not a
~/.config/kdeglobals in my system.

I found the file *kdeglobals* into the following subdir of my home dir:

1 - /home/marco/.kde/share/config/

2 - /home/marco/.kde4/share/config/

Then I suppose item 9 it is not my case, also because I cannot say that
Menu→Configurations misbehave, it behaves correctly and it responds as
expected but it doesn't works as described in WSJT-X FT4 instructions
for cloning the existing configs.

Never mind Bill, it is not a major issue for me now that I know how to
resolve it.

Just curious to know if others using WSJT-X on Linux and XFCE, are
facing same issue as I described.

Best regards!


-- 

73 de Marco, PY1ZRJ (former IK5BCU)


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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Bill Somerville]

On 29/04/2019 22:43, Dan Malcolm wrote:

Just installed WSJT-X 2.1.0 RC5 x64 on my Win10 x64 machine.  Tx works and 
seems to be OK, but something rerouted audio from VMB to my system speakers.  
No audio received by WSJT-X (either in RC5 or 2.0.2 ) , but I can sure hear the 
caterwauling in the speakers.  The best I can tell, Win10's wonderful audio 
routing system (App volume and device preferences) is set correctly.  FWIW I am 
running VMB 2.0.4.7.

Prior to installing RC5 everything was working fine.

__
Dan – K4SHQ


Hi Dan,

what is VMB?

73
Bill
G4WJS.



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

[wsjt-devel] Unsubscribe

[Lester Sousley]

-- 
Lester Sousley
509-378-2501


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Dan Malcolm]

Just installed WSJT-X 2.1.0 RC5 x64 on my Win10 x64 machine.  Tx works and 
seems to be OK, but something rerouted audio from VMB to my system speakers.  
No audio received by WSJT-X (either in RC5 or 2.0.2 ) , but I can sure hear the 
caterwauling in the speakers.  The best I can tell, Win10's wonderful audio 
routing system (App volume and device preferences) is set correctly.  FWIW I am 
running VMB 2.0.4.7. 

Prior to installing RC5 everything was working fine.

__
Dan – K4SHQ

-Original Message-
From: Christoph Berg [mailto:c...@df7cb.de] 
Sent: Monday, April 29, 2019 4:16 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.1.0-rc5

Re: James Shaver 2019-04-29 
> I’m on 20 meters - After about 2-3 minutes of operating, I’m seeing the mode 
> getting changed back to FT8 and my frequency is jumping to 14.074.  This 
> appears to be random (though it still shows the “FT4” configuration as being 
> selected).  Selecting FT4 as the mode does not put me back to 14.080 but 
> closing the program and reopening brings me back to where I need to be. A 
> reboot appears to have cured this but FYI in case anyone else is 
> experiencing a similar issue.  

I have a similar problem. I was manually tuning to 7,047 and everything seemed 
normal (apart from the occasional "Rig control error" popups that I had always 
popping up every 10 minutes or so).
But when I added the FT4 freqs to the configuration, the program started 
randomly changing bands, mostly after the end of the TX cycle.
I could complete a few QSOs on 30m and 20m, but after every second TX cycle or 
so, it would jump to the 80m or 40m FT4 freqs.

Maybe my rig control is much more instable than the occasional "Rig control 
error" popups suggest, but wsjtx 2.0.x was able to ignore most of them. Now it 
seems that it jumps bands on each of them.

I have true rig split mode active, which worked fine in 2.0.x.

Christoph


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


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

Re: [wsjt-devel] Bugies in 2.1.0

[Bill Somerville]

On 29/04/2019 22:31, WB5JJJ wrote:
I agree.  I've hit CANCEL a couple of times instead of OK.  Habit, 
Habit, Habit.


George


Hi George,

sorry about that, but TBH you should be paying attention when logging QSOs.

73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5 Configuration Settings is a "Mess"

[Bill Somerville]

On 29/04/2019 22:28, Marco Calistri wrote:

I've compiled and installed WSJT-X 2.1.0-rc5.tgz without any issue on a
opensuse Tumbleweed system, but all my attempts of cloning my standard
release settings, have caused me just frustration!


Hi Marco,

this tells me you are probably using a KDE desktop. See item 9 in the 
v2.1.0 RC5 User Guide FAQ chapter:


http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.1.0-rc5.html#FAQ

Let me know if it sorts out your issues please?

73
Bill
G4WJS.



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

Re: [wsjt-devel] Bugies in 2.1.0

[WB5JJJ]

I agree.  I've hit CANCEL a couple of times instead of OK.  Habit, Habit,
Habit.

George

On Mon, Apr 29, 2019 at 4:29 PM Christoph Berg  wrote:

> Re: Bill Somerville 2019-04-29 <
> ddfd6e65-ec40-be34-c364-f44e43ca9...@classdesign.com>
> > > Manual log qso, has Ok and Cancel buttons at least 4 different
> positions
> > > within different qsos
> > This is intentional. Is it causing you insurmountable problems?
>
> Very annoying. There are styleguides that suggest putting the OK and
> cancel buttons in certain places when using a toolkit so each app
> behaves the same. Please follow them.
>
> https://doc.qt.io/archives/qq/qq19-buttons.html
>
> Christoph
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bugies in 2.1.0

[Bill Somerville]

On 29/04/2019 22:26, Christoph Berg wrote:

Re: Bill Somerville 
2019-04-29

Manual log qso, has Ok and Cancel buttons at least 4 different positions
within different qsos

This is intentional. Is it causing you insurmountable problems?

Very annoying. There are styleguides that suggest putting the OK and
cancel buttons in certain places when using a toolkit so each app
behaves the same. Please follow them.

https://doc.qt.io/archives/qq/qq19-buttons.html

Christoph


Hi Christoph,

not disagreeing but there are reasons for this that I can't reveal. 
Let's just say it is to deter LIDs. Sorry.


73
Bill
G4WJS.

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

[wsjt-devel] WSJT-X 2.1.0-rc5 Configuration Settings is a "Mess"

[Marco Calistri]

Hello,

Sorry to use a not "very elegant word" in the subject, but I had not
found a better term to explain...

I've compiled and installed WSJT-X 2.1.0-rc5.tgz without any issue on a
opensuse Tumbleweed system, but all my attempts of cloning my standard
release settings, have caused me just frustration!

It happens exactly what happened on all the previous WSJT-X releases:

If you try to clone your settings and rename it then all the fields
inside the configuration fields (new or former) are empty: no call, no
grid, no radio, no anything!

In addition at any attempt of creating a config, there are new ones
available so that the configuration drop-down menu get filled of several
ones (all with their field empty!).

Good that I saved a rescue "WSJT-X.ini" on my computer so I've been able
to quickly resume my usual parameters, but this configuration
copy/cloning issue is really frustrating and I hope it being isolated
just on my system, due a possible error I make every time :-(

I will test the new RC5 version beside the above occurrence and I'll
report here if I find some other problem.

Thanks to all the devs team for the new version and for the progress
WSJT-X is having along the time.


-- 

73 de Marco, PY1ZRJ (former IK5BCU)


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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Enrique Scheuer]

Win 10 64 bit IC 7300. changing bands constantly when calling. Anyone had
it also ?

de Enrique
PY2CP

Em seg, 29 de abr de 2019 às 18:23, Bill Somerville 
escreveu:

> On 29/04/2019 22:16, Christoph Berg wrote:
> > Maybe my rig control is much more instable than the occasional "Rig
> > control error" popups suggest
>
> Hi Christoph,
>
> your assumption is correct, unexplained rig control errors are a sign of
> serious CAT issues. Which rig, what error inc. details, what settings?
>
> 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] Bugies in 2.1.0

[Christoph Berg]

Re: Bill Somerville 2019-04-29 

> > Manual log qso, has Ok and Cancel buttons at least 4 different positions
> > within different qsos
> This is intentional. Is it causing you insurmountable problems?

Very annoying. There are styleguides that suggest putting the OK and
cancel buttons in certain places when using a toolkit so each app
behaves the same. Please follow them.

https://doc.qt.io/archives/qq/qq19-buttons.html

Christoph


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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[David Tiller]

I also see a crash. In my case I'm not using FT4 - this is in FT8 mode. If I 
double-click on a CQ-ing station to work them, I get the following stack trace 
(Full trace attached):

VM Regions Near 0:
-->
__TEXT 00010268-000102b48000 [ 4896K] r-x/rwx 
SM=COW  /Users/USER/*/wsjtx.app/Contents/MacOS/wsjtx

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgfortran.5.dylib   0x000107e432da _gfortran_concat_string + 
23
1   org.k1jt.wsjtx 0x0001027c2c3d azdist_ + 93
2   org.k1jt.wsjtx 0x0001026e7cd5 
MainWindow::on_dxGridEntry_textChanged(QString const&) + 389
3   org.k1jt.wsjtx 0x0001026f7a72 
MainWindow::qt_metacall(QMetaObject::Call, int, void**) + 82
4   org.qt-project.QtCore 0x000107958bfd 
QMetaObject::activate(QObject*, int, int, void**) + 1773
5   org.qt-project.QtWidgets   0x000106b59684 0x106a05000 + 1394308
6   org.qt-project.QtCore 0x00010795914c 
QMetaObject::activate(QObject*, int, int, void**) + 3132
7   org.qt-project.QtWidgets   0x000106b5b186 
QWidgetLineControl::finishChange(int, bool, bool) + 614
8   org.qt-project.QtWidgets   0x000106b5c31a 
QWidgetLineControl::internalSetText(QString const&, int, bool) + 570
9   org.qt-project.QtWidgets   0x000106b53cef 0x106a05000 + 1371375
10  org.k1jt.wsjtx 0x00010273269a 
MainWindow::processMessage(DecodedText const&, QFlags) + 
13658
11  org.k1jt.wsjtx 0x0001026d5a54 
MainWindow::doubleClickOnCall(QFlags) + 820
12  org.k1jt.wsjtx 0x0001026d5d0c 
MainWindow::doubleClickOnCall2(QFlags) + 76
13  org.qt-project.QtCore 0x000107958dbb 
QMetaObject::activate(QObject*, int, int, void**) + 2219
14  org.k1jt.wsjtx 0x000102697b5e 
DisplayText::mouseDoubleClickEvent(QMouseEvent*) + 62
15  org.qt-project.QtWidgets   0x000106a51612 QWidget::event(QEvent*) + 
466
16  org.qt-project.QtWidgets   0x000106af8fdd QFrame::event(QEvent*) + 
45
17  org.qt-project.QtCore 0x0001079281a4 
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) + 148
18  org.qt-project.QtWidgets   0x000106a158d8 
QApplicationPrivate::notify_helper(QObject*, QEvent*) + 248
19  org.qt-project.QtWidgets   0x000106a18748 
QApplication::notify(QObject*, QEvent*) + 7336
20  org.k1jt.wsjtx 0x00010278feb2 (anonymous 
namespace)::ExceptionCatchingApplication::notify(QObject*, QEvent*) + 18
21  org.qt-project.QtCore 0x000107927ef4 
QCoreApplication::notifyInternal2(QObject*, QEvent*) + 212
22  org.qt-project.QtWidgets   0x000106a16210 
QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, 
QWidget**, QPointer&, bool, bool) + 896
23  org.qt-project.QtWidgets   0x000106a70aae 0x106a05000 + 441006
24  org.qt-project.QtWidgets   0x000106a6f795 0x106a05000 + 436117
25  org.qt-project.QtWidgets   0x000106a158ed 
QApplicationPrivate::notify_helper(QObject*, QEvent*) + 269
26  org.qt-project.QtWidgets   0x000106a16cf2 
QApplication::notify(QObject*, QEvent*) + 594

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com



On Apr 29, 2019, at 3:34 PM, George J. Molnar 
mailto:geo...@molnar.tv>> wrote:

Bill, this may help…

After the initial MacOS crash,


 I have been able to reproduce the crash in MacOS by entering a 4-character 
grid. Upon typing the 4th character, the app crashes. A callsign alone doesn’t 
crash it, even if Generate Standard Messages is clicked. Imagine this would 
support the app crashing on double click to reply, as that populates the grid 
field, too.

Geo/KF2T



On Apr 29, 2019, at 3:20 PM, Bill Somerville 
mailto:g4...@classdesign.com>> wrote:

On 29/04/2019 20:14, Gary Rogers wrote:

I’m unable to get the new version to work with Mac OS, will not open and get an 
immediate crash notification

Gary KO3F


Hi Gary,

if the crash report looks like the one reported by Michael above then thanks 
for the issue report, we are looking into it. The dump would contain a stack 
trace starting like this:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgfortran.5.dylib 0x000113d622da 
_gfortran_concat_string + 23
1   org.k1jt.wsjtx  0x00010e6e0c3d azdist_ + 93
2   org.k1jt.wsjtx  0x00010e605cd5 
MainWindow::on_dxGridEntry_textChanged(QString const&) + 389
3   org.k1jt.wsjtx  0x00010e615a72 
MainWindow::qt_metacall(QMetaObject::Call, int, void**) + 82


If it is a different crash then please provide the crash report details.

73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Bill Somerville]

On 29/04/2019 22:16, Christoph Berg wrote:

Maybe my rig control is much more instable than the occasional "Rig
control error" popups suggest


Hi Christoph,

your assumption is correct, unexplained rig control errors are a sign of 
serious CAT issues. Which rig, what error inc. details, what settings?


73
Bill
G4WJS.



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

Re: [wsjt-devel] End of life for rc5 could create a problem

[WB5JJJ]

Oh crap, I was so hoping it would all be over.  Life goes on.  Thanks
again.  So far all is pretty good and stable.

George

On Mon, Apr 29, 2019 at 4:15 PM Bill Somerville 
wrote:

> On 29/04/2019 22:02, WB5JJJ wrote:
>
> For those that run rc5 till it expires and then try to run v2.0.1 instead
> of updating to rc6 (or whatever), there needs to be a means to reset the
> FT4 token in the registry when the program dies on startup or you won't be
> able to run previous GA's unless you install a new rc first and change the
> mode within the program.
>
> Food for thought for the developers.
>
> WB5JJJ - George
>
> George,
>
> nothing is stored in the Windows registry by WSJT-X. The inability to
> start the 2.0.1 version when FT4 mode has been selected in v2.1.0 is a
> defect that will be fixed in a bug fix release of v2.0.1 before the
> expiration date of v2.1.0 RC5. Also it is trivial to change the selected
> mode in the settings file so the World will not end after all.
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Christoph Berg]

Re: James Shaver 2019-04-29 
> I’m on 20 meters - After about 2-3 minutes of operating, I’m seeing the mode 
> getting changed back to FT8 and my frequency is jumping to 14.074.  This 
> appears to be random (though it still shows the “FT4” configuration as being 
> selected).  Selecting FT4 as the mode does not put me back to 14.080 but 
> closing the program and reopening brings me back to where I need to be. A 
> reboot appears to have cured this but FYI in case anyone else is 
> experiencing a similar issue.  

I have a similar problem. I was manually tuning to 7,047 and
everything seemed normal (apart from the occasional "Rig control
error" popups that I had always popping up every 10 minutes or so).
But when I added the FT4 freqs to the configuration, the program
started randomly changing bands, mostly after the end of the TX cycle.
I could complete a few QSOs on 30m and 20m, but after every second TX
cycle or so, it would jump to the 80m or 40m FT4 freqs.

Maybe my rig control is much more instable than the occasional "Rig
control error" popups suggest, but wsjtx 2.0.x was able to ignore most
of them. Now it seems that it jumps bands on each of them.

I have true rig split mode active, which worked fine in 2.0.x.

Christoph


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

Re: [wsjt-devel] Bugies in 2.1.0

[Bill Somerville]

Hi Jari,

comments in line below.

On 29/04/2019 21:24, Jari A wrote:

Some quick bugies:

Windows 7 pro 64bit,

When wsjt-x 210 start, rx audio level goes to +30db = full volume
This is noted in the release announcement. It only happens with the 
Windows 64-bit build and will be fixed when the Qt team release a 
version with the defect fixed. Until then you will have to reset your 
audio input device level each time you start WSJT-X, switch 
configurations, or change the audio devices. Alternatively you can use 
the 32-bit build of WSJT-X v2.1.0 RC5.


Manual log qso, has Ok and Cancel buttons at least 4 different 
positions within different qsos

This is intentional. Is it causing you insurmountable problems?


Change color, causes mode to jump to FT8
This is noted here several times. When leaving settings in FT4 mode you 
must reselect FT4 mode. The defect is fixed for the next release.


Occasional loop in signal reporting, even high signal levels

Can you provide the relevant section of your ALL.TXT file please.


- opening 201, windows on desktop are messed up, wrong places and 
wrong sizes and mode gone to JT9
What exactly do you mean by "opening 201"? A sequence of steps to 
reproduce please.


Regards,

:Jari / oh2fqv


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

Re: [wsjt-devel] End of life for rc5 could create a problem

[Bill Somerville]

On 29/04/2019 22:02, WB5JJJ wrote:
For those that run rc5 till it expires and then try to run v2.0.1 
instead of updating to rc6 (or whatever), there needs to be a means to 
reset the FT4 token in the registry when the program dies on startup 
or you won't be able to run previous GA's unless you install a new rc 
first and change the mode within the program.


Food for thought for the developers.

WB5JJJ - George


George,

nothing is stored in the Windows registry by WSJT-X. The inability to 
start the 2.0.1 version when FT4 mode has been selected in v2.1.0 is a 
defect that will be fixed in a bug fix release of v2.0.1 before the 
expiration date of v2.1.0 RC5. Also it is trivial to change the selected 
mode in the settings file so the World will not end after all.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Error in 2.1RC5

[Bill Somerville]

On 29/04/2019 21:40, Al Flapan wrote:

I am using the 64 bit windows program and my OS is W10 pro.

When I click on the update LOTW users data I get the following error

error loading lotw users date

network error - ssl/tsl support not installed, cannot fetch:

I do not have this error using the regular release vn 2.0.1 program.

Al  AF4FA


Hi Al,

you need to install the 64-bit variant of the OpenSSL libraries. 
Specifically version:


https://slproweb.com/download/Win64OpenSSL_Light-1_0_2r.exe

from here:

https://slproweb.com/products/Win32OpenSSL.html

Take the default options including letting it install into the Windows 
system location. You don't need to donate to the OpenSSL project if you 
don't want to, just un-click the donation option.


73
Bill
G4WJS.



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

[wsjt-devel] End of life for rc5 could create a problem

[WB5JJJ]

For those that run rc5 till it expires and then try to run v2.0.1 instead
of updating to rc6 (or whatever), there needs to be a means to reset the
FT4 token in the registry when the program dies on startup or you won't be
able to run previous GA's unless you install a new rc first and change the
mode within the program.

Food for thought for the developers.

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

[wsjt-devel] Error in 2.1RC5

[Al Flapan]

I am using the 64 bit windows program and my OS is W10 pro.

When I click on the update LOTW users data I get the following error

error loading lotw users date

network error - ssl/tsl support not installed, cannot fetch:

I do not have this error using the regular release vn 2.0.1 program.

Al  AF4FA



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[David Tiller]

I also see the mode reverting to FT8.

Following the instructions, I set the mode to FT4. I then go into the frequency 
settings and reset them. When I exit that screen, the mode has been reset to 
FT8.

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | 
dtil...@captechconsulting.com



On Apr 29, 2019, at 3:26 PM, Alois Windpassinger 
mailto:alois.windpassin...@gmail.com>> wrote:

hi Gary,
here the same trouble with Mac-OS High Sierra...program crashes and is sending 
a report to Apple...hi
 gl 73 de Alois, dl8rbl

Am Mo., 29. Apr. 2019 um 21:18 Uhr schrieb Gary Rogers 
mailto:cgaryrogers...@gmail.com>>:
I’m unable to get the new version to work with Mac OS, will not open and get an 
immediate crash notification

Gary KO3F

> On Apr 29, 2019, at 3:08 PM, Bill Somerville 
> mailto:g4...@classdesign.com>> wrote:
>
> On 29/04/2019 20:05, James Shaver wrote:
>> Hey Bill - I’ll click on the mode menu, select “FT4” and the mode will 
>> remain in FT8 mode until I close WSJTX down and reopen it.
>>
>> 73,
>>
>> Jim S.
>> N2ADV
>
> Hi Jim,
>
> that seems unlikely. Are you sure you are not looking at the configuration 
> name, perhaps you have a configuration selected on that machine called "FT8".
>
> 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


--
Alois Windpassinger
___
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] Bugies in 2.1.0

[Jari A]

Some quick bugies:

Windows 7 pro 64bit,

When wsjt-x 210 start, rx audio level goes to +30db = full volume

Manual log qso, has Ok and Cancel buttons at least 4 different positions
within different qsos

Change color, causes mode to jump to FT8

Occasional loop in signal reporting, even high signal levels

- opening 201, windows on desktop are messed up, wrong places and wrong
sizes and mode gone to JT9

Regards,

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

Re: [wsjt-devel] v2.0.1 now crashes

[WB5JJJ]

Thanks Bill.

I created an "FT4 Test" configuration in rc5 with all the parameters as
suggested.  When I switched configurations in rc5 from "FT4 Test" to
"Normal FT8" and closed rc5, then restarted v2.0.1 all is now just fine and
it's been running a few of minutes.

Something to remember till v2.1.0 GA.  Otherwise, both versions seem to
function normally now.

George



On Mon, Apr 29, 2019 at 3:05 PM Bill Somerville 
wrote:

> On 29/04/2019 20:56, WB5JJJ wrote:
>
> I installed v2.1.0 rc5 in a separate directory as I've done with the rc's
> before and it runs just fine.  HOWEVER, if I exit rc5 and restart v2.0.1,
> it CRASHES within 5 seconds.
>
> I uninstalled all instances of WSTJx and rebooted my machine.  Reinstalled
> v2.0.1 and it still crashes after a few seconds.  Something is just not
> right with the rc5 install that appears to have corrupted the other
> installs.
>
> WB5JJJ - George
>
> Hi George,
>
> try starting the v2.1.0 version and setting the mode to something other
> than FT4 before returning to an older version.
>
> 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] Unsubscrib

[Javier Grosso]

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

Re: [wsjt-devel] v2.0.1 now crashes

[Bill Somerville]

On 29/04/2019 20:56, WB5JJJ wrote:
I installed v2.1.0 rc5 in a separate directory as I've done with the 
rc's before and it runs just fine.  HOWEVER, if I exit rc5 and restart 
v2.0.1, it CRASHES within 5 seconds.


I uninstalled all instances of WSTJx and rebooted my machine. 
Reinstalled v2.0.1 and it still crashes after a few seconds.  
Something is just not right with the rc5 install that appears to have 
corrupted the other installs.


WB5JJJ - George


Hi George,

try starting the v2.1.0 version and setting the mode to something other 
than FT4 before returning to an older version.


73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Patrick 9A5CW]

Hi,
Win 7 64bit, WSJT-X 64bit.
Enterening a new freq in the freq list.
Mode change from FT4 to FT8 by pressing OK in the settings menu.
The same happens when i delete new stored freq.

Everything others works ok so far, can see many users already migrated to
FT4.
Best regards and RR73 9A5CW

pon, 29. tra 2019. 20:09 Joe Taylor  je napisao:

> To:   Users of WSJT-X -- especially those interested in radio contesting
> From: WSJT Development Group
>
> By now most of you know about the FT4 protocol under development for
> eventual release in WSJT-X 2.1.0.  The new mode is particularly
> optimized for use in radio contesting.
>
> FT4 is mostly like FT8, but is 2.5 x faster, uses 1.8 x the bandwidth,
> and is 4.6 dB less sensitive.  Many other details are summarized in "The
> FT4 Protocol for Digital Contesting", available here:
> http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf
> Links to translations in other languages are available on the WSJT-X web
> page:
> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>
> Release candidate WSJT-X 2.1.0-rc5 is intended for beta-testing through
> June 7, 2019.  Please note that the FT4 mode should NOT be used in the
> ARRL June VHF QSO Party (June 8-10) or ARRL Field Day (June 22-23).
>
> We have done our best to provide suggested operating frequencies for the
> test period consistent as far as possible with world-wide band plans and
> existing usage.  Please note that thanks to good user feedback, some of
> these frequencies are different from those suggested in the document
> linked above.
>
> Default frequencies currently recommended for FT4 are as follows:
>
> Band   MHzNotes
> -
> 803.575   (3.568 MHz in Region 3)
> 407.047
> 30   10.140
> 20   14.080
> 17   18.104
> 15   21.140
> 12   24.919
> 10   28.180
>   6   50.318
>   2  144.170
>
> FT4 is designed for contesting, but it will likely find some use for
> normal QSOs as well, especially during the beta test period.  In the
> coming month we hope to receive useful feedback on the user interface,
> message sequencing, interaction with logging programs, etc.  Probably
> it's best to use "normal" (non-contest) messages except during the
> mock-contest practice sessions scheduled for  - 0100 UTC on May 9
> and May 14, and (if needed) June 5.
>
> Downloadable installation packages for WSJT-X 2.1.0-rc5 under Windows,
> Linux, and macOS are available on the WSJT-X web page:
>
> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>
> Windows users will discover that WSJT-X v2.1.0 has been made available
> as a 64-bit MS Windows build for 64-bit versions of Windows since Vista.
> This veraion has one known defect. The audio input device level will be
> reset to 100% when WSJT-X is started, when the input audio device is
> changed, and when switching to a new configuration. This is a Qt
> framework defect that we have reported and is being fixed in a future
> release; until then users should take care to set the device audio level
> back to 0dB or lower depending on requirements. Note that many sound
> cards and chips have real gain ahead of the ADC, as much as 14dB, which
> will be turned to the maximum due to this defect and is usually
> undesirable when using WSJT-X.
>
> Despite this annoying defect, we recommend the 64-bit version of WSJT-X
> on MS Windows as it has significant advantages in decoding speed.
>
> -- 73 from Joe, K1JT; Steve, K9AN; and 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] v2.0.1 now crashes

[WB5JJJ]

I installed v2.1.0 rc5 in a separate directory as I've done with the rc's
before and it runs just fine.  HOWEVER, if I exit rc5 and restart v2.0.1,
it CRASHES within 5 seconds.

I uninstalled all instances of WSTJx and rebooted my machine.  Reinstalled
v2.0.1 and it still crashes after a few seconds.  Something is just not
right with the rc5 install that appears to have corrupted the other
installs.

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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Dana Myers]

On 4/29/2019 12:45 PM, Black Michael via wsjt-devel wrote:

Need a small cosmetic change to add FT4 to the Advanced Tab.
And when switching to FT4 should there be a check for a Special Activity to be selected?  I see a lot of testers already not 
using a contest mode.


We're not in a contest or mock-contest, so of course we're not running a 
contest mode.
The setup directions might be a little ambiguous :-)

73,
Dana  K6JQ

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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Bill Somerville]

On 29/04/2019 20:26, Alois Windpassinger wrote:

hi Gary,
here the same trouble with Mac-OS High Sierra...program crashes and is 
sending a report to Apple...hi

 gl 73 de Alois, dl8rbl


Hi Alois,

there is no point sending WSJT-X crash reports to Apple, they don't want 
them. Either click "Ignore" on the initial crash message if you know 
what caused it, or view the report and send us the crash report in a 
message here, then click "Don't send".


73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Bill Somerville]

On 29/04/2019 20:45, Black Michael via wsjt-devel wrote:

Need a small cosmetic change to add FT4 to the Advanced Tab.
And when switching to FT4 should there be a check for a Special 
Activity to be selected?  I see a lot of testers already not using a 
contest mode.



Hi Mike,

please note this paragraph in the release announcement:

"FT4 is designed for contesting, but it will likely find some use for 
normal QSOs as well, especially during the beta test period. In the 
coming month we hope to receive useful feedback on the user interface, 
message sequencing, interaction with logging programs, etc.  Probably 
it's best to use "normal" (non-contest) messages except during the 
mock-contest practice sessions scheduled for  - 0100 UTC on May 9 
and May 14, and (if needed) June 5."


73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Black Michael via wsjt-devel]

Need a small cosmetic change to add FT4 to the Advanced Tab. And when switching 
to FT4 should there be a check for a Special Activity to be selected?  I see a 
lot of testers already not using a contest mode.




de Mike W9MDB___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Enrique Scheuer]

Win10 64 bit now changing  alone from 21110 to 14080 after abt. 5 to 10
calls. Already checked any non desired band split setting.

de Enrique
PY2CP

Em seg, 29 de abr de 2019 às 16:38, George J. Molnar 
escreveu:

> Bill, this may help…
>
> After the initial MacOS crash,
>
>
>  I have been able to reproduce the crash in MacOS by entering a
> 4-character grid. Upon typing the 4th character, the app crashes. A
> callsign alone doesn’t crash it, even if Generate Standard Messages is
> clicked. Imagine this would support the app crashing on double click to
> reply, as that populates the grid field, too.
>
> Geo/KF2T
>
>
>
> On Apr 29, 2019, at 3:20 PM, Bill Somerville 
> wrote:
>
> On 29/04/2019 20:14, Gary Rogers wrote:
>
> I’m unable to get the new version to work with Mac OS, will not open and get 
> an immediate crash notification
>
> Gary KO3F
>
> Hi Gary,
>
> if the crash report looks like the one reported by Michael above then
> thanks for the issue report, we are looking into it. The dump would contain
> a stack trace starting like this:
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libgfortran.5.dylib   0x000113d622da 
> _gfortran_concat_string + 23
> 1   org.k1jt.wsjtx0x00010e6e0c3d azdist_ + 93
> 2   org.k1jt.wsjtx0x00010e605cd5 
> MainWindow::on_dxGridEntry_textChanged(QString const&) + 389
> 3   org.k1jt.wsjtx0x00010e615a72 
> MainWindow::qt_metacall(QMetaObject::Call, int, void**) + 82
>
> If it is a different crash then please provide the crash report details.
>
> 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] WSJT-X 2.1.0-rc5

[George J. Molnar]

Bill, this may help…

After the initial MacOS crash, 


 I have been able to reproduce the crash in MacOS by entering a 4-character 
grid. Upon typing the 4th character, the app crashes. A callsign alone doesn’t 
crash it, even if Generate Standard Messages is clicked. Imagine this would 
support the app crashing on double click to reply, as that populates the grid 
field, too.

Geo/KF2T



> On Apr 29, 2019, at 3:20 PM, Bill Somerville  wrote:
> 
> On 29/04/2019 20:14, Gary Rogers wrote:
>> I’m unable to get the new version to work with Mac OS, will not open and get 
>> an immediate crash notification
>> 
>> Gary KO3F
> Hi Gary,
> 
> if the crash report looks like the one reported by Michael above then thanks 
> for the issue report, we are looking into it. The dump would contain a stack 
> trace starting like this:
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libgfortran.5.dylib   0x000113d622da 
> _gfortran_concat_string + 23
> 1   org.k1jt.wsjtx0x00010e6e0c3d azdist_ + 93
> 2   org.k1jt.wsjtx0x00010e605cd5 
> MainWindow::on_dxGridEntry_textChanged(QString const&) + 389
> 3   org.k1jt.wsjtx0x00010e615a72 
> MainWindow::qt_metacall(QMetaObject::Call, int, void**) + 82
> If it is a different crash then please provide the crash report details.
> 
> 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] Sometimes difficult to get FT4 QSOs completed

[Ron Koenig]

50% of Q's here are not completing... de WV4P

On Mon, 29 Apr 2019 at 14:22, James Shaver  wrote:

> I’ve been in the RR73 loop quite a bit
>
> 73,
>
> Jim S.
> N2ADV (ex KD2BIP)
>
> On Apr 29, 2019, at 3:07 PM, DG2YCB, Uwe  wrote:
>
> Hi, just made a couple of FT4 QSOs. Works well. However, sometimes it’s
> somewhat difficult to get the QSOs completed. Endless exchange of reports
> but no 73 or RR73 message. Is anyone else experiencing this?
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> ___
> 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] WSJT-X 2.1.0-rc5

[Alois Windpassinger]

hi Gary,
here the same trouble with Mac-OS High Sierra...program crashes and is
sending a report to Apple...hi
 gl 73 de Alois, dl8rbl

Am Mo., 29. Apr. 2019 um 21:18 Uhr schrieb Gary Rogers <
cgaryrogers...@gmail.com>:

> I’m unable to get the new version to work with Mac OS, will not open and
> get an immediate crash notification
>
> Gary KO3F
>
> > On Apr 29, 2019, at 3:08 PM, Bill Somerville 
> wrote:
> >
> > On 29/04/2019 20:05, James Shaver wrote:
> >> Hey Bill - I’ll click on the mode menu, select “FT4” and the mode will
> remain in FT8 mode until I close WSJTX down and reopen it.
> >>
> >> 73,
> >>
> >> Jim S.
> >> N2ADV
> >
> > Hi Jim,
> >
> > that seems unlikely. Are you sure you are not looking at the
> configuration name, perhaps you have a configuration selected on that
> machine called "FT8".
> >
> > 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
>


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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Bill Somerville]

On 29/04/2019 20:14, Gary Rogers wrote:

I’m unable to get the new version to work with Mac OS, will not open and get an 
immediate crash notification

Gary KO3F


Hi Gary,

if the crash report looks like the one reported by Michael above then 
thanks for the issue report, we are looking into it. The dump would 
contain a stack trace starting like this:


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgfortran.5.dylib 0x000113d622da 
_gfortran_concat_string + 23
1   org.k1jt.wsjtx  0x00010e6e0c3d azdist_ + 93
2   org.k1jt.wsjtx  0x00010e605cd5 
MainWindow::on_dxGridEntry_textChanged(QString const&) + 389
3   org.k1jt.wsjtx  0x00010e615a72 
MainWindow::qt_metacall(QMetaObject::Call, int, void**) + 82

If it is a different crash then please provide the crash report details.

73
Bill
G4WJS.

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

Re: [wsjt-devel] Sometimes difficult to get FT4 QSOs completed

[James Shaver]

I’ve been in the RR73 loop quite a bit 

73,

Jim S. 
N2ADV (ex KD2BIP)

> On Apr 29, 2019, at 3:07 PM, DG2YCB, Uwe  wrote:
> 
> Hi, just made a couple of FT4 QSOs. Works well. However, sometimes it’s 
> somewhat difficult to get the QSOs completed. Endless exchange of reports but 
> no 73 or RR73 message. Is anyone else experiencing this?
>  
> 73 de Uwe, DG2YCB
>  
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Ron Koenig]

Win 10 64 Bit Change Anything and mode / band changes to FT-8, did not
happen in RC4


On Mon, Apr 29, 2019, 2:12 PM Bill Somerville  wrote:

> On 29/04/2019 20:05, James Shaver wrote:
> > Hey Bill - I’ll click on the mode menu, select “FT4” and the mode will
> > remain in FT8 mode until I close WSJTX down and reopen it.
> >
> > 73,
> >
> > Jim S.
> > N2ADV
>
> Hi Jim,
>
> that seems unlikely. Are you sure you are not looking at the
> configuration name, perhaps you have a configuration selected on that
> machine called "FT8".
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Gary Rogers]

I’m unable to get the new version to work with Mac OS, will not open and get an 
immediate crash notification

Gary KO3F

> On Apr 29, 2019, at 3:08 PM, Bill Somerville  wrote:
> 
> On 29/04/2019 20:05, James Shaver wrote:
>> Hey Bill - I’ll click on the mode menu, select “FT4” and the mode will 
>> remain in FT8 mode until I close WSJTX down and reopen it.
>> 
>> 73,
>> 
>> Jim S.
>> N2ADV
> 
> Hi Jim,
> 
> that seems unlikely. Are you sure you are not looking at the configuration 
> name, perhaps you have a configuration selected on that machine called "FT8".
> 
> 73
> Bill
> G4WJS.
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[James Shaver]

I’m in the correct configuration of FT4.  It is only my Win7 32 bit machine.  
My Win 7 Pro 64 Bit and my Win 10 machines don’t have any issue after selecting 
FT4 as the mode.  

73,

Jim S. 
N2ADV (ex KD2BIP)

> On Apr 29, 2019, at 3:08 PM, Bill Somerville  wrote:
> 
>> On 29/04/2019 20:05, James Shaver wrote:
>> Hey Bill - I’ll click on the mode menu, select “FT4” and the mode will 
>> remain in FT8 mode until I close WSJTX down and reopen it.
>> 
>> 73,
>> 
>> Jim S.
>> N2ADV
> 
> Hi Jim,
> 
> that seems unlikely. Are you sure you are not looking at the configuration 
> name, perhaps you have a configuration selected on that machine called "FT8".
> 
> 73
> Bill
> G4WJS.
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Enrique Scheuer]

Win 10 everything Ok Calling 21140 but no takers.
de Enrique
PY2CP

Em seg, 29 de abr de 2019 às 16:07, George J. Molnar 
escreveu:

> Rebooted - same issue. Relaunch allows app to start, and receives well.
> Double clicking to respond causes a crash every time.
>
>
> On Apr 29, 2019, at 2:59 PM, George J. Molnar  wrote:
>
> Confirm N2ADV’s observation, and the MacOS issue. Am rebooting now to see
> what clears…
>
>
> *George J Molnar*
> KF2T, Arlington, Virginia, USA
>
>
> Please note my new email: George@Molnar.*TV*
>
> ___
> 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] WSJT-X 2.1.0-rc5

[Bill Somerville]

On 29/04/2019 20:05, James Shaver wrote:
Hey Bill - I’ll click on the mode menu, select “FT4” and the mode will 
remain in FT8 mode until I close WSJTX down and reopen it.


73,

Jim S.
N2ADV


Hi Jim,

that seems unlikely. Are you sure you are not looking at the 
configuration name, perhaps you have a configuration selected on that 
machine called "FT8".


73
Bill
G4WJS.



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

[wsjt-devel] Sometimes difficult to get FT4 QSOs completed

[DG2YCB, Uwe]

Hi, just made a couple of FT4 QSOs. Works well. However, sometimes it's
somewhat difficult to get the QSOs completed. Endless exchange of reports
but no 73 or RR73 message. Is anyone else experiencing this?



73 de Uwe, DG2YCB



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Bill Somerville]

On 29/04/2019 19:18, Michael Johnston wrote:

I’m new to this list, so I’m not sure what the protocol is for reporting bugs. 
Please redirect me as appropriate.

I’ve just downloaded and installed RC5 on a Mac running OSX Mojave (10.14.3). 
(I previously had WSJT-X 2.0.1 installed). The app crashes at startup, with a 
popup dialog box saying ‘WSJT-X quit unexpectedly.” The stack trace is below.


Process:   wsjtx [34825]
Path:  /Applications/wsjtx.app/Contents/MacOS/wsjtx
Identifier:org.k1jt.wsjtx
Version:   v2.1.0-rc5 (2.1.0-rc5)
Code Type: X86-64 (Native)
Parent Process:??? [1]
Responsible:   wsjtx [34825]
User ID:   501

Date/Time: 2019-04-29 14:17:12.131 -0400
OS Version:Mac OS X 10.14.3 (18D109)
Report Version:12
Anonymous UUID:B1ED34EC-8FF8-B795-1683-7639C5437ADC

Sleep/Wake UUID:   3E5BFD17-9D21-4A10-A0DC-21720D0ED10C

Time Awake Since Boot: 340 seconds
Time Since Wake:   94 seconds

System Integrity Protection: enabled

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS at 0x
Exception Note:EXC_CORPSE_NOTIFY

Termination Signal:Segmentation fault: 11
Termination Reason:Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [34825]

VM Regions Near 0:
-->
 __TEXT 00010e59e000-00010ea66000 [ 4896K] r-x/rwx 
SM=COW  /Applications/wsjtx.app/Contents/MacOS/wsjtx

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgfortran.5.dylib 0x000113d622da 
_gfortran_concat_string + 23
1   org.k1jt.wsjtx  0x00010e6e0c3d azdist_ + 93
2   org.k1jt.wsjtx  0x00010e605cd5 
MainWindow::on_dxGridEntry_textChanged(QString const&) + 389
3   org.k1jt.wsjtx  0x00010e615a72


Hi Michael,

this is exactly the right place to report issues, and thanks for the 
issue report. I have managed to reproduce it and am looking into it 
right now.


73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[James Shaver]

Hey Bill - I’ll click on the mode menu, select “FT4” and the mode will remain 
in FT8 mode until I close WSJTX down and reopen it.  

73,

Jim S. 
N2ADV 

> On Apr 29, 2019, at 2:57 PM, Bill Somerville  wrote:
> 
> Hi Jim,
> 
> in what way doesn't it work on the 32-bit version? Are you saying that the 
> "Menu->Mode->FT4" button is not functioning?
> 
> 73
> Bill
> G4WJS.
> 
>> On 29/04/2019 19:54, James Shaver wrote:
>> Hey Bill - on my Win10 64 bit machine that works but on my Win7 Home (32 
>> bit) machine, it won’t resolve for me unless I restart.  
>> 
>> 73,
>> 
>> Jim S. 
>> N2ADV (ex KD2BIP)
>> 
 On Apr 29, 2019, at 2:49 PM, Bill Somerville  wrote:
 
 On 29/04/2019 19:38, James Shaver wrote:
 Follow up - mode gets changed back to FT8 if I got into the settings and 
 change anything (for example, checking the box “Alternate F1-F6 bindings” 
 and clicking OK returns the mode to FT8 and FT4 mode, even if selected, 
 won’t work until the program is closed and restarted.
>>> Hi Jim,
>>> 
>>> thanks for the issue report, I can confirm this is a defect. Clicking the 
>>> "OK" button to leave the Settings dialog will take the mode out of FT4 and 
>>> set FT8. You can work around this by selecting FT4 mode again.
>>> 
>>> 73
>>> Bill
>>> G4WJS.
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[George J. Molnar]

Rebooted - same issue. Relaunch allows app to start, and receives well. Double 
clicking to respond causes a crash every time.


> On Apr 29, 2019, at 2:59 PM, George J. Molnar  wrote:
> 
> Confirm N2ADV’s observation, and the MacOS issue. Am rebooting now to see 
> what clears…
> 
> 
> George J Molnar
> KF2T, Arlington, Virginia, USA
> 
> 
> Please note my new email: geo...@molnar.tv
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[George J. Molnar]

Confirm N2ADV’s observation, and the MacOS issue. Am rebooting now to see what 
clears…


George J Molnar
KF2T, Arlington, Virginia, USA


Please note my new email: geo...@molnar.tv

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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Dana Myers]

On 4/29/2019 11:54 AM, James Shaver wrote:

Hey Bill - on my Win10 64 bit machine that works but on my Win7 Home (32 bit) 
machine, it won’t resolve for me unless I restart.


Confirm the work-around works on my W10 64-bit machine.
Only 32-bit machines I have left are embedded controllers ;-)

73,
Dana  K6JQ

thanks for the issue report, I can confirm this is a defect. Clicking the "OK" 
button to leave the Settings dialog will take the mode out of FT4 and set FT8. You can 
work around this by selecting FT4 mode again.






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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Bill Somerville]

Hi Jim,

in what way doesn't it work on the 32-bit version? Are you saying that 
the "Menu->Mode->FT4" button is not functioning?


73
Bill
G4WJS.

On 29/04/2019 19:54, James Shaver wrote:

Hey Bill - on my Win10 64 bit machine that works but on my Win7 Home (32 bit) 
machine, it won’t resolve for me unless I restart.

73,

Jim S.
N2ADV (ex KD2BIP)


On Apr 29, 2019, at 2:49 PM, Bill Somerville  wrote:


On 29/04/2019 19:38, James Shaver wrote:
Follow up - mode gets changed back to FT8 if I got into the settings and change 
anything (for example, checking the box “Alternate F1-F6 bindings” and clicking 
OK returns the mode to FT8 and FT4 mode, even if selected, won’t work until the 
program is closed and restarted.

Hi Jim,

thanks for the issue report, I can confirm this is a defect. Clicking the "OK" 
button to leave the Settings dialog will take the mode out of FT4 and set FT8. You can 
work around this by selecting FT4 mode again.

73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Enrique Scheuer]

Calling now on  21140. No ( bad) news up to now.

de Enrique
PY2CP

Em seg, 29 de abr de 2019 às 15:53, Dana Myers  escreveu:

> On 4/29/2019 11:30 AM, James Shaver wrote:
> > I’m on 20 meters - After about 2-3 minutes of operating, I’m seeing the
> mode getting changed back to FT8 and my frequency is jumping to 14.074.
> This appears to be random (though it still shows the “FT4” configuration as
> being selected).  Selecting FT4 as the mode does not put me back to 14.080
> but closing the program and reopening brings me back to where I need to be.
> A reboot appears to have cured this but FYI in case anyone else is
> experiencing a similar issue.
>
> I see the mode pop back to FT4 any time I change a setting in File>Settings
>
> > Also, I’m already seeing quite a few people that have skipped step 8 in
> the setup instructions.
> Yes, you are...  ;-)
>
> 73,
> Dana
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[James Shaver]

Hey Bill - on my Win10 64 bit machine that works but on my Win7 Home (32 bit) 
machine, it won’t resolve for me unless I restart.  

73,

Jim S. 
N2ADV (ex KD2BIP)

> On Apr 29, 2019, at 2:49 PM, Bill Somerville  wrote:
> 
>> On 29/04/2019 19:38, James Shaver wrote:
>> Follow up - mode gets changed back to FT8 if I got into the settings and 
>> change anything (for example, checking the box “Alternate F1-F6 bindings” 
>> and clicking OK returns the mode to FT8 and FT4 mode, even if selected, 
>> won’t work until the program is closed and restarted.
> 
> Hi Jim,
> 
> thanks for the issue report, I can confirm this is a defect. Clicking the 
> "OK" button to leave the Settings dialog will take the mode out of FT4 and 
> set FT8. You can work around this by selecting FT4 mode again.
> 
> 73
> Bill
> G4WJS.
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Dana Myers]

On 4/29/2019 11:30 AM, James Shaver wrote:

I’m on 20 meters - After about 2-3 minutes of operating, I’m seeing the mode 
getting changed back to FT8 and my frequency is jumping to 14.074.  This 
appears to be random (though it still shows the “FT4” configuration as being 
selected).  Selecting FT4 as the mode does not put me back to 14.080 but 
closing the program and reopening brings me back to where I need to be. A 
reboot appears to have cured this but FYI in case anyone else is 
experiencing a similar issue.


I see the mode pop back to FT4 any time I change a setting in File>Settings


Also, I’m already seeing quite a few people that have skipped step 8 in the 
setup instructions.

Yes, you are...  ;-)

73,
Dana



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Michael Johnston]

I’m new to this list, so I’m not sure what the protocol is for reporting bugs. 
Please redirect me as appropriate.

I’ve just downloaded and installed RC5 on a Mac running OSX Mojave (10.14.3). 
(I previously had WSJT-X 2.0.1 installed). The app crashes at startup, with a 
popup dialog box saying ‘WSJT-X quit unexpectedly.” The stack trace is below.


Process:   wsjtx [34825]
Path:  /Applications/wsjtx.app/Contents/MacOS/wsjtx
Identifier:org.k1jt.wsjtx
Version:   v2.1.0-rc5 (2.1.0-rc5)
Code Type: X86-64 (Native)
Parent Process:??? [1]
Responsible:   wsjtx [34825]
User ID:   501

Date/Time: 2019-04-29 14:17:12.131 -0400
OS Version:Mac OS X 10.14.3 (18D109)
Report Version:12
Anonymous UUID:B1ED34EC-8FF8-B795-1683-7639C5437ADC

Sleep/Wake UUID:   3E5BFD17-9D21-4A10-A0DC-21720D0ED10C

Time Awake Since Boot: 340 seconds
Time Since Wake:   94 seconds

System Integrity Protection: enabled

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS at 0x
Exception Note:EXC_CORPSE_NOTIFY

Termination Signal:Segmentation fault: 11
Termination Reason:Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [34825]

VM Regions Near 0:
--> 
__TEXT 00010e59e000-00010ea66000 [ 4896K] r-x/rwx 
SM=COW  /Applications/wsjtx.app/Contents/MacOS/wsjtx

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgfortran.5.dylib 0x000113d622da 
_gfortran_concat_string + 23
1   org.k1jt.wsjtx  0x00010e6e0c3d azdist_ + 93
2   org.k1jt.wsjtx  0x00010e605cd5 
MainWindow::on_dxGridEntry_textChanged(QString const&) + 389
3   org.k1jt.wsjtx  0x00010e615a72 
MainWindow::qt_metacall(QMetaObject::Call, int, void**) + 82
4   org.qt-project.QtCore   0x00011387abfd 
QMetaObject::activate(QObject*, int, int, void**) + 1773
5   org.qt-project.QtWidgets0x000112a75684 0x112921000 + 1394308
6   org.qt-project.QtCore   0x00011387b14c 
QMetaObject::activate(QObject*, int, int, void**) + 3132
7   org.qt-project.QtWidgets0x000112a77186 
QWidgetLineControl::finishChange(int, bool, bool) + 614
8   org.qt-project.QtWidgets0x000112a7831a 
QWidgetLineControl::internalSetText(QString const&, int, bool) + 570
9   org.qt-project.QtWidgets0x000112a6fcef 0x112921000 + 1371375
10  org.k1jt.wsjtx  0x00010e6316cc 
MainWindow::readSettings() + 1436
11  org.k1jt.wsjtx  0x00010e61d76d 
MainWindow::MainWindow(QDir const&, bool, MultiSettings*, QSharedMemory*, 
unsigned int, QSplashScreen*, QWidget*) + 31901
12  org.k1jt.wsjtx  0x00010e6abe35 main + 6613
13  libdyld.dylib   0x7fff5e830ed9 start + 1

Thread 1:
0   libsystem_pthread.dylib 0x7fff5ea233f8 start_wqthread + 0
1   ??? 0x54485244 0 + 1414025796

Thread 2:
0   libsystem_pthread.dylib 0x7fff5ea233f8 start_wqthread + 0
1   ??? 0x54485244 0 + 1414025796

Thread 3:
0   libsystem_pthread.dylib 0x7fff5ea233f8 start_wqthread + 0
1   ??? 0x54485244 0 + 1414025796

Thread 4:
0   libsystem_pthread.dylib 0x7fff5ea233f8 start_wqthread + 0
1   ??? 0x54485244 0 + 1414025796

Thread 5:
0   libsystem_pthread.dylib 0x7fff5ea233f8 start_wqthread + 0
1   ??? 0x54485244 0 + 1414025796

Thread 6:
0   libsystem_pthread.dylib 0x7fff5ea233f8 start_wqthread + 0
1   ??? 0x54485244 0 + 1414025796

Thread 7:
0   libsystem_pthread.dylib 0x7fff5ea233f8 start_wqthread + 0
1   ??? 0x54485244 0 + 1414025796

Thread 8:
0   libsystem_pthread.dylib 0x7fff5ea233f8 start_wqthread + 0
1   ??? 0x54485244 0 + 1414025796

Thread 9:: Qt bearer thread
0   libsystem_kernel.dylib  0x7fff5e9722ee poll + 10
1   org.qt-project.QtCore   0x0001138a00a0 
qt_safe_poll(pollfd*, unsigned int, timespec const*) + 608
2   org.qt-project.QtCore   0x0001138a1897 
QEventDispatcherUNIX::processEvents(QFlags) + 903
3   org.qt-project.QtCore   0x00011384555f 
QEventLoop::exec(QFlags) + 431
4   org.qt-project.QtCore   0x00011368220c QThread::exec() + 140
5   org.qt-project.QtCore   0x000113683183 0x113661000 + 139651
6   libsystem_pthread.dylib 

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Bill Somerville]

On 29/04/2019 19:38, James Shaver wrote:

Follow up - mode gets changed back to FT8 if I got into the settings and change 
anything (for example, checking the box “Alternate F1-F6 bindings” and clicking 
OK returns the mode to FT8 and FT4 mode, even if selected, won’t work until the 
program is closed and restarted.


Hi Jim,

thanks for the issue report, I can confirm this is a defect. Clicking 
the "OK" button to leave the Settings dialog will take the mode out of 
FT4 and set FT8. You can work around this by selecting FT4 mode again.


73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[James Shaver]

Hey, Bill - thanks.  See my last note re: same :)

73,

Jim S. 
N2ADV (ex KD2BIP)

> On Apr 29, 2019, at 2:38 PM, Bill Somerville  wrote:
> 
>> On 29/04/2019 19:30, James Shaver wrote:
>> Also, I’m already seeing quite a few people that have skipped step 8 in the 
>> setup instructions.
> 
> Hi Jim,
> 
> that is consistent with Joe's release announcement, see the last sentence 
> here:
> 
> "FT4 is designed for contesting, but it will likely find some use for normal 
> QSOs as well, especially during the beta test period. In the coming month we 
> hope to receive useful feedback on the user interface, message sequencing, 
> interaction with logging programs, etc.  Probably it's best to use "normal" 
> (non-contest) messages except during the mock-contest practice sessions 
> scheduled for  - 0100 UTC on May 9 and May 14, and (if needed) June 5."
> 
> 73
> Bill
> G4WJS.
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[Bill Somerville]

On 29/04/2019 19:30, James Shaver wrote:

Also, I’m already seeing quite a few people that have skipped step 8 in the 
setup instructions.


Hi Jim,

that is consistent with Joe's release announcement, see the last 
sentence here:


"FT4 is designed for contesting, but it will likely find some use for 
normal QSOs as well, especially during the beta test period. In the 
coming month we hope to receive useful feedback on the user interface, 
message sequencing, interaction with logging programs, etc.  Probably 
it's best to use "normal" (non-contest) messages except during the 
mock-contest practice sessions scheduled for  - 0100 UTC on May 9 
and May 14, and (if needed) June 5."


73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[James Shaver]

Follow up - mode gets changed back to FT8 if I got into the settings and change 
anything (for example, checking the box “Alternate F1-F6 bindings” and clicking 
OK returns the mode to FT8 and FT4 mode, even if selected, won’t work until the 
program is closed and restarted.  

Also as a follow up to my below about step 8 - looks like the release email has 
a slight conflict with the PDF - perhaps the PDF with the setup instructions 
should be modified?  

73,

Jim S. 
N2ADV (ex KD2BIP)

> On Apr 29, 2019, at 2:30 PM, James Shaver  wrote:
> 
> I’m on 20 meters - After about 2-3 minutes of operating, I’m seeing the mode 
> getting changed back to FT8 and my frequency is jumping to 14.074.  This 
> appears to be random (though it still shows the “FT4” configuration as being 
> selected).  Selecting FT4 as the mode does not put me back to 14.080 but 
> closing the program and reopening brings me back to where I need to be. A 
> reboot appears to have cured this but FYI in case anyone else is 
> experiencing a similar issue.  
> 
> Also, I’m already seeing quite a few people that have skipped step 8 in the 
> setup instructions.  
> 
> 73,
> 
> Jim S. 
> N2ADV (ex KD2BIP)
> 
>> On Apr 29, 2019, at 2:05 PM, Joe Taylor  wrote:
>> 
>> To:   Users of WSJT-X -- especially those interested in radio contesting
>> From: WSJT Development Group
>> 
>> By now most of you know about the FT4 protocol under development for 
>> eventual release in WSJT-X 2.1.0.  The new mode is particularly optimized 
>> for use in radio contesting.
>> 
>> FT4 is mostly like FT8, but is 2.5 x faster, uses 1.8 x the bandwidth, and 
>> is 4.6 dB less sensitive.  Many other details are summarized in "The FT4 
>> Protocol for Digital Contesting", available here:
>> http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf
>> Links to translations in other languages are available on the WSJT-X web 
>> page:
>> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>> 
>> Release candidate WSJT-X 2.1.0-rc5 is intended for beta-testing through June 
>> 7, 2019.  Please note that the FT4 mode should NOT be used in the ARRL June 
>> VHF QSO Party (June 8-10) or ARRL Field Day (June 22-23).
>> 
>> We have done our best to provide suggested operating frequencies for the 
>> test period consistent as far as possible with world-wide band plans and 
>> existing usage.  Please note that thanks to good user feedback, some of 
>> these frequencies are different from those suggested in the document linked 
>> above.
>> 
>> Default frequencies currently recommended for FT4 are as follows:
>> 
>> Band   MHzNotes
>> -
>> 803.575   (3.568 MHz in Region 3)
>> 407.047
>> 30   10.140
>> 20   14.080
>> 17   18.104
>> 15   21.140
>> 12   24.919
>> 10   28.180
>> 6   50.318
>> 2  144.170
>> 
>> FT4 is designed for contesting, but it will likely find some use for normal 
>> QSOI’m on 20 meters - After about 2-3 minutes of operating, I’m seeing the 
>> mode getting changed back to FT8 and my frequency is jumping to 14.074.  
>> This appears to be random (though it still shows the “FT4” configuration as 
>> being selected).  Selecting FT4 as the mode does not put me back to 14.080 
>> but closing the program and reopening brings me back to where I need to be. 
>> A reboot appears to have cured this but FYI in case anyone else is 
>> experiencing a similar issue.  
> 
> Also, I’m already seeing quite a few people that have skipped step 8 in the 
> setup instructions.  
> 
> 73,
> 
> Jim S. 
> N2ADV (ex KD2BIP)
> 
>> On Apr 29, 2019, at 2:05 PM, Joe Taylor  wrote:
>> 
>> To:   Users of WSJT-X -- especially those interested in radio contesting
>> From: WSJT Development Group
>> 
>> By now most of you know about the FT4 protocol under development for 
>> eventual release in WSJT-X 2.1.0.  The new mode is particularly optimized 
>> for use in radio contesting.
>> 
>> FT4 is mostly like FT8, but is 2.5 x faster, uses 1.8 x the bandwidth, and 
>> is 4.6 dB less sensitive.  Many other details are summarized in "The FT4 
>> Protocol for Digital Contesting", available here:
>> http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf
>> Links to translations in other languages are available on the WSJT-X web 
>> page:
>> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>> 
>> Release candidate WSJT-X 2.1.0-rc5 is intended for beta-testing through June 
>> 7, 2019.  Please note that the FT4 mode should NOT be used in the ARRL June 
>> VHF QSO Party (June 8-10) or ARRL Field Day (June 22-23).
>> 
>> We have done our best to provide suggested operating frequencies for the 
>> test period consistent as far as possible with world-wide band plans and 
>> existing usage.  Please note that thanks to good user feedback, some of 
>> these frequencies are different from those suggested in the document linked 
>> above.
>> 
>> Default frequencies currently recommended for FT4 are as follows:
>> 
>> Band   MHzNotes
>> 

Re: [wsjt-devel] WSJT-X 2.1.0-rc5

[James Shaver]

I’m on 20 meters - After about 2-3 minutes of operating, I’m seeing the mode 
getting changed back to FT8 and my frequency is jumping to 14.074.  This 
appears to be random (though it still shows the “FT4” configuration as being 
selected).  Selecting FT4 as the mode does not put me back to 14.080 but 
closing the program and reopening brings me back to where I need to be. A 
reboot appears to have cured this but FYI in case anyone else is 
experiencing a similar issue.  

Also, I’m already seeing quite a few people that have skipped step 8 in the 
setup instructions.  

73,

Jim S. 
N2ADV (ex KD2BIP)

> On Apr 29, 2019, at 2:05 PM, Joe Taylor  wrote:
> 
> To:   Users of WSJT-X -- especially those interested in radio contesting
> From: WSJT Development Group
> 
> By now most of you know about the FT4 protocol under development for eventual 
> release in WSJT-X 2.1.0.  The new mode is particularly optimized for use in 
> radio contesting.
> 
> FT4 is mostly like FT8, but is 2.5 x faster, uses 1.8 x the bandwidth, and is 
> 4.6 dB less sensitive.  Many other details are summarized in "The FT4 
> Protocol for Digital Contesting", available here:
> http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf
> Links to translations in other languages are available on the WSJT-X web page:
> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
> 
> Release candidate WSJT-X 2.1.0-rc5 is intended for beta-testing through June 
> 7, 2019.  Please note that the FT4 mode should NOT be used in the ARRL June 
> VHF QSO Party (June 8-10) or ARRL Field Day (June 22-23).
> 
> We have done our best to provide suggested operating frequencies for the test 
> period consistent as far as possible with world-wide band plans and existing 
> usage.  Please note that thanks to good user feedback, some of these 
> frequencies are different from those suggested in the document linked above.
> 
> Default frequencies currently recommended for FT4 are as follows:
> 
> Band   MHzNotes
> -
> 803.575   (3.568 MHz in Region 3)
> 407.047
> 30   10.140
> 20   14.080
> 17   18.104
> 15   21.140
> 12   24.919
> 10   28.180
> 6   50.318
> 2  144.170
> 
> FT4 is designed for contesting, but it will likely find some use for normal 
> QSOs as well, especially during the beta test period.  In the coming month we 
> hope to receive useful feedback on the user interface, message sequencing, 
> interaction with logging programs, etc.  Probably it's best to use "normal" 
> (non-contest) messages except during the mock-contest practice sessions 
> scheduled for  - 0100 UTC on May 9 and May 14, and (if needed) June 5.
> 
> Downloadable installation packages for WSJT-X 2.1.0-rc5 under Windows, Linux, 
> and macOS are available on the WSJT-X web page:
> 
> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
> 
> Windows users will discover that WSJT-X v2.1.0 has been made available as a 
> 64-bit MS Windows build for 64-bit versions of Windows since Vista. This 
> veraion has one known defect. The audio input device level will be reset to 
> 100% when WSJT-X is started, when the input audio device is changed, and when 
> switching to a new configuration. This is a Qt framework defect that we have 
> reported and is being fixed in a future release; until then users should take 
> care to set the device audio level back to 0dB or lower depending on 
> requirements. Note that many sound cards and chips have real gain ahead of 
> the ADC, as much as 14dB, which will be turned to the maximum due to this 
> defect and is usually undesirable when using WSJT-X.
> 
> Despite this annoying defect, we recommend the 64-bit version of WSJT-X on MS 
> Windows as it has significant advantages in decoding speed.
> 
>-- 73 from Joe, K1JT; Steve, K9AN; and 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] WSJT-X 2.1.0-rc5

[Joe Taylor]

To:   Users of WSJT-X -- especially those interested in radio contesting
From: WSJT Development Group

By now most of you know about the FT4 protocol under development for 
eventual release in WSJT-X 2.1.0.  The new mode is particularly 
optimized for use in radio contesting.


FT4 is mostly like FT8, but is 2.5 x faster, uses 1.8 x the bandwidth, 
and is 4.6 dB less sensitive.  Many other details are summarized in "The 
FT4 Protocol for Digital Contesting", available here:

http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf
Links to translations in other languages are available on the WSJT-X web 
page:

http://physics.princeton.edu/pulsar/k1jt/wsjtx.html

Release candidate WSJT-X 2.1.0-rc5 is intended for beta-testing through 
June 7, 2019.  Please note that the FT4 mode should NOT be used in the 
ARRL June VHF QSO Party (June 8-10) or ARRL Field Day (June 22-23).


We have done our best to provide suggested operating frequencies for the 
test period consistent as far as possible with world-wide band plans and 
existing usage.  Please note that thanks to good user feedback, some of 
these frequencies are different from those suggested in the document 
linked above.


Default frequencies currently recommended for FT4 are as follows:

Band   MHzNotes
-
803.575   (3.568 MHz in Region 3)
407.047
30   10.140
20   14.080
17   18.104
15   21.140
12   24.919
10   28.180
 6   50.318
 2  144.170

FT4 is designed for contesting, but it will likely find some use for 
normal QSOs as well, especially during the beta test period.  In the 
coming month we hope to receive useful feedback on the user interface, 
message sequencing, interaction with logging programs, etc.  Probably 
it's best to use "normal" (non-contest) messages except during the 
mock-contest practice sessions scheduled for  - 0100 UTC on May 9 
and May 14, and (if needed) June 5.


Downloadable installation packages for WSJT-X 2.1.0-rc5 under Windows, 
Linux, and macOS are available on the WSJT-X web page:


http://physics.princeton.edu/pulsar/k1jt/wsjtx.html

Windows users will discover that WSJT-X v2.1.0 has been made available 
as a 64-bit MS Windows build for 64-bit versions of Windows since Vista. 
This veraion has one known defect. The audio input device level will be 
reset to 100% when WSJT-X is started, when the input audio device is 
changed, and when switching to a new configuration. This is a Qt 
framework defect that we have reported and is being fixed in a future 
release; until then users should take care to set the device audio level 
back to 0dB or lower depending on requirements. Note that many sound 
cards and chips have real gain ahead of the ADC, as much as 14dB, which 
will be turned to the maximum due to this defect and is usually 
undesirable when using WSJT-X.


Despite this annoying defect, we recommend the 64-bit version of WSJT-X 
on MS Windows as it has significant advantages in decoding speed.


-- 73 from Joe, K1JT; Steve, K9AN; and Bill, G4WJS


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

Re: [wsjt-devel] The FT4 Protocol for Digital Contesting - more on frequencies

[Bill Somerville]

On 29/04/2019 16:05, Grant VK5GR wrote:


At the risk of incurring the wrath of the JT65 folks, your suggestion 
in my mind has some merit. I would go as far to say an alternate 
strategy is to take the old JT65 frequencies and use them for FT4, and 
have the JT65 folks move to the JT9 channels – grouping both of the 
weak signal modes together in one segment. WSJT can decode both 
simultaneously and neither JT65 or JT9 has a lot of traffic these days 
so maybe that is the ultimate for everyone – given that in days gone 
by JT9 and JT65 used to share anyway to an extent).


You could apply that across the board – with the exception of Region 3 
on 80m. I would agree with the compromise that Bill has suggested with 
3568 in R3 and 3575 elsewhere (n fact make it 3576 and follow the 
above suggested convention).


Bill – a different approach – do you think it has merit?


HI Grant and George,

I agree that it could work but it will compress all the 60 T/R modes 
into a 2 kHz section. Although that is not unreasonable it does have the 
issue that there is no decoder that can decode JS8CALL and JT9 and JT65. 
The dual mode JT9+JT65 decoder in WSJT-X relies on JT9 signals being 
separated above other signals and decoder performance is severely 
degraded if that is not the case.


Anyway, for now we are going with my suggested changes since we have a 
deadline rushing up towards us. We are only into a beta testing phase 
and changes can still be made without too much disruption once we have a 
better feel for how FT4 is going to be used.


In summary WSJT-X v2.1.0 RC5 will have the following FT4 suggested 
frequencies (the Iter1 column):


Band Iter0   Iter1   Notes
-
80    3595    3575   (plus 3568 Region 3)
40    7090    7047
30   10140   10140
20   14140   14080
17   18104   18104
15   21140   21140
12   24919   24919
10   28180   28180
 6   50318   50318
 2  144170  144170

73
Bill
G4WJS.

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

Re: [wsjt-devel] The FT4 Protocol for Digital Contesting - more on frequencies

[Grant VK5GR]

George,

 

At the risk of incurring the wrath of the JT65 folks, your suggestion in my 
mind has some merit. I would go as far to say an alternate strategy is to take 
the old JT65 frequencies and use them for FT4, and have the JT65 folks move to 
the JT9 channels – grouping both of the weak signal modes together in one 
segment. WSJT can decode both simultaneously and neither JT65 or JT9 has a lot 
of traffic these days so maybe that is the ultimate for everyone – given that 
in days gone by JT9 and JT65 used to share anyway to an extent).

 

You could apply that across the board – with the exception of Region 3 on 80m. 
I would agree with the compromise that Bill has suggested with 3568 in R3 and 
3575 elsewhere (n fact make it 3576 and follow the above suggested convention).

 

Bill – a different approach – do you think it has merit?

 

Grant

 

 

From: George J. Molnar [mailto:geo...@molnar.tv] 
Sent: Tuesday, 30 April 2019 12:16 AM
To: WSJT software development
Subject: Re: [wsjt-devel] The FT4 Protocol for Digital Contesting - more on 
frequencies

 

A quick two cents…

 

Is there a good reason why FT4 could not use the existing JT65 and JT9 watering 
holes on all bands? They are quite clear most of the time, and considerate 
operators could certainly share, especially with JT9.

 

In areas where licenses don’t allow operation on the watering holes, it seems 
that we have (mostly) figured it out around the world.

 

Looking forward to testing out the new mode. Wonder if speed will trump 
sensitivity for general use?

 

Many thanks to the dev team for years of effort for the ham community.

 

 

George J Molnar
KF2T, Arlington, Virginia, USA

 

Please note my new email: geo...@molnar.tv

 

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

Re: [wsjt-devel] The FT4 Protocol for Digital Contesting - more on frequencies

[George J. Molnar]

A quick two cents…

Is there a good reason why FT4 could not use the existing JT65 and JT9 watering 
holes on all bands? They are quite clear most of the time, and considerate 
operators could certainly share, especially with JT9.

In areas where licenses don’t allow operation on the watering holes, it seems 
that we have (mostly) figured it out around the world.

Looking forward to testing out the new mode. Wonder if speed will trump 
sensitivity for general use?

Many thanks to the dev team for years of effort for the ham community.


George J Molnar
KF2T, Arlington, Virginia, USA


Please note my new email: geo...@molnar.tv

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

Re: [wsjt-devel] The FT4 Protocol for Digital Contesting - more on frequencies

[Bill Somerville]

Hi Grant,

My main criteria was to try and offer suggestions that stay within the 
band plan narrow band digital mode sections. Although there are no good 
solutions for some bands (80m, 40m and 20m particularly) I think going 
below those sections is not justifiable as that would be straying into 
CW only sections. The most vociferous objections have been to choices 
above the band plan narrow band digital mode sections despite the band 
plans not disallowing such operation. In general band plans offer a 
dedicated section to a narrow mode, then the next wider modes above and 
so on, with no restriction on using a narrower mode in a wider mode 
section. Despite this suggestions of using FT4 in an all mode section of 
a band seem to be rejected out of hand. Specifically, some comments from 
members of the band planning committees have requested that we pick 
frequencies *below* the upper limits of narrow band digital mode sections.


On 29/04/2019 14:48, Grant VK5GR wrote:
Given your comments here, I still feel 80m will be a problem on 3590 
as it gives the JA community no guidance on where to go. I also think 
it is a little optimistic to think that the traffic will stay on 2kHz. 
It will spread to at least 3kHz. The use of 3567kHz by several 
expeditions for F?H mode despite being outside the band segment hasn’t 
been the end of the world. My suggestion is still for 3565kHz – and 
then lets start the move through various member societies to push IARU 
to widen the 80m digital modes segment down 5KHz to improve global 
alignment opportunities with Japan. If not, well 3590 will work (and 
at least avoids the WEFAX broadcast transmitter in Sth Korea on 
3585-3589kHz).


Unfortunately I made yet another typo with my suggestions above - having 
a bad day juggling frequencies here. I meant to suggest 3586 for all 
regions and 3568 for R3. That would offer both to R3 users so they can 
choose to interoperate simplex with JA, R1 and R2 ops. Those in R1 and 
R2 would have WSJT-X default to 3586 and they would have to QSY manually 
or set up a split to work JAs down on 3568.


Looking again I wonder if 3568 for R3 and 3575 for all regions might be 
better as it meets the criteria of staying within the narrow band 
digital mode sections for R1 and R2. The downside is that it will be 
close to the OLIVIA, Contestia, etc. folks who have a alternate QRG of 
3577 (USB dial) although I don't know if it gets used.


40m, I had like you originally considered going below 7050 but the 
desire to create some separation between the RTTY and FT4 contesters 
drove my recommendation to go above 7060. Yes it is an SSB segment 
(indeed digital voice is marked as a CoA in some regions for 7065) – 
but in that sense it is no better or worst than 7090 other than it is 
less likely to interfere with international DX SSB and more likely to 
interfere with domestic nets. 40m really is a mess and ultimately now 
that the world has access (since 2006) to 200kHz of the band it should 
be replanned properly, with CW 7000-7040, data 7040-7080 and SSB 
7080-7200. Another task to take to the IARU.


Here in the EU there are still many nets etc. right down to the upper 
limits of digital mode operation sections as the extra 7100 - 7200 
allocation is still shaking out. Any proposed frequency in an all mode 
section is bound to land on some claimed territory.


73
Bill
G4WJS.

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

Re: [wsjt-devel] The FT4 Protocol for Digital Contesting - more on frequencies

[Grant VK5GR]

Bill,

 

Thanks for the reply – and it looks like we were sending things at the same 
time J My apolgies for my earlier mail as it seems we crossed paths in the 
night.

 

Given your comments here, I still feel 80m will be a problem on 3590 as it 
gives the JA community no guidance on where to go. I also think it is a little 
optimistic to think that the traffic will stay on 2kHz. It will spread to at 
least 3kHz. The use of 3567kHz by several expeditions for F?H mode despite 
being outside the band segment hasn’t been the end of the world. My suggestion 
is still for 3565kHz – and then lets start the move through various member 
societies to push IARU to widen the 80m digital modes segment down 5KHz to 
improve global alignment opportunities with Japan. If not, well 3590 will work 
(and at least avoids the WEFAX broadcast transmitter in Sth Korea on 
3585-3589kHz).

 

40m, I had like you originally considered going below 7050 but the desire to 
create some separation between the RTTY and FT4 contesters drove my 
recommendation to go above 7060. Yes it is an SSB segment (indeed digital voice 
is marked as a CoA in some regions for 7065) – but in that sense it is no 
better or worst than 7090 other than it is less likely to interfere with 
international DX SSB and more likely to interfere with domestic nets. 40m 
really is a mess and ultimately now that the world has access (since 2006) to 
200kHz of the band it should be replanned properly, with CW 7000-7040, data 
7040-7080 and SSB 7080-7200. Another task to take to the IARU.

 

20m – 14.080 – I can see a case for that – but it is RTTY heartland and will 
cause conflict. (A bit like the problems on 14090 at times with F/H mode). We 
originally dismissed 14080 for F/H mode when I was working with the KH1/KH7Z 
team for that reason. If it was a choice between 14140 and 14080 I would pick 
14080. I would still encourage you to consider 14065 – which again is no worst 
off than 14140 in terms of band plan non compliance but does at least provide 
the separation between the FT4 and RTTY contest communities while avoiding 
angst with the PSK and QRP CW communities.

 

15m and 10m – my arguments are not strong – could easily be swayed.

 

Finally – WRC bands – if the idea is to reuse the JT9 assignments for now. 
I can understand if there is an expectation that DXers will want to use FT4 as 
well. I think you have to be very careful however with the word contesting and 
WRC bands or you will be howled down very loudly. Best make sure that on those 
bands only standard exchanges can be enabled and none of the fancy contesting 
exchange modes to preserve some face there.

 

Again feedback most welcome!

 

Regards,

Grant

 

 

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Monday, 29 April 2019 9:00 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] The FT4 Protocol for Digital Contesting

 

Hi Grant,

 

thanks for taking the time to look at possibilities for FT4 band slots. 
Comments in line below.

 

On 26/04/2019 12:15, Grant VK5GR wrote:

Joe et al,
 
A word if I may about frequency choices. Some of those proposed for FT4
probably leave a bit to be desired. Here are some thoughts to consider:
 
80m 3.595 - PROPOSE 3562kHz - 3595 is completely out of band for JA
completely and into the phone part of the band outside of Region 2. My
suggestion based on occupancy and proximity to existing digital sub-bands is
something around 3562kHz (at least keeping away from 3560 which is sometimes
a CW QRP frequency). While the IARU band plans currently have digital as
3570-3590kHz a case can be made for expanding that - and given other
restrictions in some countries on 80m, expanding digital down at least 8kHz
to 3562kHz makes some sense. A case to be made for the IARU - but you can
"help" their decision by starting to use it anyway. BTW 3600kHz is the
centre frequency for IARU R3 80m disaster comms - LSB - so FT4 on 3595 USB
will badly clash with that - another reason not to use 3595.

3562 kHz is a problem in both regions 1 and 2 as it is below the narrow band 
digital mode sub-band which starts at 3570 kHz. The only overlap with JA and 
the rest of the World is 3570 - 3575 kHz which is effectively 3570 - 3573 kHz 
if we assume USB and a 2 kHz wide slot. Having looked at as many bad plans as I 
can find I can only suggest 3590 kHz with an alternate of 3568 kHz for region 
3. 3586 kHz is probably considered as RTTY territory so even that is not free 
of contention.



 
 
40m 7.090 - PROPOSE 7052kHz (inside the digital sub-band) or 7062kHz (just
above the digital sub-band noting it is heavily used for SSB at least in
region 3) - 7090 only makes sense in the USA! Many other countries have this
as SSB voice use. The IARU digital segment is (depending on region)
7040-7060 or 7040-7060. With 7056 already being used for FT8 F/H mode on a
fairly regular basis it would make sense to use say 7050 or 7052kHz instead.
Note that 7090 is 

Re: [wsjt-devel] FT4 Frequencies

[Grant VK5GR]

Bill,

 

I wrote on this list a discussion and some options on this topic. I received
feedback from some of the readers but none from yourself or Joe and the
team. Did you receive it? 

 

I explained why the original proposals were less than ideal and offered a
reasoned argument for alternatives. Feedback on the initial thoughts was
received and a further revision offered.

 

The summary version of my recommendations therefore are:

 

3.565, 7.065, 14.065, 21.065 and 28.065 

 

This meets the following criteria:

1.   provides separation between RTTY and FT4 contesters when they are
running simultaneously (RTTY runs above the FT8/JT9 segments currently)

2.   avoids/limits impact on known QRP CW centres of activity 

3.   avoids impact on the PSK community on .070-.074 

4.   avoids pushing digital modes far into the voice segment of the
bands particularly on 80/20m but is a major compromise on 40m. 40m's digital
modes segments are a mess anyway and harmonisation is difficult at best on
that band. From a global SSB usage perspective 7.065 should offer a reduced
impact compared to moving above 7.080MHz and for all but CQ WW and CQ WPX
RTTY most RTTY contests stick to 7030-7060 today.

 

These are admittedly outside current digital segments in all cases. That
didn't seen to be a consideration of the original proposals either so no net
gain or loss in that regard. As far as actual band usage goes, these
suggestions probably offer long term a lower impact outcome than what the
FT8 team originally proposed IMHO. 

 

Of the original proposals, I offered the following observations in support
of the above arguments:

 

1.   80m - 3595kHz USB proposed frequency was outside the JA 80m band
and would interfere with the IARU R3 emergency comms Centre of Activity on
3600kHz LSB

2.   40m - 7090kHz USB - way outside the digital modes segment for
everywhere but North America. Impacts SSB voice operators in Region 1 and 3.
Will not be well received

3.   20m - 14140kHz USB - again way outside the digital modes segment. I
presume it was intended to get above the bulk of the RTTY operators in a
RTTY contest. There is no guarantee of that happening however. A better
outcome would be to move below the current fixed digital mode transmissions
below 14.070 and provide complete separation of FT4 from RTTY during a
digital contest.

4.   15m - 21140kHz - actually might have been OK - but after the
discussion on the other bands, if a convention of using .x65 can be
established then it would help operator memory.

5.   10m - 21180kHz - same argument as 15m

6.   WRC Bands - if the mode is intended for contesting then based on
the IARU global agreement to not hold contests on WRC bands, not allocating
frequencies on 30/17/12m for a mode with "Contesting" in its DNA is a good
thing. If FT4 starts to take over from FT8 or FT8 F/H mode for general
DXing, then come back and revisit frequency allocations on those bands.
However, as your stated objective is to start with FT4 as a CONTESTING mode,
don't offer WRC band frequencies.

 

Your thoughts please?

 

Regards,

Grant VK5GR

 

 

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Monday, 29 April 2019 1:22 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FT4 Frequencies

 

On 28/04/2019 16:07, Richard Solomon wrote:

Since roll-out is imminent, have we an agreement on which 

frequencies to use ?

 

73, Dick, W1KSZ

Hi Dick,

not yet. There are many claims on the frequencies we have proposed, a few
with suggested alternatives but mostly just asking us to go elsewhere.
Getting to an acceptable set of suggested frequencies for FT4 even for
occasional contest periods is difficult and it is made even harder if we
assume, not unreasonably, that FT4 may be used for general DXing as well.

One option is not to recommend any frequencies and let the community sort it
out, then add the resulting frequencies to the default recommendations later
as/if they converge. Unfortunately I don't think that will achieve the
desirable global coordination, nor is it likely to converge on the best
choices. The only good attribute would be that the developers can say "we
didn't choose that frequency, don't blame us for QRM" which is a bit of a
cop out, and we will still be blamed anyway.

Another option is to sacrifice the JT9 slots in favour of FT4. Clearly that
is not straightforward given that JS8CALL has made a claim on that bandwidth
too. Personally I would love to see JT9 get more use, it is a great mode for
HF and I miss working the world with a few mW on the HF bands.

Given the lack of truly free globally available slots in the narrow band
digital mode band plans, I suspect that no more than one 2 kHz slot per band
for FT4 should be an aim. By that I mean that if there is a contest using
FT4 then it should use those frequencies and non-contest participants should
defer. This is based on the premiss that FT4 has 

Re: [wsjt-devel] The FT4 Protocol for Digital Contesting

[Bill Somerville]

On 29/04/2019 12:30, Bill Somerville wrote:


So in summary, I am suggesting amending our proposed suggested 
frequencies for FT4 to:


*3595 kHz all regions 1 and 2**
**3568 kHz region 3*

*7074 kHz all regions*

10140 kHz all regions - shared with JT9 and JS8CALL

*14080 kHz all regions*

18104 kHz all regions - shared with JT9 and JS8CALL

21140 kHz all regions

24919 kHz all regions

28180 kHz all regions

50318 kHz all regions


Hi Grant and all,

there is a typo in the above please read as:

*7047 kHz all regions*

The in line commentary had the correct intended frequency.

73
Bill
G4WJS.
**

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

Re: [wsjt-devel] The FT4 Protocol for Digital Contesting

[Bill Somerville]

Hi Grant,

thanks for taking the time to look at possibilities for FT4 band slots. 
Comments in line below.


On 26/04/2019 12:15, Grant VK5GR wrote:

Joe et al,

A word if I may about frequency choices. Some of those proposed for FT4
probably leave a bit to be desired. Here are some thoughts to consider:

80m 3.595 - PROPOSE 3562kHz - 3595 is completely out of band for JA
completely and into the phone part of the band outside of Region 2. My
suggestion based on occupancy and proximity to existing digital sub-bands is
something around 3562kHz (at least keeping away from 3560 which is sometimes
a CW QRP frequency). While the IARU band plans currently have digital as
3570-3590kHz a case can be made for expanding that - and given other
restrictions in some countries on 80m, expanding digital down at least 8kHz
to 3562kHz makes some sense. A case to be made for the IARU - but you can
"help" their decision by starting to use it anyway. BTW 3600kHz is the
centre frequency for IARU R3 80m disaster comms - LSB - so FT4 on 3595 USB
will badly clash with that - another reason not to use 3595.
3562 kHz is a problem in both regions 1 and 2 as it is below the narrow 
band digital mode sub-band which starts at 3570 kHz. The only overlap 
with JA and the rest of the World is 3570 - 3575 kHz which is 
effectively 3570 - 3573 kHz if we assume USB and a 2 kHz wide slot. 
Having looked at as many bad plans as I can find I can only suggest 3590 
kHz with an alternate of 3568 kHz for region 3. 3586 kHz is probably 
considered as RTTY territory so even that is not free of contention.


40m 7.090 - PROPOSE 7052kHz (inside the digital sub-band) or 7062kHz (just
above the digital sub-band noting it is heavily used for SSB at least in
region 3) - 7090 only makes sense in the USA! Many other countries have this
as SSB voice use. The IARU digital segment is (depending on region)
7040-7060 or 7040-7060. With 7056 already being used for FT8 F/H mode on a
fairly regular basis it would make sense to use say 7050 or 7052kHz instead.
Note that 7090 is the designated SSB QRP frequency. I would promote 7050 for
FT4. The only reason not to is that the RTTY guys if FT4 and RTTY are in the
same contest might object - but during the contests the RTTY guys spread out
and use anything from 7030 to 7120 anyway in complete disregard of the band
plans. If they are going to be that unruly then putting FT4 down there
doesn't seem all that bad.
7052 kHz is in the wide band digital mode section for region 1 and 
region 2 which allows packet and related modes where there are automatic 
stations active, so may not be compatible. As far as I can see 7047 kHz 
looks a reasonable choice with the main criteria being below the 7050 
kHz upper limit for narrow band digital modes in regions 1 and 2.


* 30m / 17m / 12m - should NOT have FT4 allocations at all. FT4 is a
CONTESTING mode and CONTESTING is by global agreement excluded from those
WRC79 bands!!! *
FT4 is capable of the exact same operation style as FT8 and I doubt we 
will limit its use to contest modes only. the 30m, 17m, and 12m proposed 
suggestions are the same as currently used for JT9/JS8CALL, we are not 
encouraging increased bandwidth use on those band. If usage grows the 
working frequency suggestions can be revised later.


20m 14.140 - PROPOSE 14062kHz - the original proposed use of 14140KHz again
is well outside the digital segments where FT4 belongs. If anything,
creeping down into 14060-14070 might be considered acceptable despite not
being in the band plan if the aim was to separate RTTY and FT4 users in the
same contest. Going high above 14.112 (the acknowledged edge of the global
20m digital band plan segment) will be frowned upon. Take a leaf from 80m
and use 14062kHz - again at least that keeps it away from the CW QRP Centre
of activity and meets the objective of separating it from RTTY.
14062 kHz is below the lower limit for narrow band digital modes in all 
three regions at 14070 kHz. 14080 kHz is the best alternative I can come 
up with. It is in RTTY territory again but I don't see anything better 
below 14099 kHz.


15m 21.140 - PROPOSE 21062kHz - follow 20m and choose 21062kHz - although
21140kHz is the first proposed FT4 frequency that fell inside a digital
subband...
I don't see any issues with 21140 kHz and you are the first to suggest 
an alternative. What is your objection to 21140 kHz?


10m 28.180 - POROPOSE 28062kHz - again follow 20m
I don't see any issues with 28180 kHz and you are the first to suggest 
an alternative. What is your objection to 28180 kHz?


6m 50.318 - PROPOSE somewhere below 50.313 not above. Moving above is just
moving further into several countries beacon segments. Not likely to get a
lot of airplay as a international contesting band for FT8 so not as critical
- but my suggestion would be look below 50.313 not above.
I don't understand why countries like VK are putting beacons in the 50.3 
- 50.4 MHz range, I thought International