MLAT - Out-of-order timestamps

did not look into piaware-logs since very long time - because my feeder-stats-site says ‘mlat green - connected to xxx receivers’ - now by accident looked into and saw these kind of errors:

mlat-client(678): Out-of-order timestamps: 1532
mlat-client(678): Warning: the timestamps provided by your receiver do not seem to be self-consistent. This can happen if you feed data from multiple receivers to a single mlat-client, which is not supported; use a separate mlat-client for each receiver.

wondering what is the reason for this behavior?

hmmm - found the problem: switch --forward-mlat was set in dump1090-mutability what is not default when i look at github. no idea why/when - but obviously i set this myself???

Yes, that must have been manually set.

There’s actually a cosmetic bug floating around in the currently released fa-mlat-client that causes the out-of-order report in this case (the mlat client should just ignore the mlat messages entirely rather than complaining) but the fix is not yet in a released version.

yes - was my definitely my fault! and now i know how this happened. to use as little wifi-bandwith as possible my feeder connected to antenna sends results directly to flightaware and a second pi in my office connects via socat to port 30004/30104. all my playing around with the received data i then do from the pi in my office that is connected via ethernet. this ‘aggregator-pi’ i did setup dump1090 in net-only mode and --forward-mlat because then i get ads-b and mlat in one stream out of 30005. and at this stage there is no risk because i do not feed any other sites. when i replaced the ready to go fa sd-card-image in the ‘real’ feeder in my loft i was lazy and just copied the aggregator image but then forgot to eliminate the --forward-mlat switch.

so - in this case the behavior of mlat-client told me that i did something wrong - don’t know whether bandwith was wasted this way too - but maybe mlat-client drops these messages anyway.

thanx!

@obj

maybe this ‘cosmetic bug’ could be meaningful to stay in mlat-client. i was thinking that if the feeder in my loft connected to antenna would feed fr24, planefinder or others (like many here in forum do) in parallel i’d have sent them the flightaware mlat-results by accident.

so why not leave this behavior of mlat-client but just altering the error-message to e.g. ‘Warning: you maybe feed mlat-results to other networks - mlat-results loop back to port 30005’

just an idea …