Small lag on touchdown

[felipebutcher]

Hi there! Thank you very much for this. I tried with the PMDG 737 and looks like everything is working (flaps, landing gear, airspeed brake). Very nice.

I only found a small issue. Tried recording 3 landings and it happened all the 3 times. There's a small lag right when the airplane is going to touch the ground. I've looked the generated sqlite db and found this little gap (~500) between two timestamps right when attitude becomes close to the airport attitude. Looks like the difference between all the timestamps are usually around 30. Not sure if that's the issue but just fyi.

Here is a recorded video where you can see the touchdown lag: https://drive.google.com/file/d/1T65WlKZ61qb9W-ytLkf2i5rH_-SnBzr9/view?usp=sharing

Tried with version 0.14.

And here's a screenshot of the db, as you can see the gap between 30807 and 30808 is bigger than the others.

[till213]

First of all, thank you very much for the detailed analysis that you have already done (including diving into the logbook with an SQL browser ;)) and clear issue description, that is very helpful!

I think you also understand a bit of programming, so I'll go into some details, but not too much (in order not to bore you too much with it ;)).

Sky Dolly gets notified about new data ("simulation variables") via system events: I therefore create a hidden widget (EventWidget.cpp) that does nothing else than listening for SimConnectUserMessage messages ("native window events").

That SimConnectUserMessage (and it's funny: I just noticed that I spelled it wrongly in the code, with three 'n' - but that's not the root cause here ;)) is a simple integer number that I register with SimConnect when connecting to MSFS, together with the "window handle" of the event widget which is expeting the system messages ("native events"):

const auto hWnd = reinterpret_cast<HWND>(d->eventWidget->winId());
const DWORD userEvent = EventWidget::SimConnnectUserMessage;
const HRESULT result = ::SimConnect_Open(&(d->simConnectHandle), ::ConnectionName, hWnd, userEvent, nullptr, ::SIMCONNECT_OPEN_CONFIGINDEX_LOCAL);

Like this I don't have to poll for new data (like most MSFS SDK examples do), but get conveniently informed whenever new data (as in "the observed simulation variable has actually changed"): the EventWidget then emits a so-called "signal" (that's a C++ extension / functionality of the underlying Qt framework that I use, think "observer pattern" here).

So whenever the event widget sends the simConnectEvent the "slot" (= the Qt way of defining a method that can be connected to a "signal") processSimConnectEvents is called:

• Update the current timestamp (in the common base class AbstractSkyConnect)
• Call SimConnect_CallDispatch which on its turn is calling my "dispatcher" function ("callback") that checks what kind of data has been received (and records/stores it accordingly in an array (a std::vector, to be specific), together with the previously updated timestamp)

So in the case of "position data" (latitude, longitude, altitude, pitch, bank, heading):

auto simConnectPositionAll = reinterpret_cast<const SimConnectPositionAll *>(&objectData->dwData);
PositionData positionData = simConnectPositionAll->toPositionData();
positionData.timestamp = skyConnect->getCurrentTimestamp();
if (storeDataImmediately) {
    userAircraft.getPosition().upsertLast(positionData);
    dataStored = true;
} else {
    skyConnect->d->currentPositionData = std::move(positionData);
}

where getCurrentTimestamp() simply returns the previously updated timestamp (in milliseconds). I am requesting a "high precision timer" that - depending on the operating system - should have a precision up to nanoseconds (on Windows operating systems I think). So this should not be the issue here:

https://doc.qt.io/qt-6/qelapsedtimer.html#ClockType-enum

So on Windows the QElapsedTimer is using "Windows performance counters".

And that's all there is. Specifically Sky Dolly is not doing any "special calculations just before touch-down": the received data is not interpreted in any way during recording, other than it being stored in the memory array together with the timestamp that is updated (based on the performance counter used by QElapsedTimer (*)).

So I don't have any real explanation yet for this apparent timestamp gap that you have discovered and that is made very evident in your recorded video :( My only rough guess would be that the simulator (the aircraft itself perhaps) is doing some very intensive calculations just before touch-down that is somehow "starving" the SimConnect task within MSFS itself, such that there is a short "hickup" in sending updated simulation variable data. And it is interesting that this seems to be even reproducible with three landings, as you say.

What I plan to do anyway is to actually reduce the sample frequency for the position (only lat/lon/alt - not attitude) to 1 Hz. While this may sound counter-intuitive my goal here is to automatically "smoothen" the sampled data, by only taking a sample very second. The aircraft attitude and everything else would remain at the highest possible sample rate, based on the "system events" (which are sent by MSFS for every "simulated frame"), as discussed above. Because when you sample the position for every "simulated frame" you also sample every "aircraft jitter".

Whether this would actually help in this case I don't know. Maybe simply separating the actual position data from the attitude data (pitch, bank, heading) would have a positive impact (assuming that something with calculating the attitude is "holding up" the position data).

By the way, are you manually landing or with the help of a landing system (ILS)? I am asking because maybe the "landing system" may consume the CPU just shortly before touchdown. And I assume that during the actual flight you did not encounter those delays, correct?

So I will use this issue for may anyway planned "natural smoothening of position sample data" (by reducing sample rate to 1 Hz). And of course I will try and see whether I can actually reproduce this issue myself with my own (poort) landing skills (and that aircraft).

(*) You might have noticed that I am linking to the Qt 6 specific documentation pages here, whereas Sky Dolly v0.14 is still using Qt 5.15.2 hint hint ;)

[felipebutcher]

Hey my dude. You are very welcome! In fact I'm a developer too :). I was going to try building your app to play with the code a little but I haven't had time yet.

Responding to your question, it was a manual landing.

Althought I don't know the code well yet, I thought similarly to you, maybe a high cpu usage or some other bottleneck. My MSFS is installed in a HD so that could also be a bottleneck, maybe. I will try installing it on an SSD to see if something changes.

Thank you very much.

[felipebutcher]

I just tried with version 0.15 you just released. Also moved MSFS to an SSD. And guess what?

check it out: https://www.youtube.com/watch?v=KXwpdupUpf8

I can finally make wing view videos of my flights. Hope you get rich asap. Thank you!

[till213]

That looks much better - altough I can confirm that it must have been your SSD that resolved the "bottleneck" here: the replay code in Sky Dolly v0.15 is absolutely identical to the previous version ("no new features" release - simply an upgrade and adaption to Qt 6) ;)

However I keep this issue open for further replay improvements that I intend to do, among them the "downsampling" of position data to 1 Hz. Because I think when you sample at the "simulation rate" (as notified by MSFS via "events") you also record each and every "micro-stutter" - and I hope that by merely sampling at 1 Hz (only the position data though - the rest remains at the original sample rate) I will "smoothen out" those "microstutters".

Plus I will switch from Hermite to Catmull Rom spline interpolation: both splines results in a "visually smooth curve", however Catmull Rom splines have some nicer properties (if I remember correcty - I have to read up on all this again ;)) regarding "the distance of interpolated points". And if that doesn't help I will build up "distance tables" such that each interpolated point between the start and end point of a given spline segment will have uniform distance - yeah, I know, it's all this math stuff... ;)

And finally I have yet another topic in mind, at least for the AI aircraft: this should result in smooth replay specifically for AI aircraft. But one step after another. And of course I need to try this out to see whether any of this makes an actual difference for the replay ;)

According to your other YouTube videos it seems that you are living in Brazil - nice :) I have been to Jericoacoara a couple of years ago for real. Gorgeous place! And to quite some other locations in Brazil: Rio, Belo Horizonte, Foz do Iguaçu, Lençóis... to name a few ;)

[felipebutcher]

@till213 very nice man! Glad to know you came to Brazil. I am from Belo Horizonte but living in another city right now. To be honest I love Brazil haha. Very nice places you went.

Hey btw I just recorded a full flight with SkyDolly, it worked great. The landing was a bit hard but this runway is short and you can't float too much.

https://www.youtube.com/watch?v=pVIRw6v04lY

[pelelaur]

Don't know how it comes but i always have stutters on touchdown. With fenix A320 and pmdg. More with PMDG but could it be that with fenix it records less variables and therefor stutters less? In fenix it does not record speed brakes or thrust reversers. In pmdg it does. Looks like every recording program causes these stutters on landing. It use 7800X3d cpu and 4070Ti. Game runs on ssd 980pro. The guy who finds a solution for this gets my immortal gratitude. Are there any updates to be expected from sky dolly?

[till213]

Don't know how it comes but i always have stutters on touchdown.

I don't have any real explanation for this: Sky Dolly does not send more or less simulation variables (except the "expected ones" like "set flaps", "lower gear" etc.) back to the flight simulator during approach (or take off - or any phase during the flight for that matter). It sends back exactly the same "simulation variables" that it had recorded before.

However I could imagine that MSFS goes into a more "precise simulation mode" (or at least the aircraft in question do) once "they approach the ground" - which takes additional CPU and the handling of "simulation variables" (via SimConnect) could perhaps be "de-prioritised" during this more "calculation intensive phase" (that perhaps also takes "ground effects", "wind shear" etc. into account).

With fenix A320 and pmdg. More with PMDG but could it be that with fenix it records less variables and therefor stutters less?

Sky Dolly records and sends back the exact same set of "simulation variables" for each aircraft. There are no aircraft-specific simulation variables. In fact, you see all simulation variables in the dialog of the same name in Sky Dolly (press key V).

In fenix it does not record speed brakes or thrust reversers.

I tried to improve the animation (control) of spoilers, flaps and speed brakes with a previous version of Sky Dolly already, by sending "events" instead of simulation variables for those specific control elements (and there is a bug fix related to those events in the latest v0.17, specifically when one seeks on the Sky Dolly timeline back and forth).

The problem with the Fenix A320 is: I don't even get proper readings for the corresponding simulation variables when recording. And it got worse with newer versions of the Fenix A320 (the older v1.2 version did report some reasonable values for flaps at least - speed brakes: always unusable values, the maximum speed brake value that was reported was around 30% when fully extended).

In pmdg it does.

Because the PDMG reports proper values at least ;) Note that both aircraft do have their custom simulation logic (the A320 even in a separate *.exe process), so it is "hit and miss" with the "simulation variables" sometimes.

Looks like every recording program causes these stutters on landing.

Again, I suspect more that those aircraft go into a more "calculation intensive phase" when approaching the ground (below some given altitude above ground threshold perhaps) that takes e.g. additional physical effects more precisely into account, such as wind shears perhaps. And this could - theoretically - de-prioritise other tasks such as processing external "SimConnect events". But this is only an educated guess...

Are there any updates to be expected from sky dolly?

The latest v0.17 was just released a couple of days ago (a week+ perhaps). Also refer to:

https://github.com/till213/SkyDolly/blob/main/CHANGELOG.md

;)

And yes, there was some pause in between: "Life happened"...