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

Maxim Khitrov max at bhsai.org
Mon Jan 23 19:04:49 GMT 2017

Hi Kibak,

Is there any progress on this issue? I just started testing the new
Gear S3 (Tizen, APK7 firmware) and it's the same deal -
nothing matches. Accelerometer might be using CLOCK_BOOTTIME, but each
event is delayed 10-500 ms, heart rate is using CLOCK_MONOTONIC,
pressure sensor again doesn't match any time source.

The sensor framework is not usable on the S2 or S3 watches in its
current state. Is Samsung going to do anything about it? If so, when
and what do we do until then?


On Thu, Dec 29, 2016 at 1:58 PM, Maxim Khitrov <max at bhsai.org> wrote:
> Hi Kibak,
> Thanks for getting back to me. The guide link that you sent returns
> 404, but this one says "Nanoseconds" (first Google result when
> searching for "tizen sensor"):
> https://developer.tizen.org/development/api-guides/native-application/system/sensor
> CLOCK_BOOTTIME is not defined in time.h, but if I define it manually
> (= 7), it still doesn't match timestamps for the pressure sensor:
> 12-29 13:40:29.635 : SensorTest: mono=9214562044 boot=9214562050
> real=1483036829639076
> 12-29 13:40:31.730 : onSensorTest: t=9088971000
> 12-29 13:40:32.255 : onSensorTest: t=9089211000
> 12-29 13:40:32.255 : onSensorTest: t=9089451000
> 12-29 13:40:32.490 : onSensorTest: t=9089692000
> 12-29 13:40:32.930 : onSensorTest: t=9089932000
> As you can see, actual timestamps are ~125 seconds behind the
> monotonic and boottime clocks. When I sent my first message, the
> difference was about 80 seconds and there is almost no difference
> between monotonic and boottime clocks on my S2 at the moment.
> I agree that CLOCK_BOOTTIME is the ideal choice for sensor timestamps,
> but until this is fixed, is there anything I can do on my end? We're
> developing data collection software for scientific research and the
> current firmware is effectively unusable.
> -Max
> On Thu, Dec 29, 2016 at 1:18 PM, 윤기백 <seseki17 at gmail.com> wrote:
>> 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.
>> https://developer.tizen.org/en/development/guides/native-application/location-and-sensors/device-sensors#accelerometer
>> (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.
>> Thanks.
>> - 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