Closed Ergonomicmike closed 8 years ago
Both of those "tail numbers" show up in a flightaware search with local and international flights between Europe & the America's, so it's not a bug that's limited to Stratux although it could be a dump1090 bug. But it's most likely some of your aforementioned chemtrail conspiracy aircraft flown by martians for the Jade Helm exercises. I'm keeping my tinfoil hat handy just in case.
Interesting. I wonder how they display at ATC? (peepsnet? Or do we have to have Clearances for you to tell us?)
If this issue isn't unique to Stratux but an "up the chain" problem, should I close this issue then? It's not like a bizarre call sign is a deal breaker.
We do not care at all about your ADS-B!!! Our displays do not look at adsb data. We associate your squawk code to flight info.
That could be just miscondigured ADS-B eqp. I would like to also see the ICAO HEX code for the targets at the same time. I know you could grep log files but is can be easier then that.
Ill add another column to the traffic page for that data or if @avsquirrel could get that. I know he now has it share with the callsign until the callsign is known but it seems like too many times I need the hex code along with the callsign
Could you post the nnnn-es.log(.gz) and nnnn-dump1090.log(.gz)?
Tail number was N700PP, btw.
Disregard. Those files are too early. I'll upload the next session shortly.
https://www.sendspace.com/file/mfo8b8
https://www.sendspace.com/file/9dm3kh
P.S. UTC is +7 local.
Here's one example:
*8dc02d2122c30c30c30c30deacc6;
CRC: 000000
RSSI: -26.3 dBFS
Score: 1800
Time: 1644796131.00us (phase: 0)
DF 17: ADS-B message.
Capability : 5 (Level 2+, airborne)
ICAO Address : c02d21
Extended Squitter Type: 4
Extended Squitter Sub : 2
Extended Squitter Name: Aircraft Identification and Category
Aircraft Type : A2
Identification : 00000000
c02d21 has Canadian registration C-FRCI.
And another one:
*a0001a3020c30c30c30c300f2c91;
CRC: a955e1
49016889971363,RSSI: -30.0 dBFS
Score: 1000
Time: 670358238.42us (phase: 300)
DF 20: Comm-B, Altitude Reply.
Flight Status : Normal, Airborne
DR : 0
UM : 0
Altitude : 41000 feet
ICAO Address : a955e1
BDS 2,0 Aircraft Identification : 00000000
a955e1 has tail number N700PP.
Both C-FRCI and N700PP are blocked on FlightAware.
If it was done intentionally and is just a privacy thing, then I question why this hasn't come up before.
Street address: Military Trail, Jupiter, FL. (Peepsnet's backyard.) http://registry.faa.gov/aircraftinquiry/NNum_Results.aspx?NNumbertxt=700pp
Before that, Arlington, VA.
CIA?
Close this? Seems like the Stratux is decoding what's being sent.
I am not yet convinced Stratus correctly decoded what was sent. I too yesterday saw an aircraft with N and one with 00000000. And I have never seen one before. And I am on the other side of the country from ErgonomicMike. I suggest we leave this open for a while and keep our eyes open.
Seems like the only definitive way to see if this issue is a function of the new dump1090 is to have two Stratuxi running side by side, one with this alpha and the other with v0.7b3 or below to compare to. (Or have a production ADS-B unit to compare to, which we presume does everything right.) I don't have either for testing. And I don't have any old logs to grep thru. (Update: I do have rwo SD cards w/ the different versions. I could try to swap; reboot quickly if I see this again.)
Since the two aircraft were blocked by FlightAware, I lean to thinking that the Identifications were intentionally obscured. I mean, it's not like we're getting garbage in the field. As to why we haven't noticed them before - in addition to hit or miss (I mean, how often do we look at the Traffic page?), SuperTuesday campaigning? (It's amazing that bkwny & I saw the same call signs. Would be interesting to know if his logs show they're the same aircraft.)
@bkwny - do you have a copy of es.log and dump1090.log?
@Ergonomicmike - Same "call signs" = "00000000"? There are two different aircraft in your logs alone that have that "call sign".
When I watch the traffic on my PiAware at home, it is not uncommon to see nonsensical tail numbers. All ???????,12345 excetera. I believe you are correct, FlightAware is blocking the tail numbers as required and this is a non-issue for Stratux.
If anyone wants to investigate this, try taking a look at *8dc02d2122c30c30c30c30deacc6;
and seeing how dump1090-antirez and dump1090-MalcolmRobb would have decoded it. We could probably filter out some junk, but I'd like to know what has changed since moving to this new version of dump1090.
N700PP is a G-IV registered to a leasing corporation based in a strip mall storefront on a commercial street near Palm Beach, FL (I have relatives in the area)
IIRC, one of the vendors of ads-b in/out units, one a unit designed for experimentals, allows you to set your id as "0" so that your real id won't be known to whomever is watching (including FAA) and to be able to fly until your "official ID" is assigned.
On 03/01/2016 07:50 AM, cyoung wrote:
@bkwny https://github.com/bkwny - do you have a copy of es.log and dump1090.log?
@Ergonomicmike https://github.com/Ergonomicmike - Same "call signs" = "00000000"? There are two different aircraft in your logs alone that have that "call sign".
— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/298#issuecomment-190730523.
@cyoung : Hand-decoding of *8dc02d2122c30c30c30c30deacc6;
checks out to all zeros.
8dc02d2122c30c30c30c30deacc6
Byte 1 is downlink format and capability.
8d --> 10001 101 -> DF = 17, CA = 5
Bytes 2-4 are the ICAO 24-bit code.
c0 2d 21 -> ICAO C02D21
Byte 5 is the type code and emitter category.
22 -> 00100 010 -- > TC4 = Set "A", emitter category 2
Bytes 6-11 encode the callsign in a 6-bit format.
c3 0c 30 c3 0c 30 -->
1100 0011 0000 1100 0011 0000 1100 0011 0000 1100 0011 0000 -->
110000 110000 110000 110000 110000 110000 110000 110000
110000 == zero
Bytes 12-14 are a checksum.
de ac c6 --> Checksum
@cyoung Regarding the "same" call signs, I was referring to "00000000” and "N."Bwkny says he saw both too. If you look at the screen shot of my Traffic page, they were both flying at the same time. So if you find 00000000 at 19:23Z, there should be an "N" call sign aircraft nearby too.
@224XS "How to make a million dollars." Open a Leasing Corp in a strip mall. (I think 60 Minutes did a story on fake front govt ops like this a couple years ago.)
"N " appears to be A4AB66, N40ML, an EMB-505 registered to a dealer in Fort Lauderdale.
Cmon now Mike, you know that, in aviation, to make a million dollars in aviation, you start with 2 million! Three million would be better.
Just a comment about the xxxx-se.log. Could the ICAO address be stored as Hex again? It is really strange looking at it as a decimal value.
Also, instead of including "Tag": Value for each entry can a header row be added when the file is created then the values would be appended below the header. This will save from writing redundant data to the file each time a line is written. It would also make it easier to parse the data for analysis with ready made headers in the file.
Thanks.
I'm not doubting that Jeff saw "????????" as a Call Sign. But I am surprised that question marks are in the allowed character set for ADS-B stuff.
Guys, Why can this not just some ppl who entered garble-d-gook in the FMS. If i remember to boot up my stratux ill pull the log. ]
This jetblue entered BWIFATTY in his FMS as flight number and it showed up on my stratux
I know that in an advanced FMS the pilot enters the flight number(SWA143) but the N-number is harder to get to and change(N13245) so the pilot just entered a flight number as 0000000000 or N.
Most of the SWA and ASY seem to only use their number(i.e. 143 for SWA143) so you see 143 or 2425 not SWA2425 in the traffic screen
root@raspberrypi:/var/log/stratux# zcat 0039*es*log* | grep 'BWIFATTY' 9494705376865,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":2,"SubtypeCode":0,"SBS_MsgType":5,"SignalLevel":0.359009,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":0,"OnGround":false,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":-200,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:55:24.565Z"} 9494892039938,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":28,"SubtypeCode":1,"SBS_MsgType":5,"SignalLevel":0.562655,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":null,"OnGround":false,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":-200,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:55:24.710Z"} 9494892823168,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":28,"SubtypeCode":1,"SBS_MsgType":5,"SignalLevel":0.567649,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":null,"OnGround":false,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":-200,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:55:24.711Z"} 9494893439470,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":28,"SubtypeCode":1,"SBS_MsgType":5,"SignalLevel":0.569842,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":null,"OnGround":false,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":-200,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:55:24.712Z"} 9494894002282,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":28,"SubtypeCode":1,"SBS_MsgType":5,"SignalLevel":0.569083,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":null,"OnGround":false,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":-200,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:55:24.712Z"} 9494894488897,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":28,"SubtypeCode":1,"SBS_MsgType":5,"SignalLevel":0.557482,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":null,"OnGround":false,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":-200,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:55:24.713Z"} 9494895132074,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":28,"SubtypeCode":1,"SBS_MsgType":5,"SignalLevel":0.529914,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":null,"OnGround":false,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":-200,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:55:24.717Z"} 9494895755980,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":28,"SubtypeCode":1,"SBS_MsgType":5,"SignalLevel":0.538633,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":null,"OnGround":false,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":-200,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:55:24.718Z"} 9601250019012,{"Icao_addr":10624916,"DF":21,"CA":0,"TypeCode":7,"SubtypeCode":2,"SBS_MsgType":6,"SignalLevel":0.585925,"Tail":"BWIFATTY","Squawk":2664,"Emitter_category":null,"OnGround":true,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":0,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:57:11.095Z"} 9642801374830,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":4,"SubtypeCode":0,"SBS_MsgType":5,"SignalLevel":0.525949,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":0,"OnGround":true,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":0,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:57:52.621Z"} 9642802118580,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":4,"SubtypeCode":0,"SBS_MsgType":5,"SignalLevel":0.537489,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":0,"OnGround":true,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":0,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:57:52.622Z"} 9642802644621,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":4,"SubtypeCode":0,"SBS_MsgType":5,"SignalLevel":0.522148,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":0,"OnGround":true,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":0,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:57:52.622Z"} 9642803161028,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":4,"SubtypeCode":0,"SBS_MsgType":5,"SignalLevel":0.526374,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":0,"OnGround":true,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":0,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:57:52.623Z"} 9642803664153,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":4,"SubtypeCode":0,"SBS_MsgType":5,"SignalLevel":0.542857,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":0,"OnGround":true,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":0,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:57:52.624Z"} 9642804739413,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":4,"SubtypeCode":0,"SBS_MsgType":5,"SignalLevel":0.521478,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":0,"OnGround":true,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":0,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:57:52.628Z"} 9642805255767,{"Icao_addr":10624916,"DF":20,"CA":0,"TypeCode":0,"SubtypeCode":0,"SBS_MsgType":5,"SignalLevel":0.538179,"Tail":"BWIFATTY","Squawk":null,"Emitter_category":null,"OnGround":true,"Lat":null,"Lng":null,"Position_valid":false,"NACp":null,"Alt":0,"AltIsGNSS":false,"GnssDiffFromBaroAlt":null,"Vvel":null,"Speed_valid":false,"Speed":null,"Track":null,"Timestamp":"2016-03-01T04:57:52.636Z"}
9494704596657,Flight Status : Normal, Airborne 9494704636345,DR : 0 9494704677907,UM : 0 9494704719574,Altitude : -200 feet 9494704759730,ICAO Address : a21f94 9494704801449,BDS 2,0 Aircraft Identification : BWIFATTY 9494707367074,*8ca81b2a38ffd183b79b77098a46; 9494707433011,CRC: 000000 9494707474730,RSSI: -3.3 dBFS 9494707513636,Score: 1800 9494707551865,Time: 6180035245.67us (phase: 120)
As luck would have it, "????????" just flew over.
Here comes another Mr ?????? along with Mr All Zero's and a fella with a space in his number.
@cyoung - /var/log/es.log? And where is dump1090.log?
@peepsnet:
Why can this not just some ppl who entered garb-d-gook in the FMS
Agreed. Even GA Mode S transponders can be set up to allow callsign entry (it's a config menu option that takes about 15 seconds to set), and any alphanumeric string of up to eight characters is a valid input. GTX330 pilot's guide:
From what I've seen so far, there's nothing to be solved on our end. It's all either lazy data entry ("1304"), guys messing around ("BWIFATTY"), or superficial attempts to hide a flight number ("00000000")
BTW, I saw your request for adding a ICAO codes to UI. Web design really isn't my forte, but I'll see what I can do. The UI's getting a bit crowded, so maybe a toggle to switch between callsign and ICAO? Thinking of doing something similar for my distance / bearing display, to toggle between lat/lon and distance.
@Ergonomicmike:
But I am surprised that question marks are in the allowed character set for ADS-B stuff.
They're not. The ES specification calls for a "6-bit subset of the International Alphabet Number 5 (IA-5)" . Valid characters are A-Z, [space], and 0-9.
These map out to decimal values 1-26, 32, and 48-57 in the raw message. Older versions of dump1090 (antirez, MalcolmRobb) substituted question marks for any invalid values; dump1090-mutability does its lookup against a more complete character set (i.e. the gaps are filled with the unused ASCII characters that correspond to those values). Either way, a question mark tells you that something is wrong with the value that was sent / decoded.
The callsigns that decoded as "00000000" or "N__" or "4237 94" were intentionally set that way. The raw ES messages for "00000000" don't contain a run of zeroes; they contained eight consecutive '48' values (or 0x30 hex) packed together into six bytes -- the c3 0c 30 c3 0c 30
noted earlier. Likewise, you're not going to "accidentally" see seven consecutive spaces (0x20)
Thanks for the answer on the question marks. Didn't make sense that they would be allowed during entry. But it makes sense that they're being added during decode.
I agree with you that these are intentional goofy ADS-B id's and there's nothing we can do about it. But I'll leave it to Chris to close this issue.
@bkwny - Check /var/log/stratux/.
@AvSquirrel - any idea why this didn't show up before? Well, maybe it did - but I certainly never saw it before this version switch. Say, are there standard formats we could regex for and only accept for tail numbers, flight numbers, etc? Filtering out garbage identifiers would be ideal.
@Nokomis449 Do you still have that production box that you used to confirm the "Papa Alpha" zero altitude issue? How does it report these strange tail numbers?
@cyoung - I would suggest not masking off data. Just print whatever the aircraft is broadcasting and document that's what you're doing.
Odd callsigns captured with dump1090-MalcolmRobb (data collected 1/1/2016) include "TEST1234", "7", "H ????AA", and "????????"
27228248459619,MSG,6,111,11111,A3C9B4,111111,2016/01/01,15:14:17.475,2016/01/01,15:14:17.465,H ????AA,,,,,,,3620,-1,0,0,0
27251844096121,MSG,6,111,11111,A3C9B4,111111,2016/01/01,15:14:41.094,2016/01/01,15:14:41.061,H ????AA,,,,,,,3620,0,0,0,0
26996912077765,MSG,1,111,11111,A52E54,111111,2016/01/01,15:10:26.182,2016/01/01,15:10:26.128,7 ,,,,,,,,,,,0
8962961519799,MSG,1,111,11111,ADF992,111111,2016/01/01,17:46:33.462,2016/01/01,17:46:33.456,TEST1234,,,,,,,,,,,
8974828194065,MSG,5,111,11111,AC8B43,111111,2016/01/01,17:46:45.369,2016/01/01,17:46:45.323,????????,1525,,,,,,,0,,0,0
Not sure which box that was (SkyRadar DX?), but I keep the Stratux's updated to the bleeding edge. I'll be flying about 10 hours this weekend with both so I'll look for "0" altitudes. If anybody in Florida sees N6776N flying around, waggle your wings at me.
@cyoung -- You could make a case that any callsign that contains invalid characters (i.e. not A-Z, [space], 0-9) should be rejected. I wouldn't touch any of the other "odd" formats if they checksum and decode correctly.
Well at least Stratux is letting more people to pay attention to the data that's floating around out there. There are even instances where installations are sending the wrong Mode S address for their tail number, and this is not the anonymous address.
@Nokomis449 Oops - my mistake. Confused with ScraboTower near me. NM. (But if you have a SkyRader with you while you're flying, see if you can see any goofy Call Signs on it.)
@cyoung - Per your request:
https://drive.google.com/file/d/0B99rMHH_dTvASzZQUnlvZ2FYRFU/view?usp=sharing
@Axtel4 - That wrong Mode S really, really bothers me. It doesn't have to be a mistake. It can be done on purpose. There is no way for me to prohibit somebody else from transmitting my Mode S code. Arggh...
@bkwny
It happens for a number of reasons: the N number is changed but the Mode S address isn't, a hardware failure in the transponder, mis-programming / incorrect strapping at installation, intentionally changed, etc.
People complain about the FAA requiring the correct data out to get data in, but that is one method that is being used to validate the systems in operation. If someone isn't getting In when they think they should, it will force them to verify their installation is correct. We should see less of the wrong ICAO addresses as we get closer to the mandate and the systems are being validated.
On March 1, 2016 4:47:10 PM CST, bkwny notifications@github.com wrote:
@Axtel4 - That wrong Mode S really, really bothers me. It doesn't have to be a mistake. It can be done on purpose. There is no way for me to prohibit somebody else from transmitting my Mode S code. Arggh...
Reply to this email directly or view it on GitHub: https://github.com/cyoung/stratux/issues/298#issuecomment-190944848
I respectfully disagree on filtering out anything with the callsign. I would rather see what the plane is actually broadcasting. Besides, to parrot some of Mike's comments, I feel the EFB is the "brains", and the place to filter the data as necessary.
@Axtel4 - I'm talking about the guy who squits my Mode S on purpose, commits an airspace violation, and then lands. How would I defend myself against the onslaught of FAA enforcement actions that would no doubt be taken against me? This whole idea that anybody can put any Mode S code he likes into any squitter and go fly around with it is just beyond ludicrous.
@Nokomis449 - Re: filtering, I agree. Don't filter, just print what the aircraft sent.
imagine that! People wanting their privacy. Why, I never
On 03/01/2016 03:40 PM, AvSquirrel wrote:
@peepsnet https://github.com/peepsnet:
Why can this not just some ppl who entered garb-d-gook in the FMS
Agreed. Even GA Mode S transponders can be set up to allow callsign entry (it's a config menu option that takes about 15 seconds to set), and any alphanumeric string of up to eight characters is a valid input. GTX330 pilot's guide:
From what I've seen so far, there's nothing to be solved on our end. It's all either lazy data entry ("1304"), guys messing around ("BWIFATTY"), or superficial attempts to hide a flight number ("00000000")
BTW, I saw your request for adding a ICAO codes to UI. Web design really isn't my forte, but I'll see what I can do. The UI's getting a bit crowded, so maybe a toggle to switch between callsign and ICAO? Thinking of doing something similar for my distance / bearing display, to toggle between lat/lon and distance.
@Ergonomicmike https://github.com/Ergonomicmike:
But I am surprised that question marks are in the allowed character set for ADS-B stuff.
They're not. The ES specification calls for a "6-bit subset of the International Alphabet Number 5 (IA-5)" . Valid characters are A-Z, [space], and 0-9.
These map out to decimal values 1-26, 32, and 48-57 in the raw message. Older versions of dump1090 (antirez, MalcolmRobb) substituted question marks for any invalid values; dump1090-mutability does its lookup against a more complete character set (i.e. the gaps are filled with the unused ASCII characters that correspond to those values). Either way, a question mark tells you that something is wrong with the value that was sent / decoded.
The callsigns that decoded as "00000000" or "N__" or "4237 94" were intentionally set that way. The raw ES messages for "00000000" don't contain a run of zeroes; they contained eight consecutive '48' values (or 0x30 hex) packed together into six bytes -- the |c3 0c 30 c3 0c 30| noted earlier. Likewise, you're not going to "accidentally" see seven consecutive spaces (0x20)
— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/298#issuecomment-190917530.
Interesting question. How does one guard against that?
On March 1, 2016 5:13:04 PM CST, bkwny notifications@github.com wrote:
@Axtel4 - I'm talking about the guy who squits my Mode S on purpose, commits an airspace violation, and then lands. How would I defend myself against the onslaught of FAA enforcement actions that would no doubt be taken against me? This whole idea that anybody can put any Mode S code he likes into any squitter and go fly around with it is just beyond ludicrous.
@Nokomis449 - Re: filtering, I agree. Don't filter, just print what the aircraft sent.
Reply to this email directly or view it on GitHub: https://github.com/cyoung/stratux/issues/298#issuecomment-190955974
@Axtel4 - One can't. A syntactically valid squit is just that. It doesn't matter who sent it or whether the data in it is true.
We have public key cryptography but the ADS-B system designers didn't employ it. Instead, they assumed every aircraft and aircraft operator is trustworthy: trustable to transmit the correct Mode S code, trustable to transmit an accurate lat/long, and the like. IMHO this is a fatal flaw of the system design.
The callsigns will have to match because the CPDLC system will fail otherwise. I am an SME for implimenting this at KFLL https://www.google.com/search?q=cpdlc&oq=cpdlc&aqs=chrome..69i57j0l3.1863j0j4&client=tablet-android-hms-tmobile-us&sourceid=chrome-mobile&ie=UTF-8
Squitting does not require talking to a controller.
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.
And at a minimum requires VDL Mode 2 which most GA aircraft doesn't have installed.
On March 1, 2016 6:23:30 PM CST, peepsnet notifications@github.com wrote:
The callsigns will have to match because the CPDLC system will fail otherwise. I am an SME for implimenting this at KFLL https://www.google.com/search?q=cpdlc&oq=cpdlc&aqs=chrome..69i57j0l3.1863j0j4&client=tablet-android-hms-tmobile-us&sourceid=chrome-mobile&ie=UTF-8
Reply to this email directly or view it on GitHub: https://github.com/cyoung/stratux/issues/298#issuecomment-190985959
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