> For the complete documentation index, see [llms.txt](https://docs.wiclax.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wiclax.com/en/use-wiclax/dealing-with-starts.md). # Dealing with starts A competitor's start in Wiclax can be conditioned by both a general start time and an individual start time, depending on the scenarios. {% hint style="info" %} The best place to look at Individual start times in a global way is on the participant list. They can be imported either as registration data (importing participants) or as split times (importing results). {% endhint %} ## Mass starts The simplest case is that of a mass start. All participants in the event, or at least in one race of the event, start at the same time. The event (or the stage) is set up in this way:

In this case the start time will be entered either at the global level or for each of the races. The entry can be made in different places: * from the race control panel, above the main grids

* from the list of races \*\*\* capture * from the list of starts \*\*\* capture

{% hint style="info" %} The acquisition or entry of a passage time prior to a competitor's start time will be rejected. With the exception of course of a passage on the starting line. {% endhint %} {% hint style="info" %} Ahead of the competition, it is recommended to pre-position the start times of each race. In this way, races that have not yet started will not be affected by untimely chip detections on the line. {% endhint %} {% hint style="info" %} Once the race has started and the precise time is known, you can replace the forecast time with the exact value. {% endhint %} ### Shifted starts When a group of competitors - not representing a race but part of a race - has its start at a time other than the general start, before or after, an additional start row will be entered. From the starts screen, add a row with the desired start time and the filter condition that designates the group of competitors. For example `Category = 'Disabled'`. Remember to associate a name with this start row, it will be displayed as a title for the race clocks.

### Wave starts To manage a wave start, each wave will be declared as an additional start. To be created in the start list. 2 scenarios are then possible: * the composition of the waves is known and imposed, for example all bibs from 1 to 499 start in the 1st wave. In this case the rule (condition) associated with the start will indicate who is part of each wave * the composition is unknown, or unreliable: each wave can remain with an undefined rule and the option `Automatic determination of the wave, based on the chip time` will be checked. As its name suggests, the official time of each competitor will be the start time of the wave deducted from his individual start time. **Exceptions** In the event that a competitor has started in a different wave than the one normally planned, it is possible to enter its bib in the *Additional Bibs* column. An exception will always take priority over the rest of the conditions of application of the starts.

## Chip time vs Gun time In the context of a mass start, you can choose to activate the management of chip times and gun times. Gun time is also called official time. ![](/files/poL5Xn4fsXw2casF2NfW) By default, the gun time is presented as additional information for athletes, the ranking of the event remaining based on the official times. By enabling the `Ranking based on gun times` option, the rankings displayed and published will instead be based on precisely measured performances. {% hint style="info" %} If a competitor has not been detected on the starting line, his chip time will automatically take the value of his gun time. The same applies in the case where his start time is earlier than that of the race. {% endhint %} {% hint style="info" %} The Chip Time and Gun Time mode do not replace the time trial mode, which remains the most suitable in the case where each individual has his own start and especially if there is no general start. {% endhint %} ## Time trial The event is set up as an individual or team time trial. In this context, each competitor must have an individual start time to validate the acquisition of a passage at an intermediate point or at the finish. These individual start times can be acquired live and/or pre-positioned as a forecast departure. Any acquisition of a start time will potentially overwrite the forecast time initially present. ### Scheduled start / measured start 2 distinct data are registered on a participant: * his scheduled start time * his measured start time (detection on the line, chip/gate/cell/manual) Each of them is optional but one of them has to be present to calculate a net race time of a competitor in TT mode.\ As long as a measured time is present, it takes priority for the net race time calculation. That's to say if a scheduled time value also exists for the competitor, it gets ignored. Remaining though for traceability and checking. {% hint style="info" %} The start order assignment tool works on and only on the scheduled times. {% endhint %} In the participants grid as well as on the entry or result forms, we find these start times which can be edited if necessary: {% columns %} {% column %}

Mixed view, single column with a remind of scheduled times

{% endcolumn %} {% column %}

Selecting columns from the grid data menu

Viewing/editing start times on the result entry form

{% endcolumn %} {% endcolumns %} ### Building a start list

The Start Time Assignment Wizard allows you to automate a large number of scenarios, thanks to the selectable options: * working on a selection of competitors only, from the grid currently displayed * assignment to the **visible stage** or to another stage of your choice * start order based on the display order, on general classification, or simply random * number of participants leaving simultaneously the case happening, for example 2 by 2 * designation of **favorite bibs**, who must start last Once the desired order has been selected, the final instruction to carry out the assignment will be either: * entering a time for the first start and a frequency (interval between 2 starts). A secondary frequency can be specified for the last X competitors * starting intervals equal to the gaps in the general classification of the event * departures by waves, specifying for each wave its time and the number of competitors concerned **Shifting starts from the grid** With the keyboard `Control + up/down arrow`, you can easily swap start times of 2 consecutive rows to compose the starting order.

**Modifying the first start time** The *First Start* tool is a helper to enter a new value for the first departure. By validating it, all times will be recalculated/shifted taking into account this new base and without altering the initial order or frequency. Ideal in the case where the race is simply delayed. **Simple order (without times)** The start list preparation tool also allows you to define a starting order independent of time allocation.\ In this case, it relies on the `Order` data, which is a numeric index. A corresponding column is displayed in the participant list. {% hint style="info" %} After applying a starting order according to the criteria of your choice, it is possible to request a new bib number allocation which will follow this order (from 1 to xx for example). {% endhint %} ## Start times acquisition ### Individual starts Individual start times can be imported or retrieved live from an acquisition device (stopwatch or RFID reader). In both cases, integration is done by designating the start line as the target of the acquisition:

The option to process re-passes for this destination is active by default for a start line. This means that a new passing overwrites the previous value for the competitor, as long as he has no passing at the finish or at an intermediate point prior to the new value. However, you can toggle the option to only tolerate a single passing on the line. In the case of a mass start, you can specify a tolerated interval after the shot:

In the example above, any crossing of the line within 8 minutes of the starter shot (in other words the competitor's race start time) will be counted as a starting time. After this time limit, any new passage will be considered an arrival. {% hint style="info" %} The *Start check* target corresponds to a simple check point, for example at the entrance of the starting area. It only stores a yes/no value rather than a passage time. In the participant grid, the information is found in the form of a column to quickly find who has been detected or not. {% endhint %} {% hint style="info" %} A mass start line isn't always meant to be connected live. It can be processed right after the gun shot by rewinding the hardware detections. {% endhint %} ### Manual modification An individual start time can also be entered/modified: * directly from the participant list * from the participant entry form * from the results entry form, where we also find the history of the passages acquired for the starting line ### Start impulse Some RFID readers or some stopwatches can transmit an impulse identifiable as a start signal. Refer to their documentation for more information, equipment by equipment. When receiving such a signal Wiclax will open an dialog to validate which start line is concerned. If it is the focused race or the race currently displayed on the screen, you will normally only have to validate. Multiple selection of starts is possible. \#screenshot ## Start grid Printing a start grid or starting list can be done simply by printing the list of participants, previously sorted by the start time column. ### Start order field If the event does not deal with individual start times but you still need to respect a certain display order other than that of the bib numbers, you can use the `Order` data available on the participant grid. Values are free (numeric) and a display or printing of the list of participants will automatically follow the order defined in this way. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.wiclax.com/en/use-wiclax/dealing-with-starts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.