search

rsadsb / adsb_deku

✈️ Rust ADS-B decoder + tui radar application
MIT License
605 stars 22 forks source link

Possible position mis-decode #21

Closed wiseman closed 2 years ago

wiseman commented 2 years ago 
8da353c65881360d90a7bc9b1858
 Extended Squitter Airborne position (barometric altitude)
  Address:       a353c6 (Mode S / ADS-B)
  Air/Ground:    airborne
  Altitude:      24675 ft barometric
  CPR type:      Airborne
  CPR odd flag:  odd
  CPR latitude:  (67272)
  CPR longitude: (42940)
a353c6: (Position { latitude: 33.64013671875, longitude: -125.04295349121094 }, 22625)

But that aircraft was closer to longitude -117 (screenshot may have been a few minutes after the decode above): Screen Shot 2021-10-28 at 7 41 38 PM

wiseman commented 2 years ago

I just noticed that 1090 can't take a receiver location; Maybe it made a wrong guess at resolving the resulting position ambiguity?

wcampbell0x2a commented 2 years ago

I bet it's just the time between messages. I use the "Globally unambiguous position decoding" decoding which if I remember correctly uses both an Odd and Even 'Frame` for calculating the new lat/long.

It could also be a problem with my buffer in/out system. I'd have to checkup on that logic.

wiseman commented 2 years ago

Oh yeah, time between messages has definitely caused this issue for me before, in other decoders.

wcampbell0x2a commented 2 years ago

Can confirm this issue when running Coverage for a night and zooming out:

2021-11-12-074112_1338x874_scrot

Jachdich commented 2 years ago

I have something similar to this, fairly often I decode a lat/long of -300 ish by -170 ish, with a receiver location of roughly 50, -5. There's a possibility this is down to interference but I find it odd that it would always be in the ballpark of -300 -170.

wcampbell0x2a commented 2 years ago

I have something similar to this, fairly often I decode a lat/long of -300 ish by -170 ish, with a receiver location of roughly 50, -5. There's a possibility this is down to interference but I find it odd that it would always be in the ballpark of -300 -170.

Interesting. I'd like to get rid of this issue. This would require having more lat/long cpr values for all the bad lat/long values after calling get_position.

I'd also like to see if this is a problem in the C libraries, or if they do more pre/post processing.

Which dump1090 did you use?

Jachdich commented 2 years ago

Which dump1090 did you use?

I used this version of dump1090_rs