MLAT broken today?

Hello forum.

Since ~8am CET / 7am UTC today I can't seem to get a proper connection via mlat-client and am therefore unable to participate in MLAT calculation.

<snip>
Connected to multilateration server at ..., handshaking
Lost connection to ...
Reconnecting in 30.0 seconds
</snip>

I tried connecting using telnet from other networks/ip addresses. Connection is usually established, but there's no response after submitting the initial JSON string.

Is there a known problem?

 

Sorry. The forum doesn't seem to allow adding the hostname of the adsbexchange mlat feed system

 

I'm located in Germany (classified as Eastern Europe ;-)).

I might add that general feeding continues to work fine, as did mlat for the last several weeks

 

Thanks Marcin. Greetings to Poland.

I see myself in the matrix but there's definitely no stable connection. I even snooped network traffic on port 31090 - there's nothing meaningful going on.
I'm also feeding to flghtaware - this still works without issues.

 

MLAT back up. I'll look into it - but just seems overloaded. Time to throw more money at it!

 

Thanks James!

 

Same Problem here - I am trying now and then since weeks to feed MLAT data - but only ressult i get i this:

Code:

mlat-client --input-type auto --input-connect 127.0.0.1:30005 --lat XX.XXXXX --lon YY.YYYYY --alt XXXm --user VictorRomeo --server ...:31090 --no-udp --privacy --results beast,connect,127.0.0.1:30104
Sat Dec 16 14:56:55 2017 mlat-client 0.2.6 starting up
Sat Dec 16 14:56:55 2017 Connected to multilateration server at ...:31090, handshaking
Sat Dec 16 14:56:56 2017 Beast-format results connection with 127.0.0.1:30104: connection established
Sat Dec 16 14:57:01 2017 Lost connection to ...:31090
Sat Dec 16 14:57:01 2017 Reconnecting in 30.0 seconds
Sat Dec 16 14:57:32 2017 Connected to multilateration server at ...:31090, handshaking
Sat Dec 16 14:57:38 2017 Lost connection to ...:31090
Sat Dec 16 14:57:38 2017 Reconnecting in 30.0 seconds
Sat Dec 16 14:58:08 2017 Connected to multilateration server at ...:31090, handshaking
Sat Dec 16 14:58:14 2017 Lost connection to ...:31090
Sat Dec 16 14:58:14 2017 Reconnecting in 30.0 seconds
.
.
.

removed position data from post - as well as url to avoid spam detection .... i am in the north of germany .... any ideas welcome.

EDIT: From time to time i get

Code:

Sat Dec 16 15:11:32 2017 Connected to multilateration server at ...:31090, handshaking
Sat Dec 16 15:11:38 2017 Lost connection to ...:31090
Sat Dec 16 15:11:38 2017 Reconnecting in 30.0 seconds
Sat Dec 16 15:11:55 2017 Receiver status: disconnected
Sat Dec 16 15:11:55 2017 Server status:   disconnected
Sat Dec 16 15:11:55 2017 Receiver:    0.0 msg/s received        0.0 msg/s processed (0%)
Sat Dec 16 15:11:55 2017 Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.0kB/s UDP to server
Sat Dec 16 15:11:55 2017 Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used

 

Looking into it. I wonder why the instability all of a sudden.

Getting MLAT here in the PHX slice.

What version of MLAT client are you running? I'm running 0.2.6. You should also be able to run 0.2.10 (most recent release). I believe one or more of the versions in between are broken.

 

Thank you for the replies. I took the arguments from the source code from github which states:

Code:

Altitude of the receiver (height above ellipsoid). Required. Defaults to metres, but units may
specified with a 'ft' or 'm' suffix. (Except if they're negative due to option
parser weirdness. Sorry!

and:

Code:

Sets the privacy flag for this receiver. Currently, this removes the receiver
location pin from the coverage maps

... how do you calculate your --alt parameter? Is it meters? feet? AGL? MSL?

 

I just tried running mine with
--input-type auto
and I get no MLAT
try --input-type dump1090

Don't believe everything you read in that documentation - it is notoriously bad

--privacy should work - I believe some feeders use it on some receivers in not so friendly areas.

From the new image coming out as soon as I write a bite more error logic ${VARIABLE] are pulled from a config file

Code:

/usr/bin/mlat-client --privacy --input-type dump1090 --input-connect localhost:30005 --lat ${LATITUDE} --lon ${LONGITUDE} --alt ${ALTITUDE} --user ${ADSBXNAME} --server ${MLATADSBXSERVER} --no-udp --results beast,connect,localhost:30104

Config

Code:

LATITUDE="33.3xxxxx
LONGITUDE="-111.xxxxx"
ALTITUDE="500"
MLATADSBXSERVER="feed.adsbexchange.com:31090"
ADSBXNAME="jfeederaz"

 

Ok - we are getting closer

Code:

Sat Dec 16 16:17:40 2017 mlat-client 0.2.6 starting up
Sat Dec 16 16:17:40 2017 Connected to multilateration server at ...:31090, handshaking
Sat Dec 16 16:17:41 2017 Beast-format results connection with 127.0.0.1:30104: connection established
Sat Dec 16 16:17:46 2017 Server says:

        In-development v2 server. Expect odd behaviour.

        The multilateration server source code is available under
        the terms of the Affero GPL (v3 or later). You may obtain
        a copy of this server's source code at the following
        location: ...

Sat Dec 16 16:17:46 2017 Handshake complete.
Sat Dec 16 16:17:46 2017   Compression:       zlib2
Sat Dec 16 16:17:46 2017   UDP transport:     disabled
Sat Dec 16 16:17:46 2017   Split sync:        disabled
Sat Dec 16 16:17:46 2017 Input connected to 127.0.0.1:30005
Sat Dec 16 16:17:46 2017 Input format changed to BEAST, 12MHz clock
Sat Dec 16 16:17:46 2017 Parsing receiver data failed: Lost sync with input stream: expected a 0x1A marker at offset 0 but found 0x2a instead
Sat Dec 16 16:17:46 2017 Lost connection to 127.0.0.1:30005
Sat Dec 16 16:17:46 2017 Reconnecting in 30.0 seconds

I am gettting the stream from a vrs ... I will adjust I/O and keep you updated - for now it looks like the "dump1090" is important.

 

VRS might also do some unfriendly stuff to the output from dump1090 with relation to this mlat-client understanding it. Trying pull directly from dump1090 instance?

 

Ahhh. Nice. I hope to get to point my GUI replaces the need to run VRS GUI