Page 1 of 1

Ways to deal with track configuration that interfers with time delta analysis

Posted: Fri Jul 14, 2017 4:10 am
by MatthewS
Sometimes a lap will have a short period of time where the GPS data is apparently way off. (See the attached screenshot for an example.) It would be nice if HLT was able to identify that this data could not be physically possible and skip the data point or interpolate it.

If that is too complicated then perhaps if you could provide a way to manually override the scaling of the time delta. For instance, allow user to set 2 seconds as the max value for the time delta axis. All greater values would be "off the charts" so to speak. This would allow me to still analyze time won/lost for the rest of the lap.

Re: Ways to deal with bogus GPS data that prevents time delta analysis

Posted: Fri Jul 14, 2017 7:30 am
by Harry
Please export both the lap analyzed and reference lap to .hlptrl and send it to me. I will check if this is a recognizable patter. Or a general issue. Please add a link to this post to the two exports. Please do not send more than these two laps.

Harry

Re: Ways to deal with bogus GPS data that prevents time delta analysis

Posted: Fri Jul 14, 2017 2:29 pm
by MatthewS
Hey Harry,

I've uploaded the two laps here

Thanks!
Matt

Re: Ways to deal with bogus GPS data that prevents time delta analysis

Posted: Fri Jul 14, 2017 3:26 pm
by Harry
Hi,

The problem is not about the data or accuracy. The problem is the track is driven in both directions in certain sections. When calculating time won/lost, LapTimer runs a "best match" analysis to identify a reference position and time for a certain position of the lap analyzed. The blue spark is the section where LapTimer selects positions from the reference lap (i.e. the counter direction section). I do not see a simple approach to always select the correct position working for all possible track configuration. So the best option will probably be to allow a vertical scaling (horizontal zoom changes the track section shown and a vertical zoom changes the secondary Y axis). v22 earliest ;-)

- Harry

Re: Ways to deal with bogus GPS data that prevents time delta analysis

Posted: Fri Jul 14, 2017 7:36 pm
by MatthewS
Ah ok. Yes that makes sense.
While I think vertical scaling should work just fine and perhaps even be preferable to an automated solution, what about any of the following ideas:
- Adding criteria to the "best match" algorithm that:
- Uses direction (compass heading) to detect that the two datapoints being compared are not facing in a similar direction
- Uses distance relative to start to compare (eg one datapoint is 25 meters from start versus the other that's 150 meters)
- Keeping info about the previous datapoint comparison and then:
- Comparing the time gap to the previous time gap (ie it's impossible to go from 0.2 seconds behind to 40 seconds behind in when the fixes are 0.1 seconds apart)
- Comparing the direction or relative distance for each car (e.g. Car A goes from 25m to 28m from start, while Car B goes from 25m to 150m from start. That can't be so you continue your search for another nearby datapoint for Car B).

Being in IT, I fully realize it's much easier to SAY what you could do than to actually IMPLEMENT it. :)
Matt

Re: Ways to deal with track configuration that interfers with time delta analysis

Posted: Fri Jul 14, 2017 8:13 pm
by Harry
Exactly ;-)