SensorEvent.timestamp and Location.getElapsedRealtimeNanos() Timestamp Delay Offset

Question

I am currently getting timestamps from accelerometers, magnetometers, and gyroscopes and performing sensor fusion with GPS Location on an android device. I am getting the sensor timestamp using SensorEvent.timestamp and Location.getElapsedRealtimeNanos() .

My code is as follows:

Sensor Timestamp

public void onSensorChanged( SensorEvent event ) {
    if( event.sensor.getType() == Sensor.TYPE_ACCELEROMETER )
        System.out.println( "Acc:" + event.timestamp );
}

GPS Timestamp

public void onLocationChanged( Location loc ) {
    System.out.println( loc.getElapsedRealtimeNanos() );
}

My issue is that the timestamps are offset by some arbitrary amount. I know this because all the GPS values are clustered by some offset from the rest of the sensors. Sometimes this offset is in minutes, sometimes hours, sometimes leading and other times lagging. Why does this delay exist in my implementation and how do I fix it?

This is a quick plot of the clustering I was talking about. I sorted the timestamps and timestamps after the sharp disjoint are all timestamps that pertain to the GPS measurements.

In the logs, the data is output sequentially. Message types 1 and 4 pertain to sensor readings, while -1 pertains to GPS. As you can see, the timestamps are not monotonic. The rest of the GPS timestamps are offset from the sensors by a similar amount. Note that this datapoints are from another dataset.

I used the following code to output the time.

System.out.println( SystemClock.elapsedRealtimeNanos() );

After checking the system clock in the hooks, the GPS timestamp is consistent. However the sensor is clearly offset from the SystemClock. The first column is the SystemClock, second column is the timestamp from the respective event object, and the third timestamp is the message type (-1 for GPS, others are IMU sensors).

Things that I've looked into

I've also seen that GPS clock sync is about 10-15 seconds behind, but since I'm using the time from boot, it shouldn't be an issue.

I've looked into this SO question but I don't think it applies because the delay on that issue seems consistent (100 miliseconds) and the magnitude is small relative to what I'm experiencing.

As tempted as I am to use SystemClock.elapsedRealtime() in these event hooks, I know that there is a delay between when the sensors are measured and the events are called. I don't want to introduce any delay/uncertainty into my model.

After doing hours of digging, I have also found lots of android bugs that are a few years old and most are labelled obsolete. I am really stumped. Any light on the issue would be greatly appreciated.

Answer 1

The answer is simple, the SensorEvent.timestamp has an arbitrary zero reference :

It turns out after a bit of Googling (tip o' the hat to StackOverflow, as usual) that the timestamp one receives isn't based off of any particular 0-point defined in the Android OS or the API; it's an arbitrary per-sensor value intended to allow for different measurements from the same sensor to be compared, not for the measurements to be compared to other timestamped events. It's a known issue (bug concerning the documentation; bug concerning the behavior), but as of right now it's the way of the world for Android developers.

Source: http://fixermark.blogspot.ca/2014/06/quirkiness-of-android-sensor-library.html

My solution is to estimate offsets by adding SystemClock.elapsedRealtimeNanos() into the log and estimating the delay/offset of each sensor.