PiAware stops working from time-to-time & tiny UPS


#1

Hi All,

FYI: I’ve had two instances where my two PiAware units stop working for no reason. The solution that worked is to reboot the units. If I’m not around that is not possible. The enacted solution is to schedule a automatically reboot at 2am when there is little to no air traffic in my area. Not sure this is the correct solution. I looked up the linux settings for this:

In file /etc/crontab, using nano:

sudo nano /etc/crontab

I added at the bottom:

0 6 * * * sudo reboot

The PiAware time is UTC, 6am, so for EDT this occur at 2am. Yes sudo may not b necessary, but in a puTTY session I tested it and it does work.

Now I wait and see if this occurs again.

Next, to make it ‘bullet’, I need a tiny, really really tiiny, UPS for each unit. Any idea? I have a few but not ready for prime time as yet.

Ted


#2

Unless you have an actual power problem, the Pi units should not hose-up on their own. Have you checked the logs (dmesg) to see if there is a clue to the failures?

…Tom


#3

I would second the ‘rPi really shouldn’t be locking up’ sentiment(specific applications can and do get buggy, and I’ve had cheap USB wifi NICs flake out on me; but actually having the system hang such that I can’t SSH in or use a local serial terminal is not good, the kernel is mature enough that just dropping dead shouldn’t happen.)

If you haven’t already tried it, you might want to test with a nicer power supply(the ratings on some USB-charger widgets are very, very, optimistic and the power quality atrocious; USB cables can also be an issue, some of the cheapies have surprisingly high resistance on power and ground, and can cause some voltage droop, feeding the header pins directly with thicker cable might be worth looking at, especially if your Pi is any substantial distance from its PSU). It might also be worth testing a different SD card: some models hold up pretty well; but some are barely qualified to successfully store pictures and can start flaking out when used as an OS boot volume.

As for UPS, if you can find one of those ‘portable USB charger’/‘battery bank’ units that they sell for recharging phones and the like that will accept being connected to a charger at the same time as a device is connected for power, that would make an inexpensive and compact option.

Another alternative is to take advantage of the wide availability of 12 and 24v to USB adapters sold for powering electronic gizmos in the car; and use those to connect the Pi to a UPS running at one of the conventional lead-acid battery bank voltages without incurring unnecessary inverter losses. 12 and 24v systems are going to be vastly more common, and inexpensive per unit power, for mains-connected UPSs; but there isn’t a lot of point running an inverter when you can get efficient DC-DC converters designed to power 5v loads.


#4

I will look into it. Just had both units upgraded to PiAware 2.1-3. Any issues there?


#5

Actually both units are not reporting ‘LIVE less than a minute ago’ through FA. Also, I’ve reset (power cycled) router, and both PiAware units. Still have issues.


#6

Wow! lots of good suggestions. Thanks!


#7

They seem to be connecting then disconnecting immediately. I can’t tell why from this side. Check the piaware logs in /tmp?


#8

Have you tried running them both via Ethernet cables to rule out USB wifi adapter issues?


#9

Not yet. Seems unlikely that both wifi adapters are bad. I here my wife saying no internet. Sounds like an outside the home issue.


#10

I don’t think the wifi adapters are defective. What I do suspect is with both a USB wifi adapter and the USB dongle plugged directly into the Raspberry Pi’s, they might be having a USB power issue. I run both of my Pi set-ups with a separate powered USB hub where I connect all the USB devices. This, in my opinion, allows my Pi’s to run cooler and they are more stable.
…Tom


#11

PiAware site 13197 is now in ethernet and I now get aircraft plot of what the unit sees, however I get a ‘Live 2 minutes ago’ status. Also, I get an Anomaly message on site 12292 on MLAT not reaching server - that units shows 2 hours outage - that unit is still on wifi (in my shed) and has been reliable.

All this seemed to start when I upgraded to 2.1-3. Would the ISP, Comcast, impede or restrict certain ports? I recall that 2.1-3 send MLAT to FA from separate port (from ADS-B)


#12

Is there any way to downgrade from 2.1-3 to 2.1-2?

This seems to have triggered the outage but can’t be too sure? Both units were fine before that point… :question: :exclamation:

They seem to be better now but neither will provide local coverage plots…

ARGHHHHH!!! :smiling_imp:


#13

It’d be good to know what went wrong, or that problem’s not going to get fixed… Did you look in the piaware logs?
It looks like you are feeding OK now, but the new diagnostics in 2.1-3 that check on mlat traffic are saying that none of the UDP traffic is reaching Flightaware (you’ve got an anomaly on your stats page and there should be messages in the piaware logs too). So I think there are still some network problems.

You can downgrade by installing the older package by hand (it’s still available, use the URL of the current package and do the obvious thing to the version number). But that’s only really delaying things.


#14

[quote=“obj”]

Everything is now working - no real explanation. At about the time everything went normal I set the WL router outbound port range to 4999-9999 then checked 12292 coverage plot and I now see MLAT in blue aircraft icons. Thought I fixed it so I disabled the setting - Blue MLAT icons still there - Now I’m really confused!! Maybe I’m doing things too quickly and not letting things settle of the FA side. I did look at piaware.out wich stated the same at the FA anomaly report.

One good thing to come out of this: I realized I had a Blackberry Z10 battery and charger that I am not using - with a fully charger battery it keeps the Pi up for about an hour - that’s about an average blackout in my area.

Am happy things are working as they should. **I hope it lasts. **

Today was very humid. I’ve asked this question before of others not FA folks - no definitive responses. Does/can high humidity degrade wifi signal to inadequacy? Both PiAware units operate through a wifi link. As a test site 12292 (shed) is unavoidable, site 13179 (family room) is now ethernet through a powerline extension (yes powerline networks extension work beautifully). Tomorrow in the Boston area we will have foul torrential rain. LET’S SEE WHAT HAPPENS. Maybe not too many flights if at all but I should still get a coverage plots on 13179 and not on 12292, if the humidity theory has any merit.

Thanks for all you input and support Guys.


#15

Have a look at weworkweplay.com/play/rebooting- … tion-wifi/

I would ping the router gatwaye port (often 192.168.0.1)

then there’s this
blog.ricardoarturocabral.com/201 … ng-on.html

To reboot a hung pi … but if it’s hanging regularly - theres’s something wrong since the Pi and the standard software set we use is stable.


Note: My pi doesn’t do WiFi - it uses Ethernet to talk to a Vonets VAP11G wifi bridge ($20 from amazon) … that does the Wifi … avoids all the issues of getting the wifi setup right.


#16

Just posting here to let you know the issues I have had. It also seems like to me that since I’ve updated to 2.1.3, I keep having disconnect/freeze-ups on my PiAware RPi.

If there is anything I can do to help diagnose this issue, please let me know.


#17

FYI - since I’ve added the crontab instruction to reboot every day at lowest activity time - 2am. I’ve not had an issue. Not sure if this really cures the issue. Like all other PCs a reboot can’t hurt. See instruction I used above.

Good luck!


#18

Yeah I have also added in the crontab restart along with a restart if my wifi goes down too. Its only a band-aid though, it doesn’t fix the issue. So far I’ve had it go down once and it hasn’t reset yet though, so I’ll see in a few hours if it resets itself, I’m thinking I need to change it so it restarts every 2 hours to minimize downtime.