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

Maxim Khitrov max at bhsai.org
Thu Dec 29 17:08:38 GMT 2016


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


More information about the Dev mailing list