Is the CPU target “-C 60” for the ADS-B CPU in the airspy mini or the pi CPU? If I look it graphs1090 with that option set at 60 is still shows my airspy ADS-B cpu running up to 90% or higher depending on the other options I select. I assume graphs1090 is showing me the usage out of 100% and not as a percentage of the limit I set?
Is there a maximum ADS-B CPU usage I should be aiming for?
I am seeing an interesting behavior with message counts after a change to NET= in the airspy_adsb config file.
I am running 2.2-RC30-test successfully for several months now. I have this installed on a Piaware image. Running the latest 7.1 of Piaware.
I was looking at the contents of airspy_adsb.default and noticed that the default for NET= is not what I had configured.
I had NET= -l 47787:beast
Where the default is NET= -l 47787:beast -c 127.0.0.1:30004:beast
So I added the -c argument to my config and restarted airspy_adsb and immediately noticed two things.
Without the -c argument, I would see this in the log file after a restart of airspy_adsb.
Feb 08 15:17:02 airspy airspy_adsb[340]: Client connected from 127.0.0.1:45508 (beast)
Feb 08 15:17:02 airspy airspy_adsb[340]: Client disconnected 127.0.0.1:45508 (beast)
Feb 08 15:18:20 airspy airspy_adsb[340]: Client connected from 127.0.0.1:45532 (beast)
With the -c argument, the logs show this after a restart.
Feb 11 09:40:21 airspy airspy_adsb[15946]: Push client connected to 127.0.0.1:30004 (beast)
Feb 11 09:41:20 airspy airspy_adsb[15946]: Client connected from 127.0.0.1:54460 (beast)
And that looks reasonable.
However, on the tar1090 side panel, I immediately noticed that my message rate jumped to almost double the msg/s rate before the change. With about 150 aircraft seen, the message state is close to 1200 msg/s whereas before it was closer to 600 msg/s. Please note that the number of aircraft did not double.
Also in graphs1090, in the ADS-B Message Rate Graph and ADS-B Maxima, I see a corresponding jump in message rate. But, Aircraft Seen/ tracked, ADS-B Message Rate / AC and DF counts see no indication of “data doubling”.
So my question is this. Are the ~1200 msg/s rates I am seeing in tar1090 and the ADS-B Message Rate and ADS-B Maxima Graphs in graphs1090 with 150 aircraft accurate message rates at the higher value or has the default NET= setting resulting in reporting a doubling of messages? And if it is a doubling message, should the default for NET= really be NET= -l 47787:beast -c 127.0.0.1:30004:beast?
Inquiring minds would like to know.
That particular graph shows CPU in relation to a single core.
You’re likely limited to -E 20 …
What default?
If you use the my script install and it works, why are you messing with it? 
The script removes that for a reason.
If you look at the piaware config or show all the TCP connections on your system, you can figure out how it’s doubling the messages.
Hi,
I always upgraded/updated the decoder, the PiAware pack and also the Pi OS as soon they were available - still, I have the “-c” part in the config file, so it WAS NOT deleted by the update process.
(anyway, numbers of received messages seem to be normal…)
The latest “test” version of the decoder is in use here / Bullseye / PiAware 7.1…
It might make some difference that it is not a piaware image, it is based on a clean Pi installation + manual additions
Yes it does make a difference.
The piaware image you can’t just stuff data into port 30004 as you can’t make dump1090-fa just run without a data source, thus piaware is configured into relay mode which then connects to the listen port.
Adding the connect back means you’re doubling data.
Thanks. You didn’t have to be a jerk in the way you answered
Thanks. Now it is clear, I think.
Depending on your initial configuration, relaying method is available in different ways - so, mixing the methods will duplicate the outgoing messages.
He also didn’t have to answer. Given that he wrote the script, and you are arguing with him about how it works, what response were you expecting? Would you rather have a correct answer, with an ‘attitude’ that you don’t like? Or no answer to your question at all?
No need to defend me.
I sometimes answer with attitude … not proud of it.
The DF counts come from airspy_adsb directly i believe, so they wouldn’t double.
The number of aircraft doesn’t change if you get more messages for each aircraft.
The message rate per plane should double … it usually does so not sure if this was just an error.
The rest has been answered i think.
Push client pushes data into dump1090-fa.
beast-splitter due do piaware sd-card config options connects and pushes data into dump1090-fa.
The script modifying the default config is a bit intransparent to the user.
Have a nice day.
Neah, I found out that kids those days are very easy to offend. Anything that is not in line with their expected answer triggers them. My personal opinion is because they spend too much time in virtual echo chambers.
Sometimes… yes
But after a longer period of time, everyone should know that and be able to deal with it (or simply ignore it as easiest solution)
Nobody is perfect.
wiedehopf - Thank you for your follow-up answer and the detailed explanation. That takes character to do that and it has earned my respect.
Finally got my airspy mini today. Significant increase in number of messages/second and a small increase in number of aircraft. There has been an increase in range in certain directions, up to 300nm in the southwest as opposed to ~250nm with the RTL-SDR
I messed around with the settings a little bit, but I put everything back to the default values and let it run for a bit. It’s going to take a while to comb through this massive thread and figure out what everything does. I did turn on the bias t so my RTL-SDR blog LNA would get power.
Assumptions from what I’ve read so far:
Auto gain seems to work well with airspy_adsb? Not sure if I should should mess with it.
20 MSPS isn’t really necessary with the relatively low amount of aircraft in my area.
The -e preamble setting should be tuned, have no idea what it actually does so I will have to read up on that.
Two hours of graphs + map:
Small update: Broke 1 million positions/day on flightaware! And that’s on a Wednesday which is typically less busy. I don’t think I ever saw more than 850k, and that was on a super busy day.
Have messed around with settings a little bit:
-Set gain to 18
-Sample rate to 20
-Removed the -E(max preamble) setting
-Set -C to 95
-Set -P to 6 since I was getting some erroneous altitude readings
Pi was staying below 55C(using a heatsink case with upgraded thermal pads), but I added a small fan(Nidec 25mm) and temps are now closer to 45C. I’m running the fan using the 3.3v header to keep the noise down.
Pretty happy so far, will need to see how it goes over the weekend.
I am using my Airspy setup now for a couple of days
Has anyone seen an up and down in message rate over a short period of time?
I did not change anything, it is simply running without beeing touched
Or can this be the normal deviation?
Some interrogation rate shenanigans or something?
It’s not only your station though.
The position rate drop is kinda curious as the position rate should stay the same.
I had some correlation with the aircraft count at least:
Not curious enough to investigate it further … also not sure what to do.
I suppose checking DF counts:
I suppose it could be a signifcant uptick in ModeC messages overlapping with the other messages making us not receive them.
Logging ModeC message count might be interesting for that purpose but i don’t think i’m curious enough. (you’d need to use rtl-sdr as airspy doesn’t do ModeC)
The last few days I’ve been seeing fluctuating message rates:
It seems to be present in other receivers nearby, so I assume there’s something going on with ground interrogations as there aren’t any corresponding fluctuations in range, number of aircraft of signal strength.
Thanks for reply. I’ve checked my AirSquitter.
Cannot be compared directly as i do not have graphs1090 running there, but you’re right, the up/down is visible there as we…
I was just curious
