rbfeeder non-standard dump1090?

[abcd567]

It is really very simple.
Radarbox's integral dump1090 has custom port numbers, and does not have .json or map.

Radarbox feeder is capable to run in two modes
(1) using its own dump1090 
(2) using a third party decoder such as dump1090-mutability or dump1090-fa.

To activate the integral dump1090 of rbfeeder, simply in settings make network_mode= false.

To turn-off the integral dump1090 of rbfeeder, simply in settings make network_mode= true, and restart rbfeeder. Now the rbfeeder runs with its integral dum1090 deactivated, and waits to receive data from an external dump1090 at standard port 30005.

After turning-off the integral dump1090, if you install dump1090-mutability or dump1090-fa, everything works seamlessly, as these external dumps1090 use standard port 30005 to output data, and rbfeeder is also by default configured to receive data from external dump1090 on port 30005. You should then configure FR24's fr24feed and Planefider's pfclient to receive data on host 127.0.0.1, port 30005.

The dump1090-mutability serves a map in browser of Desktop/Laptop/Phone/Tablet at:
<IP-of-PI>/dump1090/

The dump1090-fa serves a map in browser of Desktop/Laptop/Phone/Tablet at:
<IP-of-PI>/dump1090-fa/
.

[abcd567]

----------snip----------
For your first question, yes OpenADSB can connect directly to your dump1090 server. Go to Settings (gear ⚙️ button) - Track Source - Edit - "+" to add a new source. You enter the host, port (if not port 80) and press Test Connection. To quickly switch trace sources, long-press the gear ⚙️ button.
----------snip----------

The Radarbox24's rbfeeder does NOT have a map server, so whatever port (80 or 8080 or anything else) you try, you wont get connected to dump1090 server. The dump1090-mutability installation automatically install a web server (lighttpd) which serves map on port 8080 or IP/dump1090/.

That's all well and good if you actually have dump1090 running but it looks to me like AirNav do something with dump1090 that is non-standard and ties you in preventing easy expansion outside the walled garden.

The rbfeeder's integral dump1090 is NOT walled garden, neither it tries to prevent expansion. It is customized to use port 32457 for beast format output, while stand-alone dump1090 uses port 30005 for beast format output. Wherever other App/feeder say use port 30005, just use 32457 and you get the same result.

I've tried all of the ports that might be associated with radarbox/dump1090/fr24 including the two you give above 30003 & 30005 to no avail. OpenADSB will just not connect.

Ports 30003 and 30005 are NOT server ports and do NOT serve the map. These are data ports and serve decoded data in Basestation and Beast format. As there is no map server associated with rbfeeder's dump1090, there is no map available to serve to either openADSB, or a web browser. It is in fact an stripped-down version of dump1090-mutability from which map has been removed.

If I type dump1090 on the Pi it returns;

pi@RaspberryPi-air:~ $ dump1090
-bash: dump1090: command not found

In fact it does not even show up in the list of running processes

The rbfeeder's dum1090 is not run as an independent app. It is encapsuled inside rbfeeder (possibly by virtualenv), and hence does not show up and is not accessable to user.

And although I believe it can be done I received this from PlaneFinder when I enquired about sharing my data with them;

----------snip----------
The points that you raise are very interesting - especially in relation to the non-standard AirNav software.
We would obvioulsy (sic) normally very much appreciate any data that you could share with us.
Unfortunately however we cannot accept your data using the current configuration.
The reason for this as that we have chose to only use standards based (or at least proven) software to be sure of data integrity.
----------snip----------

And in a second email when I pushed further and offered some suggestions as to how we might get things to work;

----------snip----------
The problem for us is that we only support the standalone version of dump1090 as this is a known entity to us.
----------snip----------

The above statement shows that the Planefinder Support have just disposed off your querry without carrying out thorough investigation.

The rbfeeder's dump1090 is infact dump1090-mutability (as it uses the same source code), and has all the same data integrity as dump1090-mutability has. The RB24 prorammers have however done following changes to their dump1090:
(1) Changed port number 30005 to 32457
(2) Changed port number 30003 to 32459
(3) Changed port number 30104 to 32004
(4) Removed the map files & folders  json, html etc, so no map files for openADSB or web browser
(5) Removed installation of web map server lighttpd, so there is no server at ports 80, 8080, or similar, hence openADSB cannot connect to these ports.

As far as data integrity and format is concerned, these are identical to dump1090-mutability. The difference is in port numbers only, and NOT in data integrity or format.

There seems to be a valid reason for eliminating map files and map server from rbfeeder's dump1090: they want users to use ANRB Windows software to view the map. For this purpose, the rbfeeder receives beast data from integral OR external dump1090 (whichever is in use), converts it to ANRB Windows software compatible format, and makes it available at port 32088 for use by ANRB Windows software.

[abcd567]

Just to verify Planefinder Support's reply is without investigation, do this:
If you have NOT yet installed dump1090-mutability, and have NOT yet changed any settings (i.e. still running rbfeeder's integral dump1090), do following

(1) Install Planefinder's feeder pfclient

Code: [Select]

wget http://client.planefinder.net/pfclient_4.1.1_armhf.deb 

sudo dpkg -i pfclient_4.1.1_armhf.deb   

(2) Go to this page to sign-in & configure

<IP-OF-PI>:30053

After completing signin/login formalities, the page will ask you host and port
In host field enter 127.0.0.1
In port field enter 32457
(with dump1090-mutability, this should be 30005, but with RB dump1090 it should b 32457)
Click Save button, then on same web page click "2 D Map" tab. You will see a map with planes. You may use this map for openADSB by using port 30053 instead of 80 in openADSB's settings.

.

[GlynH]

Easy solution to have standard ports matching other software like OpenADSB and AdsbX :

Well I finally plucked up the courage to follow your instructions and just wanted to thank you again abcd as it worked!

Just in case I cloned the MicroSDCard that the Pi runs from onto a blank one just in case something went wrong figuring it should be easy to just swap them over if I messed anything up!

Not that I ever doubted your instructions but was wary of my following them to the letter and conscious of my track record in breaking things that were working perfectly beforehand!

Both feeds are in place and uploading, I am now able to access my own Pi using OpenADSB and I have peace of mind that I have a standard installation at last.

I can even browse to the IP_Address_Raspberry Pi/dump1090/gmap.html and see aircraft on the locally generated map!

I did have 3 windows open during the process namely FR24 Local Feeder Status, FR24 Live Flight Tracker and RadarBox pointed as usual to my own Station number. I wish I had checked the Max Range there before I started as I just noticed my maximum range on RadarBox has increased from where it seemed to have settled down at 274Nm (was originally 295Nm) to 289Nm although guessing that is too soon to be anything I might have just done.

All looking good at the moment so thanks again. You are a star!

After the dust has settled I might look to feed somewhere else and if it is not listed in your instructions in this thread stand by for YAN - Yet Another Post! :)

Thanks & kind regards,
-=Glyn=-

[GlynH]

But...and there's usually a but...I don't see MLAT being displayed against my Station Page or Ranking entry on RadarBox any more so guessing I missed something setting up the dump1090-mutability config file maybe?

The local FR24feeder is still showing MLAT Yes and the line in rbfeeder.ini still has Lat,Lon, Alt & MLAT=True although the dump1090.ini doesn't have an MLAT entry or Alt only Lat & Lon.

I'm just going to take a look but if you can let me know what I might have missed into meantime that would be great!

Thanks & kind regards,
-=Glyn=-

[GlynH]

There's a separate MLAT Client that I have to install?

Ah...looks like I missed that one...hang on a minute...it is installed!

~ $ apt-cache policy mlat-client
mlat-client:
  Installed: 0.2.11
  Candidate: 0.2.11
  Version table:
 *** 0.2.11 500
        500 https://apt.rb24.com buster/main armhf Packages
        100 /var/lib/dpkg/status

~ $ sudo systemctl status mlat-client
● mlat-client.service - LSB: Multilateration client
   Loaded: loaded (/etc/init.d/mlat-client; generated)
   Active: active (exited) since Sun 2020-11-29 08:06:55 GMT; 1 day 9h ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/mlat-client.service

Nov 29 08:06:55 RaspberryPi-air systemd[1]: Starting LSB: Multilateration client...
Nov 29 08:06:55 RaspberryPi-air mlat-client[356]: Not starting mlat-client daemon, disabled via /etc/default/mlat-client ... (warning).
Nov 29 08:06:55 RaspberryPi-air systemd[1]: Started LSB: Multilateration client.

So there was the clue - so I have edited /etc/default/mlat-client from this;

# mlat-client configuration file
# This is a POSIX shell fragment.
# You can edit this file directly, or use
# "dpkg-reconfigure mlat-client"

# Start the client?
START_CLIENT="no"

# System user to run as.
RUN_AS_USER="mlat"

# User to log into the server as
SERVER_USER=""

# Logfile to log to
LOGFILE="/var/log/mlat-client.log"

# Input receiver type (dump1090, beast, radarcape_12mhz, radarcape_gps, sbs)
INPUT_TYPE="dump1090"

# Input host:port to connect to for Beast-format messages
INPUT_HOSTPORT="localhost:30005"

# Multilateration server host:port to provide data to
SERVER_HOSTPORT="mlat.mutability.co.uk:40147"

# Latitude of the receiver, in decimal degrees
LAT=""

# Longitude of the receiver, in decimal degrees
LON=""

# Altitude of the receiver, in metres
ALT=""

# List of result connections/listeners to establish.
# This should be a space-separated list of values suitable for passing to
# the --results option (see mlat-client --help for syntax)
RESULTS="basestation,listen,31003"

# Other arguments to pass to mlat-client
EXTRA_ARGS=""


To this;

# Start the client?
START_CLIENT="yes"

# Latitude of the receiver, in decimal degrees
LAT="My LAT"

# Longitude of the receiver, in decimal degrees
LON="My LON"

# Altitude of the receiver, in metres
ALT="My Antenna Height m ASL"

Feeling pretty proud of myself I issued sudo systemctl restart mlat-client but got a different error this time which pointed to Server-User so I changed that from;

SERVER_USER=""

To this;

SERVER_USER="mlat"

And all seems good in the world!

So now MLAT is being displayed against My Station entry and the line has reappeared on My Station page showing MLAT active (217 stations synced) but if someone can just confirm that's the way to do it please that would be grand!

Thanks & kind regards,
-=Glyn=-

[GlynH]

Spoke too soon...still not quite there...after a reboot no MLAT!

After checking configs and issuing various MLAT related commands it has reappeared on the RadarBox site as having MLAT enabled but once when I typed sudo systemctl restart mlat-client a box opened and prompted me for a password?

What should I check to ensure it is sorted automatically with no errors at startup?

If I type sudo systemctl status mlat-client I get the following output;

$ sudo systemctl status mlat-client
● mlat-client.service - LSB: Multilateration client
   Loaded: loaded (/etc/init.d/mlat-client; generated)
   Active: active (exited) since Mon 2020-11-30 21:32:20 GMT; 7min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 354 ExecStart=/etc/init.d/mlat-client start (code=exited, status=0/SUCCESS)

Nov 30 21:32:20 RaspberryPi-air systemd[1]: Starting LSB: Multilateration client...
Nov 30 21:32:20 RaspberryPi-air mlat-client[354]: Not starting mlat-client daemon, disabled via /etc/default/mlat-client ... (warning).
Nov 30 21:32:20 RaspberryPi-air systemd[1]: Started LSB: Multilateration client.

And even though I have the log file enabled;

LOGFILE="/var/log/mlat-client.log"

When I attempt to open the log it is always empty?

Thanks & kind regards,

-=Glyn=-

[abcd567]

Making any changes whatsoever in configuration of mlat-client is NOT required if you would have corrected a mistake in file rbfeeder.ini.

The mlat client is started by rbfeeder, passing parameters lat lon alt from file /etc/rbfeeder.ini.

The rbfeeder starts mlat-client using python. The line to star mlat client in file rbfeeder.ini is as follows:

[mlat]
autostart_mlat=true
mlat_cmd=/usr/bin/python3.5 /usr/bin/mlat-client

In this line, python3.5 is used,which was used in Raspbian Stretch. Now the distro is Buster which has python3.7. Because of this mistake,the rbfeeder could not start the mlat client. If you would have edited file /etc/rbfeeder.ini and in the line above would have changed python3.5 to python3.7, mlat would hae started working OK without any changes to mlat-client's default configuration.

[GlynH]

Ah that should explain it then although I never noticed any reference to the modified rbfeeder.ini line so apologies for missing that!

It was indeed referencing Python 3.5 and as I am on Buster I changed that to 3.7 as you suggest.

I *think* that particular line was commented out and in blue so I removed the # from the beginning of the line. If that was the case then how did mlat-client run before?

I have also put the mlat-client back to its default state as I posted above.

I rebooted and...and...no MLAT showing on RadarBox.

Typing the following returns;

$ sudo systemctl status mlat-client
● mlat-client.service - LSB: Multilateration client
   Loaded: loaded (/etc/init.d/mlat-client; generated)
   Active: active (exited) since Mon 2020-11-30 23:18:33 GMT; 13min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 350 ExecStart=/etc/init.d/mlat-client start (code=exited, status=0/SUCCESS)

Nov 30 23:18:32 RaspberryPi-air systemd[1]: Starting LSB: Multilateration client...
Nov 30 23:18:33 RaspberryPi-air mlat-client[350]: Not starting mlat-client daemon, disabled via /etc/default/mlat-client ... (warning).
Nov 30 23:18:33 RaspberryPi-air systemd[1]: Started LSB: Multilateration client.

Is that normal?

Thanks & kind regards,

-=Glyn=-

[abcd567]

I am not at my home right now, so cannot check output of command "systemctl status mlat-client".

However I am 100% positive about two things
(1) For buster, the mlat client line should be python3.7 and not python3.5
(2) Absolutely no changes are to be done in config of mlat-clent

May be there is some typo in your rbfeeder.ini file

Have a look at this post:

https://forum.radarbox24.com/index.php?topic=101771.msg440501#msg440501

If you dont find a typo in file, then better PURGE mlat-client (purge= remove software + remove all its config files), then reinstall it.

Code: [Select]

sudo apt-get purge mlat-client   

sudo apt-get install mlat-client   

.

[GlynH]

Ah OK abcd thanks for taking the time to reply as always.

Looking at that other post my rbfeeder.ini file reads;

mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client

But the post you referenced the line;

mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client --results beast,listen,30104

So do I have to append the line with --results beast,listen,30104 for it to work properly?

Well I tried it both with & without appending the line and it didn't seem to work.

Sorry to be a pain especially when you're not at home right now.

The main thing is it is still feeding so don't worry about replying straight away.

Thanks & kind regards,
-=Glyn=-

[GlynH]

Well I've just purged & reinstalled flat-client and as if by magic MLAT is live again on RadarBox!

I'm going to leave it until tomorrow and see how it goes and then reboot the Pi and see if it continues to work.

That's the plan anyway...

Interestingly I just typed;

~ $ sudo systemctl status mlat-client
● mlat-client.service - LSB: Multilateration client
   Loaded: loaded (/etc/init.d/mlat-client; generated)
   Active: active (exited) since Tue 2020-12-01 00:23:34 GMT; 4min 0s ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/mlat-client.service

Dec 01 00:23:34 RaspberryPi-air systemd[1]: Starting LSB: Multilateration client
Dec 01 00:23:34 RaspberryPi-air mlat-client[2171]: Not starting mlat-client daem
Dec 01 00:23:34 RaspberryPi-air systemd[1]: Started LSB: Multilateration client.
lines 1-10/10 (END)...skipping...
● mlat-client.service - LSB: Multilateration client
   Loaded: loaded (/etc/init.d/mlat-client; generated)
   Active: active (exited) since Tue 2020-12-01 00:23:34 GMT; 4min 0s ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/mlat-client.service

Dec 01 00:23:34 RaspberryPi-air systemd[1]: Starting LSB: Multilateration client...
Dec 01 00:23:34 RaspberryPi-air mlat-client[2171]: Not starting mlat-client daemon, disabled via /etc/default/mlat-client ... (warning).
Dec 01 00:23:34 RaspberryPi-air systemd[1]: Started LSB: Multilateration client.

But as it seems to be working I'm not panicking any more...

Thanks & kind regards,
-=Glyn=-

[abcd567]

Looking at that other post my rbfeeder.ini file reads;

mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client

But the post you referenced the line;

mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client --results beast,listen,30104

So do I have to append the line with --results beast,listen,30104 for it to work properly?

The part  "--results beast,listen,30104" connects the mlat calculation results (fed-back by Rsdarbox24 mlat server) to port 30104 of dump1090-mutability.

With this feedback added, the dump1090-mutability (which was originally displaying ads-b planes) will now start displaying both the ads-b and mlat planes on its map.

If you omit "--results beast,listen,30104" part from config file, everything will work as normal except that the dump1090-mutability map will stop showing mlat planes.

.

[GlynH]

Ah OK thanks so I'll keep the  "--results beast,listen,30104" part in then for full compatibility.

So...it ran all night and all of today with MLAT working as it should so I rebooted and typed;

 $ sudo systemctl status mlat-client

Which returned the following;

● mlat-client.service - LSB: Multilateration client
   Loaded: loaded (/etc/init.d/mlat-client; generated)
   Active: active (exited) since Tue 2020-12-01 19:30:15 GMT; 1min 13s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 365 ExecStart=/etc/init.d/mlat-client start (code=exited, status=0/SUCCESS)

Dec 01 19:30:15 RaspberryPi-air systemd[1]: Starting LSB: Multilateration client...
Dec 01 19:30:15 RaspberryPi-air mlat-client[365]: Not starting mlat-client daemon, disabled via /etc/default/mlat-client ... (warning).
Dec 01 19:30:15 RaspberryPi-air systemd[1]: Started LSB: Multilateration client.

MLAT showed up on MyStation on the RadarBox page shortly after the reboot, then disappeared before it reappeared after a while although MLAT has appeared to be flaky on RadarBox itself today. Typical...

Curious though as to what the error message means and if there is anything I need to do to stop it?

Thanks & kind regards,
-=Glyn=-

[abcd567]

I have never checked status of mlat-client.
It is started, stopped, restarted by rbfeeder as and when needed by rbfeeder.