Feeder Outage

[T-EDDL262]

Hi Gents,
I am facing huge issues with my FR24 feeder (Raspberry 4b)
My setup:
Raspberry 4b
Airspy USB mini
Uputronics 1090MHz ADS-B Filter

I am receiving constantly "Feeder Outage Notifications" and can see that the connection to FR24 is lost.
Bildschirmfoto 2020-10-13 um 11.37.39.png

I do have a 100MB DSL line and all other equipment in my household is working flawless. This causes that my acccumulated online time of course is going down day by day.

I have no idea whatsover why this is happening. The Raspberry is also connected via WLAN.
Any idea or hint how I can see what the cause is?

Andreas

[Oblivian]

At a guess....

https://forum.flightradar24.com/forum/radar-forums/flightradar24-feeding-data-to-flightradar24/194147-fr24feed-26-5-dvbt-fail-receiver-down-failed

[verdi]

I haven't found the solution either,,, Clipboard01.jpg

[T-EDDL262]

This is driving me nuts. I now updated the Raspberry with the latest Version and now, on top of the above issue, my Range is just half of what it was before.... My Average range in the past was 325 Nm and now is just 180Nm! No chage to anything done except the Raspberry upgrade....... And still the Feeder Otage Notification. I checked Oblivions Thread bt beside the situation that I do not understand what is "dump1090-mutability" ( This "service" is not running o may installation, my FR24.ini is looking pretty much the same:
receiver="beast-tcp"

fr24key="xxxxxxxxxxxxxxx"

host="127.0.0.1:31004"

bs="no"

raw="no"

logmode="2"

logpath="/var/log/fr24feed"

mlat="yes"

mlat-without-gps="yes"

In Virtual Radar I can see that tha Range is much higher:

Bildschirmfoto 2020-10-17 um 18.29.21.png

[Oblivian]

So you use rtl1090 instead?

That would have been handy to know prior, you probably won't find dump1090 if so.

31004 is tcp sbs/bs format normally. And gain and other setting are set in that.

You might see that in vrs but what is the last received signal timeout. Average on stats is the traded off middle of the lowest and highest. If there is gaps in signal, fr24 often ignores

If you were somehow sending blended mlat results previously in error, that would sure boost it.

What other feeder apps/ configuration present

[wiedehopf]

Those ranges in VRS are bogus.
400 nmi is not really achievable unless you get lots of ducting and the weather conditions aren't right i believe.
My guess would be you had the location configured wrong or something.

Usually you should point it to this, port 30005: host="127.0.0.1:30005"

How did you set up the airspy, you use the airspy_conf script? In that case definitely use 30005 ... data should be available there.

[T-EDDL262]

Well I cross checked the results of VR with FR24 planes that are reported and I could see the same plane in both Tools. So some planes with range>300Nm are possible with the Antenna I am using. I live >600km north of Paris and can see planes in VR that are pretty much in this distance. So this is almost 300 Nm far away from me. I tried to change the Settings as described above to 127.0.0.1:30005 but then the Feeder is running but no planes are reported anymore but still VR is working. Honestly I don't know how the Airspy is configured as I took over this image 5 months ago from a colleague and we did "just" the usual FR24 Setup to have the right location. It has worked fine and the ranges were as expected (Average 320Nm reported) he has a better ceramic filter and has an average range of 349Nm. Then the issues started around May for me that the Raspberry went offline sporadically (no change to the setup at all) and since the DDOS FR24 faced it is simply a lucky day it is not going offline minimum twice a day. I changed the Powersupply to ensure that this is not the case and also used a new Power supply for the Antenna Filter (it is normally powered via the airspy but I am using an additional PWS)

So beside the "offline" Situation since the Raspberry OS Update, I am also singnifically losing range! This for me does not make sence at all!

I am not addicted to the Raspberry OS and have very limited understanding of nano and the use of it. So I am a bit lost here and really need a step by step "support" to secure that some mistakes or not done because of a faulty setup.
I would like to use the original FR24 Setup (latest version) but I fear that then the airspy will not work anymore as FR24 is using different Hardware. So I simply cannot :-(

My colleague is not reachable for me for the time being......

[T-EDDL262]

Actual screenshot of VR where 1 Ring represents 50 Nm
Bildschirmfoto 2020-10-18 um 10.12.56.png

[Oblivian]

I tried to change the Settings as described above to 127.0.0.1:30005 but then the Feeder is running but no planes are reported anymore but still VR is working

The big question is, was it showing aircraft still?. Because if you are seeing planes on VRS while the feeder is not uploading/showing 0 reported. Then that is getting them from another networks MLAT feed or similar. And not a true representation of your local feed.


On second thought, ignore that. As we don't know what decoder/source setup to confirm

[wiedehopf]

Let's see then, show the output for these commands:

pgrep -fa airspy_adsb
pgrep -fa dump1090

It will show which ports airspy_adsb is listening on.

[T-EDDL262]

So I can assure that VRS is set to my location:
Bildschirmfoto 2020-10-18 um 10.36.10.pngBildschirmfoto 2020-10-18 um 10.35.51.png


This actually is showing when the FR24 Feeder is set to 127.0.0.1:31004
Bildschirmfoto 2020-10-18 um 10.37.35.png
And this 30 seconds later when I set to 127.0.0.1:30005
Bildschirmfoto 2020-10-18 um 10.38.14.png

VRS then still working

[T-EDDL262]

Let's see then, show the output for these commands:

pgrep -fa airspy_adsb
pgrep -fa dump1090

It will show which ports airspy_adsb is listening on.

pi@raspberrypi:~ $ pgrep -fa airspy_adsb
470 /home/pi/airspy_adsb_117 -l 31004:Beast -t 3600 -p -n -w 4 -d 2 -g 21 -b
pi@raspberrypi:~ $ pgrep -fa dump1090


So ther obviously is no 1090 dump..........

[wiedehopf]

Yeah 31004 is correct in that case.

That means it's just FR24 being intermittent.
Several other people can't get rid of FR24 being intermittent either, i wouldn't worry about it, it's on them to fix that.

In regards to having lower range than before, that might just FR24 being intermittent and thus FR24 stats being incomplete.

Your furthest contacts are over the water, so that might indeed be some sort of ducting.


It's not terribly hard to start fresh on a 2nd sd-card keeping the current one as a backup:

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

Those instructions include setting up airspy.
It's a bit of stuff to work through, but it's possible even without previous experience with Raspbian.

[T-EDDL262]

Hi Wiedehopf, thanks for your support, of course also to Oblivian :-)

So I understand that this is obviously nothing I can change. Anyhow it is a bit frustrating as I manually have to restart the Pi sometimes up to 3 times a day....... DO you know if there is any way to check if the Pi still is in contact with FR24 and if it is not getting a response let's say >2 minutes it will automatically perform a reboot or restart of the FR24 client?

I am earliest receiving a mail after 60 minutes and then can "Hard reset" the Pi with a Plugt that is controllable vie Philips Hue (so simply I switch off and on .....)


This is not the most elegant way but the only solution I am able to implement for know......

What is strange is, that my colleague who has exactly the same setup (except he is using a better Antenna+filter) has no issues at all and his Pi is working without any issues: T-EDDL230

[Oblivian]

You might get away with downgrading fr24feed and stopping the auto update.

But it does take some further SSH work

https://github.com/wiedehopf/adsb-wiki/wiki/Raspbian-Lite:-ADS-B-receiver#feed-fr24-optional