Slight difference between front end pace vs .fit file pace? #1838
Replies: 37 comments 67 replies
-
yes it could be a km/miles conversion issue. QZ is doing all the math in meters under the hood. Anyway a debug log with a fit file will be perfect to analyze this |
Beta Was this translation helpful? Give feedback.
-
|
I've just taken a deeper dive into the fit file and the speed in m/s calculates correctly, but the distance covered implies a different pace (i.e. the pace that the websites report). So it looks like it is the distance calculation that is somehow wrong in the conversion. Attached is a spreadsheet showing the calc for the final lap of a .fit file extracted using fitfileviewer (zip uploaded) |
Beta Was this translation helpful? Give feedback.
-
|
Yep, will do that - just thought that that .fit file extract was interesting as it presents both the actual pace being displayed by the app (i.e. the data recorded as speed) as well as the information that causes pace on websites to be out of step (i.e. distance and time). I'm going to dig through some other output files and see if the difference appears to be consistent between the speed field and the distance / time field calculations, but I will send a full debug file over and attach here when I next use the TM (tonight I hope). |
Beta Was this translation helpful? Give feedback.
-
|
yes but i would like to understand if there is some mis calculation for your specific trainer, thanks |
Beta Was this translation helpful? Give feedback.
-
|
No worries - my spreadsheet playing seems to indicate that there's a consistent gap of about 0.6% which looks / feels like a difference between using 1600m for a mile and 1609.34m for a mile (as a guess), but as you say that could be coming from the device rather than your conversions in the app itself; I'm not in a good place to understand how the app works! |
Beta Was this translation helpful? Give feedback.
-
|
with a debug log and the fit file will be clearer |
Beta Was this translation helpful? Give feedback.
-
|
Switched on logging, but not sure where to access the log file from? Might it be hidden under Android 14? |
Beta Was this translation helpful? Give feedback.
-
|
as i said for debug log on android 14 you need the beta. 2.16.24 logs on
/documents/qz
Il giorno mer 29 nov 2023 alle 22:15 yellowbarchetta <
***@***.***> ha scritto:
… Switched on logging, but not sure where to access the log file from? Might
it be hidden under Android 14?
As an aside, the gap between displayed pace and actual distance / pace was
much bigger tonight. 8:19 per mile on the app display, 8m49 time to cover a
mile. That suggests its likely a treadmill issue I guess; wonder if it
struggled tonight in the garage where the temps were close to freezing.
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWC7ULN6WIZSWEY5K53YG6QXJAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMJQGI3DO>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Lol, found it. Hate the Google files app. looks like the debug didn't write when I ran earlier so I'll sort tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
ok thanks!
Il giorno mer 29 nov 2023 alle 23:24 yellowbarchetta <
***@***.***> ha scritto:
… Lol, found it. Hate the Google files app.
looks like the debug didn't write when I ran earlier so I'll sort tomorrow.
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWBLIETJT3PNXS526ATYG6Y2NAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMJRGAYTI>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
OK, here's some data. Admittedly this is coming from the "fake treadmill" but I think it represents the same issue when I've post-reviewed the .fit file both as a data table and when it gets uploaded to processing services. The "fake" treadmill speed was set to 8m16 per mile, and in the file itself the "speed" reading in m/s is absolutely consistent at 3.239. That calculates out at 8m16.86s per mile, so pretty much in line with the "displayed" speed on the QZ app. But the distance entries in the fit file are inconsistent. They are mostly around 3.2m difference between each spot, but for the most part they vary between about 3.17m to 3.25m. I'm not surprised that there are differences there, as presumably the precision of the logging of a distance record isn't exactly ever 1s, even though the entries are stamped with 1s precision. However, some of the distance entries are quite a lot bigger than this (ranging from 0m to nearly 55m) which wouldn't be explained by timing precision. Every second does have a record, so there are no time gaps bigger than 1s. Even ignoring the "big" gaps though, the distance increments at a pace which is slower than the treadmill pace, and that doesn't seem right to me. Presumably the "pace" and the "distance" are coming from slightly different sources, or being processed in different ways? The implied pace by distance / time is about 8m20/21 per mile vs the "set" speed of 8m16 per mile. I'll do the same exercise from the treadmill itself tonight, but in the meanwhile here is the debug log and the .fit file for that session. I'm pretty sure you can see the same discrepancy between distance/time and pace in the raw log file, having dropped the log into excel and played around a little. Hope it intrigues! It looks to me as if the app receives both a distance and a pace from the device and doesn't try to ensure that they are consistent. But I might be wrong!! |
Beta Was this translation helpful? Give feedback.
-
i didn't have a chance to check the log yet but for your information, qz is calculating the distance from the speed received from the treadmill, so pace, speed and distance are on the same information. Could you please quick me point to one big gap in the file? (i don't have a lot of time in these days, so i'm trying to collect all the info that you have already analyzed) |
Beta Was this translation helpful? Give feedback.
-
|
1701334249181 |
Beta Was this translation helpful? Give feedback.
-
|
thanks, i'm checking it |
Beta Was this translation helpful? Give feedback.
-
|
I've also tried to use the time stamps with the thousandths of a second to understand the speed / distance thing, but that doesn't seem to work either. Better minds than mine will solve this!! It's odd that the variance is always in the same direction, so I don't know whether that implies that it is a rounding issue or not. But as you say, if the distance is calculated from the speed, and the speed is 100% consistently reported (as you'd expect from a treadmill's data) then you'd expect time x speed = distance. Don't worry about "fixing" this, it's a long way from being urgent, but it was just something as a data nerd that I spotted! |
Beta Was this translation helpful? Give feedback.
-
here there is a jump, was qz always on foreground? |
Beta Was this translation helpful? Give feedback.
-
|
I'm going to say "probably" always in foreground. Couldn't 100% say so, and screensaver might have kicked in, I left my phone on the desk. |
Beta Was this translation helpful? Give feedback.
-
|
screensaver shouldn't affect qz because is forcing always on, isn't working
this for you?
Il giorno gio 30 nov 2023 alle 12:25 yellowbarchetta <
***@***.***> ha scritto:
… I'm going to say "probably" always in foreground. Couldn't 100% say so,
and screensaver might have kicked in, I left my phone on the desk.
Those big gaps might be a red herring then.
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWBA7I4HDQL6KKN7WK3YHBUJZAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMJWGY2DE>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, it does work fine normally to stay unlocked. I don't think the phone locked when recording, but I can't be certain. |
Beta Was this translation helpful? Give feedback.
-
|
i would like to check if you see these gap also tonight. if so there is
something that it's not working with the timer, maybe that's about some
power saving scenario of the phone
Il giorno gio 30 nov 2023 alle 12:28 yellowbarchetta <
***@***.***> ha scritto:
… Yes, it does work fine normally to stay unlocked. I don't think the phone
locked when recording, but I can't be certain.
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWB756TJI4UFMXQR57TYHBUXRAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMJWGY3TQ>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
it's because i'm applying an offset to the fit file. that's normal. Let's see how it will go tonight, by the way I really appreciated what you're doing here, i never have time to double check all the tiny things! |
Beta Was this translation helpful? Give feedback.
-
|
LOL, no worries - I was worried I was being a pain in the backside!! That offset gap looks quite large though? There is a resulting discrepancy between the fit file and the start / end time of the treadmill though - the debug file has the first movement of the treadmill time stamped as 8:31:01/02 which matches the .fit file but the fit files end at 8:54:55 or thereabouts, and the debug log receives last info at 08:57:36. That makes me wonder if the .fit file writes every second with the time simply being incremented by 1s each time, ignoring any gaps in the data perhaps? The time gaps (i.e. any debug record where the gap between the times is > 1 second) come to about 2m37, which is pretty close to being the gap between the total time recorded by the .fit file vs the total time treadmill was running. Coincidence? |
Beta Was this translation helpful? Give feedback.
-
|
i'm quite sure that the problem is here Line 317 in a3a2bca or saying it better, the issue are the hole in the debug log that are reflecting into this line. we have to understand these holes first. |
Beta Was this translation helpful? Give feedback.
-
|
check also the comment above that line that I wrote in the past :) |
Beta Was this translation helpful? Give feedback.
-
|
Yep, that looks like an issue if the app isn't getting a new update every second. Which may well be what I'm seeing if my TM doesn't send a record reliably every second. Still think there's another issue "somewhere" if the calculation of distance on a second by second basis still doesn't precisely equal speed x time (I'd expect distance to be absolutely the same for every second if the speed is the same too). But that might disappear with tweaks to the way the fit file is written. |
Beta Was this translation helpful? Give feedback.
-
|
yeah but it can't be that the case of the fake treadmill profile. there
it's for sure every seconds. so there is a major issue, i hope, only on
your system somehow
Il giorno gio 30 nov 2023 alle 13:26 yellowbarchetta <
***@***.***> ha scritto:
… Yep, that looks like an issue if the app isn't getting a new update every
second. Which may well be what I'm seeing if my TM doesn't send a record
reliably every second. Still think there's another issue "somewhere" if the
calculation of distance on a second by second basis still doesn't precisely
equal speed x time (I'd expect distance to be absolutely the same for every
second if the speed is the same too). But that might disappear with tweaks
to the way the fit file is written.
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWGXLHMTX5N3WSP35QLYHB3QTAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMJXGI2DO>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
I suppose though this is the question to ask - if you run a "fake treadmill" on your phone or on windows, does the distance for every "second" come out exactly the same, or does it vary by small and / or large amounts? Because if the app is getting speed from the treadmill only, then the same distance should be calculated for every second that is recorded. It's the variability of that "distance" which is creating the possibility of displayed speed not equalling .fit file speed (because the .fit file is processed in a way which takes the distance as being correct, and the time as correct, and then back calculates the speed). |
Beta Was this translation helpful? Give feedback.
-
|
I'm not great at code, but if this is the source of the distance figures, then is there something in here which is creating the lack of precision, perhaps by using milliseconds? I've just snipped out one example of where it looks (to my untrained eye!) that a calculation is being made. ` |
Beta Was this translation helpful? Give feedback.
-
|
If that didn't compute in milliseconds, but instead was whole seconds, so secsTo used instead of msecsTo perhaps that would address what I'm seeing; though obviously I don't know if there are knock on effects across other parts of the app! |
Beta Was this translation helpful? Give feedback.
-
|
it has msec, i don't understand what you're saying. the precision of that one is a double in milliseconds. tested and i'm sure about this |
Beta Was this translation helpful? Give feedback.
-
|
What I mean is that if you compute the difference between 09:00:00.123 and 09:00:01.456 you'll get 1333msec difference. If you then use that in the formula to compute distance you'll calculate (say) 5m/s x 1333msec = 6.665m travelled. But if the .fit file record only rounds to whole seconds you'd have speed = 5m/s, time = 1s, but distance = 6.665m. Then if you process that fit file you'd actually compute a distance of 6.665m over 1s = 6.665m/s. |
Beta Was this translation helpful? Give feedback.
-
|
we can also try the same on windows for example
Il giorno gio 30 nov 2023 alle 13:28 cagnulein ***@***.***> ha
scritto:
… yeah but it can't be that the case of the fake treadmill profile. there
it's for sure every seconds. so there is a major issue, i hope, only on
your system somehow
Il giorno gio 30 nov 2023 alle 13:26 yellowbarchetta <
***@***.***> ha scritto:
> Yep, that looks like an issue if the app isn't getting a new update every
> second. Which may well be what I'm seeing if my TM doesn't send a record
> reliably every second. Still think there's another issue "somewhere" if the
> calculation of distance on a second by second basis still doesn't precisely
> equal speed x time (I'd expect distance to be absolutely the same for every
> second if the speed is the same too). But that might disappear with tweaks
> to the way the fit file is written.
>
> —
> Reply to this email directly, view it on GitHub
> <#1838 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAALYWGXLHMTX5N3WSP35QLYHB3QTAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMJXGI2DO>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***
> com>
>
|
Beta Was this translation helpful? Give feedback.
-
|
yes exactly, if on windows we don't see the holes and the fit file is
better, means that the holes on your phone are the responsible for this
Il giorno gio 30 nov 2023 alle 18:13 yellowbarchetta <
***@***.***> ha scritto:
… I suppose though this is the question to ask - if you run a "fake
treadmill" on your phone or on windows, does the distance for every
"second" come out exactly the same, or does it vary by small and / or large
amounts? Because if the app is getting speed from the treadmill only, then
the same distance should be calculated for every second that is recorded.
It's the variability of that "distance" which is creating the possibility
of displayed speed not equalling .fit file speed (because the .fit file is
processed in a way which takes the distance as being correct, and the time
as correct, and then back calculates the speed).
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWDEFTFIGNVQXVACGDTYHC5DTAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMRQGQ3DM>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
nope that's fine for sure, i already double check it. i'm 99% sure that the
issue are your holes. or at least they are the biggest issues
Il giorno gio 30 nov 2023 alle 18:20 yellowbarchetta <
***@***.***> ha scritto:
… I'm not great at code, but if this is the source of the distance figures,
then is there something in here which is creating the lack of precision,
perhaps by using milliseconds?
`
Distance += ((Speed.value() / 3600000.0) * -- 108 |
((double)lastRefreshCharacteristicChanged.msecsTo(QDateTime::currentDateTime())));
I've just snipped out one example of where it looks (to my untrained eye!)
that a calculation is being made. `
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWGDJ6GQZ4NFYEM6O2LYHC57FAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMRQGUZTI>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
but they are 2 different process: the distance is calculated with the
greatest precision and then every seconds it's written on the fit file. the
total distance would be ok. the counter side is that you are seeing a
distance "floating" during the workout in the fit file, but it's useless
since it's the speed that it's processed for pace and of course speed on
strava for example .
aren't you agree?
Il giorno gio 30 nov 2023 alle 19:45 yellowbarchetta <
***@***.***> ha scritto:
… What I mean is that if you compute the difference between 09:00:00.123 and
09:00:01.456 you'll get 1333msec difference. If you then use that in the
formula to compute distance you'll calculate (say) 5m/s x 1333msec = 6.665m
travelled. But if the .fit file record only rounds to whole seconds you'd
have speed = 5m/s, time = 1s, but distance = 6.665m. Then if you process
that fit file you'd actually compute a distance of 6.665m over 1s =
6.665m/s.
If the original calculation was whole seconds only you'd have speed =
5m/s, time = 1s, distance = 5m. Which would then process correctly.
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWC62BJ5K65O4DY2EVDYHDH3BAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMRRGI3DI>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
if you want i can also do a pr restoring the timestamp in the fit file if you wanna try it |
Beta Was this translation helpful? Give feedback.
-
|
No, I don't think that is correct - fundamentally the distance between each second (measured in metres) should be identical for every single second where the pace is identical. It shouldn't change, because distance = speed x time. Time is always 1s, speed is always (say) 8m19s per mile so distance in the fit file should be 100% identical for every second where the pace is the same. But it's not because the distance is being calculated by gaps which are not equal to seconds. You might be right overall if your calculation for distance each time is cumulative - then I'd agree that any "noisy" data points would average out to nil over a prolonged duration. But all I can see in the log is that the distance between each step changes every second, which (in my head at least!) doesn't feel right. I've just dug out a zwift-recorded .fit file and it presents the same situation with distance between each point being greater or lesser than you'd expect if speed is fixed, but in that case there doesn't seem to be an accumulation of the error which results in a different pace outcome. Definitely odd!! |
Beta Was this translation helpful? Give feedback.
-
|
I'm doing another run in a few minutes. Will unpack that later against a debug file! |
Beta Was this translation helpful? Give feedback.
-
|
yes but you can't mathematically have a distance calculated every seconds with the precision of millisecond in a mobile environment :) that's why i'm doing in this way the only thing that we can do is writing the real timestamp in the fit file instead of the +1 so holes will be covered (but then i need to fix pause event for strava) ok let me know, im going to bed soon :) |
Beta Was this translation helpful? Give feedback.
-
|
Wouldn't this work? Enjoy your sleep!! I don't think apps would read the millisecs in the timestamps in the fit file? Though I might be wrong about that, but I think they expect whole seconds only. |
Beta Was this translation helpful? Give feedback.
-
|
nope in that way you have a rounding, it will not work for sure. you can
try on excel :)
nope app doesn't read milliseconds, but if there is holes, it will also
write holes in the timestamp of the fit file
Il giorno gio 30 nov 2023 alle 20:46 yellowbarchetta <
***@***.***> ha scritto:
… Wouldn't this work?
Distance += ((Speed.value() / **3600.0**) *
((double)lastRefreshCharacteristicChanged.**secsTo**(QDateTime::currentDateTime())));
Enjoy your sleep!!
I don't think apps would read the millisecs in the timestamps in the fit
file? Though I might be wrong about that, but I think they expect whole
seconds only.
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWHAVQGAN5FCJR7LB3DYHDPCHAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMRRG42DE>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks. Point to point is interesting, because that's what I'm seeing as the fundamental issue; the sum of the individual distances doesn't match the expected distance based on the time elapsed for the whole activity and the speed in between. I understand what you are saying about the variability of speed, especially if on a bike where the user is in control of the speed rather than the device itself. But I still don't think it makes any difference. The "speed" is a snapshot of speed at the time, presumably at the millisecond that it is recorded, even for a cyclist. But during that second (!) the cyclist could have varied the speed significantly. For a stupid example imagine a cyclist riding at 10,000m/s for 0.000 to 0.250, then 1,000m/s for 0.250 to 0.750 then 10m/s for 0.750 to 1.000, the speed that your app would see would depend on whether the measurement was taken at 0.000-0.250, 0.250-0.750, 0.750-1.000 and that would influence the distance calculation. If it was taken in the first part of the second, the distance calculated would be 10,000m, if it was taken in the last part of the second it would record only 10m travelled. If then the next 100s were all travelled at 10m/s then you could have total distances of either 1010m or 11,000m recorded (If my maths is correct!). Of course, in the real world the variability would be far less so you're really choosing between a speed of 11.23456kmh or 11.23123kmh in that individual second, and therefore the per second distance difference is relatively small. The ultimate calculation if seconds are used as integers rather that milliseconds doesn't really change that. But it does mean that if there are small errors / discrepancies in the calculation (as I think the snipped code and calulation above shows) when done to the msec level, they disappear if the sample period is scaled up to whole seconds, without losing any significant level of precision. But I think for a treadmill, it's that accumulation of small differences which is creating the issue. Like I say, my simplistic issue is that if I look at the total time of the activity and "know" that the speed is constant (because it is a treadmill) then I can definitely show that the calculated distance does not equal the sum of the individual distance calculations by something which is more than just roundings. In your example the log says 0.0261347 distance but your calc says 0.0293888. Not sure where "calculated 0.0026897" comes from, but that's a third number! |
Beta Was this translation helpful? Give feedback.
-
|
Will give the release a try tonight! |
Beta Was this translation helpful? Give feedback.
-
|
Got your point. I'm still thinking that the current implementation should work anyway and I'm quite sure that we will see an improvement now that i cached the timestamp.
these are the delta from the 2 distance in the log that I picked. Anyway let's check tonight. On my domyos treadmill, when i'm doing a 10 km/h session, at a 60:00 mark i'm getting 10km on the odometer so i'm more than sure that the current implementation is right if there is no software bugs like the one that i fixed now for your treadmill, but i'm more than happy to double check them! Also I checked with chatgpt if there are holes in the log, and no, there are not. I love chatgpt for this kind of stuff :) https://chat.openai.com/share/eaf74d6f-7be3-41ac-b392-51669dd71dfa |
Beta Was this translation helpful? Give feedback.
-
|
Wow, love the chatgpt use :-) |
Beta Was this translation helpful? Give feedback.
-
|
Do you subscribe to ChatGPT to allow file uploads? |
Beta Was this translation helpful? Give feedback.
-
|
yes i'm using every day for file analysis
Il giorno ven 1 dic 2023 alle 12:58 yellowbarchetta <
***@***.***> ha scritto:
… Do you subscribe to ChatGPT to allow file uploads?
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWFR5MXK2HPMLVVL6Z3YHHA5RAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMRYG4YTK>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Agreed, that first entry should be zero distance. But later in the file
zero distance shouldn't occur if there is a speed registered. Obviously if
speed is zero then distance should be zero too later in the file
…On Sun, 3 Dec 2023, 17:17 Roberto Viola, ***@***.***> wrote:
Upload.from.GitHub.for.iOS.png (view on web)
<https://github.com/cagnulein/qdomyos-zwift/assets/48216/e2e06afd-b134-4330-906e-e854684f432d>
It's the first record with the instant speed and instant power. It looks
correct to me, why we should remove this entry?
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOAEASKRLI3VBEUFZC5TKL3YHSX2PAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONBUHA4DC>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
I scrolled the whole fit file with fit file viewer but I can’t see any
distance = 0 line apart the first one. Am I missing something?
Il giorno dom 3 dic 2023 alle 18:22 yellowbarchetta <
***@***.***> ha scritto:
… Agreed, that first entry should be zero distance. But later in the file
zero distance shouldn't occur if there is a speed registered. Obviously if
speed is zero then distance should be zero too later in the file
On Sun, 3 Dec 2023, 17:17 Roberto Viola, ***@***.***> wrote:
> Upload.from.GitHub.for.iOS.png (view on web)
> <
https://github.com/cagnulein/qdomyos-zwift/assets/48216/e2e06afd-b134-4330-906e-e854684f432d>
>
> It's the first record with the instant speed and instant power. It looks
> correct to me, why we should remove this entry?
>
> —
> Reply to this email directly, view it on GitHub
> <
#1838 (reply in thread)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AOAEASKRLI3VBEUFZC5TKL3YHSX2PAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONBUHA4DC>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***
> com>
>
—
Reply to this email directly, view it on GitHub
<#1838 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWEBMVNJJXB47IBNEMLYHSYOXAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONBUHEYTQ>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Hmm, let me check if I sent the right .fit file!! |
Beta Was this translation helpful? Give feedback.
-
|
Yes, though maybe I've not communicated well! It's where the distance doesn't increase between two time stamps e.g. this one early on - distance at 22.85m for both seconds, despite there being time elapsed and a speed recorded. Garmin processes the speed graph by reading the "speed" entries, but Strava processes the speed graph by plotting the distance / time pace, so it has little spikes when the distance doesn't increment, or when it "catches up" on the next second. 
|
Beta Was this translation helpful? Give feedback.
-
|
Hah ok, yes I didn’t understand it. I will check the log tomorrow
Thanks
Il giorno dom 3 dic 2023 alle 21:05 yellowbarchetta <
***@***.***> ha scritto:
… Yes, though maybe I've not communicated well! It's where the distance
doesn't increase between two time stamps e.g. this one early on - distance
at 22.85m for both seconds, despite there being time elapsed and a speed
recorded. Garmin processes the speed graph by reading the "speed" entries,
but Strava processes the speed graph by plotting the distance / time pace,
so it has little spikes when the distance doesn't increment, or when it
"catches up" on the next second.
image.png (view on web)
<https://github.com/cagnulein/qdomyos-zwift/assets/58736713/ae4fa8cb-4779-49a5-af16-7b02d70cda5f>
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWFAROE4YBHMGCHOAYLYHTLQFAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONBWGA2TI>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
it happens because your treadmill sends the metrics every 1s so sometimes, the thread is anticipating the treadmill and so it has the previous calculated distance. |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense. Will see if I can try tonight. |
Beta Was this translation helpful? Give feedback.
-
|
Tried this tonight. No zero distance in a second, but still a lot more variability than makes sense to me when the fit file only deals with whole seconds. THat said, it doesn't make a difference in practical terms other than making the graph a bit less neat. As an aside, this version (and the same in this branch) doesn't seem to email the .fit files to me? Not a big deal as I know the main release works, but just thought I'd flag it. Here's Garmin's graph |
Beta Was this translation helpful? Give feedback.
-
|
yes this version doesn't have the smtp account, i will add it, thanks.
i had an idea to implement the 1sec odometer easily (i hope). i will think
about it, thanks
Il giorno mar 5 dic 2023 alle 23:03 yellowbarchetta <
***@***.***> ha scritto:
… Tried this tonight. No zero distance in a second, but still a lot more
variability than makes sense to me when the fit file only deals with whole
seconds. THat said, it doesn't make a difference in practical terms other
than making the graph a bit less neat.
As an aside, this version (and the same in this branch) doesn't seem to
email the .fit files to me? Not a big deal as I know the main release
works, but just thought I'd flag it.
Here's Garmin's graph
image.png (view on web)
<https://github.com/cagnulein/qdomyos-zwift/assets/58736713/688eacaa-fbbe-4f6c-8b18-20747dc5a9b0>
Here's Strava's graph
image.png (view on web)
<https://github.com/cagnulein/qdomyos-zwift/assets/58736713/15f6c9a0-cf43-4a0b-88c9-1db41e202a95>
Activity is this one
https://www.strava.com/activities/10334488370/overview
Tue Dec 5 21_26_09 2023.zip
<https://github.com/cagnulein/qdomyos-zwift/files/13573404/Tue.Dec.5.21_26_09.2023.zip>
debug-Tue_Dec_5_20_27_05_2023.zip
<https://github.com/cagnulein/qdomyos-zwift/files/13573428/debug-Tue_Dec_5_20_27_05_2023.zip>
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWABGIIU6GRJWJ4DFKDYH6K43AVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONRZGQYTG>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
@yellowbarchetta i created this https://github.com/cagnulein/qdomyos-zwift/actions/runs/7111680704 following your idea to write at 1s. So what I did in the detail: i still have the classic odometer variable calculated everytime that I received an event from the fitness device, but I have also a distance1s variable, that increments every seconds using the actual speed. It should works. Let me know! |
Beta Was this translation helpful? Give feedback.
-
|
about the email, i checked the code and it should be right, maybe it was only a glitch. could you please try again? |
Beta Was this translation helpful? Give feedback.
-
|
It happened on every side-loaded version that I've tried, so I don't think it was a one-off. The only thing that I'd changed was I amended the email address to match the one you've whitelisted. Previously I had a spam trap in there ([email protected]) and that always worked to email me the .fit file. Now I've amended to [email protected] (and used the side loaded versions) it's failing. Would I be able to see something in a debug file? |
Beta Was this translation helpful? Give feedback.
-
|
yes i saw a smtp error. i will check on my side then.
did you see also the new build with the fit file at 1s?
Il giorno mer 6 dic 2023 alle 13:14 yellowbarchetta <
***@***.***> ha scritto:
… It happened on every side-loaded version that I've tried, so I don't think
it was a one-off. The only thing that I'd changed was I amended the email
address to match the one you've whitelisted. Previously I had a spam trap
in there ***@***.***) and that always worked to email me
the .fit file. Now I've amended to ***@***.*** (and used the
side loaded versions) it's failing.
Would I be able to see something in a debug file?
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWEWXQEWDSSEGCU27WLYIBOTPAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONZVGYZTC>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
no rush :) just curious :) |
Beta Was this translation helpful? Give feedback.
-
|
Tried it with the fake TM, worked fine as every distance between timestamp was the same (+/- 1cm I think, down to roundings). Will try with a real one tomorrow I think. As an aside, I've now created a "Tasker" (android automation) routine which monitors for QZ exiting, and then triggers copies of the .fit and debug files to my Google Drive, and deletes all of the others. All of those png files are very messy!! |
Beta Was this translation helpful? Give feedback.
-
|
I'm adding an option to auto remove these pictures on android 14. |
Beta Was this translation helpful? Give feedback.
-
|
Latest activity tonight, nice smooth graph as I'd expect to see. https://www.strava.com/activities/10344925316 There is a separate minor issue with the laps though - for some reason the distance of the final "lap" isn't calculating correctly. I think I spotted that on another activity too, but wasn't sure. In terms of this activity, I left the auto laps on for mile 1-4, then hit a couple of manual laps, then let the autolaps work out, then one manual lap before hitting stop at the end. The final lap should measure about 0.7m, but is reported as 0.22. You can see it is wrong as the total distance (8m) doesn't compute with the sum of the individual lap distances, and it's only the final one which is "wrong". |
Beta Was this translation helpful? Give feedback.
-
|
that's great! actually the sum is fine in kms on strava
am i missing something? |
Beta Was this translation helpful? Give feedback.
-
|
Ah, no it's not that view of the laps - that's just one that Strava does
with it's defaults.
It's the "laps" view that can be seen on the website view (or in Garmin
Connect). I'll grab some screenshots.
…On Thu, 7 Dec 2023 at 21:48, Roberto Viola ***@***.***> wrote:
that's great!
actually the sum is fine in kms on strava
7CF93B2C-A1FD-4191-88AD-4B428957836A.png (view on web)
<https://github.com/cagnulein/qdomyos-zwift/assets/48216/525e0fb3-11f8-4a7e-8bee-c77a8e3141df>
A6836759-FCEF-4D35-8FE2-01F5C2C8ED56.png (view on web)
<https://github.com/cagnulein/qdomyos-zwift/assets/48216/ee636a7a-43a0-480b-8ae4-5d2e4753cc59>
am i missing something?
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOAEASIZVTQB4TL3XTLT2X3YII2UBAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOOJUGA4TK>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Just adding to this, the final "lap" looks to be a different "type" of lap being written and this is where the error in the data is. It's taken the distance from the previous lap but the correct elapsed time (359.83m instead of something closer to 1142m in distance, but 364s (6m03) as the time). |
Beta Was this translation helpful? Give feedback.
-
|
you are right! there is one missing line! fixed, it's building ;) thanks as always |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/cagnulein/qdomyos-zwift/actions/runs/7140497488 |
Beta Was this translation helpful? Give feedback.
-
|
No treadmill for me for a couple of days I think, but easy enough to test on a fake treadmill. Will d/l and check it out when it's built. |
Beta Was this translation helpful? Give feedback.
-
|
(Deleted) |
Beta Was this translation helpful? Give feedback.
-
|
strange, i didn't change any settings. let me check it
Il giorno ven 8 dic 2023 alle 16:24 yellowbarchetta <
***@***.***> ha scritto:
… This version has the issue where the settings menu can't be accessed :-(
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWBSHHFYRNVTC33JQ5LYIMWMDAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBQHE2TC>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
It might have been me getting confused with the version I installed; so I
would ignore it for now!!
…On Fri, 8 Dec 2023 at 15:51, Roberto Viola ***@***.***> wrote:
strange, i didn't change any settings. let me check it
Il giorno ven 8 dic 2023 alle 16:24 yellowbarchetta <
***@***.***> ha scritto:
> This version has the issue where the settings menu can't be accessed :-(
>
> —
> Reply to this email directly, view it on GitHub
> <
#1838 (reply in thread)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAALYWBSHHFYRNVTC33JQ5LYIMWMDAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBQHE2TC>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***
> com>
>
—
Reply to this email directly, view it on GitHub
<#1838 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOAEASJPJM7YUOWQI5ADMKTYIMZQJAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBRGIYDQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Just tried this https://github.com/cagnulein/qdomyos-zwift/suites/18873058415/artifacts/1101551631 and it worked fine for the settings page . So let me know when you will try it :) Thanks |
Beta Was this translation helpful? Give feedback.
-
|
Yep, all good, my error.
Tested out the final lap issue using fake treadmill, all seems to work
perfectly now.
…On Fri, 8 Dec 2023, 16:29 Roberto Viola, ***@***.***> wrote:
Just tried this
https://github.com/cagnulein/qdomyos-zwift/suites/18873058415/artifacts/1101551631
and it worked fine for the settings page . So let me know when you will try
it :)
Thanks
—
Reply to this email directly, view it on GitHub
<#1838 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOAEASNR3PYDO3G2Y5WCA53YIM56PAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBRGU2TG>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Awesome, thanks!
Il giorno ven 8 dic 2023 alle 18:28 yellowbarchetta <
***@***.***> ha scritto:
… Yep, all good, my error.
Tested out the final lap issue using fake treadmill, all seems to work
perfectly now.
On Fri, 8 Dec 2023, 16:29 Roberto Viola, ***@***.***> wrote:
> Just tried this
>
https://github.com/cagnulein/qdomyos-zwift/suites/18873058415/artifacts/1101551631
> and it worked fine for the settings page . So let me know when you will
try
> it :)
>
> Thanks
>
> —
> Reply to this email directly, view it on GitHub
> <
#1838 (reply in thread)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AOAEASNR3PYDO3G2Y5WCA53YIM56PAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBRGU2TG>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***
> com>
>
—
Reply to this email directly, view it on GitHub
<#1838 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALYWE3Z7CMGFL66VANCX3YINE3ZAVCNFSM6AAAAAA76BFMMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBSGA4TQ>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
@yellowbarchetta i just fixed a bug introduced by the 1s odometer thing that if you do 2 workouts in a single qz session, the second one will have a negative odometer. |
Beta Was this translation helpful? Give feedback.
-
Will gather some data on this next time I use the treadmill, but I've noticed that the pace that the app reports on the front end is always out by a small amount when the .fit file is decoded and used by websites such as Garmin Connect. Not much, but always slower - e.g. pace on the screen on the app might be 8m19s per mile, but when uploaded the pace reports as 8m24s per mile (just examples).
I've not logged this as a bug as I don't know if I'm just expecting something to be identical when it shouldn't, and I've not tested to see whether the same issue presents if I use metric rather than imperial (sorry, but as a UK user minutes per mile is my default!). I wondered if maybe the conversion to miles was slightly inaccurate though?
Distance doesn't get affected though, and as speed = distance / time it would make most sense to me if it was the visual display of pace that was the issue rather than the data recorded in the .fit file. Anyone else seen something similar?
Beta Was this translation helpful? Give feedback.
All reactions