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

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


On Fri, 30 Dec 2016 03:18:40 +0900 윤기백 <seseki17 at gmail.com> said:

> 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...)

hmmm. i wouldn't use BOOTTIME. you get many more wrap-arounds then increasing
the number of times an app may glitch due to wrapping 32bit values (every
1.2hrs or so of wall clock time then as opposed to every 1.2hrs of actual
running time which would be far longer on most systems like phones and watches
that suspend for long periods).

> 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
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev


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


More information about the Dev mailing list