To be honest that’s how I run mine - did find that FA did drop my link at times for no reason using 30005 etc 
Rock steady using dump-fa 
1 Like
You had problems with beast-splitter?
Yep, followed your post and worked but kept getting kicked out and the system had to keep keep rejoining - so went back to my original settings.
Your advice on auto restart vice RC.local I was using works like a champ
When you followed the howto it wasn’t using beast-splitter.
I’ve since modifed my install script to use beast-splitter, maybe i’ll update the howto as well 
Right now i’m running on 1250 MHz on the RPi 3B+ to simulate a RPi 3B.
Using the normal cpu clock of 1400 MHz my 3B+ was doing -m 20 just fine after i gave the pi some more voltage.
Anyway i’ll have to wait for tomorrow, maybe it’s the message rate that affects the performance.
You don’t need sudo for reading the log but it does not harm much. I get this output:
Jan 24 23:20:08 piaware airspy_adsb[5330]: Decoding started at 20 MSPS
Jan 24 23:20:10 piaware airspy_adsb[5330]: Client connected from 127.0.0.1:58450 (beast)
Jan 24 23:20:20 piaware airspy_adsb[5330]: Push client connected to localhost:30104 (beast)
Jan 24 23:20:39 piaware airspy_adsb[5330]: Client connected from 127.0.0.1:58456 (beast)
How would a lost package look like?
Like this
Jan 24 23:06:14 pi airspy_adsb[297]: Acquired Airspy device with serial 26A464DC287C2593
Jan 24 23:06:14 pi airspy_adsb[297]: Decoding started at 20 MSPS
Jan 24 23:06:15 pi airspy_adsb[297]: /!\ Lost 131072 samples /!\
Jan 24 23:06:15 pi airspy_adsb[297]: /!\ Lost 131072 samples /!\
Jan 24 23:06:15 pi airspy_adsb[297]: /!\ Lost 131072 samples /!\
Jan 24 23:06:15 pi airspy_adsb[297]: /!\ Lost 524288 samples /!\
Jan 24 23:06:15 pi airspy_adsb[297]: /!\ Lost 393216 samples /!\
Jan 24 23:06:15 pi airspy_adsb[297]: /!\ Lost 131072 samples /!\
Jan 24 23:06:15 pi airspy_adsb[297]: /!\ Lost 131072 samples /!\
Jan 24 23:06:15 pi airspy_adsb[297]: /!\ Lost 393216 samples /!\
Jan 24 23:06:15 pi airspy_adsb[297]: Client connected from 127.0.0.1:38414 (beast)
But that was only on startup, it’s been running fine since.
Note that i’m actually clocking down right now to check out the bottlenecks.
I’ll be joining the testing when I get back home.
Last two weeks I was back home in România.
Well it seems like it is dependant on the Message rate. But using beast-splitter instead of connecting multiple feeder directly to airspy_adsb seems to help.
I was running 1250 MHz over night (the RPi 3B is 1200 MHz) and it worked all night
Jan 24 23:06:15 pi airspy_adsb[297]: /!\ Lost 393216 samples /!\
Jan 24 23:06:15 pi airspy_adsb[297]: Client connected from 127.0.0.1:38414 (beast)
Jan 25 07:40:43 pi airspy_adsb[297]: /!\ Lost 131072 samples /!\
But then the European morning rush hit and around 1400 Messages/s it started losing samples again. Not too bad though. Turned it up to 1300 MHz now but i’m sure with less Messages/s and using beast-splitter it should run fine with -m 20.
(Disregard the dips in the message rate, that’s just reboots and changing dump1090-fa settings)
So if you want @retman1222 you can run the install script again and it will change your configuration to using beast splitter.
You will need to change the gain and sample rate in the airspy config file again, it get’s overwritten.
Pretty confident it could run quite stable now for your message rate even on the 3B.
(I presume you didn’t touch /boot/config.txt in regards to frequencies yet, because the frequency of 1000 i wrote some time ago is not gonna cut it, the default settings might just work though)
Don’t know about a possible message rate increase in the summer though, you might just want to stay with -m12 for now.
Maybe i can take a look at the source of airspy_adsb itself and improve the work distribution between the threads, i get the feeling there are yet things to improve in that regard.
1 Like
hello widedhopf, i will re install the script next week and advise. you are correct i didn’t touch /boot/config.txt. when you re did the script did you change frequency from 1000 to 1200?
My scripts won’t touch your frequency settings in /boot/config.txt 
If you want to just make the pi permanently run at the current maximum speed, which should not be a problem with a fan, you can just add the following two lines to /boot/config.txt
force_turbo=1
boot_delay=1
On a 3B that will mean a frequency of 1200
On my 3B+ that means a frequency of 1400.
Anyway i’m getting 1700 messages per second at times which means it will drop a few samples.
I’m probably going back to -m12 for now. (Or i might overclock the Pi to 1450 and see if it stays stable)
ok, great re changes to RPI 3B…i just did a comparison of older (v3) data to the 60nm away ref site. comparing this data to the mini gives me about a 9.3% increase in aircraft and a 15% increase in positions (the larger percentage difference that navzptc is seeing (building a new receiver, this is going in a prime location…) is well explained by him.
Regarding the -x option (dx mode), it seems to introduce bogus messages somehow.
I was very confused when i looked at the number of tracks in the dump1090 graphs / stats:
That is dx mode with 20 MHz sample rate, then at 14:15 dx mode with 13 MHz sample rate, and then after 14:45 approximately dx mode is off. Sample rate doesn’t seam to matter much when dx mode is off at least in connection with these strange tracks.
The number of tracks after switching it off fits with what i had with my rtl-sdr v3 dongle.
Actually it also uses 7% of one core just sitting around. And it’s annoyingly slow detecting for example airspy_adsb being restarted.
I’ll change to using dump1090-fa.
1 Like
I did arrived home and tried the -m 20 (instead of the default -m 12).
The CPU usage went up a few % (like 15%), but this is with only 600 messages/sec (it can go up to double of that). Note that one core gets pegged to 100% and the rest of the load goes to other cores.
You will likely be losing samples with that cpu load of the main thread reducing the number of your MLAT hits.
If you want to check for lost samples you can add -v to the options of airspy_adsb and redirect its text output to a file by adding &> /tmp/airspy.log at the very end of the command line you use to start airspy. (But it needs to be before the & you use it to send it to the background i believe let me check Edit: yes the single & you already have needs to be even behind these shenanigans :))
Then you can check that log with cat /tmp/airspy.log
In my config.txt I had also a line that overclock the base frequency from 700 to 800MHz:
#uncomment to overclock the arm. 700 MHz is the default.
arm_freq=800
700 is only the default for old Raspberry Pis
Which one do you use?
I did un-comment the 800MHz like above, also added the Turbo…
But, I am confused, don’t know what freq I actually have:
pi@pi_3:~ $ lscpu
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Model: 4
Model name: ARMv7 Processor rev 4 (v7l)
CPU max MHz: 800.0000
CPU min MHz: 800.0000
BogoMIPS: 38.40
Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
800 is just the default frequency of your Pi.
the turbo just disables the dynamic frequency it usually uses (when the CPU is at less than full load it clocks down, not sure if it still throttles if it gets too hot, that might also be disabled i don’t know)
Those settings where posted also on airspy website, so I had them already:
Additionally, we recommend to put these lines in /etc/rc.local :
# /!\ RPi3 Only! /!\ echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governorThen append these lines to /boot/config.txt :
# /!\ RPi3 Only! /!\ force_turbo=1 arm_freq=800