Harry's GPS Suite Forum

I was using the latest version of GrandPrix on iPhone5 at "Infineon" Raceway (which is now called Sonoma raceway and most people recall as Sears Point...)

I have a GoPoint BT1 ODB device and an XGPS150 with the 10Hz software installed.

When looking at the charts of lap data, there is a consistent 2.5 second delay in the GPS vs the ODB speed data. I notice that as well when I'm on the track as the "beep" that I've passed a trigger point seems to happen about 2 seconds after the physical spot of the trigger.

A consistent 2.5" delay in getting a position fix from the GPS to the software isn't really a problem for calculating lap times, but it does make for a problem when trying to use the lap charts to make sure I'm shifting and throttling at the right times and places.

A configurable option (perhaps post-processing) for delaying the ODB data points by a specified offset would be nice to have.

It's also interesting to see the differences in the GPS speed fixes vs the ODB speed fixes. Not sure which is more accurate, but I would guess it's the ODB as the GPS fixes seem to be more heavily filtered.

I've attached a hpltrz file of a sample lap so you can see the offset.

The delays (especially for GPS) have no effect on timing and positions. A GPS fix is coming in with the time it originated, so LapTimer will always work with this time. You need to differentiate that view with LapTimer's real time notification. When the fix triggering a new lap (i.e. a position some distance *behind* the start / finish line) is coming in, it's origin is already approximately 2s old. Although it has a 2 second old timestamp, it is not available earlier due to runtime effects (distance to satellites, update rate, processing time, local network latencies). This is the reason LapTimer beeps late.

OBD is a different thing as the time origin is not part of the data coming in. This is the reason heuristics need to be applied. You can adjust the standard sensor delay values in LapTimer's Expert Settings. Please note this delays are applied during recording, not "after the fact".

While GPS speed is clearly more accurate for constant speeds (at least above 30 or 40 mph), OBD is more spontaneous.

- Harry

Harry wrote:OBD is a different thing as the time origin is not part of the data coming in. This is the reason heuristics need to be applied. You can adjust the standard sensor delay values in LapTimer's Expert Settings. Please note this delays are applied during recording, not "after the fact".

- Harry

Thanks for the prompt reply. I should have checked the expert settings more carefully.

I see that the "Dual XGPS150" has a default sensor delay of 0.7 seconds. What does that do given the timestamps are included in the GPS data as you said?

"Any ODB" has a default delay of 1 second.

Does that mean that since I'm still seeing 2.5 seconds of delta, I need to increase this difference by an additional 2.5 sec?

Note that because the maximum delay is 3 sec, I guess I'll have to do that by changing the Dual XGPS150 delay to 0.2 (-.5) and the ODB delay to 3 seconds (+2). Is that right?

Thanks,

Actually, a 2.5s difference to the default is more than I would expect... Instead of comparing the speed development only, I'd suggest to compare other parameters too: check if the GPS plot and acceleration are well aligned. Next, compare longitudinal acceleration to OBD speed development to have that relation fixed.

The reason I'm not too optimistic on GPS speed / OBD speed alignment is that GPS speed I not well aligned to position changes. Both variables are calculated independently...

On the adjustments: the sensor delays are the time LapTimer expects to be the time between an event occurs (e.g. reaching a certain position), and the point in time this information is delivered .

So in case a sensor data is ahead in the recording, you need to decrease the delay. Finally, please always use GPS as the Stream everything needs to be alignen to. It is the only source featuring time stamps.

Harry