I’m willing to get a newer one. Which do you recommend?
Edit: I don’t want to do bias-t, so it would need to use external power.
Check 24MHz again. You may find a good surprise.
1 Like
Cheers prog for the heads up, will switch test station over to 24Mhz at midnight 
3 Likes
What about the experience with Airspy Mini and 20Mhz? Here it does not perform like 12Mhz. Getting lower message counts.
I think it depends a bit on the pi you’re running, with a pi3 and 24 MSPS there isn’t much CPU left for decoding.
Pretty certain 20 and 24 MSPS only really shine with a pi4.
But i haven’t really tested so it’s sure worth a try.
Are you running -C i presume?
2 Likes
Or a x86 type of CPU.
1 Like
A Pi3 won’t even cope with 20MHz with a decent amount of traffic.
I have been running 12 MSPS since all the new updates… Happy to switch to 24 and see what happens… Keep everything else the same ? -C85 (pi4)
I did a comparison of RC16 with RC17 with -e from 1 to 25 (also did e 60 as that’s the max). RC17 is measurably better. The sample is 20 seconds from today with gain of 15.
This is DF17 messages:
and difference:
Here is the difference for the total number of messages:
RC17 decoded an extra aircraft that RC16 never did even at -e 60.
With this sample, I was seeing results in RC17 with the preamble filter 3-4 stops lower than needed to get those results in RC16.
The differences are generally quite small (overall <1%), however they are consistent and positive, so a definite improvement.
I need to automate some testing for -P settings to see what the trade off is with cpu usage, gain of DF17 messages due to resultant higher preamble, and the loss of other message types.
With RC 16 I was getting occasional single lines in the log. With RC17 I have some from earlier, but that was immediately after I stopped the decoder to take a sample. Since then I’ve had one example at 16:07:26 where there were 5 lines in the log. I think that’s probably due to me doing other cpu heavy stuff on the pi. Where there is a gain change, there are no corresponding dropped samples in the log, eg at about 16:23:
6 Likes
The new filters are really good. Btw, there are different filters for the supported sample rates. Most of the gains show on 20 and 24 msps. 12 msps still has some improvements, but not as much as the other two.
4 Likes
@wiedehopf @prog Graphs from Airspy vs ref station with FA orange stick. I’m sorry about the enormity of the images. Best to open them in a new tab to view full size.
Edit: OK, I guess you can just click them to enlarge.
Airspy
FA orange stick
Running tweaked Pi4 with -C 90 - at 12Mhz it drops down to 80~85% when lots of AC around during busy traffic.
Plenty of extra local GA traffic over the last few days here due to Goodwood Revival 2 miles away - helo taxis etc.
1 Like
Can you post your whole Option string please?
Both sites presently running at 12Mhz with following:-
GAIN= auto
OPTIONS= -v -t 300 -f 1 -w 5 -e 4 -C 90
Thanks. Are you getting roughly the same number of MLAT synchronisations on the Flightaware stats page?
My options are similar to yours but only 5 synchronisations rather than 650
[Edit] Ignore that last post as I didn’t wait long enough after the last restart. Back to 690 now.
Been running rc17 for approx 6 hours and it’s really too early to say anything that I can back up with numbers, but it seem to perform better that previous rc:s.
I’m going to get a sample and compare rc17 with 16 and perhaps some of the earlier version for good measure.
Usually I see the biggest improvements (compared to pre-autogain) when the traffic slows down (from a maxium of 35-40 aircrafts to below 10 scattered over the entire range I can “see”.
The testing I’ve done previously (with recorded samples) always showed the best performance with 24 msps, going to re-run the test with rc17 and compare.
Anyway, good work, my gain seem to have dropped one notch after installing rc17 compared to previous version.
1 Like
On my pi4, Sample rate 20 needs -p switched on. This way my mlat is not synced anymore.
Is there a way to keep both higher sample rate and MLAT working on a pi4? 24 is not usable here.
Switched to 24 a few hours ago… this dropped -e significantly. Will leave it like this for a few days…
Everything else seams fine….
OPTIONS= -v -t 180 -f 1 -w 5 -P 6 -e 5 -C 85
Gain=auto
whoa!, i switched from 12MHz to 20MHz (on mini) and auto gain dropped the gain to 16. the gain had been between 21 (at night) to 18 but no lower since the advent of auto gain. also, a nice increase in RSSI. of course CPU went from 46% to about 78%.
-v -t 120 -f 1 -w 5 -e 6 Rrms -P 5
just checked my logs, @wiedehopf @prog it says report it so I am
Sep 19 16:51:15 Flightp1 systemd[1]: Started Airspy ADS-B receiver.
Sep 19 16:51:15 Flightp1 airspy_adsb[29962]: airspy_adsb v2.2-RC17
Sep 19 16:51:15 Flightp1 airspy_adsb[29962]: Listening for beast clients on port 47787
Sep 19 16:51:15 Flightp1 airspy_adsb[29962]: Acquired Airspy device with serial B58069DC393F4513
Sep 19 16:51:15 Flightp1 airspy_adsb[29962]: Decoding started at 24 MSPS (Gain: auto; CPU target: 85 %)
Sep 19 16:51:16 Flightp1 airspy_adsb[29962]: Push client connected to 127.0.0.1:30004 (beast)
Sep 19 18:02:10 Flightp1 airspy_adsb[29962]: No data from device for 15 seconds, attempting to restart decoder!
Sep 19 18:02:10 Flightp1 airspy_adsb[29962]: Apparently the data processing didn’t finish, report this please.
Sep 19 18:02:45 Flightp1 airspy_adsb[29962]: FATAL: watchdog timed out, aborting process!
Sep 19 18:02:45 Flightp1 systemd[1]: airspy_adsb.service: Main process exited, code=killed, status=6/ABRT
Sep 19 18:02:45 Flightp1 systemd[1]: airspy_adsb.service: Failed with result ‘signal’.
Sep 19 18:03:00 Flightp1 systemd[1]: airspy_adsb.service: Service RestartSec=15s expired, scheduling restart.
Sep 19 18:03:00 Flightp1 systemd[1]: airspy_adsb.service: Scheduled restart job, restart counter is at 1.
Sep 19 18:03:00 Flightp1 systemd[1]: Stopped Airspy ADS-B receiver.
Sep 19 18:03:00 Flightp1 systemd[1]: Started Airspy ADS-B receiver.
Sep 19 18:03:00 Flightp1 airspy_adsb[22969]: airspy_adsb v2.2-RC17
Sep 19 18:03:00 Flightp1 airspy_adsb[22969]: Listening for beast clients on port 47787
Sep 19 18:03:00 Flightp1 airspy_adsb[22969]: Acquired Airspy device with serial B58069DC393F4513
Sep 19 18:03:00 Flightp1 airspy_adsb[22969]: Decoding started at 24 MSPS (Gain: auto; CPU target: 85 %)
Sep 19 18:03:01 Flightp1 airspy_adsb[22969]: Push client connected to 127.0.0.1:30004 (beast)