FlightAware Feeds; Other Feeds Go Down

They are not that smart :wink:

So do I, but RB24 web map shows my location about a km off, logged-in or logged-out, same. :+1:

That’s strange, for me it was very exact when logged in.

Oh, after several Ctrl+Shift+Delete and Ctrl+F5, Logged-in=precise, logged-out=aproximate
This stubborn browser Cache :frowning_face:

Can you expand on this? I don’t run their Windows software any longer, but I’m curious to know what the issue is/was.

Hopefully it’s just the Windows version, as I was about to add them again to one of my ‘combos’. I do like that you can see your traffic from any internet enabled device when away from home.

Out of professional curiosity I wanted to see how they do their randomness. So, I looked at RB24 @keithma location in Chrome and in Safari. Not logged in (as I don’t feed them). It turns out that the location is identical in both browsers. I’m guessing that is how all feeders do this then. Once someone starts feeding, pick a random location within a km and keep that location fixed.

They just round to 2 decimals in regards to degrees latitude/longitude.
FA does it the same (the stats page just displays the value)

On FA you can set it to round to 1 decimal as well (the 10 km setting).

That’s why the coordinates for FA 1km precision is the exact position RB displayed for my feeder.

I c. There’s no random number generator involved even. I assumed too much clearly. :grinning:

Yes, it has nothing to do with their RPi feeder.

(1) Their Windows software latest version does not work ok with their spplied hardware (AirNav RadarBox) and many users have down graded to previous version.

(2) On Win 10 zadig does not install properly or fails. As result ALL dvbt based dongles, including RB24 FlightStick, FA ProStick, and generic dvbt fail. This is NOT RB24 issue, it is Win10 vs Zadig issue.

Nothing specific. Just seemed like the update rate was really slow.
Which is probably because it’s not local but online data from the website?

It was more a general rant, nothing wrong in particular.
Oh yeah now i remember, they introduced a new software version for their new hardware and it has bugs, so the guy with most activity on the forums recommends the previous version :slight_smile:

Nothing wrong with the linux feeder i saw, just meh.
Also it spams the log an awful lot.
The fr24 feeder is much scrappier and i still run that.
(because i sometimes use the premium functions on their website)

And mine ends with 1142 :upside_down_face:

It gives a very precise location, I agree. But that’s not where the aerial is, they do appear to have added a fiddle factor.

Thanks @abcd567 and @wiedehopf.

I added the RB feed again.

Funnily enough, mine is showing offline at RB despite the other places I feed to being online.

relevant xkcd: xkcd: Coordinate Precision

1 Like

That was recently linked when i suggested 5 decimals when configuring receiver location in regards to MLAT :wink:
I suppose 4 are probably plenty!

The main reason I like RB24 is that it provides a web interface showing my planes & max range. I dont have to open any port in my router for others to see my planes live.

https://www.radarbox24.com/stations/EXTRPI000008

https://www.radarbox24.com/stations/EXTRPI000035

And as we are being off-topic and chatting about other feeders anyway:

Anyone has any clue why i would keep getting this in my FR24 feed logs?

2019-07-09 23:59:13 | [mlat][e]Received MLAT timestamp error: 59 seconds!

Note my flightaware MLAT is working nicely.
By chance does anyone else have this problem?
(It’s well hidden in the logs so i wouldn’t be surprised if other people just don’t notice it)

In case you want some better logs for fr24feed, follow the advice in the 2nd post of this thread: FlightAware Feeds; Other Feeds Go Down - #2 by wiedehopf

It will give you most relevant information without any spamming logging:
sudo journalctl -u fr24feed

2019-07-09 16:29:05 | [reader][i]Connected to the receiver, configuring
2019-07-09 16:29:07 | [feed][n]connecting
2019-07-09 16:29:07 | [feed][n]connected via UDP (fd 15)
2019-07-09 16:29:07 | [feed][i]Feed connected
2019-07-09 16:29:07 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
2019-07-09 16:29:07 | info | Stopping ReceiverACSender threads for feed 
2019-07-09 16:29:07 | info | Configured ReceiverACSender: 185.218.24.22:8099,185.218.24.23:8099,185.218.24.24:8099, feed: EDQG49, send_interval: 5s, max age: 15s, send metadata: true, mode: 1, filtering: true
2019-07-09 16:29:07 | info | Network thread connecting to 185.218.24.22:8099 for feed EDQG49
2019-07-09 17:21:28 | [feed][n]syncing stream: timeout
2019-07-09 17:31:20 | [feed][n]syncing stream: timeout
2019-07-09 17:35:43 | [feed][n]syncing stream: timeout
2019-07-09 17:35:43 | [feed][i]Feed disconnected
2019-07-09 17:35:43 | [feed][n]disconnected
2019-07-09 17:35:43 | info | [feed][n]waiting 7 seconds
2019-07-09 17:35:50 | [feed][n]connecting
2019-07-09 17:35:50 | [feed][n]connected via UDP (fd 15)
2019-07-09 17:35:50 | [feed][i]Feed connected
2019-07-09 17:35:50 | info | Network thread connecting to 185.218.24.23:8099 for feed EDQG49
2019-07-09 17:53:21 | [feed][n]syncing stream: timeout
2019-07-09 18:10:46 | [feed][n]syncing stream: timeout
2019-07-09 19:53:33 | [feed][n]syncing stream: timeout
2019-07-09 19:53:33 | [feed][i]Feed disconnected
2019-07-09 19:53:33 | [feed][n]disconnected
2019-07-09 19:53:34 | info | [feed][n]waiting 13 seconds
2019-07-09 19:53:46 | [feed][n]connecting
2019-07-09 19:53:46 | [feed][n]connected via UDP (fd 15)
2019-07-09 19:53:46 | [feed][i]Feed connected
2019-07-09 19:53:47 | info | Network thread connecting to 185.218.24.24:8099 for feed EDQG49
2019-07-09 23:59:13 | [mlat][e]Received MLAT timestamp error: 59 seconds!

Note that this level of sync timeouts isn’t normal, there have been some more errors since the cloudflare outage a week ago.
(of course i don’t know what syncing stream does even mean but hey)

FR24 log contains a huge amount of such rubbish error messages. I used to be worried, but finally solved it in 3 phases over time:

  • phase 1: stopped caring for such entries
  • phase 2: stopped looking at logs altogather
  • phase 3: stopped logging by setting logmode=0 :smile:

With that nice systemd service modification the logmode setting doesn’t matter.

Anyway i’m not worried, more curious.
Sometimes MLAT works fine for a few days, then boom, error!
Maybe it’s some actual short periods where frame are dropped.
The FA MLAT system quickly resynchronizes and doesn’t care but maybe FR24 just raises a counter for every desynchronization.

But sadly it’s more likely it is the FR24 servers for MLAT in Europe.

Talking of “other feeds”, I also feed opensky-network. They also provide live internet based web interface, withou need for me to open any port in my router. I can also toggle on/off display of max range plot (button with spanner symbol → Ranges)

https://opensky-network.org/receiver-profile?s=10

https://opensky-network.org/receiver-profile?s=11