locked WSJT-X waterfall freezes & stops decoding @ raspberry pi


Vladimir
 

Hi,

I have following issue - after a first transmission the waterfall display freezes & WSJT-X stops decoding messages.
Until the first transmission everything works fine.

The misbehavior is reproducible again and again.

I'm using latest Raspbian OS (thus based on debian stretch) on raspberry pi3. This setup worked already perfectly on this very hardware/software setup until June or so.
The issue appreared, as it seems, after i upgraded from raspbian 10.4 to 10.7 in december 2020 and wanted to to some FT8.
Nor the old WSJT-X 2.1.2 version, nor the 2.2.2 works since then.

And it seems like only the armhf architecture is affected. On my regular workstation, an amd64 based setup, also with Debian 10.7 both the old WSJT-X version (2.1.2) and the current stable version 2.1.2 work like expected (tested just minutes ago).

As it seems i'm not the only one who is experience this issue -

* https://forums.qrz.com/index.php?threads/js8-and-wsjt-x-stop-decoding.727399/
* https://groups.io/g/RaspberryPi-4-HamRadio/topic/wsjtx_freezing_after_transmit/75267615?p=

Best


dpsm64@...
 

Hi --

I too was suffering from the same problem until last night, when I stumbled upon a partial answer. I'm using a Raspberry Pi 4 which I loaded with the latest HamPi image, and was consistently finding that WSJT-X would freeze up after transmitting on either WSPR or FT8 (the only modes I tried). flrig stayed active, the transceiver (IC-7200) would still behave normally, and WSJT-X was still responsive (i.e., could still scroll the band activity window and click buttons, and still controlled the rig through flrig), but the waterfall froze and there was no further decoding of incoming signals.

My "fix", if you can call it that, was to go into the audio tab of WSJT-X settings and change the input device. I had it set to "default", which appeared to work -- before transmitting I was getting plenty of decodes, so the audio was definitely getting through. I changed the input to also_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog.mono. Doing that kept the waterfall working after transmitting, at least in my environment, and the decodes keep rolling in.

Now, the reason I say this is a partial fix is because I'm not sure I have the audio output settings right. I had that set to "default" too originally, so I suspect it needs to be set to something else. There are currently 31 options listed for audio output devices, and I'm not sure which one to pick. I'm pretty sure it's neither of the two "alsa_output.platform-bcm2835_audio.*" options -- tried both of those on WSPR last night and nobody seemed to hear me. The rig is keying up, but I suspect that I'm not modulating at all. So there's still work to do, but at least I have consistent decodes.

Hope this helps someone.


dpsm64@...
 

Update on audio output settings -- on a hunch, I changed to "plughw:CARD=CODEC,DEV=0" and now I'm getting out! Just made a bunch of WSPR contacts on 20m, which unfortunately was at 20 watts by mistake, sorry about that everyone. But at least now I know I'm modulating. And, the waterfall is still going and I'm still decoding.


Georgina Joyce
 

Hello,

I am struggling with this too. I have TS-590SG. I know my cable connection provides this output:

sources:
alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.monitor/#3: Monitor of PCM2903B Audio CODEC Analog Stereo
alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo/#4: PCM2903B Audio CODEC Analog Stereo

This was from the command:

pacmd list-card.

I can amend the playback level but not the capture level. Like you it is hard to identify which setting to select on the audio tab of WSJTX. From memory, those drivers you tried were the audio stream for the HDMI ports.

I am sure you are right with using the burr brown identifier but as it has several listings it is difficult to know which are those required for RX & TX levels.

I shall watch this thread with interest because it is looking like these radios with a USB lead are probably using a very similar configuration.

Good luck

Gena
On 15 Jan 2021, at 17:13, dpsm64@... wrote:

Hi --

I too was suffering from the same problem until last night, when I stumbled upon a partial answer. I'm using a Raspberry Pi 4 which I loaded with the latest HamPi image, and was consistently finding that WSJT-X would freeze up after transmitting on either WSPR or FT8 (the only modes I tried). flrig stayed active, the transceiver (IC-7200) would still behave normally, and WSJT-X was still responsive (i.e., could still scroll the band activity window and click buttons, and still controlled the rig through flrig), but the waterfall froze and there was no further decoding of incoming signals.

My "fix", if you can call it that, was to go into the audio tab of WSJT-X settings and change the input device. I had it set to "default", which appeared to work -- before transmitting I was getting plenty of decodes, so the audio was definitely getting through. I changed the input to also_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog.mono. Doing that kept the waterfall working after transmitting, at least in my environment, and the decodes keep rolling in.

Now, the reason I say this is a partial fix is because I'm not sure I have the audio output settings right. I had that set to "default" too originally, so I suspect it needs to be set to something else. There are currently 31 options listed for audio output devices, and I'm not sure which one to pick. I'm pretty sure it's neither of the two "alsa_output.platform-bcm2835_audio.*" options -- tried both of those on WSPR last night and nobody seemed to hear me. The rig is keying up, but I suspect that I'm not modulating at all. So there's still work to do, but at least I have consistent decodes.

Hope this helps someone.

Georgina


Call: M0EBP
DMR ID: 2346259
Allstar: 52178
Locater: IO83PS


Vladimir
 

dpsm64, Georgina,

t
hanks for the hints!


That gave me the idea to re-check what actual settings i do have in WSJTX regarding audio input/output.


I found that the audio input/output was both set to "pulse", so WSJTX would pass all the output to pulseaudio and pulseaudio should handle all. Same for input.
At least that was my assumption.


Now, what i tried out is following - i've also set both to "plughw:CARD=CODEC,DEV=0". And it worked (at first glance at least).
I could transmit and the waterfall did NOT freezed up.

BUT.

I'm always checking the input/output level using "pavucontrol", which
is much better then the lxde's built-in sound utility.
(pavucontrol is a pulseaudio's own volume-control utility -
"sudo apt update; sudo apt get -y install pavucontrol")


And, after i started "pavucontrol" and tried to transmit again i got a

"Error in Sound output: An error opening the audio output device has occurred."

error.

So when using "plughw:CARD=CODEC,DEV=0" an EXCLUSIVE access to the hardware is granted to a program that is using it.
In that situation - it was "pavucontrol". And WSJTX did not managed to get access to it.
So, "plughw..." is probably ALSA's direct representation of audio-hardware offered by the kernel.


Now, what i tried one of the next audio-devices which WSJTX *also* see -

* alsa_output.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.analog-stereo/#0: Audio Adapter (Unitek Y-247A) Analog Stereo
* alsa_input.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.analog-mono/#1: Audio Adapter (Unitek Y-247A) Analog Mono

These names come from PULSEAUDIO, which sit's basically on a top ALSA (which sit's communicates with the kernel).

After i've choosen THEM for input & output, then

* i could transmit
* the waterfall did not freeze up
* both apps, WSJTX and pavucontrol, ran simultaneusly and no one had any troubles

This is, for sure, the most correct behaviour.


The "blocking" behaviour when choosing "plughw:CARD=CODEC,DEV=0" as both devices is reproduceable and is even correct, i assume.
If WSJTX is compiled with alsa-support(which i believe even is the case) it easily can grab a sound-interface directly from ALSA.


My conclusion here is - using the correct interface is the key :-) (facepalm).

However, what the "pulse" device in the list of WSJTX is, is still a big question for me. Maybe WSJTX's own "view" of pulseaudio api?


Best

Vladimir