[Dev] Sensor timestamp source (Tizen 2.3.2, Gear S2 EPK5 firmware)
max at bhsai.org
Thu Dec 29 18:58:34 GMT 2016
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"):
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
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.
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.
> (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.
>> On Thu, Dec 29, 2016 at 11:25 AM, Maxim Khitrov <max at bhsai.org> wrote:
>>> 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
>>> 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 :  t=18446744073694551
>>> 12-29 10:29:27.222 :  t=225000(-18446744073.470)
>>> 12-29 10:29:27.222 :  t=465000(+0.240)
>>> 12-29 10:29:27.227 :  t=705000(+0.240)
>>> 12-29 10:29:27.227 :  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
>>> 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?
>> Dev mailing list
>> Dev at lists.tizen.org
More information about the Dev