Okay I had to test somethings before I said you were right LOL 
and you usually are. No matter what I do with the other receiver plugged in for UAT it loses sync and actually my message rate drops quite a bit from the Airspy. Currently showing out of sync again due to my testing but I know itâs from me messing around. (now in sync with 214 receivers) For some reason and Iâm going with you with the soapy-sdr no matter what I do it causes a problem with the timing on the Airspy. I plugged them in the same USB, separate USB 2.0 and 3.0 ports, tried 12 and 20 sampling and nothing works. As soon as the Airspy is the only receiver connected it works fine even with the sample rate set to 20.
1 Like
Maybe itâs still the same USB chip which handles both ports.
Or the 5V on the USB ports drops if the second dongle is active.
(If you have a powered USB hub lying around it doesnât hurt to try plugging the 978 dongle in via that USB hub)
But that seems unlikely because USB 3.0 ports should be capable of 1A, so there should be enough power available.
Anyway if you switched the Airspy from a RPi to a Odroid you should have a spare RPi for 978 MHz 
1 Like
Okay well here is where it gets interesting. Knowing that @obj had posted in another message there were some improvements to the development version of dump978_fa I just cloned the development branch and installed it and no more issues. So the issue appears to be something in the release version of dump978_fa that is the root of all evil here. I have both dongles running, Airspy is running at a sample rate of 20 and all is great, great message rate and my test setup is synchronized with 207 nearby receivers.
I think for production I am going to do just that @wiedehopf and run the Airspy on the Odroid and UAT on the Pi and just run them as separate stations. It would appear to be the safest bet in the long run to avoid any future problems. My guess is for USB, itâs just too much data anyway you slice it.
Indeed, it was giving me grief. I now have the following configuration:
-v -f 1 -b -p -g 17 -m 12
When I put it to -m 20 it would stop operating. When I put the orange dongle on a powered USB hub, it was slightly better. It took a day before the airspy started to report lost samples using the command in the next post by @wiedehopf
Keep your eye on it. Maybe it was something in the release version that didnât agree with the N2 (which also has USB 3).
1 Like
sudo journalctl -e -u airspy_adsb
Thatâs the command you want to use to check for lost samples.
sysctemctl status only displays a very limited amount of log information if it does at all.
Anyway as written some posts above, in some cases lost samples are not reported when the problem is on the USB bus.
You were using 3.7.1?
The improvements he mentioned should be in that version.
I donât see any relevant changes in dump978-fa from 3.7.1 to dev.
Maybe installing a more recent soapy-sdr version can help.
Upgraded to Airspy mini and change Pi2 to pi3,
Nice improvement ,still some Sample lost waiting for Pi 3b+
1 Like
If you have a fan and a good power supply you can overclock the 3b.
Should run fine with 1300 instead of 1200 MHz.
But first try running sudo apt install rpi-update and sudo rpi-update to get the firmware and kernel to the most current one.
Then if you want to increase the clock, add these lines to /boot/config.txt
dwc_otg.fiq_fix_enable=0
force_turbo=1 #Voids Warranty!
boot_delay=1 #helps to avoid sdcard corruption when force_turbo is enabled.
arm_freq=1300
The dwc_otg line shouldnât matter but it doesnât hurt to use, nothing to do with overclocking.
The rest of the lines should be obvious
You can also try with the default maximum frequency (#arm_freq to comment it out, then default is used), just disabling the automatic frequency adjustments and locking to the max frequency can help with lost samples.
How did you set it up? Using multiple network connections with the airspy software increases CPU load and can cause loss of samples.
Thatâs why my scripts use dump1090-fa as a hub for distributing the beast messages.
Would have expected the whole affair to work without much problems on 12 MHz though.
The kernel is updated
4.19.42-v7+ to 4.19.46-v7+
I used your install script.
But creating Graphs is too much.,
Jun 6 18:53:01 ADSB CRON[1537]: (root) CMD (bash graphs1090.sh 1h >/dev/null 2>&1)
Jun 6 18:53:27 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:53:27 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:53:28 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:53:28 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:53:28 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:54:01 ADSB CRON[2359]: (root) CMD (bash graphs1090.sh 6h >/dev/null 2>&1)
Jun 6 18:54:04 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:54:04 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:54:04 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:54:05 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:54:05 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:54:05 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:54:05 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:54:05 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!
Jun 6 18:54:05 ADSB airspy_adsb[299]: /!\ Lost 131072 samples /!\
You installed my graphs correct?
Iâm sure you already removed the cron file for the adsb receiver project?
ls /etc/cron.d
Anyway the logs look like itâs my version. (was confused for a moment, iâve reduced the cron logging)
Good that you didnât
Open with an editor: /usr/share/graphs1090/graphs1090.sh
This is line 54:
pre="sleep 0.3"
Increase the 0.3 to 1.3, it will stretch out the graph creation, basically a small pause after each graph.
Not sure if it will help, some of the loss is smack between two graph creations.
Shouldnât take 30 seconds.
Can you also show the graph with the ADS-B CPU load and normal CPU load:
You are receiving quite a few messages with lots of aircraft around, that creates increased load.
Might also be a memory bottle neck, the 3B+ is a little faster in that regard.
Still wouldnât expect problems with 12 MHz 
You could try stopping the âtimelapseâ, it does use memory bandwith as well when doing the compression.
sudo systemctl stop timelapse1090
Basically if that CPU% goes over 90%, you are going to have lost samples no matter what because there will be spikes.
I wouldnât expect that much CPU with 12 MHz, but it seems to depend on noise and other factors.
You can try reducing the gain, that can have an effect as well.
With some cooling you can also increase the CPU frequency as described earlier.
Any experience with a Pi 3b and airspy mini? My maximum aircraft count during the day is around 250. At the moment I am using a blue fa stick and the message rate is around 1300.
I guess a pi do not have enough cpu or what you think?
You want a 3B+ rather than a 3B
Iâm not sure why bram has so much CPU usage with 12 MHz sample rate.
At 12 MHz it should be manageable on a RPi 3B but apparently it isnât for his setup.
So it might work, but i canât really be sure because for some people it seems to work, for some it doesnât.
There are some people with many aircraft in view for whom the 3B+ is working fine with the airspy mini: Building a new receiver, this is going in a prime location - Suggestions for receiver/preamp/filter please
But it seems there are those that have problems.
A remark: youâll need a LNA in addition to the airspy mini to make full use of it.
@bramjacobse Can you show the temperature graph and /boot/config.txt as well?
Maybe itâs throttling.
What kind of power supply are you using?
Iâm Using a Big USB Anker multie Port USB charger.
Flightaware antenna, Uptronic ceramic filtered Amp,
Jus tthinking maybe i got some kind of groundloop powering the filter/amp, i will have a go at bias-t the Amp with the airspyâŚ
Doesnât mean itâs really solid.
The RPi official power supply is probably better but with that CPU load it probably doesnât make a difference.
Iâm still wondering whether itâs using the full CPU frequency or maybe thermal throttling?
Or maybe you followed the guide on the airspy webpage and reduced the clock to 800 MHz?
I donât see any âUnder-voltage detectedâ Messages in logs
but here is something
pi@ADSB:~ $ vcgencmd measure_clock arm && vcgencmd measure_temp && vcgencmd get_throttled
frequency(45)=600000000
temp=56.9âC
throttled=0x50005
I will try other supply later todayâŚ
Thatâs 600 MHz.
And that throttling counter is 0 for me.
Iâve rigidly set the frequency though.
Definitely something off.
Shouldnât be throttling at 57C though, maybe it is though, i donât know.
Iâve also changed timelapse1090 to reduce performance impact.
Chunk size can now be configured and defaults to 90 instead of 360.
(Thatâs the number of json files combined for compression and transfer)
This can slightly increase website load time but that already takes some time and shouldnât really affect it negatively.
If you are really tight on performance chunk size can be further reduced.
Length of USB power cable was the problem, to much voltage drop.
vcgencmd measure_clock arm && vcgencmd measure_temp && vcgencmd get_throttled
frequency(45)=1200002000
temp=60.7âC
throttled=0x0
Interesting to know that the RPi throttles when faced with insufficient power.
This explains some of my observations about lost samples.