1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Out-of-order position reports

Discussion in 'Other technical not related to ADSBx Feeding' started by jdubner, Jan 1, 2019.

  1. jdubner

    jdubner New Member

    I use a Perl script to take a feed from adsbexchange.com, parse the received JSON data, and put the individual position reports into a MySQL database to display on a Google map in real-time or later. The data seems to be error-free except for the time (JSON 'PosTime' item).

    Some position reports are delayed by a few seconds and this causes them to be displayed later. It's particularly obvious when the points of the position reports are connected by a line that should represent the flight path. The plotted data is "zig-zagged" back and forth -- i.e. not a smooth progression.

    Here is an example of this phenomenon. Hover over an aircraft icon or green dot icon or scroll down to view the tabular data). Note that the fourth and fifth position reports' should be reversed in order.
    Code:
    2018-12-31   00:34:10    44.8654° N    123.1983° W    0°    43    194'
    2018-12-31   00:35:13    44.8623° N    123.1983° W    0°    67    219'
    The tip off here is the Speed (knots) parameter: the aircraft was on landing roll and the position of the 67-knot speed should precede the 43-knot one. (I should know: that's my airplane <g>.) Also, the 00:35:13 report time of the last position report was approximately 30 seconds after the aircraft cleared the runway (as verified by APRS position reports, a whole different topic BTW).

    This raises the question: what is the root cause and how can I fix it? Could this be due to different adsbexchange.com feeders having unsynced clocks? Or network or some other latency? Or is the JSON item 'PosTime' not rigorous enough for my purposes?

    My own feeder to adsbexchange.com is less than a mile away from the above example if that is any kind of a factor.

    Thanks for any insight anyone can shed on this.

    --
    Joe
     
    Last edited: Jan 11, 2019 at 2:31 AM
  2. MDA

    MDA Administrator Staff Member

    This traffic is low altitude/groun traffic. If ADSBx is only source of data then you have to accept such kind of inconvenience.
    Funny shape of track is caused by lack of receivers in your neighborhood, MLAT is only estimated position.
    Position calculation needs at least 4 receivers, if there is enough even one problem with Internet connection (data sent with delay from buffer) can cause such kind of problem.
    I've seen much worse tracks :).
    Can't post examples, I'm saving my SSD :D.
    Please accept this (try to apply filter removing out-of-area messages).

    Marcin
     
  3. jdubner

    jdubner New Member

    Thank you for your reply, Marcin. And thanks for helping me out earlier with posting my original message.
    True enough. But that should shield the aircraft's ADS-B transmissions from all except nearby receivers and preclude any MLAT.
    This cannot be so. My own feeder receiver is located on the airport, less than 1 NM away from the reports in the URLs I gave. That is the reason (or at least part of the reason) why ADS-B coverage was so good close to the ground in my posting.
    This I can easily believe. But what receiver(s) could be in play except for my own nearby one when the aircraft is virtually on the ground as in this case. (However, this same problem frequently occurs at higher altitudes too.)
    Certainly, I can accept this. I would gladly remove out-of-area messages if I could identify them. In this case, the message in question was simply timestamped a few seconds late.

    Some other information that may or may not be relevant:
    1. All of this activity was on 1090 MHz although 987 MHz ADS-B is also in use here in the USA. The aircraft in question does not use 978 MHz except for ADS-B IN (receive only).
    2. The aircraft was located about 5 NM from an FAA basestation which purportedly retransmits ADS-B on occasion. This aircraft is configured to require no retransmission; however, the basestation may have retransmitted a report for a different aircraft and it was picked up by a feeder receiver.
    For many, many years APRS has had a similar problem (delayed packets). However, I've generally been able to identify and remove them. If you or anyone can offer some advice on an algorithm to do this for ADS-B, I would appreciate it.
     
  4. jdubner

    jdubner New Member

    Following up to my own postings . . .

    I have changed my Perl script to discard position reports in which "Mlat" is true. Made no difference as far as I could see. Still seriously broken.

    Here's today's flight. Scroll down to the tabular data for 00:20:51 and 00:20:59. There's no way my little airplane could turn 120 degrees, pick up 25 knots, and gain almost 500 feet in only 8 seconds.

    Wish there was a field that would specify which feeder provided the report so I could get a clue where to look further for the timing issues. If it was mine I would fix it; if someone else's I would discard all from that particular feeder (that's what I do on APRS with a few "bad actors" polluting the data).

    Any good ideas, anyone?