I’d doubt that very much.
Maybe he just restarted airspy_adsb one time too often.
They don’t detect the clock reset properly and time out the mlat client…
If you do that too often you get timed out for the day due to unstable.
2 Likes
One thing to bear in mind is that my heat map script uses the original signal strength values (those that show in dump1090), and not the new full range signal scale in graphs1090. That is because that data is not available in the aircraft.json file which is generated by dump1090.
I can’t change that unless prog or wiedehopf decide to add some equivalent that gives access to the full range per aircraft data.
1 Like
aircraft.json addition … unlikely 
But the current autogain iteration seems to keep 99% of signals int the range you can see just fine in the limited RSSI that’s a available via beast.
I don’t think it’s a problem. The heat maps weren’t intended to be accurate tools, more of a visualisation.
The heatmap script is useful and well done!
The heatmap can still show a difference with dynamic vs fixed gain. In my case autogain is optimizing mostly to make the weak signals stronger. So if I had saved a heatmap from a recent day running at lower gain, I’m pretty sure that the difference could be seen in the heatmap. Especially with stronger far away signals.
By hand I’ve been tweaking gain between 12 and 13. There are last nights graphs with RC12.
Many thanks for the work on this and to @wiedehopf too of course 
1 Like
Possibly. As the drum sticks have been hidden so far today, the RC12 MLAT figure today, so far is in front, 569 to 536. I must say, if I had to name one definite improvement since the drums started rolling, I would say it is MLAT. Before my MLAT figures rarely went above 10 in a day, since the serious tweaking has started, I have been in the 3 figure range with MLAT fairly regularly.
1 Like
MLAT is mostly GA aircraft, so it’s very very very weather and weekend dependant.
Well not sure how it’s in Australia … but that’s how it works in Europe.
And they work great (a week ago vs last 24 hours)
Avg RSSI change is visible, and also the impact of a bigger gain on distant plots.
3 Likes
The graphs look good so far.
here is my plots of the last 8 hours. I notice that there is a funny drop-out in the graphs at around 04:00. not sure what happened there, the logs doesn’t show anything. (seems as though the average gain settles on around 17 when there is traffic around. My optimal manual gain, based on comparing my Airspy station to my RTL-SDR station, was also 17)
Was there any traffic in the other receivers at that time?
That’s exactly what we want. Thanks for sharing.
Graphs of last 24 hours. RC12 from 16:10 Saturday.
Edit added comparison with reference station. Airspy showing clear improvement.
Thanks @prog @wiedehopf
ignore the comment about the dropout. I see the same on my other station, so I assume it was a network-issue. (happens quite a bit over here in the rural areas of Norway at night). Wish they would hurry up with fibre,
1 Like
Are the graphs not on the same system as the airspy?
I’d assume you just saw no signals at all in that time.
The RSSI and noise statistics you see are on DF17 messages.
So you won’t see a noise reading without messages.
Caius, is there somewhere a doc how to run your scatter-graphs with Readsb?
scatter-graphs builds on graphs1090, just enable the option in the graphs1090 config: GitHub - wiedehopf/graphs1090: Graphs for readsb / dump1090-fa / dump1090 (based on dump1090-tools by mutability)
His scatter-graph readme should mention that, no?
hmm apparently it doesn’t GitHub - caiusseverus/adsbcompare: Tools to plot and compare data gathered with graphs1090
@caius can you fix that 
To get you going hellhound, just do this
enable_scatter=yes
in
/etc/default/graphs1090
and restart graphs1090 service, that should be all you need to start collecting data.
1 Like
Sep 12 11:45:56 ADSB-pi4 airspy_adsb[5707]: CPU 93.2 %, target 88.0 %, adjusting preamble filter: 10 → 9
Sep 12 11:46:06 ADSB-pi4 airspy_adsb[5707]: CPU 82.6 %, target 88.0 %, adjusting preamble filter: 9 → 10
Sep 12 11:47:56 ADSB-pi4 airspy_adsb[5707]: CPU 93.1 %, target 88.0 %, adjusting preamble filter: 10 → 9
Sep 12 11:48:06 ADSB-pi4 airspy_adsb[5707]: CPU 82.3 %, target 88.0 %, adjusting preamble filter: 9 → 10
Sep 12 12:12:35 ADSB-pi4 airspy_adsb[5707]: No data from device for 15 seconds, exiting!
Sep 12 12:12:50 ADSB-pi4 airspy_adsb[5707]: FATAL: watchdog timed out, aborting process!
Sep 12 12:12:50 ADSB-pi4 systemd[1]: airspy_adsb.service: Main process exited, code=killed, status=6/ABRT
Sep 12 12:12:50 ADSB-pi4 systemd[1]: airspy_adsb.service: Failed with result ‘signal’.
Sep 12 12:13:05 ADSB-pi4 systemd[1]: airspy_adsb.service: Service RestartSec=15s expired, scheduling restart.
Sep 12 12:13:05 ADSB-pi4 systemd[1]: airspy_adsb.service: Scheduled restart job, restart counter is at 1.
Sep 12 12:13:05 ADSB-pi4 systemd[1]: Stopped Airspy ADS-B receiver.
Sep 12 12:13:05 ADSB-pi4 systemd[1]: Started Airspy ADS-B receiver.
Sep 12 12:13:05 ADSB-pi4 airspy_adsb[22467]: airspy_adsb v2.2-RC12
Sep 12 12:13:05 ADSB-pi4 airspy_adsb[22467]: Listening for beast clients on port 47787
Sep 12 12:13:05 ADSB-pi4 airspy_adsb[22467]: Acquired Airspy device with serial 26A464DC28164693
Sep 12 12:13:05 ADSB-pi4 airspy_adsb[22467]: Decoding started at 20 MSPS (Gain: auto; Preamble Filter: 8)
that is what is confusing to me. both my ADSB-stations, (different SDR’s and different Pi’s, different PSU’s, different antennas and pre-amps) show the same dropout. Havent noticed that before, but will keep a lookout. Maybe the Russians or NATO were playing around with an ECCM-system, or something weird, lol.
Yeah you’re having USB issues it seems.
watchdog did it’s job pretty well.
Note that no data from device doesn’t mean no aircraft.
It means you don’t get the raw data you ALWAYS get from the airspy, no matter the traffic (raw samples).
2 Likes