I have two sites and I’m having real trouble getting my London site to maintain MLAT synchronization. The other site I run on a Raspberry Pi 4 seems happy, it has synchronized and currently with 311 nearby receivers according to the stats page.
My London radar runs on an Ubuntu Proxmox instance (amd64), compiled using the provided script. I have, just like the Edinburgh site, surveyed the coordinates of the antenna precisely using Google Earth Pro, and measured how high it is (8m). Sometimes if I tweak the elevation slightly, the MLAT will go green for about 5 minutes and then drop sync again and fall back to red.
I’ve triple checked the coordinates and elevation, applied the same process to both sites but no matter what I do I just can’t get the London radar to maintain sync.
Any ideas would be greatly appreciated. Thanks very much
Have you tried going to your site configuration pop up that has a “edit location” selection? Inside the edit location you can choose to select your location from a map and when you bug your location it will insert a very detailed Lat and Long config. Works well for me.
Tell me about the hardware the London site runs on. I’ve found that hardware can cause a lot of MLAT problems. Sometimes when transferring large files it’ll destabilize mlat. In another case I had too many USB devices plugged in and adding a powered hub stopped the problem. So it could be a hardware issue.
I have indeed tried various methods, entering the coordinates manually and/or selecting a location on the map. Adjusting the elevation as well, neither method has resulted in success (other than as mentioned, sometimes the MLAT goes green for about 5 minutes and then drops off again).
Hardware wise - the instance currently has 2 cores from an AMD Ryzen 5700G allocated to it with 2GB memory and use of the main NVME SSD. The RTLSDR is connected directly to one of the motherboard USB 2.0 ports and granted to the instance through Proxmox configuration. Resource-wise it’s really unstressed, dump1090+piaware and a few other providers use no more than about 4% CPU. I was also wondering if the hardware was causing problems although I’m not sure how/why in this case.
I should also add to above that the solution is otherwise entirely stable, it has been running without a hiccup for roughly 6 months now. It’s only MLAT that I’ve encountered problems with so far.
VM USB passthrough can be patchy, and mlat relies on reliably getting USB data from the dongle. I don’t have direct experience with proxmox, but that’d be my first guess.
does rtl_test -s 2400000 on the proxmox instance work cleanly? (You may see a couple of initial drops, but not ongoing drops)
It is losing a little bit, ran it for a few minutes and there were a couple of losses reported after the initial 3 at the start:
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Detached kernel driver
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
[R82XX] PLL not locked!
Sampling at 2400000 S/s.
Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.
Reading samples in async mode...
Allocating 15 zero-copy buffers
lost at least 100 bytes
lost at least 68 bytes
lost at least 120 bytes
lost at least 68 bytes
lost at least 68 bytes
lost at least 16 bytes
lost at least 120 bytes
^CSignal caught, exiting!
User cancel, exiting...
Samples per million lost (minimum): 1
Reattached kernel driver
@obj certainly knows better than I do but I’m guessing there are too many drops for mlat to be reliable. I’m not sure how to fix that on your set up though.
mlat is fine with the data source being “remote” over IP (within reason - it won’t tolerate a lot of latency), so yeah, putting dump1090 closer to bare metal even if piaware etc runs elsewhere seems reasonable.
Sounds good, thanks. I’ll probably run dump1090-fa on the upper bare metal and see if that solves it. Saves having to use another RPi, I only have one spare at the moment
@obj would you be able to advise what settings I need to change with piaware and the SkyAware web interface to work with the bare metal (it’s on IP 10.0.100.30). So far I’ve overridden the default mlat-results-format config variable with this:
“beast,connect,10.0.100.30:30104 beast,listen,30105 ext_basestation,listen,30106”
(instead of localhost)
I probably need to do a few more things too. Thanks again
Edit - also set:
receiver-host 10.0.100.30
receiver-type other
Further edit:
Multilateration (MLAT): Supported / Enabled (synchronized with 558 nearby receivers)
This has a few moving parts. In a piaware sdcard image, you can use “receiver-type relay” but that’s not going to work out of the box for you (it needs to configure a few different services, and that’s only done on sdcard images)
but the short version is:
run a beast-splitter configured to pull data from the real receiver, provide data on port 30005, and connect/push data to 30104
run a dump1090-fa instance with no SDR device (net-only mode) that listens on 30104 and has no output ports. the sole reason for this instance is to generate json files for skyaware
configure piaware for receiver-type other, host localhost. (this will connect to beast-splitter for data)
Then beast-splitter will establish one connection to the real receiver and redistribute data to mlat-client / piaware / the skyaware dump1090-fa locally. mlat-client will send results to the skyaware dump1090-fa.
Thanks, the beast-splitter solution sounds good, I’ll look into implementing that. For the time being I’m running dump1090-fa and lighttpd on the bare metal and the instance has been reconfigured as “other” and talks directly over local IP.
Perhaps most importantly is MLAT now seems rock solid and all the other services that use dump1090 seem happy too.
