Since our system only has a limited view of the actual events on track we need to implement some heuristics to prevent unreasonable time-id matches from happening.
EndIdTimeout
-- Since riders may enter the bluetooth range of the end id unit without finishing (going through the end time gate) we need a way to prevent old id events from matching with newer times. This timeout (in seconds) sets what the maximum time between an end id and an end time event may be to match them.
MinLapTime
-- It is possible that a track enters and leaves the end id unit range for a bit somewhere in the middle. If something happend to trip the timing gate at that point you would gat an unrealistic lap time. This config value gives the minimum lap time in seconds that a lap needs to have in order to be valid. If a lap is too short it will not be reported and the involved end id and end time events will be available for future matches
Acceptance criteria:
These config values should be set through the /Config endoint of the web api
Since our system only has a limited view of the actual events on track we need to implement some heuristics to prevent unreasonable time-id matches from happening.
EndIdTimeout -- Since riders may enter the bluetooth range of the end id unit without finishing (going through the end time gate) we need a way to prevent old id events from matching with newer times. This timeout (in seconds) sets what the maximum time between an end id and an end time event may be to match them.
MinLapTime -- It is possible that a track enters and leaves the end id unit range for a bit somewhere in the middle. If something happend to trip the timing gate at that point you would gat an unrealistic lap time. This config value gives the minimum lap time in seconds that a lap needs to have in order to be valid. If a lap is too short it will not be reported and the involved end id and end time events will be available for future matches
Acceptance criteria: These config values should be set through the /Config endoint of the web api