WsprryPi
WsprryPi copied to clipboard
JamesP6000
Crashes when "Waiting for next WSPR transmissoin window".
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.
could you take a picture of your test setup? this very well could be a power / grounding issue.
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
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?
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.
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.
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
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.
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
You seem to be missing your callsign. Can you try again and see if it still
crashes?
wspr [options] callsign locator tx_pwr_dBm f1
JP
On Mon, Apr 10, 2017 at 11:54 AM, orsty3001 [email protected] wrote:
sudo wspr -r -o -s EM94ax 10 20m 0
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JamesP6000/WsprryPi/issues/6#issuecomment-293044747, or mute the thread https://github.com/notifications/unsubscribe-auth/AEiQH5OdOsQG4rcccqFLtkpjQboMSqAYks5runrZgaJpZM4M3NGd .
I substituted "My Callsign" there so I wouldn't have to post my real callsign.
`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.
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... `
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.
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.
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...
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
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.
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
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???
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
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.
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.
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.
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!
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.
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.
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.
I am having the same issue with Zero in headless mode too. No problem with only HDMI or only USB or both plugged in.
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 ..
