mlat-server by mutability

Want to post something that doesn't quite fit into the other forums? This is the place for that.
GregoryGHarding
Posts: 94
Joined: Mon Jan 26, 2015 9:01 am
Location: CYYT

Re: mlat-server by mutability

Postby GregoryGHarding » Sat Dec 12, 2015 10:33 am

jonfear wrote:Greg

Check /var/log/ for the server messages. Something like "cat server-errors.log" If you are getting lots of errors then "tail -f /var/log/server-errors.log". This will show each new error message as it arrives.

Looking back through the post, it looks like your client are pointing to internal IP addresses. This seems wrong. Are you using a VPN or similar to move the data from the clients?

By default this system resides on the net. The clients point directly to the ip or domain name of the server. If you are going through a VPN, this "may" cause issues.

Fortunately this is a linux package and so is very powerful however it is not for the linux novice. There is a steep learning curve even for the likes of me who has used linux in various flavours for over 20 years!

We will try to help but need as much information a possible from you...

Jon


i have no logs for server-errors.log but i am using upstart, i have upstart logs for the server conf, reading that, it only shows successful handshakes to clients, and successful connection to basestation-output
same goes for client side, each of my clients have upstart logs, but those only show successful conx to mlatserver

jonfear
Posts: 365
Joined: Sat Feb 09, 2013 12:15 pm
Location: Wick St Lawrence
Contact:

Re: mlat-server by mutability

Postby jonfear » Sat Dec 12, 2015 4:59 pm

Greg

Check the var/www/html/sync and /var/www/html/coverage directories. There should be the required files there. You then need to check that httpd or apache is installed, configured and running. Once these deps are fulfilled then you should be able to see the web page outputs.

WRT the system, I assume you are running all these clients on a local network, locally. If this is the case then you are unlikely to see much output. You need to space the clients out about 20km apart (from memory). That then gives each client a slice of the sky.

There is no way of faking real clients, they need to be in place.

If this is not that case then why the private IP addresses?

HTH

Jon
http://www.360radar.co.uk, the new name for MLAT Radar in the UK and Western Europe.

Former PP feeder Bm. No longer feeding. I do not have time to sort out imaginary problems with NTP
when it has been working fine for 2+ Years.

jonfear
Posts: 365
Joined: Sat Feb 09, 2013 12:15 pm
Location: Wick St Lawrence
Contact:

Re: mlat-server by mutability

Postby jonfear » Sat Dec 12, 2015 5:03 pm

GregoryGHarding wrote:
jonfear wrote:Greg

Check /var/log/ for the server messages. Something like "cat server-errors.log" If you are getting lots of errors then "tail -f /var/log/server-errors.log". This will show each new error message as it arrives.

Looking back through the post, it looks like your client are pointing to internal IP addresses. This seems wrong. Are you using a VPN or similar to move the data from the clients?

By default this system resides on the net. The clients point directly to the ip or domain name of the server. If you are going through a VPN, this "may" cause issues.

Fortunately this is a linux package and so is very powerful however it is not for the linux novice. There is a steep learning curve even for the likes of me who has used linux in various flavours for over 20 years!

We will try to help but need as much information a possible from you...

Jon


i have no logs for server-errors.log but i am using upstart, i have upstart logs for the server conf, reading that, it only shows successful handshakes to clients, and successful connection to basestation-output
same goes for client side, each of my clients have upstart logs, but those only show successful conx to mlatserver


Try "ps fauxxx | grep python" you should see something like:

vrs 5318 52.2 60.6 2717752 1238804 pts/8 Sl Aug31 77635:42 python3.4 /home/vrs/mlat-server/mlat-server --client-listen 40147:40147 --check-leaks --work-dir /home/vrs/mlat-server/logs --write-csv /home/vrs/mlat-server/logs/csv.csv --basestation-connect xx.xx.xx.xx:38199 --filtered-basestation-connect xxxx.no-ip.org:32001 --basestation-connect xxxx.no-ip.org:32000 --basestation-connect www.mlat-radar.net:xxxxx --filtered-basestation-connect www.mlat-radar.net:xxxxx

If you do not see this then the server is not running...

J
http://www.360radar.co.uk, the new name for MLAT Radar in the UK and Western Europe.

Former PP feeder Bm. No longer feeding. I do not have time to sort out imaginary problems with NTP
when it has been working fine for 2+ Years.

GregoryGHarding
Posts: 94
Joined: Mon Jan 26, 2015 9:01 am
Location: CYYT

Re: mlat-server by mutability

Postby GregoryGHarding » Sat Dec 12, 2015 10:46 pm

jonfear wrote:
GregoryGHarding wrote:
jonfear wrote:Greg

Check /var/log/ for the server messages. Something like "cat server-errors.log" If you are getting lots of errors then "tail -f /var/log/server-errors.log". This will show each new error message as it arrives.

Looking back through the post, it looks like your client are pointing to internal IP addresses. This seems wrong. Are you using a VPN or similar to move the data from the clients?

By default this system resides on the net. The clients point directly to the ip or domain name of the server. If you are going through a VPN, this "may" cause issues.

Fortunately this is a linux package and so is very powerful however it is not for the linux novice. There is a steep learning curve even for the likes of me who has used linux in various flavours for over 20 years!

We will try to help but need as much information a possible from you...

Jon


i have no logs for server-errors.log but i am using upstart, i have upstart logs for the server conf, reading that, it only shows successful handshakes to clients, and successful connection to basestation-output
same goes for client side, each of my clients have upstart logs, but those only show successful conx to mlatserver


Try "ps fauxxx | grep python" you should see something like:

vrs 5318 52.2 60.6 2717752 1238804 pts/8 Sl Aug31 77635:42 python3.4 /home/vrs/mlat-server/mlat-server --client-listen 40147:40147 --check-leaks --work-dir /home/vrs/mlat-server/logs --write-csv /home/vrs/mlat-server/logs/csv.csv --basestation-connect xx.xx.xx.xx:38199 --filtered-basestation-connect xxxx.no-ip.org:32001 --basestation-connect xxxx.no-ip.org:32000 --basestation-connect http://www.mlat-radar.net:xxxxx --filtered-basestation-connect http://www.mlat-radar.net:xxxxx

If you do not see this then the server is not running...

J


checked both clients and server vm's, all clients and server are running, they show successful handshakes, and server basestation-output is connecting to VRS on seperate machine fine. with zero output

i do see some messages in my upstart logs for server when i tail -f like " A40D92 : receiver range check (even) failed"

but thats it no connection errors

GregoryGHarding
Posts: 94
Joined: Mon Jan 26, 2015 9:01 am
Location: CYYT

Re: mlat-server by mutability

Postby GregoryGHarding » Sat Dec 12, 2015 11:25 pm

jonfear wrote:Greg

Check the var/www/html/sync and /var/www/html/coverage directories. There should be the required files there. You then need to check that httpd or apache is installed, configured and running. Once these deps are fulfilled then you should be able to see the web page outputs.

WRT the system, I assume you are running all these clients on a local network, locally. If this is the case then you are unlikely to see much output. You need to space the clients out about 20km apart (from memory). That then gives each client a slice of the sky.

There is no way of faking real clients, they need to be in place.

If this is not that case then why the private IP addresses?

HTH

Jon


thers that problem, i do not have any httpd or apache installed. will start on that now, as for those dirs will i symlink them from the mlat-server folder to www?

these clients are indeed real physical receivers. i use a modesmixer for each receiver to output specific feeds to multiple places, and convert to beast.

Skibox
Posts: 113
Joined: Mon Apr 07, 2014 7:06 pm
Location: ESGG

Re: mlat-server by mutability

Postby Skibox » Sun Dec 13, 2015 12:16 am

GregoryGHarding wrote:
checked both clients and server vm's, all clients and server are running, they show successful handshakes, and server basestation-output is connecting to VRS on seperate machine fine. with zero output
i do see some messages in my upstart logs for server when i tail -f like " A40D92 : receiver range check (even) failed"



From your setup it looks like you have feeds coming into your VRS server, and then run centralized mlat clients that connect to rebroadcast feeds on the same machine. Nothing wrong with that I guess, as long as the data contains proper timestamps and the rebroadcasts are in pass-through mode. I have one box doing just that and I get timestamps passed through VRS. But check this carefully.

You still haven't given any information about what your clients actually are. Beasts? Piaware ? Some other Dump1090-based systems? Or GPS-synced Radarcapes ?

Your main problem seems to be that the clients never sync. Therefor my questions about your clients.

On each client console you should see something like this:

Fri Dec 11 12:03:39 2015 Server status: ready
Fri Dec 11 12:03:39 2015 Receiver: 106.0 msg/s received 2.0kB/s from receiver
Fri Dec 11 12:03:39 2015 Server: 0.0 kB/s from server 0.5kB/s TCP to server 0.0kB/s UDP to server
Fri Dec 11 12:03:39 2015 Aircraft: 5 of 5 Mode S, 9 of 15 ADS-B used
Fri Dec 11 12:18:39 2015 Receiver status: connected

If not, You are not getting data the client can work with!

This should also be obvious from the sync stats output, var/www/html/sync

When you get useable data in, you should see more that just connect messages in your server log:

20151126 20:56:15.209 INFO client [xxx] Handshake successful (RX1 v3 dump1090 0.2.4 tcp zlib2)'
20151126 20:56:16.113 INFO client [yyy] Accepted new client connection
20151126 20:56:16.115 INFO client [yyy] Handshake successful (RX2 v3 sbs 0.2.4 tcp zlib2)'
20151126 20:56:51.508 INFO client [zzz] Accepted new client connection
20151126 20:56:51.511 INFO client [zzz] Handshake successful (RX3 v3 dump1090 0.2.4 tcp zlib2)'
20151126 20:57:02.758 INFO kalman 4CA7DE acquiring.
20151126 20:57:03.392 INFO kalman 502C7D acquiring.
20151126 20:57:03.474 INFO kalman 489788 acquiring.
20151126 20:57:03.660 INFO kalman 502C7C acquiring.
20151126 20:57:06.351 INFO kalman 502C50 acquiring.
20151126 20:57:11.872 INFO kalman 43EA6E acquiring.
20151126 20:57:29.842 INFO kalman 502C7D acquired. <------ Here a position is found
20151126 20:57:40.115 INFO kalman 502C7E acquiring.
20151126 20:57:45.027 INFO kalman 3C4DD8 acquiring.
20151126 20:57:57.683 INFO root Halting on SIGTERM
20151126 20:57:57.683 INFO root Server shutting down.
20151126 20:57:57.683 INFO client [RX1] Disconnected
20151126 20:57:57.683 INFO client [RX2] Disconnected

Other examples:
20151126 20:59:18.959 INFO kalman 489788 outlier: md=17.7
20151126 20:59:18.959 INFO kalman 489788 reset due to outliers.
20151126 20:59:20.035 INFO kalman 489788 acquiring.

20151126 21:16:54.596 INFO root 86CEF4: receiver range check (even) failed
20151126 21:16:55.086 INFO root 86CEF4: receiver range check (even) failed

20151126 22:50:40.613 INFO clocksync RX1:RX2: 06A066: step by 3.9us

20151127 14:51:50.078 INFO kalman 4AB30B tracking lost

20151211 19:55:43.788 INFO mlattrack 47809c solved altitude=19368ft with dof=0


/M

Skibox
Posts: 113
Joined: Mon Apr 07, 2014 7:06 pm
Location: ESGG

Re: mlat-server by mutability

Postby Skibox » Sun Dec 13, 2015 12:19 am

GregoryGHarding wrote: i use a modesmixer for each receiver to output specific feeds to multiple places, and convert to beast.


Aha! What is the input data to the modeSmixer? Why do you "convert to beast"? What are the actual receivers ?

/M

GregoryGHarding
Posts: 94
Joined: Mon Jan 26, 2015 9:01 am
Location: CYYT

Re: mlat-server by mutability

Postby GregoryGHarding » Sun Dec 13, 2015 12:29 am

Skibox wrote:
GregoryGHarding wrote: i use a modesmixer for each receiver to output specific feeds to multiple places, and convert to beast.


Aha! What is the input data to the modeSmixer? Why do you "convert to beast"? What are the actual receivers ?

/M


i have a few planefinder.net boxes that output basestation
and i have a few fr24 receivers that output raw

i convert to beast just to keep the type regular, its a OCD thing

GregoryGHarding
Posts: 94
Joined: Mon Jan 26, 2015 9:01 am
Location: CYYT

Re: mlat-server by mutability

Postby GregoryGHarding » Sun Dec 13, 2015 12:33 am

Skibox wrote:
GregoryGHarding wrote:
checked both clients and server vm's, all clients and server are running, they show successful handshakes, and server basestation-output is connecting to VRS on seperate machine fine. with zero output
i do see some messages in my upstart logs for server when i tail -f like " A40D92 : receiver range check (even) failed"



From your setup it looks like you have feeds coming into your VRS server, and then run centralized mlat clients that connect to rebroadcast feeds on the same machine. Nothing wrong with that I guess, as long as the data contains proper timestamps and the rebroadcasts are in pass-through mode. I have one box doing just that and I get timestamps passed through VRS. But check this carefully.

You still haven't given any information about what your clients actually are. Beasts? Piaware ? Some other Dump1090-based systems? Or GPS-synced Radarcapes ?

Your main problem seems to be that the clients never sync. Therefor my questions about your clients.

On each client console you should see something like this:

Fri Dec 11 12:03:39 2015 Server status: ready
Fri Dec 11 12:03:39 2015 Receiver: 106.0 msg/s received 2.0kB/s from receiver
Fri Dec 11 12:03:39 2015 Server: 0.0 kB/s from server 0.5kB/s TCP to server 0.0kB/s UDP to server
Fri Dec 11 12:03:39 2015 Aircraft: 5 of 5 Mode S, 9 of 15 ADS-B used
Fri Dec 11 12:18:39 2015 Receiver status: connected

If not, You are not getting data the client can work with!

This should also be obvious from the sync stats output, var/www/html/sync

When you get useable data in, you should see more that just connect messages in your server log:

20151126 20:56:15.209 INFO client [xxx] Handshake successful (RX1 v3 dump1090 0.2.4 tcp zlib2)'
20151126 20:56:16.113 INFO client [yyy] Accepted new client connection
20151126 20:56:16.115 INFO client [yyy] Handshake successful (RX2 v3 sbs 0.2.4 tcp zlib2)'
20151126 20:56:51.508 INFO client [zzz] Accepted new client connection
20151126 20:56:51.511 INFO client [zzz] Handshake successful (RX3 v3 dump1090 0.2.4 tcp zlib2)'
20151126 20:57:02.758 INFO kalman 4CA7DE acquiring.
20151126 20:57:03.392 INFO kalman 502C7D acquiring.
20151126 20:57:03.474 INFO kalman 489788 acquiring.
20151126 20:57:03.660 INFO kalman 502C7C acquiring.
20151126 20:57:06.351 INFO kalman 502C50 acquiring.
20151126 20:57:11.872 INFO kalman 43EA6E acquiring.
20151126 20:57:29.842 INFO kalman 502C7D acquired. <------ Here a position is found
20151126 20:57:40.115 INFO kalman 502C7E acquiring.
20151126 20:57:45.027 INFO kalman 3C4DD8 acquiring.
20151126 20:57:57.683 INFO root Halting on SIGTERM
20151126 20:57:57.683 INFO root Server shutting down.
20151126 20:57:57.683 INFO client [RX1] Disconnected
20151126 20:57:57.683 INFO client [RX2] Disconnected

Other examples:
20151126 20:59:18.959 INFO kalman 489788 outlier: md=17.7
20151126 20:59:18.959 INFO kalman 489788 reset due to outliers.
20151126 20:59:20.035 INFO kalman 489788 acquiring.

20151126 21:16:54.596 INFO root 86CEF4: receiver range check (even) failed
20151126 21:16:55.086 INFO root 86CEF4: receiver range check (even) failed

20151126 22:50:40.613 INFO clocksync RX1:RX2: 06A066: step by 3.9us

20151127 14:51:50.078 INFO kalman 4AB30B tracking lost

20151211 19:55:43.788 INFO mlattrack 47809c solved altitude=19368ft with dof=0


/M


Fri Dec 11 12:03:39 2015 Server status: ready
Fri Dec 11 12:03:39 2015 Receiver: 106.0 msg/s received 2.0kB/s from receiver
Fri Dec 11 12:03:39 2015 Server: 0.0 kB/s from server 0.5kB/s TCP to server 0.0kB/s UDP to server
Fri Dec 11 12:03:39 2015 Aircraft: 5 of 5 Mode S, 9 of 15 ADS-B used
Fri Dec 11 12:18:39 2015 Receiver status: connected


i do have this for the cleints, however its always using 0 of x mode-s and usually 50% of ads-b

and this is what i see in server log right now via tail -f

Code: Select all

20151212 11:31:21.874  INFO     root                 A40D92: receiver range check (even) failed
20151212 20:58:31.700  INFO     root                 392F2A: receiver range check (even) failed

GregoryGHarding
Posts: 94
Joined: Mon Jan 26, 2015 9:01 am
Location: CYYT

Re: mlat-server by mutability

Postby GregoryGHarding » Sun Dec 13, 2015 1:00 am

this is what my www looks like after installed and symlinked folder. sync isnt flashing to the table. and coverage.. well it doesn't load anything

Image
Image


Return to “General Discussion”

Who is online

Users browsing this forum: Bing [Bot], JOECALW and 2 guests