I noticed that before at initial pick from decoder(s) specially distant aircraft
I think the problem lies with the decoder - never the aircraft (which anyway do not transmit heading info). as soon as reliable position is established, the correct display appears.
No that’s not it. It’s more than one aircraft and it’s all along the way through my coverage.
obj introduced some fancy advanced heading readouts including the magnetic heading being displayed. Maybe the original packets from the plane contain some bit which mean a new heading is decoded. The MLAT messages probably contain the correct heading.
I don’t quite follow the code with regard to how the MLAT/non-MLAT packets are combined.
Didn’t say those MLAT aircraft transmit a heading, just saying some part of the message if wrongly decoded
I should probably record the packets coming in on the MLAT port and then record the beast packets coming out of dump1090 excluding the mlat ones and afterwards feed the packets to another dump1090 to see which of the packets the heading comes from.
Not quite sure how to do it yet.
Or i could split up the MLAT data plane from the no position plane in dump1090 to display them separately. That actually sounds like a plan time to dive into the code, tomorrow maybe
Oh i’ll also install the official package and check if the problem is the same.
Running version is self compiled from dev branch plus some changes. Most changes are html only though and the one change to dump1090 itself really should not affect decoding. I’ll still try to get the same trace with the official package just to make sure.
Ok, so that one is probably a mis-decode. I’ll have a poke at it tomorrow to see if there’s another more plausible decode.
The problem with Comm-B is that there’s no way to know which message format is being used (the register number is only in the interrogation which we don’t see, not the reply). dump1090 tries to guess at the format based on which way decodes plausibly, but I guess it’s getting it wrong in this case.
edit: looks like this message is actually a BDS6,0 report but dump1090 decodes it as a BDS5,0 report