Folks I debated whether to revive "MLAT Enabled No MLAT "but the thread was 3 years old
and I guess it would have spammed all the contributors - possibly to their annoyance!
I have a couple of RPi4: one with FA blue Pro Stick Plus dongle and the other an Airspy Mini dongle.
Same amplified signal is fed to both systems via a cavity splitter.
The Airspy is my experimentation system and has only recently been installed.
Location is precisely set on both systems and I don’t notice errors or bad performance on either.
For reasons I do not understand, the Airspy system is not launching /usr/lib/piaware/helpers/fa-mlat-client (as if mlat has been disabled). Consequently I see a more “OTHER” for Airspy (RHS picture above)
Strangely I see a green MLAT synchronised:
But dipping into the various files I notice…
pi@piaware:~ $ cat /run/piaware/status.json
{
“uat_enabled” : false,
“piaware” : {
“status” : “green”,
“message” : “PiAware 3.8.1 is running”
},
“expiry” : 1586355510171,
“interval” : 5000,
“mlat” : {
“status” : “red”,
“message” : “Multilateration is not enabled”
},
“modes_enabled” : true,
“adept” : {
“status” : “green”,
“message” : “Connected to FlightAware and logged in”
},
“radio” : {
“status” : “green”,
“message” : “Received Mode S data recently”
},
“site_url” : “https://flightaware.com/adsb/stats/user/hphillip#stats-123922”,
“time” : 1586355499171
}
…confirming status red for MLAT
As an experiment, I tried manually launching fa-mlat-client (but I’m certainly not clear if the parameters are correct or even appropriate) and I see…
pi@piaware:~ $ /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type dump1090 --results beast,connect,localhost:30104 --results beast,listen,30105 --results ext_basestation,listen,30106 --udp-transport 70.42.6.156:13235:3797719881
fa-mlat-client 0.2.11 starting up
Using UDP transport to 70.42.6.156 port 13235
Listening for Beast-format results connection on port 30105
Listening for Extended Basestation-format results connection on port 30106
Route MTU changed to 1500
type mlat_event event ready mlat_client_version 0.2.11 capabilities anon modeac
Input connected to localhost:30005
Input format changed to BEAST, 12MHz clock
type mlat_event event connected
type mlat_event event clock_reset reason Decoder mode changed to BEAST frequency 12000000 epoch none mode BEAST
Beast-format results connection with ::1:30104: connection established
type mlat_seen hexids AE6043 491D85 34324F 407698 43C09A 43C55F AA01A2 06A1A5 7608EA 01012A 06A12A 4076EB 43C171 3C5432 407277 A1B4B9 4CA27C A6E03F
type mlat_rates rates 491D85 1.72 407277 1.90 43C171 1.87 43C09A 1.40 AA01A2 1.75 407698 1.81 7608EA 1.87 A6E03F 1.62 A1B4B9 1.82 01012A 1.69 4CA27C 1.75 06A1A5 1.88 34324F 1.47 06A12A 1.60 4076EB 0.85 3C5432 1.14
type mlat_udp_report messages_sent 0
type mlat_seen hexids 4BB150
type mlat_rates rates 491D85 1.94 407277 1.94 43C171 1.88 43C09A 1.88 AA01A2 1.94 407698 1.91 7608EA 2.07 A6E03F 1.66 A1B4B9 1.85 01012A 0.73 4CA27C 1.88 06A1A5 1.85 34324F 1.88 06A12A 1.59 4076EB 1.47 3C5432 1.43
type mlat_seen hexids 43C7CF
type mlat_rates rates 491D85 1.94 407277 1.97 43C171 2.00 43C09A 1.88 AA01A2 1.94 407698 1.97 7608EA 1.91 A6E03F 1.78 A1B4B9 1.53 01012A 1.27 4CA27C 1.72 06A1A5 1.94 34324F 1.62 06A12A 0.64 4076EB 1.40 3C5432 1.59 4BB150 1.00
…which suggests potentially I should be able to enable the MLAT and get it working.
I just don’t know how to enable the mlat on this Airspy installation!
If I set the MLAT enabled radio button on the Site Configuration it appears to do nothing.
Next time the dialog loads it has been reset to MLAT disabled.
Beginning to clutch at straws.
Does anyone have any suggestions for a fix without having to do a complete re-install?
Any advice much appreciated.
