ldd (Debian GLIBC 2.36-9+rpt2+deb12u7) 2.36
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
2.36
Oh seems i only updated the update-binary.sh and not the install.sh.
Just run the update as stated here and you’ll have the bookworm version: https://github.com/wiedehopf/airspy-conf?tab=readme-ov-file#update
Edit: install.sh fixed as well.
1 Like
MLAT no sync on FlightAware with AirSpy R2
I wonder if anyone can help me understand why FlightAware MLAT fails to sync with an unstable clock but all my other MLAT clients are working fine?
I had a perfect sync with my FlightAware Pro stick, so my set up in general was ok but I decided to make use of the R2. Anyway the important point being MLAT works for 360radar and adsb exchange but not for FlightAware. I am using the airspy default install with sample rate of 12.
Any help thankfully received, Mike.
Any other usb devices connected?
FA will say ‘clock unstable’ sometimes just for restarting the decoder if it’s indirectly connected.
In that case, no touching and wait 
Make sure the location is good on the stats page: https://www.flightaware.com/adsb/stats/user/mikey1963
Location Set: November 4, 2024 3:22 PM
Location Source: Receiver
Think this location source receiver thing is a bug with FA.
But maybe it’s not, it should say “user entered”.
Well I have waited over 24 hours and it doesn’t recover at all. I know normally if I reboot I might have to wait say 10 mins but never over 24 hours. I have the r2 plugged into a powered usb hub to ensure it has sufficient power and no bias tee selected.
Other USB devices being connected is not really about USB power.
Which pi is this?
It’s a pi4, I have a usb gps connected to the standard usb and usb3 stick which is the main disk into usb 3. The r2 is connected to the usb3 powered hub which is connected into the other USB3
Yeah, USB storage and MLAT don’t work well together (at least on rpi).
Ditch it.
I’d also recomending ditching the USB GPS because really there is no point.
But that should be less of an issue.
Most likely you’ll have bad_sync int he adsbexchange-mlat log as well.
Or it’s the USB GPS providing a bad location to FA.
Manually setting it is just a better approach.
Ok, thanks will give that a go, it was all working fine before tho so why does putting the R2 in make a difference?
airspy is more USB bandwidth, about 6x that of an rtl-sdr running at 2.4 MSPS.
Really i don’t know, USB on the raspberry pi has many issues.
It’s much worse on the pi3 though.
If you want to try something new on a fresh sd-card without changing the current setup, give https://adsb.im a try.
Great stuff, thanks looks interesting I’ll give it a go
I did a test on a microSD card Pi4 a while back and found the R2 preformed more reliably on the Black USB2 connections and poorer on the Blue USB3 connections. Might be helpful. I also learned Flightaware software does not use GPS interfaces for locations. The R2/Pi4 systems appreciate working on the KISS principal, Keep It Simple… The microSD cards may be slower than an attached SSD, but the simpler you have your system, the more reliable the overall results are. Perhaps test some options with and without the various parts and let us all know the results.
About running with an R2 SDR. The code to support the 12, 20 and 24 MHz sampling speeds is much more complex than code for the rest of the SDRs using 2.4 MHz sampling rates. With an E value of 60, a Pi4 can easily use a bit more than 200% on the ADSB charts. Hope you have installed Wiedehopf’s Graph1090 program. That makes managing and improving your systems much easier. Almost instant feedback on tweaks and changes. Have fun.
1 Like
Seems that adsb.im no longer links to a raspberry pi image. Shame.
Just a bug with the build process.
Will be there in a bit.
Should be fixed now.
1 Like
Set up my Airspy on a Raspberry 4 at a different location. Better than collecting dust in the cupboard
Any suggestions for improvement?
Settings in conf:
#gain is 0 to 21, each step of gain is equivalent to about 3dB, so reduce in increments of 1 if 21 is too high
GAIN= auto
#other options, append or remove from the line starting with OPTIONS=
OPTIONS= -v -t 120 -e 60 -f 1 -w 5 -P 8 -C 60 -E 60
And these are the graphs for the first few hours:
Overall CPU is hovering around 35%, it’s a dedicated feeder, nothing else is running on it.
Thanks
You may take a chance on rising the sample rate to 20, if your sdr is an R2 or mini with added heat sink.
Yes, that’s i considered, but the Mini is not equipped with a heat sink.
I had it running in the past for a few days but without significant improvement. That’s why i disabled it again.
For what it’s worth my mini has been running at 20MHz without any additional heatsink for 5 years with no issues, and that’s in a loft space which can get pretty hot in the summer.
There is less advantage in running 20MHz in countries like the US which have lower message rates, so it’s not really an issue either way.
1 Like
I am located in Europe, message rates are up to 2200 depending on the time of the day.
A while ago i’ve been running the Mini with 20 MHz but the charts did not show a significant improvement. So i decided to stick to 12 MHz
1 Like