Step by step how to integrate airspy into existing piaware

My setup is very simple now.

  1. Start with editing rc.local to add the airspy_adsb:
    sudo nano etc/rc.local

sudo nice --5 /home/pi/airspy/airspy_adsb -c 127.0.0.1:30104:BEAST -g 20 -p -r -x&

  1. Change the default dump1090-fa receiver options (commented part):
    sudo nano /etc/default/dump1090-fa
#RECEIVER_OPTIONS="--device-index 0 --gain -10 --ppm 0 --net-bo-port 30005"
RECEIVER_OPTIONS="--net-only --fix"
DECODER_OPTIONS="--max-range 360"
NET_OPTIONS="--net --oversample --phase-enhance --net-heartbeat 60 --net-ro-size 1000 --net-ro-interval 1 --net-ri-port 0 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005"
JSON_OPTIONS="--json-location-accuracy 2"

Note that the Beast input port is 30004 and 30104, and the data is mirrored at output in Beast format is on 30005 (as expected by MLAT client).

The MLAT client will expect the output where you configure piaware to look for it.
As you are already aware your configuration will not be possible with piaware sd-card install as you can’t change the dump1090-fa config in that case.

@burgdorfer
why don’t you include the receiver-type and receiver-host and receiver-port settings you used by editing your post.
also mention you are on the piaware sd card install.

It will make it easy for me to link other people to your post :slight_smile:

@widehopf: done

Is it possible to create a file /etc/default/airspy_adsb and put the configuration there? I mean, creating the file is trivial but getting airspy_adsb to read it probably not… This would even more simplify the service file and you wouldn’t have to run the daemon-reload command every time you change the configuration.

You can use systemd to do the job for you.
Above ExecStart, put this line:

EnvironmentFile=/etc/default/airspy_adsb

Then create the file and in it you only need the line:

OPTIONS="-c localhost:30104:BEAST -l 29999:BEAST -b -g 21 -p"

In the ExecStart line you then instead of the options write $OPTIONS

You should probably also mention that the airspy binary needs to be in the directory /home/pi :slight_smile:

But if you do nothing it will look at 30005. Changing the default port is un-necessary.

The default port will be used by dump1090-fa as far as i know.
This means the both dump1090-fa and airspy will try listening on that port.
That can cause problems which is why i recommend another port.

@burgdorfer

Could you check the output of this command:

ps -eF | grep dump1090-fa

I’m curious if dump1090-fa still tries to listen on port 30005 (–net-bo-port 30005)

That’s why my Airspy does not output on 30005.
Only on 30104 and then the rest is done by dump1090-fa (mirrors that data on the 30005).

No it doesn’t. I neither have that parameter nor port 30005 in any other parameter in the long list of this command. And everything works.

Just running the push client doesn’t work if dump1090-fa is configured by piaware on an sd-card install.
But it appears changing the listen port to 29999 is not necessary unless you want to use piaware with the relay config option.

@burgdorfer you might want to change the port to 30005 if you want to run other feeders and not reconfigure the port when configuring them.
But it doesn’t really matter then i guess.

1 Like

@ wiedehopf
I guess I can also open the 30104 for listen (-l) instead of push (-c):

I’ll try that now, see if it makes a difference. For now it seems it works the same, but it is early morning, not too many planes above.
The only visible difference is that is using IPv6 instead of the forced IPv4 (127.0.0.1) in previous case:

Beast-format results connection with ::1:30104: connection established

That would not work.

Imagine such ports as a plug and a socket.
Listening is a socket.
Connecting is a plugging in a plug.

You can plug in multiple plugs into each socket though :slight_smile:

But two sockets can’t be in the same place (port 30104 is already open) and the two sockets won’t magically connect.

The actual data can travel both directions on the established connection. But if the programs are only configured to receive data the data will only travel in one direction which depends on the programming and configuration.

Yep, didn’t work. I have reverted to -c 127.0.0.1:30104

I hate to be “that guy” and keep having to repeat myself.

To clear the S/N ratio on this thread, once again:

Because you repeat it it doesn’t become complete and correct. In my case at least the system only started to work when the listening hostname and port in airspy_adsb starting command matched the one used in /boot/piaware-config.txt section receiver-port and hostname. It does not matter wether you use port 29999 or 30005 or maybe another one.
Your command line above without -l anyport:BEAST parameter does not work on an SD card install piaware 3.6.3. I just checked that. Maybe you have some additional config file somewhere to specify port number.

1 Like

Then we should clarify what’s what.
I did post above my settings that work for the Piaware add-on installation. The “-l” is definitely not working due to conflict with dump1090-fa, that why “-c” is needed… as is also recommended by airspy people too.

That’s because the SD card install needs some specific changes and you probably didn’t know how to do those: PiAware - Advanced Configuration Settings - FlightAware
When you change the “receiver-type” in the config file to “relay”, the system automatically configures at start-up the “beast-splitter” that would add the necessary port redirection, and there is no need to add “-l” to the airpsy. Quote from the above link:
" External receiver - Relayed connection (SD card image installs only)
This configures PiAware to talk to an external receiver or other ADS-B source over the network. The receiver needs to provide data in the Beast binary format over TCP. Set “receiver-type” to “relay” and “receiver-host” / “receiver-port” to the host/port to connect to. PiAware will establish a single TCP connection to the receiver and internally relay data to the local map display, faup1090 and mlat-client as needed."

Yeah well the configuration you are describing explicitely requires a server, that means an open port the program providing the data is listening on.
So yes for the piaware sdcard install the -l is definitely required.

The -c might get you some planes displayed in dump1090-fa but ti won’t be feeding flightaware.
What was exactly the problem that presented itself in the other thread burgdorfer started.

I don’t know how many times I said that. Dump1090-fa config file has as an argument to output BEAST format on 30005. So yes, it is feeding FA too.

I should really get an sd-card image to tinker around with it so i know what exactly the software does. I’m relying here on a question i asked burgdorfer in regards to that software behaviour.

Anyway you are contradicting yourself if you say at the same time that the port 30005 does not need to be changed. Because those ports being opened by airspy and dump1090-fa would be a conflict.

Just running top and checking the command line will show you if 30005 is being used by dump1090-fa.
As you are no longer on a sd-card install you can’t check can you?

I never said that Airspy need to send anything to 30005. I am sending the data only to 30104 and the rest is done by the dump1090-fa configuration (mirror to 30005).

In my previous SD card install, setting the receiver type on the “relay” type changed the dump1090-fa to net only but activated the beast-splitter and that was doing the same thing (mirroring the data from 30104 to 30005. Again, only feeding the 30104 port was needed from airspy.

FWIW the sdcard receiver configuration logic is all here: piaware-support/generate-receiver-config at master · flightaware/piaware-support · GitHub

1 Like