* A correct kick of a stick or a correct rounding of a pylon is known as a 'strike'. In this task there are a total of 9 strikes.
* The pilot gets a green flag to start
* Timing starts the moment the pilot kicks the slalom pole (typically a 1.8m ski slalom pole)
* Pilot must fly the course in a specific sequence characterised by flying around around one pylon, and then kicking the stick again.
* Once the whole course is completed, the last kick on the slalom pole stops the clock.
* Scoring is based on Pilot time + pilot time penalties. (shortest time is best).
* It should be noted that all slalom scoring is identical apart from the number of strikes required to complete the course.
h4. Required measurements
* Start time (simultaneous to strike 1)
* Flew round the correct pylon in the correct direction (strike 2), Did kick the stick (strike 3), and so on until strike 8
* Stop time (simultaneous to strike 9)
* Added penalties (if any)
h4. Observer workflow
# Identification of competitor: Select the competition number or name of the competitor about to start the task.
# Green flag is raised to indicate competitor may start.
# Kick first stick - timer starts.
Note that the pilot has 3 tries at this, and it is not uncommon for the observer to press 'start' or 'kick' when the pilot actually misses the stick. Pilot will go around for a second go but this can be very quick, 5 - 10 seconds, it must therefore be very simple to reset the timer to zero ready for this second attempt.
# Strikes 2 - 8: Marked as either correct, or not. Pilot only has one attempt at each.
# Strike 9: Kick of last stick - timer stops.
Note that the pilot has 3 tries at this, and it is not uncommon for the observer to press 'stop' or 'kick' when the pilot actually misses the stick. Pilot will go around for a second go but this can be even quicker than the same thing at start, \~5 seconds. This time must therefore be treated as a 'split' ie the underlying timer must continue to run, or better, all recorded times are 'real time'. Either way, it must be very simple to record a second (or third) actual strike 9.)
If all went well, then at this point we have collected two times and 9 booleans.
# Ref. 1.14.5, the Observer must be able to apply any of the penalties: 2S, DL, E0, SF, TG, XC, XE, XL, XO, XS, YO, YS, YM (There must be the plain english description but sufficient to include just the code in the transmitted data).
# Once Observer is satisfied everything is correct, press submit button to transmit data to scoring HQ. This may be changed and repeated.
# Start again with Identification of next competitor.
Note that the time between a competitor finishing and the next one starting should be as little as 20 or 30 seconds so the next setup should be quick and simple (but he does have control of the green flag, so could delay the start).
If there is some sort of course failure (not uncommon for the stick to permanently fall over in this task) then a white flag is raised and the competitor should return to the start and wait for the green flag. In the meantime the observer must reset all data collection to zero ready for the task to start again.
h4. Data which needs to be sent to Scoring
* Terminal ID from where the data was sent from
* Operator name who sent it
* When it was sent
* Task number or ID
* Pilot competition number
* Start time
* Strikes: 9 identified booleans
* Finish time
* Penalty codes (if any)
A JSON representation could be like this:
* With this data, the scoring system should calculate: 91 \[sec elapsed time (t9-t1)\] + 10 \[sec for missing s3\] + 10 \[sec, penalty DL\] = 111 sec.
* This is using UNIX Epoch time. Not very human readable, but conceivably does manage times down to ms much more elegantly than formats like ISO time.
* With a distributed time system like this it is usual for all real times to be in UTC and conversion to local only occurs in UIs.
* The times t2 - t8 are not required for scoring but are included as an example of how some data which is probably collected anyway could be usefully sent for use in some 'added value' analysis of the performance, for example commentators like having split times to predict where the competitor might finish while still in the course.
The above is a very simple representation of the basic requirement, additionally:
* There should be some sort of security mechanism built in.
* There should be a response code from the receiver.
* Cacheing arrangement so unsent data can be sent later (eg when device is back in wifi range)
* All data must be cached locally so in the worst case it is still recoverable via a physical connection.