wondering what they do which impacts the message rate in the local web interface…
Their beast connection asks dump1090-fa to enable modeAC decoding.
As mentioned 
1 Like
Their script seem to be programmed badly.
It’s not possible to stop or restart the service. It always hangs on “Stoping RBFeeder…”
You hve to kill the process
This happened when we first set up a receiver at the MTG site but I genuinely can’t remember what fixed it.
I appreciate that’s not helpful.
That was doubling of messages because the airspy-conf didn’t exist and someone configured it so it would connect to dump1090-fa twice.
Unrelated to rbfeeder requesting modeAC decoding.
With an airspy that request has no effect as the airspy_adsb isn’t programmed to do ModeAC decoding and dump1090-fa can’t magically make modeAC messages appear when it only gets ModeS via network.
I thought you’d remember, thanks. It was so long ago that I really couldn’t think what it was.
quite an impressive number.
1 Like
I think in US only some military planes use that ModeC those days.
The planes that only have ModeC aren’t many at all indeed.
But some people like their mil planes even if it’s just a squawk apparently.
I suppose it could also be about collecting statistics.
Chinese and Russian “enthusiasts” would be my bet.
Aggregating intelligence data from multiple sources is a thing.
1 Like
I haven’t dug into it at all but my suspicion is that they’ve turned on the existing A/C support in mlat-client, which in turn requests A/C from dump1090. I built that infrastructure a while back when I was evaluating A/C mlat (came to much the same conclusion - it’s not hugely useful)
1 Like
Probably.
Wouldn’t hurt them either to use another debian package that’s not named mlat-client if they are gonna modify it that much …
Oh well.
Fun fact:
Installed the Opensky Feeder again. It started with the similar message rate than the local view.
But since a few hours the rate shown there is 300 msgs lower.
no idea what causes that. Restarting the impacting services or a full reboot of the device does not fix it.
They don’t use all messages anymore.
You basically updated their feed client.
2 Likes
Having the AirSquitter connected which is shown as “Radarcape”, the message rate matches again. Maybe because the are using a different method
I’d expect they are.
Due to the GPS timestamps they want all the data as they can do retroactive MLAT on that dataset.
Pretty good explanation. Thanks
My Problem is back, this time including showing the number in graphs1090
Situation:
For testing purposes i moved the Raspberry with the Airspy outdoor.
To have the second receiver back, i built it from scratch using a complete different Raspberry.
Connected is a blue FA Stick.
After the operating system i installed readsb and tar1090 using @wiedehopf automatic installer
Then i installed graphs1090
While accessing the web interface two things happened:
I see the whole traffic also from the outdoor receiver
The message rate is way too high again, up to 1600, which is impossible based on the used FA stick and the current amount of aircraft
I did not do something special, i only changed the feeder-id in Piaware but that shouldn’t have an impact
I tried to get it fixed by removing readsb and installing dump1090-fa, but it’s showing the same data.
Any idea why this is happening and where to start fixing it?
Extract from journalctl for dump1090:
- Subject: A start job for unit dump1090-fa.service has finished successfully
-- A start job for unit dump1090-fa.service has finished successfully.
Jun 07 13:35:25 Raspi3 dump1090-fa[602]: Mon Jun 7 13:35:25 2021 CEST dump1090-fa 5.0 starting up.
Jun 07 13:35:26 Raspi3 dump1090-fa[602]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000)
Jun 07 13:35:26 Raspi3 dump1090-fa[602]: Detached kernel driver
Jun 07 13:35:26 Raspi3 dump1090-fa[602]: Found Rafael Micro R820T tuner
Jun 07 13:35:26 Raspi3 dump1090-fa[602]: rtlsdr: enabling tuner AGC
Jun 07 13:35:26 Raspi3 dump1090-fa[602]: Allocating 4 zero-copy buffers
Jun 07 13:35:29 Raspi3 piaware[608]: ADS-B data program 'dump1090-fa' is listening on port 30005, so far so good
Jun 07 13:35:29 Raspi3 piaware[608]: Started faup1090 (pid 836) to connect to dump1090-fa
Jun 07 13:35:29 Raspi3 piaware[608]: piaware received a message from dump1090-fa!
Jun 07 13:36:00 Raspi3 piaware[608]: 219 msgs recv'd from dump1090-fa; 214 msgs sent to FlightAware
Forget about the gain, this has no impact
Thanks
Well let’s check if it’s modeac again
jq < /run/readsb/stats.json '.total.local'
Also is it the same message rate in the graphs?
I’m a bit confused …
Are you running readsb or dump1090-fa?
Glad we are two now
I installed readsb using your script. After i’ve seen that the message rate, the displayed aircraft and the graphs are showing a way too high number, i removed readsb and installed dump1090-fa
So far it went through, but the issue persist.
As also aircraft are shown which are not visible for the indoor receiver, it looks like the device is getting the additional feed from the outdoor receiver.
That would also explain the message rate which is around 1500 at the moment where the outdoor is showing 1000 and the indoor is normally having around 500 .
You’ve asked for the stats from readsb, but i can deliver only the stats for dump1090-fa:
{
"samples_processed": 1152253952,
"samples_dropped": 0,
"modeac": 0,
"modes": 12474151,
"bad": 3270435,
"unknown_icao": 9047093,
"accepted": [
150600,
6023
],
"signal": -6.4,
"noise": -20.4,
"peak_signal": -1,
"strong_signals": 17308
}
The two screens. To the left the receiver outdoor, on the right the indoor receiver.
It is physically not possible to see the aircraft in the south.
I have no clue how this was done. I installed the scripts for Piaware, Flightradar24 on top of readsb/dump1024.
The only thing i did is using existing feeder IDs
I suspected also the problem as discussed previously. But now no feeder service is running, only dump1090-fa without any feeder. I switched to dump1090-fa because the switch given by obj did not work for me on readsb
EDIT:
Graph also shows the high count. This is the one from the indoor receiver with FA stick. Just started new a few minutes ago after i disabled all services except dump1090, tar1090 and graphs1090
Also the messages > -3dBFS does not match. Gain is still at -10 (no change after install)