since the last update some graphs are not “flat” any longer but have some reoccuring spikes with the same time distance
The ADS-B CPU usage:
The CPU temperature:
Any idea where this comes from? Before that the lines did not show it.
The distance from spike to spike is approx 7-8 Minutes (looking on the 2 hour graph)
This is the important bit.
And that i had just changed something in the install script not long ago.
OK, i was just wondering because i did not see it that way in any of the previous versions.
how did you get your temperature that low? My device is meanwhile outdoor and it’s close to 0°C
But it still shows around 35-40° CPU temperature
https://www.amazon.de/F12-120-Standard-Gehäuselüfter-Standardgehäuse-Konfiguration/dp/B002KTVFTE
Runs great on 5V.
The Rpi is hanging by wires, so that also helps.
Thanks. will check it in spring, when it needs additional cooling.
Cold outside tonight, i covered the device a bit with some cork plate above and beneath, because i had concens regarding the low temperatures.
Min temp was 37°C
But this goes beyond this thread 
Maybe somebody can split the topic?
An RPi should work down to 0°C per the chip specs.
Environmental temperature or CPU temperature?
What you’re referring to is the LAN-Chip, the SoC is able to cover lower temperatures.
tonight we had -3°C
But back to topic:
How do i read the chart regarding the ADS-B tracks seen and the number of tracks with single messages? Is it bad if this number is high, and is there something i can do to reduce it?
The red area isn’t large at all and that is what represents the number.
Stacked graph.
If you had the green from 0 to 100 and the red from 100 to 200, you would have the same value for both “track types”.
It’s showing tracks per hour, so it’s really the rate at which you are detecting new aircraft. This includes aircraft that were in range but disappeared for longer than 60s (I think that is the time out) eg flying into a blind spot behind terrain or landing then taking off again.
Single message tracks are those that appear in range but only one message is received from them. This is something that is highly unlikely for a real aircraft to do - just briefly be in range for one message, so it’s a good indicator of how many bad decodes you are getting. Random errors are much more likely to only happen once.
Some random errors are to be expected given the nature of the signal, but in your graph you don’t have many. Increasing the w setting on the airspy decoder will reduce this, as it increases the number of valid messages from an aircraft required before accepting it as real.
I’m running with it set at 5 at the moment and see almost no single message tracks.
It’s 5 minutes.
60 second timeout is for planes you only received one message from, those are then counted as the single tracks.
The stats output all tracks and single tracks.
The current graphs version subtracts single tracks from all tracks to get both types, multi message tracks and single message tracks.
They are then plotted stacked.
Thanks, then i am good with it.
You have more bogus messages (red) than real ones (green). What do you think?
We don’t know your system - receiver type, LNA or no…
Reduce the gain one more step would be a start. Maybe adding a filter would help too.
good… I can not find the link (commands) to find check / or set the rtlsdr-gain
can you point me to a link ?
