[Dev] Sensor timestamp source (Tizen 2.3.2, Gear S2 EPK5 firmware)

윤기백 seseki17 at gmail.com
Thu Dec 29 18:18:40 GMT 2016

Hi, I am a Tizen sensor FW developer and also involved in Gear series development.

First of all, I apologize for feeling confused about timestamp.

Sensor timestamp should have been CLOCK_MONOTONIC..
But it was provided as a CLOCK_REALTIME timestamp due to some problems in product development. (It’s an obvious bug...)
Whenever releasing new firmware, there should be a strict check on the timestamp and values, but there was a missing part..
So.. we are going to add additional testcases in the future.

And we are not strictly guiding the manufacturer to provide monotonic timestamp yet..
IMHO, sensor events should be based on monotonic timestamps 
because of the problem of event sequence when the platform time is changed.
(I'm currently considering CLOCK_BOOTTIME for the batching, it is also monotonic based timestamp.)

It should be provided as a “microseconds" timestamp, as described in the following document.
(Could you tell me the docs that says nanoseconds?)

Plus, the problem you mentioned, accelerometer, pressure sensor and HRM timestamps are different, 
has to be checked at the driver level on gear s2 because timestamps are provided by kernel device driver..
if you report to me, i’ll check that issue.
(i think.. pressure sensor seems to be CLOCK_BOOTTIME...)

If you have also any sensor problems, feel free to contact me.
- Kibak

> 2016. 12. 30. 오전 2:08, Maxim Khitrov <max at bhsai.org> 작성:
> Just to add to this, when I test SENSOR_HRM, the timestamps are from
> CLOCK_MONOTONIC, but timestamps for SENSOR_PRESSURE are over a minute
> behind CLOCK_MONOTONIC and the offset seems to be increasing every
> time I run the test. So to summarize:
> SENSOR_HRM timestamps are from CLOCK_MONOTONIC.
> SENSOR_PRESSURE is almost CLOCK_MONOTONIC, but not really.
> SENSOR_ACCELEROMETER is... I have no idea, but nothing usable.
> -Max
> On Thu, Dec 29, 2016 at 11:25 AM, Maxim Khitrov <max at bhsai.org> wrote:
>> Hi,
>> I posted about this on the developer forum and JIRA back in August,
>> but got nowhere. The original Gear S2 firmware used CLOCK_MONOTONIC
>> for sensor event timestamps. The next firmware (DPG1) changed this to
>> CLOCK_REALTIME. The new firmware (EPK5) that was released a few weeks
>> ago changed the source yet again, only this time I don't have a clue
>> what it's using and I can't find the relevant source at
>> https://review.tizen.org/git/.
>> Here's logcat output from a small native test program:
>> 12-29 10:29:19.827 : CLOCK_MONOTONIC: 153936923042954
>> 12-29 10:29:19.862 : CLOCK_REALTIME:  1483025359862936528
>> 12-29 10:29:27.222 : [00] t=18446744073694551
>> 12-29 10:29:27.222 : [01] t=225000(-18446744073.470)
>> 12-29 10:29:27.222 : [02] t=465000(+0.240)
>> 12-29 10:29:27.227 : [03] t=705000(+0.240)
>> 12-29 10:29:27.227 : [04] t=946000(+0.241)
>> The first two lines are the current time values obtained using
>> clock_gettime, followed by 5 acceleration events at a rate of 250 ms.
>> What am I looking at? Yes, I get that the last four values are
>> relative times in microseconds (even though the docs still say
>> nanoseconds).
>> The first timestamp is always the same, so it's not even an actual
>> time value, which makes it very difficult to convert these times to
>> UTC or to compare them with timestamps from other sensors. I also have
>> no idea whether these values are going to be affected by jumps in the
>> UTC clock or not. Can anyone explain what is happening here and
>> whether there is some hope of a stable API in the future?
>> -Max
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev

More information about the Dev mailing list