Given the number of stations (more than 40 within 60 miles) in my vicinity I was under the assumption that MLAT should be technically possible. But there are no MLAT flights on the web map. How can we know if MLAT is activtated in a certain area or not?
Bert
Look at the “MLAT” column under “Nearby ADS-B sites” on your stats page: flightaware.com/adsb/stats/user/esurk2001
Multilateration is not supported directly from the Radarcape feeder software at the moment, which is probably why you don’t see any.
If you run a separate PiAware you can configure it to pull data from your Radarcape; that setup does support multilateration.
Ok, I understand. I see other people feeding for MLAT in my vicinity.
When I do the separate Piaware setup and pull the data for upload, can I get MLAT traffic in return?
Is MLAT traffic ever shown on the flightaware.com/live/ web page?
Thanks
Yes
Is MLAT traffic ever shown on the Live Flight Tracker - FlightAware web page?
This is one of those “it’s complicated…” questions. It doesn’t show up on that specific map, but it is integrated into FA’s flight data elsewhere.
Thanks, got it!
ok, I installed a piaware now and intend to split the antenna line. This seemed easier than connecting the pi to the radarcape.
I want to keep both receivers online in future.
Now, the pi was automatically assigned to my account by means of the IP address, which is of course the same to the outside world.
Piaware status shows the mlat client is not running. I suspect that the presence of the radarcape as a non mlat device is the reason?
Where to go from here?
How can I run 2 devices from the same IP?
How can MLAT be enabled on the pi?
Create a new user account?
For mlat to work when using a rtlsdr dongle, you need to set the receiver location here: flightaware.com/adsb/stats/user … tats-31284 then restart piaware.
There’s nothing else you need to do to get two devices associated with your account.
However you may be better off with just the Radarcape receiver and a single antenna feed. The radarcape is inherently a better receiver and the GPS timestamps help with mlat. PiAware can be configured to pull data from the radarcape. With a PiAware sdcard image, configure “receiver-type radarcape” and “radarcape-host ” (using piaware-config on the command line, or by editing /boot/piaware-config.txt on the sdcard), reboot, and it should do the rest itself. piaware will produce a combined map and output on the usual ports for mlat results etc; it shouldn’t affect anything else you want to do with the radarcape.
If you do go with splitting the antenna line be aware that you’re taking at least a 3dB loss, and you need a splitter with good isolation (not just a simple tee) as the USB dongles feed a lot of noise back towards the antenna that will negatively affect the radarcape.
Thanks for your super quick response, got it going now.
Crossfeeding is simpler than I thought. sudo nano/boot/piaware-config.txt does it
Is Radarcape + piaware mlat enabled starting from version 3 ?
I’m interested to try this, but I have been holding off upgrading to ver 3 because I don’t want any mlat returns that have spoofed icao (as discussed in the thread about mlat data censoring). Is there a way to turn these off completely ?
/M
Yes.
I’m interested to try this, but I have been holding off upgrading to ver 3 because I don’t want any mlat returns that have spoofed icao (as discussed in the thread about mlat data censoring). Is there a way to turn these off completely ?
Currently it is all or nothing (either you get both normal + anonymized results, or none), but it’s a reasonable feature request to be able to control it more carefully, I’ll put it on the todo.
Note that the anonymized results are sent in the same format as TIS-B results which use anonymized addresses, so downstream software should already be capable of distinguishing them from real aircraft addresses.
OK, thanks. I’m staying with 2.1.5 for the time as that provides just that, a filtering against spoofed ICAOs. I don’t want to get 2 different targets for the same aircraft, one via our true mlat feed, the other spoofed through fa-mlat, in that case I prefer to be without FA’s targets altogether.
I have no idea about how VRS handles TIS-B, is there even TIS-B in Europe ?
BR
/M
There is no TIS-B in Europe.
I added an option to piaware 3.2.0 (not released yet) that allows you to disable the anonymized results.
Excellent, thanks!
/M
What is needed to get this to work with 3.3.0 ? I can’t get fa-mlat to sync with any receivers using radarcape data, (but mlat-client on the same pi works fine)
Feeder Type: PiAware (Debian Package Add-on) 3.3.0
Multilateration (MLAT): Supported / Enabled
02/14/2017 00:15:45 mlat(19779): Receiver status: connected
02/14/2017 00:15:45 mlat(19779): Server status: not synchronized with any nearby receivers
02/14/2017 00:15:45 mlat(19779): Receiver: 77.0 msg/s received 1.4kB/s from receiver
02/14/2017 00:15:45 mlat(19779): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.5kB/s UDP to server
02/14/2017 00:15:45 mlat(19779): Aircraft: 5 of 6 Mode S, 4 of 7 ADS-B used
/M
You shouldn’t need anything special. What is your piaware configuration?
(nb: next Radarcape software version - due Real Soon Now - includes piaware directly)
Does it need to see the RC GPS status messages? I have ModeSmixer running inbetween but can try beast-splitter instead.
~# piaware-config
allow-manual-updates yes # value set at /etc/piaware.conf:7
flightaware-password # value set at /etc/piaware.conf:10
flightaware-user # value set at /etc/piaware.conf:8
mlat-results-format “beast,connect,some.server.net:33117 beast,listen,33005” # value set at /etc/piaware.conf:9
receiver-type radarcape # value set at /etc/piaware.conf:11
/M
Yes, it does. It reads the 12MHz/GPS timestamp bit in the status message to decide how to interpret the timestamps. If the status message is missing then it’s probably getting that wrong. Assuming your radarcape is configured for GPS mode, you should see messages about “input format changed to RADARCAPE, 1000MHz clock” from mlat-client in the piaware logs.
OK.
I get that message from mlat-client, but not from fa-mlat-client, So I guess fa-mlat is just pickier and requires the status, while mlat-client works anyway ?
ModeSmixer seems to discard the status messages, will change to beast-splitter and try.
/M
It’s fundamentally the same code, probably they’re getting started with different arguments (you can force GPS or 12MHz on the command line via a legacy clock type, I guess you are doing that when starting mlat-client manually; piaware starts fa-mlat-client in autodetect mode)
ModeSmixer seems to discard the status messages, will change to beast-splitter and try.
You really do want the status messages to make it to (fa-)mlat-client, even apart from the 12MHz/GPS thing, it will switch between GPS-epoch-synchronized and freerunning timestamps based on the GPS health info that newer radarcape software provides.