CODEWITHSUNDEEP
androidgpstimestampsensors
user1086105
user1086105

Reputation: 247

Android: GPS timestamp vs. SensorEvent Timestamp

I just realised that on android the timestamps you get from a GPS Location update are in ms since epoch whereas the timestamps of SensorEvent updates(e.g. of the Accelerometer) are in ns since startup.

I would like to convert the GPS timestamps to the format of the SensorEvent timestamps, does anyone know a good method to do this?

I tried the following: I measured once the time of system startup since epoch:

startupTime = System.currentTimeMillis() - SystemClock.uptimeMillis();

For each gps location update I subtract the startup time:

timestamp = loc.getTime() - startupTime;

But those converted timestamps do still not conform to SensorEvent timestamps, there is still a difference of a couple of seconds...

Upvotes: 3

Views: 3622

Answers (3)

rbncrthms
rbncrthms

Reputation: 306

I am currently looking at responses for the Pressure sensor event, and the timestamps reported there appear to be in nanoseconds since the epoch. If you divide by 1,000,000 you should get a comparable value; this is what I'm seeing in my experience when finding out the age of a sensor value in ms.

I would divide the SensorEvent timestamp by 1000000 and that should give you a value that is comparable with the getTime() method provided by the Location object you get from GPS.

References:

http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp (but it doesn't say what clock is used)

http://developer.android.com/reference/java/lang/System.html#currentTimeMillis()

http://developer.android.com/reference/android/location/Location.html#getTime()

Upvotes: 1

Tobias
Tobias

Reputation: 21

Do not use SystemClock.uptimeMillis(), since it measures the time since boot without the time where the device was in sleep mode. Instead use SystemClock.elapsedRealtime().

Upvotes: 2

mwengler
mwengler

Reputation: 2778

Personally, I would just call System.currentTimeMillis() whenever I got a gps location or a sensor event, and log that as the appropriate timestamp for comparing these events. It should be accurate to within a few milliseconds, relatively speaking, meaning unless a sensorevent happens within a millisecond or so of a GPS fix, you will always get the correct "before" and "after" relationship using this method. Further, it is difficult to imagine any application where having these times to more accuracy than a few milliseconds would actually matter, so this should be an easy and good technique.

The loc.getTime() is from the gps receiver, very much separate from the System.currentTimeMillis(). Unless you are trying to set your phone's clock to be synchronized with so-called "gps time" I would ignore loc.getTime() entirely.

Upvotes: 0

Related Questions