FlightAware Discussions

Mlat-client not synchronizing with nearby stations

After about 18 hours, my mlat-client is not synchronizing.
I am pretty sure it is the way my setup is done.

I have a kinetic receiver plugged into USB driven by pfclient.

pfclient is listening on ports 30053 and 30054

I have modesmixer2 setup listening on ports 30005 and 30104 (and 8080 for webconsole)
modesmixer2 command line:

/usr/bin/modesmixer2 --google-key XXXXXXXXXXXXXXXXX --web 8080 --location 45.XXXXXX:-73.XXXXXX --inConnect 127.0.0.1:30054 --inServer 30104 --outServer beast:30005 --log-file /var/log/modesmixer2.log 

finally I have piaware setup like this:

piaware -p /run/piaware/piaware.pid -plainlog -statusfile /run/piaware/status.json
fa-mlat-client --input-connect localhost:30005 --input-type beast --results beast,connect,localhost:30104 --results beast,listen,30105 --results ext_basestation,listen,30106 --udp-transport 70.42.6.156:6890:991595952
faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat 45.480 --lon -73.497

with fa-mlat-clien listening on ports 30105 and 30106

May  7 11:17:35 planepi piaware[5214]: 2792 msgs recv'd from modesmixer2 (33 in last 5m); 2792 msgs sent to FlightAware
May  7 11:22:35 planepi piaware[5214]: 2828 msgs recv'd from modesmixer2 (36 in last 5m); 2828 msgs sent to FlightAware
May  7 11:27:35 planepi piaware[5214]: 2830 msgs recv'd from modesmixer2 (2 in last 5m); 2830 msgs sent to FlightAware
May  7 11:32:25 planepi piaware[5214]: mlat-client(5262): Receiver status: connected
May  7 11:32:25 planepi piaware[5214]: mlat-client(5262): Server status:   not synchronized with any nearby receivers
May  7 11:32:25 planepi piaware[5214]: mlat-client(5262): Receiver:    6.0 msg/s received        0.1 msg/s processed (2%)
May  7 11:32:25 planepi piaware[5214]: mlat-client(5262): Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.0kB/s UDP to server
May  7 11:32:25 planepi piaware[5214]: mlat-client(5262): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used

Synchronization requires nearby ADS-B aircraft, but there are no nearby ADS-B aircraft to use (actually, no aircraft at all apparently)

edit: oh, wait a minute:

If this is a basestation, they don’t provide timestamps that are useful for multilateration.
What’s the source protocol? If it’s the CSV-like Basestation format, that’s entirely useless for multilateration and in fact we’d rather not take data from there at all; piaware really wants the original raw messages. not messages synthesized by modesmixer from a Basestation feed.

As modesmixer doesn’t seem to want to make them ADS-R messages, maybe he could be convinced to use a magic timestamp when synthesizing raw messages?

EDIT: the zero timestamp might not be bad as a magic timestamp … so whatever
(hmmm which timestamp does uat2esnt use? that’s no timestamp so zero as well after conversion to beast by dump1090?)

I’m pretty sure he has an overflow because he doesn’t change the altitude Q bit properly when aircraft are above 50750 ft.
That leads to some bogus altitudes in some data from Google Balloons i’ve looked at. (not FA data)

@obj
Hmm i’m thinking discarding messages with timestamp zero wouldn’t be a bad idea. (for my usecase at least, not sure about piaware)

Bad message (probably synthetic):

*8da2237d5841c4ffb3b079fa4c42;
CRC: 000000
Time: 0.00us
DF:17 AA:A2237D CA:5 ME:5841C4FFB3B079
 Extended Squitter Airborne position (barometric altitude) (11)
  ICAO Address:  A2237D (Mode S / ADS-B)
  Air/Ground:    airborne
  Baro altitude: 12100 ft
  CPR type:      Airborne
  CPR odd flag:  odd
  CPR latitude:  -4.57809 (32729)
  CPR longitude: -75.44686 (110713)

Good message from same hex id:

*8ea2237d58807cffafb078895450;
CRC: 000000
RSSI: -16.1 dBFS
Time: 4416546187946.67us
DF:17 AA:A2237D CA:6 ME:58807CFFAFB078
 Extended Squitter Airborne position (barometric altitude) (11)
  ICAO Address:  A2237D (Mode S / ADS-B)
  Air/Ground:    airborne?
  Baro altitude: 63300 ft
  CPR type:      Airborne
  CPR odd flag:  odd
  CPR latitude:  -4.57818 (32727)
  CPR longitude: -75.44690 (110712)

If this is a basestation, they don’t provide timestamps that are useful for multilateration.
What’s the source protocol? If it’s the CSV-like Basestation format, that’s entirely useless for multilateration and in fact we’d rather not take data from there at all; piaware really wants the original raw messages. not messages synthesized by modesmixer from a Basestation feed.

It is not a basestation, it is called a 1090-puck. I have no idea what the difference is, and they were manufactured very briefly and I cannot find any information about the protocol. But they were intended to be used with the BaseStation software.

Yeah, I’ve thought about that - I really need to collect more data first though so I can see how many receivers it would affect.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.