v1.51 → v1.52
Hah, looks like it’s RPi3 optimized 
RPi 3B+ 1400 MHz force_turbo=1 with active fan and plenty of supply voltage.
Running 20 MHz sample rate.
Check the throttling also.
root@pi: vcgencmd get_throttled
throttled=0x0
root@pi: vcgencmd measure_clock arm
frequency(45)=1400146000
root@pi: vcgencmd measure_temp
temp=30.6'C
Pretty sure i could overclock it a bit if need be 
@Nitr0 can you also check in your SBC what’s the clock frequency when running 1.52?
pi@raspberrypi:~ $ vcgencmd measure_clock arm
frequency(48)=2000478464
As discussed previously USB2 is too limited in bandwidth to use anything else besides the Airspy at 20 or 24 MHz.
The limitation is not processing power.
It would need a 2nd USB2 chip, which i’m pretty sure it doesn’t have.
I agree, however the board apparently has a separate lane for USB 3.0 and it’s USB 2.0 ports. We’ll see I guess. I don’t really trust some of the Chinese marketing schemes… Will find out the old fashioned way.
So you’ll be able to use real USB 3 devices besides the Airspy then most likely.
Other USB2 devices won’t care about the USB3 as they don’t speak it.
Plugging a USB2 device into a USB3 port will still go through it’s own chipset will it not? It wont make a USB2 device any faster of course, but if it goes through it’s own pipeline… We’ll see.
No it’s routed to the only chip on the board that’s USB2 capable.
You’d have to have non-connected USB controllers for 2 and 3 with the controller for 3 still being capable of 2.
But that’s not how it works, you get one controller chip that supports up to two USB 3 devices or 4 USB 2 devices with the USB 2 devices sharing the USB2 bandwidth.
Bias t output seems to have stopped working with version 1.52 and my Airspy mini.
Bias t is working when switched by ADSBSpy under windows so the mini is fine.
Running on an Odroid XU4
Edit:
OK It is a bit more fundamental.
glibc 2.28 is not available for Ubuntu 18.04.2 LTS which is what the Odroid is using.
So Version 1.52 will not work at all on the Odroid.
Gone back to version 1.37 which I had archived and all is working again.
Anyone with a link to a better version than 1.37 that works with the Odroid?
Version 1.52 here. It just dropped the Pi3B CPU usage at 91-95% (at the 1200MHz that I can’t change).
I had also installed the cpufrequtils that Nitr0 suggested and set the governor on performance, don’t know if that matters (I had it before in rc.local)
Well, no more MLAT drops!
CPU temp is at 73C, I had opened the box lid, still don’t have a fan to blow over the small heatsink.
LE: MLAT dropped again. I have approx 900 msg/sec now.
1 Like
Hmm wonder if this what caused my N2 issues. Now the version on that was about 12 hours ago, no at home now, seems to be still downloading to FA but couldn’t get the 1090 tar map up???
My tar map works just fine.
RPI4 / 24 MHz. 1.43 & 1.46 were 10-12% more ADSB CPU utilization. 1.47 and 1.52 (did not get a chance to try those in between) returned CPU usage back to the typical level.
I’ve been seeing lost samples in the log ever since 1.43, including 1.52. Never had lost samples noted in the log before 1.43 that I can remember. MLAT still working fine.
Mike
glibc 2.4 which is much earlier:
https://raw.githubusercontent.com/wiedehopf/airspy-conf/master/airspy_adsb-linux-arm.tgz
(compiled on stretch instead of buster)
@prog
Went to my attic to put a Raspbian Stretch sd-card into my Rpi to compile it for the old glibc with gcc6.
It’s literally 2 functions when compiling on buster, all others are still GLIBC2.4, excerpt from objdump -T airspy_adsb
00000000 DF *UND* 00000000 GLIBC_2.28 fcntl
00000000 DF *UND* 00000000 GLIBC_2.7 __isoc99_sscanf
Compiling on Stretch it’s all 2.4, that is hopefully old enough to work on everything.
(correction on Stretch it still has one function requiring 2.7:
00000000 DF *UND* 00000000 GLIBC_2.7 __isoc99_sscanf )
1 Like
The last decoder is really best. It’s still not allowing MLAT on my Pi 3B, but it took much longer to be kicked out.
In the graph below you can see where the -m 20 was switched on - where the sudden huge jump sin usage are. With the last version, it didn’t hit the “ceiling” but somehow lost samples. With -p 1.
Didn’t have time to fully look into it b4 going to work. Did push the N2 up to 24 when all these updates started yesterday. Went a bit burko, 100% cpu and not recording any thing for about 30 mins. Dropped it back to 20, back to normal.
N2 doesn’t work with 24 sadly, i’ve tried it extensively.
Luckily 20 MHz is almost as good