Sports Performance Monitoring

Technical Field

The invention relates generally to sports performance monitoring, and in particular for swimmers.

Background

Known sports performance monitoring devices for athletes employ a variety of sensors such as cardiac rate detectors and GPS receivers for runners, and cadence detectors for cyclists. However, such sensors are not suited use in water and, in any event, are not useful measures in assessing swim performance.

Existing swimming performance monitoring devices such as handheld stopwatches are not suitable for use by the swimmer and are more typically suited for use by a coach standing on the side of the pool. However, this requires a coach to be present at every swim session, and there are a limited number of swimmers the coach can reliably track.

Furthermore, wrist worn stopwatches are not well adapted for use in the pool in that

They require the swimmer to pre¾s ^~~ a ^~ iratton-at^ach-tum -^

action of the turn.

Summary

According to one aspect there is provided a swim state detection method for a swimmer comprising determining a swim start event and determining a rest start event.

According to another aspect there is provided apparatus for detecting a swim state of a swimmer, the apparatus comprising a processor, wherein the processor determines a swim start event and the processor determines a rest start event.

According to another aspect there is provided a computer readable storage medium having a computer program recorded therein, the program being executable by a computer apparatus to make the computer determine the swim state of a swimmer, the program comprising code for determining a swim start event and code for determining a rest start event.

Other aspects are disclosed. Brief Description of the Drawings

At least one embodiment of the present invention will now be described with reference to the drawings, in which:

Figures 1A and IB collectively form a schematic block diagram of an apparatus; Figure 2 shows the major operating states of the apparatus;

Figure 3 shows a state diagram of the swim record state;

Figure 4 shows the steps of the taken during the initialisation state of the apparatus;

Figure 5 shows the steps of the swim start test;

Figure 6 shows the steps of the rest start test;

Figure 7 shows the steps performed during the swim state;

Figure 8 shows the steps performed during the lap turn test;

Figure 9 shows an exemplary turn signal;

Figure 10 shows exemplary empirical data of the angle between the SRV and the NAV during a swimming session;

Figure 11 shows further exemplary empirical data of the decision of the swim start test;

Figure 12 shows the details of the end of a repetition event; and

Figure Γ3 shown exemplary em mcainda a^f^e^eeeler^©^^

body.

Detailed Description

Where reference is made in any one or more, of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

Apparatus hardware

Figures 1A and IB collectively form a schematic block diagram of a swim performance apparatus 101 having embedded components, upon which the methods, to be described, can be practised.

The apparatus 101 is adapted to be attached to the body of a swimmer, and may be attached by a belt around the hips of the swimmer or to the swimmer's bathing costume. The apparatus 101 is provided with a water-tight housing suitable for use underwater. The apparatus 101 is configured to detect swim states and at least one measure of one or more statistics of the swimmer's performance during a swimming session for subsequent upload to a computer for post-workout analysis.

As seen in Figure lA, the apparatus 101 has an embedded controller 102. Accordingly, the apparatus 101 may be referred to as an "embedded device". In the present example, the controller 102 comprises a processing unit (or processor) 105 which is bi-directionally coupled to an internal storage module 109. .The storage module 109 may be formed from non- volatile semiconductor read only memory (ROM) 160 and semiconductor random access memory (RAM) 170, as seen in Figure IB. The RAM 170 may be volatile, non-volatile or a combination of volatile and non-volatile memory. The internal storage module 109 is configured to record one or more swim states and measurements of a swimmer recorded during the swimming session. The controller 102 is also operable to implement several timers to record, for instance the total session time, total swim time, time for each lap, time for each repetition and time for each rest after repetition. The controller 102 is also operable to implement several counters to record, for instance, the number of total laps swum and the number of laps for each repetition. The controller 102 is also operable to implement several registers to record, for instance, -the-st okejate, stroke rate average for each lap, stroke rate average for each repetition, stroke rate average for the total session, intensity factor and training stress score.

The apparatus 101 has a display controller 107, which is connected to a video display 114, being a liquid crystal display (LCD) panel or the like. The display controller 107 is configured for displaying graphical images on the video display 114 in accordance with the instructions received from the processor 105. Preferably, the display 114 is a black and white LCD two-line display device.

The apparatus 101 also has user input devices 113 which are typically formed by keys, a key pad or like control. In accordance with the intended use of the swim performance apparatus 101, the user input devices 113 are water-tight. In some implementations, the user input device may include a touch-sensitive panel physically associated with the display 114 to collectively form a touch screen. Such a touch screen thus may operate as one form of a graphical user interface (GUI) as opposed to a prompt or menu driven GUI typically used with key pad display combination. Other forms of user input devices may also be used, such as a microphone (not illustrated) to perform voice commands or a joy stick/thumb wheel (not illustrated) for ease of navigation about menus. As seen in Figure 1A, the apparatus 101 also has a portable memory interface 106, which is coupled to the processor 105 via a connection 119. The portable memory interface 106 allows a complementary portable memory device 125 to be coupled to the apparatus 101 to actively source the destination of data or to supplement the internal storage module 109. Examples of such interfaces permit coupling with portable memory devices such as universal serial bus (USB) memory devices, digital (SD) cards, personal computer memory card international association (PCMIA) cards, optical discs and magnetic discs.

The apparatus 101 also has a communications interface 108 to permit coupling of the device 101 to a computer or communications network 120 via a connection 121. The connection 121 may be wired or wireless. For example, the connection 121 may be radio

The apparatus 101 is an effective and advantageous apparatus for implementing the described methods. In particular, with reference to Fig. IB, the steps of the described methods are put into practise by instructions in the software 133 that are carried out within the controller 102. The software instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user. An embodiment of the software is presented in Appendix 1.

The software 133 is generally loaded into the controller 102 from a computer readable medium, and is then typically stored in the ROM 160 of the internal storage module 109, as illustrated in Fig. 1A, after which the software 133 can be executed by the processor 105. In some instances, the processor 105 may execute software instructions that are located in RAM 170. Software instructions may be located in RAM 170 by the processor 105 initiating a copy of one or more code modules from ROM 160 into RAM 170. Alternatively, ROM 160 and RAM 170 may be implemented using FLASH memory from which the software instructions of one or more code modules may be loaded for execution by the processor 105, and in which the collected swim data may be recorded. Alternatively, the software instructions of one or more code modules may be pre-installed in a non-volatile region of RAM 170 by a manufacturer. After one or more code modules have been located in RAM 170, the processor 105 may execute software instructions of the one or more code modules.

As described herein, the application program 133 is typically pre-installed and stored in the ROM 160 by a manufacturer, prior to distribution of the apparatus 101. However, in some instances ^" , the application programs 133 may be supplied to the user encoded on one or more CD-ROM (not shown) and read via the portable memory interface 106 prior to storage in the internal storage module 109 or in the portable memory 125. In another alternative, the software application program 133 may be read by the processor 105 from the network 120 or loaded into the controller 102 or the portable storage medium 125 from other computer readable media. Computer readable storage media refers to any storage medium that participates in providing instructions and/or data to the controller 102 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, flash memory, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the device 101. Examples of computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the device 101 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on websites and the like. A computer readable medium having such software or computer program recorded on it is a computer program product.

The second part of the application programs 133 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 114. Through manipulation of the user input device 113 (e.g., the keypad), a user of the device 101 and the application programs 133 may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via loudspeakers (not illustrated) and user voice commands input via the microphone (not illustrated).

Figure IB is a detailed schematic block diagram of the controller 102 comprising the processor 105 for executing the application programs 133, and the internal storage 109. The internal storage 109 comprises read only memory (ROM) 160 and random access memory (RAM) 170. Alternatively, internal storage 109 may comprise FLASH memory. The processor 105 is able to execute the application programs 133 stored in one or both of the connected memories 160 and 170. When the electronic device 102 is initially powered up, a system program resident in the ROM 160 is executed. The application program 133 permanently stored in the ROM 160 is sometimes referred to as "firmware". Execution of the firmware by the processor 105 may fulfil various functions, including processor management, memory management, device management, storage management and user interface.

The processor 105 typically includes a number of functional modules including a control unit (CU) 151, an arithmetic logic unit (ALU) 152 and a local or internal memory comprising a set of registers 154 which typically contain atomic data elements 156, 157, along with internal buffer or cache memory 155. One or more internal buses 159 interconnect these functional modules. The processor 105 typically also has one or more interfaces 158 for communicating with external devices via system bus 181, using a connection 161.

The application program 133 includes a sequence of instructions 162-163 that may include conditional branch and loop instructions. The program 133 may also include data, which is used in execution of the program 133. This data may be stored as part of the instruction or in a separate location 164 within the ROM 160 or RAM 170. In general, the processor 105 is given a set of instructions, which are executed therein. This set of instructions may be organised into blocks, which perform specific tasks or handle specific events that occur in the apparatus 101. Typically, the application program 133 will wait for events and subsequently execute the block of code associated with that event. Events may be triggered in response to input from a user, via the user input devices 113, as detected by the processor 105. Events may also be triggered in response to other sensors and interfaces in the apparatus 101.

The execution of a set of the instructions may require numeric variables to be read and modified. Such numeric variables are stored in the RAM 170. The disclosed method uses input variables 171 that are stored in known locations 172, 173 in the memory 170. The input variables are processed to produce output variables 177 that are stored in known locations 178, 179 in the memory 170. Intermediate variables 174 may be stored in additional memory locations in locations 175, 176 of the memory 170. Alternatively, some intermediate variables may only exist in the registers 154 of the processor 105.

The execution of a sequence of instructions is achieved in the processor 105 by repeated application of a fetch-execute cycle. The control unit 151 of the processor 105 maintains a register called the program counter, which contains the address in ROM 160 or RAM 170 of the next instruction to be executed. At the start of the fetch execute cycle, the contents of the memory address indexed by the program counter is loaded into the control unit 151. The instruction thus loaded controls the subsequent operation of the processor 105, causing for example, data to be loaded from ROM memory 160 into processor registers 154, the contents of a register to be arithmetically combined with the contents of another register, the contents of a register to be written to the location stored in another register and so on. At the end of the fetch execute cycle the program counter is updated to point to the next instruction in the system program code. Depending on the instruction just executed this may involve incrementing the address contained in the program counter or loading the program counter with a new address in order to achieve a branch operation.

Each step or sub-process in the processes of the methods described below is associated with one or more segments of the application program 133, and is performed by repeated execution of a fetch-execute cycle in the processor 105 or similar programmatic operation of other independent processor blocks in the apparatus 101. Main Operating States of the Apparatus

The apparatus 101 , in the methods described below, is configured to determine one or more swim states and performance measures of a swimmer, such as total session time (being the period from the first wall kick or transition from rest to the swim state up to the end of last swim repetition), total swim time (the period of the swim state), total rest time (the period in the rest state during the total session time), total laps swum, time for each lap, time for repetition (one or more laps swum without a rest), time for each rest after repetition, laps for each repetition, stroke rate (typically at 0.1 second resolution), stroke rate average for each lap, stroke rate average for each repetition, stroke rate average for total session, intensity factor and training stress score (IF TSS) consistent with training peaks definition. The IF TSS is calculated using the swimmer's actual measured swimming speed, compared to their Critical Swim Speed. The Critical Swim Speed is calculated using maximal swim efforts over 50m and 400m where the Critical Swim Speed = 350m (Tl-T2), where Tl is the 400m swim time and T2 is the 50m swim time.

As stated above, the apparatus 101 is configured to determine one or more swim states and performance measures of the swimmer during a swimming session for upload to a computer for post-session analysis. The post-session analysis may produce the ■following exemplary tables.

Table 1 provides a summary of the session comprising distance (in meters), swim time, pace, rest and session duration (in hours:minutes:seconds).

Table 1: Session Summary

Table 2 provides a summary of each repetition comprising the distance swum, the total time for each repetition, the pace during the repetition and the rest period at the end of each repetition. Specifically, the first row shows that the swimmer swam 100m in a time of 1 :31.0 and took a 5.2 second rest before starting the next 100m repetition. Each row of the table represents a repetition.

Dist Time Pace Rest

100 01:31.0 00:45.5 00:05.2 Dist Time Pace Rest

100 01:42.5 00:51.3 00:05.9

100 01:26.7 00:43.4 00:07.3

100 01:39.4 00:49.7 00:05.8

200 03:02.6 00:45.6 00:13.3

100 01:26.8 00:43.4 00:04.4

100 01:31.3 00:45.6 00:12.2

100 01:25.9 00:42.9 00:05.7

100 01:30.3 00:45.1 01:07.4

100 01:25.6 00:42.8 00:06.0

100 01:26.1 00:43.0 00:08.9

100 01:25.9 00:42.9 00:08.3

100 01:26.2 00:43.1 04:51.9

200 02:53.1 00:43.3 00:15.0

200 02:52.8 00:43.2 00:16.5

200 02:52.3 00:43.1 00:16.8

, 100 01:25.8 00:42.9 00:19.6

100 01-2679- -00 43 4- -0007,4-

100 01:26.4 00:43.2 00:18.2

100 01:27.1 00:43.5 00:39.1

200 02:53.4 00:43.3 00:16.6

200 02:52.8 00:43.2 00:15.7

200 02:53.7 00:43.4 00:19.4

100 01:24.3 00:42.1 00:28.3

100 01:23.0 00:41.5 00:20.5

100 01:23.6 00:41.8 02:28.4

100 01:42.8 00:51.4

Table 2: Repetitions

Table 3 shows the laps swum during each repetition, comprising the time for the lap and the number of strokes. Each row of the table represents a repetition. . Str Str Str Str

Lap Count Lap Count Lap Count Lap Count

00:43.5 55 00:47.5 . 54

00:50.8 54 00:51.7 56

00:43.1 53 00:43.6 50

00:49.7 57 00:49.7 53

00:43.2 53 00:47.3 50 00:47.0 58 00:45.1 54

00:42.2 53 00:44.6 52

00:45.3 56 00:46.0 54

00:42.1 53 00:43.8 51

00:44.3 56 00:46.0 55

00:45.3 47 00:40.3 50

00:45.1 48 00:41.0 50

00:44.6 47 00:41.3 50

00:45.6 45 00:40.6 48

00:40.4 54 00:44.9 54 00:44.0 52 00:43.8 52

00:41.3 52 - 00:43.5 53 00:43.9 53 00:43.9 52

00:41.1 53 00:43.9 bb 00¾3T6- 53- — ΘΘ:43τ5- 56-

00:41.4 53 00:44.3 53

00:42.1 54 00:44.7 53

00:42.0 54 00:44.3 54

00:43.1 53 00:43.9 52

00:41.3 53 00:44.3 54 00:43.6 56 00:44.0 55

00:41.4 55 00:44.7 58 00:43.1 57 00:43.4 56

00:41.4 54 00:44.0 56 00:43.8 55 00:44.3 55

00:40.7 53 00:43.5 55

00:39.5 54 00:43.4 55

00:40.5 58 00:43.0 57

00:49.3 56 00:53.5 57

Table 3: Laps

Figure 2 shows the top-level operating states 200 of the apparatus 101, comprising an idle state 205, a swim record state 210 and a communication state 215. The apparatus 101 will enter the swim record state 210 after a short button push 220 of one of the user input devices 113. Once in the swim record state 210, the apparatus 101 will enter an idle state 205 after a further short button push 220 on user input devices 1 13. The purpose of the further button push 220 is to orientate the device on the swimmer. The swimmer is to stand still after pushing the button, allowing the apparatus 101 the opportunity . to determine the direction of gravity relative to the swimmer's standing body that is important to the operation of the algorithm described below.

The apparatus 101 will enter the communication state 215, when mounted in a cradle 225. Once in the communication state 215 the apparatus 101 will exit the communication state 215 when the apparatus 101 is removed from the cradle 225. During the communication state 215 the apparatus 101 is configured to transfer data to and from a computing device or to charge the apparatus 101 internal battery by inductive coupling. A waterproof metallic charging coupling may be used as the inductive coupling interface.

determined from the orientation of the body of the swimmer, as further described below with reference to Figure 6.

During the rest state 330, the apparatus 101 records of the rest time of the swimmer but continues recording the total elapsed time. Furthermore, during the resting state 330, the display 1 14 can cycle through one or more display screens for the information of the swimmer.

Similarly, the apparatus 101 will transition from the rest state 315 back to the swim state 310 upon fulfilment of the swim start test 320, as described below with reference to Figure 5. Initialisation State

Figure 4 shows the steps of the taken during the initialisation state 305 of the swim performance apparatus 101. During the initialisation state, the swimmer is expected to be standing upright with the apparatus 101 attached in the correct position (i.e. substantially vertically orientated) on the swimmer's body.

The method begins at step 405 where the apparatus 101 enters the swim record state 210. As described above, the swim record state 210 is initiated when the swimmer presses a button of the user input devices 113.

In step 410, the accelerometer 191 and gyroscope 192 are initiated, during which, for example, the zero offsets of the accelerometer 191 and the gyroscope 192 are set to the last known value. The last known value may be calculated from the prior use of the device or in the case of the first use of the device, the factory defaults are used. The sample frequency of the accelerometer 191 and the gyroscope 192 is nominally 0 Hz.

At step 415, after a further short button push the apparatus 101 waits for a

t e wor s "CA B", n cat ng ca rat on s ta ng p ace.

During the calibration process, the gyroscope 192 may be used to ensure swimmer that the swimmer has settled and is stationary. If the swimmer is not stationary, the display 114 may either display an error message or prolong the wait period.

Once the wait period is over, at step 420 the measured x, y and z axis of acceleration signals from the accelerometer 191 are smoothed to calculate a normalized Standing Reference Vector (SRV), this being the vector along the spine of the swimmer.

Each dimension of acceleration signal may be smoothed separately by averaging. For example, the values of Ax collected during the two second period are averaged, and the same is done for Ay and Az. The averaged values of Ax, Ay, Az are then normalised as the square root of the sum of squares of the values. The values of Ax, Ay, Az are all divided by the normalisation factor.

Alternatively, steps 415 and 420 can be substituted, by determining once the gyroscopes 192 have settled, which indicates the swimmer is not moving. At this time, the apparatus 101 reads the three dimensions of acceleration from the accelerometer 191 for a period of two seconds during which the swimmer is expected to stand still. Then the normalised standing reference vector is calculated as per step 420 above.

At step 425, the apparatus 101 performs the swim start test 320 to determine when the swimmer begins swimming. The swim start test 320 is described in more detail below.

After the swim start test 320 has been satisfied, the method 305 progresses to step 430, where the various timers, lap counters and registers of the controller 102 are initiated.

At step 435, the apparatus 101 enters the swim state 310.

Weighted Moving Average Gyro Zero Offset

Drift of the zero offsets of the gyroscope 192, for example due to temperature fluctuation, may lead to measurement inaccuracy. As such, the gyroscope 192 zero offset should be continually adjusted. Such an adjustment is possible to a sufficient degree of accuracy using the knowledge that a swimmer does not rotate when swimming, rather simply merely rolls from side-to-side. As such, across a lap, the rotation of the swimmer sums to zero.

Accordingly, during ^" the lap state when the swimmer is actually swimming a lap (nominally taken as the period from 1 second ^~ affer ^~ the start of1h¾^wim-state^2^ntil-l- second before the start of the rest state 315 or turn event), the zero offsets of the roll, pitch and yaw signals of the gyroscope 193 are progressively updated. A weighted moving average can be used to set the zero offset. For example, the zero offset of the pitch signal can be calculated according to the following equation:

Pitch _{n+l +} ( - l)Z _a ^■

. λ

where

Z = zerooffset,

λ - pitch -weight (nom = 50), and

Pitch = Raw Signal value

Equation 1

Similar corrections are applied to the yaw and roll signals of the gyroscope 192. As the zero offset values of the gyroscope 193 signals may be used to determine the lap state in the manner described below, the non-corrected zero offsets can be used to determine the lap state. This approach is acceptable from an accuracy viewpoint, since the value for the zero offset moves fairly slowly.

Swim start test .

Figure 5 shows the steps of the swim start test 320. The swim start test 320 is based on the orientation of the swimmer's body and is satisfied when the swimmer transitions from a vertical standing orientation to a prone swimming orientation.

The test 320 begins at step 505 where the x, y and z axis of acceleration signals are obtained from the accelerometer 190.

At step 510, a normalized acceleration vector (NAV) is calculated. The NAV represents the orientation of the apparatus 101.

At step 515, the apparatus 101 determines the angle between the SRV, this being the vector along the spine of the swimmer recorded when the swimmer was in a standing position, and the NAV, being the orientation of the apparatus 101.

If swimmer begins swimming and therefore transitions from a vertical to a prone swimming orientation, the angle between the SRV and the NAV will increase from zero towards ninety degrees.

A threshold test may De emp]oy d ^_ to ^_ determine-when^e-sw4nimer_iias__begurL swimming, for example if the angle between the SRV and NAV is greater than a 45°. A dot product of the LRV and SRV vectors is performed to determine the angle between the LRV and SRV vectors. Since LRV · SRV =|LRV||SRV|cos (0) where Θ is the angle between the LRV and SRV vectors, and |LRV| = |SRV| = 1 then the dot product yields cos(#) directly. The threshold test for a specific angle can be determined directly from the dot product; for example for 45° swim test has been fulfilled when

LRV · SRV < 0.707.

In order to overcome spurious false positive and negative swim tests, n samples may be taken and applied to further threshold tests. For example, the swim start test 320 may be satisfied where more than 80% of the samples are satisfy the swim test.

Figure 10 shows exemplary empirical data comprising the angle 1010 between the SRV and the NAV during a swimming session. Also shown is the decision 1005 of the swim start test 320 where a high value indicates swimming and a low value indicates standing (resting). Figure 11 shows further exemplary empirical data comprising the decision 1005 of the swim start test 320. There is shown the x-acceleration 1115, being the acceleration along the spine of the swimmer, y-acceleration 1110, being the acceleration across the back of the swimmer and the z-acceleration 1105, being the acceleration through the body of the swimmer. The spike in the x-acceleration data 11 15 corresponds to the start of the swim state. Furthermore, the spike in the acceleration in the x direction (along the spine of the swimmer) represents the wall kick.

Rest start test

Figure 6 shows the steps of the rest start test 330. The rest start test 330 is similar to the swim start test 320 in that the orientation of the apparatus 101 determines whether the test has been fulfilled.

The method begins at step 605 where the x, y and z acceleration signals are received from the accelerometer 190. At step 610 the NAV is determined and at step 615, the angle between the NAV and the SRV is determined using the dot product technique. If the difference between the SRV and the NAV is greater than the threshold, for example 45°, the current sample is marked as having fulfilled the swim test. To determine the start of

Swim State

Figure 7 shows the steps performed during the swim state 310. The method begins at step 705 where signal data are obtained from the accelerometer 191 and the gyroscope 192.

At step 710, the various timers are incremented, such as the total session time, total swim time, time for each lap, time for each repetition and time for each rest after repetition timers.

At step 620 the rest start test is performed. If the rest start test is fulfilled, detailed processing of the end events is performed at step 720. The apparatus 101 then enters the rest state 315.

Should the rest start test 620 fail, the method progresses to lap turn test at step 720 where it is determined whether the swimmer has performed a lap turn in the manner described below with reference to Figure 8. Should the lap turn test succeed, processing of the turn timing is performed at step 730, whereafter the method repeats from step 705.

Calculating the Turn Signal

Figure 8 shows the steps performed during the lap turn test 725. The method begins s at step 805 where the pitch, roll and yaw signal data values are obtained from the gyroscope 190.

At step 810, the values are obtained from the gyroscope 190 are converted into rotation rates by subtracting the current value of the weighted moving average of the gyroscope zero offsets and multiplying by a scaling factor. The rotation rates are thus0 given as pitch rate, roll rate, and yaw rate in radians per second.

At step 815, the turn signal is calculated in the manner described below. The turn signal is analysed to detect when the swimmer performs a turn at the end of a lap.

At step 820, if the turn signal is greater than a threshold, then a detailed turn timing processing 730 is performed,

is In order to calculate the turn signal, the pitch, roll and yaw rotation rates from the gyroscope 192 are integrated to provide pitch, roll and yaw angles. In a manner more ^{" ~~} suited for ^" a low-power processor 105, the pitch, roll -and-yaw signals may instead be accumulated according to the following equation: ^{~^}

PitchAngle _n = PitchAngle^ + PitchRate _n

0 RollAngle _n ~ RollAngle _nA + RollRate _n

YawAngle _n = YawAngle _n _ _} + YawRate _n

Equation 2

As the above angles are susceptible to an accumulation of error, their value is largely meaningless. However, the rate of change of angle may be computed by 5 comparing the current angles to previous angles.

As such, the turn signal can be computed by comparing the current average angle to a weighted moving average of. the previous angles.

The current average angle can be computed according to the following equation: y ⁿ , PitchAng :

PitchAngleAverage _n = ^ - ^curra ^ -

. currav

. Y" RollAngle,.

RollAngleAverage _n = ^™" ¹

currav

where currav is default 20 samples (or 2 seconds)

Equation 3

The weighted moving averages of the angles are thus:

PichAngle _n +(A W - \)WMAPitchAngle _n ^ WMAPitchAngle _n =

AW

RollAngle„ +(A W - \)WMARollAngle _n _ _x

WMARollAngle _n =

AW

WMAYa Angle, = ^ngl^AW - ΧψΜΑΥα,Α ^η ^ where AW is AngleWeight parameter (nom = 50)

— Equation 4 — _.

An exemplary turn signal 905 is shown in Figure 9. A turn is characterised by a peak in the turn signal, shown at point 910. As such, in order to determine when a turn event occurs, the turn signal 910 is compared to a threshold 915. In this example, the threshold is 2. If the Turn Signal 910 has multiple local maxima then the first of the local maxima is considered the strongest indicator of a turn event. If it is wished to reduce the computational load on the processor 105, the threshold may be squared instead of taking the square root in Equation 6.

Calculating Turn Timing

In the example given in Figure 9, the turn event is considered to be in progress during the time that the Turn Signal 910 is greater than the threshold 195.

However, in order to determine the lap time more accurately, further information, such as when the swimmer touches the wall, is required.

A wall touch event can be determined from the angle of the swimmer's body relative to the lane direction. As such, a further vector, the Lane Reference Vector (LRV) is used. The LRV is used instead of the NAV as since the NAV is a vector aligned with acceleration, the NAV generally points in the direction of gravity. While it may be possible to use the NAV, this approach may be complicated by the user switching onenlation by say. hOTging^om-baeksteOke-to-breaststroke —

The LRV can be set after the start of the swim state 320 to represent the direction along the lane. As such, the difference between the LRV and the SRV can be used to determine when the swimmer changes direction. For example, LRV * SRV will be approximately 1 while the swimmer is still swimming in the direction of the LRV, and LRV * SRV will be approximately -1 when the swimmer has completed a turn and is swimming in the opposite direction. Again, a threshold, such as -0.5, may be used to distinguish a wall kick. A threshold of -0.5 is used as a threshold of 0 actually represents the point mid-way through the turn. However, this point is not well correlated to the wall kick. For example, mid-way through a turn the body of the swimmer is not yet rotated enough to plant their feet on the wall to kick off. However, once the swimmer has rotated largely in the opposite direction that is when they kick-off, hence the threshold being selected as 120° or -0.5 in dot product terms.

In order to minimise the accumulation errors, the LRV may be set just prior to the turn signal 910 passing above the threshold, as shown at point 915. For example, the LRV may be set to the SRV 10 samples before the sample where turn signal > 2; in other words, the sample 1 second prior to the signal where turn signal > 2. The LRV, like the SRV, is a normalised vector (having unity magnitude).

The movement of the LRV relative to the swimmer is determined by applying the opposite of the yaw, pitch and roll to the LRV, such that, for example, if the swimmer pitches down, the LRV will pitch up relative to its prior position. In other words, the apparatus 101 and hence the SRV move with the swimmer. If the swimmer pitches down (i.e. to start a tumble turn), then the apparatus 101 will point down. However, the LRV (since it is aligned with the lane) does not move in an absolute sense. However, relative to the swimmer, it looks like the LRV has moved (pitched up). As such, if

LRV _n _, = (x,y,z), R = yaw angle, Q = pitch angle and P = roll angle

Then LRV (n) can be computed by computing yaw first: x, = cos(R)x - sin(R)y

y, = sin(R)x + cos(R)y

Z _] = z

Equation ?

Computing the pitch second: x ₂ = cos(Q)x, - sin(Q)z,

z ₂ =sin(Q)x, + cos(Q)z,

Equation 8

and computing the roll last: x ₃ = x ₂

y ₃ = cos(P)y ₂ - sin(P)z ₂

z ₃ = sin(P)y ₂ + cos(P)z ₂

Equation 9

It may be possible to simplify the implementation of these equations by using the following first order approximations: cos(0) ~ 1

sin(0) ~ 0

Equation 10

As the small values for sine and cosine may result in an accumulation of rounding errors, the LRV may be renormalised as follows: length = 7 3 + y] + z

4 =

length y. - length

z = * ³

⁴ length

LRV _n ^ (x„y„2 )

Equation 1

Now, the LRV is pointing to the end of the lane and the SRV will be pointing along the spine of the swimmer. Since |LRV| =|SRV| = 1 , then LRV · SRV = cos (0) whereflis the angle between the LRV and SRV vectors.

As such, when Θ≥ threshold (default value of 120°), then cos(#) < - 0.5 , signifying the start of wall kick.

Therefore, turn timing can be indicated by either the swimmer (SRV) moving through 120° relative to the lane direction (LRV) or a peak in the turn signal. Empirical data has shown that both can determine the accuracy of a wall kick event to within 0.5 seconds, whereas an average of the two provides for greater accuracy across a very broad range of swimming and turning styles. Nevertheless, it is to be understood that either technique can be used to the exclusion of the other with satisfactory performance.

As such, Figure 9 shows exemplary empirical data using both methods for determining the turn timing. As stated already, graph 905 represents the turn signal, useful for the first method of determining a wall kick using a peak in the turn signal 905. Graph 945 represents Ae dot product of me SRV and the LRV, useful for the second method of determining a wall kick indicated by the swimmer (SRV) moving through 120° relative to the lane direction (LRV).

The value of graph 945 is 1 at the point 2 seconds prior to the turn signal 905 passing the threshold 915, whereafter it is slightly less than 1 for the following two seconds, represented by a gradually increasing difference between the SRV and LRV. Once the swimmer starts to turn, the graph 945 rapidly changes to -1 representing a 180° turn in the opposite direction,

Also shown is graph 920 representing the component of acceleration aligned with the LRV, indicating the acceleration along the lane. When the swimmer is swimming smoothly, this acceleration is close to zero because the swimmer is swimming at constant velocity. The dips in the graph 920 at point 930 represent the point where the swimmer has stopped moving forward in the lane (cessation of forward motion) and started to turn, being a deceleration (or negative acceleration). The second dip in the graph 920 at point 940 represents the wall kick, being the positive acceleration in the opposite direction to the prior swimming lap (or negative acceleration). The start of the wall kick is the time that the swimmer's feet touch the wall and represents the lap timing event.

In practice, the acceleration signal 920 may not solely be relied upon for turn timing due to it being an inherently noisy signal. Furthermore, as different swrmmers ^~ use ^" a ^{^} variety of techniques to execute their turn, the shape of the acceleration graph changes depending on the turn type. As such, the application of inertial navigation equations 7, 8 and 9 described above, is desirable to more reliably detect a wall kick.

Calculating stroke rate

Figure 13 shown exemplary empirical data of the acceleration across the swimmer's body 1305, obtained from the Ay signal from the accelerometer 191. The acceleration 1305 is due to gravity when the swimmer rotates. The frequency of the acceleration graph 1305 corresponds to the frequency of rotation of the swimmer's body, which correlates directly to stroke rate. As such, counting the peaks in acceleration graph 1305 provides the lap a stroke count measure.

As can be seen from Figure 13, the acceleration graph 1305 is interrupted by a turn event. Calculating End of Repetition

The simplest indication of the end of a repetition is a state change from swim state to rest state, as described above. However, a swimmer may sometimes only stand up long after they have finished swimming, thereby erroneously prolonging the duration of the final lap in the repetition.

However, the end of a repetition can be accurately determined from a local minimum of the dot product of the LRV and the normalised acceleration vector (NAV) of the swimmer in the two seconds prior to the transition from the swim state to the rest state. The dot product of the LRV and the normalised acceleration vector of the swimmer yields the component of acceleration of the swimmer in the direction of the LRV and removes the effect of gravitational acceleration.

Figure 12 shows detail of the end of a repetition. The swim state signal decision 1205 shows a transition from a swimming to standing orientation. However, as stated above, this transition does not necessarily correlate closely with the timing of the end of a lap. The acceleration graph 1210 shows the dot product of the normalised acceleration and the LRV representing the component of the acceleration in the direction of the lane. The negative peak in the acceleration graph 1210 shown at point 1220 represents the slowing of the swimmer along the lane, correlating to the time when the swimmer stops swimming, therefore being the end of the repetition. Graph 1215 represents the turn signal.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", but not "consisting only of. Variations of the word "comprising", such as "comprise" and "comprises", have correspondingly varied meanings. Appendix 1

This appendix contains a C language implementation of the methods stated above, and in particular:

• Algorithm Stage 1 is an implementation of the Standing Reference Vector,

• Algorithm Stage 2 is an implementation of the Swim Start Test,

• Algorithm Stage 3 is an implementation of the Rest Test and a Turn Test, and

• Algorithm Stage 4 is an implementation of the Second Turn Test.

00001

00038 #include "algorithm. h"

00039 #include "pushbutton. h"

00040 #include "clock.h"

00041 iinclude "flash. h"

00042 #include "accelerometer.ti"

00043 #include "gyroscope. h"

00044 #include "communications .h"

00045 #inc.lude "memory.h"

00046,

00047 / Local defines -

OO53^fraefine-RS E StiOPE^ HRESH0l3D2^ (0x£3¾-5-94W y-_7-6.0-0i-6fl _: a

00059 //#define RATE_SLOPE_THRESHOLD2 (Ox003D0900) // 2000*2000 00060

00061 // Local function prototypes

00062 void algorithmStagel ( void ) ;

00063 void algorithmStagel2 ( void ) ;

00064 void algorithmStage2 ( void )

00065 void algorithmStage3 ( void ) ;

00066 void algorithmStage4 ( void );

00067

00068 // Local variables

00069 intl6_t srv[3] ;

00070 intl6_t hrv(3]

00071 int32_t srvDotHrv;

00072 uint8_t swimStartTimer = 50;

00073 uint8_t restStartTimer = 50;

00074 uint8_t standStartTimer = 20;

00075 uint32_t previousGyroMagSlope2 ;

00076 uint8_t turnTimeFlags ;

00077 #define PEAK 0x01 //!< \ref turnTimeFlags peak value of \ref gyroMagSlope2 has passed 00078 #define TROUGH 0x02 \ref turnTimeFlags trough value of \ref gyroMagSlope2 has passed

00079 #define ANGLE 0x04 //!< \ref turnTimeFlags cumulative angle for a turn has passed

00080 uint8_t turnTimeA;

00081 uint8_t turnTimeB;

00082 uint8_t timeoutCounter;

00083

00084 typedef- int32_t matrix3x3 [3] [3 ] ;

ιο 00085 matrix3x3 localRotationMatrix;

00086 matrix3x3 rotationMatrixO;

00087 matrix3x3 globalRotationMatrix;

00088

00095 void ( *algorithm ) ( void );

15 00096

00100 void initAlgorithm ( void )

00101 {

00104 totalTime = 0;

00105 swimTime = 0 ;

20 00106 restTime = 0;

00107 lapTime = 0;

00108

00109 algorithm = algorithmStagel;

00110 ^" riteAlgorithmStagel essage ( )

^" 25 ^{" ~} 0TJTT2 ^~ T

00113

00120 void algorithmStagel ( void )

00121 {

00124 if ( accellnactivity )

30 00125 {

0012 accellnactivity = 0;

00128 srv[0] = accel_X[currentIndex] ;

00129 srv[l] = accel_Y[currentIndex] ;

00130 srv[2] = accel_Z [currentlndex] ;

35 00131 zeroGyros ( ) ; o

00132 addXmitChar (srv [ 0 ] ) ;

00133 addXmitChar (srv[0] » 8) ;

00134 addXmitchar (sr [1 ] ) ;

00135 addXmitChar(srv[l] » 8) ;

40 00136 addXmitChar (srv[2] ) ,·

00137 addXmitChar(srv[2] » 8);*/

00138 algorithm— algorithmStagel2 ;

00139

00141

45 00143 00144

00189

00195 void algori hmStage2 ( void )

00196 {

00199 int32_t srvDotAcc =

00200 (( (( int32_t ) srv[0] ) ( ( int32_t ) accel_X[curren Index] )

00201 + ! ( int32_t ) srv[l] ) ( ( int32_t )

10 accel_Y[currentIndex] )

00202 + ( ( int32_t ) srv[2] ) ( ( int32_t ) accel_Z [currentlndex] );

00203 // Note that the output of the accelerometers is 256/g, so the magnitude of both srv and accel should be 256

15 00204 srvDotAcc < 0xB505 )

00205

00207 swimStartTimer --;

00208 if ( ! swimStartTimer )

00209 {

20 00210 mode = SWIMMING,

00211

00212 //JP

00213

00215 memoryAddChar L 0x05

-25- -002^6 - -memoryAddChar (_0x0_D.

00217 memoryAdd2 Bits ( timeOfDay )

00218 memoryAdd24Bits ( date ) ;

00220

00221 //JP- end

30 00222

00223- writeSwimmingMessage ( )

00224 swimTime += 5;

00225 restTime = 0;

00226 repTime = 5

35 00227 repDistance = 0;

00228 repCount = 0;

00229 // lapTime += 50; // ! <li> Adjust the

\ref lapTime by 50 deciseconds </li>

00230 lapTime = 50;

40 00231 reststartTimer = 50;

00232 algorithm = algorithmStage3 ;

00233 writeAlgorithmStage3Message ( )

00234

00236 J

45 00237 else 00238 {

00240 swimStartTimer = 50;

00241

00242 }

00244 }

00245

00253 void algori hmStage3 ( void ) -

00254 {

00257 inc32_t srvDotAcc =

00258 ( ( int32_t ) srv[0] ) ( ( int32_t ) accel_X[currentIndex] )

00259 + ( ( int32_t ) srv[l] ) ( ( int32_t ) accel_Y[curren Index] )

00260 + ( ( ^' int32_t ) srv[2] ) ( ( int32_t ) accel_Z [currentlndex] )

00261 // Note that the output of the accelerometers is 256/g, so the magnitude of both srv and accel should be 256

00262 srvDotAcc > 0xB505 )

00263

00265 restStartTimer -- 00266 if ( ! restStartTimer

00267 {

00268 mode = RESTING;

00269

00270

00271

00273 memoryAddChar ( 0x06 ) ;

00274 memoryAddChar ( 0x00 ) ;

00275 memoryAdd24Bits ( timeOfDay ) ;

00276 memoryAdd24Bits ( date ) ;

00278

00279 //JP- end

00280

00281 writeRestingMessage ( ) ;

00282 res Time = 50;

00283 swimTime -= 5;

00284 . repTime -= 5;

00285 lapTime -= 50;

00286 lapCount ++

00287 totalDistance += lapLength;

00288 repDistance += lapLength;

00289 writeLapMessage ( ) ;

00290 LCDTimeDeciSec ( lapTime ) ;

00291 swimStartTimer = 50;

00292 algorithm = algorithmStage2 ; 00293 wri eAlgorithmStage2 essage () ;

00294 }

00296 . }

00297 else

00298 {

00300 restStartTimer = 50;

00301

00302 }

00303

00304 if ( lapTime > 50 )

00305 {

00306 if ( gyroMagSlope2 > RATE_SLOPE_THRESHOLD2 )

00307 {

00309 previousGyroMagSlope2 = gyroMagSlope 00310 turnTimeFlags = 0;

00311 timeoutCounter = 0;

00312 globalRotatibnMatrix[0] [0] = 0x00008000;

00313 globalRotationMatrix[0] [1] = 0x0;

00314 globalRotationMatrix[0] [2] = 0x0;

00315 globalRotationMatrix[l] [0] = 0x0;

00316 globalRotationMatrix[l] [1] = 0x00008000;

003Ϊ7 globalRotationMatrixtl] [2] = 0x0;

00318 globalRotationMatrix[2] [0] = 0x0

00319 globalRotatioriMatrix[2] [1] = 0x0;

00320 globalRotationMatrix[2] [2] = 0x00008000;

00321 algorithm = algori hmStage4 ;

00322 riteAlgorithmStage4Message ( ) ;

00324 }

00325 }

00327 }

00328

00336 void algorithmStage4 ( void )

00337 {

00345 if ( ! ( turnTimeFlags & PEAK ) _. )

00346 {

00348 · if ( gyroMagSlope2 < previousGyroMagSlope2 )

00349 {

00351 turnTimeFlags |= PEAK;

00352

00353 }

00354 previousGyroMagSlope2 = gyroMagSlope2 ;

00355

00356 }

.00357 else if ( ! ( turnTimeFlags & TROUGH ) )

00358 { - 00360 if ( gyroMagSlope2 > previousGyroMagSlope2 )

00361 {

00363 turnTimeFlags |= TROUGH;

00364 turnTimeA = ( NSAMPLES-.1 ) 12;

00365

00366 }

00367 previousGyroMagSlope2 = gyroMagSlope2 ;

00368

00369 }

10 00370 else

00371 {

00373 turnTimeA ++;

00374

00375

15 00377

00378

00429 if ( ! ( turnTimeFlags & ANGLE ) )

00430 {

00432 uint8_t oldestlndex = currentlndex;

20 00433 if ( ++oldestIndex == NSAMPLES ) oldestlndex = 0;

00435 int32_t phi = gyro_X [ oldestlndex] * ( 0x00000036/0x03 );

00436 int32_t theta = gyro_Y [oldestlndex] * ( 0x00000036/0x03 ) ; -

-25- -in;3¾ — si- -gyro^Z-[¾idest-index-]-*—(—0 «S9GO-0-3 -OxO-3-

) ;

00438 // addXmitChar ( gyro_X [oldestlndex] ) ;

00439 // addXmitChar ( gyro_X [oldestlndex] »8 ) ;

00440 // addXmitChar ( gyro_Y [oldestlndex] ) ;

30 00441 // addXmitChar ( gyro_Y [oldestlndex] »8 );

00442 // addXmitChar ( gyro _^ Z [oldestlndex] ) ;

00443 // addXmitChar ( gyro_Z [oldestlndex] >>8 ) ;

00444 /* addXm Char (phi) ;

00445 addXmitchar (phi»8 ) ;

35 00446 addXmitChar (phi>>l6) ;

00447 addXmitChar (phi»24 ) ;

00448 addXmitChar ( theta) ;

00449 addXmitChar (theta>>8) ;

00450 addXmitChar( theta»16 ) ;

40 00451 addXmitChar ( theta»24 ) ;

00452 addXmitChar (psi ) ;

00453 addXmitChar ( si»8 ) ;

00454 addXmitChar (psi>>16) ;

00455 addXmitChar ( si»24 ) ; * /

45 00456 00457 localRotationMatri fO] [0] = 0x00008000;

00458 localRotationMatrixfO] [1] = -psi;

00459 localRotationMatrix[0] [2] = theta;

00 60 localRotationMatrix[l] [0] = psi

00461 localRotationMatrix[l] [1] = 0x00008000;

00462 lbcalRotationMatrix[l] [2] = -phi ;

00463 localRotationMatrix[2] [0] = -theta;

00464 localRotationMatrix[2) [1] = phi;

00465 loca!RotationMatrix[2] [2] = 0x00008000;

10 00466

00467 for ( uint8_t n=0; n < 3; ++n )

00468 {

00469 fo ( uint8_t row=0; row < 3; ++row )

00470 {

15 00471 for ( uint8_t col=0; col < 3; ++col ) 00472 {

00473 rotationMatrixO [row] [col] = 00474 (

00475

20 localRotationMatrix[row] [0]* globalRotationMatrix[0] [col]

00476

localRotationMatrix[row] [1] *globalRotationMatrix[l] [col]

00477

localRotationMatrix[row] [2] *globalRotationMatrix[2] [col]

-25-

00479 }

00480 }

00481 for ( uint8_t i=0; i < 36; ++i ) // Copy the result back to globalRotationMatrix. 9*4 bytes

30 00482 {

00483 ( ( uint8_t * ) globalRotationMatrix ) [i] = ( uint8_t * ) rotationMatrixO ) [i] ; // Typecast it back to. a ID array

00484

35 00485 )

00486 // for ( uint8_t i=0; i < 36; ++i )

00487 // {

00488 // addXmitChar ( ( ( uint8_t * ) globalRota ionMatrix ) [ij)

40 00489 / }

00490

00491 for ( int row=0 ; row < 3; row ++ )

00492 {

00493 hrvtrowj =

45 00494 (

00495 globalRotationMatri [row] [0] *srv[0] 00496 + globalRotationMatrixlrow] [lj *srv[l]

00497 + globalRotationMatrixirow] [2] *srv[2]

00498 ) » 15;

00499 }

5 00500 srvDotHrv =

00501 ( ( int32_t ) srv(0] ) * ( ^' . ( int32_t ) hrv[0] )

00502 + ( ( int32_t ) srv[l] ) * ( ( int32_t ) hrv[l] )

00503 + ( ( int32_t ) srv[2] ) * ( < int32_t ) hrv[2] ) ;

00504 /* addXmitChar ( hrv[0] );

10 00505 addXmitChar ( hrv[0]»8 ) ;

00506 addXmitChar ( hrv(l] ) ;

00507 addXmitChar ( hrv[l]»8 );

00508 addXmitChar ( hrv[2] ) ;

00509 addXmitChar ( hrv[2]»8 );

15 00510 addXmitChar ( srvDotHrv ) ;

00511 addXmitChar ( srvDotHrv»8 ) ;

00512 addXmitChar ( srvDotHrv»16 ) ;

00513 addXmitChar ( srvDotHrv»24 );*/

00514 if ( srvDotHrv < -42598 )

20 00515 {

00517 turnTimeB = NSAMPLES ;

00518 turnTimeFlags |= ANGLE;

00520 }

00522 } ^{' " ""} .

^" 25 ^" 00523 ^: eli : : ^{: ~} ' ^:

00524 {

00526 turnTimeB ++;

00527

00528 }

30 00530

00532 if ( turnTimeFlags == ( PEAK | TROUGH | ANGLE ) )

00533 {

00534

00535 //JP

35 00536

00538 memoryAddChar ( 0x04 ) ;

00539 memoryAddChar ( 0x00 );

00540 memoryAdd24Bits ( timeOfDay ) ;

00541 memoryAdd24Bits ( date ) ;

40 00543

00545

00547 lapTime -= ( turnTimeA+turnTimeB ) /2;

00548 lapCount ++;

45 00549 totalDistance += lapLength; 00550 repCount ++;

00551 repDistance += lapLength

00552 riteLapMessage { ) ;

00553 LCD imeDeciSec ( lapTime j ;

00554 lapTime = ( turnTimeA+ urnTimeB )

00555 algorithm = algorithmStage3 ;

00556 writeAlgorithmStage3Message ( ) ;

00558

00559

00560 if ( ++timeoutCounter == 50 )

00561 {

00563 algorithm = algorithmStage3 ;

00564 writeAlgorithmStage3Message ( ) ;

00566 }

00567 }

00568

00569

00570