From: Tony Collett
Date: Wed, 03 Feb 2021 16:06:01 PST
Hi Group
I had an intriguing experience yesterday calling a Fox on 30m
When my call was selected my Tx was correctly moved to the Fox frequency but he was not seeing my report so he kept sending his report to me while I responded with his report for 3 periods.
On the 4th period he dropped my call and went on to work a different station - my first failure to work an F&H QSO !
What I didn't expect was that my transmitter was moved off the Fox frequency to a different one (but still below 1000Hz) and WSJT kept sending my report to the Fox. It continued to do this for some time and the timer didn't come into operation which it does when you are just calling the Fox.

I had this same experience with 4U1UN on 30M. After sending my transmission several times at about +750, the QSO completed.

I noted that while many of the stations calling were loud, they were frequently receiving reports lower than -15. Possibly he has high noise levels or a receiver problem?

I had observed this same F/H behavior with 4U1UN a few days earlier on 40M, but didn't manage to work him that time.

73,

John, K9MM

On 04/02/2021 02:42, David Piersall wrote:

You've given a very good description of how Dxpedition mode works. Three strikes and you're out, as we say in the US.
If the Fox doesn't complete with you, you get kicked into the weeds where you won't bother him any more. Immediately go back above 1000 and start over. I've certainly been there and done that.

Dave, N6ORB

Dave,

"kicked into the weeds" is not what is happening here. If you can't complete with the Fox in a couple of overs WSJT-X will shift you up a couple of hundred Hertz to allow stations with better propagation to be worked, but the Fox is still able to decode your signal and reply. Admittedly after a couple of minutes your best strategy is to move up above 1000 Hz and call again when you hear the Fox. If you are just waiting for an RR73 from the Fox then persevere a bit longer as the Fox will keep replying to R+report messages even if they have already logged the QSO.

73
Bill
G4WJS.

I am reporting a problem trying to use WSJT-x and the above configuration
I started with release 1.1 and it was working perfectly, release 2.2 and 2.3 are giving the same results: no tone output to tranceiver via the USB connection.
The input is instead working , i am not using the CAT (none as transceiver in the configuration).
Let me add also an inconvenient in selection the audio devices to be chosen, the USB device list which is very long and where is impossible to understand what is the desired device without a correspondence with the Linux system naming. What i did (but not the best solution) i have been addressing the USB audio input and output as default device to the system and selecting default as audio device in the wsjt configuration. Doing it i am able to receive but not to send while i am able to send from the system a .wav file addressing the K3s which means a working physical connection.
The mode i am using is JT65, it would be nice to have it working and avoid to be forced to remove the default on board audio from the Linux configuration while using WSJT.
Thanks for the attention , i1ndp nando

On 04/02/2021 02:38, Pat via groups.io wrote:

Hi Bill
2.2.2

Hi Pat,

please upgrade to v2.3.0.

73
Bill
G4WJS.

Just loaded 2.4.0 rc1 and was monitoring jt4d and jt4F, both crashed with error  EXIT CODE 2, and the following detail::

reinstall v2.3.0 and all ok.

Running: C:\WSJT\wsjtx\bin\jt9 -s WSJT-X -w 1 -m 3 -e C:\WSJT\wsjtx\bin -a C:\Users\Dave\AppData\Local\WSJT-X -t C:\Users\Dave\AppData\Local\Temp\WSJT-X

At line 13 of file C:\Users\bill\src\k1jt\wsjtx\lib\pctile.f90

Fortran runtime error: Index '-26' of dimension 1 of array 'tmp' below lower bound of 1

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open

#0 0xffffffff

#1 0xffffffff

#2 0xffffffff

#3 0xffffffff

#4 0xffffffff

#5 0xffffffff

#6 0xffffffff

#7 0xffffffff

#8 0xffffffff

#9 0xffffffff

#10 0xffffffff

#11 0xffffffff

#12 0xffffffff

#13 0xffffffff

#14 0xffffffff

#15 0xffffffff

  73 Dave ZL2MQ

here is his adif file in my wsjt log

correction
 his call is k4yt
sorry Karl for hacking up your call.
Pat

On 04/02/2021 13:27, James Quick wrote:

Hello All,

I am running macOS Big Sur and wsjtx 2.3.0 with no trouble. Just installed wsjtx 2.4.0-rc1 and it starts ok but about 45 seconds it closes down. No error report or nothing. Has anyone got it running on a Mac computer? Thanks for any help or advice.

73

Jim Quick / N4ULE
jimn4ule@...

Hi Jim,

see this message posted to the wsjt-devel list on Source Forge:

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

73
Bill
G4WJS.

Hello All,

I am running macOS Big Sur and wsjtx 2.3.0 with no trouble. Just installed wsjtx 2.4.0-rc1 and it starts ok but about 45 seconds it closes down. No error report or nothing. Has anyone got it running on a Mac computer? Thanks for any help or advice.

73

Jim Quick / N4ULE
jimn4ule@...

Hi

interestingly for me 2.3 did exactly the same as rc3: that is installed OK , ran, then exited silently after around 4 minutes leaving nothing in the events log. Rebooting the PC fixed it.

I am running Wn10 Pro 20H2 fully patched on a Lenovo i7 machine with 16Gb RAM and SSD.

Jon

Just to add my recent experiences to this thread...

In late October 2020 I commissioned a new PC for my 'radio' apps - the PC is a Dell 3070 with an i7-9500 CPU, 16G RAM and a 512GB SSD, running (64-bit) Win 10 Pro.  I installed WSJT-X v2.2.2 on the new PC and everything worked absolutely fine.

I didn't get round to trying any of the -rc versions of v2.3.0 but a couple of days ago I decided to upgrade to the GA release of v2.3.0, at which point I discovered that for some unfathomable reason I'd installed the 32-bit version of v2.2.2 when I'd installed it on the new PC last year!  Anyway, I downloaded the installer for the 64-bit version of v2.3.0 and then ran the installer...

The installation went absolutely smoothly and painlessly, without any hitches apart from me having to install the 64-bit version of OpenSSL, and v2.3.0 is behaving and performing without any issues whatsoever so as far as I'm concerned all is well.  My grateful thanks to Joe, Steve and Bill, and all the rest of the development team, fo another excellent piece of work - great stuff, guys!

73
--
Martin G0HDB

On 04/02/2021 11:25, Louis Alexander wrote:

Bill, 2 things here.  My Yaesu FTDX5000 has a CAT lite that is enabled when its com port is being used by WSJX and anytime CAT is on the lite stays on and second I am using Virtual Serial Port Emulator and I see all the com ports and there activity levels.  Looks like a good idea that you could cut the CAT control loose from WSJT but do not see any shortcut that actually does that.

Louis,

WSJT-X continues to poll the rig via CAT. As I said turning off monitor disables *active* CAT control, that means it should make no changes to rig settings in that state.

73
Bill
G4WJS.

Bill, 2 things here.  My Yaesu FTDX5000 has a CAT lite that is enabled when its com port is being used by WSJX and anytime CAT is on the lite stays on and second I am using Virtual Serial Port Emulator and I see all the com ports and there activity levels.  Looks like a good idea that you could cut the CAT control loose from WSJT but do not see any shortcut that actually does that.

On 04/02/2021 11:08, Louis Alexander wrote:

For some reason or another that does not release the CAT, it just stops the software from receiving.  The way the older software worked for me was that if the frequency you shifted to was not in the frequency list then the green band button lite would turn red but nothing else would happen in the program.  I think v 2.2.2 was the last version that ran that way.  Once the FST4, etc versions came out then that's when I started to notice the change frequency problems.

Hi Louis,

what makes you think active CAT control is not relinquished when "Monitor" is not enabled?

73
Bill
G4WJS.

For some reason or another that does not release the CAT, it just stops the software from receiving.  The way the older software worked for me was that if the frequency you shifted to was not in the frequency list then the green band button lite would turn red but nothing else would happen in the program.  I think v 2.2.2 was the last version that ran that way.  Once the FST4, etc versions came out then that's when I started to notice the change frequency problems.

What I'm not clear on.? Will I end up with "2" wsjt-x adi files or is there a single shared file.

you will end up with 2 wsjtx_log.adi and wsjtx.log files.

73's de Kari, oh2gqc