Possible position mis-decode about adsb_deku HOT 7 CLOSED

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

from adsb_deku.

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

from adsb_deku.

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.

from adsb_deku.

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

from adsb_deku.

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.

from adsb_deku.

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?

from adsb_deku.

Which dump1090 did you use?

I used this version of dump1090_rs

from adsb_deku.