Hmm. Works fine @ 20 mhz w/o bitpacking for me too.
Oct 9 01:09:40 localhost piaware[3097]: mlat-client(3864): Server status: synchronized with 222 nearby receivers
Thanks for sharing that info. I’d been wanting to run 20 for some time.
Mike
1 Like
My best guess is that the Odroid N2 doesn’t have the best power supply for the USB ports.
Bitpacking is extra work for the core int he Airspy.
Not sure why exactly the sample rate seems to be there, but there are still gaps in the data coming over USB.
Oh well 20 MHz will have to be good enough for N2 users.
1 Like
Good 'nuff for me. If I had been at 20 Mhz all along I would have really wanted to try out 24 Mhz. But I’m going from 12 to 20 so I’m hoping to see a little improvement. It’s moving along just fine. The theory about USB power sounds plausible to me 
Mike
I spoke too soon. It worked for 20 minutes. Now clock is unstable again and MLAT down @ 20 mhz with no bitpacking.
Oct 9 01:24:40 localhost piaware[3097]: mlat-client(3864): Server status: clock unstable
Was good while it lasted ! I’m back to 12 Mhz and I’ll just chill without til such day when something changes.
Mike
Well, even if i’d normally avoid USB hubs, you can try one as it might provide the power required to power the Airspy.
Amusingly, transponder overheating at high message rates can actually be a problem!
I have an RPi4 as well with an Airspy R2 and can’t get reliable mlat over 12.
24 gives
Average speed 18.8332 MSPS Real
Well, i actually posted the wrong command for 24 MHz, that needs -p 1 for that program to enable bit packing.
Let’s try 20 MHz with and without packing. Note it should work without packing:
timeout -s INT 60 airspy_rx -r /dev/null -t 4 -a 20000000 -f 1090 -g 18 -p 1
timeout -s INT 60 airspy_rx -r /dev/null -t 4 -a 20000000 -f 1090 -g 18
Let’s also check if there are any obvious voltage or throttling issues:
sudo dmesg --ctime | grep voltage
vcgencmd get_throttled
Which power supply are you using?
Maybe you are able to measure the voltage on the USB ports while airspy_adsb is active?
Have you upgraded to the most recent kernel?
sudo apt update
sudo apt dist-upgrade
1 Like
Isn’t the -p option without any argument?
That depends on the application.
For airspy_rx it’s with the 1.
Ah… Confusing…
I think I overlooked your reasoning for turning off the bias T. I get it now. You want to see what happens if the bias-T power is turned off. If it works fine with the bias-T turned off, then there isn’t enough juice from the USB port to power both the Airspy and the amp.
I’m going to run some tests with the bias T off. the airspy_rx tests are perfect, bias T on or off. So the only tests I’m going to do are to run 24 mhz in my ADSB setup, with Bias T off, to see if I will have any clock issues. Of course, with the amp turned off, I’m pretty sure I’ll only get a couple of planes and there will not be any MLAT going on anyway because I won’t be detecting planes. So the test might not be conclusive. I’ll give it a try though.
Yeah that’s why i wanted the test with airspy_rx, but it seems full MSPS numbers doesn’t really mean it’s all working.
With airspy_adsb without bias-t it doesnt really make sense.
But you can get yourself this on ebay: Bias Tee Wideband 1mhz-3ghz for Ham Radio RTL SDR LNA Low Noise Amplifier 50vdc for sale online | eBay
Or try a powered USB hub.
So far I am having no issues with unstable clock reported. Then again, beccause i’m receiving about 15 planes without the amp on (vs 100+ with the amp on), I apparently also am not seeing anything [thus far] that requires me to participate in MLAT. Everything shows “green” in the Flightaware console. But if there is nothing to MLAT, then I’m never going to have an issue with MLAT failure and am never going to see a “clock unstable” notice in the logs.
I’m going to leave it run like this for an hour with the hope that it might find some MLAtable plane to deal with.
If I didn’t have an amp (with no power) inline, I’d be picking up more planes. But as you know, if you have an amp inline and it’s not powered, you’re going to see less than you would see without the amp inline at all.
I just remembrered though that I did buy one of those bias-T inserters that has its own power (wall wart) and which is also a splitter (providing two receive ports).
If I can’t find anything conclusive with this testing because MLAT is not needed, later on today I’ll attempt to find the bias-T inserter and put it inline to handle the powering of the amp and then will do some testing.
Mike
I tried a few days ago to use the Airspy connected to powered hub but it didn’t result in a synced MLAT at 24 MSPS on N2.
My default setup is at 20 MSPS with the bias tee turned on.
Yeah i’m aware, but not all power supplies even in the same production run are created equal.
Also the N2 could be slightly different in regards to delivering power to the USB ports.
The Airspy might be a little more demanding in regards to USB voltage.
I run my Airspy with a separate Bias-T for the LNA. I don’t like the idea of my expensive Airspy exposing 5V over the coax…
Hate to ask yet again, but hopefully changing my font color from clear will help this go around: Can someone please link any older airspy_adsb revisions, or are we stuck with this v1.40? Everything else is open source…
I wasn’t paying much attention to what you need. I have airspy_adsb 32-bit ARM binaries v 1.37, v1.38 and v1.40.
if you need one of those and you’re comfortable getting them from somebody you dont’ know, send an email to my username @gmail
Here is a single tgz file containing the three binaries, airspy_adsb_v137, airspy_adsb_v138, airspy_adsb_v140. Obviously if you use them you’ll want to rename them to airspy_adsb. These are 32-bit ARM versions that I had recently gotten from the Airspy.Com website.
I’ll remove the link tonight. If you want it, grab it. If not, no loss here.
https://airwaves.ovscan.com/fa
Mike
2 Likes
Awesome, thanks Mike! Much appreciated, I grabbed the tgz.