Feed data to PiAware in AVR Format from External ADS-B Receiver

[wiedehopf]

@abcd567

--inConnectId 127.0.0.1:30104:MLAT \

That’s the wrong port anyway.
(30105 would be where you can get MLAT data, 30104 is a beast input port for dump1090-fa)

But yeah i wouldn’t do that, don’t think mm2 is MLAT aware.

[abcd567]

@wiedehopf

That’s the wrong port anyway.
(30105 would be where you can get MLAT data, 30104 is a beast input port for dump1090-fa)

I have NOT installed dump1090-fa (or mut or MR) on RPi.

As NO version of dump1090 exist on RPi, there is no data available on port 30105.

The only mlat data source is piaware which makes data available on port 30104

Here ModeSMixer2 is functioning as dump1090 (minus decoder). It supplies ADS-B data to Piaware on port 30005, and can receive mlat feed-back from piaware on port 30104. It also generates display (map).

[wiedehopf]

@abcd567

The only mlat data source is piaware which makes data available on port 30104

PiAware - Advanced Configuration Settings - FlightAware

The default settings set up three items:

beast,connect,localhost:30104 - this feeds multilateration results back to the local dump1090 for display on the map
beast,listen,30105 - this provides a Beast binary format feed of multilateration results that can be used by external systems, e.g., VRS
ext_basestation,listen,30106 - like 30105, but in a different format

inConnect connects to a port.
30104 would need to be a server/listen port, don’t think mm2 supports that.
(dump1090-fa only has listen/server ports and can’t do “connect”)

[abcd567]

By using
--inConnectId 127.0.0.1:30104:MLAT \
ModeSMixer2 receives Mlat data from Piaware and displays it on map. See the map below. The green planes are Mlat, white are Adsb:

[abcd567]

@wiedehopf

beast,listen,30105 - this provides a Beast binary format feed of multilateration results that can be used by external systems, e.g., VRS
ext_basestation,listen,30106 - like 30105, but in a different format

Here ModeSMixer2 is NOT an external system, it is replacement of the non-existing dump1090-fa

[wiedehopf]

@abcd567

–inServer arg Input server. Format: port

that’s what would go with 30104, not inConnect.

[abcd567]

@wiedehopf

inServer arg Input server. Format: port

For infeed, it is not necessary to use --inServer. The --inConnect works ok.

For output, --outServer is necessary, --outConnect wont work alone unless supported by netcat or socat

[wiedehopf]

@abcd567

The --inConnect works ok.

If that works, it’s implemented incorrectly.
Still doubtful that it works

You need to read up on what TCP listen vs TCP connect means.
Note that this is independent of the direction the messages/beast data flow.

If you want an analogy: Listen is a socket, and connect is a plug plugs into it.
(the port number also needs to match)

This is a plug: beast,connect,localhost:30104
Also a plug: --inConnectId 127.0.0.1:30104:MLAT
A plug with a plug can’t make a connection.

In contrast, look at working combinations of socket and plug:
socket: --inServerId 30104:MLAT
plug: beast,connect,localhost:30104

Or:
socket: beast,listen,30105
plug: --inConnectId 127.0.0.1:30105:MLAT

In the original configuration for mm2, it’s done correctly:
(inconnect with 30105 for MLAT)

@abcd567

Modify file mm2.sh, and replace following:lines

--inConnectId 127.0.0.1:30005:ADSB \ 
--inConnectId 127.0.0.1:**30105**:MLAT \ 

By following lines

--inConnect ip:port of your microADSB \
--outConnect beast:127.0.0.1:30005 \

[abcd567]

Oops… the map I posted was using original mm2.sh i.e. port 30105. I dont know how I posted 30104 believing it is the original config. Thanks for pointing out.

[SweetPea11]

@abcd567

Out of curiosity, replicated @ypcc1 's install

Remember that @ypcc1 is on an island in the middle of the Indian Ocean.

There is no other receiver within range to provide MLAT data for him to sync to.

S

[abcd567]

@SweetPea11

There is no other receiver within range to provide MLAT data for him to sync to.

The replication of @ypcc1 does NOT contain Mlat.

MLAT came up later as a separate issue.

Please see @ypcc1’s replication below: No mlat.

@abcd567

sudo nano /home/pi/mm2/mm2.sh

#!/bin/sh
/home/pi/mm2/modesmixer2 \
 --inConnect 192.168.0.10:30002 \
 --outServer beast:30005 \
 --web 8787 \
 --location 43.xxx:-79.xxx \

[wiedehopf]

The new setup without mm2 is working by the way:
https://flightaware.com/adsb/stats/user/ypcc1#stats-107377

2 glorious aircraft were received with 15 positions each.

[SweetPea11]

@abcd567

The replication of @ypcc1 does NOT contain Mlat.

MLAT came up later as a separate issue.

This was unclear hence my emoji.

S.

[wiedehopf]

@SweetPea11

no other receiver within range to provide MLAT

Yeah it would make sense to switch off MLAT:

sudo piaware-config allow-mlat no
sudo systemctl restart piaware

Not that it matters much, with that little traffic even MLAT shouldn’t be using barely any traffic.

[abcd567]

@wiedehopf

Yeah it would make sense to switch off MLAT:

sudo piaware-config allow-mlat no
sudo systemctl restart piaware

Not that it matters much,

(1) Yes, it matters. If you dont switch off mlat, or inConnectId 127.0.0.1:30104:MLAT, your piaware log will have hundreds of lines like this:

@abcd567

[877]: mlat-client(915): Beast-format results connection with ::1:30104: [Errno 111] Connection refused

(2) Now I remember I got 30104 instead of 30105 from above log line.

The 30105 was used in the install which had dump1090-fa installed, and Piaware was feeding mlat results to it on port 30104 by default.

[SweetPea11]

@wiedehopf

Not that it matters much, with that little traffic even MLAT shouldn’t be using barely any traffic.

Our experience at another remote site where we are using a cellular data feed shows a threefold increase in data when we turn MLAT on.

There are usually about 350 ADSB aircraft a day and 6 to 10 “other” aircraft a day with MLAT turned off. That consumes less than 20MB of data per day.

Turning on MLAT gives 1 or 2 MLAT aircraft a day but raises data usage to about 70 MB a day.

Barely any traffic!

Clearly not an issue if your feed is normal terrestrial broadband but worth considering if you are using cellular data.

S.

[ypcc1]

Hi Everybody,

As wiedenhopf mentioned, the receiver is working! Thank you to all for your assistance.

A couple of additional questions:

• Is the consensus that I turn off MLAT as to not fill up my Pi’s logs?
• How do I modify ‘collectd’ to show the proper AMSL?
• How do I modify my ‘combine1090’ configuration to also feed data to FlightRadar24? Can I add another line on the next port, then use the port at the receiver port for FlightAware?

sudo nano /etc/default/combine1090
TARGET=127.0.0.1:29002

Then install fr24feed via the following script:

sudo bash -c "$(wget -O - https://repo-feed.flightradar24.com/install_fr24_rpi.sh)"

Then modify the fr24feed.ini to point to the output of combine1090:

sudo nano /etc/fr24feed.ini
receiver=“beast-tcp”
fr24key=“(removed)”
host=“192.168.1.9:29002”
bs=“no”
raw=“yes”
logmode=“2”
windowmode=“0”
mpx=“no”
mlat=“no”
mlat-without-gps=“no”

[wiedehopf]

@ypcc1

host=“192.168.1.9:29002”

You can give it the existing beast port piaware is connecting to.

127.0.0.1:29005

Don’t modify the combine1090 configuration in the way you described, it would stop the setup from working.
I’m afraid you need to understand TCP, ports and the data flow a bit better to modify those settings
Anyway as i said it’s not necessary.

@ypcc1

• How do I modify ‘collectd’ to show the proper AMSL?

I don’t understand, the graphs don’t show altitudes.

To show the range correctly, you need to configure the location for dump1090-fa run by combine1090.

In /etc/default/combine1090, find the line
DECODER_OPTIONS="--max-range 360"

Add --lat and --lon like this.

DECODER_OPTIONS="--lat 50.1234 --lon 10.1234 --max-range 360"

Restart combine1090-dump:
sudo systemctl restart combine1090-dump

[wiedehopf]

It seems the FA stats page isn’t showing the positions received correctly in regards to the directional diagram:
https://flightaware.com/adsb/stats/user/ypcc1#stats-107377

Check that you don’t still have set the negative altitude there.
That may result in the statistics being confused. (not sure how the system handles something like this)

[ypcc1]

Hi wiedenhopf, abcd567 and SweetPea11,

I’ve made the changes you’ve suggested, these are:

1. MLAT has been disabled:

sudo piaware-config allow-mlat no
sudo systemctl restart piaware

2. I’ve modified the combine1090 file as follows - As I’m at -12 degrees in latitude, is using the minus symbol the correct expression?

sudo nano /etc/default/combine1090
SOURCES= 192.168.1.7
PORTS= 30005
TARGET=127.0.0.1:29001
RECEIVER_OPTIONS=“–net-only”
DECODER_OPTIONS=“–lat -12.xxxxxx --lon 96.xxxxxx --max-range 360”
NET_OPTIONS=“–net --net-heartbeat 60 --net-ro-size 1000 --net-ro-interval 0.2 --net-ri-port 29001 --net-ro-port 29002 --net-sbs-port 29003 -$
JSON_OPTIONS=”–json-location-accuracy 1"