In an effort to further simplify feeding, we have started maintaining an SD card image. The image is basically a FlightAware “piAware” 3.1.0 image with some changes. Take a look at the “how to feed” section for more details. This new method requires no SSH access, or command line activities whatsoever.
Changes made to the piAware image are as follows:
- Installed the adsbreceiver.net scripts to maintain an ADS-B and Mode S feed to ADSBexchange (https://github.com/jprochazka/adsb-exchange.git). Note, this complies with FlightAware’s request not to forward their MLAT calculations to 3rd parties. You will see both FlightAware’s and ADSBexchange’s MLAT calculations on your local dump1090 web-interface, but FlightAware’s calculations are not forwarded to us.
- The device will reboot daily at 10:00 GMT
If you have feedback, let me know.
Aside from the annoying sounding daily reboot, does this image differ from the one provided by the adsbreceiver.net project directly?
https://github.com/jprochazka/adsb-receiver/releases/latest
The daily reboot keeps things running clean (ie. memory leaks, etc.). It’s different than the adsbreceiver image because it can be installed, setup, and run by someone who does not want to (or can’t) use the CLI at all, and might not have any idea even what the local IP of the pi is… It’s the FlightAware piaware 3.1.0 image with a couple of very minor mods. I have future plans to add more as time permits.
Its a fair point on the need for an image that can be installed without touching the CLI, does the image automatically update the adsb-receiver scripts so that the user doesn’t have to think about upgrades?
In my experience I haven’t seen any of the symptoms you describe on the piaware image that would justify regular reboots, never mind daily ones…
Putting aside for a second whether this is a good idea or not, firstly would doing this weekly say on a Sunday be a more reasonable balance?
Timing wise 10am seems like an odd choice as even with this being set in UTC it seems likely there would be planes overhead if deployed anywhere in Europe, is there a reason why this couldn’t happen at say 3am when there is a much lower chance of the reboot resulting in missed tracks?
And finally I would also be concerned about having a large number of feeders go offline at the same time, even if only for a couple of minutes, could some sort of randomisation be introduced say by adding the last octet of the devices IP address divided by 4 number of minutes past whatever time is deemed most suitable for a reboot?
This is a work in progress. Upgrade functionality is slated for down the line.
Regarding the rebooting. Just 2 days ago, I had a piaware (it was 3.0, granted) go offline in the middle of the day, the 3am reboot brought it back. It is rare to have an issue, but I understand where you’re coming from. I beleive we only lose about 30 seconds of data with a reboot, so it is minor. Perhaps we could scale back to once per week, and randomize. Those are all good suggestions. 1000 GMT was chosen because for me that’s 3am local. Clearly, it doesn’t scale for other geographies and that’s something else we need to address. For the audience this image is aimed at, a daily 30 second outage may not be a big deal. It’s performed via root’s crontab file, if you want to modify it.
These are all good points we will address going forward.
Thanks,
Dan