-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GA aircraft appear as Airbus or Boeing airliners #44
Comments
After testing the clean XP11.26 installation, I tested my normal, rather complex 11.26 version, again at KAPA. LT loaded nicely and showed the correct number of aircraft, correct registrations and approximate positions compared to Flightaware, but, once again, wrong aircraft type (airliner rather than GA). This time I took a screenshot of the A/C info window. Here it is along with the log.txt |
Added ADS-B Exchange and now many aircraft show correct type (and in total, a lot more aircraft)! I was surprised that I can have both OpenSky and ADS-B Exchange checked at the same time. |
A320 is the "default" a/c type if the LT/multiplayer library can't decide anything better. Here LT probably couldn't get hold of good a/c master data. In OpenSky the pure tracking data contains no a/c info. That's why there is the additional masterdata channel. If LT only receives tracking data but cannot get master data then it's gonna be an A320. For the second case Log analysis was easier as the transponder code A2AF88 is there. And the log says about that plane:
So LT couldn't process that master data. However...621 received chars looks about correct. Sending that query again now, days later, my browser receives a totally valid answer of, chacka, 621 characters:
That would mean that LT failed processing some of that data and bailed out. Just an idea to be verified: LT (specifically the JSON parser) stumbles over the < in the category description. |
FYI I tried again using OpenSky with same result - mostly A320s - while ADS-B Exchange provided correct aircraft types |
Found the reason...EDIT: not necessarily a bug: Here (LTFlightData.h:138) the function "empty" expects and operator code to be set:
This is included in the checks if data is valid. So...refusing the data is correct...however, if we see that behaviour too often we might need to look for a different solution, probably a lookup in the Doc8643 data. That's why I also add label 'Enhancement' to it. |
I am not sure I understand why it seems to affect OpenSky and not ADS-B Exchange |
Well, it’s different databases maintained by different software and different people. Lots of chances to produce differences. It’s free (under conditions) resources...no warranty, no guarantees, not complete. So we need to live with yet another inaccuracy. Unfortunately, “172S” doesn’t appear as a model description in Doc8643 either (maybe that’s also why OpenSky didn’t find it?). |
I understand those potential differences, but I seem to recall seeing a King Air 200 shown correctly as a BE20 and a Bombardier Challenger shown correctly as a CL30 by ADS-B Exchange and shown as A320s by OpenSky; could OpenSky just ignore GA/business aircraft (at KAPA - essentially a GA/business jet aitport, OpenSky only had airliners). In any case, matching Beechcraft to either BE58 or BE9L in a reverse Doc8643 would make it right also 80% of the time. |
Using ADS-B Exchange, I finally caught a displayed aircraft without ICAO type |
Aha, ADS-B Exchange as well, soso. With ADS-B Exchange the a/c master data comes within the tracking data (that's why there is only one stream). So unlike OpenSky I cannot check the master data independently. But one line out of your Log.txt already tells most of what we need:
Note the empty paranthesis in the second line: That's the aircraft from your screenshot. That's where the type code should be as in the first of the log lines. So also here: ADS-B Exchange didn't send an ICAO type code. |
|
Well...certainly...we can add all the world's planes to Edit: THat test was soooo easy: And confirmed: No Boeings displayed for airbusses. There's something wrong with the doc8643 matching in the multiplayer library...darn...I have to dig into that old code. |
Easy on my side too: here is a Cirrus S20 shown as an A320 and the log.txt with Debug: Log model matching checked (I had it on all along but forgot to attach the log.txt in previous post) |
Basically fixed! At least reinstalled the functionality originally intended. See here: An incoming A380 (what a concident after 2 minutes of testing) "correctly" matched to a B747:
Liveries don't match up, defaults to BAW. Maybe I can even fix that with a recursive match... |
"Time for a new beta release, I guess...but tomorrow." PS Look at the CSLs loaded in my log.txt (3 comments above): I have added a lot of models that I have fixed so they do not produce parsing warning. |
Wow, @TwinFan, Sie sind schnell! Looking forward to that. |
Issue still open for the idea of a "reverse doc8643", which would be considered in case icao type code is missing from the tracking data, but manufacturer/model text is available. The latter is human readable, not standardised, and would need an intelligent interpretation or damn long list for a mapping to reasonable ICAO type code.
which would allow to assess the situation over time and probably devise other means of deducting a good ICAO type code guess, e.g. by taking the info into the existing doc8643...the single example above could be fixed by stating: Try finding the manufacturer, ignore everything after a dash [which usually distinguishes sub-types of aircrafts not needed for a reasonable model match] and try to find a match in the type code and model fields of doc8643 (while ignoring spaces, dashes and the like on both sides). That rule would have determined A321 as a type code in this single case. Will revisit these messages from time to time to see if a rule like the above really helps in a resonable number of cases. |
I fully agree. |
I saw some regression today. After getting LT v0.86.20190112, I flew from KAPA to KBJC in a new plane I just got (Carenado C172 G1000),and after landing, I was reloading several aircraft to link them to different profiles on my yoke) when I noticed one A320 high over the runway threshold before the take-off roll and it stayed at that level the whole length of the runway: the regression is that it was a Piper PA28 that should not have been shown as an A320. Next I saw 2 other A320s landing and they were actually C172s, so the wrong model again. |
PS Thinking that it might have been my error not to have made sure the CSLs in LT were loaded, I went back and reloaded at the same airport, went into LT settings/CSL, made sure the LT box is checked (there is only LT in this particular XP installation), clicked on Load anyway., got message that the CSLs were successfully loaded and still only A320s for GA |
PPS On a hunch, I once again reloaded, went into LT settings and changed the default from A320 to C172 and now it seems that the C172 is used every time. It appears that the default overrides the model matching. |
PPPS I really am confused now; I tried one more on a different XP installation. Now the model matching seems to work The only difference between the 2 XP installations is that in the one where model matching did not work, I had LT showing NO label for aircraft (my thought here was I no longer test. I am just using LT to increase realism). I will now test that. I am at a total loss, I hope you can make sense of everything above. |
I can...it's just the original issue ;) The real difference is not the installation but the received tracking data. Watch the "ICAO type" line in the info window! In the first 2 cases it reads "?", i.e. the networks did not provide an ICAO type. LiveTraffic had no means of deriving a model and reverted to the default: Which was A320 in both cases:
In the second and third case the ICAO type code actually is "C172", i.e. the networks did say that this actually is a C172, which certainly means that it will be rendered with C172, no matter what is configured as default (as you have a C172 CSL model in your installations). So for the case provided in the screenshot in case 3 the change from A320 to C172 did not even make a change.
The changed default in case 3 did make a change for eight other aircrafts, though, not pictured in screenshots but visible from the
All are now rendered using the C172 model. (The fact that the chosen flight model here is [MediumJets] is because that this the default based on no available ICAO type code...has nothing to do with the chosen CSL model. See the difference above for N1839E and N998DW from case 3 and 4: In their log lines the chosen flight model is [GA], which better matches a C172.) Please don't get confused from the human-readable manufacturer/model information in the A/C info window, which is non-standardized. Our idea earlier here in the issue was to use that human-readable text for a reverse lookup... But as the reverse lookup is not yet implemented the entire model-matching bases solely on the ICAO type code. And that was empty in all irritating cases. |
Thank you for the explanation. If I recall correctly, I was using only OpenSky as the source when the missing ICAO occurred (and I am not sure how that happened since I did not intentionally uncheck ADSBEX and have been using both at the same time consistently for a while) - I believe this is not the first time that OpenSky had this issue where I often fly. |
Both OpenSky and ADS-B Ex have the issue from time to time and on different aircrafts. We can't do anything about it. If both channels are on and both channels see a specific plane then at least one of the channels need to pass in an ICAO code for the correct model to appear. |
Understood. I suppose it is more the reason to use both, thereby reducing the odds of not having the ICAO code,. |
Forum user crbascott extracted a useful file from OpenSky's aircraft.csv database, which does the trick of matching available model text to a/c type like this (some random extracts of his file):
This file is just under 300kb in size and can easily be distributed together with LiveTraffic. So the reverse-doc8643 functionality can now become reality:
|
On a clean installation of XP 11.26, with LiveTraffic 0.81 and Bluebell CSLs + required xsquawkbox files, I tested this morning at my "home" airport Centennial (KAPA), comparing to the traffic that appears on Flightaware. LiveTraffic shows the correct number of nearby planes, the correct registration number and their approximate locations, but NOT the correct type. KAPA is essentially a GA airport but LiveTraffic only displays Airbus and Boeing airliners.
For example, the screenshot attached shows an airliner with registration N5306U, which on Flightaware is identified as a C172. The A/C information window when this registration number is entered has a blank field for the a/c type (sorry forgot to take a screen shot of the A/C info window).
Log.txt
The text was updated successfully, but these errors were encountered: