so what are we trying to say here? The signal was somehow able to reflect of a building onto my reciever from 278NM away due to the atmosphere or did the signal reflect through a foreign long range object? Maybe an adsb repeater?(hardly used in India)
2 Likes
Did you read the link on ducting?
You only need to look at the amateur band distance records to see what is possible.
Reflecting off a building seems highly unlikely, but reflecting of another aircraft is certainly possible.
Did you ever check to see where the plane (really) was?
Never heard of a āADS-B Repeaterā. Who would want one and what function would it serve? For most users, a plane out of range is of no interest.
2 Likes
mlat identifies the source of the transmitter so if there was something retransmitting Mode S (highly unlikely) that doesnāt change things - itād locate the retransmitter.
2 Likes
I agree with @geckoVN that ideally, if you still have it, you should go back an look at the data for the flight in question.
Ducting is quite common and I often get ranges beyond 280 NM when conditions are right.
However, I think what you saw was just a MLAT āglitchā - these are also relatively common. I managed to capture one just now. It is on a much smaller scale than your example, but the it clearly shows a wrongly calculated position.
The off-track position implies the helicopter travelled 9.5 NM in 76 seconds which equals a speed of 450 knots. Thatās nearly three times the max speed of an A139 helicopter. (Note this was an adsb exchange MLAT track - the FlightAware track is āde-identifiedā, as this is a Police helicopter, and there werenāt any positions on that track covering the time of the glitch.)
I donāt know enough to explain how these bad positions are calculated. Maybe someone more knowledgeable could comment?
2 Likes
There are parts of the solution space (depending mostly on the geometry of the receivers versus the aircraft) that are very sensitive to small errors & the initial position guess. Under some conditions this can sort of āflipā the possible solution far out from the correct position. Itās a bit like bending a springy sheet of metal by pushing the edges together - there are two possible shapes it can take. In the GPS world this is expressed as ādilution of precisionā - GDOP / TDOP / HDOP / VDOP etc.
The open-source mlat solver I released some time ago (which adsbx and other sites now use) tries to avoid that by feeding many measurements over time through a Kalman filter, which produces both a smoothed result and also an estimate of the error in the result. It only releases results when the estimated error is low enough. In parts of the solution space which are very sensitive to small errors, the natural noise in measurements makes the ābadā solution jump around a lot and so the estimated error stays high.
The FlightAware mlat system has diverged quite a bit since with a lot of internal tuning, so Iād hope it is somewhat more robust against this sort of error. Iāve generally gone down the path of preferring quality over quantity, sacrificing some coverage for the sake of better position tracks; other sites may have made different tradeoffs.
3 Likes
Thanks for the explanation.
This is the FlightAware MLAT track for the same flight/time (different scale, sorry) - I think it illustrates your point.
2 Likes
not really as i am using tar1090 on ?pTracks which means its past. checked something like flightradar24 and saw nothingā¦
1 Like
That is what i have thought of but there are 2 positions. also, my reciever would have reported something at a radius of 278NM to get this kind of result
1 Like
saw the email and read it. It was probably a glitch.
1 Like
One of the other sites who use mlat-client, is Radarbox24. They have built the mlat-client package from source-code at mutabilityās Github site. They were supplying mlat-client_0.2.11 package from their repository by command sudo apt install mlat-client.
This package was causing sudden failure of mlat (possibly because of some customization done in source code by them??). The mlat could be restored by rebooting Pi, but failure re-occured after few weeks or few months. This was happenning since Buster time, and in spite of complaints by users, nothing was done by RB24.
(1) I solved this problem by replacing the RB24 supplied mlat-client by mlat-client built using source-code at Github mutability, then protecting it from replacement during updates by RB24ās defective package by issueing command sudo apt-mark hold mlat-client
https://forum.radarbox24.com/index.php?topic=106441.msg532161#msg532161
(2) Few days ago RB24 woke up and replaced the defective mlat-client package in their repositories by new package (mlat-client version 0-2-13) and advised users to upgrade to new version.
https://forum.radarbox24.com/index.php?topic=106441.msg541381#msg541381)
1 Like
I couldnāt find your post about living on the ground floor. Honestly, if you use a cookie tin-antenna and are discrete with your feedline, you could put it on a table for a couple hours and let it just run. The sd card image that I run is pretty good about filtering out junk and is frighteningly stable, lol! Really, itās not a sophisticated set-up. You could be surpised.
2 Likes
I personally just use a 1090 antenna the ones you find on amazon
1 Like
Thatās not a bad rat-tail antenna. Put it on a cookie-tin lid outside. It shoud be fine.
Probably not an ADS-B repeater but reflection? Or, ducting?
Maybe both?
They are not waterproof.
itād work ok for a while, but performance would degrade as moisture penetrates and does its thing.
I thought about the marine environmnent, @geckoVN and no, itās not waterproof.
ā¦ āon a table outsideā
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.