Crashes when "Waiting for next WSPR transmissoin window".

[orsty3001]

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]

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

[orsty3001]

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]

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]

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]

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.

[JamesP6000]

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]

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]

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]

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

[JamesP6000]

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 notifications@github.com 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 .

[orsty3001]

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

[orsty3001]

`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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[BruBor20015]

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]

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]

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]

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]

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]

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]

My recent pull request (https://github.com/JamesP6000/WsprryPi/pull/16) has a fix for the Exiting with error; caught signal: 28 error that many people are reporting.

[zanco]

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]

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]

@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.