Maximizing standing go accuracy

[devenh]

Harry,

I am trying to figure out how to optimize the standing go accuracy for next Sunday's Silver State Classic Challenge road rally. One car at a time starts at one minute intervals. Each competitor starts on the minute (e.g. 9:43:00.00) based on an atomic clock.

I ran some simultaneous tests with an iPhone 4s and an iPad paired with an XGPS150. Not surprisingly, the iPad was much more accurate than the 4s with internal GPS, often by more than 2 seconds (although the test vehicle was not the swiftest, so this probably exacerbated the problem). So I plan to get an XGPS160 so I can have both devices using the same GPS source. I understand that the 160 has a 10Hz update rate. Will that improve standing go sensitivity?

Assuming 1) that I am good enough to start exactly on the minute; 2) that the sensor delay for XGPS is 0.7 in Expert Settings; and 3) that the average time recorded by HLT is XX:00.4, then should I change the sensor delay and, if so, which direction?

In my 10 standing go tests, the iPhone never false started (i.e triggering a start when I had not moved). The iPad did once. Having a false start within 15 seconds of the actual start would be catastrophic as there would not be enough time to reset. Other than waiting for the last second to hit "Staged," is there anything else that can be done to minimize this risk? Would the XGPS160 be more prone to this?

Are the time values recorded by HLT based on GPS time or the device's internal clock? Do you think the time values will be +/- 0.1 second from atomic time?

Any other tips?

Thanks,

Deven

[Harry]

LapTimer triggers standing go situations both by raising speed and by sudden acceleration changes. Only the former will be improved by a higher update rate GPS. The later is the event that will usually be a lot faster visible for LapTimer. It will trigger more than 90% of all situations. While LapTimer uses GPS times for time calculation (i.e. without any influence from real time processing delays), the standing start is a little different. Acceleration events are always based on system time but are bridged to GPS time using a best fit method (both times are synced continuously). This sync will introduce a certain error but it will be clearly below 0.1 seconds.

Back to your challenge. For regularity events I always recommend to use LapTimer for operation while driving all but the last mile / kilometer. To get precise results on the last meters and sub-second, I'd use a high precision stop watch in addition.

- Harry

[devenh]

Okay, I think sensor delay concept is sinking in. Did a search on sensor delay and I still have a few question.

Assuming the default sensor delays (internal acceleration .5, XGPS .7) and the standing go is triggered by the internal accelerometer, then if HLT sees acceleration at 9:15:00.5, then it is recorded as being at 9:15:00.0, right?

At 9:20:00.0 the elapsed time would be shown as 5:00:0, right?

Last year when we were discussing this topic you wrote:

What does this mean for you? As long as the start time is given from "outside" (i.e. the atom clock time we were talking about), you need to add the sensor delay topic. So under the assumption you start based on an external signal, LapTimer will start approximately the named delay late and keep that delay until crossing the finish. So you actually need to arrive with a lap time display of 55:58.50 when crossing finish (LapTimer will report 56:00.00 as the actual lap time - one and a half second later).

So would I have to adjust my target time by the amount of the acceleration or XGPS delay?

Finally, is there any way for one to fine tune these delays for one's equipment? For instance should the delay be different for the XGPS 150 vs 160? iPhone 5 vs 6?

Deven

[Harry]

The delay is the measure for the time between an event occurring in reality and the time the observation arrives in LapTimer for processing. This gap is roughly the time between reality and the time the observation is displayed on screen. So while driving, with a GPS sensor with a 0.7s delay, the information you see is approximately this time old. LapTimer refreshes the display approximately 5 times a seconds (i.e. each 0.2s), so add an average of 0.1 seconds between processing and display to this delay value.

This means the fix time you see in GPS View is late about this time too. If you want to start at 9:15:00.0, do it when 9:14.59.2 is displayed. Whatever system time you have at this point in time (can be off by seconds), LapTimer will map this time to UTC time processed currently (9:14.59.2, reality 9:15:00.0) using the above mentioned method to sync system and GPS time.

In case you start like this, the lap time displayed at 9:20:00.0 (reality) is 5:00.0.

The delay for the XGPS160 is slightly lower than for the XGPS150 (10 Hz vs. 4/5 Hz) - something like 0.025s less.

That's how it is in the app. Except for the GPS time based lap time calculations, everything else may suffer from runtime effects, iOS is no so called real time system. As an example, the display may (rarely) stop updating for 1 second due to some background activities. So back to the start:

For regularity events I always recommend to use LapTimer for operation while driving all but the last mile / kilometer. To get precise results on the last meters and sub-second, I'd use a high precision stop watch in addition.

- Harry

[devenh]

So if I am on a track with a stop / go trigger, all the GPS and time data saved in the hlptrl file are based on the coordinates and time values sent from the GPS device with the exception are those values that have to be interpolated (e.g. splits and start/finish line), right?

If the GPS delay is 0.5s and the screen is refreshed every 0.2s, then then the finish or lap time is displayed on average 0.6s after the finish line has been past, right?

Deven

[Harry]

So if I am on a track with a stop / go trigger, all the GPS and time data saved in the hlptrl file are based on the coordinates and time values sent from the GPS device with the exception are those values that have to be interpolated (e.g. splits and start/finish line), right?

Yes.

If the GPS delay is 0.5s and the screen is refreshed every 0.2s, then then the finish or lap time is displayed on average 0.6s after the finish line has been past, right?

Deven

Yes.

[devenh]

Great, thanks!

Now this next point is where I get confused

On a "normal" lap where the start and stop are GPS triggers, everything displayed is offset by 0.6s (using our previous assumptions). If the lap time is measured 2:00.00, it is recorded and displayed as 2:00.00.

But on a lap triggered by a standing go using the internal accelerometer and ending with a GPS trigger, there is a likely display issue as the sensor delay for each trigger is often different.

For instance, assuming a GPS delay of 0.5s and an accelerometer delay of 0.9s (and ignoring the refresh delay), there is a 0.4s display "inconsistency." When I start 0:00.00 is displayed 0.9s after I have moved. My question is at 0.5s after crossing the finish line does HLT display 2:00.00 (but this is really after 1:59.60 after 0:00:00 was displayed) or is 2:00.00 displayed 0.9s after crossing the finish line? Again ignoring the refresh delay.

Deven

[Harry]

I need to check that in detail in the code. But the principle is as follows: LapTimer receives an acceleration triggering a standing go, it memorizes the current system time, subtracts the acceleration sensor delay, adds the GPS sensor delay, and maps this to GPS UTC time. So in the end we are in our well defined GPS timestamp system again. In general, a regular go trigger will be more accurate as it does not need to take two (probably inaccurate) delays into account.

- Harry

[devenh]

The delay for the XGPS160 is slightly lower than for the XGPS150 (10 Hz vs. 4/5 Hz) - something like 0.025s less.

So there is no practical difference in sensor delay between the 150 and 160, thus leave the default XGPS delay at 0.7s?

Any reason to tweak the internal acceleration delays for the 4s and gen 3 iPad of 0.5s?

Deven

[Harry]

The 160 has 10 Hz meaning an inaccuracy between reality and fix position of 1/10s / 2 = 0.05s. The 150 is at 0.1 in average. So you can reduce the delay by 0.1-0.05 = 0.05 for the 160 compared to 150.

Harry