Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible position mis-decode #21

Closed
wiseman opened this issue Oct 29, 2021 · 7 comments · Fixed by #101
Closed

Possible position mis-decode #21

wiseman opened this issue Oct 29, 2021 · 7 comments · Fixed by #101
Labels
apps-radar bug Something isn't working library

Comments

@wiseman
Copy link
Contributor

wiseman commented Oct 29, 2021

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
Copy link
Contributor Author

wiseman commented Oct 29, 2021

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

@wcampbell0x2a
Copy link
Member

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
Copy link
Contributor Author

wiseman commented Oct 29, 2021

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

@wcampbell0x2a wcampbell0x2a added the bug Something isn't working label Oct 31, 2021
@wcampbell0x2a
Copy link
Member

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

2021-11-12-074112_1338x874_scrot

wcampbell0x2a added a commit that referenced this issue Dec 2, 2021
Add --filter_time for removing airplanes after the the specified time.
This is down to 2 seconds in the ICAO document, but I see 10 seconds as
being pretty good for reducing the amount of mis-decodes greatly.

This was previosuly 60 seconds, which was giving very bad lat/long if a
long period of time was between both messages odd/even.

See #21
@Jachdich
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

Jachdich commented Dec 12, 2021

Which dump1090 did you use?

I used this version of dump1090_rs

@wcampbell0x2a wcampbell0x2a moved this to Todo in v0.6.0 Jan 1, 2022
Repository owner moved this from Todo to Done in v0.6.0 Jan 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apps-radar bug Something isn't working library
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants