Suggestions regarding inaccurate Nordschleife BTG triggers
Posted: Fri Aug 26, 2016 11:43 am
Hi,
Correction of the inaccurate triggers for the Nordschleife BTG track set has been requested previously however I understand that modifying the existing track set would render the extensive lap library on Harry's server unusable. e.g. no data points to pad the last couple of seconds of the lap. I also understand that, in aggregate, the lap time is going to be close due to roughly complimentary offsets at beginning and end of the track set. Regardless, the incorrect start/stop times in the video overlays are a constant source of annoyance (at least for me) so I have the following two suggestions:
1. Create an alternative (corrected) BTG track set and let the customer decide which one to use. Potentially (I think) the issue with doing this would be having two track sets with near identical trigger locations on the same device which may cause conflict. I'm not sure if this is indeed a valid potential issue however I believe that allowing the customer to choose whether to switch to the new track set (effectively the customer would be accepting that they will need to build a new lap history for analysis purposes) is a reasonable approach. Personally, I am far more interested in the accuracy of the laps I do now and in the future than I am in my historic laps, mainly because as I become more familiar with the circuit my older laps simply become anecdotal and of little relevance.
2. Define a new trigger type to start/stop the data logging and the video, but not the timing. This proposal has been suggested before, certainly by Autocross users. These additional triggers would need to be added to the existing, approved BTG track set. They would also, presumably, be available for use in user-defined track sets. Additional functionality would be required to allow the user not only to define the end of the video during overlay/export, but also to define the end of the data logging. The user can be presented with the logging data sequentially and could scroll to the desired end point. A really neat way to do this would be to provide an overlay of the data logs onto the map screen that the user can navigate around, zoom in on and select. One further option required would be to allow the user to "Align sectors to user-defined data logging end point" during the overlay/export routine. This option would identify the final sector (lap end) data point, calculate the difference between that data point and the user-defined data logging end point, and then offset all the sector triggers in the data log by that same margin. by For BTG users, this would give far more flexibility when overlaying videos, supporting precise alignment of video, data logging and final/end lap time at the "Gantry". Once overlay is complete, the start of the lap may not precisely be at the "Bridge" but it should be closer to it than it is under the current track set.
I readily admit that I do not have anywhere near sufficient knowledge to understand the complexities involved from the development perspective in either of these two suggestions, but I do believe that it is important to try to provide the customer base with choices or options to improve the user experience.
Finally, great app! And thanks in advance for considering these suggestions.
Jon.
Correction of the inaccurate triggers for the Nordschleife BTG track set has been requested previously however I understand that modifying the existing track set would render the extensive lap library on Harry's server unusable. e.g. no data points to pad the last couple of seconds of the lap. I also understand that, in aggregate, the lap time is going to be close due to roughly complimentary offsets at beginning and end of the track set. Regardless, the incorrect start/stop times in the video overlays are a constant source of annoyance (at least for me) so I have the following two suggestions:
1. Create an alternative (corrected) BTG track set and let the customer decide which one to use. Potentially (I think) the issue with doing this would be having two track sets with near identical trigger locations on the same device which may cause conflict. I'm not sure if this is indeed a valid potential issue however I believe that allowing the customer to choose whether to switch to the new track set (effectively the customer would be accepting that they will need to build a new lap history for analysis purposes) is a reasonable approach. Personally, I am far more interested in the accuracy of the laps I do now and in the future than I am in my historic laps, mainly because as I become more familiar with the circuit my older laps simply become anecdotal and of little relevance.
2. Define a new trigger type to start/stop the data logging and the video, but not the timing. This proposal has been suggested before, certainly by Autocross users. These additional triggers would need to be added to the existing, approved BTG track set. They would also, presumably, be available for use in user-defined track sets. Additional functionality would be required to allow the user not only to define the end of the video during overlay/export, but also to define the end of the data logging. The user can be presented with the logging data sequentially and could scroll to the desired end point. A really neat way to do this would be to provide an overlay of the data logs onto the map screen that the user can navigate around, zoom in on and select. One further option required would be to allow the user to "Align sectors to user-defined data logging end point" during the overlay/export routine. This option would identify the final sector (lap end) data point, calculate the difference between that data point and the user-defined data logging end point, and then offset all the sector triggers in the data log by that same margin. by For BTG users, this would give far more flexibility when overlaying videos, supporting precise alignment of video, data logging and final/end lap time at the "Gantry". Once overlay is complete, the start of the lap may not precisely be at the "Bridge" but it should be closer to it than it is under the current track set.
I readily admit that I do not have anywhere near sufficient knowledge to understand the complexities involved from the development perspective in either of these two suggestions, but I do believe that it is important to try to provide the customer base with choices or options to improve the user experience.
Finally, great app! And thanks in advance for considering these suggestions.
Jon.