MLAT data handling improvements

The "to-do" list for Virtual Radar Server is as long as my arm, but if you want to pile more work onto it then this is for you.
Post Reply
Skibox
Posts: 135
Joined: Mon Apr 07, 2014 7:06 pm
Location: ESGG

MLAT data handling improvements

Post by Skibox » Thu Sep 22, 2016 12:04 am

1. It would be more logical if the MLAT flag was set already in the receiver settings.
As now, If I view an input that has ONLY MLAT data, it says MLAT=NO. Only on a merged feed will MLAT=YES
Also, sometimes the MLAT flag alternates between yes and no for some reason.

2. Set a priority for merged feeds which MLAT source will be used. If 2 Mlat feeds has the same target, it will plot with a jagged track as the 2 solutions will not be identical. Would be nice to set them in a certain priority

3. The MLAT flag is undefined (blank) for some targets. ModeS without any positions should be MLAT=NO ?

4. It is not possible to sort the A/C list on MLAT flag, it changes the list but in seemingly random order

5. Suggestion: Use the already existing transponder type flag ( S/A/A1/A2) and add "M" for valid position from MLAT. Then we would only need this field in the list.

BR /Marcus

agw
Posts: 2058
Joined: Fri Feb 17, 2012 3:20 am

Re: MLAT data handling improvements

Post by agw » Thu Sep 22, 2016 12:39 am

The reason why your MLAT-only receiver is saying that none of the aircraft are MLAT is because you haven't configured it to mark MLAT messages as such (either that or there's a bug in VRS that's causing it to ignore the marker :)). If your MLAT receiver is based on mutability's MLAT server & client then you should have an option somewhere to add markers to the messages so that VRS knows that they're MLAT.

The reason why you get the flip-flopping between two MLAT receivers is because VRS has been configured with an merged feed timeout that is shorter than the interval between MLAT messages. If you boost the timeout a bit in the merged feed settings (by default it's 3 seconds) then you should be able to find a value that stops that effect. The downside is that when an aircraft finally goes out of range of a receiver VRS will wait that many seconds before it gives up waiting for messages from the receiver and lets another take over.

The problem with the sort is that when you sort by clicking column headers you're only specifying a single field to sort on. The sort order between two items that have an equal value is undefined. However, if you configure the sort in options then you can sort on multiple fields, you should be able to sort on (say) MLAT and then Registration, or MLAT and then ICAO etc. - i.e. you can tell VRS what to sort on when two aircraft have the same MLAT value.

Skibox
Posts: 135
Joined: Mon Apr 07, 2014 7:06 pm
Location: ESGG

Re: MLAT data handling improvements

Post by Skibox » Thu Sep 22, 2016 1:59 am

Thanks for the fast reply!
agw wrote:The reason why your MLAT-only receiver is saying that none of the aircraft are MLAT is because you haven't configured it to mark MLAT messages as such (either that or there's a bug in VRS that's causing it to ignore the marker :)). If your MLAT receiver is based on mutability's MLAT server & client then you should have an option somewhere to add markers to the messages so that VRS knows that they're MLAT.
Something is not working correctly then, because many of the feeds are from Piaware clients, and one is from mlat-server, all mutability software.

From the Piawares we use Basestation format, maybe that is why it's not marked correctly? But from the server we use beast format and should work OK ?

I still think the right place to manually set this is in the receiver config. If I can't control the senders data, that is where it should be set.

agw wrote:The reason why you get the flip-flopping between two MLAT receivers is because VRS has been configured with an merged feed timeout that is shorter than the interval between MLAT messages. If you boost the timeout a bit in the merged feed settings (by default it's 3 seconds) then you should be able to find a value that stops that effect. The downside is that when an aircraft finally goes out of range of a receiver VRS will wait that many seconds before it gives up waiting for messages from the receiver and lets another take over.
OK, it's at 2 or 3 seconds now for different feeds, I will try 5 seconds. But that means losing even more valid data when it changes between receivers.

IMO, It is not a very good way to merge feeds (it's more an auto-selection, rather than merging) , we continually lose a lot of data, and get timeouts without updates even when there is full coverage from other receivers. We have discussed this before and all the AIS software I work with do this differently.

Take for example an aircraft transiting between 2 receivers, Rx A and Rx B. The total received data will look something like this, (A is a packet from Rx A and B one from Rx B):
AAAAAAAAABAAABAAABAABAABABABABABBABBABBABBBABBBBABBBBBABBBBBABBBBBBBBBABBBBBBBBBBBBBBBBBB Here it has passed x seconds timeout and it starts using RxB's data. Until then, only Rx A has been used, providing an ever deteriorating quality and update rate. None of the B data has been used! Then it stops completely and we have a gap, until it times out and finally starts using the data from Rx B.

De-duplication of packets and a true merging of data would provide much more and better data quality.

agw wrote:The problem with the sort is that when you sort by clicking column headers you're only specifying a single field to sort on. The sort order between two items that have an equal value is undefined. However, if you configure the sort in options then you can sort on multiple fields, you should be able to sort on (say) MLAT and then Registration, or MLAT and then ICAO etc. - i.e. you can tell VRS what to sort on when two aircraft have the same MLAT value.
I understand that, but would still expect all YES to be grouped together, regardless of their respective order, but they are not! The list has Yes, No and blank all mixed together.

BTW, if I click a column header, how do I get back to the pre-defined sort order ?

Thanks,

/Marcus

agw
Posts: 2058
Joined: Fri Feb 17, 2012 3:20 am

Re: MLAT data handling improvements

Post by agw » Sun Oct 02, 2016 10:31 pm

Mutability can mark BaseStation format messages as being generated by MLAT but you need to set the option to use his extended BaseStation format rather than the generic flavour. I don't know how you would do that with the Piaware.

The Beast version should work without change, from what I remember he sets a magic number in the timestamp to indicate that it's MLAT. Unfortunately my MLAT test feed has been down for some time so I can't check that it's working, but the tests are still passing so if the magic number is what I'm expecting it to be then VRS will pick it up and use it.

I'll take a look at the MLAT column sorting and see what's going on there.

Skibox
Posts: 135
Joined: Mon Apr 07, 2014 7:06 pm
Location: ESGG

Re: MLAT data handling improvements

Post by Skibox » Tue Oct 11, 2016 2:38 pm

Hi,
agw wrote:Mutability can mark BaseStation format messages as being generated by MLAT but you need to set the option to use his extended BaseStation format rather than the generic flavour. I don't know how you would do that with the Piaware.
Yes, but only in the output from mlat-client and fa-mlat-client. I have changed them to beast format and it works well, mlat is identified.

BUT, the problem is in the main feed from mlat-server. There is no way to change to anything else than basestation format. So, the problem remain that these are identified as ADSB positions on that receiver, it sets the transponder flag to A and mlat=no ......

There could be other mlat feeds that can not be changed as well, sometimes you can not control the source, just happily accept the data....

Also, the mlat positions can be 10 seconds apart, and that is why it is jumping between the different feeds. I don't want to set the general time-out to more than 10 seconds as that woudl drop a LOT of useful data, as described above.

So, I still think that it would be a better solution to mark specific receivers as mlat already on the input, just like there is a "Is Satcom ACARS" selection. It would also be good with a separate timeout for mlat. (or change to true data merging for adsb data, and use the timeout only for mlat data)
agw wrote:The Beast version should work without change, from what I remember he sets a magic number in the timestamp to indicate that it's MLAT. Unfortunately my MLAT test feed has been down for some time so I can't check that it's working, but the tests are still passing so if the magic number is what I'm expecting it to be then VRS will pick it up and use it.
The beast "magic timestamp" for mlat is working fine!
agw wrote:I'll take a look at the MLAT column sorting and see what's going on there.
Thanks!

Skibox
Posts: 135
Joined: Mon Apr 07, 2014 7:06 pm
Location: ESGG

Re: MLAT data handling improvements

Post by Skibox » Mon Oct 24, 2016 12:54 am

Bump. Comment?
Skibox wrote:Yes, but only in the output from mlat-client and fa-mlat-client. I have changed them to beast format and it works well, mlat is identified.

BUT, the problem is in the main feed from mlat-server. There is no way to change to anything else than basestation format. So, the problem remain that these are identified as ADSB positions on that receiver, it sets the transponder flag to A and mlat=no ......

There could be other mlat feeds that can not be changed as well, sometimes you can not control the source, just happily accept the data....

Also, the mlat positions can be 10 seconds apart, and that is why it is jumping between the different feeds. I don't want to set the general time-out to more than 10 seconds as that woudl drop a LOT of useful data, as described above.

So, I still think that it would be a better solution to mark specific receivers as mlat already on the input, just like there is a "Is Satcom ACARS" selection. It would also be good with a separate timeout for mlat. (or change to true data merging for adsb data, and use the timeout only for mlat data)

agw
Posts: 2058
Joined: Fri Feb 17, 2012 3:20 am

Re: MLAT data handling improvements

Post by agw » Fri Oct 28, 2016 12:24 am

I'm not sure what you mean by "true data merge", but I can't see how changing the merge will help. If you're saying "just use whatever messages come in, when they come in" then that will produce your original jagged track from the two MLAT sources that are calculating different positions for the same aircraft. Likewise if you're saying "keep the last so-many messages on each feed that can see an aircraft and use those to discard duplicates, then keep what remains" (which is much harder to do reliably, especially when one receiver is seeing the aircraft at extreme range and has gaps in its stream of messages from the aircraft) then it'll still produce a jagged track because the two MLAT sources will be producing unique position messages on each feed.

Skibox
Posts: 135
Joined: Mon Apr 07, 2014 7:06 pm
Location: ESGG

Re: MLAT data handling improvements

Post by Skibox » Thu Jan 25, 2018 10:33 pm

Can we for the time leave the data merge problems aside and try to fix the mlat input handling?

1. Mlat-server does not tag the position feed with the magic timestamp (or any timestamp), so they are not automatically identified as MLAT in VRS.

2. When a merged feed has the mlat receiver feed marked as "mlat", it will actually ONLY set data from this feed to mlat, IF there is also data for the same hex code from at least one other receiver in the merged feed. If the mlat-feed is the only data source that provides a certain ICAO, this data is passed with mlat=no, regardless of the mlat flagged receiver.

3. Mlat feeds, just like Satcom, needs a different timeout. So, I still think that it would be a better solution to mark specific receivers as mlat already on the input, just like there is a "Is Satcom ACARS" selection.


I will be happy to provide a feed from mlat-server to help fix the problem.

/M

Skibox
Posts: 135
Joined: Mon Apr 07, 2014 7:06 pm
Location: ESGG

Re: MLAT data handling improvements

Post by Skibox » Sat Mar 03, 2018 1:55 pm

Bump

Post Reply