Floating ac, sliding sideways and backwards ac

[CloudSkimmer]

Describe the bug So we still have these ac just floating above the tarmac and/or runways.

I started in EGLL, and flew around a bit, then flew to EGKK then EGSO smaller airport

A Log.txt file with log level (Settings/Advanced) set to 'Debug' is included Log.txt

Screenshots attached but unfortunately, my day shots are marred bc I never 'x' ed out the settings window (darn!) Night shots are ok I should have a full day tomorrow if all goes according to plan. I can then put in some more time. And I'll remember to x out the windows next time!

*

• X-Plane 11.30b7
• LiveTraffic_0.83.20181212

[TwinFan]

A bit of back and forth on the taxiway, especially if waiting before take off, is difficult to avoid. If planes sit more or less still the position in the data points LT receives jitter slightly just because GPS doesn't stand still and probably also because of consolidation effects of the ADS-B-processing servers. More smoothing of that I would take as an enhancement...like ignoring position updates of less than a meter in distance or so.

Regarding the floating aircraft: You're sure it's not an A306 model with VERT_OFFSET still set to 17.5 as delivered by Bluebell? I can't make out the id of the pictures aircraft, so I have no chance for analysis.

If you find floating aircraft again please try to id them, ideally show a a/c info wnd. Then I can try making out something from the logs.

[CloudSkimmer]

That’s the thing! From day one, when I open the window to identify, I get a blank space where that info should be. It’s why I frantically (lol) take screenshots. So I must be doing something wrong when I call that window up. My apologies if I missed something or misunderstood how to get that info showing. I have several hours today to attach myself to the puter. I need to update drivers, programs, etc then I’ll get right to a flight and test. I’ll keep a close eye 👁 on my messages so you can drill into me brain on getting the info to show in the window instead of blank spaces. Until then, I’ll reread your instructions and try it again. I’ll probably kick myself because I missed sumptin’! :)

[CloudSkimmer]

Btw, I’m almost 100% certain they were a320’s but I’ll recheck.

[TwinFan]

You're supposed to enter the plane's id in that blank field of the a/c window ;) If your a/c label (Settings > Labels) is set up to include "Any a/c id" then the yellow label at the plane will show you an id that works...that you enter into the a/c info wnd. You could even open multiple a/c info windows and follow different planes.

[TwinFan]

Oh...just had an idea...for months already I was thinking about how I could ease the entering of this information....esepcially in a VR environment that difficult, I understand. But there is no functionality in XPlane to map a 2-D mouse click onto an object in 3-D space, so it is not possible to just click on such a multiplayer aircraft and let LT id it.

But the idea I just had is: Display the information of the plane that is closest to the viewer in the direction of viewing...that shouldn't be too difficult to achieve. Entered #62 for that.

[CloudSkimmer]

Ahh! OK..I'll give BOTH a try! First I need to update my nvidea driver and some other x-plane plugins and what-not.

[CloudSkimmer]

Well, that still did not work. I put the ac info in and nothing happens, even after hitting enter. So, again, I took some more screenshots. I also attached the LtRaw data..I hope that helps.... The ac info is hard to read. On top of that, when I zoom in to get closer to the ac in question (I am out of the plane, on the apron, runway or where ever), the yellow description gets microscopic---no kidding! What I do try to do is turn my head so that there is better contrast to the label, then screenshoot it! ..meanwhile, the log.tx AND LtRaw is attached with any worthwhile screenshots... Also, now some ac are doing cartwheels either in the sky or on the ground!!

Log.txt LTRawFD.log

[CloudSkimmer]

Well, that still did not work. I put the ac info in and nothing happens, even after hitting enter. So, again, I took some more screenshots. I also attached the LtRaw data..I hope that helps.... The ac info is hard to read. On top of that, when I zoom in to get closer to the ac in question (I am out of the plane, on the apron, runway or where ever), the yellow description gets microscopic---no kidding! What I do try to do is turn my head so that there is better contrast to the label, then screenshoot it! ..meanwhile, the log.tx AND LtRaw is attached with any worthwhile screenshots... Also, now some ac are doing cartwheels either in the sky or on the ground!!

Log.txt LTRawFD.log

[CloudSkimmer]

closed accidentally then opened again..ooops

[TwinFan]

Thanks for the log files. I will use them for general flight tracking data analysis like for the rocket plabe issue. I'm unable to analyse the specific events in above screenshots without knowing which aircraft this is about or at least having a timestamp.

I am pretty sure the a/c info works...it does so for everybody else. To start very simplistic just try to enter "1" into the empty field where the cursor blinks, and hit enter. This will show info on the first aircraft in LiveTraffic's list...can be any plane, but it's a start for verifying the functionality. If you want a specific aricraft's info you enter call sign, or registration (tail number), or transponder hex code. I understand that the yellow labels are next to unreadable...what's your VR resolution? (Surprisingly, I can't find that info in the Log.txt) Must be massive! Maybe you could for a few minutes switch off VR and use X-Plane the old way on a flat screen to get a feel of how the labels and the a/c info window works? I'll gonna check how the text size is handled for the labels...maybe I have a chance of increasing it in case of high screen resolutions.

In the meantime you could also open OpenSky Explorer and try any aircraft info you find there in close proximity of your simulated location...in the end LiveTraffic shows the very same flights, just with a 90 second delay.

[CloudSkimmer]

OK...finally! Good Idea and thanks. so....Had to manually type in the regi number..clicking on it did not work. Still hard to read those ac labels ..ich bin olt! meine augen ist nicht gute! lol..(sorry abt my German) anyway, the log(s) New LTRaw and xplane's 11.30b7 (after cleansing and saving old LTRaw in another file) and screenshots of the 2ac I found at EGLL floating, rocketing, etc.
Incidentall, on my flight from Cardiff, I was able to see other ac as I was flying at FL120-210, then see ac as I was making my approach into EGLL...very cool indeed! Log.txt

LTRawFD.log

[TwinFan]

Yea, finally :) BTW: Clicking on any label is not supposed to work, see issue #62 for explanation.

Also see isseu #64: OpenSky airplanes using wrong altimeter...but EGLL reported Q1007 this morning, which means they planes should fly too low, not too high.

So, now, with this information I could start analyse the three cases above...and I see very clearly that LiveTraffic assumes the ground at 294f:

LiveTraffic 1544956115.5 DEBUG src\LTFlightData.cpp:896/TryFetchNewPos: DEBUG POS DATA: a/c 341646 IBE31YL SimTime: 1544956115.5 - 2018-12-16 10:28:35
a/c 341646 IBE31YL ppos:
(51.4688, -0.4860)   295f GND_OFF     {h 270, p   8, r   0} [1544956115.5] Y: 74f Phase: 61 Final
posList:
(51.4688, -0.4855)   294f GND_OFF     {h 270, p   8, r   0} [1544956098.0] <h 270,    35m @   4kt,    2ft/m>
(51.4688, -0.4860)   295f GND_ON      {h 270, p   8, r   0} [1544956116.0] <h 328,    66m @   2kt,    0ft/m>
(51.4693, -0.4865)   296f GND_ON      {h 328, p   0, r   0} [1544956192.0]
posDeque:
(51.4693, -0.4865)   296f GND_ON      {h 328, p   0, r   0} [1544956192.0]

If you look at the change from GND_OFF to GND_ON there's actually no change in altitude, it's always around 295f. Likely (will check the LTRawFD tonight) the flight tracking data will report lower altitudes while the plane descends to the runway, but LiveTraffic thinks the ground as at 295f and hold the plane there.

On the other hand, in the second screenshot (same plane) I can clearly see that the plane is doing its Final at 299ft, being 226ft above ground. That would mean ground at the position is 73ft high. Unfortunately there's no debug position output for the very same timestamp in Log.txt for that plane.

Something's fishy with the szenery setup. Which szenery are you using for EGLL? Could you try disabling that one and working with XP11's standard EGLL for a test?

Analysis by far not finished...that were just quick ideas after browsing the data for 10 minutes.

[TwinFan]

Now I spent quite some time with the logs. The main question remains: Why did LT at some point in time decide that the terrain is at 295ft? As we can see from the data pasted above LT decided for GND_OFF at timestamp 1544956098 while 18s later at a very slightly different position it decided at basically the same altitude for GND_ON and kept it like that for the last received position at timestamp 1544956192. This last data for timestamp 1544956192 was received 8 times in total identically. (Apparently OpenSky lost contact at just returned the last available data point for some time, that's normal.) In all 9 cases the data received had no altitude given (null, in this version still processed as 0) and the ground flag set to true. So LT had to determine terrain altitude and set the position to that terrain altitude. It determined 295ft in the first case and 296ft in the 8x repeated second case. And I can't say way...

The rest is explainable: With these (wrong) altitudes given the last leg the plane could fly (from the 1544956116 to the 1544956192 position) was a leg with basically no altitude difference, that means VSI was 0, the plane did not descend below 295ft. The plane was already in flight phase 'Final', so the auto-land mechanism kicked in: Although there was long no data any longer (your screenshots indicate this in the a/c info wnd: The 'Last Data' sits at -500s!) the plane was not removed as the auto-land mechanism says: If in Approach/Final then despite no data keep the plane going for it to land, roll out and stop (see FAQ for more). Only in this case, as the plane could no longer descend, it never touched ground.

Because that is the funny thing: Once the actual plane reached the position at timestamps 1544956116 and 1544956192 at an altitude of 295ft, LT apparently no longer though that this is ground (which in fact in isn't). So by that time LT did not determine touch down and continued in phase 'Final'...that would go on forever.

I'm a bit at a loss here...obviously there was a problem, no doubt. Data says so. But at the moment I can't figure out why it happend.

• [ ] Why did LiveTraffic come up with a too high terrain value for 9 received flight tracking data points?

[CloudSkimmer]

Very interesting. As far as EGLL, that is X-Plane stock. But under that is the ORBX S.UK mesh and scenery. That’s funny because when I’m in my home base of LSZH, my other flying area (in rl too), the exact same thing happens but with more rocketing than EGLL. LSZH happens to be Aerosoft that has been out since beginning of XP10 and updated since, and it contains a special mesh in and around the airport. I don’t remember seeing floating ac there. Just rocketing! I’m up early (as usual) and after my coffee and regular constitution and meditation, I’ll fit in a quickie flight at a different and “virgin” airport (no special mesh or scenery) and recreate what I did last time. Thank you for your in depth analysis too, as well as your patience with my testing (last ten days have been quite hectic here at the hacienda!). Once I’m “coffeed up”, I’ll study this again and then “fly away...”!! Hopefully it will pan out coz I want to see this work as much as you do :)

[CloudSkimmer]

Here are the files and screenshots. From Frankfurt am Main since this is hard stock x-plane and this time xplane 1030rc1. One of the shots are just all the planes at once floating above the tarmac, the others have the info window. I actually went to a major airport in Canada and could not get any ac injected, so I just went to Germany since you've mentioned this. LTRawFD.log Log.txt

[CloudSkimmer]

And... Why did LiveTraffic come up with a too high terrain value for 9 received flight tracking data points? My guess is that the Hq/Hpa barometric pressure is coming into play..somehow!

[CloudSkimmer]

And... Why did LiveTraffic come up with a too high terrain value for 9 received flight tracking data points? My guess is that the Hq/Hpa barometric pressure is coming into play..somehow!

[CloudSkimmer]

@TwinFan ok, This new build I grabbed some shots using the AUTO for the nearest ac. I was at EGLL just flying around. Many ac, some landing, taking off or taxiing to where ever but of course some floaters. I went and snapped three and included my log and LtRaw. Still looks great, esp with ac coming and going. Log.txt LTRawFD.log