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

Request and discussion on new / to change features
MatthewS
20 or more Posts ★★★
20 or more Posts ★★★
Posts: 23
Joined: Tue Sep 17, 2013 3:05 am
Has thanked: 4 times
Been thanked: 2 times

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

Postby MatthewS » Fri Jul 14, 2017 4:10 am

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.
Attachments
IMG_4977.PNG
IMG_4977.PNG (72.26 KiB) Viewed 232 times
IMG_4976.PNG
IMG_4976.PNG (102.96 KiB) Viewed 232 times
Last edited by MatthewS on Fri Jul 14, 2017 7:37 pm, edited 1 time in total.


User avatar
Harry
Site Admin
Site Admin
Posts: 8339
Joined: Sun Sep 12, 2010 10:32 am
Location: Cologne, Germany
Has thanked: 97 times
Been thanked: 347 times
Contact:

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

Postby Harry » Fri Jul 14, 2017 7:30 am

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


Image Image Image Image
MatthewS
20 or more Posts ★★★
20 or more Posts ★★★
Posts: 23
Joined: Tue Sep 17, 2013 3:05 am
Has thanked: 4 times
Been thanked: 2 times

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

Postby MatthewS » Fri Jul 14, 2017 2:29 pm

Hey Harry,

I've uploaded the two laps here

Thanks!
Matt


User avatar
Harry
Site Admin
Site Admin
Posts: 8339
Joined: Sun Sep 12, 2010 10:32 am
Location: Cologne, Germany
Has thanked: 97 times
Been thanked: 347 times
Contact:

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

Postby Harry » Fri Jul 14, 2017 3:26 pm

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


Image Image Image Image
MatthewS
20 or more Posts ★★★
20 or more Posts ★★★
Posts: 23
Joined: Tue Sep 17, 2013 3:05 am
Has thanked: 4 times
Been thanked: 2 times

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

Postby MatthewS » Fri Jul 14, 2017 7:36 pm

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


User avatar
Harry
Site Admin
Site Admin
Posts: 8339
Joined: Sun Sep 12, 2010 10:32 am
Location: Cologne, Germany
Has thanked: 97 times
Been thanked: 347 times
Contact:

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

Postby Harry » Fri Jul 14, 2017 8:13 pm

Exactly ;-)


Image Image Image Image

Return to “Feature Requests”

Who is online

Users browsing this forum: No registered users and 1 guest