till213
commented
1 year ago 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
pelelaur
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.