Other USB devices on the pi?
There is variation in chips 
I am booting / running the pi off a small (32GB) SSD drive which is plugged in via USB. So maybe thatâs the cause.
Try to use an SD card instead. It solved my problem here with M2. SSD in USB case.
Anyway, you do not need an SSD when your system works on ADS-B decoding.
The extra io processes on SSD will decrease the bandwidth between receiver and Pi (BW of USB is limited by the common controller)
2 Likes
When I was running a Pi I always used the largest microSD card it would take to spread out the wear on the card.
1 Like
I have an Airspy R2 with an RTLSDR LNA powered by bias -b option from the R2. Using an infrared thermometer, I measure the R2 temp at 122 F with ambient temp of 88 F. Antenna is at the attic high spot and decent coax down to the garage where the LNA, R2, and a Pi-400 are on a shelf in the garage. The system is only used for ADS-B tracking via a WiFi connection. Currently tracking around 63 planes with 275 messages per second.
The temp seems to be quite high. I do not have any heat sinks attached yet and wondering if others out there have a similar situation.
I use an external bias-t for the LNA powered from the 5v rail on the pi rather than the built in one. The rtlsdr LNA draws about 150mA from memory which is quite a bit more than the 50mA the airspy is rated for. I donât know if itâs likely to do any damage, but I decided that being the most expensive component in the receiver it was probably prudent to do so. I did use the internal bias-t for a short period when I initially set it up and it doesnât seem to have had any adverse effects however.
I use an airspy mini rather than the R2 and it does get warm, though not hot. It didnât have any trouble with the recent heatwave here where outside temps were 40C (104 F) and the loft temperature was significantly higher than that. I donât have a fan on the receiver, only the pi cpu.
1 Like
You did it well. The internal bias may work normally, but sometimes you need to cut off from the power then switch it on again. I did not want to torture it, so I use also an external bias (50 ohm/ upto 6 GHz) driven by a diy low noise dc stabilizer circuit. (forget the usual stepdown converters).
Of course I do not know your receiving circumstances, but 275 messages seem to be low.
Between 60-80 airplanes, usually I have about 18-20 messages/plane/sec.
( FA antenna + triple-filtered LNA (RTL) inserted close to the antenna + about 16m of H155 coax + Bias-T + sysmocom cavity filter + Airspy R2 )
I use also ferrite beads for additional filtering.
1 Like
When thinking about it, forgot for a bit as well that everything except Europe gets much lower message rates. (due to less / different ATC interrogation)
I should really add a âposition rate per ADS-B planeâ to graphs1090.
The EU would be much handicapped due to all the overlap we get with all the interrogation.
6 Likes
Now, we have only positions per sec on ADS-B Maxima⌠(here it looks a kinda limited around a highest of 150-156/sec)
âŚI thought that DF17/DF18 rate and number of detected planes can be a good indicator of receiving quality.
Handicap or not, agressive interrogation may cause overlapped transmissions much earlier than in an area far from EU. (far from EU, you can have better conditions to get all the transmitted DF17 packets)
We can pick any part of the existing dataflow for counting things, but: - how can we compare the quality of receivers (stations) working in different circumstances? Is there a way at all?
Itâs not really possible to compare receivers operating in different locations like that, because the conditions will vary so much between them. Not only will different traffic levels have an impact, but the nature of that traffic and its interaction with ground stations will also affect it. Even how the traffic is dispersed will have an effect due to aircraft proximity affecting the number of TCAS messages for example, so with the same number of aircraft, you might see different message rates depending on whether they are all arriving and departing a local airport, or spaced evenly across a 250nm circle at high altitude.
The best objective measure of receiver performance would be how many messages are decoded in a time period as a proportion of all those actually transmitted within that time period - even that is problematic. How do you determine which messages should have been decoded? There are external aspects which affect even that, like tropospheric ducting increasing range and bringing more aircraft into receiver range.
The only real answer is to use long term statistics to build a normal performance envelope which shows behaviour under a multitude of conditions. The effects of changes can be compared to that, and if the changes move the envelope one way or another you can say it had a positive or negative effect. Thatâs why I tend to use graphs like this one to see whatâs happening:
You can see that even that is quite noisy however, and it only applies to my receiver in my location. If I moved the same hardware elsewhere, Iâd expect different results.
2 Likes
You have created some wonderful graphs to help tune a system. Is there a thread here to implement these graphs. Beautiful!
Thank you for expressing your opinion.
The quality of the station can only be âmeasuredâ by the statistics of the decoding of data packets, the number of which is constant within a given period of time and does not change with, say, the interrogation rate. (sorry for my brutal English) The occurrence of DF17 can be considered almost constant, even if some airplanes can turn it off (mil)
If we look at the number of transmitted ADS-B messages all in one, we also get a false result. The probability of decoding DF17 packets in Europe is also made difficult by the significant overlaps and the GSM band close to 1090 MHz. So what is usually labeled as an advantage of the European region is actually a disadvantage⌠(I mean: high message rate)
So, quality of our station is really relative to itself, and depends on your own acceptance (tolerance) level.
1 Like
Thanks. Most of my stuff is in that repo, however itâs not particularly organised. If you want to create that graph in particular it is this script that will do it.
Note that you need to have graphs1090 installed and also switch on collection of the data files it uses. Edit /etc/default/graphs1090:
# enable data collection for caius scatter graphs
enable_scatter=yes
then restart the service.
That will generate a data file each night containing the previous days data - this is to preserve the resolution for older data as the rrds used by graphs1090 become less granular for longer durations.
1 Like
Currently running Airspy on a Raspberry 4 for testing purposes.
What i have seen is a difference in max. number of aircraft count:
On the Aircraft chart it shows 204 as max:
But the Airspy graphs reports 215 as highest aircraft count:
Also the average count differs.
Where does that difference come from? Different things?
What timeout did you give to airspy?
Thatâs right, itâs longer than 60 seconds
1 Like
Ehm - good question. I did not change this value. It is still at -t 90
I am thinking of replacing the 10m of h155 coax with a USB3 Active cable, do you think this will be ok with a Airspy Mini and a RTL-SDR Pre-amp on bias T ? The USB cable does have to connections for âadded powerâ on the Pi side if that helps , any advice would be appreciated.
Iâd guess it wonât work.
Also post the product youâre gonna use.
Put the preamp before the 10m of coax and youâll have a much better solution.
2 Likes