Feeder Outage

[wiedehopf]

I'd recommend turning off the outage emails.

I could implement such stuff but i don't really fancy working around their client any more than that guide i linked does already.
If you really want to fix it and want me to implement some workaround, you'd first have to reinstall and follow that guide so i have a somewhat known basis to start from.
Just use a 2nd sd-card, that way you can switch them back if you're not successful.

https://github.com/wiedehopf/adsb-wiki/wiki/Raspbian-Lite:-ADS-B-receiver

[wiedehopf]

Honestly i'm not even sure rebooting the Pi helps?
I've restarted the feed service and the stats aren't working properly anyhow ;P

Really i'd try to and not depend on the FR24 stats at all .....

[wiedehopf]

Nevermind my FR24 stats are working they just update really slow.

Even if you don't do a complete reinstall, install fr24feed like described here: https://github.com/wiedehopf/adsb-wi...ADS-B-receiver
It will provide you much better logging (without all the useless stuff) and you can try the older 1.025 and the newest 1.026 easily.
If your config is present already, don't do the signup, just restart the service at the end:
sudo systemctl restart fr24feed

[abcd567]

On all the 3 Pi's

$ apt policy fr24feed
fr24feed:armhf:
Installed: 1.0.26-9
Candidate: 1.0.26-9

No issues

18-Oct-2020-T-CYYZ9.png


18-Oct-2020-T-CYYZ52.png


18-Oct-2020-T-CYYZ100.png










.

[Oblivian]

Right. Total lack of updates that they've released another version again...

26-9 has gone production (wasn't 26-7 the test!!). Anyone who manually updates or disabled auto update will need to re-do

With any luck this will stop everyone with current concerns (bar those with clear issues like the SSH death too)
Although the description differs. As even when it went offline itself wouldn't restart. System will still have an IP then I would have thought..

# [1.0.26-9] - 2020-10-13
## Fixed
- Bug where in some cases empty updates could be sent to the server.

# [1.0.26-8] - 2020-10-12
## Fixed
- Bug in ground speed decoding for 2-15kt range.

# [1.0.26-7] - 2020-10-05
## Changed
- Last config can now be cached on disk (optional).
- Added incremental backing off when fetching config fails.

## Fixed
- Fixed crash when fr24feed is started before system has an IP.

[verdi]

What does all this mean ?

[Oblivian]

What does all this mean ?

With your unrelated issues.

Nothing. Carry on trying to find why your entire network/Pi is shutting down core services first of all.

[T-EDDL262]

Ok, the range issue is fixed. Now I am back to 330 Nm average. Simply all Versions after FR24 1.0.25 have a bug that calculates the range wrong.
the only thing I have to fix now is the outage issue.
Is anyone aware of any logfile the Pi stores where I can see if it stopped due to an internal issue (core software) or if FR24 is causing the crash?
what irritates me is that I cannot reach the Pi at all via WLAN. Only a cold start fixes the issue. I changed the Power supply just to be sure....... but again 5 minutes ago it went offline

[wiedehopf]

There is some network bug apparently with some certain routers or whatever, not exactly sure..... you could try this i suppose, but be careful to get it exact and not forget the -a.

echo noarp | sudo tee -a /etc/dhcpcd.conf
sudo reboot

[T-EDDL262]

Interesting! Tried it yesterday evening and until now it is working stable. Do I see it right that " tee -a " writes into dhcpcd.conf but what exactly??
I cannot find the parameters for tee in google :-P I find postings using "tee" but no explanation what sudo tee-a is doing.

Thanks anyhow and fingers crossed. My router is a fritz box 7590 with two 1250 mesh routers and it looks like it really is a bit tricky as time by time also my YAmaha audio speakers (Satelites and Subwoofer via WLAN for 7.1 setup) also loosing connection....

However Range is back to "normal" after Downgrade.

Bildschirmfoto 2020-10-22 um 10.40.08.png

[wiedehopf]

man tee
man sudo
man echo
man dhcpcd.conf
(search for noarp)

google bash pipe

[wiedehopf]

In regards to the range, i'd actually expect the newer version to be correct rather than the old one.
To claim a certain range, you need a certain number of positions reported that far away.
The threshold probably was probably very low and they increased it.

[T-EDDL262]

Thanks for the great support anyhow. Unfortunately again the Pi went offline.... So your hint did not solve the issue.....
Maybe I give it a try and change from WLAN to LAN maybe this will fix it....

[abcd567]

T-EDDL262:

What is output of this command?

apt policy fr24feed

If output shows that "installed" version is less than 1.0.26-9, Do this:

wget http://repo-feed.flightradar24.com/rpi_binaries/fr24feed_1.0.26-9_armhf.deb

sudo dpkg -i fr24feed_1.0.26-9_armhf.deb

After installation is complete, check version:

sudo apt policy fr24feed

[T-EDDL262]

The 1.0.26-9 was installed and crashed even more-........
I can assure you that some friends of mine have the same Version running I am using and their Pi works flawless since month's
None of them is using the current 1.0.26-xx

I think the issue is somewhere else as I cannot reach the Pi at all when the outage message comes. it simply is not adressable. I think the issue is in the Network environment or maybe simply the Pi is defective.
That is why I asked if there is a general logifiel of the Pi where I can see why it crashed. today it crashed exactly at 13:54 (11:54 UTC)

So if I would know where a logfiel can be fund I could read the information and post it so that someone with more knowledge than me could make a suggestion....



On the other hand I do find plenty of Feeders which have the same issue that the pi stops feeding into fr24.