MLAT

[bgaf]

I think the problem is in the server because around me there are more then 15 MLAT receivers and my XRnage receiver is connected to them. My Pi, when it was working normally, was connected to the most of them too. Last time there was connected receiver from Hungary. The others are from Bulgaria, Romania, Greece and so on. Today I will pay attention and to my router. Maybe it's blocking some traffic because of it's security options.

[bgaf]

Finally I got MLAT working. Up to now 15 stations has been synced to my receiver. The problem was in my router. It's security settings were blocking some traffic from my AP to the router. OpenWRT sometimes is more strict then it's needed. It was hard to believe but that's the truth.
My excuses to Radarbox. The software is working, despite the bugs it has.

@abcd567
Sir, thank you very much for paying attention to my problems. You've done tremendous efforts to support the community at all levels. Thank you once again.

[rw6ark]

   Hello dear!
I have two receivers on Rpi connected to the Internet through different providers, the first one with a white dynamic IP, the second through a NAT provider, a gray dynamic IP.
MLAT is active, receivers are successfully transmitting data to FA, FR24 and two private servers.
I recently installed feeder Radarbox and MLAT from github. Before the change of the IP provider, MLAT data is transmitted, there is synchronization with other receivers,
After changing the IP, MLAT is not transmitted to the radarbox server. (FA,  and two private servers will continue to operate) ADS-B planes on my receiver page show but no MLAT.
It turns out to restore connection, with the server by rebooting, or by the command: systemctl restart rbfeeder.
Tested many times. Always successful.

Client MLAT status: mlat-client.service - LSB: Multilateration client
   Loaded: loaded (/etc/init.d/mlat-client; generated; vendor preset: enabled)
   Active: active (exited) since Thu 2022-01-06 13:16:23 MSK; 5 days ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/mlat-client.service
Jan 06 13:16:23 Work-10-10-25-2 systemd[1]: Starting LSB: Multilateration client...
Jan 06 13:16:23 Work-10-10-25-2 mlat-client[308]: Not starting mlat-client daemon, disabled via /etc/default/mlat-client ... (warning).
Jan 06 13:16:23 Work-10-10-25-2 systemd[1]: Started LSB: Multilateration client.

What can I do to automate the process of connecting to MLAT Radarbox servers?
Sorry my English, this is a machine) Thanks for your reply!

[Runway 31]

I believe there is a bug in the MLAT client which requires you to either re-boot or to systemctl restart rbfeeder as you have noted.  Hopefully this will be fixed before to long

Alan

[abcd567]

I believe there is a bug in the MLAT client which requires you to either re-boot or to systemctl restart rbfeeder as you have noted.  Hopefully this will be fixed before to long

Alan

Restarting  by "sudo systemctl  restart rbfeeder" does NOT solve make mlat to work. Only Rebooting RPi makes mlat to work.

I don't think RB24 software developers are interested in removing this bug, as it is lingering on from Buster time and now continuing in next generation OS Bullseye since almost an year.

To check if mlat is active, run status command:

Code Select Expand


sudo systemctl status rbfeeder


If mlat-client is working OK, the output of status command should contain "/usr/bin/python3.9 /usr/bin/mlat-client". Please see below:

Code Select Expand


CGroup: /system.slice/rbfeeder.service ├─ 994 /usr/bin/rbfeeder └─1200 /usr/bin/python3.9 /usr/bin/mlat-client --input-type dump1090 --input-connect 127.0.0.1:32457 --server mlat1.rb24.com:40900 --lat 43.5>

 

If "/usr/bin/python3.9 /usr/bin/mlat-client" is missing, Reboot RPi and check again, it should appear after reboot.

Because RB24 has not solved this bug, instead of installing RB24 supplied mlat-client by command "sudo apt install mlat-client", I have built mlat-client from source code and installed on my RPi. I have uploaded these to my Github site, which also contains instructions as to how to install these for various OS (Buster, Buster-64bit, Bullseye, Bullseye-64bit)from where

https://github.com/abcd567a/mlat-client-package/blob/master/README.md



NOTE:
(1) After installing mlat-client, do not forget to restart rbfeeder by following command:

Code Select Expand


sudo systemctl restart rbfeeder 


 

[Runway 31]

Thanks abcd, only a reboot will get it working again

Alan

[abcd567]

Thanks abcd, only a reboot will get it working again

Alan

The RB24 supplied mlat-client fails to restart automatically whenever rbfeeder is restarted by command "sudo systemctl restart rbfeeder". A reboot is required to restart it properly.

If RB24 supplied mlat-client is replaced by mlat-client from my Github site, it will always start when rbfeeder is restarted by command "sudo systemctl restart rbfeeder". There is no need to reboot to start it.

It is very easy to check if rbfeeder could start mlat-client.
Just issue command "sudo systemctl status rbfeeder" and in output, look for line containing  "/usr/bin/python3.9 /usr/bin/mlat-client". If this line is missing, mlat client has not started.
Please see the relevant part of status command's output below.

Code Select Expand


     CGroup: /system.slice/rbfeeder.service
             ├─ 997 /usr/bin/rbfeeder
             └─1023 /usr/bin/python3.9 /usr/bin/mlat-client --input-type dump1090 --input-connect 127.0.0.1:32457 --server mlat1.rb24.com:40900 --lat 43.5>



.

[Runway 31]

Thanks abc it was the RB supplied feeder I was talking about.  You info will be very handy for users

Alan

[Aerotower]

A

Thanks abcd, only a reboot will get it working again

Alan

The RB24 supplied mlat-client fails to restart automatically whenever rbfeeder is restarted by command "sudo systemctl restart rbfeeder". A reboot is required to restart it properly.

If RB24 supplied mlat-client is replaced by mlat-client from my Github site, it will always start when rbfeeder is restarted by command "sudo systemctl restart rbfeeder". There is no need to reboot to start it.

It is very easy to check if rbfeeder could start mlat-client.
Just issue command "sudo systemctl status rbfeeder" and in output, look for line containing  "/usr/bin/python3.9 /usr/bin/mlat-client". If this line is missing, mlat client has not started.
Please see the relevant part of status command's output below.

Code Select Expand


     CGroup: /system.slice/rbfeeder.service
             ├─ 997 /usr/bin/rbfeeder
             └─1023 /usr/bin/python3.9 /usr/bin/mlat-client --input-type dump1090 --input-connect 127.0.0.1:32457 --server mlat1.rb24.com:40900 --lat 43.5>



.

abcd567 but if we put this at rbfeeder.ini the problem is solved or not?

[mlat]
autostart_mlat=true
mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client --results beast,connect,127.0.0.1:30104

[abcd567]

abcd567 but if we put this at rbfeeder.ini the problem is solved or not?

[mlat]
autostart_mlat=true
mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client --results beast,connect,127.0.0.1:30104

It did NOT solve for me.
The problem is NOT with rbfeeder or its configuration.
The bug  is in RB24 supplied mlat-client package.

You can check yourself by changing config the way you suggested, save the changes, then:
(1) Give command "sudo systemctl restart rbfeeder", then check if MLAT is working.
(2) If not, Reboot Pi and check again.

[abcd567]

In RB24 feeder's config file "/etc/rbfeeder.ini", under [mlat], the 2nd line (blue color) is by default commented out (i.e a # is placed at it's start).

As per standard computer coding practice, the lines which are commented out (i.e. have # at their start) are ignored during execution. Therefore the 2nd mlat line is also ignored by rbfeeder.

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

If the rbfeeder finds above line commented-out, it starts using it's in-built mlat command.

From file "/etc/rbfeeder.ini" it uses lat, lon, alt, and user parameters.

The rbfeeder's in-built mlat command is given below:

/usr/bin/python3.9 /usr/bin/mlat-client --input-type dump1090 --input-connect 127.0.0.1:32457 --server mlat1.rb24.com:40900 --lat 43.xxxxxx --lon -79.xxxxxx --alt 1xx --user EXTRPI000008 --results beast,connect,127.0.0.1:32004

The question is that why this commented-out line is there if it is not being used?
The reason is simple. If anyone wants to overide defaults, he can un-comment (i.e. remove # from start of line) and modify this line to suite his requirements. When this line is un-commented, it is no more ignored by rbfeeder, and whatever setting is given by user over-rides the in-built default setting.

If you see the default in-built line, it shows that mlat-results are fedback to RPi on port 32004:

   --results beast,connect,127.0.0.1:32004


Example 1:
If someone wants mlat-results feedback to go to port 30104 (to display RB24 mlat planes on map of dump1090-fa or dump1090-mutability), then he has to do this in file /etc/rbfeeder.ini:

(1) Scroll down to this line

#mlat_cmd=/usr/bin/python3.9 /usr/bin/mlat-client

(2) Remove # from its start (line's color will change from blue to white)

(3) Add "  --results beast,connect,127.0.0.1:30104 " to this line.

After above 2 changes, the line will become like this:

mlat_cmd=/usr/bin/python3.9 /usr/bin/mlat-client  --results beast,connect,127.0.0.1:30104

Example 2:
If someone wants mlat-results feedback to say port 30007 to VRS on his Windows computer at 192.168.0.21, then  he has to do this in file /etc/rbfeeder.ini:

(1) Scroll down to this line

#mlat_cmd=/usr/bin/python3.9 /usr/bin/mlat-client

(2) Remove # from its start (line's color will change from blue to white)

(3) Add "  --results beast,connect,192.168.0.21:30007 " to this line.

After above 2 changes, the line will become like this:

mlat_cmd=/usr/bin/python3.9 /usr/bin/mlat-client  --results beast,connect,192.168.0.21:30007