Raspberry Pi Zero W Buster - System Crash / Screen Lock or "Freeze" when try to transmit WSPR in combination with ssh/vnc

[SyCoTechs]

////// If you using the Raspberry Pi Zero W and have the same issue, as far as i know there is no direct solution atm. Even not with an older Raspbian Build. So if you are only here to fix this problem it would probaby dont help you to read more then this first text paragraph. Long story short: Probably its the best to either use an "normal" raspberry like 1/2/3 or set up an cronjob on the ZeroW to automatically let the script for transmitting run. Let a time window open for 15 Minutes per hour or so where the script is not running so you can connect while over vnc for eventual maintenance. ///////

My Problems experienced while setting up the PiZeroW with the WsprryPi software: Im using the Raspberry Zero W with the newest 10.0 "Buster" Raspbian Build. Everything up to date. I had first some problems in compiling but modify the files like that https://github.com/gibmat/WsprryPi/commit/bd8545954b9c43e704fe8178d93e98a5fef6b881 solved that problem. After installed, transmitting and receiving of a test signal went quite well, done that multiple times on and off and no problems.

The Problems started as i tried to transmit an actual WSPR Beacon. As others i also experience the screen freeze problem. But it looks like i can come around with an additional info. As others my screen also freezes when im connected over vnc and then start the transmitting. It freezes at "Waiting for next WSPR Transmission window..." But now the clue, when im connected over HDMI to my Computer screen, everything works fine! Also the same time using vnc works wonderfull. Note: Only if the screen is on. If the screen is in standby it crashes. The screen freezes as soon as i unplug the HDMI Cable and try to use vnc. Even when a run with limited transmissions and then stop transmissions(--terminate 5) should be complete, the screen dont come to unfrozen again.

Plug in and out the HDMI Cable makes no difference at that point the screen shows frozen, also unplugging the router to maybe force vnc to stop doesnt shows an effect. Need to reboot to get it to work again. I tried it headless direct into the CLI from boot with the same experience. On the other hand, if im not connected over SSH or VNC, i can pull the Display Connector and leave it disconnected without a problem and connect it later again and use it normally further.

From my experiences what i measured with my SDR Receiver i can tell that the device keeps sending in pulses after the screen got frozen, but it doesnt uses the usual break at 1:51 anymore. Wich leads me into that the system is freezing into a loop or something. Additional the ZeroW dont accepts keyboard input anymore, it doesnt even serve it energy to light up his Capslock LED.

So it looks like it has something to do with the System or Networking. I didnt experienced that problem at any other points, only with that software. FM Transmitting works nice and also the WSPR test-tone worked flawless. When i let him connected over HDMI i can start and stop WSPR signal at any time over vnc and it works nicely.

My ZeroW is shown as Raspberry 1 btw, idk if this is wanted to be like this. bc2836 modul is unloaded over blocklist bec its not under the /modules list in this new Raspbian build.

I dont want to install an old firmware for the raspi, would be better if it could be get to running on the new Raspbian Buster. If all doenst helps i would probably do so but i hope theres a other solution somewhere.

Update: Tested different Downloads while leaving the Raspi transmitting WSPR and connected to wifi but disconnected from HDMI and VNC/SSH. After plugging it to hdmi after some minutes it still works. So the pure network traffic itself isnt the problem. Atleast not the Download. I have the strong suspicion that it might have to do with the upload. I will test that later. My thoughts are, it is something that is activated when the RaspiZeroW hands over the controls to an remote computer but via SSH at CLI the same as via VNC. Something in the WSPR Software while transmitting WSPR signal may conflict with it

Update 2: Tried running without anntenna and tried to use it before the transmitting started - when it is in "Waiting for transmission window" showed that it also frezes my pi and my vnc drops also out, which leads me to the fact that no transmitted radiowaves disturbing the Pis wifi chip here, otherwise it would work when it is not yet transmitting. Atleast that seems to be logical.

Means that there probably has to be an software issue and no hardware issue

Update 3: Tested external WiFi Usb device with disabled onboard wifi chip - no change in problematics, still crashes. Didnt tested Terminal based upload while connected over HDMI but seems like uploading data is the reason for my little Pi zero to freeze. If someone wantes to fix the issue i recommend to run this task if he wants to point out if it affects the problematic.

Update 4: Bec of its based on armv6 the same as raspberry pi 1 it has only rare alternative linux distros. If it were an Raspberry 2/3 there wouldnt be a problem since it bases on armv7 and i would be able to test ubuntu mate or something.

Tried Rasbian Jessie image from 2017 without installing any updates yet bec i dont wanted to mess the result. Unfortunately no change. Im even think its worser, it didnt even let me control over vnc now when its hdmi connected to my screen as it was able at Raspbian 10 Buster. Still crashes.

Maybe there is an easy way if the wifi chip could be somehow shielded or some point connected to grounding or something. But if its the wifi chip itself it doesnt explain why it also crashes the pi when i use an external wifi adapter. Maybe its another processing unit or has to do with a chip that is before the wifi but only while uploading but not downloading(bec downloading while was no problem at all(at Raspbian 10.0 Buster) and at a browser speed test it seemed to be and upload problem as it received 0 bytes(yes, 0 bytes, first time i seen that), anyway i didnt tested that further but i recommend to do that if someone wants to try a fix or something) Update: I tested it on the "Jessie" Build with speedtest-cli and got normal results. Around 12.70-17.28 Mbits/s Download Speed and around 1.69 Mbits/s Upload Speed. And no crashes. I tried that mutiple times with wspr trasmitting running and it worked nicely. Also started the speedtest, disconnected the hdmi and waited till it finished and reconnected, still worked nicely.

So it really looks like it is an software issue, but i dont know anymore what to test further on my PiZeroW. Maybe using Teamviewer host(if its even avaible for armv6 what im quite not sure about) could be a solution. Maybe its something with the "reading the framebuffer" as it is was vnc does. But what does SSH that is similar? It has to be something the requests information which the pi tries to give and then running into a crash. Maybe its requested process or device used by another service(of the wsprrypi software)or giving wrong values out or something other which i cant think about bec im not a programmer.

At the End the only thing i can do is making a cronjob to run the script for the raspberry pi zero w and let a 15 minute time window open at the end of every hour where i can connect over wifi vnc for maintenance if it is needed. Maybe i can mesh some code together to let it automatically report after every closed cronjob, to send a small message to my webserver to let him know, "im still alife and sending" and if the webserver didnt received it 3 hours in a row it sends me an email letting me know my WSPR Pi is probably down rn. Yes i think thats the best solution for now.

Maybe it would work on my Pi3B+, but i dont want to use it for this task as the cpu power needed is small and only uses 20% of my pi zeros.

Update 5: After some more intense websearch for the Raspberry 1(same architecture) have found another maybe fitting distribution(no not arch linux, i tried that but it was a pain to set it up and i gave up due to many failures atlast no host lookup possible as trying to update. I talk about the KaliLinux. I already used that further on a regular pc but its some time ago. While i write that, it is downloading in the Background, going to flash that and start over. Fingers crossed

Update 6: Sadly the same, going to use it with an Cronjob then. SyCoT out

[CX1GU]

Hi SiCoTechs, i'm Gonzalo. Are you tried -f option? In my Zero w freeze problems come from NTP Frequency calc. I'm work from ssh and connected to my cellphone.

So, give a try to -f option and tell us. CX1GU

[SyCoTechs]

Hi Gonzalo, yes i tried -f option with a specific frequency PPM correction with -p function which i calculated before, according to my SDR Stick receivings(SDR Stick is ppm corrected over GSM900 Tower). That was one of my first tries.

Maybe my ZeroW is broken? I dont know. But what i know is that with all other software and kinds of use the ZeroW works without problems. Also the FM transmitting with PiFM worked without any problems over VNC. I only see these problems with WsprryPi

Regards Dean

[mark-orion]

I am having the same problem with Buster. Not sure if this a pure software problem or a problem where the new OS makes the hardware behave strange (firmware ???). Usually I run wspr with the script below. It shuts down unused services (just in case...), syncs the time with ntpdate and triggers wspr in a while loop. With this script I notice that the moment wspr starts transmitting the network goes down (device not reponding to ping) and comes back up after the 2min. wspr transmission." Interesting is the "WLAN0: carrier lost" entries in the syslog. Strangely they happen after the transmission is running for about 1 minute. I tried turning off WiFi power management as this is a well known culprit for many WiFi problems, but not here. It would probably a good experiment to try with an external WiFi dongle. However I tried with and without a 50Ohm dummy load after the low pass filter but did not notice any different behaviour.

#!/bin/bash
# Run WSPR
CALL=yourcall
GRID=yourlocator
PWR=10
FRQ=20m
MAXWAIT=120
sudo systemctl stop vncserver-x11-serviced.service
sudo systemctl stop bluetooth.service
sudo systemctl stop systemd-timesyncd
sudo systemctl stop alsa-restore.service
sudo systemctl stop alsa-state.service
sudo systemctl stop triggerhappy.service
sleep 10
sudo systemctl daemon-reload
while :; do
    echo "Synchronizing Time"
    sudo ntpdate -b -p8 pool.ntp.org
    sudo wspr --terminate 1 --offset --self-calibration $CALL $GRID $PWR $FRQ
    NUMBER=$RANDOM
    let "NUMBER %= $MAXWAIT"
    echo "Waiting $NUMBER seconds..."
    sleep $NUMBER
done

[normanr]

See also https://github.com/raspberrypi/linux/issues/3671, this seems to be affecting lots of people.

[cathalferris]

To add another data point:

I've got a PiZero W version 1 running Buster, with the QRPGuys EZ-PiWspr board. I can transmit test tones perfectly fine, and I can easily pick these test single-frequency transmissions up with my SDR or HF transceiver with panadapter.

However, the Pi just hangs when trying to transmit WSPR signals.

I've fully shielded the ez-pi board with Kaptan tape and copper foil, so I doubt there's any RF getting into the PiZero outside of the GPIO pins or the power cable, both of which are possible but shouldn't affect the running. It's also possible that the Pi picks up the radiated transmission, but it doesn't hang when I transmit a few hundred watts from my ham gear..

When looking on the panadapter output on the HF transceiver, I often see a short burst of radio transmisison of about a symbol length and then silence. It's as though the Pi can't handle the first step change in frequency.

In my trials of running the WSPR script via cronjob, I did get one complete WSPR transmission and then a hang of some type. I may yet just repurpose one of my earlier Pi systems to this task, as I suspect the PiZero just isn't up to the job.

(edit after testing without the ez-pi-wspr board; PiZero still hangs, even in a screen session.)

(HB9HJF / EI4IWB callsign - all good and legal to transmit :) )

[zinkwazi]

Hi all, I posted re: the Raspberry Pi Zero 2 W crashing in https://github.com/JamesP6000/WsprryPi/issues/6 if anyone has made progress on this, please chime in.

thanks!

Greg

[BobbyB256]

I have a fix! My Pi Zero W has been running Buster with a simple change to the wspr.cpp file. Around line 700 is the wait_every() function that waits for the one second after the even minute. In there are some calls to usleep() that compiles to something that locks the whole system! There might be other solutions but I have commented out those calls and just used the existing for loop and added another to look at the system time. The full function then looks like: ` // Wait for the system clock's minute to reach one second past 'minute' void wait_every( int minute ) { time_t t; struct tm* ptm; for(;;){ time(&t); ptm = gmtime(&t); if((ptm->tm_min % minute) == 0 && ptm->tm_sec == 0) break; //usleep(1000); } //usleep(1000000); // wait another second for(;;){ time(&t); ptm = gmtime(&t); if(ptm->tm_sec == 1) break; } }

`

Once you get this working you might find another Pi Zero specific problem - frequency drift. I was getting 4 Hz or more drift over the 2 minute transmission which means I was not getting reception reports. With an IR camera I measured 4 deg F temp rise evenly over the Broadcom chip during transmission, so the crystal sees about the same because it is small and right next to it. My solution here is to put heat sinks on top the Broadcom IC and bottom of the PCB, and a small fan blowing over everything. Now I get drift of 0 or sometimes 1.

Happy WSPRing!

[edegraaff]

All, since i have my licence since a week or two (pd1eg) i wanted to try this project. After some reading and experimenting i was able to recieve the pi zero on my sdr, decode the signal and upload it to WSPRNet. It is correct the SSH sessions (wifi) is directly closed when you startup the program. I will do some experimentig. Thanks to the discussion here i have been able to transmit. Need to build the filter and so on. I start with some further testing and the first is adding a USB Nic to the zero and see if the connection stays. And the first test shows adding an USB Nic to the PI the SSH connection stays ok. That means this could be a solution as temp fix. The main question that stays is there a Wifi disturbance during transmission thas is causing the "hang" of the system. I will try to do some extra investigation. The "hang" can be solved by this work arround: add keyboard and monitor to the pi zero and the whole system stays stable.

[edegraaff]

Info: Pi Zero W , Raspbian Bullseye, SMA connector to GPIO4 and Ground Used the tip from the raspberry forum. I did not uncomment the code as sugested by Bobby Next step will be to connect the PI to the 20 meter loop. Tested command sudo ./wspr mycall mygrid 33 20m The bandpass filter is not yet builded. Another observation is when you connect the pi zero to a Dipool with a 9:1 unun the system transmit. When i unfold the wireantenna (dipole) the Pi Zero shows the "hang" When i fold the wires (wind them on a pice of wood as in first experiment) same issue, here in the shack, maybe influences due all the electronnics in the shack. I am not transmitting with the iCOM or any HF tranmist other than the PI. When i connect the pi to a monitor and keyboard in console mode over wifi it seems the transmission is solid, and the wifi also stays. I tried in another room, unrired the dipole and... seems to stay working. Strange... When there is a keyboard and monitor connected the zero stays stable also over ssh at least until now.

Quote:__Re: Need help with "undefined reference makedev" Thu Aug 29, 2019 11:03 am

The problem is a missing function called makedev, not a program. makedev() is actually a macro and you need to include the correct header for it. At the top of mailbox.c add the following line Code: Select all

include <sys/sysmacros.h>

I assume if the code used to compile under Stretch then one of the other includes used to include sysmacros but no longer does on Buster.__endQuote

[zinkwazi]

PD1EG, congrats on getting your license! I will try the USB trick and see if that works.

(I did try recompile with BobbyB256's fix after it was posted but the issue persisted for me.)

[edegraaff]

Thanks Greg, Some more insights: USB keyboard not needed, i did transmissions with ony the monitor connected to the hdmi connector. and tested the pizero. this is the result: i wil check more options later on. Tested, without monitor the system crashes. System is now offline until i have the right filters.