FlightAware Discussions

Step by step how to integrate airspy into existing piaware


#82

@SoNic67

As you might remember!, I have been through this using an Odroid XU4 and FA SD card image a while back, but with help from very knowledgeable people on here, managed to get it working fine.

If your using the latest FA image then place the following into your /etc/rc.local file:

/home/pi/airspy/airspy_adsb -c 127.0.0.1:30104:BEAST -g 21 -n -p -w 4 –d 1 -f 1 -x -m 12 & (This is what I’m running!)

(or whatever your path is!) - you may need to tweak these settings if the RPI goes into overload!!!

Make sure your rc.local file runs during start up.

Set receiver-type ‘relay’ in piaware-config

This connects to FA with no problem, and gives great results - then you can add FR24 feed etc as shown on other posts on this forum.

Since getting this up and running, I have got to #1 in the UK, and #21 overall in 30 day rankings - Airspy Mini is an amazing bit of kit - just wonder how much difference it would make if I could do 20Mhz Mlat to FA servers with it!!!


#83

Firstly, I found out that the option “relay” on PiAware SD card is initializing the beast-splitter config file with:

ENABLED=yes
INPUT_OPTIONS="–net 192.168.1.236:30005 "
OUTPUT_OPTIONS="–listen 30005:R --connect localhost:30104:R"
The option “other” that I have used before does not do that, it just configures the dump1090-fa to run in -net-only mode (relay does that too). So using “other” requires that airpsy to “push” data on the two above ports.

That’s why on the SD card installs, fa_config_generator makes it sufficient that airpsy to send data only to the 30104 port, because it configures the beast-splitter to do the rest.
In my previous attempt, from a add-on install, that wouldn’t work, because there is no automatic configuration.
So I needed the line to be:

sudo /home/pi/airspy_adsb -c 127.0.0.1:30104:BEAST -l 30005:BEAST -g 18 -p -w 4 &

Now I am past that, since I have re-flashed the PiAware SD card. An dI was wondering how can I add the second tuner in this install (like the UAT 978), without using netcat (because I already have the beast-splitter active).
So I was planning for the second receiver (configured for port 30010), to configure beast-splitter to use something like:

sudo beast-splitter --net localhost:30010 --connect localhost:30104 --connect localhost:30005 $

However, I don’t know if --connect or --listen are appropriate. I don’t get why the SD card setup uses --listen for 30005 and --connect for 30104.
It appears that --connect works, no conflicts, but…

PS: I hate that airspy_adsb doesn’t have a manual page, just what is outputted via this (for airspy mini):

pi@piaware:~ $ ./airspy_adsb -help
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

#84

The listen on 30005 is bogus because that port is already being listened on by airspy.
Only one program can listen on a port on one machine. Otherwise when you connect to a machine the machine wouldn’t know which program the connection is meant for.
It probably works because it connects to the input first and when trying to listen on the output beastsplitter gets an error that the port is already used and just ignores that part of the output.

Listen and connect with ADSB data does not necessarily mean in which direction the data will be flowing by the way. It’s just which program will act as a “server” (listen) and which program as a “client” (connect).

Also you should use -f 1 one the command line to make sure the error correction is enabled.
Not sure what dx mode is but pretty sure it was explained in the other thread by the creator of the software.

Anyway back to the ports.
You have dump978 running listening on 30010?
It’s localhost not localport by the way.

Also you need some program to combine both message streams as i don’t think piaware can accept data from two sources.
dump1090-fa can accept data from multiple sources but i’m not sure if you can feed piaware from dump1090-fa.

Don’t you use the package install version?
Not sure if the FA SD card image even works on an odroid.
In case it’s a package install can post your config for dump1090-fa?

Thank you.


#85

Like I said, that option in airpsy_adsb was needed for the “add-on”, but not for the SD card install (with “relay” option autoconfiguring like I said above)…

And yes I am planning to make dump978 to listen to another port (like 30010).

So to me looks like only one executable can use a port out in server mode (–listen, -l, -bind) but there can be many using that port out in (–connect) mode? As clients?


#86

What I posted was for when I had it running on the SD image using a RPI - All I had to change for the odroid /add-on setup was to put dump1090-fa into ‘–net-only’ mode which SoNic67 pointed out to me.


#87

In and out doesn’t matter. You can have a server that receives data and a server that offers data. Same for clients.
But yes listen is only possible by one application for a specific port like 30005.

@navzptc
If you could be so nice could just post your dump1090-fa config anyway?
Also the piaware-config setting for receiver would be interesting.
Thanks a lot. It would help me help sonic i hope :wink:


#88

This is what I have now and it’s working.
In /etc/rc.local :

sudo /home/pi/airspy_adsb -c 127.0.0.1:30104:BEAST -g 18 -p -w 4 -f 1 -x &

In /boot/piaware-config.txt :

receiver-type relay # updated by fa_piaware_config
receiver-host 127.0.0.1
receiver-port 30005

In /etc/default/beast-splitter :

`# Generated automatically by fa_config_generator

`# This file will be overwritten on reboot.
ENABLED=yes
INPUT_OPTIONS="–net <other_receiver_IP>:30005 "
OUTPUT_OPTIONS="–listen 30005:R --connect localhost:30104:R"


#89

This must be feeding dump1090-fa then and the beast splitter is doing literally nothing.
Curious.
If you put piaware into relay mode and configure it to connect to 30005 you should be providing data on that port via airspy with the listen option. I’m not going to say your way isn’t working it’s just not how it’s meant to be used.
It’s probably also meant to be used without using port 30005 because that is used internally already. So you would want to set the port 29005 or whatever that is outside the standard range dump1090-fa operates on.
It is probably also sensitive to the order the different programs are started.

Can you post the output of this:

pgrep  dump1090 -a

If i understand the current workings correctly you are feeding the data directly into dump1090-fa on port 30104 which is its default data in listen port.

beast-splitter connects to dump1090-fa on port 30005 and feeds the data back to dump1090-fa on port 30104. dump1090-fa probably discards the duplicate packets.

Maybe you can understand the data going around a bit better. It’s not that complicated but you need to be familiar with some basics.


#90

The way that relay mode is intended to work is:

  1. beast-splitter a) connects to your configured receiver host/port for input data; b) listens on port 30005 for connections and provides a copy of input data there; c) connects to localhost:30104 and sends a copy of input data there;
  2. dump1090 listens on ports 30004/30104 for input data (beast-splitter will connect there, see step 1c)
  3. piaware connects to localhost:30005 for input data (this connects to beast-splitter, see step 1b)
  4. fa-mlat-client a) connects to localhost:30104 and sends mlat results there (this connects to dump1090, see step 2); b) listens on localhost:30105 and provides mlat results there

Net result is that the external behaviour looks just like what you’d have with the normal rtlsdr setup:

  • skyview (via dump1090-fa) includes both radio and mlat results
  • port 30005 provides radio data only, no mlat; piaware feeds this data to FlightAware
  • port 30105 provides mlat results only, no radio data

This only works if the configured relay receiver does not interfere with any of the normal ports.
I’d suggest configuring airspy to listen on some other completely different port, only, and point the relay config at that port.

You can see the code that sets this up here: https://github.com/flightaware/piaware-support/blob/master/scripts/generate-receiver-config


#91

Obj,
Thank you for explanation.

Is this picture accurate? The port 30104 is recommended by airspy at FlightAware Integration, but to me it looks like it might feed back MLAT to FA servers trough the Beast-Splitter. Or the MLAT packets are ignored by Beast-Splitter because they are not Beast formatted?
Should airspy_adsb output on port 30004? Then dump1090 will pick that port (together with 30104) and beast-splitter can be configured also for that port.

LE: Took out the diagram, it was not right, see below post with the corrected one.


#92

It’s unclear to me from the above drawing why beast splitter is even necessary.

I have one Pi @ 192.168.1.151 that runs Piaware/dump1090-fa/Skyview (package install). It operates in --net-only mode with the following lines in /etc/default/dump1090-fa:

RECEIVER_OPTIONS="--net-only --net-bo-port 3005 --net-bi-port 3001 --net-bi-port 30104"
NET_OPTIONS="--net --net-heartbeat 60 --net-ro-size 1000 --net-ro-interval 1 --net-ri-port 30001  --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005"

Aside from adding the --net-only option, it’s essentially a stock configuration.

sudo netstat -a | grep LISTEN for anything Piaware there looks like:

tcp        0      0 0.0.0.0:http-alt        0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:30001           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:30002           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:30003           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:30004           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:30005           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:30104           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:30105           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:30106           0.0.0.0:*               LISTEN

I have a remote system out in the garden shed near the antenna mast that has an airspy for 1090 ADS-B and a dongle for 978Mhz UAT.

airspy_adsb is invoked as:

/home/pi/airspy/airspy_adsb -c 192.168.1.151:30104:Beast -b -g 19 -x &

dump978 is invoked as usual with the command ending in:

/usr/bin/socat -u TCP:192.168.1.151 30001

Piaware/Skyview gets everything needed sent via ports 30104 (airspy) and 30001 (UAT dongle) without using beast splitter. MLAT gets handled via FA’s MLAT client just as if I had a 1090 dongle attached to the system. Flights from the UAT feed show up on Skyview and in FA’s tracking.


#93

The Piaware doesn’t “see” the 30104 directly, only the 30005. Your dump1090 sends data from 30104 to 30005 port, that’s why you don’t need beast-splitter:

–net-bi-port 30004,30104 --net-bo-port 30005

Originally I didn’t have beast-splitter configured and I was using airspy-adsb to send directly to both 30104 and 30005 (like you do with dump1090).
That worked too, but airspy-adsb doesn’t copy what comes in (or I don’t know how) so I needed the --net option from beast-splitter.

However, this is my updated setup, that I think that goes around the issue of back-feeding MLAT to FA servers:

The autoconfigured dump1090 default for the SD card looks like this (there is no output on 30005):

.# Generated automatically by fa_config_generator
.# This file will be overwritten on reboot.
DECODER_OPTIONS="–max-range 360"
$ --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104"
JSON_OPTIONS="–json-location-accuracy 2"
RECEIVER_OPTIONS="–net-only --net-bo-port 0 --fix"

Hmm, maybe I should switch back to the add-on package, looks cleaner…
PS: I connect also the FR24 to localhost:30005 (Beast TCP).


#94

The --connect of the beast splitter should be an outward facing arrow wherever it goes as it pushes data out by connecting to the port.
(It would connect to dump1090-fa to feed it the data it receives, servers can have multiple clients on the same port)
Not sure how it could input data that way.
Therefore the airspy data would not be getting to the beast splitter in this config.

But if your setup is working in that config i won’t bug you about it :stuck_out_tongue_winking_eye:

The new dump1090 versions are aware of mlat packages and won’t forward them so you don’t really need to worry about that i believe. (There is a command line option to forward mlat packets but you won’t turn that on will you? :slight_smile: )


#95

There’s some older airspy_adsb configuration posts here that people copy&paste from that need to get a blindfold and a cigarette. There’s absolutely NO need for the “-l somehost:30005” command on airspy_adsb when using a standard Piaware package install unless you want to participate in Airspy’s MLAT.

Exactly. Forwarding MLAT stuff off of the local network to non-FA places takes some serious command gymnastics that I want no part of. FA-derived MLAT data can easily be used within the local network for stuff like VRS quite easily.


#96

See, that’s what I don’t get. I have asked before what’s the difference between --connect and --listen.
Doesn’t “–connect” usually mean a client? Generally speaking.
Then beast-splitter only input is the --net?
If so, the port 30104 is written (output mode) by both beast-splitter and the fa-mlat client. Isn’t that a conflict?

I would agree if the redirect to 30005 is done by dump1090 (like in your case).
But, in the case of Piaware SD card install, it looks like that’s not there (and gets re-written at reboot by the code that Obj pointed to).
There has to be a way for the data to get to 30005 in order to be sent to FA servers.


#97

No that is not a conflict. A port is not simply written to, a connection is first established.
A server can accept connections from multiple clients on the same port, so the correct way would be to separate the arrows on port 30104 both transporting data to dump1090.

listen means server mode and connect means client mode. (–net also means client mode for beast splitter)
But your diagram is showing the DATA flow, not which program is client and which program is server. (You would need to either annotate this or invent some graphical representation if you want to show it)

Anyway this all won’t work correctly with piaware MLAT as you are feeding data from two receivers.
In case the UAT is already connected to it’s own piaware you can devise a method to display the data on this dump1090 though.
You would have to change the beast splitter config and stop piaware from changing it.
A packet install would be easier to avoid configuration options being overwritten.

On a packet install you would need to modify the following defaults (this is one possible configuration to achieve what i described above):
Replace --net-bo-port 30005 with --net-only in /etc/default/dump1090-fa
Install beast-splitter.
Remove the listen 30005 option in /etc/default/beast-splitter
Set ENABLED to yes in /etc/default/beast-splitter
Put a # in front of the INPUT_OPTIONS="--serial /dev/beast" line
Remove # in front #INPUT_OPTIONS="--net remotehost:remoteport" change to IP:30005 so it connects to you UAT source.

For the airspy: Listen on 30005 and connect to 30004 so both piaware and dump1090 get their data from the airspy.

Now if your separate piaware instance running on the UAT device is generating MLAT data and you want to have in the dump1090 on this device then you can use the piaware-config on the UAT device to make it connect to the dump1090 on this this device

piaware-config mlat-results-format           "beast,connect,localhost:30104 beast,listen,30105 beast,connect,AIRSPY-IP:30104" 

There are of course other possible setups i just wanted to explain a bit more.

I might have also forgotten something. Also i’m unsure which programs will try reconnect their client after say 60 seconds when they couldn’t make a connection on startup.
For example piaware if it can’t find data on 30005 it will try again 60 seconds later.


#98

It’s not necessary; there are several ways of setting this up; receiver-type relay happens to use beast-splitter as it’s designed to handle any case where there is a single input into the system. For example, it’ll also talk to a Beast over a serial port (receiver-type beast, which is mostly identical to relay), and there can be only one user of the serial port in that case. It’ll also handle a remotely-hosted source of data (e.g. an external radarcape).


#99

I wish you give that lengthy explanation before I switched to SD card install :smiley:
Now, those settings are controlled by the software that Obj made, they will be overwritten at reboot.
So either I need to work with what I have or… reinstall PiAware as add-on package. What’s tedious is that I need remake all the changes that you posted with the display of RSSI… I like those.

For now it seem to work for ADS-B (sending mssg to FA and FR24), and I might not do UAT anymore.


#100

I have put the receiver type on “other” because that will disable beast-splitter. So it makes more sense to me.
However, now I have something else:
“mlat-client(780): Beast-format results connection with ::1:30104”
How do I disable ipv6? On add-on it never tried this…


#101

You are disabling it for FR24?
Just disable it like the last time you disabled it?
Don’t think you can disable it just for piaware.