Did the developers address any issues with the [MSEC] tag in the 1.5.7b update? I’m trying to use a sine function using milliseconds and I’m not getting the same results between WFS and a Galaxy 5 watch.
I’ve read about the “broken” [MSEC] tag in previous versions and I’m wondering if the tag has been a problem for anyone else, or if anyone knows if the devs worked out any issues.
That is what I have done and guess what, in preview it was (I am using v1.3.13) updating like 1, 201, 401, 601, 801, 2, 202 and so on. So it updates actually only 5 times a second.
The question is, if it still does it like that with newer version.
Sorry, I wont download it just for this little test.
Hey @Knightwing . Thanks so much for the Video . Very nice . I worked in Special Effects Modelmaking in my career and we did a lot of timed stuff in front of High Speed Film Cameras . In the testing we did in the early days we were accustomed to look at our movies at 30 FPS to get a clue of what was going on . We got into higher frame rates for our testing as the technology changed . The point is I have a Frame counter on my Quick Time Pro an have use it a lot to check timing things I see in your Video that the 0.1 digits are fine . but the 0. 011 digits are completely made up . Even accounting for strobing they are nonsense . The 0.010 digit does not move even at 30 fps . I would expect it to change at least once in 3 frames .
I have moved stuff manually by 0.5PX I have neve found a need for higher res than that so . At least manually that works . I notice the low res on [UTC_TS] For me that is the fall back when outer timers fail … I just wonder how they get the second hand Sweep smooth . Obviously that is reserved .
What I am seeing is the first decimal is counting 1/10 seconds . The second is counting around 2.5 seconds and the third is counting 1/5 sec.
The difference between a sweep second hand and one run with [SEC_MSEC] I can see not rhythm at all . Just random strobing .
I tried the top second hand ( BLUE ) at 10 HZ it looks exactly the same so it is not 10 , 15 HZ or even near . I am jolly glad that we are not making time Pieces . I made a clock thing to take to an exhibition in Basle in the same Hall they do the Watch and Wonders show . I was a bit nervous about the timer being right . Lucky for me I found a reasonably accurate RTC to look after the Clock for the Arduino we used to run the time display on the rig . Admit we were a little towards the Back of the Exhibition but no one Commented that it was out of time . We were near one of the Cafes .
I just tried a simple test using a pointer that rotates based on the [MSEC] tag using this formula in the angle field: [MSEC] * (360/1000)
The result is a very rough rotation, roughly 5 times/sec. It’s not really any different from the previous versions of WFS in my memory.
My goal is to use a sine function to fade and/or scale an image smoothly using milli’s as a base. Oh well, I’ll keep trying, but it seems that the [MSEC] tag itself is unchanged from past versions of WFS.
I know we need to take account for processing speed. From read of time , to displaying the time on output to the tag. But i seen apps clockd on the phone that able to display milliseconds accurate up to 1/100 of a secs or refreshing at 10 milliseconds.
So its possible for the milliseconds tag to give results up to 1/100 sec instead of 1/10 secs
Hi @Knightwing , your equation and mine actually produce the same result, yours is cleaner as it’s reduced… Your video also pretty closely matches my test.
So it looks like the tag is a bit misleading in that it’s not a pure representation of millis, but millis with a 1/10 sec update rate (so millis/10?).
Anyway I was trying to use the millisecond tag in a sin/cos function to show a smooth heartbeat, either going from 0to100 opacity and back down in sync with the heart rate tag, which I have working but because the [MSEC] tag has this precision issue, it’s a somewhat janky result.
Thanks for helping figure this out, hopefully the devs or @r.liechty_SDR will address this.
Thanks @Knightwing for correction. Here’s another wrinkle to this issue: Does this look like a problem to anyone else?
Why is the digit in the 1/10th place updating faster than the 1/100 or 1/1000? I haven’t tested it on an actual device, this is just a clip from WFS, but I’m confident it will match on the wearos hardware.
I’ve been pulling 18-20 hour days since Saturday on a paying project, so if I’m mistaken it wouldn’t surprise me at all, lol.
EDIT: I just ran the code on the hardware, and the only difference is the update speed, but functionally it’s identical to the clip.