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

Carsten Haitzler (The Rasterman) tizen at rasterman.com
Thu Dec 29 23:44:45 GMT 2016


On Thu, 29 Dec 2016 11:25:04 -0500 Maxim Khitrov <max at bhsai.org> said:

> 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?

anything that uses timestamps for events with CLOCK_REALTIME is broken.
fundamentally.

who made this change and how? it went from "right" to "broken" pretty badly.

timestamps for EVENTS are actually only ever intended to be compared with
each other, and not some absolute timepoint. how far was it from event A i just
got to event B that just arrived, and timestamps should never go backwards or
jump around due to NTP/timezone changes/system clock changes etc.

this now hilights the problem of getting input from many different
sources/protocols, because if source A decides 0 is a different place than B
then how can you compare event time points between let's say an accelerometer
event and a digital compass event? and a rotation of a dial or press on the
screen...

this is why IMHO events that can be seen as input, interpreted as such and used
AS input should all go down the same event stream from the same source with the
same timestamp system. at least you get order of delivery correct and don't
have to buffer and re-order them client-side based on timestamp.

-- 
Carsten Haitzler (The Rasterman) <tizen at rasterman.com>


More information about the Dev mailing list