Somehow I can’t get my RPi3 to feed Flightaware using the Airspy radio. Symptoms:
On the RPi’s web interface I see “Radio” and “MLAT” are red, “Piaware” and “Flightaware” are green.
on the host/dump1090-fa/ site I see many planes. Thus the radio is working.
my flightaware status is
sudo piaware-status
PiAware master process (piaware) is running with pid 15813.
PiAware ADS-B client (faup1090) is not running.
PiAware mlat client (fa-mlat-client) is not running.
the ADS-B listener is on another host, I can't check on its status.
faup1090 is NOT connected to the ADS-B receiver.
piaware is connected to FlightAware.
journalctl -u piaware gives me
Jan 01 17:59:07 piaware piaware[16376]: creating pidfile /run/piaware/piaware.pid
Jan 01 17:59:07 piaware piaware[16376]: ****************************************************
Jan 01 17:59:07 piaware piaware[16376]: piaware version 3.6.3 is running, process ID 16376
Jan 01 17:59:07 piaware piaware[16376]: your system info is: Linux piaware 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
Jan 01 17:59:09 piaware piaware[16376]: Connecting to FlightAware adept server at piaware.flightaware.com/1200
Jan 01 17:59:09 piaware piaware[16376]: Connection with adept server at piaware.flightaware.com/1200 established
Jan 01 17:59:09 piaware piaware[16376]: TLS handshake with adept server at piaware.flightaware.com/1200 completed
Jan 01 17:59:09 piaware piaware[16376]: FlightAware server certificate validated
Jan 01 17:59:09 piaware piaware[16376]: encrypted session established with FlightAware
Jan 01 17:59:09 piaware sudo[16383]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/netstat --program --tcp --wide --all --numeric
Jan 01 17:59:09 piaware sudo[16383]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 01 17:59:09 piaware sudo[16383]: pam_unix(sudo:session): session closed for user root
Jan 01 17:59:10 piaware piaware[16376]: logged in to FlightAware as user xxxxx
Jan 01 17:59:10 piaware piaware[16376]: my feeder ID is xxxxxxx
Jan 01 17:59:10 piaware piaware[16376]: Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr {} --net-bo-port 30005 --stdout
Jan 01 17:59:10 piaware piaware[16376]: Started faup1090 (pid 16395) to connect to the ADS-B data program at /30005
Jan 01 17:59:10 piaware piaware[16376]: faup1090(16395): faup1090: failed to connect to :30005 (is dump1090 running?): can't resolve : No address associated with hostname
Jan 01 17:59:10 piaware piaware[16376]: lost connection to the ADS-B data program at /30005 via faup1090
Jan 01 17:59:10 piaware piaware[16376]: faup1090 exited with EXIT 1
Jan 01 17:59:10 piaware piaware[16376]: will reconnect to the ADS-B data program at /30005 in 30 seconds
Did you follow all the instructions on the airpsy thread?
This is what I get on my setup:
pi@pi_3:~ $ sudo piaware-status
PiAware master process (piaware) is running with pid 515.
PiAware ADS-B client (faup1090) is running with pid 641.
PiAware mlat client (fa-mlat-client) is running with pid 632.
Local ADS-B receiver (dump1090-fa) is running with pid 508.
dump1090-fa (pid 508) is listening for connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.
dump1090 is producing data on localhost:30005.
Your feeder ID is xxxxxxxxxxxxxxxxxxx (configured at /etc/piaware.conf:9)
If that worked before… you need to reboot the remote system somehow.
@SoNic67: I have read the thread but it is 114 posts long and some advices are mutually exclusive, some are outdated. I do start airspy_adsb by CLI since the rc.local method for starting it at boot time did not work. rc.local is also deprecated one should use systemd nowadays, correct me if I’m wrong.
@Wiedehopf: sudo /home/pi/airspy_adsb -c 127.0.0.1:30104:BEAST -l 30005:BEAST -b -g 21 -p &
On the sd-card image. Gain 21 gives best results although I use a preamp.
$ piaware-config
allow-auto-updates yes # value set at /boot/piaware-config.txt:39
allow-manual-updates yes # value set at /boot/piaware-config.txt:43
allow-mlat yes # value set at /boot/piaware-config.txt:47
allow-modeac yes # value set at /boot/piaware-config.txt:51
feeder-id xxxxxxxxxxxxxxx # value set at /boot/piaware-config.txt:32
image-type piaware # value set at /usr/share/piaware-support/piaware-image-config.txt:5
manage-config yes # value set at /usr/share/piaware-support/piaware-image-config.txt:4
receiver-type other # value set at /boot/piaware-config.txt:31
wired-address 192.168.178.6 # value set at /boot/piaware-config.txt:19
wired-broadcast 192.168.1.255 # value set at /boot/piaware-config.txt:21
wired-gateway 192.168.178.1 # value set at /boot/piaware-config.txt:22
wired-nameservers "89.236.189.120 8.8.4.4" # value set at /boot/piaware-config.txt:23
wired-netmask 255.255.255.0 # value set at /boot/piaware-config.txt:20
wired-network yes # value set at /boot/piaware-config.txt:17
wired-type static # value set at /boot/piaware-config.txt:18
wireless-network no # value set at /boot/piaware-config.txt:25
If i remember correctly you need to set
receiver-host
so that this config works. (this option has no default, setting it to localhost will work best in your case)
Also it is better to use something like port 29999 for airspy listening port so it doesn’t collide with dump1090-fa also trying provide data on 30005.
(Not sure which command line piaware produces for dump1090-fa with those config options so it might not be necessary but it can’t hurt either.)
If you change the listening port in airspy to 29999 then also use the piaware config option receiver-port and set it to 29999.
Thanks for your help! @biekerc: That was a mistake indeed. However, correcting it did not change anything. @wiedehopf: I added receiver-host localhost and receiver-port 29999 to /boot/piaware-config.txt and now “Radio” turned green! $ sudo piaware-status now returns:
$ sudo piaware-status
PiAware master process (piaware) is running with pid 1203.
PiAware ADS-B client (faup1090) is running with pid 1232.
PiAware mlat client (fa-mlat-client) is not running.
airspy_adsb (pid 853) is listening for connections on port 29999.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.
the ADS-B data program at localhost/29999 is producing data on localhost:29999.
Starting command is now $ sudo /home/pi/airspy_adsb -c localhost:30104:BEAST -l 29999:BEAST -b -g 21 -p &
It seems I have to configure MLAT separately since it does not work yet.
Location was already configured since I ran the site using a cheap Nooelec radio before. Yes, I am using a LNA.
I added mlat-results-format beast,connect,localhost:29999 to /boot/piaware-config.txt, now everything is working fine, see my stats.
I am surprised this information was not readily available in the getting started page. Thank you very much for your friendly and quick help.
That mlat-results config you used is not what made it work.
Maybe it just needed some time to start working.
That’s just the mlat results. it will now try to connect to port 29999 which does not make any sense because the airspy program does not need the mlat results.
Receiver-host not defaulting to localhost is indeed not so useful.
Could be better documented but the huge majority is running rtl-sdr compatible dongles anyway.
Actually it depends on the clock of the receiver in this case the airspy.
USB is not time accurate enough so the timestamp must come from the receiver.
The actual system time does not matter too much (apart from being out more than a couple of seconds probably, but i’m sure piaware syncs time with the flightaware servers anyway)
Now what is correct is that MLAT will receive data from the mlat servers before syncing up and checks if your receiver clock is stable.
Not sure how long that takes.
In regards to range you are probably limited by terrain more than anything so in case you use the rtl-sdr blog LNA you might even consider turning down the gain some
$ /home/pi/airspy/airspy_adsb -h
airspy_adsb v1.37
Options:
-m <mlat_freq> MLAT frequency in MHz: 12 or 20
But the Airspy isn’t doing the MLAT, so “-m” is not needed. It’s compatible by default with no “-m”. AirSpy is just feeding (asynchronously) to Piaware, which then handles its own timing. I believe that the “-m” command is a remnant from when the AirSpy folks may have been running their own MLAT server. It’s not needed for Piaware and just causes confusion here.
This is my station right now, using the command line I quoted above:
Multilateration (MLAT): Supported / Enabled (synchronized with 348 nearby receivers)
Well as i didn’t know which the default setting was it was a reasonable suggestion
And it is relevant for the beast output data what you chose here no matter which application does the MLAT.
Because the timestamp is basically just a number being incremented and you need to know which clock frequency that is based on.
So the timing (a timestamp in clock cycles for every message) is already embedded in the BEAST messages otherwise it wouldn’t work anyway.
@SMBurn: No, when I leave the -l option my setup is not working anymore. Maybe because I use port 29999 and default may be 30005. It’s a pity they don’t tell the default settings in airspy_adsb -h.
I have the Airspy R2. How do I find out the correct MLAT frequency? It’s working now but it could be wrong? Do I need a DX mode, -x option?
I did not get better results using a lower gain than 21. I use the uputronics ceramic filter.
The interesting question regarding gain is which amplifier you use. A filter is not an amplifier (often called LNA for low noise amplifier) @prog How do you check which amplitude the incoming messages have?
Your program supplies some sort of RSSI but for many messages it is just zero.
Anyway if your amplifier is single stage (less than 20dB) you can probably run max gain no problem.
If it were the rtl-sdr blog LNA or some other double stage design you might want to reduce the gain. But there is often a range of gains where the messages you receive don’t change for the most part.
The -x mode does some fancy oversampling but it might be on by default now.
It is designed to receive messages that partially overlap i believe.
Specifying extra options is not a problem.
Output listening and push client ports are not open by default so you can’t leave out that option.
SMBurn is using the push option and pushing the messages via port 30104 to dump1090 which then serves them again on port 30005 where piaware is fetching them.
But in the end it doesn’t even matter which way the messages go, but as you use the sd card image i would use the setup as intended. (Because you can’t configure dump1090 not to use the port 30005 as an output port as such detailed configuration is not intended for the sd card version)
You could also use the relay mode and make airspy only listen on 29999.
piaware would then connect there, use the messages itself and also forward the messages to dump1090.
If the frequency was wrong it wouldn’t be working. You can always change it and see if it stops working
