HLT data freeze after crossing start/finish

[toolo4sno]

I recently had some intermittant issues at my last OTD. It seemed around half of my laps experienced a data freeze after crossing start/finish and lasting for around 10-12s. On my videos you can see the gauges freeze at the values that were read at start/finish. After 10-12s everything acts normal again. The G-forces map in HLT shows the values after start finish to be basically 0.

I've added the GoPoint OBD sensor since my last OTD. I've made some settings adjustments to hone that sensor, but that's about all I've changed. I did allow slow speeds for detection purposes.

I also had some minor issues with the data being output from the GoPoint. At some points it had me doing 300+MPH and pegged at 8k RPM for a few minutes.

Session 4 seemed to do it the most. You can see it here (@ 1:55, 3:20) http://www.youtube.com/watch?v=DhF53k8dRps
I also attached one track map with G-forces on. You can see after start/finish that it just drops to nothing and then comes back on again.

Any ideas?

[Harry]

It seems the system is overloaded when you cross start / finish. GPS data is timed runtime-independant (i.e. even if a fix is coming in 5 seconds late, it can be assigned the real time). For acceleration it is different. In case the system can't consume data due to other activities, they come in late too but cannot be assigned the original time (which is not documented). So the question is what can be done to reduce the system load. LapTimer stores a lap's recordings (technically a transaction) when finishing a lap. This is usually done within a few hundreds seconds, but may take longer in case the database is very large, the lap recorded is very long, or the update rate is very high (20 Hz). Is there anything that comes to mind reading the list? How many fixes do you have in your database? The number is visible in Lap List's header. Please reboot your system in addition, maybe you have some unfriendly background processes running.

- Harry

[toolo4sno]

It seems the system is overloaded when you cross start / finish. GPS data is timed runtime-independant (i.e. even if a fix is coming in 5 seconds late, it can be assigned the real time). For acceleration it is different. In case the system can't consume data due to other activities, they come in late too but cannot be assigned the original time (which is not documented). So the question is what can be done to reduce the system load. LapTimer stores a lap's recordings (technically a transaction) when finishing a lap. This is usually done within a few hundreds seconds, but may take longer in case the database is very large, the lap recorded is very long, or the update rate is very high (20 Hz). Is there anything that comes to mind reading the list? How many fixes do you have in your database? The number is visible in Lap List's header. Please reboot your system in addition, maybe you have some unfriendly background processes running.

- Harry

I'm pretty sure I've been using 100Hz update rate (under accelerator tweaks) for as long as it has been available. Although, like I said, I just added the GoPoint so there is one more sensor I didn't have before. To get the timing I thought was best I use a 0.4s sensor delay on "Any OBD", and keep the Dual XGPS (5Hz) at 1.5s with Int. Accel at 0.5s. I turned on "Allow Low Speeds" for Trigger detection. Those are the only expert settings I believe I have changed.

I normally run the GoPro app before HLT to turn on the rear camera. To my knowledge nothing is actively running in the background of my iPad, but I'm not familiar with how their OS handles background apps.

The lap with map shown above says 265 fixes (GPS, ACCEL, OBD). Most from that day are in the 270-300 range, with the highest running 355 (looks like complete ACCEL data for those).
An average lap at the same track (without OBD) last year is 330-350 fixes.

After double checking my video, the OBD and ACCEL data are the only ones that freeze. GPS still displays the correct position, but that is likely related to the runtime-independant design you mentioned earlier.

Also, I don't have any good video to show it, but any idea about intermittent bogus strings of OBD data for 1-2 minutes at a time? Maybe related?

When you say "but may take longer in case the database is very large" what is very large? Should I do some Lap List cleaning after I have exported the data I need for videos and such? I intended on keeping all laps, good and bad. I currently have 127 laps in Lap List for the one track.

[Harry]

The 100 Hz certainly add some extra load to the system, you may want to reduce it to the 30 Hz standard. Update rates higher than that do not add too much benefit currently as LapTimer stores data using the GPS update rate only. The only benefit is you get more instant reactions in visual realtime acceleration displays. The GoPoint adds further processing load too, but that is comparably small. The delays are not related to performance.

On background activities: other than Android, iOS takes care there is not too much going on in the background. Nevertheless, there are ways to run in background and I'd suggest you try a fresh reboot directly ahead of the next LapTimer utilization.

I would consider any database with more than 100.000 fixes as large. My personal database (I use for testing) has 200.000 fixes. At this size, operation becomes a but slower compared to the factory default. The fix number you named for individual laps are nothing that should be critical. It is more about cases you run a 20 Hz GPS devices on really long tracks like Nordschleife (around 8 to 9 minutes per lap).

The OBD effects are from dropped connections. While no OBD data is coming in, LapTimer extrapolates the last values - which helps for short drop outs, but yield strange values on the long run.

- Harry

[toolo4sno]

The 100 Hz certainly add some extra load to the system, you may want to reduce it to the 30 Hz standard. Update rates higher than that do not add too much benefit currently as LapTimer stores data using the GPS update rate only. The only benefit is you get more instant reactions in visual realtime acceleration displays. The GoPoint adds further processing load too, but that is comparably small. The delays are not related to performance.

On background activities: other than Android, iOS takes care there is not too much going on in the background. Nevertheless, there are ways to run in background and I'd suggest you try a fresh reboot directly ahead of the next LapTimer utilization.

I would consider any database with more than 100.000 fixes as large. My personal database (I use for testing) has 200.000 fixes. At this size, operation becomes a but slower compared to the factory default. The fix number you named for individual laps are nothing that should be critical. It is more about cases you run a 20 Hz GPS devices on really long tracks like Nordschleife (around 8 to 9 minutes per lap).

The OBD effects are from dropped connections. While no OBD data is coming in, LapTimer extrapolates the last values - which helps for short drop outs, but yield strange values on the long run.

- Harry

Looks like the 100Hz setting was ok before the GoPoint, but it may have sent me over the limit. OK, I'll lower the ACCEL update rate. I don't look down at the iPad much; so if a 100Hz setting only helps realtime display then I don't need it that high. If you give me a "dial" that goes to 100; I'll put it at 100:) More is better right. I suppose 30Hz is as fast as the video frame rate. I'll give it a try next month and see how it goes.

Can I keep all my laps in HLT or should I go through and clean out "bad" laps (read: slow) that I have already exported? Will this help or is that purely memory use.

Does the database number of "fixes" equal how many GPS fixes there were during the lap? Isn't the number of database fixes dependendant on GPS update rate (5Hz), avg speed during lap and lap distance? I can't really change it that much correct? I suppose I want as many fixes as the iPad3 can handle.

Thanks again Harry

[Harry]

The 30 Hz are a good value as it allows lowpass filtering and gives enough fixes for the actual storage scheme - which is at GPS rate. In case the internal GPS is used, 10 Hz update rate for acceleration is more than enough, LapTimer stores one value a second only anyway. The 30 Hz are more than enough for 5 Hz GPS chips. Only for the VBOX Sport running at 20 Hz, I'd recommend a higher value around 60 Hz. So the 30 Hz are not related to video frames, these are interpolated from the GPS rate anyway.

Without compression, a 5 Hz GPS will generate 5 fixes per second recorded - independent of the distance or speed driven. So a 2 minute lap makes 600 fixes for a 5 Hz GPS and 2400 for the VBOX, and 120 for the internal GPS. Record 100 laps and you have 60000 / 240000 / 12000 fixes. A combination of the overall database size and the size of an individual lap make the measure for the load generated when a lap is stored.

- Harry

[toolo4sno]

The 30 Hz are a good value as it allows lowpass filtering and gives enough fixes for the actual storage scheme - which is at GPS rate. In case the internal GPS is used, 10 Hz update rate for acceleration is more than enough, LapTimer stores one value a second only anyway. The 30 Hz are more than enough for 5 Hz GPS chips. Only for the VBOX Sport running at 20 Hz, I'd recommend a higher value around 60 Hz. So the 30 Hz are not related to video frames, these are interpolated from the GPS rate anyway.

Without compression, a 5 Hz GPS will generate 5 fixes per second recorded - independent of the distance or speed driven. So a 2 minute lap makes 600 fixes for a 5 Hz GPS and 2400 for the VBOX, and 120 for the internal GPS. Record 100 laps and you have 60000 / 240000 / 12000 fixes. A combination of the overall database size and the size of an individual lap make the measure for the load generated when a lap is stored.

- Harry

OK, I'll use 30Hz ACCEL update rate, close up programs/reboot, and do a little lap list cleaning.

I wasn't suggesting the 30Hz had any relation to video rates. Just mentioning that my video is only 30fps so having something read faster than that for the purpose of a video is kind of silly in retrospect.

I always know when I have a trouble shooting issue with HLT that I'll be learning something.