0 kts in the Web UI

[Axtel4]

I don’t know it this is unique to me or not, but I have been testing my system since building and installing the Malcolm Robb dump1090 branch and I have been seeing aircraft reported in the Web UI with 0 kts groundspeed. It does not seem to impact the traffic seen on my App.

In the attached screenshot there are a number of aircraft with 0 kts. The one of interest is FDX3629 / N682FE / A90B27. It is unique because there is a Message 4 (DF17 Airborne Velocity) in the log that reports everything except the groundspeed. The other 0 kt aircraft are not reporting Message 4. I am not sure if Stratux isn’t receiving this message for those aircraft, or they are not transmitting Message 4.

Here are two examples from the dump1090.log. FDX3629 never shows Ground Speed and is marked as “Unavailable” whereas FDX3654 is marked “valid” and shows the Groundspeed.

FDX3629 from dump1090.log: *8da90b27990000001008002f8bb2; CRC: 000000 (ok) DF 17: ADS-B message. Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne)) ICAO Addres 40865262857726,s : a90b27 Extended Squitter Type: 19 Extended Squitter Sub : 1 Extended Squitter Name: Airborne Velocity EW status : Unavailable EW velocity : 515 NS status : Unavailable NS velocity : 79 Vertical status : Valid Vertical rate src : 1 Vertical rate : 64

FDX3654 from the dump1090.log: *8da8a73d9902250a680b0a2cf483; CRC: 000000 (ok) DF 17: ADS-B message. Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne)) ICAO Address : a8a73d Extended Squitter Type: 19 Extended Squitter Sub : 1 Extended Squitter Name: Airborne Velocity EW status : Valid EW velocity : 548 NS status : Valid NS velocity : 82 Vertical status : Va 41788836485997,lid Vertical rate src : 0 Vertical rate : -64

0069-es.zip 0069-dump1090.zip

[ghost]

This one looks like an aircraft problem. Mostly. :-)

Here's that ES message from FDX3629 with a little annotation.

     [8bit] [24 bits] [ES register - 56 bit]  [24 bits]
Desc: DF/CA  ICAO ID   TC   ----PAYLOAD-----   CHECKSUM
Byte:     0  1  2  3    4   5  6  7  8  9 10   11 12 13
Msg:     8d a9 0b 27   99  00 00 00 10 08 00   2f 8b b2

Byte 0 tells us that this is a Type 17 downlink (ADS-B), Capability 5. (0x8d = 10001101. Split after the first five bits, and we get 17 and 5)

Bytes 1-3 are the ICAO hex code, A90B27.

Byte 4 gets us into the ES message, and tells us what format type and subtype we're looking at. Like byte 0, this is a 5+3 message. 0x99 = 10011 001, or type = 19 and subtype = 1. Looking at the spec for this message, the next 3.5 bytes should contain velocity / integrity flags and the EW and NS components of ground speeds.

But they don't. These 3.5 bytes are empty (zero) -- in fact, all that's left in the rest of the ES message is baro vertical speed.

Nulls are passed to the dump1090 output. We're apparently interpreting those as zero in the web UI -- and that might be something that we could fix.

So, why is there an EW / NS velocity report in the verbose log? Because those are the values parsed from the last aircraft, and while dump1090 doesn't parse / update velocity if it sees an "invalid" flag, it uses the most recent values when it makes the log file. The 515 and 79 knot components actually belong to A46CE1.

*8da46ce19912040a00048f152229;
CRC: 000000 (ok)
DF 17: ADS-B message.
  Capability     : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
  ICAO Address   : a46ce1
  Extended Squitter  Type: 19
  Extended Squitter  Sub : 1
  Extended Squitter  Name: Airborne Velocity
    EW status         : Valid
    EW velocity       : 515
    NS status         : Valid
    NS velocity       : 79
    Vertical status   : Valid
    Vertical rate src : 0
    Vertical rate     : 0

*8da90b27990000001008002f8bb2;
CRC: 000000 (ok)
DF 17: ADS-B message.
  Capability     : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
  ICAO Address   : a90b27
  Extended Squitter  Type: 19
  Extended Squitter  Sub : 1
  Extended Squitter  Name: Airborne Velocity
    EW status         : Unavailable
    EW velocity       : 515
    NS status         : Unavailable
    NS velocity       : 79
    Vertical status   : Valid
    Vertical rate src : 1
    Vertical rate     : 64

[JohnOCFII]

This one looks like an aircraft problem. Mostly. :-)

Here's that ES message from FDX3629 with a little annotation.

Wow. Nice sleuthing there, Mr. @AvSquirrel

[Ergonomicmike]

I don't mean to clutter up the github with jokes, but @AvSquirrel, you CAN quit your day job. :-)

My airplane partner used to attend ARINC meetings when she was designing the FMC for the B-767. She even wrote some of the ARINC specs. (I used to help a bit.) Seeing the familiar ARINC documents in the post brings back good memories. (We got to fly around the country in the Glasiar attending meetings, with someone else paying for it.)

[Axtel4]

Thanks. It helps to have the right version of DO-260. :-)

[ghost]

@JohnOCFII , @Ergonomicmike -- thanks! :-D

Re: the "Mostly" comment... pull request #173 is submitted to fix traffic.js. This will parse the "Speed_valid" flag before blindly copying 0 into the web UI.

[Axtel4]

I updated with the fix to the 0 kts GS issue and observed an additional anomaly. While watching traffic on my app, I saw a traffic target with GS --- in the Web UI. I located that target on my app and observed the Heading arrow of the target did not correlate with the ground track of the target. Typically the Heading arrow is within a few degrees of the ground track (depending on cross wind correction). In this instance, the Heading arrow pointed to 0 degrees while the target tracked from NW to SE with a delta of approximately 150 degrees between the Heading arrow and the ground track. Switching back to the Web UI showed the traffic heading as 0 deg in addition to having the invalid GS. My next step is to capture more data and figure out how to use the replay logs to see if this is unique to a particulate app.

[cyoung]

Check out this transponder:

329265088747,MSG,3,,,A346D0,,,,,,,45000,,,42.45012,-84.54754,,,0,0,0,0
329657950001,MSG,3,,,A346D0,,,,,,,0,,,72.93750,42.35294,,,0,0,0,0
329784067551,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
330243978866,MSG,3,,,A346D0,,,,,,,45000,,,72.95913,42.78728,,,0,0,0,0
331623499784,MSG,3,,,A346D0,,,,,,,30225,,,72.93750,42.35294,,,0,0,0,0
333523429737,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
333524109349,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
333785523599,MSG,3,,,A346D0,,,,,,,30325,,,72.93750,42.35294,,,0,0,0,0
337322839815,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
337915310573,MSG,5,,,A346D0,,,,,,,45000,,,,,,,0,0,0,0
338564169912,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
339748053003,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
340334368834,MSG,3,,,A346D0,,,,,,,45000,,,72.96221,42.87775,,,0,0,0,0

Saw it flipping from FL300 to FL450.

http://flightaware.com/live/flight/WWI31/history/20160103/1645Z/KEGE/KHPN/tracklog

[cyoung]

Fixed via pull request #173.