-
-
Notifications
You must be signed in to change notification settings - Fork 123
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
QZ FIT file start timestamp inconsistent with Zwift #1311
Comments
A few more notes. Using https://www.fitfileviewer.com/, the Session and Event tables of QZ FIT file show a start timestamp of 2:14:03pm. That could possibly indicate there is missing data from 2:14:03 - 2:17:01pm in the QZ file. |
seems a bug in the garmin fit library. Question: if I create a windows version with the patch, can you help me doing a test and verify that it's all good? |
@victorypoint when it's ready you will see a new windows version here https://github.com/cagnulein/qdomyos-zwift/actions/runs/4267692357 (bottom of the page) it will be ready in 30 minutes |
@cagnulein, thank-you! Very excited to test this out. That's interesting about the timestamp bug in the Garmin FIT SDK. I'm curious if you're using the latest 21.105 SDK, Feb. 2, 2023? - https://developer.garmin.com/fit/download/ |
no I updated the last time some months ago. I usually don't use never the
last version due to possible new bugs. When I find something stable I
usually stick with it ;)
Roberto Viola
Software engineer and open source enthusiast
http://robertoviola.cloud
Il giorno sab 25 feb 2023 alle ore 02:56 Al Udell ***@***.***>
ha scritto:
… @cagnulein <https://github.com/cagnulein>, thank-you! Very excited to
test this out. That's interesting about the timestamp bug in the Garmin FIT
SDK. I'm curious if you're using the latest 21.105 SDK, Feb. 2, 2023? -
https://developer.garmin.com/fit/download/
—
Reply to this email directly, view it on GitHub
<#1311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWDNKGNPEJ7BHASC3TLWZFRDFANCNFSM6AAAAAAVHIEN2Y>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Thank-you. I started doing some testing. Go to bed! 😴🛌 |
@cagnulein, using new Windows QZ build v2.12.73, I repeated my test as before using QZ fake treadmill mode::
Here are detailed timestamps per FIT table:
FIT files attached. |
sorry @victorypoint I found now the original issue, it's not fault of the fit library, it's just my fault :( |
@victorypoint in case you missed, new artifact is ready |
@cagnulein, this update is great! I retested as before. Here's the results:
Looking at the FIT tables using https://www.fitfileviewer.com/, I noticed both FIT files have consistent data structure, however the QZ Event table has no stop timestamp record whereas the Zwift table does. Is this important? I will continue to do more testing. |
ok let me know when i can merge this!
Il giorno sab 25 feb 2023 alle 23:41 Al Udell ***@***.***> ha
scritto:
@cagnulein <https://github.com/cagnulein>, this update is great! I
retested as before. Here's the results:
- Launch QZ in paused state - 2:38pm
- Launch Zwift and begin a manual run - 2:42pm - avatar stands still
waiting for speed
- Hit QZ Start button - 2:43pm - avatar stands still waiting for speed
- Hit QZ preset speed button 10kph - 2:45pm - avatar begins to move
- Hit QZ Stop button, end Zwift run, exit both QZ and Zwift - 2:55pm
- Examine Zwift and QZ FIT files:
- Zwift starting timestamp - 2:45:07pm - this appears to be very
close when QZ speed preset button was pressed
- QZ starting timestamp - 2:45:04pm - this also appears to be very
close QZ speed preset button was pressed
Here's the original Zwift FIT file elevation graph overlayed with the
elevation corrected FIT file:
[image: image]
<https://user-images.githubusercontent.com/63697253/221381711-65686043-521e-492f-aecb-06cb22bb6fa4.png>
I will continue to do more testing.
—
Reply to this email directly, view it on GitHub
<#1311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWAR7LSB4PW6S2BOBYLWZKDBNANCNFSM6AAAAAAVHIEN2Y>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Roberto Viola
Software engineer and open source enthusiast
http://robertoviola.cloud
|
@cagnulein, my next test discovered a problem with how QZ calculates elevation gain. I'll post the issue here but let me know if you want a new ticket for this. For this test, I wanted to compare how QZ calculated elevation compares with the terrain elevation for a given course. To get a terrain elevation graph, I used bike mode and mapped the entire 23K Volcano Climb course in a FIT file. Next, I switched to run mode (using the bike pairing meetup trick) and repeated the course using auto-inclination, then merged the QZ elevation into the resulting Zwift FIT file. Here's the 2 graphs overlayed. You can see the Zwift bike elevation in blue and QZ run elevation in green. From what I can tell, the ascent elevations are very close, however QZ appears to be shallowing the decent. Note that I used fake treadmill for this test with 'Zwift inclination gain' = 2. For comparison, here is an elevation graph of Zwift bike elevation overlayed with QZ bike calculated elevation. So, it appears that QZ is treating decent (negative elevation) with a different calculation than ascent (positive elevation). |
yes because zwift send the negative inclination to half :) you have to enable the zwift negative incliantion double setting. There are some youtube videos about this zwift issue too :) |
@cagnulein, I repeated this test using the longer Mega Pretzel course just to confirm it wasn't isolated to a single course. Again I'm finding that QZ is treating decent (negative elevation) with a different calculation than ascent (positive elevation). Here's the 2 graphs overlayed - Zwift bike elevation in blue and QZ run elevation in green. Again, I'm using fake treadmill with 'Zwift inclination gain' = 2. Also, here is the elevation graph of Zwift bike elevation overlayed with QZ bike calculated elevation. |
check my above comment @victorypoint |
Thanks! .. desperately poking around in QZ looking for this setting now... |
Sorry, I can't find this setting. Why exactly is Zwift sending negative inclination to half and positive inclination to full? |
bike options, double negative inclination. zwift does this because, IMHO, the bikes with negative inclination will be uncontrollable (because you will have super high cadence during downhill) |
@cagnulein, found it under Bike options - 'Double Negative Inclination'. So it's a Zwift bug? |
yes confirmed :) |
Ok thanks. Will retest. |
@cagnulein, so with QZ 'Double Negative Inclination' turned on this time, unfortunately I'm getting the same elevation graphs as before. I'm thinking maybe there's another setting that needs to be set in QZ. I'm using fake treadmill with 'Zwift inclination gain' = 2 as before with Wahoo Treadmill device. Logs and FIT files attached. |
oh that's strange, let me check this!
Il giorno mar 28 feb 2023 alle 03:40 Al Udell ***@***.***> ha
scritto:
@cagnulein <https://github.com/cagnulein>, so with Zwift 'Double Negative
Inclination' turned on this time, unfortunately I'm getting the same
elevation graphs as before. I'm thinking maybe there's another setting that
needs to be set in QZ. I'm using fake treadmill with 'Zwift inclination
gain' = 2 as before with Wahoo Treadmill device.
[image: GPXSee 2023-02-27 10_33_45 PM]
<https://user-images.githubusercontent.com/63697253/221738963-b2edf4df-9b6d-4a64-9672-3ae1d652bac4.png>
Logs and FIT files attached.
bike vs run mode.zip
<https://github.com/cagnulein/qdomyos-zwift/files/10846032/bike.vs.run.mode.zip>
—
Reply to this email directly, view it on GitHub
<#1311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWGMA5EGH7774UW7WV3WZVQSZANCNFSM6AAAAAAVHIEN2Y>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Roberto Viola
Software engineer and open source enthusiast
http://robertoviola.cloud
|
@victorypoint i'm an idiot, i'm applying the zwift negative inclination only to the bikes. That's why you're seeing this.
|
Is this what you mean? We will likely need Settings-Treadmill Options-"Pause when App Starts" turned on. First Zwift activity, we press Start button start then Stop button when done. Then reset QZ for next activity by pressing Back and then Pause. Or we leave "Pause when App Starts" turned off. Then we press Pause then Start at beginning of activity.
Yes, it's working well! |
merged!
yeah I mean I was looking to find a way to achieve this without adding any new settings. If I'm right, QZ elapsed timer is not counting if the speed is == 0, if this is true the start trigger is ok for the fit file. For the stop instead it's tricky because there is no automatic way to stop it. But I was thinking: is it really necesseary? I mean since the Zwift activity has an end, we can simple discard all the remaining qz activity from the zwift one (the qz activity will be probably longer than the zwift one, but we can simply cut the remaining off, isn't it?) |
@cagnulein, let me test this idea - single QZ FIT file for multiple Zwift activities and see if FIT merge works. |
@cagnulein, ok I tested this theory and you're a genius! Have I ever mentioned that before? 🤣🤣 Here's what I did to test multiple Zwift activities/single QZ session. A typical scenario is to start on May Field, jump to a run event, then exit to main Zwift screen and perhaps do other runs, workouts, meetups while staying in Zwift with QZ running in the background.
Here are elevation graphs of resulting FIT file merges for each Zwift activity. Blue is Zwift FIT, green is Zwift/QZ/elevation merge FIT. Note that the first graph is the bike ride where Zwift FIT file always has correct terrain elevation. The remaining graphs are runs where Zwift elevation is incorrect (in blue) and need to be corrected with QZ elevation (green): |
so your java skills are still strong! 💪 |
so I guess we can reopen this |
my idea is adding a command line argument to specify the zwift fit file directories. So qz can get the lastest one and opening it each seconds or so? what do you think? |
Incredible idea! This just after I came up with a Windows batch solution using the Java option 😂 - https://github.com/victorypoint/RepairZwiftFIT |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Keep this alive please! |
about this @victorypoint should we proceed with opening the fit file in real time? do you think it's doable? |
@cagnulein, yes, I believe it's doable. The active FIT file is readable in realtime which is what we want to obtain coordinates for each timestamp. |
@victorypoint can you attach a fit file from a workout here? I mean getting it while you're running, so i can check that the file is closed. Also how often this file is updated from zwift? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@cagnulein, so sorry for the delay on this! I've been so busy with the python stuff! 😮. So I just did a workout as follows:
So it looks like my previous theory that the inProgressActivity.fit file updates in real-time is wrong - it appears to update every 10 minutes or so? However, the timestamped FIT file does update in real-time I believe every second and is readable during workouts. |
@victorypoint are you still interested on this? now with the zwift api we can collect gps data! |
the only issue is that for now the windows build doesn't support the zwift api (i have to find the time to add them), but if you want I can add this on the android or ios build |
@cagnulein, yes! Absolutely! I can test on all platforms so good to go 👍 |
ok i will try to do first on ios, i need to convert the X and Y from zwift to gps coordinates, i found that there is a conversion to do for the different worlds |
@victorypoint i thought it could be easy instead i'm struggling to find information about how to translate coordinates from zwift system to the world system. https://github.com/sandermvanvliet/RoadCaptain/blob/d8ec891349212d2a8ef2691925376712680e0bc4/src/RoadCaptain/TrackPoint.cs#L256 seems to be the most update resource but his conversion doesn't match at all. Also I don't understand if this conversion is actually working on RoadCaptain. Do you have some information about this? I have X and Y zwift coordinates in realtime but I can't transform them to real GPS coordinates |
@cagnulein, ok I'll check it out in the next few days. I haven't used roadcaptain yet so need to study it a bit. |
@cagnulein, now that we have a consistent way to synchronize that start of activities between Zwift and QZ (ensure speed is 0 then increase to start FIT file recording at the same time), I'm finding a strange inconsistency with the start timestamp in the QZ FIT file. This is affecting the ability to accurately merge data between the two FIT files (e.g. latitude, longitude, elevation, power, etc).
For example, here's results of a recent test using QZ fake treadmill mode:
I've retested this several times and always arrive at a strange delayed QZ starting timestamp. Any help resolving this is greatly appreciated.
FIT files attached.
test4.zip
The text was updated successfully, but these errors were encountered: