# Was the [MS] tag fixed?

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

1 Like

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

1 Like

I think that “precision” was the issue. It is not true milliseconds tag, when it updates only 10 times a second.

1 Like

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.

1 Like

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.

1 Like

Ok will test it out myself…first

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

1 Like

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 .

1 Like

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

1 Like

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 .
.
.
.

1 Like

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.

1 Like

@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.

1 Like

Video of [msec]*(360/1000)
You can use a software to slow down the video. Its rotates 10 times not 5 per secs

1 Like

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

1 Like

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.

1 Like

@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.

1 Like

To all, caculate the milliseconds tag to accurately to 1/10 second values. Its cleaner with

((floor([MSEC]*100))/100)

3 Likes

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.

1 Like

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