AirNav Systems Forum
AirNav RadarBox and RadarBox24.com => AirNav RadarBox and RadarBox24.com Discussion => Topic started by: GlynH on November 18, 2020, 07:26:58 PM
-
I think I’ve mentioned here recently that I am over the moon with finally being able to have my own device sat on the network unattended, feeding both RB24 and FR24 and still be able to use the RadarBox software locally for the first time since I originally got into the hobby back in 2008!
In the two weeks since I setup the Raspberry Pi/FlightStick I notice I am now sat at the number 5 position in the UK ranking and number 83 Globally which is a result especially as I am tracking less than a quarter of the aircraft now than I was back in 2008!
Now I am looking to expand my horizons a little bit I seem to be hitting a brick wall with regard to using the OpenADSB app on my own phone to connect to my own data on my own device on my own network.
OpenADSB can use unfiltered data from ADSBExchange which should be good for military and other types of aircraft and it also has the option to connect to your local dump1090 to display your own contacts as this has always been my primary interest but here is where my problem begins.
Looking at the Pi it is not showing dump1090 as being installed so I am unable to determine what port I need to connect to it.
I suspect it is somehow integral and wrapped up in rbfeeder process being the software I installed from AirNav to feed the RadarBox network which incidentally takes up 20% of my CPU time.
Is this assumption correct and is there anything I might be able to do to rectify this so I can use the app I paid for to view my own data as going forward there might be further instances where I need an ‘industry standard’ type of connection to access my own data?
A question for Support I guess but as I’m still waiting for an answer to a question I asked over a week ago I thought I’d throw it out here first...
Thanks & kind regards,
-=Glyn=-
-
Run this command to list the available ports
NOTE: Increase the width of PuTTY window to see all columns
sudo netstat -anp | grep -w LISTEN
-
Thanks for the reply...this is what I see;
sudo netstat -anp | grep -w LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 536/sshd
tcp 0 0 0.0.0.0:32088 0.0.0.0:* LISTEN 464/rbfeeder
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 798/smbd
tcp 0 0 0.0.0.0:32004 0.0.0.0:* LISTEN 464/rbfeeder
tcp 0 0 0.0.0.0:32008 0.0.0.0:* LISTEN 464/rbfeeder
tcp 0 0 0.0.0.0:32457 0.0.0.0:* LISTEN 464/rbfeeder
tcp 0 0 0.0.0.0:32458 0.0.0.0:* LISTEN 464/rbfeeder
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 798/smbd
tcp 0 0 0.0.0.0:32459 0.0.0.0:* LISTEN 464/rbfeeder
tcp6 0 0 :::8754 :::* LISTEN 529/fr24feed
tcp6 0 0 :::22 :::* LISTEN 536/sshd
tcp6 0 0 ::1:3350 :::* LISTEN 489/xrdp-sesman
tcp6 0 0 :::3389 :::* LISTEN 521/xrdp
tcp6 0 0 :::445 :::* LISTEN 798/smbd
tcp6 0 0 :::32004 :::* LISTEN 464/rbfeeder
tcp6 0 0 :::32008 :::* LISTEN 464/rbfeeder
tcp6 0 0 :::32457 :::* LISTEN 464/rbfeeder
tcp6 0 0 :::32458 :::* LISTEN 464/rbfeeder
tcp6 0 0 :::32459 :::* LISTEN 464/rbfeeder
tcp6 0 0 :::139 :::* LISTEN 798/smbd
I did run a port scanner against the Pi the other day in an attempt to see what ports might be open and threw in some other ports I've seen in related software to no avail.
Thanks & kind regards,
-=Glyn=-
-
From your output of netstat command, I have copied lines pertaining to rbfeeder, and added a column at right describing each port. There are two ports (32008 & 32458) about which I dont know. Mostlikely these are ports for inputting/outoutting data in some special format. Try tem by typing in your browser these addresses
IP-of-Pi:32008
IP-of-Pi:32458
Extracted from netstad command's output:
NOTE:
Scroll right to see in full
tcp 0 0 0.0.0.0:32088 0.0.0.0:* LISTEN 464/rbfeeder Output for ANRB Windows
tcp 0 0 0.0.0.0:32004 0.0.0.0:* LISTEN 464/rbfeeder Input-MLAT results feedback.
tcp 0 0 0.0.0.0:32008 0.0.0.0:* LISTEN 464/rbfeeder ???????
tcp 0 0 0.0.0.0:32457 0.0.0.0:* LISTEN 464/rbfeeder Output-Beast format.
tcp 0 0 0.0.0.0:32458 0.0.0.0:* LISTEN 464/rbfeeder ??????
tcp 0 0 0.0.0.0:32459 0.0.0.0:* LISTEN 464/rbfeeder Output-Basestation format.
-
Thanks for the info.
Yeah I tried all of the ports shown in my port scan in a web browser to no avail as it either sat there spinning or returned;
This page isn't working at the moment
xxx.xxx.xxx.xxx sent an invalid response.
ERR_INVALID_HTTP_RESPONSE
I believe that OpenADSB might be looking for port 80 or 8080 from dump1090 so a standard http port that might not be present in the version bundled with rbfeeder?
The port number can be configured from within OpenADSB but of course it has to exist in the first place!
Thanks & kind regards,
-=Glyn=-
-
Easy solution to have standard ports matching other software like OpenADSB and AdsbX :
Step-1: Install dump1090-mutability
sudo apt install dump1090-mutability
sudo usermod -a -G plugdev dump1090
sudo systemctl stop rbfeeder
sudo systemctl restart dump1090-mutability
To set your latitude and longitude, give following command. Accept all other default settings by pressing Enter key.
When asked "address to bind", remove default value "127.0.0.1" to make it blank, then press Enter key.
sudo dpkg-reconfigure dump1090-mutability
Step-2: Reconfigure rbfeeder to deactivate its integral dump1090
sudo nano /etc/rbfeeder.ini
under [network], modify line:
network_mode=false
To
network_mode=true
Save (Ctrl+O) and close (Ctrl+x) the file.
restart rbfeeder
sudo systemctl restart rbfeeder
Step-3: Reconfigure fr24feed to get data from dump1090-mutability
sudo nano /etc/fr24feed.ini
Change line:
host="127.0.0.1:32457"
To
host="127.0.0.1:30005"
Save (Ctrl+O) and close (Ctrl+x) the file.
Restart fr24feed
sudo systemctl restart fr24feed
-
Now I am looking to expand my horizons a little bit I seem to be hitting a brick wall with regard to using the OpenADSB app on my own phone to connect to my own data on my own device on my own network.
OpenADSB can use unfiltered data from ADSBExchange which should be good for military and other types of aircraft and it also has the option to connect to your local dump1090 to display your own contacts as this has always been my primary interest but here is where my problem begins.
Looking at the Pi it is not showing dump1090 as being installed so I am unable to determine what port I need to connect to it.
You can not modify ports on RB feeder to match openADSB, as port numbers in RB feeder are hard coded. However you may be able to change settings of openADSB to match rbfeeder's ports, just as you have done in case of FR24 feeder.
Check settings of openADSB App to find what port number it is configured to by default. If that port number is 30005, it means it is set to receive Beast data from port 30005 of any standard dump1090.
If above is true, then in settings of openADSB app, change that port number from 30005 to 32457, as rbfeeder uses this port for Beast output instead of standard 30005
-
Easy solution to have standard ports matching other software like OpenADSB and AdsbX :
Easy for you to say! :)
I'm definitely going to give that a go but if I could just check a few things please before I take the plunge;
I notice that after installing dump1090-mutability I issue the command to stop rbfeeder. Do I have to stop FR24 as well?
After configuring dump1090 and altering the configs for both rbfeeder and fr24feed will everything start up automatically after a reboot as it does at the moment?
Does dump1090 add itself to the repository source list so the usual sudo apt update / sudo apt full-upgrade will look in the correct place for future updates much like rbfeeder and fr24feed does?
Does this install any of the maps etc. that I see referred to? I don’t particularly want any bloatware etc. installed but curious whether anything else gets installed this way?
And finally will I still be able to feed the RadarBox Legacy program from port 32088?
Thanks once again for your full & detailed explanation and sharing your knowledge.
Kind regards,
-=Glyn=-
-
OpenADSB does not have a default port and can be set for any port number required as I understand it.
However reading the app synopsis it suggests port 80 which leads me to believe it is looking for a standard http port such as one that would drive a webpage or something?
I have already tried inputting every port number I can think of to no avail which suggests it does not understand Beast, RAW, Basestation or the usual datatype associated with feeders.
All moot now as I intend to follow the instructions in your previous post to install a standard dump1090 as every other feeder of this type offers.
Even now after all this time why do AirNav still insist on doing things differently from the standard approach which can make things difficult for the end user when looking to integrate with other applications?
What purpose does it serve in this day & age...<sigh>
Thanks & kind regards,
-=Glyn=-
-
I have absolutely no idea about app openADSB.
Where the app "openADSB'" will be installed, on RPi or another machine (desktop/laptop/phone)?
The dump1090-mutability installation automatically installs a web server (lighttpd). The dump1090-mutability serves a map through this web server, and this map can be viewd on any computer/phone on the same local network in a web browser at following address:
IP-of-Pi/dump1090/gmap.html
From what you mentioned about openADSB app using port 80,I suspect that if both dump1090-mutability and openADSB are installed on same machine (i.e. RPi), it may result in a conflict.
-
Thanks for the reply as always abcd,
OpenADSB is a paid iOS app that I have installed on both my iPhone & iPad.
http://openadsbapp.com/
I would think that's exactly how it works by connecting to the Pi over port 80 (or 8080 maybe) and takes its data from there so no conflict should be present as it will only be reading data from that port.
Thanks & kind regards,
-=Glyn=-
-
OpenADSB is a paid iOS app that I have installed on both my iPhone & iPad.
Great. Definitely there will be no conflict as dump1090-mutability and openADSB are installed on different machines.
http://openadsbapp.com/
I would think that's exactly how it works by connecting to the Pi over port 80 (or 8080 maybe) and takes its data from there so no conflict should be present as it will only be reading data from that port.
You have misunderstood it. Port 80 or 8080 is the port on your iPhone/iPad on which the openADSB will serve its table/map. It has absolutely nothing to do with RPi's port 80 or 8080.
As far as fetching data from RPi is concerned, the openADSB app on your iPhone/iPad can do it by pulling any one of the following data streams fron RPi:
- Beast format data from RPi's port 30005
- Basestation format data from RPi's port 30003
- json format data by pulling files fro RPi's data folder which stores these files.
- html map file directly from RPi into iPhone/iPsd's browser at following address:
IP-OF-PI/dump1090/
IP-OF-PI/dump1090-fa/
I am not aware what format data openADSB app pulls from RPi's dump1090 (mutab or mr or fa). Anyway it is not important for user, as this should be preconfigured in openADSB. The user will have to add only IP address of the Pi in the openADSB settings.
-
I notice that after installing dump1090-mutability I issue the command to stop rbfeeder. Do I have to stop FR24 as well?
No, you dont have to stop fr24feed.
The rbfeeder was using the Dongle, and dump1090-mutability after installation has failed as it did not find any free Dongle. The rbfeeder was stopped manually to free the Dongle, and after that the dump1090-mutability was restarted. Now there was a free Dongle available, and dump1090-mutability grabbed it and started working normally.
In the next step, rbfeeder's network_mode was changed from false to true, and after that rbfeeder was restarted. With changed setting, the rbfeeder wont look for Dongle (which is no more available, as it is being used by dump1090-mutability). It would connect to port 30005 to grab data from dump1090-mutability, and start working flawlessly.
After configuring dump1090 and altering the configs for both rbfeeder and fr24feed will everything start up automatically after a reboot as it does at the moment?
YES, sure.
Does dump1090 add itself to the repository source list so the usual sudo apt update / sudo apt full-upgrade will look in the correct place for future updates much like rbfeeder and fr24feed does?
YES, sure.
In fact the debian.org/raspberrypi.org have added the dump1090-mutability to Debian/Raspbian repository list when they released Debian/Raspbian Buster.
Does this install any of the maps etc. that I see referred to? I don’t particularly want any bloatware etc. installed but curious whether anything else gets installed this way?
The dump1090-mutability package comes with integral map, and the map is served by web server lighttpd. The lighttpd is installed automatically when dump1090-mutability is installed.
And finally will I still be able to feed the RadarBox Legacy program from port 32088?
YES, sure.
.
-
I'm not sure that's the case though is it?
OpenADSB specifically asks for a port number to connect to in order to display aircraft on its map so I assume it polls /data/aircraft.json? Not sure if this is presented when installing rbfeeder to begin with?
The page in the app settings asks for a port number - see photo attached.
Here is what the author states;
----------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----------
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.
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.
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 and just look at that CPU utilization of rbfeeder at 61.1% although in fairness through the web interface it usually sits @20%;
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
464 root 20 0 158576 16144 5612 S 61.1 0.4 2663:53 rbfeeder
607 root 20 0 17776 11044 5652 S 7.6 0.3 177:40.76 mlat-client
529 fr24 20 0 160708 15120 5716 S 7.3 0.4 270:51.49 fr24feed
348 avahi 20 0 6408 3384 2556 S 0.3 0.1 17:17.16 avahi-daemon
964 pi 20 0 160924 40712 22996 S 0.3 1.1 16:40.68 lxpanel
27577 pi 20 0 10408 3052 2532 R 0.3 0.1 0:00.08 top
1 root 20 0 33740 8168 6492 S 0.0 0.2 0:08.09 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.16 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
9 root 20 0 0 0 0 S 0.0 0.0 0:13.18 ksoftirqd/0
10 root 20 0 0 0 0 I 0.0 0.0 5:05.91 rcu_sched
11 root rt 0 0 0 0 S 0.0 0.0 0:00.07 migration/0
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1
14 root rt 0 0 0 0 S 0.0 0.0 0:00.06 migration/1
15 root 20 0 0 0 0 S 0.0 0.0 0:05.38 ksoftirqd/1
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2
19 root rt 0 0 0 0 S 0.0 0.0 0:00.06 migration/2
20 root 20 0 0 0 0 S 0.0 0.0 0:05.51 ksoftirqd/2
23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3
24 root rt 0 0 0 0 S 0.0 0.0 0:00.06 migration/3
Even its time display looks to be the odd one out...<sigh>
Had I known then what I know now I would have followed one of your different tutorials and installed dump1090 and then took the decision whether or not to add rbfeeder to it rather than start off with rbfeeder and then end up banging my head on the wall in a futile attempt to use my data from my computer across my network in another application of my choice.
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----------
Plan B coming up methinks...
-=Glyn=-
-
Fantastic explanation abcd! Thanks very much for that...just what I needed.
You really are the fount of all knowledge when it comes to everything Pi.
Now I have options that I understand! Wish me luck...I'm going in!:)
On a semi-related issue I notice my Max range has dropped from 296->267Nm and with it my ranking has slipped down a few places.
With a properly installed & working dump1090 another advantage might be getting to play around to see what influence Gain might have on Max Range if any.
But that will be for another day (if at all) as I have already achieved my ultimate goal of a stand-alone, networked, reliable Virtual Radar so wouldn't ever want to compromise that.
Thanks again & kind regards,
-=Glyn=-
-
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/
.
-
----------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.
-
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
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.
.
-
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=-
-
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=-
-
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=-
-
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=-
-
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.
-
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=-
-
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.
sudo apt-get purge mlat-client
sudo apt-get install mlat-client
.
-
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=-
-
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=-
-
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.
.
-
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=-
-
I have never checked status of mlat-client.
It is started, stopped, restarted by rbfeeder as and when needed by rbfeeder.
-
IMPORTANT:
I have noted an error in this line:
mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client --results beast,listen,30104
It should be
mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client --results beast,connect,127.0.0.1:30104
EXPLANATION:
The dump1090 already uses port 30104 to "listen".
As only one software can use any port to "listen", if RB24 feeder mlat-client is also configured to "listen" to same port, it will cause conflict and failure of one of the two: either dump1090 or mlat-client.
Even when port 30104 is blocked by dump1090 for "listen', it is available for connection by multiple other software using "connect". That is what is done in the correct command.
-
And I knew I shouldn't have messed with a working system.
I altered the file as you suggested above, rebooted the Pi and it won't boot!
I put I an older SD Card and it now boots but not feeding RB24 or FR24.
I have put the original SD Card in another Pi and taken a look in /etc/default but don't see rbfeeder.ini in there so I must have deleted it?
Would that stop the Pi from booting?
I now need to see if I have another copy of rbfeeder.ini kicking around and try to copy it to the original SD Card and see if that fixes it.
-=Glyn=-
*UPDATE* Actually there is an rbfeeder.ini in /etc/ although I notice that has the original line referencing python3.5 where I had modified mine to read python3.7 at some point.
HELP!
-
OK what I had to do was use the SD Card backup I took before I installed dump1090-mutability so at least I have a working system again albeit using rbfeeder and its built-in dump1090
I'm just in the process of updating the system as its found 69 files to update since I took the backup.
Then assuming all is OK I think I might just backup this working system to another SD Card so it should be easy to roll back should I need it in the future.
Then I'll work through this thread to install dump1090-mutability and alter rbfeeder.ini to reflect the changes then hopefully I should be back to where I started from earlier this evening!
I can't remember what else I might have altered in the weeks since I took the last backup so I'm hoping it was only the usual Raspberry Pi updates.
I suppose this is as good a place to ask as I need to install dump1090 again - should I go for -mutability once again or -fa / readsb as I was advised on another forum that the former is unmaintained?
If I need to change then this seems to be as good a time as any...
Thanks & kind regards,
-=Glyn=-
-
The Map of dump1090-fa is more beautiful and has more features than map of dump1090-mutability.
Engine (receiver-decoder) wise currently both are more or less same. However in future versions of FA, there may be improvements in the engine as well.
You can install dump1090-fa instead of dump1090-mutability if you want.
To install dump1090-fa, give following commands
wget https://flightaware.com/adsb/piaware/files/packages/pool/piaware/p/piaware-support/piaware-repository_4.0_all.deb
sudo dpkg -i piaware-repository_4.0_all.deb
sudo apt-get update
sudo apt-get install dump1090-fa
sudo reboot
NOTE:
With dump1090-fa, the configuration of rbfeeder and fr24feed are identical to those advised earlier with dump1090-mutability.
I would recommend to use a spare microSD card and follow procedure below:
Bake a Pi - OPTION-2 (CLICK HERE) (https://www.airnavsystems.com/forum/index.php?topic=10201.msg187851#msg187851)
- Raspbian Lite image
- dump1090-fa
- Radarbox24 data feeder
- Additional data feeders.
.
.
Flow Chart
(https://i.postimg.cc/QdpYV310/RB24-feeder-Flow-Chart.png)
Default Config (Without Mlat)
(https://i.postimg.cc/C1KcvntQ/RB24-Config-Default.png)
Config Mlat Enabled
(https://i.postimg.cc/bvpCtBR8/RB24-feeder-Config-MLAT-Enabled.png)
-
Thanks again abcd.
I won't go with the Raspbian Lite image as I already have a fully working, setup & configured Pi from a standard setup I made some time ago running rbfeeder & FR24 so I'll just go through the process like last time but with -fa instead of -mutability this time round.
I guess I should amend the;
#mlat_cmd=/usr/bin/python3.5 /usr/bin/mlat-client
shown in the screenshot above to read;
mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client --results beast,connect,127.0.0.1:30104
as per your post above?
Thanks & kind regards,
-=Glyn=-
-
I guess I should amend the;
#mlat_cmd=/usr/bin/python3.5 /usr/bin/mlat-client
shown in the screenshot above to read;
mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client --results beast,connect,127.0.0.1:30104
as per your post above?
The command "mlat_cmd=/usr/bin/python3.5 /usr/bin/mlat-client" with correct python version 3.7 is built into rbfeeder. That is why by default in the file /etc/rbfeeder.ini it is commented out (starts with #) and is therefore ineffective. In nano any line starting with # appears blue to highlight at a glance that it is commented out and is ineffective.
When rbfeeder is started, the builtin correct command executes automatically, provided you have removed # from start of line "#autostart_mlat=true" (in nano this line will change its color from blue to white when # is removed)
Leave the line "#mlat_cmd=/usr/bin/python3.5 /usr/bin/mlat-client" as is. Since it is commented-out, in nano it will show blue color. Let it stay blue colored.
In case you want to over-rule builtin command and use a custom command with additional parameter such as "--results beast,connect,127.0.0.1:30104" (for feeding results to dump1090 fa or mutability), you have to use "mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client --results beast,connect,127.0.0.1:30104". Since you want it to execute, there should be no # at its start (the line will show white color in nano).
In case the custom command gives issues, simply make it ineffective by placing a # at it's start. Upon placing a # at start of line, it's color will turn blue in nano confirming that it is commented-out and is ineffective.
-
So once again with your help abcd I seem to have muddled through and successfully installed dump1090-fa and figured out that the url to view the maps is now Pi_IP/dump1090-fa instead of the previous Pi_IP/dump1090-mutability/gmap.html - does that sound right?
The thing is though when I open the Skyview map view (you are right the maps are much nicer) my location and range rings are not showing despite being toggled on under Settings. Is this something that only appears after it has been running a while or should it as I expect show up straight away?
Interestingly when I type sudo systemctl status dump1090-fa it shows the gain is already set to -10 which saves me doing it!
But if I wanted to check or make any changes to the config how best to do it please?
Thanks & kind regards,
-=Glyn=-
-
When you add latitude and longitude to config file, it sets location of receiver (i.e. center of rings), which in turn enables dump1090 to plot the rings.
In dump 1090-mutability you added lat & lon when you ran command "sudo dpkg-reconfigure dump1090-mutability". With dump1090-fa, this command is not available and you have to add your lat & lon by editing file /etc/default/dump1090-fa.
sudo nano /etc/default/dump1090-fa
Scroll down to following line
RECEIVER_OPTIONS="--device-index 0 --gain -10 --ppm 0"
Add you latitude & longitude, so that the line becomes like this
RECEIVER_OPTIONS="--device-index 0 --gain -10 --lat xx.xxxx --lon yy.yyyy --ppm 0"
(Replace xx.xxx and yy.yyyy by their actual values)
Save file (Ctrl+O) and close editor (Ctrl+x)
Restart dump1090-fa
sudo systemctl restart dump1090-fa
Ring should appear after restart. If they dont appear, clear browser cache (Ctrl+Shift+Delete) and reload browser (Ctrl+F5).
-
Yup...that worked! You're a star abcd!
I did input my lat/lon to 6 decimal places and that was reflected when I typed sudo systemctl status dump1090-fa so that seemed to work.
The rings were then displayed at 100, 150 & 200 miles but to match what is displayed in RadarBox I edited /usr/share/dump1090-fa/html/config.js to add rings at 50 & 250 miles;
DefaultSiteCirclesCount =5; (was 3)
DefaultSiteCirclesBaseDistance = 50; (was 100)
So I'm going to sit back and enjoy it while it lasts...I'll let the dust settle now that everything seems to be working so hopefully no more questions on this particular subject from me for a while.
Famous last words...:)
Thanks very much again for sharing your knowledge and your patience abcd...I wouldn't have made it this far without your help.
-=Glyn=-
-
Next Enhancement:
Click the link below. On the page opened, scroll down to following item, and implement it.
(8) ADD TERRAIN LIMIT RINGS
https://forum.radarbox24.com/index.php?topic=10201.msg187851#msg187851 (https://forum.radarbox24.com/index.php?topic=10201.msg187851#msg187851)
.
-
Stop teasing abcd...I've already said I'm going to sit back & enjoy it and now you're finding me more mods to do! :)
I haven't seen what the terrain enhancement looks like but I like the map I see and wouldn't want to clutter it up nor would I want to break my Pi again!
Due to that short 2 hour outage last night I've already slipped 66 places down the Global ranking and gone from 6 to 13 in the UK ranking.
Won't stop me looking for enhancements though so I'm always open to suggestions...:)
Thanks & kind regards,
-=Glyn=-
-
If you are not in a mood to do any more mods, it is ok and fair, dont do it. However I will suggest that when you have some spare time, just brows it to see what it is.
I will also recommend that you brows the post What is the Maximum Range I Can Get? (https://www.airnavsystems.com/forum/index.php?topic=9251.0). The procedure given in this post does NOT involve any modification to your RPi. In fact even if you dont have any RPi or any other ADS-B receiver, still you can plot your maximum theoretical range curve on a map by this method.
-
I have already seen both the Terrain & Maximum Range website some time ago but as I live on a hill and my own range has hovered between 250-300 miles in the last 12 years I don't have much motivation to plot it theoretically! :)
Always on the lookout for something newer, faster, better though...
Thanks & kind regards,
-=Glyn=-
-
Well my moratorium on enhancements didn't last long!
Although I had seen it before I just installed wiedehopf's graphs for use with dump1090-fa and like what I see...thanks wiedehopf.
Now if I only knew how to use them to my advantage to optimise gain etc. :)
Thanks & kind regards,
-=Glyn=-