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.
Thanks
Hi, what are you trying to do…msec just gives the results 1 to 999 msec.
So depends on your formula and tag precision…
As tag precision is 0.1
What to u mean broken i dont see any issues
I think that “precision” was the issue. It is not true milliseconds tag, when it updates only 10 times a second.
Hi, its not the tag…it updates every milliseconds as it should, its px / degree precision i was talking about.
You unable to change e.g x from 10 to 10.001
Even if your result is 10.001px
To test the update rate of msec is to use it in a text field.
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.
Ok will test it out myself…first
@Peter , @bruce.bergdahl , @russellcresser
I tested on version 1.5.7b what i see in preview text field. Is weird… it like this
1xx,2xx,3xx (xx is random but in this speed)
Example = xyz
X = 9
Z = + 1
On the watch seem the same.
@r.liechty_SDR its seem
For 3 digit its not 001, 002, 003
But order i cant explain.
E.g from 001, it jumps to 101 up to 901
Then only z changes to e.g 002 , 102, 202…till 902
If z becomes 9 e.g 909 next is
010 instead of 919…
See video
@russellcresser this could cause smoothness issue to
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 .
Hi, so there is a issue with milisecond tags.
Anyway if i did floor([msec]/10) its seem to give 1/10 sec refreshing, so i guess its like @Peter says [msec] even [utc_ts] is accurate for 1/10 sec measurement…
But solving this wont solved the px and rotation precision either.
This is a 2 problem issue solving one only doesnt help
Hopes someone from samsung see this thread @r.liechty_SDR
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.
@bruce.bergdahl . If you use [MSEC] as your timer you will only be able to run something sub one second .
Try this and see if it works for you . It still has the 1/10 second problem .
@bruce.bergdahl i think you see it wrongly.
I did the same test but instead i did ([msec]/100)*(36)
Which = to 1/10 sec interval.
On my watch i do get 10 change in rotation.
Video of [msec]*(360/1000)
You can use a software to slow down the video. Its rotates 10 times not 5 per secs
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.
E.g 10:02:50:01
10:02:50:02
…
10:02:50:11
…
10:02:50:99
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.
@bruce.bergdahl in not millis/10 its milis/100.
If its millis/10 = 1/100 sec (which will produce smoother animation) Anyway just explaining maths here.
But yes there a bug/or processing issues… atleast to me.
But saying that most digital clocks i seen display the milliseconds up to 1/100 sec refresh rate
Like i explain earlier…
Like this clock displaying increments of 1/100 sec
Anyway to make your caculation cleaner, you may use (floor([MSEC]/100)) formula so it will be accurate 1/10 sec values. Instead of 1/10 + random milliseconds.
To all, caculate the milliseconds tag to accurately to 1/10 second values. Its cleaner with
((floor([MSEC]*100))/100)
Thanks @Knightwing for correction. Here’s another wrinkle to this issue: Does this look like a problem to anyone else?
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.
I think i tis because Galaxy Watch6 has a 60Hz refresh rate so it refreshes 60 times a second not an even 100 or 1000
Ron
Samsung Developer Relations