FlightAware Discussions

V5.0.5-airspy dump1090-fa with native AirSpy support now available

Further update after testing a few things:

changing -e 10 to 11, 12, 13 does not change the overall picture, just increases CPU. Changing sample rate from 12 to 20 does not change things, but uses more CPU and the mini will run hotter.

changing-e-CPU-use-202107241157edit

I am sure there are changes, but insignificant in the grand scheme of things here which is to test dump1090-fa-airspy. However what I have found is that the airspy mini can do just as well, and better than the Orange FA dongle. I get around the same number of aircraft and same distance as well. I see more messages.

And this annotated set from graphs1090 highlights some areas of difference

Observations: the Mini using airspy_adsb provides similar aircraft numbers and more messages than the reference system. So why don’t I use the Airspy Mini instead? Simple: airspy_adsb currently does not support Mode A/C.

What I cannot tell is if the messages are all valid in either system, however this may help, as it shows a breakdown of messsage types, and potential errors or bad decodes.

Two things…

If you use airspy_adsb’s -r Reduce the IF bandwidth to 4 MHz option, you can get the same effect in dump1090 by setting --freq 1089200000

Question… If you use --airspy-enable-rf-bias to power an LNA, do you think dump1090 should turn the bias back off again when it exits? Right now, I leave it on.

Personally, I think yes, if dump1090 turned it on when it started then it should turn it off again when it stops.

1 Like

@gtj0 - Well done sir! I’ve been out of it for awhile, just happened to have a few minutes to browse and found this thread. It’s come a long ways!

Hope to have time again to test within the next couple months and I still have a couple identical rigs up to help with the dirty-work. Just need time. Heck, I’m still on v3.7 and a dev version at that. That’s how far behind things have gotten on my end.

Looking forward to catching up with everyone again soon. Keep up the good work.

2 Likes

And you have a lower number of aircraft without position on the Airspy.
I assume your message rate > -3dBFS seem to be too high with 11% on the FA dongle

@gtj0 I agree, should always leave it in a known state, leaving it as you found it is correct.

You just know that there would be a “but”, though… But I use the LNA powered via USB socket not bias-t, as I have a passive splitter and need the LNA on regardless of the state of any of the connected receivers. If my only option was to power via dump1090 enabling bias-t, and if I blocked DC at the other splitter ports via a capacitor, I would want dump1090 to leave it on. I suspect this is a corner case :slight_smile: !!! If someone has this requirement, I would expect they have the skills to make separate LNA power arrangements. So on reflection (maybe a pun in there), yes always turn off when dump1090 exits: safer option and let the ‘corner-case’ experimenters do their own thing, as I have done.

I will have a play and report back

Yes a little high, I have been ‘pushing the boundaries’ of the dongle chasing the last drop of performance. I found the same trend, though when the -3dbfs was lower, compared with airspy-adsb.

I will lower the gain a notch and see what happens. trying to avoid changing too many things at once: makes comparision difficult :grin:

KIV I am in a very quiet location, RF-wise at 1090Mhz and that may well make a difference to performance.

OK, that makes it hard to identify the real performance.

Update: tried this, the ref system (dump1090-fa V5) shows a noticable drop in traffic

The airspy_adsb test system does not show such a marked difference with the -r option set

Both systems now reset to original settings

Welcome Back!

Agreed. I’ll try to add it this weekend but I’m pulling my antenna platform down for a quick refurb and that usually ends in more work than expected and certainly more aggravation. :slight_smile:

Yeah I got the same result but I never used it with airspy_adsb before. Thanks for testing.

Pleasure, anytime :slight_smile:

Would you like me to continue using the airspy_adsb on the test system or revert to dump1090-fa-airspy for further testing?

Quick referb… more work… my experience too :frowning: Good luck

Your call. I probably won’t have anything new to test on dump1090-fa-airspy until Tuesday.

Hi all
im a bit confussed as to why i don’t see this

journalctl -xeu dump1090-fa .

 Demod  HiRate:
 Successful Message Demod Offsets
 Demod window width: 15
 Offset   Count
  -7:               0
  -6:               0
  -5:               0
  -4:              11
  -3:              48
  -2:             393
  -1:            7457
   0:           17648
   1:            3939
   2:             787
   3:             217
   4:              32
   5:               0
   6:               0
   7:               0

but get this instead ?

type or past-- A stop job for unit dump1090-fa.service has finished.
--
-- The job identifier is 4401 and the job result is done.
lines 524-546/546 (END)
Aug 03 08:53:42 raspberrypi dump1090-fa[14470]:          0 non-ES altitude messages from ES-equipped aircraft ignore
Aug 03 08:53:42 raspberrypi dump1090-fa[14470]:       2133 unique aircraft tracks
Aug 03 08:53:42 raspberrypi dump1090-fa[14470]:         42 aircraft tracks where only one message was seen
Aug 03 08:53:42 raspberrypi dump1090-fa[14470]:         99 aircraft tracks which were not marked reliable
Aug 03 08:53:42 raspberrypi dump1090-fa[14470]: CPU load:  16.8%
Aug 03 08:53:42 raspberrypi dump1090-fa[14470]:   7606664 ms for demodulation
Aug 03 08:53:42 raspberrypi dump1090-fa[14470]:   10771 ms for reading from USB
Aug 03 08:53:42 raspberrypi dump1090-fa[14470]:   2127750 ms for network input and background tasks
Aug 03 08:53:42 raspberrypi dump1090-fa[14470]: Tue Aug  3 08:53:42 2021 BST  Normal exit.
Aug 03 08:53:42 raspberrypi systemd[1]: dump1090-fa.service: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: https://www.debian.org/support
e code here

journalctl -xeu dump1090-fa will show you the current log for the service. That’s good for seeing startup errors.

I think what you want is…
journalctl -o cat -fu dump1090-fa
That will follow the live output for the service.

It’s only going to show meaningful output if you have stats turned on…
--stats --stats-every 10
That will print out the stats every 10 seconds.

EDIT: Oh, don’t leave stats set for too long or you’ll get a very large /var/log/daemon.log!

sudo apt remove rsyslogd

fixed :stuck_out_tongue_winking_eye:

1 Like

Hi guys,

libairspy0 and libairspy-dev are installed on my pi4 (buster) but Airspy R2 still does not work. It is ok on windows and SDR#

Please help with a step by step solution, I am not really at home with linux

Thanx for the effort

Janos

Update:
This is also installed https://github.com/airspy/airspyone_host/archive/master.zip without any success.

Can you describe what steps you took and what the actual result was?

On this pi, previously an RTL V3 dongle and later an RSP1a worked succesfully.
…for Airspy r2, I skipped libusb.

libairspy0 and dev was installed without error, then I installed the dump/hirate decoder - as it was described in v.5.0.

After reboot, it was not so perfect… dump1090-fa said that compatible device is not available (or similar)

I checked if there is more up to date user mode driver - I could not find one.

Latest firmware was installed without problem. I tested the receiver on windows, … it is ok.

I am really a newbie in linux, so please: be patient :slight_smile:

Edit:
I checked also the other USB ports available, rebooted a few times without success.

You do still need libusb but it was probably installed automatically anyway.
Since you already installed airspyone_host, run this command from a Linux terminal and paste the results back here.

$ sudo airspy_info