Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Crashes when "Waiting for next WSPR transmissoin window". #6

Open
orsty3001 opened this issue Apr 7, 2017 · 55 comments
Open

Crashes when "Waiting for next WSPR transmissoin window". #6

orsty3001 opened this issue Apr 7, 2017 · 55 comments

Comments

@orsty3001
Copy link

Crashes when I try to start wspr on a raspberry pi 1. The only way to recover is unplugg the device and plug it back in.
@itdaniher
Copy link

could you take a picture of your test setup? this very well could be a power / grounding issue.

@orsty3001
Copy link
Author

Since I posted I tried both the zero and the pi 1. I have also tried with just using the ground pin 9 and all of the grounds tied together. The pi zero gets a little bit further but hangs after about a minute of waiting to transmit instead of instantly like the pi 1 does.

https://i.imgur.com/23MumQz.jpg

@itdaniher
Copy link

Oh, if it crashes instantly then it's not likely to be a grounding issue - I'd only expect that to occur on transmission, not launch.

How are you powering the pis in question? Have you tried different variants of PSU / cable?

@orsty3001
Copy link
Author

I have dozens of USB ac adapters. Most are 1 amp and above. I tried them all and the USB ports on my computer. Just now I tried a jumpbox and a USB 12v car adapter and it still hangs in the same place.

@orsty3001
Copy link
Author

Is there a way to debug the software? I can't do anything to see where exactly it hangs because of the hard lockup that occurs.

@itdaniher itdaniher mentioned this issue Apr 9, 2017
Closed
@JamesP6000
Copy link
Owner

Hi Guys,

I'm suspecting that something recently changed in Jessie...

Can you see if running PiFmRds produces the same problem?
https://github.com/ChristopheJacquet/PiFmRds

Both codebases are using mailbox.c to configure the memory maps and the ioctl messages you're seeing are coming from mailbox.c.

JP

@orsty3001
Copy link
Author

I'll try to run that program when I get off work but just to let you know WsprryPi worked when I downloaded a version of Jessie that is from December of 2016. So it's got to be something that's changed in the latest.

@JamesP6000
Copy link
Owner

I just upgraded to the latest Jessie (apt-get update/ apt-get dist-upgrade), rebooted, and it seems to be working fine on an old Raspberry Pi 1. No lockup. Perhaps they fixed the problem? Nothing was connected to any GPIO pins.

Could you send the actual command line you're using the launch the program?

James

@orsty3001
Copy link
Author

orsty3001 commented Apr 10, 2017 •
edited
Loading

sudo wspr -r -o -s My Callsign EM94ax 10 20m 0

@JamesP6000
Copy link
Owner

JamesP6000 commented Apr 10, 2017 via email

@orsty3001
Copy link
Author

I substituted "My Callsign" there so I wouldn't have to post my real callsign.

@orsty3001
Copy link
Author

orsty3001 commented Apr 10, 2017 •
edited
Loading

`Power: tx_pwr_dBm 10
Requested TX frequencies:
0.000010 MHz
14.097100 MHz
0.000000 MHz
Extra options:
NTP will be used to peridocially calibrate the transmission frequency
Transmissions will continue forever until stopped with CTRL-C
A small random frequency offset will be added to all transmisisons

ioctl_set_msg failed:-1
ioctl_set_msg failed:-1
Ready to transmit (setup complete)...
Desired center frequency for WSPR transmission: 0.000035 MHz
Waiting for next WSPR transmission window..`

Then it locks up. Also there is a typo in the program there. The words periodically and transmissions is spelled wrong.

Also was able to test PiFmRds and it works fine.

@JamesP6000
Copy link
Owner

It's interesting. In the email I received from github, there was no mention of "my callsign" but it's clearly shown on the webpage version.

Thanks for the spelling corrections :) Unfortunately the compiler does not flag spelling errors :)

From the program output you copied, it seems that your wspr is trying to transmit on the frequency 10 Hz (the first line after "Requested TX frequencies". Is that what you intend? I have never tried it at that low of a frequency.

If I use your command line and substitute my callsign, I get the following without crashing and without a transmission at 10Hz:

`pi@RPi1:~/WsprryPi $ sudo ./wspr -r -o -s AB0JP EM94ax 10 20m 0
Detected Raspberry Pi version 1
WSPR packet contents:
Callsign: AB0JP
Locator: EM94AX
Power: 10 dBm
Requested TX frequencies:
14.097100 MHz
0.000000 MHz
Extra options:
NTP will be used to periodically calibrate the transmission frequency
Transmissions will continue forever until stopped with CTRL-C
A small random frequency offset will be added to all transmissions

Ready to transmit (setup complete)...
Desired center frequency for WSPR transmission: 14.097098 MHz
Waiting for next WSPR transmission window...
Obtained new ppm value: -43.1177
TX started at: UTC 2017-04-10 22:10:01.004
TX ended at: UTC 2017-04-10 22:11:51.597 (110.592 s)
Desired center frequency for WSPR transmission: 0.000000 MHz
Waiting for next WSPR transmission window...
Skipping transmission
Desired center frequency for WSPR transmission: 14.097090 MHz
Waiting for next WSPR transmission window...
`

@orsty3001
Copy link
Author

I just noticed it did the same thing in my email. Very strange.

I'm at a lost. I'm not sure how to diagnose this issue since it just hangs up and can't do anything until the power is unplugged and plugged back in. I'll just run it on the older version of the OS for now to have a play with wspr.

Thanks.

@andrewbnortham
Copy link

I am having the same problem as well. Locks up when it begins transmitting and the only solution is to power cycle. Raspberry pi 3, latest build update with the TAPR shield. It was a fresh install and I documented the entire thing:
https://andrewbnortham.com/ke8fzt/20m-wspr-beacon-receiver-raspberry-pi3/

I am going to wipe it and do a fresh build and see if it still locks up.

@andrewbnortham
Copy link

Full wipe and reinstall with only WsprryPi on a Rpi3, and it crashes pretty regularly, it says 'Waiting for next WSPR transmission window..' and crashes before it starts transmitting... Only in GUI mode.

I setup the Pi to boot directly to the CLI and couldnt get it to crash, only crashed when in the GUI...

@JamesP6000
Copy link
Owner

Ah, That explains a lot. I'm running headless and hence I never had any problems. The GUI is also trying to use the PWM controller and is conflicting with WsppryPi:

******
PWM Peripheral:
******
  The code uses the RPi PWM peripheral to time the frequency transitions
  of the output clock. This peripheral is also used by the RPi sound system
  and hence any sound events that occur during a WSPR transmission will
  interfere with WSPR transmissions. Sound can be permanently disabled
  by editing /etc/modules and commenting out the snd-bcm2835 device.

JP

@orsty3001
Copy link
Author

Mine is also headless. I have it set to boot strait to the command line. It doesn't have snd-bcm2835 listed at all in /etc/modules. It still hangs up with the latest version of Jessie.

@MontyOH
Copy link

MontyOH commented Apr 18, 2017

Gotta say - same thing: RasPi Zero W with fresh Jessie Lite - headless with no snd modules loaded and hangs. Actually have to pull the power to get it to come back. Would work "sometimes" (about 1 out of 4 tries), so just enough to be frustrating and non-deterministic.......

However, no problems on the RasPi3s with Mate. Also tried Mate headless on the Zero - works but huge amount of resources for bloat.

Seems to point to a Jessie problem, will l try Jessie on the Raspi3, but seems to be clear....

Hope it helped on the troubleshooting side, now, why conflict for the PWM?? If that is the cause

@MontyOH
Copy link

MontyOH commented Apr 21, 2017

Quick update - works on some power supplies more regularly than others.... Mate 100% reliable, but with zero on battery will work on a couple, fail on most. Noise on the input or ground when starting transmit?? Don't know. Raspi3 100% as well no matter what distro. So...... Suggestions???

@JamesP6000
Copy link
Owner

Hi all,

I just can't reproduce this... I just tried on and RPI1 and an RPI3 and both are happy with no lockups... I'm running Jessie-Lite that I installed about 2 months ago but which I have just updated, performed dist-upgrade, and then rebooted.

I'll put a link from the README to here but I don't know what else to try...

JP

@orsty3001
Copy link
Author

I can get it to do it religously on a rpi1 and zero by downloading the latest version of jessie with mate or the lite version. Updating that by only doing apt-get upgrade. The pi zero is connected using a USB hub and a usb wifi adapter. This is not a pi zero w. Just the pi version 1.3 with the camera connector. It will hang up every single time if I do that.

The only other thing you could try on top of that is set the locale to en.us and the keyboard layout to US. I have not tested it by leaving it to en.GB.

I know it's not a hardware issue and my power adapter is good because it works with an older version of jessie. It only locks up with the latest stable release of jessie downloaded from raspbian's website.

@MontyOH
Copy link

MontyOH commented Apr 21, 2017

Decided to spend some time on this: Using RPi3, RPizero and RPizero W (all I have)

Starting with the Zeros: (results were same with both versions)

Any "new" version of Jessie kills the process, but seems to be a race condition. By that I mean that I can do: sudo wspr -t 7.1e6 and it will put out a nice tone right where it is supposed to. Have yet to kill it on "test" mode and even made a small script to start and stop the command for over an hour - no problems.

However, as soon as you want to do a "real" wspr: sudo wspr -o MyCall EM79 10 80m 40m 30m etc, it will lock up BEFORE starting the GPIO pin (ie transmitting). I have tried on several Jessie and Jessie lite versions now - same behavior.

On the other hand, if I use the 16.04.02 version of Mate (full version) - it all works fine. It is just that even booted headless it takes 100M of the memory space, let alone booting into the XWin side at ~350M. Ouch!

RPi3s seem to have no issues with either distro with my tests. That was easy :)

So there IS a hardware dependence, but where in the OS of the new Jessie is it making it not work??

And the real issue is does it propagate (using DMA for the pins is something that I do for smooth non-flicker dimming of LEDs as well as for radio work - not explored yet)

My other post regarding the power supply was due to swapping different batteries vs wall power input in an effort to see if some sort of ripple or voltage variation on the input was giving the hickups. It seemed initially that the battery power would give me "better results" ie would work "more" than the other way. Normally don't use the wall power for radio side as the 60Hz hash likes to get into the tones and produce sidebands - noted in the readme - but had to try.

So there you are - long post. Am willing to take any other direction that I can to help fix this as do not really want to go back in OS if do not have to and if problem in Jessie, can run it down to get it into the next cycle.

@th0ma5w
Copy link

th0ma5w commented May 1, 2017

Not sure if related but I've had for at least a month the following message or similar after some time of working fine:
Desired center frequency for WSPR transmission: 10.140127 MHz
Waiting for next WSPR transmission window...
TX started at: UTC 2017-05-01 04:18:01.002
Exiting with error; caught signal: 28

... So I have to run the thing in a while loop on the shell. This is a Raspberry Pi 1 that I've periodically updated with apt for the last few years.

@K0PIR
Copy link

K0PIR commented May 23, 2017

I have seen where this is a problem when using the Pi headless. Has there been a solution? That's the only way I use mine.

Thanks!

@andrewerrington
Copy link

I am having the same issue. I downloaded latest Jessie Lite and booted my Pi 1 with TAPR shield. Downloaded WsprryPi from here and compiled and ran it. It crashes at "Waiting for next WSPR transmission window...". I downgraded to Jessie Lite from May last year, and it still crashes. This time it's at "Ready to transmit (setup complete)...". It sometimes works, but when it crashes it hangs the Pi. Another way to hang the Pi is by running WsprryPi in tty1 (Alt-F1) then opening tty2 (Alt-F2), logging in and typing 'ps ax' to get a list of processes. I get a partial list of processes then the Pi hangs.

@andrewerrington
Copy link

andrewerrington commented May 24, 2017 •
edited
Loading

Same problem with Jessie-lite from 2015-11-21. Now trying wheezy from 2015-02-16.

Update: Can't compile. Need later gcc than is present in wheezy.

@K0PIR
Copy link

K0PIR commented May 25, 2017 •
edited
Loading

I have got mine working with the Raspberry Pi QRP TX Shield for WSPR. I am using a RPi3. It is not consistent, but it was working for me today. I am not positive about this, but think if the TAPR TX Shield is pushed too far down on the GPIO pins, it causes problems. I also found that my 2.5A power supply was causing a dirty transmission. I am using a battery now and it is rated at 2.0A.
Like I said, it was working and I don't know if it'll work tomorrow. I'll followup.

@mustafatan75
Copy link

I am having the same issue with Zero in headless mode too. No problem with only HDMI or only USB or both plugged in.

@pwassink
Copy link

pwassink commented May 26, 2017 •
edited
Loading

On the don't update your PI when running wspr statement, I was not to happy on that ..

Seen that complete freeze after updates happen on a Pi3 here, checked some solutions, what does work is make sure you have all stuff working on a basic jessie rasbian image as instructed.
You even might start wspr for a while without updating just to test it . Ok that works , Great now on to the next..

Now you have to make sure your pi is also safe by running all (a whole lot of! ) required updates:
start with an $ sudo apt-get install rpi-update
(this will load the online kernel-updater which will be needed after you finished all normal updates)
Then make sure your pi complete OS gets updated to the latest levels by entering:

$ sudo apt-get update

and when that command is finished:

$ sudo apt-get upgrade

will also take a while to complete, then wait to reboot and verify your current running Kernel
by entering this command $ sudo uname -a

Anything below 4.9.29-v7+ #1000 SMP might be considered as OLD ..

Now you can use the extra command installed at the beginning of this update so enter:
$ sudo rpi-update

That will download the latest Kernels, and install them in the right place, DO reboot after this and DONT try to start your old wspr again!

After the reboot on a freshly booted Raspberry pi 3 try a $ sudo uname -a
You should see a fresh kernel from at least 4.9.something now, which will tell you all the work done sofar was successfully completed.

Then the last hurdle, throw away your whole wspr dir by issuing the $ sudo rm -r /ful/path/to/your/WsprryPI
(Be VERY carfull entering this command, it is not windows and will not ask if you were sure, very sure, absolutely sure .. :-) )

After that download the wsprfile-sorces again from GIT and do a brandnew & fresh compile, in my case it worked fine afterwards, , tested on a ancient Pi model B, Pi3 and Pi0 W now..

Your milage may vary .. Good luck.

Peter Pd0pha running wspr with only 6 Miliwatt on an endfed now ..

@K0PIR
Copy link

K0PIR commented May 26, 2017

The problem I have discovered is the WIFI gets disconnected after transmission starts. I am trying to use WIFI and VNC. If I have a keyboard, mouse and monitor connected I don't have any problem, but I can see the WIFI gets disconnected. I haven't tried with a wired connection yet using VNC.

I have tried a couple of different antennas. First, I used just two 17' wires attached to the WSPR TX Shield. One in each slot. Then I tried a coax with the shield in one slot and the center wire in the other. It is connected to the antenna, but still the antenna is only a couple of feet away from the RPi3. I still have the problem of loosing WIFI. I am wondering if the antenna is just too close to the RPi3 and that's why it is killing the WIFI.

@K0PIR
Copy link

K0PIR commented May 27, 2017

On mine I have found that using it on a wired connection (eth0) it does not crash and works perfectly. I tried a longer coax (16 ft) and it still crashed while using WIFI.

@MontyOH
Copy link

MontyOH commented May 29, 2017

Okay - gotta leave a "results" comment after so many weeks of fighting this:

Initial testing is included above. Wsprry works great with Mate on the RasPi3 - but had hiccups that would "mostly" work under Jessy. The RasPi0 W would NOT work headless to save my soul. It would xmit perhaps 1 time out of 8 and hang during the middle. If the session was a console one under Jessie, much greater chance of success.

However - after reading pwassink and his post - I tried to do a FRESH install, with all updates including the "dread" rpi-update (was told that was unstable) and ONLY put on Wsprry. Guess what, it works on both RasPi3 and Zero.

Only hitch was that you NEEDED to be logged in for the first run of the program. I was headless and it hung both times. However, after hooking up a keyboard and screen, logging into the console - has worked like a charm ever since. Have been testing the Zero for the better part of a day on a battery - idea was to have much better battery life with the Zero than running Mate under RPI3.

So...... That is my results. If you are having problems, give the shout. I have burned 4 copies of the Jessie OS and recreated the results with 2 different RPI0s and two RPI3s. Each time I needed to log into the console - so there it is. Hope it holds and helps someone else in need!

@MontyOH
Copy link

MontyOH commented May 29, 2017

I should have added that you only need to log into console once - works headless after that. Been running screen and detaching with no issues.

@Supremehamster
Copy link

GOOD NEWS
Running on Jessie latest upgrades updates on pi2b
Kept crashing at different times - I finally figured out it is the screen blanking which is causing the problem.
Setting consoleblank=0 in /boot/cmdline.txt and rebooting fixed it.
Perhaps the wsprrypi code (or lower) can't handle a blanked screen? ;)

@JamesP6000
Copy link
Owner

Thanks for the consoleblank workaround! Are things stable now for everyone? Can I remove the warning from the README that points to this thread? Or are people still having problems?

Thanks,
James

@MontyOH
Copy link

MontyOH commented Jun 30, 2017

Added the line into the JessieLite side for the RPIZeroW - works and do not have to reboot after using it once. So sure seems to - although since using it headless, can't fathom the consoleblank doing anything.... Well - it seems to work!

@doug9999999999999999999999999999999999
Copy link

I have been running on an RPi3 with the TAPR shield for over a year. When running headless in GUI I loose wifi after the first transmission and of course then loose my VNC connection. A few days ago I started crashing with the following error "Exiting with error; caught signal: 28". I wiped the SD card and started over. Same issues. I tried Supremehamster's console blank work around. Same issues. Gave up on GUI. Rebooted in CLI and have had the same PuTTY/wifi connection running stable for over 24 hours with WPSR tx'ing like clock work.

edit: I spoke too soon. Right after I posted this the wifi dropped. Still tx'ing like a champ. Then I rebooted as I do not want to tx unattended.

edit_2: now I am getting "Exiting with error; caught signal: 28" in headless CLI too.

@bcorky
Copy link

bcorky commented Aug 7, 2017 •
edited
Loading

I get the same " Exiting with error; caught signal: 28 " when running headless.. after a short transmission using Pi3 and latest raspian with the TAPR shield

@doug9999999999999999999999999999999999
Copy link

I upgraded to Raspian Stretch and everything seems to be working now. I am running GUI headless for now.

@BruBor20015
Copy link

I have a RPi 1 Model B running Stretch. When I run wspr, it will output the correct signal for a second to maybe 10 seconds and then stop outputting. The app still runs and reports its status as if it is actually running. I stop the app with Ctrl-C. Even when I try test mode, the output only lasts for a few seconds. This all worked fine with Wheezy, so I know there is nothing wrong with my hardware. I have tried all of the fixes mentioned in this issue, but nothing has worked. I have all of the latest updates and upgrades. I do not use a GUI. I boot to a CLI. Has anyone else been able to get wspr to work with Stretch and RPi 1 Model B?

@bcorky
Copy link

bcorky commented Oct 13, 2017

I know this a funny question but is your internet connection working? When i put a clean copy of stretch did not support it and I had to go to some lenghts to install it manually.

@BruBor20015
Copy link

My internet connection is working fine. Never any trouble with that. I'm thinking I might just upgrade to a Pi3 since wspr was reported to work on Pi3 with Stretch. I still would like to know how to get it to work on Pi1B.

@bcorky
Copy link

bcorky commented Oct 13, 2017

Fine but It was a Pi3 that I had trouble with the WiFi had to manually load the entry for it. There was a bit of chatteer on google that helped me . the same pi3 worked fine( and still does) with with Wheezy . Why I asked is that it corrects it self with the time server on the internet and i thought it might be loosing contact ,but I would have expected some error message.

@BruBor20015
Copy link

SUCCESS!
I now have wspr running on Pi1B with Stretch. The problem was self-inflicted. I had enabled the Dallas 1-wire interface that uses the default pin GPIO4 as its interface. That is also the pin used by wspr. I had to add the line

dtoverlay=w1-gpio,gpiopin=23

to /boot/config.txt to instead use GPIO23 for the 1-wire interface. I have a DS1820 temperature sensor on GPIO23.
So I now have an ADC on SPI, LCD module on I2C, temperature sensor on 1-wire and wspr on GPIO4, all running simultaneously. Very cool.

@k6mle
Copy link

k6mle commented Nov 5, 2017

I have the RPi Zero working quite nicely with wspr. It's running headless and I VNC into it to get things running. What I've found (and it may be the command I'm giving to start wspr) is that it's running in a continuous TX cycle, rather than the 80/20 cycle that is typical with wsjt-x. As a work-around, I've put the wspr command into a cron job to run every ten minutes, or so. My question: is there an option/method to issuing the wspr command at startup that will give the TX a little more down time?

Thanks,
Michael
K6MLE

@roamingryan
Copy link

roamingryan commented Nov 16, 2017 •
edited
Loading

My recent pull request (#16) has a fix for the Exiting with error; caught signal: 28 error that many people are reporting.

@zanco
Copy link

zanco commented Jun 30, 2018 •
edited
Loading

Hi. Today I installed WsprryPi on a new Pi ZeroW with debian Jessie. Used an image I use for my PiZero W lora tracker. Ran update, upgrade, checked kernals, disabled Bluetooth and onewire. Disabled the console blanking also.

No luck with transmitting. EIther from SSH or from the console screen (hdmi monitor - usb mouse keyboard) the wifi suddenly disables. SSH fails because of that. The program can be stopped with ctrl-c and then the wifi comes up again.

Any clue which log file to check to get some more information how to continue ?

Edit: Tried different USB cable, battery powered, dc decoupled both center and shield from the antenna wire by capacitor, attached a single 30 cm wire, all the same result. wspr -t works however without problems but running wspr as soon as the tx starts the wifi goes offline.

Thanks,
Ben - PE2BZ

@Sharkusa
Copy link

Sharkusa commented Nov 16, 2018 •
edited
Loading

I'm thinking this is an RFI issue.
I'm getting a lock-up on a headless RPI3 with the TAPR shield, mine only boots me of the WIFI but keeps running if I get out of screen before the first run. No way to restart the terminal and can't ping the IP, it needs to be rebooted to get back in.
I also have a home built LPF with no amp and that runs fine with no lock-up.
73's

@mark-orion
Copy link

@Sharkusa thanks for suggesting RFI. I have the same crashes you are describing on and off. I am using a PiZero feeding via a filter into a magloop. With the PiZero mounted more or less in the centre of the loop I do have the power cable sometimes dangling too close too the loops capacitor (strong electric fields here!) and it looks as RF is creeping into the line. Keeping the cable away eliminates the crashes and maybe it's time for a ferrite choke too.

@AA7US AA7US mentioned this issue Feb 26, 2019
Open
@JimNtexas
Copy link

I had this issue. When I initially set up my TAPR/wspr system I was using a good sized usb battery power supply. Once I got it working, I move the transmitter to a more permanent location and plugged it in to an Apple 110v usb converter, a small one.

Then I got the crash after 'Waiting for next wspr....'.

After futzing around I switched back to battery power and it worked! I replaced the little Apple usb power wart with a 2 amp power wart, and it is working again!

@zinkwazi
Copy link

zinkwazi commented Jun 27, 2022 •
edited
Loading

Hi All,
I would really like to get this working on a Raspberry Pi Zero 2 W for a low power mobile WSPR rig but still experiencing the crashing issues mentioned by many above.

I am testing with the updated version from threeme3 as well as the latest from @JamesP6000.

  • Using @JamesP6000 version, the pi zero hard crashes immediately when the wspr executable is called.
  • Using threeme3's version If I use makefile1 then the pi zero crashes immediately and requires a hard reboot and if I use makefile2, wspr starts but doesn't transmit and just sits at the "TX started at:" message.

I have two pi zero w that I am happy to donate to @threeme3 or @JamesP6000 or someone who has the know-how to work on this.

I have done the following troubleshooting steps:

  • Disabled wifi, bluetooth and HDMI
  • PiFmRds compiles and works fine
  • Tried battery power and high quality 2A USB power
  • Same issue occur when low pass TAPR filter hat is not present
  • I have successfully used headless rpi v3 and v4 with the TAPR hat on backpacking trips using GPS for accurate time

I am also happy to try other suggestions or code edits and test remotely if anyone has any good ideas.

thanks,

Greg

@zinkwazi zinkwazi mentioned this issue Jun 27, 2022
Open
@edegraaff
Copy link

Hi, my zero also crashes directly, strange cant figure out why

@edegraaff
Copy link

Hi, my zero also crashes directly, strange cant figure out why

Well, found a workarround, connect keyboard and monitor, and the system is stable, why? no clue at all but it works.

@zinkwazi
Copy link

SOLVED: Raspberry Pi Zero crashing successfully solved by adding an HDMI dummy load adapter.
https://github.com/zinkwazi/wspr-zero
IMG_9252

Thanks for all the suggestions above, very rewarding to find a workaround so that I can use the pi zero for mobile WSPR!

@trancen trancen mentioned this issue May 6, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests