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

Maxim Khitrov max at bhsai.org
Thu Dec 29 18:58:34 GMT 2016


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