Faux tail numbers of "N" and "00000000" with new dump1090

[Ergonomicmike]

1. Stratux version: 0.7b3 + 855b "alpha"
2. Stratux config: dual SDR, GPS yes (BU-353), AHRS no; battery, battery cable: Anker E5, Anker cable.
3. EFB app and version (iFly v9.4 RC2). EFB platform (Android KK). EFB hardware (Azus Zenad S 8).
4. Description of your issue.

I noticed two goofy tail numbers today. "N" and "00000000." (Eight zeros.) Here's the screen shot: http://postimg.org/image/yx922cu5j/

And here's a clip from es.log

{"Icao_addr":11097569,"DF":20,"CA":0,"TypeCode":19,"SubtypeCode":1,"SBS_MsgType":5,"SignalLevel":0.001005,"Tail":"00000000","Squawk":null,"Emitter_category":null,"OnGround":false,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":41000,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-02-29T17:54:05.797Z"}
49016938747301,

[skypuppy]

Thank you, Chris!

On 03/01/2016 06:34 PM, cyoung wrote:

The same problem exists in many different forms - you can call a controller with the call sign of someone else, use the squawk code of someone else, etc. We can only save the world one issue at a time and this issue is outside the scope of #298 https://github.com/cyoung/stratux/issues/298.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/298#issuecomment-190989423.

[ScraboTower]

@Ergonomicmike - sorry been away for a few days. I still have the loan of the SkyRadar , Stratux is at 7b1 ... What you want me to check ?

[cyoung]

There have been some significant changes relevant to 1090 traffic since v0.7b1, @ScraboTower. If you could download http://updates.stratux.me/builds/update-stratux-v0.7b3-d714a5139e.sh and use the "update" feature in the interface it will bring you up to the latest.

[ScraboTower]

Sorry brain failure. I am already at 7b3, did it and flew with it on Saturday

[cyoung]

The release versions will lag behind the "commit" version, like they always did - but now upgrading to the latest commit is easier to do for anyone without recompiling from source. There are 93 "v0.7b3" versions you could have now - check the status page, if it doesn't say "d714a5139e" then it's not the latest.

[Ergonomicmike]

@ScraboTower Once you have the Stratux updated, we're interested in whether the SkyRadar displays the same goofy call signs we started noticing in the Stratux lately.(See above for examples.) Kind of a sanity check.

[ScraboTower]

Ran for 5 hours just sitting on office desk but only once noticed any diff - SkyRadar showed the callsign DPJ987 but Stratux("d714a5139e") didnt - all other data elements matched.

FDX3154 reported 0 altitude on both devices.

[Ergonomicmike]

Thx. What did Stratux show for the call sign of DPJ987 then? Blanks? Question marks? Dashes? Chris will probably ask for your logs.

[ScraboTower]

WingX displayed blanks

Both devices were hooked up to two iPads running WingX

[Axtel4]

I captures these 00000000 Flight IDs this evening: From Statux:

From RTL1090:

[jthawkes]

Since the Flight ID can be entered manually why worry about it.

The FAA (and other locations that use the ICAO planning system) use the ICAO hex address to identify aircraft.
You can also simply decode U.S. ICAO addresses to get the A/C callsign anyway. They use a STD formula to get them. I believe that changing the ICAO address is harder to do.

http://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/air_traffic_services/flight_plan_filing/media/filing_adsb_capability_faa_icao_flight_plan.pdf

[ghost]

@Nokomis449 , @bkwny --

A syntactically valid squit is just that. It doesn't matter who sent it or whether the data in it is true.

Agreed 100%. Like I said a couple days ago, any valid, checksummed callsign message should be passed. I'm still on the fence on two corner cases.

• Stratux receives a DF=17, TC = 1-4 extended squitter ADS-B identification message that is decoded and passes checksum verification, but contains a callsign with invalid characters. In other words, the emitting transponder intentionally sent characters that it shouldn't have. My inclination is to let it ride, since other receivers should also be seeing the same thing.
• Stratux receives a DF=21 (Comm-B, non-ES / non-ADS-B) that decodes with invalid characters. This format doesn't allow checksum verification by outside observers (the checksum encodes the ICAO ID of the aircraft; radar stations and other Comm-B ground emitters can verify the checksum because they know who they are talking to, but we don't) so dump1090 has to "guess" if the message decoded properly. My inclination is to drop DF21 callsign decoding since an ADS-B target will also send DF17 callsign messages.

Thoughts?

[Ergonomicmike]

Don't know if this code was manually entered or is the ICAO coming thru? (In caps instead of lower case?)

[Axtel4]

Do you have the dump1090 and ES log for that?

[ghost]

IIRC, we've always shown the ICAO code (in caps, grayed out) if the callsign isn't available.

Check out @axtel4's screenshot in the first post of #172.

[Ergonomicmike]

@Axtel4 Unfortunately, not for that one. (Did a reminage before installing the jessie kernel, and default is Logs off.)

But I caught another one. A54D73.

https://www.sendspace.com/file/xnk0pa

[Ergonomicmike]

@AvSquirrel You're correct. Mine is consistent with Axtel4's screenshot from #172. (I searched this issue for similar and didn't see any and so thought it was a new anomaly.) So, NM.

[Ergonomicmike]

@AvSquirrel Not to over complicate this - I like your idea above for displaying DF 17 & 21 call signs. As a final and/or additional fall back position, if a call sign is questionable (spaces? all 0's? Just an "N"? Can't really test for BWIFATTY) then treat it like it isn't available and display ICAO as you're doing now when a call sign isn't available?

[Ergonomicmike]

I sound double minded because previously I've suggested that Stratux just display what's sent. I'm still okay w/ that. The potential advantage of displaying ICAO when in doubt is that, unlike 00000000, ICAO call signs should be unique. (In theory.)

[bkwny]

Can the Web UI display both the ICAO code and the aircraft-operator-provided identifier? Why is the Web UI built in such a way that it displays the ICAO code inside the colored icon and then switches to the aircraft-operator-provided identifier once Stratux knows same?

And for the record I would disagree with ever masking off, editing, blanking out, or otherwise corrupting the aircraft-operator-provided identifier. Display whatever the aircraft is transmitting, to the best of our ability.

[Ergonomicmike]

I wonder if all EFB's simply repeat what they're sent w.r.t. Call Signs? (But that's out of our control.)

[Ergonomicmike]

Just caught an ICAO Stratux call sign. iFly reports "Unknown." (And then it changed to a UAL flight when Stratux caught up.)

[Axtel4]

DroidEFB and Avare don't repeat any call signs.

[Ergonomicmike]

IFly will repeat the small "e" when the message type option is enabled in the Stratux Settings page. So I thought it repeated everything sent to it. Does Stratux send ICAO only call signs to the EFB?

[Ergonomicmike]

Off topic, but I thought it was a silly gimmick when iFly started showing Call Signs. But it's kinda cool in the pattern - I can tell who the tower is talking to for sequencing.

[ScraboTower]

WingX already displayed the call sign and Hilton recently added an option to switch it on/off... I thought at times it cluttered the screen a lot, particularly on smaller screens like an iPhone. Too busy in the pattern to worry about who was who.

[Ergonomicmike]

I'm off topic again, but iFly only shows them when you're zoomed in a lot. (That is, no clutter in cruise.)

[ScraboTower]

I'm off topic again, but iFly only shows them when you're zoomed in a lot. (That is, no clutter in cruise.)

That's a good idea.

[cyoung]

So I built a 1090 "transmitter" that sends specific messages "over the air" (closed loop in this case) and fed in *8dc02d2122c30c30c30c30deacc6; to older versions of the software - dump1090-antirez, dump1090-MalcolmRobb, and the current version. All of them produce a target with identifier '00000000'.

Have you seen this happen again?

@bkwny - was not able to pull data from your logs, all of them were blank after decompressing. Do you have 'Record Logs' on?

[bkwny]

@cyoung - Didn't then, do now.

[cyoung]

How often do they show up? I'm not able to reproduce it locally.

[Ergonomicmike]

If you're asking about 00000000's, they seem "random" to me, in the sense that I can't predict them. I just upgraded to 18de alpha and will let it run for the evening. If I find any 00000000's in a log, I'll let you know.

[Ergonomicmike]

@cyoung There's no 58c6.sh in the /builds directory. Is it in process?

[cyoung]

Where do you get 58c6?

17ab2e5c41 is the latest, it's there now. See right hand side on the commits list to verify latest builds: https://github.com/cyoung/stratux/commits/master

How often are you seeing the "00000000" identifiers? Trying to figure out how long I need to have my setup running before I see one.

[Ergonomicmike]

Oops. NM. 58c6 was the update to get to v0.7b3. Brain fatigue. I get 58c6 (the last 4 digits of the .sh file) in https://github.com/cyoung/stratux/releases.

So far I haven't seen any 00000000's this afternoon. (Saw a 33 go into PHX.) It's a slow Satuday here in Phx. Not very many air carriers flying. Am recording a log and will check it later tonight.

[cyoung]

Not able to reproduce now. I don't think it was an issue on our end. The changes will go to a release version and if there's a widespread issue we'll surely hear about it and reopen.