AirNav RadarBox
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
 


Author Topic: MLAT  (Read 72093 times)

0 Members and 1 Guest are viewing this topic.

bgaf

  • New Member
  • *
  • Posts: 13
Re: MLAT
« Reply #150 on: November 05, 2021, 10:14:08 AM »
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

  • New Member
  • *
  • Posts: 13
Re: MLAT
« Reply #151 on: November 05, 2021, 02:04:50 PM »
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.
« Last Edit: November 05, 2021, 02:07:04 PM by bgaf »

rw6ark

  • New Member
  • *
  • Posts: 1
Re: MLAT
« Reply #152 on: January 11, 2022, 03:49:32 PM »
   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!
« Last Edit: January 11, 2022, 04:01:21 PM by rw6ark »

Runway 31

  • Moderator
  • Hero Member
  • *****
  • Posts: 33499
Re: MLAT
« Reply #153 on: February 16, 2022, 05:07:29 PM »
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

  • Hero Member
  • *****
  • Posts: 841
  • CYYZ - Toronto
Re: MLAT
« Reply #154 on: February 17, 2022, 03:41:11 AM »
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]
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]
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]
sudo systemctl restart rbfeeder 

 


Runway 31

  • Moderator
  • Hero Member
  • *****
  • Posts: 33499
Re: MLAT
« Reply #155 on: February 17, 2022, 08:53:14 AM »
Thanks abcd, only a reboot will get it working again

Alan

abcd567

  • Hero Member
  • *****
  • Posts: 841
  • CYYZ - Toronto
Re: MLAT
« Reply #156 on: February 17, 2022, 09:34:19 AM »
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]
     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>


.
« Last Edit: February 17, 2022, 09:39:58 AM by abcd567 »

Runway 31

  • Moderator
  • Hero Member
  • *****
  • Posts: 33499
Re: MLAT
« Reply #157 on: February 17, 2022, 09:45:54 AM »
Thanks abc it was the RB supplied feeder I was talking about.  You info will be very handy for users

Alan

Aerotower

  • Hero Member
  • *****
  • Posts: 525
Re: MLAT
« Reply #158 on: February 18, 2022, 06:46:42 PM »
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]
     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

  • Hero Member
  • *****
  • Posts: 841
  • CYYZ - Toronto
Re: MLAT
« Reply #159 on: February 18, 2022, 07:34:22 PM »

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

  • Hero Member
  • *****
  • Posts: 841
  • CYYZ - Toronto
Re: MLAT
« Reply #160 on: February 21, 2022, 06:34:05 PM »

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.

Quote
[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:

Quote
/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
Quote
#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:
Quote
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
Quote
#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:
Quote
mlat_cmd=/usr/bin/python3.9 /usr/bin/mlat-client  --results beast,connect,192.168.0.21:30007


« Last Edit: February 21, 2022, 07:01:23 PM by abcd567 »