I have added this to the rc.local:
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
I have added this to the rc.local:
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
I have another question about Airpsy (Mini) integration. I have launched the Airspy decoder with the “-w 4” option, but it doesn’t look like is spreading the work load on four cores. More like two… most of time just one. The load just “jumps” from one core to another.
Is that a limitation of the htop command?
You don’t have enough decoding work to fully use even one core. There has to be enough work to occupy more than 1 core (Load Average > 1.00) before other cores kick in.
My version of airspy_adsb no longer shows -w as an option
pi@odroidxu4:~/airspy$ ./airspy_adsb -h
airspy_adsb v1.37
Options:
-s <serial_number> Device serial number
-t Aircraft timeout in seconds
-g <rf_gain> RF gain: 0…21
-f Forward Error Correction (FEC) bits
-c :[:format] Add a Push Client
-l [:format] Add a Server
-m <mlat_freq> MLAT frequency in MHz: 12 or 20
-x Enable DX mode
-r Reduced IF bandwidth
-b Enable Bias-Tee
-p Enable Bit Packing
-v Verbose mode
-h Display this help screen
Available output formats:
It is fairly quiet at the moment so I don’t see a lot of CPU usage.
I am seeing 130 planes with 900-1000 msgs/sec.
Mine neither. I wonder if they removed that option silently.
Indeed. The new algorithm is much more efficient and should never require more than one RPi2 core. RPi3 is more than enough for the entire decoding and filtering.
Any testers for this update for Windows? http://airspy.com/downloads/adsbspy-1.0.0.50.zip
Thanks!
I don’t use it in Windows, I wonder if the updated the Linux too?
LE: Nope, the last commit was 8 months ago. Ver 1.37.
This is just the Windows build of the CLI version you use on Linux.
Using the help option “./airspy_adsb -h”, I noticed the following available commands:
airspy_adsb v1.37
Options:
-s <serial_number> Device serial number
-t Aircraft timeout in seconds
-g <rf_gain> RF gain: 0…21
-f Forward Error Correction (FEC) bits
-c :[:format] Add a Push Client
-l [:format] Add a Server
-m <mlat_freq> MLAT frequency in MHz: 12 or 20
-x Enable DX mode
-r Reduced IF bandwidth
-b Enable Bias-Tee
-p Enable Bit Packing
-v Verbose mode
-h Display this help screen
Available output formats:
- AVR - Raw AVR format
- AVR-STRICT - Raw AVR format with only CRC valid frames
- ASAVR - Raw Airspy AVR format
- Beast - Raw Beast Binary format
As you can see a lot of commands from beginning of this thread are not available anymore, for example the “-w 4” one.
I did try for a while the “-x” option “Enable DX mode” but didn’t seem to make a difference.
Today I have tried “-r” option for “Reduced IF bandwidth”. Not sure how reduced that is, and what’s the ADS-B protocol needs, but for me it did improve the performance. Not sure if is not a coincidence though, after the Thanksgiving holiday that we had last Thursday, number of flights might be increased this Sunday.
Will check again tomorrow.
Sunday after Thanksgiving. Big day.
I do not use the /etc/rc.local method to get airspy_adsb to autostart, it did not work on my raspbian stretch (flightaware 3.6.3 sd card install). Instead I created a file /etc/systemd/system/airspy_adsb.service
with this content:
[Unit]
Description=Fetching data from Airspy SDR
Documentation=https://discussions.flightaware.com/t/howto-airspy-mini-piaware-dump1090-fa-configuration/44343
[Service]
WorkingDirectory=/home/pi/
EnvironmentFile=/etc/default/airspy_adsb
ExecStart=/home/pi/airspy_adsb $OPTIONS
Nice=-10
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=airspy_adsb
User=root
Group=root
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target
Then I activated it with sudo systemctl daemon-reload
and sudo systemctl enable airspy_adsb
. Et voilà: Upon next reboot it started automatically. You can check what it did by using journalctl -u airspy_adsb
. Depending on where you put your airspy_adsb you may have to adjust the path to it.
In /boot/piaware-config.txt
I put the following receiver configuration:
receiver-type other
receiver-host localhost
receiver-port 29999
In /etc/default/airspy_adsb
I put
OPTIONS="-c localhost:30104:BEAST -l 29999:BEAST -b -g 21 -p -m 20"
Maybe that’s useful for some of you.
That port 29999 won’t work by itself. Something else needs to happen, because MLAT client looks at port 30005.
He’s posting this as an example for a service file, assuming people are able to formulate the command line themselves.
Or just point piaware to port 29999…
You got it. And I am sure this can be done better.
ExecStart=/usr/bin/nice -n -10 /home/pi/airspy_adsb -c localhost:30104:BEAST -l 29999:BEAST -b -g 21 -p -m 20 &
will give better priority and faster sampling rate
I know. But with incomplete info, people can get confused. If the default setting of dump1090-fa is not changed, there is no need of the port 29999 or whatever. Dump1090 will redirect the samples received on input (30104) to default port of MLAT client.
As discussed in the other thread -m20 can give problems on the RPi.
For example it can make MLAT unstable.
Does it work for you?