Track/Crit Races need the ability to pause and roll back a race

[mbuckaway]

Is your feature request related to a problem? Please describe. The race situation: There has just been a big crash. The course/track is no longer safe for riders to continue. Race is neutralized and riders leave the course/track. Currently, there is no way to pause a race. If CrossMgr is permitted to run, there could be extra chip reads while the race is neutralized and then there could be a 15 min lap in with the other <2min laps. The only solution currently is to stop CrossMgr, and create a new race from the point where the crash happened.

Describe the solution you'd like Along with start/stop, Crossmgr needs a way to pause a race. The clock would stop as would data collection. Additionally, it would need some way to wind back a race possibly removing a lap (or 2 or 3 in case of track racing) to get back to a clear set of data before the crash happened.

Describe alternatives you've considered There isn't really a good solution presently other than stopping CrossMgr and starting up a new race from the lap the race was neutralized, which messes up the results page.

[rkantos]

In some cases it could be possible to redo the results up to that point by importing the RFID-file again, with the reads removed while the race was stopped. Of course this means all reads need to be cleared when loading the RFID-file.

[mbuckaway]

@rkantos That is a good work around to put all the results into one race and one set of race results, but it's alot of work when one should be able to hit PAUSE RACE, and get the same result.

[esitarski]

There are a number of issues to consider here:

• PAUSE RACE cannot take effect in real-time as you may not be able to react to the issue in time. Need something like "pause race after lap 11". This would mean that the race would be considered paused at the last rider's time passing at lap 11. There also needs to be a way to edit the pause start manually to keep the timer in control.
• Internally, a pause would be represented as a time interval. Reads during a pause interval would be ignored for results. Of course, these reads would be stored internally so that that if the pause interval was edited, the results would be update automatically.
• All reads after a pause interval(s) would be adjusted by subtracting the total pause duration from the recorded time. In this way, new reads are mapped into a "virtual race time" and appear as if the pauses didn't happen. Since the original read times are not changed, pause intervals could be edited/added/deleted at any time and the results would change accordingly.
• Internally in CrossMgr, this could be implemented by pre-processing the "times" attribute in the Rider class - taking the pause intervals into account to ignore/adjust as described above. Once the pause interval logic was applied, the rest of CrossMgr would take it from there (Primes, Results, Publish, etc.). Performance impact should be minimal - just have to check if each time falls into a pause interval (ignore), or if it is outside (subtract sum of earlier pause durations). Can be done in a single pass over the times - O(N).
• Does UNPAUSE work the same way as a race start (Manual, First Read, etc.)? Sometimes a race is started with time offsets (especially in a crit). Is it OK to ignore these time offsets and just let it work itself out in the next lap (easiest solution)?
• Missing Splits and Lap Time edits need more thought. Edits likely have to be mapped from "virtual" race time back into "actual" time. This could lead to some confusing interactions with auto-correct that need to be thought through.

Not a trivial enhancement when considering missing splits/lap edits.

[mbuckaway]

"PAUSE RACE cannot take effect in real-time as you may not be able to react to the issue in time."

Correct, and it certainly was the case on Sunday. Crash happened, 4 laps later, race was neutralized. This is the reason the race needs to wound back. I would envision selecting a lap in one of the screens to "crop race". It would be at the end of a lap after all riders have passed. Then the race would be restarted at that point. The fun part, this probably be a case where an undo would not be possible.

[esitarski]

I don't see a big problem with undo. Each PAUSE interval has a "start" (when we start ignoring data input) and an "end" (we accept input again). PAUSE intervals can be moved/changed at any time (I say "intervals" plural because this could happen multiple times in a race). The key point is that all data is stored wrt the original race start time. It would be mapped into "virtual" race time based on the PAUSE intervals. No data "cropping" necessary - just skip inputs if they happened during a pause.

[mbuckaway]

To make a comment, one hits the comment button.

[esitarski]

Sorry - fat mouse fingers. I thought of some more considerations:

Time Trial mode. For the moment, TT's will not be paused. Pausing a TT only makes sense if you pause the start times, and that is completely different logic than interrupting a race and resuming it. A use case might be if the course was temporarily obstructed. I can imagine that pausing a TT could be done by editing the Excel spreadsheet: add the pause (say 15 minutes), then re-import the start times into CrossMgr (this needs to be tested). Editing an Excel sheet is painful and difficult to execute in real-time under race circumstances, but this may be all that is needed for this rare use case. Managing TT delay logic in CrossMgr could get complicated as delays could be absorbed by gaps between categories etc.

Races run by time, not laps. Race pauses require a distinction between "elapsed time" (time since the race start) and "race time" (elapsed time subtract pauses). For example, say I am running a 45 min race, and I have a pause for 10min at min 20-30. One minute after the race resumes the following are true:

• Paused time=10min
• Elapsed time=31min.
• Current Race Time=21 min (elapsed time - total paused time)
• 24 min remain in the race (remaining lap count computed wrt this time)

Race Shortened after Pause. To keep the day on time, the race might be shortened after a pause. This should work in the usual way by editing the Categories screen: decreasing the Race Time or decreasing the Race Laps, depending on whether the race was run by time or laps.

[esitarski]

Now implemented in Beta in the latest Dev version.

It ended up working differently than originally imagined (much simpler and task focused). I also address the issue a RFID read delay during the restart.

Explanation of the feature is covered in the Help under in the Restart section.

I still have a few more test to complete with my RFID simulator.

[mbuckaway]

RFID simulator? Um, is that another project to be checked in? It would be extremely useful.

[esitarski]

It's JChipClient.py, which simulates input from CrossMgrImpinj. It also creates a basic eg spreadsheet. It creates the same spreadsheet each time you run it. To set up a race, start it to get the spreadsheet (you can then Ctrl-C it to stop the simulation). Then you can link to it in CrossMgr.

For all integrations (Alien, RaceResult, etc.) there is a corresponding XXXClient.py which simulates the device. These were written based on the published spec for the device. The simulators are used to test with, as well as what happens when you disconnect, etc. Without the simulators, it would be impossible to deliver the integrations without owning the hardware (which costs $$$$).

[esitarski]

Debugging done (a few enhancements were required for the simulation to enable testing). I was able to Finish a race, then restart it and have it continue as if nothing happened. The RFID delay works well (that could be a good feature to add to the regular start).

[esitarski]

Closing as feature now implemented.