Precision timestamp with miliseconds

Former Member over 10 years ago

How can I get from system unix epoc with miliseconds?

Sys.getClockTime have hours, min and sec [1]
Moment have timestamp: year, month, day, hour, min, sec [2]
Sys.getTimer have miliseconds but unsynchronized! When seconds on [1] or [2] change value +1, getTimer have for example 473ms!

I must calculate aproxymate offset to getTimer to build "precision" timestamp.
Hello Garmin: this is WATCH! and we need precision, confidential source of time for applications!

Former Member over 10 years ago

For stopwatch I need a timestamp start -> asap after the button press, current -> for display and stop after button press. I can store timestamps in a flash and restore again after widget restart.
Yes, I know about time drift and gps shift but this make difference on any stopwatch.
Anyway.
Need I too much? Sorry we have XXI age and we write a programs on the WATCH! And don't have we time witch miliseconds in GPS watch?
Think You ist is ok?

travis.vitek over 10 years ago

Multiplying by 1000 ain't right is it?

I convert to milliseconds and then add in the elapsed milliseconds according to the system timer.

Former Member over 10 years ago

Yup. I had a good run. Time for bed now.

travis.vitek over 10 years ago

For stopwatch I need a timestamp start -> asap after the button press, current -> for display and stop after button press. I can store timestamps in a flash and restore again after widget restart.

Yes, I know how this works. I implemented a stopwatch months ago that did exactly this, it just didn't have millisecond accuracy.

Yes, I know about time drift and gps shift but this make difference on any stopwatch.

I don't know of many stopwatches that deal with time discontinuities that occur when synchronizing with GPS. I don't really know of many stopwatches that use GPS.

Need I too much? ...And don't have we time witch miliseconds in GPS watch?

I don't know if you are asking too much. I don't know if the information is readily available, and I don't know how accurate it will be after a reboot or how the system handles the previously mentioned time discontinuities.

I still think that this is all something you can do yourself. You should be able to use the current system timestamp to establish the number of elapsed seconds, and the system timer to determine some reasonable estimate of the elapsed milliseconds. I'm not sure how a device reboot would be handled since the system timer is likely to reset on reboot. Regardless, your stopwatch would be off by a little (up to two seconds) if the user rebooted.

Former Member over 10 years ago

I'm look to my widget - the TimeZonesWidget. I show in this unix timestamp and after reboot it work very good - on precision I can look in my eye compared do servers synchronized to debian ntp pool. GPS need very good time to calculate position. I think in my watch is very good source of time, but this is not show to ciq applications - in my opinion it is not good. I undestund some restrictions like power save, security personal settings, but time - in watch?

Former Member over 10 years ago

The timer provided by System.getTimer() is a free running 32bit millisecond timer. The timer will rollover every ~49 days. It will also reset if the device is restarted.

For as long as the device runs without running out of battery, or restarting, you can keep track with just the millisecond timer.

There is no synced millisecond time source in our watches. They do not use sub-second precision for applications other than the stopwatch timer, which uses differential timing from the millisecond timer.

Jedd_ over 1 year ago

Anyone have an update on this? I need a timestamp with milliseconds as I need to sync to an android application and the time for the data to arrive at the application is ~1.6s. I need accuracy to ~10ms. Currently at startup I am just looping for a second waiting for the time to change, then calculating a millisecond offset to add with the timer milliseconds to the date. The watch should have very accurate time from the GPS, so it is a little frustrating this is not readily available.

flocsy🤠 over 1 year ago in reply to Jedd_

I also hit this when I had to log things with milliseconds, but since it was only logs I just gave up on it. Your use case sounds more valid, but look at the last sentence from the comment of Brian from 9 years ago. Can't you do the same? What do you do and how you use the timestamp?

Jedd_ over 1 year ago in reply to flocsy🤠

Unfortunately I'm syncing a button press to another Bluetooth device through a phone and the variable delay across Bluetooth and CIQ causes the issue. The only solutions are timestamp with accurate enough time or improve the Bluetooth CIQ latency issue or allow Bluetooth bonding to get around the issue altogether (but that is only being added to the newest watch models and I want to support back to the vivoactive 4 series)

I need the absolute time so I can't use a delta.

flocsy🤠 over 1 year ago in reply to Jedd_

What's your flow? Using absolute time isn't the very best practice IMHO. There must be a better way.