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, 윤기백 <sesek...@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 <m...@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 <m...@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@lists.tizen.org >> https://lists.tizen.org/listinfo/dev > _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
