So i know MLAT is not 100% but this seems strange:
Ground Track: 236° (SW)
Track Rate: -0.03
Magnetic Heading: 310° (NW)
Roll: -25.3
Then shortly later it’s correct again:
Ground Track: 314° (NW)
Track Rate: -0.03
Magnetic Heading: 309° (NW)
Roll: -0.5
This switches back and forth while the actual track is quite straight.
Can’t find it on the web page:
Maybe a problem with the magnetic heading? Why would a non-ADS-B plane transmit that?
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.
well track/heading not reported per se no need. after all the MSSR knows and calculates this accurately.
however newer ADS-B models appear to be able to transmit AFDS panel MCP settings
as per this paper here.
I think @obj is experimenting with these , said requires models ads-b2 or something…
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
I’d probably need to see the raw messages to explain what’s going on here.
One simple way to look at the original messages + how dump1090 has decoded them is
$ view1090-fa --show-only <ICAO of the aircraft here>
(this won’t show the synthetic mlat messages though)
Here you go:
*a0000a9cff9e592380048f8ab1cf;
CRC: 4ca934
RSSI: -21.3 dBFS
Time: 54690924840.17us
DF:20 addr:4CA934 FS:0 DR:0 UM:0 AC:2716 MB:FF9E592380048F
Comm-B, Altitude Reply
Comm-B format: BDS5,0 Track and turn report
ICAO Address: 4CA934 (Mode S / ADS-B)
Air/Ground: airborne?
Baro altitude: 16100 ft
Ground track 322.7
Roll: -0.7 degrees left
Groundspeed: 284.0 kt
TAS: 286 kt
*a0000a9cf019bf1c7f10002e14ae;
CRC: 4ca934
RSSI: -10.4 dBFS
Time: 54690933805.00us
DF:20 addr:4CA934 FS:0 DR:0 UM:0 AC:2716 MB:F019BF1C7F1000
Comm-B, Altitude Reply
Comm-B format: BDS5,0 Track and turn report
ICAO Address: 4CA934 (Mode S / ADS-B)
Air/Ground: airborne?
Baro altitude: 16100 ft
Ground track 219.2
Track rate: -0.94 deg/sec left
Roll: -22.5 degrees left
Groundspeed: 226.0 kt
Those were two consecutive messages.
For good measure another one with magentic heading readout:
*a0000a99f029bf1c7f20008379b5;
CRC: 4ca934
RSSI: -11.2 dBFS
Time: 54695695964.08us
DF:20 addr:4CA934 FS:0 DR:0 UM:0 AC:2713 MB:F029BF1C7F2000
Comm-B, Altitude Reply
Comm-B format: BDS6,0 Heading and speed report
ICAO Address: 4CA934 (Mode S / ADS-B)
Air/Ground: airborne?
Baro altitude: 16025 ft
Mag heading 315.4
IAS: 223 kt
Mach number: 0.452
Baro rate: -896 ft/min
whole log:
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