Dump1090 - Message rate too high in Skyaware

FlightAware ADS-B Flight Tracking
1

Since today i have the phenomenom that dump1090-fa is showing twice the amount of messages / second.

This screenshot shows both of my receivers side by side:
The upper one is my outoor receiver showing 513 Msg/sec
The lower one is indoor and the one showing wrong numbers. With half the number of aircraft it should be around half of the other rate as well

Earlier today i had numbers up to 1500/msg which is impossible and never seen before, especially not on my indoor receiver

In addition graphs1090 show the correct values in the message rate graphs
The problem is not in Skyaware only, it’s also on the alternative interface tar1090

Rebooting the device or restarting the service did not change it back to normal

image
image540Ă—546 80.9 KB

Any ideas or solutions?

EDIT:
Just two more ADS-B aircraft fires the rate to almost 800 which is higher than the 700 on my outdoor device with 38 aircraft:

image

And the graphs for the last minutes:

image
image375Ă—733 19 KB

2

All screenshots are from tar1090.

Sounds like you enabled --mode-ac maybe?

Not sure how graphs1090 will handle that … yeah i think it would ignore the mode a/c while the webinterfaces would display it.

1 Like
3

Yes the screenshots are from tar1090, but the issue is shown also in Skyaware. Two screenshots with less than two minutes in between:

image

image

Is this --mode-ac a setting of dump1090?
I cannot remember changing anything by myself, it was simply there.

This is the dump config file. Did normally not change anything except gain:

# dump1090-fa won't automatically start unless ENABLED=yes
ENABLED=yes

RECEIVER_OPTIONS="--device-index 0 --gain 48.0 --ppm 0"
DECODER_OPTIONS="--max-range 360 --fix"
NET_OPTIONS="--net --net-heartbeat 60 --net-ro-size 1300 --net-ro-interval 0.2 --net-ri-port 0 --net-ro-port 30002 --net-sbs-port $
JSON_OPTIONS="--json-location-accuracy 1"

# Use a machine-specific wisdom file if it exists
if [ -f /etc/dump1090-fa/wisdom.local ]
then
  RECEIVER_OPTIONS="${RECEIVER_OPTIONS} --wisdom /etc/dump1090-fa/wisdom.local"
fi

EDIT: Just realized that the the values fluctuate very strong. Just another screenshot.
Similar aircraft, but now > 1100 messages.

image

EDIT2
Not too bad for a blue FA stick with 24 aircraft only :rofl:
image

4

If i’m not mistaken it can also be activated by network connections, not sure though.

Let’s just check the stats.json …

jq < /run/dump1090-fa/stats.json '.total.local'
5

Thanks, here we go:

{
  "samples_processed": 4608229376,
  "samples_dropped": 0,
  "modeac": 600290,
  "modes": 37354120,
  "bad": 10082486,
  "unknown_icao": 26923915,
  "accepted": [
    338782,
    8937
  ],
  "signal": -18.9,
  "noise": -35.7,
  "peak_signal": -3.1,
  "strong_signals": 0
}

At the time i’ve taken the file, the message rate of 260 with 10 ADS-B aircraft

6

That’s mode-ac and mode-s, so mode-ac is indeed on.
As i said … was pretty sure this was the case.

How you managed to enable it, i don’t know but you very likely did something …
Did you restart the dump1090-fa service?

As i said it can either be on the command line, check that like this just to make sure

pgrep dump109-fa

As for network connections, you’d have to know what connects to dump1090-fa using a beast connection.

1 Like
7

Hi,

that’s really strange.
Nope, i did not enable anything, at least nothing i remember. But honestly i don’t remember by when it was shown this way. I just have seen it yesterday. I am not checking this every day

I needed to stop and start dump1090-fa for testing purposes.
Feeding is enabled to Flightaware, Flightradar24 and Radarbox (all three including MLAT)

using the pgrep command only shows the process number
i’ve checked it more detailed with htop. The process runs, having two subprocesses with same name and same command line.

In addition “dump1090” is used/adressed by two MLAT clients (FA and RB) and in the commandline three processes from tar1090. Frequently there’s dump1090 mentioned by the graphs processes

That’s the filtered view while searching for dump1090, highlighted is the process number shown by your command above

image
image1333Ă—244 68.4 KB

8

Hi,

I noted high message rate after i did apt-get upgrade and Radarbox client was updated

9

Funny

after i did the screenshot above i went back and stopped all feeding services one after each other.
The RBFeeder (Radarbox) did not stop, so i needed to kill the process.
Once it was off, the message rate went down to a normal value.

Launching all feeders again and the rate went up again once the RBFeeder was started again.

I will try to reinstall the RBFeeder, checking if it fixes the issue.

10

Done

Result is the same. Message rate goes up once the process starts.
But on the new installed Raspberry where the Airsquitter will be mounted there is also RBFeeder running, but without that impact.

The only difference is that there dump1090-fa is not running but readsb provided by wiedehopfs script.

Weird

11

It sounds like the updated rbfeeder is requesting A/C data.

You can pass --no-modeac-auto to dump1090-fa to tell it not to turn on A/C decoding when requested by a network client.

1 Like
12

My readsb doesn’t respect requests to enable modeAC via the network (unless you explicitely enable that automation via command line, i’ve changed that in comparison to dump1090-fa).
So different conditions.

From that observation it sounds like radarbox is requesting ModeAC via the beast connection.
Well that’ll be fun … whyever they are messing with that, not my issue.

1 Like
13

Just tried to change the setting in rbfeeder.ini from
mode=beast to mode=raw

But that doesn’t make a difference.

Just changed it in dump1090 config, restarted the service and the high message rate is gone. Perfect, thanks

That’s the reason why it is shown only on one device

Yes, nothing on your end. Honestly i never expected it, so thanks for trying to figure it out.
Will create an entry in RB Forum, but i have doubts if this will be even read :slight_smile:

Thanks for your help!

1 Like
14

In the past I contacted them directly (support@radarbox24.com) and have to say that Anthony replied within a few hours. You could give it a try.

15

Please forgive my ignorance but is it a bad thing to have --mode-ac enabled?

I looked at my piaware-config.txt and shows:

// Should PiAware enable reception of Mode A/C messages when requested?
// You may need to disable this if processing Mode A/C overloads your receiver.
allow-modeac yes

I don’t remember enabling this when I built this receiver back in January.
I also noted an increase recently in messages that coincides with the latest Rabarbox update.

If I set allow-modeac to no my message count goes down but the receiver does not seem to be overloaded with it enabled.

16

Nothing to say sorry about :slight_smile:

I did not recognize any change since the update of the Radarbox feeder. The only location where i realized it was the message rate in the web interface (Skyaware).

It was nowhere else. Not in the graphs, not in any other feeder which provides a message rate and not on any of the feeding sites.

17

Besides the bogus message rate no issue unless you’re short on CPU.
Not sure how much extra CPU it takes, i suppose not much.

18

Just tried to identified the moment i disabled it.

The ADS-B CPU usage went down by 4% in average, the overall CPU usage was not noticable

19

Cool thanks.
Could Radarbox be using it for something legitimate or was it an inadvertent change?

20

Probably they want to do something with the data … what though no clue.
You can attempt some basic location as in MLAT … but you still only know the squawk and not a unique id as it is with ModeS.
If they pull it off modifying the mlat-client / server to do ModeC mlat … well done … but i personally don’t find it useful at all.
Really not sure what they do though, ask them :stuck_out_tongue: