piaware-config receiver-type relay
piaware-config receiver-host localhost
piaware-config receiver-port 47787
that’s what the setup script does.
You can connect directly to airspy_adsb on port 47787 if you want.
At some point it was using significant CPU per extra connection but that’s been corrected.
Hello my friends:
Using an Airspy Mini and the script.
All is fine.
With rtl-sdr i used the gain optimization script.
Do we have an Airspy version?
I am using an rtl-sdr.com triple filtered LNA.
With rtl-sdr i was using a gain of 25.4db.
Thank’s a lot.
I don’t think that script is particularly useful, but i suppose it gets you somewhere in the ballpark.
No there is no script like that.
Tweak it so the weakest signals you get are around -30 dBFS and you should be fine.
A lot of thank’s.
I must use a gain of 13 to have the the weakest signals around -30 dBFS
Try the highest -e value you can with ADS-B CPU utilization below 95%. That, or increasing Sample_Rate will impact the graphed signal range as well.
Read through these threads. Airspy is different in terms of gain and signal range for most. In my case, surrounded by trees on 3 sides, it took me a lot of testing to realize I get the most planes and messages with a rather high gain and narrower average signal high/low range than I was used to from my non-Airspy experience. With the FA Blue stick plus I had best results with a low-ish total gain, with or without LNA/prefilter.
A lot of thank’s.
I will work with it.
You can have a look at:
http://casa.meteoelche.es:8089/tar1090/
and
http://casa.meteoelche.es:8089/graphs1090/
Thank’s
Give it some time. Optimize for ADS-B tracking (gain, e-value) and see if that helps catch MLAT.
In my case I had problems getting MLAT with sample_rate of 20 MHz. I stuck with 12 MHz and high -e value since that seemed to produce the best total results for me. However, 20 MHz MLAT is probably worth the effort for you since I’m assuming you get a lot more MLAT traffic than I do here in the US. I’m not sure what the trick is for 20 MHz MLAT, it just never sync’d in my 20 or 30 minute tests in the past (I only get 15 to 25 MLAT per day so testing isn’t that easy).
If you set sample_rate to 20, you may need to decrease -e value to keep ADS-B CPU utilization reasonable.
In case it helps
Most people seem to suggest starting out with gain testing 17 or 18 and testing up or down a bit from there. It took me a long time to actually try 19 or 20 and the results in terms of plane count were significant and immediate.
Thank’s again my friend.
With a gain of 13 i am getting a good dinamic range with weakest signals around -30 and strongest around -3.
I will continue working on it.
Don’t be afraid to let peak signals frequently hit 0.0. It just doesn’t matter with Airspy. It’s counterintuitive! You won’t drop messages for planes flying over your roof.
That’s the Airspy Mini needing rock solid power not to drop stuff at 20 MHz.
(you wouldn’t see the drops in the syslog, the dropping of samples happens in the SDR, not on the system side, this is not detectable in software)
I’ve just recently due to MLAT issues changed my Airspy Mini to 12 MHz.
(after running 20 MHz MLAT just fine for a year, so i get the impression there might be some degradation of some capacitors maybe?)
So if you have MLAT issues i’d recommend going to 12 MHz.
If that doesn’t fix it, might still be power issues i suppose.
I’m using the R2, but yeah I’m perfectly happy with 12 Mhz results, and the overall Airspy improvement in general. I only tested 20 MHz for short periods of time and don’t think the potential benefit is much for my region’s very low MLAT traffic case.
i’m running a 3B+ with my airspy mini. i could never get MLAT to sync with ethernet connection when running 20MHz. the minute i changed to wifi all was well at 20MHz
20 MHz … isn’t about MLAT, it’s about the sample rate and all traffic.
The time resolution isn’t much different, the naming of the parameter is misleading.
Sounds about right to me
Thanks for clarifying that. I always wondered. Anyway, in brief tests I don’t think it helped much with overall numbers. Will probably test again someday since I can’t sit still. 
The MLAT counter is translated to 12 MHz regardless of the actual ADC frequency => Only in the Beast output mode for backward compatibility. Other modes get 12, 20 or 24 MHz depending on the -m option.
Does BEAST benefits from the higher resolution before conversion (better detecting the samples)?
When you take into account the 2MHz or 2.4MHz of the RTL dongles that make the majority of the contributions, one or two high resolution contributors in the mass may not improve the results by much, if at all. But when all the contributors have a good timing resolution and a low jitter clock, the positions may become very accurate. Bev of COAA uses the MLAT at 20MHz in some of his servers, the reports say this works very well with low splatter.
The timing noise from doing ADS-B-based synchronization is at best somewhere around 0.2us, though, so there’s not really much benefit there for clocks that are not providing epoch-synchronized timestamps.
(The ~ 0.2us number came from looking at pairs of GPS-synchronized receivers providing 1ns-resolution clocks that were also doing ADS-B based synchronization. The GPS synchronization is good down to 50ns or so, so anything worse than that on the ADS-B case is from synchronization noise - this will be things like imprecision in GPS aircraft position, timing delays between aircraft GPS determining a position and the position being emitted via ADS-B, perhaps multipath effects between aircraft and receiver)
OT: That made me look up the Linux epoch timestamps. Seems like we will run out of timestamps Tuesday, January 19, 2038, at 03:14:07 a.m.