UAT rebroadcast traffic speed incorrect

[peepsnet]

Ver 0.7b3
Dual sdr
Anker 20600
Edimax

Although the gps position does update and move the aircraft on the screen the relayed speed seems to be incorrect

[ghost]

ES or UAT replay?

[ghost]

And can you attach copies of the replay files you're using to this issue?

[Axtel4]

What is incorrect? The 0 kts?

[peepsnet]

This is not a replay file this is live traffic at Fort Lauderdale International Airport and yes the knots 0 of airborne aircraft being rebroadcast

[Axtel4]

The 0 kts not be incorrect for the speed. It can be that the aircraft is equipped with a Version 0 Mode S transponder. This will be common until Jan 1, 2020 mandate. After that date all ADS-B aircraft will need to be Version 2 and broadcast the correct information. Version 0 aircraft may also show 0 heading, --- airspeed, and/or ---- heading.

On February 21, 2016 7:15:17 PM CST, peepsnet notifications@github.com wrote:

This is not a replay file this is live traffic at Fort Lauderdale
International Airport and yes the knots 0 of airborne aircraft being
rebroadcast

---

Reply to this email directly or view it on GitHub:
#277 (comment)

[Ergonomicmike]

I didn't know why until Axtel4 explained it, but I've been seeing 0 kt (and 0 degree) AC ever since I got an SDR for 1090. (Whic was some time around v0.5.)

[peepsnet]

Ok. So it's a feature... is the a/c really reporting 0 or nothing?

If the a/c's are reporting nothing then we should display it that way with something like an italicized null or something.

[skypuppy]

Sometimes the other planes do not conform to the "official" ADS-B
standard and therefore don't play nicely with others. May not be
stratux's fault.

On 02/21/2016 07:15 PM, peepsnet wrote:

This is not a replay file this is live traffic at Fort Lauderdale
International Airport and yes the knots 0 of airborne aircraft being
rebroadcast

—
Reply to this email directly or view it on GitHub
#277 (comment).

[Axtel4]

It depends on how the aircraft is configured and the manufacturer of the transponder. When ES was released at DO-181 Version 0 the cert requirement was that it operate correctly with TCAS. Since ADS-B was not being used in the US there was not a requirement to include all the ADS-B data at that time. The minimum data set for DF-17 was the Lat/Lon, 4096 Squawk Code, Mode C altitude, Mode S address, TCAS equipage level, and the TCAS avoidance solution if an RA was initiated. This data was used outside the US as a quality control measure for ATC. There are a number of countries that are ahead of the US with the ADS-B mandate.

The other items you are accustomed to seeing did not exist until DO-181 Version 1 and 2 with them being fully mandated at Version 2 after 01-Jan-2020.

[Ergonomicmike]

@peepsnet Yeah, I agree. Somewhere, either here or in the reddit, I suggested that dashes would be better. But as others are telling us here, the Stratux is faithfully reporting what is being sent. Unless there's a way to know if someone's xpndr is a Ver 0 Mode S, I think we just have to live with it. (I've been invited to ride shotgun Thursday with a guy who has a Stratus V2. I'll put it on my Test Card to see how the Stratus reports these aircraft.)

[Axtel4]

The other thing you will see with Version 0 transponders if your EFB App has a heading vector ( or arrow) is the heading vector will point to 0 degrees but the target will move across the display in the direction of flight. So for a target moving from East to West the heading vector will point North instead of in the direction of flight.

[Ergonomicmike]

That makes sense. But I would have (wrongly) reported that as a bug to iFly if I had seen that. Perhaps iFly is doing some post processing? I'll watch my buddy's FF for this Thursday.

[Axtel4]

That makes sense. But I would have (wrongly) reported that as a bug to iFly if I had seen that.

In flight I am too busy doing other tasks to monitor the app that closely and I didn't pick up on it at first until I was siting stationary at home watching the EFB app. At that point I saw what the symbol was doing and compared it to the post processed 1090ES data. If the App sees 0 degrees the vector line points North. I am not sure how the app processes the ---'s for the heading. Maybe with the ---'s the app just paints the symbol without the vector line.

[ghost]

JBU672 is indicating as 978 FIS-B / ADS-R target. It's maybe a little unusual that you're not seeing a 1090 position, but within the realm of reason. However, there are two things that don't make a lick of sense to me:

• You're in Lauderdale, but JBU672 is 5 degrees -- that's 300 nautical miles -- north of you. Those corrdinates are 120 miles east of Savannah, GA.
• JBU672 is at FL350, well above the FL240 service ceiling of the ADS-R / TIS-B rebroadcasts.

I'm trying to wrap my head around this -- I wouldn't rule out anything at this point, including bad data translation from the ground stations. Did you have logging turned on? A parse through the uat.log could be telling.

[peepsnet]

Yea it was on! tell me what you want me to try

[Ergonomicmike]

@Axtel4 iFly will sometimes show a diamond symbol (indicating nonjmoving traffic), say at 8000'. I'll watch it, because I know that the target can't be stationary at 8000'. The diamond moves and eventually changes to a triangle w/ a vector. I don't think that iFly is calculating the motion, because when I go back to the status page, the airspeed is usually filled in by then. But I'll check for it next flight. (BTW, I only do this head down stuff in flight when I'm the non-flying pilot.).

[Ergonomicmike]

@AvSquirrel This isn't the same thing that you're taking about with 978 rebroadcast. But when I get targets w/ 0 airspeed, they're usually at the limit of my SDR's range. I don't know why their GPS position comes thru loud & clear but their airspeed/heading does not. But that's what I've observed.

[cyoung]

@peepsnet - get the tail number, http://www.flightradar24.com/flight/b6672.

Say it was N643JB, then http://registry.faa.gov/aircraftinquiry/NNum_Results.aspx?NNumbertxt=N643JB
N643JB -> A8712A

zgrep a8712a /var/log/stratux/*uat.log.gz

Then paste the output from that.

[peepsnet]

0094-uat.log.gz

Log above and last 20 or so lines below

/var/log/stratux/0094-uat.log.gz:11916521471740,-0aa8712a36bb7b93a6005eb7064886e13f15c3bc7712440b6a936280005ed0000000;rs=0;ss=249;
/var/log/stratux/0094-uat.log.gz:11917529705177,-0aa8712a36bc2393a6905ea7064886e12f15c3bc7712440b3a936280005ee0000000;rs=0;ss=234;
/var/log/stratux/0094-uat.log.gz:11918418903667,-0aa8712a36bcc993a71c5e97064886e12f15c3bc7712440b52936280005ee0000000;rs=0;ss=245;
/var/log/stratux/0094-uat.log.gz:11919536308718,-0aa8712a36bd8193a7b85e87064886e14f15c3bc7712440b9a936280005ea0000000;rs=0;ss=234;
/var/log/stratux/0094-uat.log.gz:11920626884916,-0aa8712a36be4193a85a5e77064886e13f15c3bc7712440b22936280005e90000000;rs=0;ss=234;
/var/log/stratux/0094-uat.log.gz:11922262599603,-0aa8712a36bf6193a9505e67064886e19f15c3bc7712440bc2936280005e80000000;rs=0;ss=224;
/var/log/stratux/0094-uat.log.gz:11923271479550,-0aa8712a36c00f93a9e05e47064886e1bf15c3bc7712440bca936280005e80000000;rs=0;ss=216;
/var/log/stratux/0094-uat.log.gz:11924647581320,-0aa8712a36c0f993aaaa5e37064886e1df15c3bc7712440bea936280005e60000000;rs=0;ss=221;
/var/log/stratux/0094-uat.log.gz:11925582111112,-0aa8712a36c19d93ab345e17064886e1df15c3bc7712440ba2936280005e60000000;rs=0;ss=229;
/var/log/stratux/0094-uat.log.gz:11926417955538,-0aa8712a36c23593abb65e0706488761cf15c3bc7712440be2936280005e20000000;rs=0;ss=225;
/var/log/stratux/0094-uat.log.gz:11927407515694,-0aa8712a36c2d593ac445df706488761cf15c3bc7712440bda936280005e20000000;rs=0;ss=224;
/var/log/stratux/0094-uat.log.gz:11928428986788,-0aa8712a36c38793acd85de7064487620f15c3bc7712440b22936280005e00000000;rs=0;ss=209;
/var/log/stratux/0094-uat.log.gz:11929379260433,-0aa8712a36c43193ad6c5dc7064487620f15c3bc7712440baa936280005df0000000;rs=0;ss=229;
/var/log/stratux/0094-uat.log.gz:11930388398297,-0aa8712a36c4d593adf45db7064487622f15c3bc7712440b92936280005de0000000;rs=0;ss=221;
/var/log/stratux/0094-uat.log.gz:11931526637203,-0aa8712a36c59993aea05da706448761ef15c3bc7712440bd2936280005dd0000000;rs=0;ss=209;
/var/log/stratux/0094-uat.log.gz:11932586023609,-0aa8712a36c64f93af385d8706448761bf15c3bc7712440b5a936280005dc0000000;rs=0;ss=215;
/var/log/stratux/0094-uat.log.gz:11934282174858,-0aa8712a36c77993b03c5d7706408761ef15c3bc7712440bd2936280005da0000000;rs=0;ss=216;
/var/log/stratux/0094-uat.log.gz:11935553911577,-0aa8712a36c84f93b0ee5d5706408761ff15c3bc7712440b12936280005d80000000;rs=0;ss=212;
/var/log/stratux/0094-uat.log.gz:11939395884544,-0aa8712a36cae393b3285d07063c86e1df15c3bc7712440b9a936280005d70000000;rs=0;ss=226;
/var/log/stratux/0094-uat.log.gz:11940458918919,-0aa8712a36cb9793b3be5cf7063c86e1ff15c3bc7712440b72936280005d20000000;rs=0;ss=231;
/var/log/stratux/0094-uat.log.gz:11941416260949,-0aa8712a36cc4393b4565ce7063c86e1df15c3bc7712440bc2936280005d70000000;rs=0;ss=223;
/var/log/stratux/0094-uat.log.gz:11942479649334,-0aa8712a36ccf993b4ea5cd7063c86e1df15c3bc7712440bd2936280005d70000000;rs=0;ss=230;
/var/log/stratux/0094-uat.log.gz:11945688904281,-0aa8712a36cf1b93b6be5c97063c8661ef15c3bc7712440bba936280005d00000000;rs=0;ss=233;
/var/log/stratux/0094-uat.log.gz:11957660964693,-0aa8712a36d71f93bd865b9700000061ef15c3bc7712440b52936280000000000000;rs=0;ss=240;
/var/log/stratux/0094-uat.log.gz:11958917796672,-0aa8712a36d7bf93be0c5b8700000061df15c3bc7712440b32936280000000000000;rs=0;ss=232;
/var/log/stratux/0094-uat.log.gz:11959858859692,-0aa8712a36d86193be945b7700000061df15c3bc7712440b0a936280000000000000;rs=0;ss=220;
/var/log/stratux/0094-uat.log.gz:11960801201359,-0aa8712a36d90193bf1c5b6700000061df15c3bc7712440b52936280000000000000;rs=0;ss=237;
/var/log/stratux/0094-uat.log.gz:11961882026150,-0aa8712a36d9bb93bfb65b47063483e1ef15c3bc7712440b50932200005b80000000;rs=0;ss=225;
/var/log/stratux/0094-uat.log.gz:11962588258598,-0aa8712a36da6993c04a5b37063483e1bf15c3bc7712440b32936280005b60000000;rs=0;ss=237;
/var/log/stratux/0094-uat.log.gz:11963905603649,-0aa8712a36db1793c0de5b17063083e1ef15c3bc7712440b52936280005b50000000;rs=0;ss=243;
/var/log/stratux/0094-uat.log.gz:11964868515888,-0aa8712a36dbbb93c16c5b07063083e1ef15c3bc7712440b32936280005b50000000;rs=0;ss=235;
/var/log/stratux/0094-uat.log.gz:11966726349534,-0aa8712a36dd2393c2965ad7063083e1ef15c3bc7712440b82936280005b40000000;rs=0;ss=253;
/var/log/stratux/0094-uat.log.gz:11967681005783,-0aa8712a36ddc593c3225ac7063083e1ef15c3bc7712440b42936280005b40000000;rs=0;ss=235;
/var/log/stratux/0094-uat.log.gz:11968746002710,-0aa8712a36de7b93c3bc5ab7063083e1ef15c3bc7712440be2936280005b40000000;rs=0;ss=249;
/var/log/stratux/0094-uat.log.gz:11969811132345,-0aa8712a36df2d93c4565aa7063083e1ef15c3bc7712440b3a936280005b40000000;rs=0;ss=244;
/var/log/stratux/0094-uat.log.gz:11970703985574,-0aa8712a36dfc593c4d45a87063083e1ef15c3bc7712440b9a936280005b40000000;rs=0;ss=237;
/var/log/stratux/0094-uat.log.gz:11972402076250,-0aa8712a36e0e793c5ce5a67063083e1ef15c3bc7712440b92936280005b40000000;rs=0;ss=228;

[peepsnet]

FYI LAN592 is also not close to the correct speed. it should be around 350 to 250knots. That is LAn Chille a heavy cargo jet i believe...

[Axtel4]

Since you have a 1090 dongle installed and JBU672 is an Air Transport catagory aircraft we can cross reference the Jet Blue aircraft data in the 0094-es.log to the UAT log.

[peepsnet]

Here is is!

0094-es.log.gz

[Axtel4]

Interesting, JBL672 (A8712A) doesn't show up in your 1090ES log, but there is a track record for it in FlightAware. It should since it is an A320.

[peepsnet]

yea. I didnt see it in the ES log.

[Ergonomicmike]

Didn't AvSquirrel say it was a 300 miles away? Not gonna get that on 1090.

[cyoung]

According to flightaware, it started in FLL which is where @peepsnet is based. So perhaps it is in an earlier file?

[peepsnet]

zgrep a8712a /var/log/stratux/*.log.gz
Nope. not in any other files. but I was having the 1090 SDR issue

[ghost]

@peepsnet -- this is great data!

TL;DR:
There's an int16 overflow in the UAT speed decoding that causes any ground speed greater than 181 knots to decode as zero. 1090ES is not affected. I'm working on an overhaul of the 1090 traffic code, and will include fixes to the UAT code in the same commit sometime this week.

Technical stuff
First, these appear to be valid UAT position messages. The "address qualifier" of 2 indicates that these are probably ADS-R messages, rather than TIS-B. The giveaways are the presence of an emitter category (3 = large aircraft), and a high NIC (7 = position containment within 0.2 NM) -- you're not going to get that with radar alone.

As strange as it sounds, those messages correctly encode a position over Chesapeake Bay. Take a look at the snapshot below from 0044Z, as well as the decoding of the first UAT message. Both show positions at about 38.5°N / 76.2°W, descending out of FL370 on a 34° track.

UAT Position Decoder
====================
Parsing UAT message: -0aa8712a36bb7b93a6005eb7064886e13f15c3bc7712440b6a936280005e
Airground state: 0
Speed = 0, NS vel = 401, EW vel = 268
ICAO=A8712A, Tail=JBU672, Address qualifier=2, Emitter=3
Airground state: 0 (OnGround=false)
NIC: 7, Position valid: true, Lat: 38.483669, Lng: -76.184692, Alt_geo: false, alt: 36850
Raw velocity parameters: NS valid=true, NS vel=401, EW valid=true, EW vel=268
Processed velocity (current method): Speed valid=true, Speed = 0, Track = 34, Vvel=-1152
Raw velocity parameters( floating point): NS valid=true, NS vel=401.0, EW valid=true, EW vel=268.0
Processed velocity (floating point method): Speed valid=true, Speed = 482.3, Track = 33.8, Vvel=-1152
Ground station details: UTC Coupled=false, Site ID=15

So... why is speed funky? Instead of reporting speed and track, ADS-B encode the north-south and east-west speeds, and it's up to the receiver to do the math to calculate speed and track.

As it happens, there's a bug in the root sum of squares routine during decode. Velocity components are stored as int16, and aren't being recast before they're squared in line 329. If the either component is greater than 181, or the sum of squares is greater than 2^15 -1, the sum of squares is set to zero. Since the components were (correctly) flagged as valid, this gets passed to the GDL90 and UI outputs.

Recasting to a more compatible data type (float64 in this example) correctly calculates a ground speed of 482 knots.

Interestingly enough, you got a few messages that didn't have valid velocity components, and these would have been detected as such (i.e. speed and track would have been blanked out on the UI) :

UAT Position Decoder
====================
Parsing UAT message: -0aa8712a36d86193be945b7700000061df15c3bc7712440b0a936280000000000000
Airground state: 0
ICAO=A8712A, Tail=JBU672, Address qualifier=2, Emitter=3
Airground state: 0 (OnGround=false)
NIC: 7, Position valid: true, Lat: 38.563042, Lng: -76.117188, Alt_geo: false, alt: 35550
Raw velocity parameters: NS valid=false, NS vel=0, EW valid=false, EW vel=0
Processed velocity (current method): Speed valid=false, Speed = 0, Track = 0, Vvel=-1792
Raw velocity parameters( floating point): NS valid=false, NS vel=0.0, EW valid=false, EW vel=0.0
Processed velocity (floating point method): Speed valid=false, Speed = 0.0, Track = 0.0, Vvel=-1792
Ground station details: UTC Coupled=false, Site ID=15

Attached below is a modified, standalone version of the UAT traffic decode routine that does both the current method and my prototype. It's a bit rough (it reads the UAT message as a hard-coded string) but can be run from the command line as go run decode_UAT_traffic.go.

decode_UAT_traffic.go.zip

[Ergonomicmike]

It always makes me grin when I see the synergy in this Project.

[peepsnet]

Is this the same for the LAN592 he was going slower(below 10000) so the int16 could hold the value? although not calculated correctly because of the n/s & e/w component?

We were probable only getting one of the 2 components n/s or e/w??
https://www.youtube.com/watch?v=p2_lJ2bGltE

[peepsnet]

Attached below is a modified, standalone version of the UAT traffic decode routine that does both the current method and my prototype. It's a bit rough (it reads the UAT message as a hard-coded string) but can be run from the command line as go run decode_UAT_traffic.go.

what are the arguements for this?

I got this from the UAT log
==> /var/log/stratux/0118-uat.log <==
START,Mon Feb 22 19:28:06 +0000 UTC 2016,Mon Feb 22 19:28:06 +0000 UTC 2016
UNPAUSE,97296250
3470945103,-00aa3cc12556e18de9a6056911323020bf00;rs=3;ss=53;
5535592133,-00aa3cc12556938de948055911662aa08e00;rs=1;ss=80;
6421252602,-00aa3cc12556738de92a0559117628207800;rs=0;ss=137;
13665343120,-00aa3cc125551f8de8a2053911d400a05f00;rs=3;ss=46;
14544255828,-00aa3cc12554ed8de8a4053911d002a05f00;rs=6;ss=52;
16881507962,-00aa3cc125547f8de8ac053911d006205800;rs=4;ss=49;
17753844837,-10aa3cc125544f8de8b2053911cc06a0590000000000000000000000000510000000;rs=0;ss=75;
19694426399,-00aa3cc12553f58de8be053911cc07206e00;rs=1;ss=61;
26683288271,-08aa3cc12552a98de90e054911ac1280a909df20c157040beea4c2a0000530000000;rs=1;ss=68;
27259174000,-00aa3cc125528d8de918054911a813008800;rs=0;ss=53;
29724782124,-00aa3cc12552198de94c0559119c16804800;rs=3;ss=66;
31610377852,-08aa3cc12551c98de9740549119819204f066a0025ed2d0baea4c0a0000530000000;rs=5;ss=56;
32731757956,-00aa3cc12551958de992054911941a801800;rs=0;ss=65;
33297341758,-10aa3cc12551838de99c054911941b00480000000000000000000000000530000000;rs=1;ss=56;

Got an example?

[peepsnet]

Oh I see... nano the file and change the hard coded variable...

[peepsnet]

FWIW.
import (
"os"
"fmt"
"encoding/hex"
"math"
"strings"
)

func main() {
//s := "-0aa8712a36d7bf93be0c5b8700000061df15c3bc7712440b32936280000000000000"
s := os.Args[1]

Added "os" in import
Added s:= os.Args[1]

go run decode_UAT_traffic.go -08a7bf2425571b8ddd7404f810d022e070066a0025ed2d0b0695c0a00004d0000000;

[cyoung]

Fixed in #285.