Date   

locked Re: Waterfall active, no decodes

Reino Talarmo
 

Ed,

Decoding saved .wav files validates only that PC is working properly. It does not tell anything about connection between rig and PC. On the other hand Signalink USB has worked for others.

One new issue came into my mind, when looking into Ten Tec manual. Could it be that you have Automatic Notch AN activated?
Also Noise Blanker NB and Noise Reduction functions may affect to decoding, but not as radical is happens to you.

73, Reino OH3mA

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of lmeeny
Sent: 1. syyskuuta 2020 1:07
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Waterfall active, no decodes

Reino,

Thank you for the reply. Here are my responses and comments on your concerns.

"I have followed with interest this discussion. I have not seen which rig you are using and how its audio is connected to your PC. Also PC operating system may
be an issue."

I'm using Windows10 PRO version 2004, build 19041.450. The link between my rig, a TenTec Eagle, and WSJT-X is a Signalink USB.

"All seems to indicate that your audio (path) has some serious difficulty. Most probably you have already checked that PC audio sampling rate is 48000 Hz with 16 bits, although also other sampling rates should work."

The Signalink USB sampling rate is 48,000 Hz at 16 bits. WSJT-X generates .wav files from the waterfall that, when using WSJT-X FILE --> LOAD, are decoded properly.

"You have also checked that your rig is really using upper sideband (USB) not lower sideband, actually then it should not decode any signals unless some station is using LSB, hi!"

Yes, the rig is set for USB

"One issue that is not easy to see is related to continuous audio sampling, sometimes waterfall may give some hint. If there are some missing time periods timewise, I mean sampled audio stream is shorter due to missing periods, then decoding is very difficult as symbols are no more in proper locations. That may happen, if PC load is so high that audio samples are missed from the audio stream for a considerable time period(s). Another cause for missing periods could be virtual audio connections in SDR radio systems (and in remote rig usage)"

I believe, perhaps mistakenly, that the ability to decode the saved .wav files validates the audio stream.

Any additional comments or suggestions will be appreciated!

73,

Ed W2GHD


locked Re: Rig Control error

Bill Somerville
 

Hi Svein,

the Hamlib developers can be contacted on the Hamlib project developers mailing list:


I am fairly certain you issue is specific to your setup as no one else is reporting a similar issue. Having said that it may be specific to real serial ports used for PTT only, that is a smaller subset of users since real serial ports are rare these days. I wonder if you have access to a USB to serial adapter you could try to see if the problem only occurs with real serial ports?

73
Bill
G4WJS.

On 01/09/2020 09:33, Svein Henriksen wrote:

Bill,

 

How do I contact the HAMLIB developers with regard to this bug?

You can eventually contact me directly at la3pu@...

 

73 de LA3PU Svein

 

 

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: torsdag 27. august 2020 17:06
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error

 

Hi Svein,

 

Hamlib does close a serial port used just for PTT when PTT is reset, the intent is to allow other applications to also key the radio so long as they do the same. The port is held open while PTT is set as an attempt to do so exclusively. The whole arrangement is supposed to emulate a "wired-OR" physical connection without each application requiring a separate serial port.

 

I'm not sure any of that helps here, except it might explain why the error happens when it does, i.e. it may be happening on a PTT set after a period with the PTT reset during which something happens that makes reopening the serial port impossible.

 

Serial ports in an idle state can become active if they receive data or if certain control lines are set (e.g. RI). I now you state that nothing is connected to the serial port, nevertheless this may be a clue. I see you are running on Windows, I'm not even sure if Windows Desktop systems respond to login attempts on serial ports, if it were Linux I would suggest making sure the serial port login handler was disabled for that serial port.

 

73
Bill
G4WJS.

 

On 27/08/2020 15:48, Svein Henriksen wrote:

Bill,

 

Only the RTS pin and pin 5(GND) are connected. Nothing else is connected to the computer at all besides audio in and out. I made the cable myself and yes it is screened. It goes to a control box where it drives an OPTOCOUPLER. So it is galvanically isolated from the radio. Since I did not have the problem on the previous computer at all, it is likely some timing difference between the two with respect to the comport responding then. Such differences must surely be taken into account in software.

So could be that HAMLIB is too quick to report if it does not detect the comport immediately.

 

73 de LA3PU Svein

 

 

 

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: torsdag 27. august 2020 13:06
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error

 

Hi Svein,

 

WSJT-X, using Hamlib, opens the COM port being used for PTT control via RTS or DTR even though the port is not used for RS-232 CAT control. It the o/s reports the port as not available. or other related errors, then Hamlib and consequently WSJT-X reports that error. Is anything else connected to that serial port? Have you check the physical connections used for PTT control?

 

73
Bill
G4WJS.

 

On 27/08/2020 11:10, Svein Henriksen wrote:

Bill,

 

It definitely looks like it helps to set the polling frequency higher. I have set it to 30 seconds. The problem then comes much more seldom.

When it does it is often immediately after I double click on a station to answer a CQ call and seconds before the RTS line and hence the transmitter is even activated. So it definitely has nothing to do with RFI.

Now any computer has a few mV of noise on the comport lines. In my case only the RTS line is even connected.

So if it is noise that occasionally  triggers it this means that HAMLIB and / or WSJ-X (due to the way it has been integrated) is polling the com line for a radio that is not configured and not connected.

So this is definitely a bug. When Radio: None has been configured there should be no polling

Can you mention this to the HAMLIB people perhaps, or should I? How do I eventually contact them?

I will now try and install a couple of 100 nF capacitors from pins 2 and 3 to pin 5. I see on the oscilloscope that this attenuates the noise present. Its only a few mV and this is way below the threshold on an RS232 line so it could be pulses occurring now and then due to some WIN thingy and 100 nF may not be enough so I am dubious that this will help. But I think it should not be this way anyway.

 

73 de LA3PU Svein.

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: tirsdag 25. august 2020 19:52
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error

 

On 25/08/2020 18:46, Svein Henriksen wrote:

Bill,

 

This morning everything started up without problems and has worked for some QSOs without failing.

But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.

Rig Error: Do you want to configure the radio interface?

On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.

Pressing retry and it goes back to working normally.

There is only one COM port (COM1) ant it is used for PTT with RTS.

No rig connected and in setup rig is set to none.

Nothing connected to any of the USB ports.

The WSJT-X is V2.2.2.

On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.

I never had this, or any other, problem while using this.

Maybe I need to roll back to 2.2.0.

I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.

Is the old versions available on Princeton and any special precautions if rolling back?

 

Any other suggestions?

 

73 de LA3PU Svein

Hi Svein,

that sounds like RFI problems, does it only happen during QSOs on one band? Does reducing your transmitter power improve the situation?

As you say nothing is connected to your PC USB ports I assume this is a real serial port, you could try some ferrite clip on chokes at the PC end of the serial cable, or maybe just re-routing the serial cable to the rig. What interface are you using for the RTS to PTT switching, and where does it draw power from?

73
Bill
G4WJS.



locked Re: Subprocess error

Bill Somerville
 

Hi David,

I don't understand your question, the link is to the installers for v2.1.2, that is the version I am recommending.

73
Bill
G4WJS.

On 01/09/2020 08:28, DAVID GRIFFITHS wrote:

Many thanks Bill. I have looked at the link you sent me. Which version should I use?. There are several listed.
Kind regards
David Griffiths


From: main@WSJTX.groups.io <main@WSJTX.groups.io> on behalf of Bill Somerville <g4wjs@...>
Sent: 31 August 2020 20:18
To: main@WSJTX.groups.io <main@WSJTX.groups.io>
Subject: Re: [WSJTX] Subprocess error #WSPR
 
On 31/08/2020 16:38, DAVID GRIFFITHS wrote:
> I have finally got my transceiver and computer talking to one another
> and WSJTX seemed to be working alright. However, I got a number of errors.
> " Running C:\WSJT\wsjtx\bin\user hardware 10 ( also 15,20 and
> 40).Process failed to start:The system cannot find the file specified."
> What does this mean and how do I correct it?
> Kind regards
> David Griffiths G4PKV

Hi David,

there is a known defect in WSJT-X v2.2.2 with WSPR band hopping mode. If
you need band hopping mode then I recommend you use WSJT-X v2.1.2.

https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.2/

73
Bill
G4WJS.



locked Re: Rig Control error

Svein Henriksen
 

Bill,

 

How do I contact the HAMLIB developers with regard to this bug?

You can eventually contact me directly at la3pu@...

 

73 de LA3PU Svein

 

 

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: torsdag 27. august 2020 17:06
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error

 

Hi Svein,

 

Hamlib does close a serial port used just for PTT when PTT is reset, the intent is to allow other applications to also key the radio so long as they do the same. The port is held open while PTT is set as an attempt to do so exclusively. The whole arrangement is supposed to emulate a "wired-OR" physical connection without each application requiring a separate serial port.

 

I'm not sure any of that helps here, except it might explain why the error happens when it does, i.e. it may be happening on a PTT set after a period with the PTT reset during which something happens that makes reopening the serial port impossible.

 

Serial ports in an idle state can become active if they receive data or if certain control lines are set (e.g. RI). I now you state that nothing is connected to the serial port, nevertheless this may be a clue. I see you are running on Windows, I'm not even sure if Windows Desktop systems respond to login attempts on serial ports, if it were Linux I would suggest making sure the serial port login handler was disabled for that serial port.

 

73
Bill
G4WJS.

 

On 27/08/2020 15:48, Svein Henriksen wrote:

Bill,

 

Only the RTS pin and pin 5(GND) are connected. Nothing else is connected to the computer at all besides audio in and out. I made the cable myself and yes it is screened. It goes to a control box where it drives an OPTOCOUPLER. So it is galvanically isolated from the radio. Since I did not have the problem on the previous computer at all, it is likely some timing difference between the two with respect to the comport responding then. Such differences must surely be taken into account in software.

So could be that HAMLIB is too quick to report if it does not detect the comport immediately.

 

73 de LA3PU Svein

 

 

 

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: torsdag 27. august 2020 13:06
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error

 

Hi Svein,

 

WSJT-X, using Hamlib, opens the COM port being used for PTT control via RTS or DTR even though the port is not used for RS-232 CAT control. It the o/s reports the port as not available. or other related errors, then Hamlib and consequently WSJT-X reports that error. Is anything else connected to that serial port? Have you check the physical connections used for PTT control?

 

73
Bill
G4WJS.

 

On 27/08/2020 11:10, Svein Henriksen wrote:

Bill,

 

It definitely looks like it helps to set the polling frequency higher. I have set it to 30 seconds. The problem then comes much more seldom.

When it does it is often immediately after I double click on a station to answer a CQ call and seconds before the RTS line and hence the transmitter is even activated. So it definitely has nothing to do with RFI.

Now any computer has a few mV of noise on the comport lines. In my case only the RTS line is even connected.

So if it is noise that occasionally  triggers it this means that HAMLIB and / or WSJ-X (due to the way it has been integrated) is polling the com line for a radio that is not configured and not connected.

So this is definitely a bug. When Radio: None has been configured there should be no polling

Can you mention this to the HAMLIB people perhaps, or should I? How do I eventually contact them?

I will now try and install a couple of 100 nF capacitors from pins 2 and 3 to pin 5. I see on the oscilloscope that this attenuates the noise present. Its only a few mV and this is way below the threshold on an RS232 line so it could be pulses occurring now and then due to some WIN thingy and 100 nF may not be enough so I am dubious that this will help. But I think it should not be this way anyway.

 

73 de LA3PU Svein.

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: tirsdag 25. august 2020 19:52
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error

 

On 25/08/2020 18:46, Svein Henriksen wrote:

Bill,

 

This morning everything started up without problems and has worked for some QSOs without failing.

But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.

Rig Error: Do you want to configure the radio interface?

On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.

Pressing retry and it goes back to working normally.

There is only one COM port (COM1) ant it is used for PTT with RTS.

No rig connected and in setup rig is set to none.

Nothing connected to any of the USB ports.

The WSJT-X is V2.2.2.

On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.

I never had this, or any other, problem while using this.

Maybe I need to roll back to 2.2.0.

I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.

Is the old versions available on Princeton and any special precautions if rolling back?

 

Any other suggestions?

 

73 de LA3PU Svein

Hi Svein,

that sounds like RFI problems, does it only happen during QSOs on one band? Does reducing your transmitter power improve the situation?

As you say nothing is connected to your PC USB ports I assume this is a real serial port, you could try some ferrite clip on chokes at the PC end of the serial cable, or maybe just re-routing the serial cable to the rig. What interface are you using for the RTS to PTT switching, and where does it draw power from?

73
Bill
G4WJS.

 


locked Re: Subprocess error

DAVID GRIFFITHS
 

Many thanks Bill. I have looked at the link you sent me. Which version should I use?. There are several listed.
Kind regards
David Griffiths


From: main@WSJTX.groups.io <main@WSJTX.groups.io> on behalf of Bill Somerville <g4wjs@...>
Sent: 31 August 2020 20:18
To: main@WSJTX.groups.io <main@WSJTX.groups.io>
Subject: Re: [WSJTX] Subprocess error #WSPR
 
On 31/08/2020 16:38, DAVID GRIFFITHS wrote:
> I have finally got my transceiver and computer talking to one another
> and WSJTX seemed to be working alright. However, I got a number of errors.
> " Running C:\WSJT\wsjtx\bin\user hardware 10 ( also 15,20 and
> 40).Process failed to start:The system cannot find the file specified."
> What does this mean and how do I correct it?
> Kind regards
> David Griffiths G4PKV

Hi David,

there is a known defect in WSJT-X v2.2.2 with WSPR band hopping mode. If
you need band hopping mode then I recommend you use WSJT-X v2.1.2.

https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.2/

73
Bill
G4WJS.


locked Re: World-wide Digi DX Contest Problem

Jim Shorney
 

I also noticed the decode button staying on during the contest. Investigating, I found that one CPU core was hitting 100% for periods roughly coinciding with the decode button behavior.

I'm using WSJT-X in Kubuntu 18 Linux, compiled from source. I have WSJT-X connected via LAN to DXLabs SpotCollector on a very busy Windows box for the extra highlighting of calls. After I tried a couple of other things I found that clearing the band activity pane with right-CLICK-Erase helped. Periodically erasing the band activity or erasing when the monitor button started to act up seemed to settle things down.

I can't say if I was missing any decodes or not, I was usually getting plenty so how would I know? :)

73

-Jim
NU0C

On Mon, 31 Aug 2020 16:27:19 -0700
"Tony Collett via groups.io" <tony.nbs@...> wrote:

Possibly!

More basic system here v2.2.2 W10 Pro 64bit v2004 on a 3GHz Intel Core2 Duo CPU and just WSJT running alongside N1MM with a K3 over the weekend.
Out of contests I run JTALert and DXLab suite (Commander/Log and Spot) so much more going on on the PC.

I've never noticed the decode light stay on before but it was doing it over the weekend during the Digi DX Contest. Didn't appear to lose me any decodes, other than them appearing after the next period had started from time to time.

I did have WSJT crash out on me twice though which it has never done before. Both times I had just logged a QSO and clicked on a decode of a wanted station - not his CQ but one containing reports. Think one of the decodes included a hashed call but not sure of the other occasion.

73
Tony G4NBS


locked Re: World-wide Digi DX Contest Problem

Tony Collett
 

Possibly!

More basic system here v2.2.2 W10 Pro 64bit v2004 on a 3GHz Intel Core2 Duo CPU and just WSJT running alongside N1MM with a K3 over the weekend.
Out of contests I run JTALert and DXLab suite (Commander/Log and Spot) so much more going on on the PC.

I've never noticed the decode light stay on before but it was doing it over the weekend during the Digi DX Contest. Didn't appear to lose me any decodes, other than them appearing after the next period had started from time to time. 

I did have WSJT crash out on me twice though which it has never done before. Both times I had just logged a QSO and clicked on a decode of a wanted station - not his CQ but one containing reports. Think one of the decodes included a hashed call but not sure of the other occasion.

73
Tony G4NBS


locked Re: Constructive criticism

d_ziolkowski
 

John-

perhaps you could compile and maintain said information?

Dan KC2STA

On Mon, Aug 31, 2020 at 5:29 PM JP Tucson, AZ <samcat88az@...> wrote:
Nope! Sorry...

That says what it fixed; not what it broke!

Like: 
A) the .adi header, or
B) the Yaesu 897, 817, etc., or
C) the decodes issues, or
D) the problems with band hopping ...

Etc.!



73 - John - N7GHZ

On Mon, Aug 31, 2020, 1:35 PM Lloyd Korb <lloydk8dio@...> wrote:

On Mon, Aug 31, 2020 at 3:56 PM JP Tucson, AZ <samcat88az@...> wrote:
Hi guys.

As I think we all have seen; there have been countless help posts concerning several bugs in v2.2.2. - With generally the same replies/answers.

So, out of curiosity, I just rechecked on the Official Princeton WSJT-X website & nowhere is there a section on that page that lists Known Bugs & fixes or work-arounds.  There really should be one; it would save you guys a lot of repetitious answers on groups.io  .









--
Dan Ziolkowski KC2STA
SKCC #4290T
Ubuntu LINUX


locked Re: Waterfall active, no decodes

lmeeny
 

Reino,

Thank you for the reply. Here are my responses and comments on your concerns.

"I have followed with interest this discussion. I have not seen which rig you are using and how its audio is connected to your PC. Also PC operating system may
be an issue."

I'm using Windows10 PRO version 2004, build 19041.450. The link between my rig, a TenTec Eagle, and WSJT-X is a Signalink USB.

"All seems to indicate that your audio (path) has some serious difficulty. Most probably you have already checked that PC audio sampling rate is 48000 Hz with 16 bits, although also other sampling rates should work."

The Signalink USB sampling rate is 48,000 Hz at 16 bits. WSJT-X generates .wav files from the waterfall that, when using WSJT-X FILE --> LOAD, are decoded properly.

"You have also checked that your rig is really using upper sideband (USB) not lower sideband, actually then it should not decode any signals unless some station is using LSB, hi!"

Yes, the rig is set for USB

"One issue that is not easy to see is related to continuous audio sampling, sometimes waterfall may give some hint. If there are some missing time periods timewise, I mean sampled audio stream is shorter due to missing periods, then decoding is very difficult as symbols are no more in proper locations. That may happen, if PC load is so high that audio samples are missed from the audio stream for a considerable time period(s). Another cause for missing periods could be virtual audio connections in SDR radio systems (and in remote rig usage)"

I believe, perhaps mistakenly, that the ability to decode the saved .wav files validates the audio stream.

Any additional comments or suggestions will be appreciated!

73,

Ed W2GHD


locked Re: CONTEST LOG TO ADI FILE

Martin G0HDB
 

On Mon, Aug 31, 2020 at 07:41 PM, Rod Linkous wrote:
Seems like I remember seeing a technique to transferring a contest to ADI file.  Is it possible?

Thanks and 73

Rod W7OM
Hi Rod, all your contest QSOs should already be in the wsjtx_log.adi file.

If you renamed your original wsjtx_log.adi file to something else, eg. wsjtx_log.full, before the start of a contest then when you first fired-up WSJT-X in readiness for the contest the app would have created a brand-new blank wsjtx_log.adi file and all your contest QSOs would have been written to the new wsjtx_log.adi file. 

After a contest is finished all you need to do is copy all the QSOs from the contest's wsjtx_log.adi file into the wsjtx_log.full file then delete or rename the contest's wsjtx_log.adi file and finally rename the wsjtx_log.full file back to wsjtx_log.adi.

Of course, if you didn't do anything to your original wsjtx_log.adi file before the contest then all your contest QSOs will just have been appended to the existing wsjtx_log.adi file.

HTH,
--
Martin G0HDB


locked Re: Constructive criticism - part 2...

JP Tucson, AZ
 

Let me add this:

Perhaps you should also please ask to stop the OVER-moderation of this groups.io page!

Maybe, just maybe if the helpful hints & answers posted here actually remained here... people could actually make this a useful tool & find some good resources.

I have seen 100% valid & helpful posts disappear within 3 minutes. 


73 - John - N7GHZ


On Mon, Aug 31, 2020, 12:56 PM JP Tucson, AZ via groups.io <samcat88az=gmail.com@groups.io> wrote:
Hi guys.

As I think we all have seen; there have been countless help posts concerning several bugs in v2.2.2. - With generally the same replies/answers.

So, out of curiosity, I just rechecked on the Official Princeton WSJT-X website & nowhere is there a section on that page that lists Known Bugs & fixes or work-arounds.  There really should be one; it would save you guys a lot of repetitious answers on groups.io  .






locked Re: Waterfall active, no decodes

lmeeny
 

Bill,

I am and have been using BktTimeSync. I also checked the time displayed on the main WSJT-X window against time.is and they matched.

Ed



locked Re: Constructive criticism

JP Tucson, AZ
 

Nope! Sorry...

That says what it fixed; not what it broke!

Like: 
A) the .adi header, or
B) the Yaesu 897, 817, etc., or
C) the decodes issues, or
D) the problems with band hopping ...

Etc.!



73 - John - N7GHZ


On Mon, Aug 31, 2020, 1:35 PM Lloyd Korb <lloydk8dio@...> wrote:

On Mon, Aug 31, 2020 at 3:56 PM JP Tucson, AZ <samcat88az@...> wrote:
Hi guys.

As I think we all have seen; there have been countless help posts concerning several bugs in v2.2.2. - With generally the same replies/answers.

So, out of curiosity, I just rechecked on the Official Princeton WSJT-X website & nowhere is there a section on that page that lists Known Bugs & fixes or work-arounds.  There really should be one; it would save you guys a lot of repetitious answers on groups.io  .







locked Re: Suspect RFI into computer

Kyle K7UU
 

Tell us why, please.

Kyle
K7KE


locked Re: Constructive criticism

Lloyd Korb
 

On Mon, Aug 31, 2020 at 3:56 PM JP Tucson, AZ <samcat88az@...> wrote:
Hi guys.

As I think we all have seen; there have been countless help posts concerning several bugs in v2.2.2. - With generally the same replies/answers.

So, out of curiosity, I just rechecked on the Official Princeton WSJT-X website & nowhere is there a section on that page that lists Known Bugs & fixes or work-arounds.  There really should be one; it would save you guys a lot of repetitious answers on groups.io  .






locked Re: Suspect RFI into computer

Joe Burnham <wd4kav@...>
 

Not sure what you mean by “rf filters”, but I had a similar problem here with my 7300 and PC, connected by a single USB cable.

I bought some clamp on toroids and put one at the end of the cable before it connects to the port on the computer. I also looped the power cable to the pc through a larger toroid up close to where the power cord plugs into the PC.

This fix solved my problems, and I can run 50-60 watts output to my vertical which is about 25 feet away. OH, make sure your rig and tuner are grounded too.

73, Joe

On Aug 31, 2020, at 9:31 AM, wojtasczyk@... wrote:

I


locked Re: Subprocess error

rturpen@...
 

I ran into this problem on mac, got around it by adding an empty bash script into the .app package.

in wsjtx.app , show contents, create new file in Contents/MacOS named user_hardware, chmod +x so it can execute. contents of new file on next line

#!/usr/bin/env bash

wsjtx will then execute it and get back a good return value, allowing the app to continue. for windows it would be a bat file doing nothing, on linux same as mac os, file locations differ on those platforms, haven’t had a chance to try it on those yet.

73
N0SSL

On Aug 31, 2020, at 12:18 PM, Bill Somerville <g4wjs@...> wrote:

On 31/08/2020 16:38, DAVID GRIFFITHS wrote:
I have finally got my transceiver and computer talking to one another and WSJTX seemed to be working alright. However, I got a number of errors.
" Running C:\WSJT\wsjtx\bin\user hardware 10 ( also 15,20 and 40).Process failed to start:The system cannot find the file specified."
What does this mean and how do I correct it?
Kind regards
David Griffiths G4PKV
Hi David,

there is a known defect in WSJT-X v2.2.2 with WSPR band hopping mode. If you need band hopping mode then I recommend you use WSJT-X v2.1.2.

https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.2/

73
Bill
G4WJS.


locked Constructive criticism

JP Tucson, AZ
 

Hi guys.

As I think we all have seen; there have been countless help posts concerning several bugs in v2.2.2. - With generally the same replies/answers.

So, out of curiosity, I just rechecked on the Official Princeton WSJT-X website & nowhere is there a section on that page that lists Known Bugs & fixes or work-arounds.  There really should be one; it would save you guys a lot of repetitious answers on groups.io  .





locked World-wide Digi DX Contest Problem

John, K9MM
 

I'm running WSJT-X v2.2.2 on a Windows 10 Pro v1909 system with a FlexRadio 6600M using the slice-master interface to Smart SDR v2.62..

Soon after I enabled the "Special Operating Activity" mode for this contest on Saturday, I encountered a problem where the Decode indicator would remain illuminated at the end of the decode cycle and there would be no more decodes. I believe this is the same problem reported during Field Day. Clearing the decode window and hitting ALT-Z would correct the problem, but only momentarily.

I switched back to normal operating mode, but the problem persisted. I shut down and re-started WSJT-X, but the problem persisted. I shut down WSJT-X, slice-master, and the SDR software, but the problem persisted. Finally, I re-booted the computer, and that fixed the problem as long as I didn't enable Special Operating Activity again.

I didn't see anyone else reporting this problem during the contest. Am I the only one who was seeing it? During Field Day many were reporting it. Is there a work-around? Thanks!

73,

John, K9MM


locked Re: Suspect RFI into computer

Jim Brown
 

On 8/31/2020 12:16 PM, Joe KN5Y via groups.io wrote:
Read Palomar Engineering online RFI issues. Consider wrapping cables around ferrite toroids as well as using snap-on chokes
I do NOT recommend this company or their materials.

73, Jim K9YC