WO2015048884A1

WO2015048884A1 - Systems and methods for monitoring lifting exercises

Info

Publication number: WO2015048884A1
Application number: PCT/CA2014/000723
Authority: WO
Inventors: Vahid BABAKESHIZADEH; Rami ALHAMAD; Peter Michael LOVAS; Suresh Joshi
Original assignee: Push Design Solutions, Inc.
Priority date: 2013-10-03
Filing date: 2014-10-02
Publication date: 2015-04-09

Abstract

A user sensor device, which is worn by an athlete, is provided to measure acceleration, orientation and other information about an athlete while exercising. Exercises include lifting weights. The user sensor device sends the recorded data to a mobile device for processing and the mobile device displays the interpretation of the data in a graphical user interface. The athlete uses this information to schedule workouts and manage the progress of the workouts. Using a server system that is in communication with the mobile device, a coach or trainer sends workouts to the mobile device as well as feedback regarding the progress of the workouts.

Description

SYSTEMS AND METHODS FOR MONITORING LIFTING EXERCISES

TECHNICAL FIELD

[0001] The following relates to a system and method for tracking and analyzing exercises and managing training regimens.

BACKGROUND

[0002] Exercise training is becoming more data driven. Athletes and coaches wish to record data about an athlete's performance and analyse the data. For example, the data can be used to track an athlete's progress over time. The data can also be shared with others. Conveniently recording the exercise data, meaningfully displaying the exercise data, and conveniently sharing the exercise data is difficult.

[0003] The difficulties of recording, displaying and sharing exercise data are more complex for weight training. Given the variety of exercises for weights (e.g. barbell curls, bench press, deadlifts, etc.), it can be cumbersome and difficult to accurately measure data about an athlete and to manage the obtained data.

SUMMARY

[0004] In one embodiment, a processor-implemented method comprises wirelessly connecting, by a mobile device comprising a processor, to a sensor device comprising a motion-measurement unit capturing motion data and a musculature-measurement unit capturing biometric data; receiving, by the mobile device, one or more user inputs from a user interface of the mobile device; receiving, by the mobile device, motion data and biometric data from the sensor device; identifying, by the mobile device, a first repetition of an exercise being performed by the user according to at least one of the motion data, the biometric data, and the one or more user inputs; and responsive to identifying the first repetition of the exercise: analyzing, by the mobile device, the biometric data and motion data in view of the identified exercise.

[0005] In another embodiment, a mobile device for monitoring exercise information comprises a wireless interface component configured to communicate wirelessly with a user sensor device and receiving inertial measurement data for a motion performed by a user from the user sensor device; a display screen configured to display a user interface, receive one or more user inputs, and display a number of repetitions identified; and a processor configured to compare the inertial measurement data against a motion profile of an exercise selected by a user input, and identify one or more repetitions of the exercise performed by the user based on the selected exercise and the inertial measurement data.

[0006] In yet another embodiment, a processor-implemented method capturing motion and biometric data comprises capturing, by a sensor device attached to a user, motion data for a repetition performed by the user, the motion data containing acceleration data and orientation data; capturing, by the sensor device, biometric data from the user performing the repetition of an exercise; transmitting, by the sensor device, the motion data for the repetition and the biometric data for the repetition to a mobile device; and generating, by the sensor device, a haptic response based on an indicator received from the mobile device.

[0007] In another embodiment, a user sensor device for measuring exercise information, the user sensor device configured to be attached to an athlete's body, the user sensor device comprising an inertial measurement unit configured to measure acceleration of the sensor device and orientation of the sensor device about X, Y, and Z axes; an electromyography (EMG) sensor forming at least part of an outer surface of the user sensor device and positioned on the user sensor device such that the EMG sensor touches the athlete's body when the user sensor device is attached to the athlete's body, and configured to measure biometric data associated with the athlete's body; a processor configured to calibrate the inertial measurement unit based on one or more gravity vectors, and determines a beginning and end of repetitions of an exercised performed by the athlete based on the acceleration and the orientation of the sensor device; a wireless communication device configured to transmit data obtained from the inertial measurement unit and the EMG sensor; and a haptic feedback generator configured to generate a haptic feedback in response to instructions received from the processor, the processor receiving haptic feedback instructions from the mobile device.

[0008] In yet another embodiment, a computer-implemented method for managing exercise data comprises transmitting, by a computer, a machine-readable computer file containing a workout to a mobile device associated with a user, wherein the workout comprises one or more exercises to be performed and a motion pattern associated with each respective exercise; receiving, by the computer, from the mobile device exercise data associated with each respective exercise of the workout, wherein the exercise data contains repetition data associated with each respective repetition of the exercise; storing, by the computer, in a non-transitory memory the exercise data in a workout record associated with the user; and generating, by the computer, a profile page of the user based on the workout record of the user, wherein the profile page displays exercise data for one or more workout records of the user.

[0009] In another embodiment, a system comprises a sensor device comprising a sensor device comprising an inertial measurement unit configured to capture motion data of a user, an electromyography sensor configured to capture biometric data of the user, and a wireless communication interface configured to communicate with a mobile device; a mobile device comprising a wireless communication interface configured to receive motion data and biometric data received from the sensor device, and a processor configured to identify a start and end of a repetition based on the motion data associated with one or more repetitions of one or more sets of an exercise performed by the user; and a server computer comprising a networking interface configured to receive the workout data from the mobile device, and a non-transitory storage medium configured to store the workout data in a record of the user, wherein the workout data comprises the motion data and biometric data for each respective repetition in the one or more sets of the exercise.

[0010] Additional features and advantages of an embodiment will be set forth in the description which follows, and in part will be apparent from the description. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the exemplary embodiments in the written description and claims hereof as well as the appended drawings.

[0011] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.

BRIEF DESCRIPTION OF DRAWINGS

[0012] The methods, systems and/or programming described herein are further described in terms of exemplary embodiments. These exemplary embodiments are described in detail with reference to the drawings. These embodiments are non-limiting exemplary embodiments, in which like reference numerals represent similar structures throughout the several views of the drawings, and wherein:

[0013] Figure 1 is a flow diagram of the configuration of the system, detailing an example of the transfer of data originating from the user sensor device.

[0014] Figure 2 is a flow diagram illustrating an example of the sequence of data transfer following the use of a user sensor device.

[0015] Figure 3 is a block diagram of example components found in the user sensor device.

[0016] Figure 4 illustrates a an example of a user sensor device and accompanying armband from the front, top and side views.

[0017] Figure 5 illustrates how the user sensor device can be worn on an athlete's arm.

[0018] Figure 6 is a cross section of the forearm from Figure 5 illustrating the placement of the sensor and electromyogram.

[0019] Figure 7 is a flow diagram of the user sensor device once turned on, along with flow diagrams for the Bluetooth component and the measurement unit's auto calibration component.

[0020] Figure 8 is a flow diagram of the user sensor device's status as indicated by a light emitting diode (LED).

[0021] Figure 9 is a flow diagram detailing the hardware interrupt on the capacitive touch button.

[0022] Figure 10 is a block diagram detailing the interaction between the user sensor device and a mobile device, illustrating how the system generates and processes data before syncing with a server.

[0023] Figure 11 is a flow diagram for a mobile application and its interaction with both a user sensor device and a server. [0024] Figure 12 illustrates three methods in which a sync may occur from a mobile device to a server.

[0025] Figure 13a is a flow diagram of the algorithm process for generating user metrics.

[0026] Figure 13b is a flow diagram of the algorithm process for generating user metrics.

[0027] Figure 14a illustrates the sequences of data collection and metric generation from the user sensor device.

[0028] Figure 14b illustrates the sequences of data collection and metric generation from the user sensor device.

[0029] Figure 15a is a flow diagram of the preprocessing steps of user data obtained from the user sensor device.

[0030] Figure 15b is a flow diagram of the preprocessing steps of user data obtained from the user sensor device.

[0031] Figure 16a is a flow diagram of the data transformation obtained from the user sensor device.

[0032] Figure 16b is a flow diagram of the data transformation obtained from the user sensor device.

[0033] Figure 17a is a flow diagram demonstrating the incorporation of machine learning and decision fusion processes into the algorithm of extracting repetitions and metrics.

[0034] Figure 17b is a flow diagram demonstrating the incorporation of machine learning and decision fusion processes into the algorithm of extracting repetitions and metrics.

[0035] Figure 18 is the primary workflow of the mobile application, depicting the start of a workout. [0036] Figure 19 is a flow diagram of the login procedures when launching a workout mobile application.

[0037] Figure 20 is a flow diagram of the settings page on the mobile application, where the syncing of devices and the updating of athlete information is performed.

[0038] Figure 21 is a flow diagram of starting a scheduled workout on a mobile application.

[0039] Figure 22 is a flow diagram of filtering and selecting workouts on a mobile application.

[0040] Figure 23 is a flow diagram of selecting and starting a workout on a mobile application.

[0041] Figure 24 is a flow diagram of modifying a selected workout on a mobile application.

[0042] Figure 25 is an example depiction of a login page of a mobile application.

[0043] Figure 26 is an example depiction of a workout screen with a list of favorite workouts on a mobile application.

[0044] Figure 27 is an example depiction of a list of scheduled workouts for a mobile application.

[0045] Figure 28 is an example depiction of the main page for a workout mobile application.

[0046] Figure 29 is an example depiction of a list of exercises after selecting a workout for a mobile application.

[0047] Figure 30 is an example depiction of a list of workouts available to an athlete on a mobile application.

[0048] Figure 31 is flow diagram of a 'free' workout session where exercises are selected immediately preceding the start of a workout. [0049] Figure 32 is an example depiction of creating a 'free' workout session on a mobile application.

[0050] Figure 33 is an example depiction of entering and changing workout parameters on a mobile application.

[0051] Figure 34 is an example depiction of the mobile application screen during a workout.

[0052] Figure 35 is an example depiction of a review page in between sets during a workout.

[0053] Figure 36 is a flow diagram of criteria that would trigger synchronization between a mobile application and a server.

[0054] Figure 37 is a flow diagram illustrating post-workout options for a mobile application.

[0055] Figure 38 is an example depiction of an athlete's profile for a mobile application, where social feeds, statistics, athlete information and achievements are shown.

[0056] Figure 39 is an example depiction of friends' updated personal bests in an athlete's social feed for a workout mobile application.

[0057] Figure 40 is a flow diagram of an online portal where coaches or trainers log in to update athlete information and to push new workout routines or to schedule tests for members.

[0058] Figure 41 is a flow diagram of the login procedures for coaches or trainers using a portal management system.

[0059] Figure 42 is a flow diagram illustrating example steps a coach or trainer must undertake to assign periodization plans to athletes on a team.

[0060] Figure 43 is a flow diagram illustrating functionality of a team dashboard on a portal management system where a coach or tramer can edit, add or remove athletes and assign periodization plans. [0061] Figure 44 is a flow diagram illustrating functionality of a test dashboard on a portal management system where a coach or trainer can schedule, edit and assign tests to members of a team.

[0062] Figure 45 is a flow diagram illustrating functionality of an athlete dashboard on a portal management system where coaches or trainers can review and push periodization plans to individual athletes.

[0063] Figure 46 is a flow diagram for workout routines on a portal management system where coaches or trainers can add, edit, duplicate or delete workouts for specific athletes.

[0064] Figure 47 is an example depiction of the periodization dashboard of a portal management system where coaches or trainers can add periodization plans to athletes.

[0065] Figure 48 is an example depiction of the team dashboard of a portal management system where a list of athletes belonging to a team is presented.

[0066] Figure 49 is an example depiction of the athlete dashboard of a portal management system, illustrating athletes belonging to a specific team.

[0067] Figure 50 is an example depiction of the athlete dashboard of a portal management system where recent history and analytics of a specific athlete are presented.

[0068] Figure 51 is an example depiction of the test dashboard of a portal management system where a list of tests and an overview of performance is presented.

[0069] Figure 52 is an example depiction of the routine dashboard of a portal management system where coaches or trainers can add, edit or remove workout routines for athletes.

DETAILED DESCRIPTION

[0070] It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the example embodiments described herein. However, it will be understood by those of ordinary skill in the art that the example embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the example embodiments described herein. Also, the description is not to be considered as limiting the scope of the example embodiments described herein.

[0071] The continued development of technology in the personal fitness market has led to new methods of recording and sharing of data. The analytics generated by the data serves as a powerful tool to increase an athlete's performance and to maximize potential. However, it is recognized that there is yet to be a portable consumer device capable of recording, logging and displaying exercise data for athletes, including athletes who weight train. Some currently available exercise data collection systems require the aid of specialized data technicians or personnel, which can hinder the independence and convenience of an athlete. Some currently available exercise data collection systems include sensors that are built-in to the exercise equipment, or are tethered onto a weight or a bar, and consequently limit the range of possible exercises. Therefore currently available exercise data collection equipment are considered not robust and do not offer the flexibility and portability that is desired.

[0072] As smartphones continue to grow in popularity, the number of mobile applications related to exercise and health also grows. It is recognized, however, that many of such mobile applications have user interfaces with a continual high level of user interaction and are considered cumbersome for many athletes, especially when the athlete is exercising. The user interface and experience is even more cumbersome for many of such mobile application when the types of exercises are various.

[0073] It is also recognized that some athletes are unaware of the appropriate level of load or volume training. Overexertion is a cause of not only fatigue but also a source for injuries. It is recognized that a system for measuring an athlete's performance, trends and fatigue can streamline a workout and provide feedback for optimal performance.

[0074] Many new strength training athletes are unaware of exercises to perform and are unsure of proper technique used for a given exercise. Instructional tools such as videos and pictures only supplement the knowledge and do not provide insight into how to properly perform the exercise. While trainers are the best and safest way to learn efficiently, costs often exceed the derived benefit of contracting a trainer. Therefore, it is recognized that the ability for athletes to self-regulate and learn from other instructional means is desirable.

[0075] It has been known that exercising with a partner motivates and encourages active participation. Present strength training methods and apparatus's do not facilitate the use of existing or proprietary social networks to promote and challenge athletes to compete among peers. In exercising technologies, it is recognized that athletes are unable to, or cannot conveniently, share progress and exchange workout routines with others. Similarly, teams or individuals with private coaches are not able to conveniently view historical records of athletes' data to streamline workouts and view progress. It is recognized that the lack of social data and communication infrastructure impacts the efficacy of communication between coaches, athletes, peers or any combination thereof and ultimately affects performance.

[0076] Turning to Figure 1, an example embodiment of a proposed system is provided for measuring and managing exercise data. A user sensor device 100 is positioned on the body of the athlete 108 can be used to measure data about the athlete when the athlete lifts weights 109. The user sensor device 100 is configured to detect and send data to either a mobile device 101 or a central processing hub 102. In the example embodiment presented in Figure 1, one user sensor device 100 is shown. However, although not shown, multiple user sensor devices can simultaneously communicate with the central hub 102 or to the mobile device. For example, the athlete 108 may wear multiple user sensor devices 100 on different parts of his/her body, and the data collected from the multiple user sensor devices can be collected by the mobile device 101 or the central hub 102, or both.

[0077] In another example embodiment, also not shown, multiple athletes may exercise in the same vicinity (e.g. the same gym), and each athlete wears at least one user sensor device 100. Each athlete may have their own mobile device that obtains the data from the respective user sensor device, and each of the mobile devices are in communication with the central hub 102 or the central servers 103, or both. In another example embodiment, each athlete's user sensor device 100 communicates directly with the central processor hub 102. Such scenarios may be desirable when multiple athletes wish to have their exercise data compared and displayed with each other on a display screen 104, for example, which is located in the gym. [0078] In the various example embodiments described above, the mobile device or the central hub process the data and sends the processed data to a remote server 103. The server 103 is configured to push the data to an external display 104 or to a user portal 110 that can be shared and viewed by other parties. In an example embodiment, the other party requires access credentials to enter the user portal. Such parties may include a social group 105, a coach trainer 106, and an athlete 107. It can be appreciated that these other parties 105, 106, 107 use computing devices (e.g. tablets, laptops, mobile devices, desktop computers, etc.) to access and interact with the portal 110.

[0079] It can be appreciated that the user sensor device 100 is able to communicate with the mobile device 101 or the central hub 102, or both, through currently known and future known wireless communications. For example, Bluetooth, WiFi, NFC, radio, or other wireless communication technologies can be used. The interaction with the central servers 103 occurs using wireless technologies or wired technologies, or both. Communication with the central server 103 is facilitated by the Internet, although other public and private networks can be used.

[0080] Turning to Figure 2, an example embodiment of a workflow overview of the system is provided. The user sensor device 100 includes an inertial measurement unit ( U) 150, a microcontroller unit (MCU) 151 and a wireless communication device 152. The exercise data 157 captured from the IMU 150 is sent to a microcontroller unit 151 that instructs the wireless communication device 152 to transfer the data to the mobile device 101. Data from the training athlete is wirelessly sent from a user sensor device to a mobile device on a continual basis until instructed otherwise. The data includes, for example, sensor-fused orientation, gravity-compensated acceleration, raw acceleration data, raw gyroscopic data, and a battery status of the battery in the user sensor device 100. The battery, though present in the device 100, is not shown in Figure 2. The mobile device 101 may also send start and stop commands to the user sensor device 100.

[0081] Although not shown, the mobile device 101, the hub 102, and the server 103 each include a processor device, a memory device and a communication device.

[0082] Data analysis and processing are performed on the mobile device 101. In another example embodiment, the data may be processed by the servers 103. Visualizations 153 of the processed data (e.g. statistics, metrics and benchmarks) can be viewed on the mobile device. The processed data and the raw data may be sent to a server 103 through a wireless network 155. The athlete's data is then sent to any interested parties 156 associated with the athlete for further viewing and analysis. Two-way communication is established between the athlete and a coach 106 or another athlete, for example, using the mobile device 101. The coach is able to use the user interface provided by the portal 110 to access the athlete's workout data, either in real-time, or after the athlete's exercise. The data can be analyzed by the coach and the coach can provide feedback based on the data. The coach can also determine and schedule workouts for the athlete using the portal 110. The athlete's mobile device 101 displays the recommendations and schedules to the athlete, which are obtained via the portal 110.

[0083] Turning to Figure 3, an example configuration of a user sensor device 100 is shown. In this example embodiment the IMU 150 includes an accelerometer and a gyroscope, which can measure acceleration and orientation along the X, Y and Z axes. The device 100 also includes a capacitive touch sensor 201, a haptic device 208, an electromyography (EMG) sensor 202, a battery 205 (e.g. lithium polymer battery), a recharging circuit 206 for the battery, an indicator light (e.g. LED) 209, a Bluetooth module 207, and a memory device 204 (e.g. flash memory 204). These components are connected to the MCU 151.

[0084] In an example embodiment, the capacitive touch sensor 201 is pressed to power on or off the user sensor device 100. When the device 100 is turned on, the device can be synchronized with the mobile device 101 through the Bluetooth module 207, which, in this example embodiment, serves as the communication protocol between a user sensor device 100 and a wireless interface component (e.g., Bluetooth interface card/chip) of the mobile device 101. If no connection with the mobile device is established, data from the IMU 150, EMG sensor 202, the recharging circuit 206, etc. can be saved and stored in the memory device 204, and then later sent to the server 103 when the mobile device and the server 103 are able to communicate with each other.

[0085] The EMG sensor 202 records the electrical activity of muscle cells. For the device 100 described herein, the data from the EMG sensor 202 can be used to determine the presence of a weight in a clamped hand. The data from the EMG sensor 202 can also be used for other types of analysis and decision making. Data obtained from the U 200 is packaged together to form sensor-fusion based metrics (e.g. combination of accelerometer and gyroscope data) to be wirelessly transmitted through the Bluetooth module 207 to the mobile device. Such metrics may include raw acceleration data, raw gyroscope data, sensor- fused orientation coordinates, gravity-compensated acceleration data and battery status, as shown by the interaction between components 152 and 101 in Figure 2. Haptic vibration 208 can be used for both informative and instructional purposes, with unique vibrating sequences assigned to different purposes. For example, if an athlete completed the amount of pre-set repetitions in a set, the user sensor device 100 could vibrate. If an athlete has been improperly performing an exercise, the haptic controller could vibrate but in a matter different than described previously.

[0086] Although not shown, the EMU 200 can include other devices such as a magnetometer, barometer or thermometer to measure other metrics.

[0087] Of the remaining components in a user sensor device, the lithium polymer battery 205 is rechargeable and supplies the necessary power to the components of the device. The recharging circuit 206 charges the lithium polymer battery and indicates the battery charge status to the microcontroller. The indicator LED 209 displays the overall status of a user sensor device, using different combinations of steady or flashing lights. The LED 209 may be colored light.

[0088] Figure 4a is the top view of an example embodiment of a user sensor device

100. The user sensor device is comprised of a water and impact resistant shell 250 along with an adjustable antibacterial armband 251 that can be detached from the shell. In an example embodiment, the device is worn along the forearm of the athlete, although it can be appreciated that the user sensor device can be attached to the body in various ways. Other preferred locations include the lower back and the calf.

[0089] Figure 4b depicts a front view of a user sensor device. The capacitive touch sensor 201 is situated at the front of the device 100, with the indicator LED 209 forming the boundaries of the sensor 201. Other components in Figure 3 are housed within the shell 250 with the EMG and haptic controller touching or forming at least part of the bottom surface of the shell 250. In this way, the EMG sensor 202 and the haptic device 208 are situated closer to, or against, the athlete's skin.

[0090] Figure 4c is a side view with the adjustable armband removed from the shell. [0091] It can be appreciated that the small and portable user sensor device does not restrict user movement and can be placed anywhere on the body. The lightweight design can be easily attached using commonly known methods such as Velcro, strap back or tape. This flexibility allows for three axes of data to be obtained (e.g. X, Y and Z coordinates) and does not rely upon components that much be attached to a weight lifting bar.

[0092] Figure 5 depicts the an example embodiment of the user sensor device 100 , including the armband 251, placed on the forearm.

[0093] A cross section of the forearm in Figure 5 is illustrated in Figure 6 where elements 350 represent two bones of the forearm. The EMG sensor 202 or the haptic device 208, or both, are located at the bottom of the user sensor device 100 and close to the athlete's body. However, these components 202 and 208 can be positioned elsewhere within the device 100.

[0094] It will be appreciated that any module or component exemplified herein that executes instructions or operations may include or otherwise have access to computer readable media such as storage media, computer storage media, or data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Computer storage media may include volatile and non-volatile, removable and nonremovable media implemented in any method or technology for storage of information, such as computer or processor readable instructions, data structures, program modules, or other data, except transitory propagating signals per se. Examples of computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by an application, module, or both. Any such computer storage media may be part of the user sensor device 100, the mobile device 101, the central hub 103, the central servers 103, the computing devices 105, 106, 107 that can access the portal 110, etc., or accessible or connectable thereto. Any application or module herein described may be implemented using computer or processor readable/executable instructions or operations that may be stored or otherwise held by such computer readable media. [0095] Turning to Figure 7a is a high level flow diagram illustrating example computer executable or processor implemented instructions that are performed by the user sensor device 100. It can be appreciated that all the sub-figures (i.e. Figures 7a, 7b. 7c) may occur independently of each other or in combination with each other. At block 400, the user sensor device is activated or "awaken". This can be triggered when receiving a user input from the capacitive touch sensor 201. When the device is awake, as per block 401, the device 100 determines whether the device 100 is in communication with the mobile device 101. If there is no connection, an attempt is made to connect with the mobile device (block 402) before returning to block 401. When the user sensor device 100 is connected to the mobile device 101, the device 100 determines whether the IMU has data (block 406). If the IMU has data to be sent, the data is retrieved in block 403 before the user sensor device sends the data to a flash memory component (block 404). Subsequently the LED indicator updates (block 407) to reflect any changes in the user sensor device's state. If an IMU did not have data to be sent, the LED is still updated to reflect this result, as per block 407. The user sensor device cyclically continues this flow provided the device is awake.

[0096] The executable instructions for the Bluetooth communication thread are depicted in Figure 7b whereby the state of the flash memory component is determined. At block 408, if data is contained within the flash memory component the Bluetooth module sends the data to the mobile device at block 409. Otherwise the Bluetooth module at block 410 sleeps for a predetermined period of time and awaits new data.

[0097] Figure 7c depicts executable instructions for the auto calibration method of the IMU component. Block 411 determines if motion has been detected for a pre-set duration of time. If motion has been detected, at block 413, the device 100 calibrates the IMU against gravity vectors and subsequently refers back to block 411 to check for motion. If no movement is detected the timer at block 412 is refreshed before once again checking for any motion at 411.

[0098] Figure 8 illustrates executable instructions, performed by the user sensor device 100, for controlling the LED indicator 209. After the device 100 is turned on (block 450), the device 100 determines whether the device 100 is in communication with the mobile device (block 451). If so, the LED color is updated to red (block 456) and following the start of a workout exercise block (458), the LED updates to green (block 459). If the exercise is finished (block 460) the LED returns to red at block 456, otherwise the LED remains green for the duration of the exercise. It can be appreciated that the LED automatically toggles between both colors based on the presence of an ongoing exercise. If no exercise was started, the LED is red; conversely if the exercise was not finished, the LED is green. However, after an exercise has been completed the LED returns to red.

[0099] A user sensor device can also be turned off (block 457) after the LED is red. If a user sensor device cannot connect to a mobile device, the LED blinks red (block 452) and attempts to restore communication with the mobile device. If a predetermined number of connection attempts are exceeded (block 453), the LED indicator fades (block 454) and the device sleeps (block 455). This saves the battery charge within the lithium polymer battery. If the number of connection attempts is not exceeded, the flow returns to block 451.

[0100] Figure 9 depicts example executable instructions, performed by the user sensor device 100, for controlling the status of a user sensor device based on the color or blinking pattern of the LED indicator 209, or both. The color or blinking pattern may vary depending on the user input received from the capacitive touch sensor 201. If the sensor 201 is touched once (block 500), the device 100 determines if the device 100 and the mobile device are in communication (e.g. or are synchronized), as per block 501. If the sensor 100 and the mobile device 501 are not in communication, the LED indicator 501 will indicate this using a certain color or blinking pattern, or both. The sensor 100 then attempts to communicate with the mobile device 101 (block 505). If the light indicates the user sensor device and the mobile device are already in communication, a further determination of whether data is being collected (block 502) is made. If data is not being collected, the user sensor device starts collecting data (block 503). If data is being collected, the user sensor device stops collecting data (block 506). It can be appreciated that when the athlete touches the capacitive touch sensor 201 with a single tap, the operation of the user sensor device 100 is altered.

[0101] A double tap of the touch sensor (block 504) returns the battery status of the device 100. If enough battery power exists for more than one workout (block 507), the LED indicator blinks green twice (block 517). If there is enough battery power for only one workout (block 508), the LED indicator blinks yellow twice (block 518). Otherwise, the LED indicator will blink red twice (block 509) to indicate that there is insufficient battery power. [0102] Lastly, holding down the touch sensor (block 510) initiates a check of whether the user sensor device is on (block 511). If the user sensor device was off, it is subsequently activated or woken up (block 514) with the LED indicator state appropriately updated (block 515). The user sensor device then attempts to establish communication with the mobile device (block 516). If the device was on, then the LED indicator is updated to indicate off (block 512) and the device is subsequently put to sleep or deactivated (block 513).

[0103] Turning to Figure 10, example executable instructions show the interaction between a user sensor device 100 and a mobile device 101. After turning on the user sensor device (block 550) and opening the mobile application to interact with the user sensor device (block 551), a two-way communication stream is established between the two devices (block 552). After determining an exercise on the mobile device (block 553), either automatically or based on user input, the user sensor device is put into a data recording mode for a set (block 554).

[0104] By way of background, a "set" refers to a group of repetitions in weight training. An "exercise" refers to a particular movement (e.g. barbell curl, bench press, squat, leg press, etc.), and each exercise may be performed a certain number of sets, and within each set the particular movement is repeated a certain number of times. A "workout" refers to an exercise or a collection of different exercises that an athlete performs in a session.

[0105] Continuing with Figure 10, the user sensor device collects and streams data from the IMU and EMG to the mobile device (block 556). The mobile device characterizes the data according to the exercise, which was determined as per block 553. Data received on the mobile device is continuously stored (block 555). After the athlete stops exercising or the set is complete (block 557), the mobile device processes the collected data of the set using algorithms to compute a set of metrics (block 558). The mobile device displays the metrics (block 559). The data, raw or processed, or both, is sent from the mobile device to the central servers 103 (block 560). Such metrics may include, but not limited to, power, force, repetition counting, volume load, tempo, explosive strength and velocity per repetition. The steps in between and including blocks 554 and 560 may be repeated until the workout is completed. [0106] It can be appreciated that the user sensor device 100 detects the set has started and stopped through various ways. In an example, the IMU and EMG data can be used to detect that the athlete has started a repetitive motion using a certain amount of strain to indicate the beginning of a set. Similarly, the IMU and EMG data can detect that the athlete has stopped the repetitive motion. The repetitive motion is detected by identifying a certain pattern in the IMU and EMG over a period of time. The analysis of the data for this purpose can be performed by the mobile device 101 or the user sensor device 100. In another example, the user sensor device detects the start and the stop of a set based on user input. For example, the athlete can tap the capacitive touch sensor 201 to indicate the start and the stop of the set.

[0107] Turning to Figure 11, example executable instructions, which are performed by the mobile device 101, show the mobile device's interaction with both a user sensor device 100 and a server 103. When the mobile application for the exercise program is launched (block 600), a login graphical user interface (GUI) is displayed (block 601), as well as a main page GUI (block 602). Any number of GUI options is displayed, including but not limited to, options for workout (block 604), social feed (block 603) and profile pages (block 605).

[0108] Within the profile page, a settings GUI (block 606) can be launched. From the settings GUI, the mobile device displays an option to force synchronization or communication between the mobile device and the server (block 612). The settings GUI also allows an athlete to force synchronization between the mobile device and the user sensor device (block 611). While syncing should be done automatically with minimal interaction with the mobile device, the option to force synchronization serves as a facilitator for the user to manually initiate the synchronization. This may be helpful, for example, when the automatic synchronization fails.

[0109] Other options can be accessed from the profile page, including an option to display statistics (block 609) and an option to display progress (block 610). The statistics and progress are based on the athlete's exercise data.

[0110] Traversing from the main page GUI to the workout GUI (block 604) leads to a set of options, including but not limited to, filtering and adding workouts (block 607) and selecting workouts (block 608). Receiving a user selection for a workout (block 608) from the GUI can lead to displaying a modification tab (block 614). A list of modification options are displayed and depending on which modification option is selected one or more of the following are performed: swapping the current exercise with a similar one (block 615), removing an exercise from the workout (block 616), adding an exercise to the workout (block 617), and editing an exercise listed in the workout (block 618). When adding an exercise, the exercise can be from a collection of exercises are pre-set in a database hosted on the server, enabling an athlete to review and select exercises based on preference. In another example, there is the option to add an exercise by obtaining it from another party, via the central server 103. For example, exercises can be shared and reviewed among a network of friends or coaches using the portal 110, and an athlete may use a shared exercise as their own. This sharing approach also applies to workouts (e.g. block 608).

[0111] Following the selection of a workout and the start of a set (block 619), metrics are computed (block 621) for each repetition of an exercise performed based on data wirelessly transmitted from a user sensor device to a mobile device. The computed metrics are further synchronized with the central server 103 (block 624) when a connection between the server and mobile device is available. If a connection cannot be established at any time during the workout, data will be communicated between the mobile device and the server 103 following the completion of the workout (block 622). In an example embodiment, data collection and processing are done in real time, and can be viewed by another party with privileged access to the data (e.g. access to the portal 110). For example a coach can review and analyze an athlete's progress within seconds of each repetition performed and provide live feedback through the mobile device 101.

[0112] At any point during a workout, content such as the type of exercise, the number of sets or weights can be edited (block 613) using the GUI.

[0113] Athletes alternate between starting and finishing sets until the workout is completed. A review of the workout history (623) and final workout analytics are presented. Such analytics may include the number of calories burned, set and total workout time, and power calculations per set. Following a workout review athletes can share the workout history (625) via a variety of social media platforms. Such platforms may include existing networks or a social network developed for the purposes of this mobile application. [0114] Figures 12a, 12b and 12c outline example executable instructions for a synchronization process between a mobile device 101 and a server 103, which can happen in any one of three ways. In Figure 12a, the mobile application is activated or opened (block 650), after which the mobile application determines if a wireless connection is available (651). If so, synchronization between the mobile device and the server will occur and, in an example embodiment, is maintained throughout the workout (blocks 652, 654 and 653). Two- way communication is established between the server and the mobile device.

[0115] If no connection was available during the workout, synchronization occurs following the completion of the workout (block 655), as shown in Figure 12b. The synchronization includes determining if a wireless connection is available (block 656), and if so, activating the synchronization (blocks 657, 659, 658).

[0116] Synchronization commands may also originate from the server 103. In Figure

12c, a coach or a fellow athlete edits a workout (block 660, which triggers a notification to be pushed to the mobile device (block 661). In doing so, the server also initiate synchronization with the mobile device. Such synchronization commands may be triggered by changes to, including but not limited to, workout instruction plans from coaches, athlete portal information, or updates in social feeds. When a wireless connection is available to the mobile device (block 662), a two-way synchronization occurs between the server and the mobile device (blocks 663, 664).

[0117] Figure 13a and Figure 13b provides examples of executable instructions that are performed by the mobile device to determine when a set, including the individual repetitions of the set, have been performed.

[0118] Figure 13a shows an embodiment in which the mobile device receives user input that indicates which exercise is going to be performed. In some cases, the user may provide input indicating when the exercise is going to begin. And in some cases, as in Figure 13a, the mobile device may detect when the user has begun a set of repetitions. At block 700, the mobile device receives a selection for an exercise. The characteristics of the exercise may be stored on the device or may be downloaded. When a user inputs his or her selection for the exercise, the mobile device is informed which exercise motions to expect from the user. Following this step, an analysis of the set data, obtained from the user sensor device 100, is used to detect a set (block 701). Further analysis of the data reveals the subsequent detection of each repetition (block 702) within a set. The mobile device then applies one or more algorithms to perform metric extraction (block 703). Using the extracted metrics, the mobile device may apply one or more algorithms to determine one or more recommendations (block 704). The mobile device may continuously monitor the data from the user sensor device to determine whether the user begins a new set (loop 705). That is, the mobile device may identify when the user performs a repetition that belongs to a new set. If a repetition is detected, then the mobile device has detected a new set, which causes the mobile device to again perform set detection (block 701). When no further sets are detected, the mobile device prepares one or more visualizations, suitable for display on a graphical user interface. The mobile device may generate and display the metric visualization (block 706), which may present the metric data, and the meaning of the metric data, in a concise and clear manner. Additionally or alternatively, the mobile device may generate and display a recommendation visualization (block 707) for presenting the recommendations associated with the set and the repetitions on a suitable display, which may facilitate user improvement.

[0119] Figure 13b shows an embodiment in which the mobile device determines which exercise the user is performing or has performed. In some embodiments, the mobile device may automatically detect when the user has begun a set of exercise repetitions. At block 700, the mobile device determines that the user is beginning an exercise, and determines which exercise the user is performing, based on characteristics of the exercise stored on the device. Following this step, an analysis of the set data, obtained from the user sensor device 100, is used to detect a set (block 701). Further analysis of the data reveals the subsequent detection of each repetition (block 702) within a set. The mobile device then applies one or more algorithms to perform metric extraction (block 703). Using the extracted metrics, the mobile device may apply one or more algorithms to determine one or more recommendations (block 704). The mobile device may continuously monitor the data received from the user sensor device to determine whether the user begins a repetition of a new set. But unlike Figure 13a, the mobile device of Figure 13b may determine which exercise is being performed (block 700) in the new set; so without informing the mobile device, the user may begin a new set of the same or different exercise, which may be useful when users do not wish to interrupt training to interact with the mobile device. If a repetition is detected (loop 705), then the mobile device may determine the exercise being performed (block 700), and proceed to set detection (block 701). When no further sets of exercises are detected, the mobile device prepares one or more visualizations, suitable for display on a graphical user interface. The mobile device may generate and display a metric visualization (block 706), which presents metric data, and the meaning of the metric data, in a concise and clear manner. Additionally or alternatively, the mobile device may generate and display a recommendation visualization (block 707) for presenting the recommendations associated with the exercises, sets, and/or repetitions on a suitable display.

[0120] Figure 14a provides an overview of executable instructions for data acquisition (750), sensor fusion (751), preprocessing (752) and data transformation (753) using values obtained from a user sensor device sent to a mobile device. Figure 14b provides an overview of an additional embodiment, which may perform similar steps for data acquisition (750) as Figure 14b, as well as additional or alternative instructions for sensor fusion (751b), preprocessing (752b), and data transformation (753b).

[0121] The operations of blocks 750, and 751 may be performed by the user sensor device, and the operations of blocks 752 and 753 may be performed by the mobile device. The IMU on the user sensor device determines acceleration and rotational velocity experienced by the sensor (blocks 754 and 755). For example, raw acceleration values are in units of G's (1G = 9.81 m/s) and raw gyroscope values are in degrees/second. Other data, such as the EMG data, is also measured.

[0122] Sensor Fusion 751 combines the low frequency changes in acceleration and high frequency changes in gyroscope values. Techniques used to combine these raw values include using known methods such as a Kalman filter, or other suitable complementary filter, and subsequently numerically integrating the resulting change in angle. At low frequencies, determining the effect of gravity on each axis of the accelerometer gives the orientation of the device. At high frequencies, the gyroscope values numerically integrated can accurately determine the angle of the device, given that the initial orientation is known. It can be appreciated that a combination of both the high and low frequency orientations provides a stable orientation (block 757) in both static and dynamic cases. As mentioned earlier, the gravity-compensated acceleration values (block 756) are in units of G's, with the positive Z axis pointing downwards. Therefore, the IMU component moving upwards away from the centre of the earth yields a negative acceleration value in the Z direction.

[0123] Similar to sensor fusion 751 of Figure 14a, sensor fusion 751b in Figure 14b, may perform the additional operation of determining an orientation of the sensor device by determining a vector representing a direction and scale, or quatemions (block 3001). In some cases, the quaternion is later converted into a matrix, such as a rotation matrix having data in the form of Euler's angles (i.e., degrees). A gravity-compensated acceleration may be determined in the form of G's, and based on a World coordinate frame (i.e., Z is down and lg = 9.81m/s).

[0124] Blocks 752 and 753, and blocks 752b and 753b illustrate techniques used in the algorithm to extract an individual repetition of an exercise from data obtained from the user sensor device in blocks 750 and 751 , and blocks 750 and 75 lb, respectively.

[0125] In both Figures 14a and 14b, data validation 758, 3005 performs a check on the data to ensure that faulty data is not generated. Blocks 758 and 3005 are performed on all linear acceleration axes and orientation data. For example data validation 758, 3005 ensures that all incoming acceleration and orientation data are not 0 or infinite. For instances where irregularities are captured, the athlete 157 would be notified. Similarly, data cleansing 759, 3007 removes recoverable errors such as outliers from a set of data. An example of an error is a time-stamped unit of data that exceeds five times the standard deviation of its neighbours. Such erroneous data may arise from transfer errors, but can be corrected in blocks 759 or 3007, by averaging the values of its neighbours and replacing the outlier with the calculated average. It can be appreciated that blocks 758, 759, 3005, and 3007 are not required for some embodiments, but may serve as useful tools to ensure data integrity.

[0126] Turning to Figure 14a, after the data is cleansed and validated, the operations in blocks 760, 761 and 762 are performed. Spline smoothing 760 fits a cubic smoothing spline to the primary acceleration axis, which is many use cases is the Z axis. A spline is a piecewise polynomial function with a high degree of smoothness at the places where the polynomial pieces connect. In an example embodiment, a low smoothing parameter is used to keep the signal from being too dampened. This method attempts to remove high frequency noise but also smooth's out low frequency components. Similarly, low-pass filtering 761 is applied to the primary acceleration axes. In an example embodiment a 5^th order Butterworth low pass filter between 20-30 Hz is used. It can be appreciated that other filtering techniques at different frequencies can also be used to generate desired results. One having skill in the art would appreciate that acceleration filtered to 25-30 Hz may closely replicate force plate data, which may be a useful guide for removing enough of the noisy signals to provide accuracy, while also keeping core signals. [0127] Set extraction 762 is an exercise dependent process that typically uses the orientation of the user sensor device to determine if an athlete is doing a set. For example, when the mobile device has determined or detected that the exercise is a bench press, the mobile device will expect the data to show that the orientation of the user sensor device is vertically oriented. This is because the user sensor device is to be positioned on the athlete's forearm during a bench press, and the athlete's arm and the user sensor device are both in a vertical orientation during the bench press exercise. In other words, depending on the selected exercise, the mobile device will apply a set of filters and analysis parameters that correspond to the selected exercise. The mobile device stores the filters and analysis parameters in association with various corresponding exercises in a memory device of the mobile device. It can be appreciated that set extraction 762 may be used to improve results obtained in numerical integration 763. It is known that accelerometers have inherent offsets causing drift in numerical integration, leading to non-linear results. Therefore if a set is accurately extracted, the orientation of the device stays mostly constant, meaning the integrated drift becomes linear.

[0128] Block 763 uses the trapezoidal method of numerical integration on the primary acceleration axis to give the velocity of an athlete. Due to the linear drift as discussed earlier, a linear de-trend is used to correct the velocity. This can include fitting a first order function (for example, a line) to the polynomial to compensate for linear drift.

[0129] It can be appreciated that blocks 760, 761, 762 and 763 may occur in various orders, for example according to the processes described in Figure 16a.

[0130] Turning to Figure 14b, after the data is cleansed 3007 and validated 3005, the operations in blocks 3009, 3011, 3013, and 3015 are performed.

[0131] As previously described, set extraction 3009 is exercise dependent, because each exercise has particular series of expected motions that are modeled by the orientation and acceleration detected by the sensor device. For example, when the mobile device has determined or detected that the exercise is a bench press, the mobile device will expect the data to show that the orientation of the user sensor device is vertically oriented. This is because the user sensor device is to be positioned on the athlete's forearm during a bench press, and the athlete's arm and the user sensor device are both in a vertical orientation during the bench press exercise. Set extraction 3009 may apply an advanced probabilistic method to adaptively find an accurate estimate of a threshold value for the orientation angles, in order to identify relevant set start and end points. Accelerometers of the sensor device may have inherent offsets, which cause drift in numerical integration performed in block 3015. The value of this offset changes with large orientation changes, which may cause the numerically- integrated drift to be non-linear. However, if the set is accurately extracted, the orientation of the device stays mostly constant (within 20-30 degrees), meaning the integrated drift may be treated as linear, which can be dealt with easier through various correcting measures.

[0132] Runtime calibration 3011 identifies and removes the accelerometers¹ bias error as data is collected from the user sensor device. As data is received from the sensor device, runtime calibration 3011 may allow the mobile device to detect a motionless period of the acceleration signals, by calculating, over periodic or rolling windows along the signal, a mean for acceleration signals, variations about the mean, and the standard deviation of the signal. An accelerometer's bias value may then be calculated as the mean value of the acceleration signals during a motionless period. Then, the acceleration signals may be calibrated by removing the bias error from the signals.

[0133] Signal filtering 3013, which occurs after set extraction 3009 in the embodiment of Figure 14b, may be applied to primary acceleration axis to remove noise in the signals. In many cases, the primary acceleration axis is the Z-axis, however for some specific exercises, the primary acceleration axis may be the X-axis or the Y-axis. One example of signal filtering 3013 in this embodiment, may include a high-order, Butterworth low-pass filter, using a 20-30 Hz filter, which may replicate Force Plate data; removing enough of the noisy signals to provide clearer data from the signals, but keeping the core signals such that useful data may be extracted.

[0134] Numerical integration 3015 may be performed using a trapezoidal method of the primary acceleration axis, in order to determine a velocity metric and a displacement metric of the user when performing the exercise. Numerical integration 3015 may occur between pre-determined "set begin" and "set end" time-points, identified during set extraction 3009. The trapezoidal method may employ damping during the integration, which may be used to compensate for the inherent drift in the velocity and displacement signals received from the user sensor device. In this embodiment, the velocity and the displacement are used to extract repetitions of the detected set during data transformation (block 753b). Moreover, numerical differentiation may be performed on the orientation angles in order to calculate angular velocities and accelerations, thereby calculating angular Kinematics, which may be used to extract repetition metrics during data transformation (block 753b).

[0135] Turning back to Figure 14a, data transformation 753 is the process of extracting repetitions from a set. A peak detection routine is used on numerically integrated velocity data obtained from 763. The velocity data is normalized to a zero mean and standard deviations are obtained. It can be appreciated that a normalized threshold base is independent of the speed at which the exercise is done. The peak detection algorithm at block 764 looks for local maximum and local minimum, referred to as a peak and a trough respectively. In the peak detection, the mobile device confirms that the distance between a peak and trough is at least two standard deviations apart.

[0136] Following the peak detection process at 764, a peak removal algorithm at block 765 is used to remove false peaks using knowledge about the exercise. For example, assume that a full repetition of an exercise lasts for a minimum of 500 milliseconds and a maximum of 4 seconds. If a peak is detected more than 4 seconds away from a trough, it is likely to be a false peak and therefore removed. In some implementations, each repetition may be expected to have exactly 1 peak and exactly 1 trough.

[0137] Following false peak removal is block 766, repetition detection. The algorithm recursively parses the data, searching for a peak-trough or trough-peak pair. Each pair signifies a single repetition. After the first repetition has been discovered, block 766 continues to search for the next pair in the chain of data. An adaptive repetition detection 766 algorithm may be implemented to automatically detect potential repetitions based on the signals from a numerical analysis step. Repetition detection 766 algorithm reviews signals for potential repetitions by recognizing a pattern of signal inputs that may identify a specific exercise. In some embodiments, the pattern of each repetition is constructed by various constraints on the structure of the repetition. That is, a particular exercise may be modeled by a pattern of expected signals or data received from the user sensor device.

[0138] Block 767 follows repetition detection and utilises the spline smoothed 767 data to determine the start and end of a repetition. Using the location of peak and trough pairs, the beginning of a repetition is determined to be the first zero crossing before the first peak or trough. The subsequent end of a repetition is the first zero crossing after the second peak or trough. Similar techniques can be employed to obtain the start and end of a set. The beginning of a set is refined to just before the beginning of the first peak or trough; the end of a set is refined to just after the end of the last peak or trough.

[0139] Repetition start and end detection is combined with the low pass filtered data to obtain repetition metric calculations 761. Metrics calculated may include and are not limited to, duration, peak acceleration, peak force, peak power, tempo and ground reaction force. Duration is measured by calculating the difference in time between the beginning and end of a repetition. Peak acceleration per repetition compares the low pass filtered acceleration data between the beginning and end of a repetition. Peak force per repetition is the peak force due to the effect of gravity on the system mass, influenced by the acceleration of the system mass by the athlete. System mass is defined as the combined masses of the athlete and the external load moved. For example, the system mass of a squatting athlete is the sum of the mass of the athlete and weight attached. However for bench press the system mass is the mass of the athlete's arms and weight attached. Peak velocity per repetition is similar to numerical integration described in block 763; the refined beginning and end of set data is used instead of the complete data set. Peak power per repetition is calculated by finding the maximum of the product of the force and velocity that occurs between the start and end of each repetition. Lastly, tempo is calculated by taking the average duration of each repetition within a set. For example, a bench pressing athlete performs 8 repetitions, with 17 seconds going up and 15 seconds going down. Therefore the tempo is calculated as 4 seconds per repetition.

[0140] Repetition validation 769 performs a check on the metrics calculated in block

768. Using pre-set and exercise specific conditions, repetitions containing metrics that are not humanly possible are excluded from the data set. For example, if the peak power during a bench press was 10 kW, which is not humanly possible by most standards, an error has occurred and therefore is not displayed.

[0141] Turning to Figure 14b, the mobile device may execute instructions for performing a data transformation 753b process for extracting repetitions and related data, from a detected set. Repetition detection 3017 may implement adaptive localized rep detection routines to detect one or more potential repetitions based on the signals and data from numerical analysis 3015. The repetition detection algorithm may identify potential repetitions by recognizing a pattern of the signal, which models a specific exercise. A pattern for each repetition is constructed using various constraints that model the signal structure of a given repetition. For example, the distance between different signal phases for a repetition is constrained within an expected model, based on a particular exercise. So, the flight time of jump exercises may have lower bounds on an associated signal structure, according to the type of the jump exercise expected to be performed.

[0142] In some embodiments, repetition refinement 3019 may be performed to increase the accuracy and precision at which potential repetitions are supposedly located on the signal; i.e., better metrics may be calculated when the locations at which repetitions are supposedly located are denoted with greater precision. Thus, it is preferable to identify the start and end of repetitions as closely as possible to each repetition's location. As such, the locations on a signal where repetitions are identified may be refined using a velocity signal nearby each of the repetitions. The locations are refined to be as close as possible to the start and end of a repetition by applying a triangularization method on the velocity signal, which may increase the accuracy and precision of identified repetition locations.

[0143] Repetition recognition 3021 determine where, on the signal, a repetition occurred. In some embodiments, repetition refinement 3019 may be used for more precise determinations during repetition recognition 3021. As an example of repetition recognition 3021, depending on whether the exercise begins with an upward motion (e.g., deadlift) or downward motion (e.g., squat), each peak point on the signal (found in 3017) is paired with one trough point (found in 3017). A combination of a peak and a trough represents a repetition. The mobile device may continue to find each next pair of peaks and trough, thus identifying each subsequent repetition of the detected set.

[0144] Repetition validation 3023 may identify false repetitions that were incorrectly identified during repetition recognition 3021. The signal structure of a full length of each of the detected repetitions is constrained by a lower bound and an upper bound, based on the pattern of the particular exercise being performed. By referencing this pattern expected for the exercise, repetition validation 3023 may then identify and then remove false repetitions escaping the upper and lower bound, over a threshold tolerance. For example, if a peak (a local maximum indicating the possible start of a repetition), is too far away or too close to an associated trough (a local minimum indicating the possible end of a repetition), the repetition validation 3023 may determine that the peak is a false peak, and is thus removed. The threshold for closeness and bounds is based on the pattern for the given exercise. In some cases, false repetitions are detected and removed based on discrepancies occurring within the associated signals, as compared to other legitimate repetitions.

[0145] Repetition phase deduction 3025 may be used to more accurately determine the locations of repetitions. Using the locations of each repetition, different phases of the repetition may be deducted so that the locations of the phases may be more accurately determined. As an example, for linear exercises (exercises where the motion is either upward or downward), the peak/trough points are used to determine the start and end points of the concentric and eccentric phases of the movement. But, for jump exercises (where motion is not strictly upward and downward), displacement, velocity, and acceleration signals are used to distinguish pushing and flight phases of each repetition. Repetition phase deduction 3025 may examine the area nearby each data point to find the start/end points of the repetition. In repetition phase refinement 3027, the locations of the start and end points of each repetition may be further refined, at each phase, using a triangularization technique to improve the accuracy of finding start and end points.

[0146] Repetition metric calculation 3029 may use the repetition phase beginning and end points for performing duration calculations (e.g. time in concentric, eccentric, isometric phases). For each repetition, the filtered acceleration (found in 3013) may be used to determine peak and average acceleration, between repetition beginning and repetition end. The peak and/or average accelerations are analyzed for both phases of the movement, i.e. concentric and eccentric. For some angular exercises (i.e., non-linear), the angular kinematics of the motion modeled by the signal may be transformed into a corresponding linear kinematics, in order to find a more accurate acceleration signal. In some cases, depending on the exercise being performed, the peak/average force for each repetition is determined as either peak/average ground reaction force (simulating a force plate), or as effective force. Ground reaction force is the force due to the effect of gravity on the system mass, influenced by the acceleration of the system mass by the user performing the exercise. Effective force is the force applied to the moving sections of the system. As previously described, the system mass is the combined effective mass of the user (exercise dependent) and the external load they are moving. For example, if the user is performing squats, almost the entire mass of the user is used and the external load (i.e. barbell); whereas for bench press or bicep curl, very little mass of the user is included, because the system mass is predominantly the barbell/dumbbell. Peak and average forces are analyzed for all phases of the motion associated with the signal. The peak and average velocity for each repetition may be calculated by performing the numerical integration/differentiation as in preprocessing methods described herein. The peak average velocities may be analyzed for all of phases of the motion. The peak/average power for each repetition is calculated by computing the mechanical power between repetition start and end. Peak/average powers are analyzed for all phases of the motion. Often, the peak force, peak velocity, and peak power are located at different points in time relative to the signal.

[0147] As previously mentioned, the mobile device may calculate tempo. Tempo is calculated as the timing of different phases of the movement for each repetition (e.g. tempo of a bench press = 3-1-1 [3 seconds down, 1 second hold down, 1 second up]). A repetition's total work is calculated by integrating the force-displacement or power-time profiles of each repetition. The force used for the calculation of work is the effective force applied to the system, which in some cases may differ from the ground reaction force depending on the exercise.

[0148] Repetition revalidation 3031 may be performed against the repetition metrics extracted from the repetitions (from 3029). The mobile device may identify irregular or impossible results from the extracted metrics for a repetition. For example, repetition revalidation 3031 may identify a repetition containing a metric that is not humanly possible, such as a user's peak power during a bench press being calculated as lOkW; or identify an irregularity based on other repetitions or expected patterns. Identified irregularities and impossibilities may be excluded from the metrics. Metrics are also passed through an adaptive similarity check based on the general performance of the athlete. If any of the reps is detected as being too dissimilar to other repetitions, the irregular repetition identified and removed from the metrics of the set. In some embodiments, this similarity check may be done iteratively for each repetition, until convergence.

[0149] A recommendation determination 3033 may be performed, in real-time mode providing real-time feedback. The recommendation may determine whether the user should terminate or continue a set that is in progress, based on the user's performance of each repetition of the set. The recommendation may be prepared and provided to the user through any number of interfaces (e.g., screen display, sound, haptic feedback). A number of factors may be used when determining a recommendation, such as the number of repetitions completed, average velocities of the finished repetitions, and the current set number for the exercise in the workout. In some embodiments, the recommendation determination may provide feedback for improving the user's performance, and protecting the user's safety, among others. Non-limiting examples of recommendations may include a load change, a number of repetitions to perform for a set, and termination of the exercise or workout, among others. Recommendation may be given while a repetition or set is in progress, but may also be provided after a set is completed.

[0150] An example of the order of operations for blocks 752 and 753, are shown in

Figure 15a and Figure 16a, respectively. Likewise, an example of the order of operations for blocks 752b and 753b, are shown in Figures 15b and 16b, respectively.

[0151] Turning to Figure 17a, shown is an example executable instructions illustrate the integration of machine learning (block 775) and subsequent decision fusion (776) with the above noted process. It can be appreciated that blocks 775 and 776 occur as intermediary steps between repetition detection (block 766) and repetition start end detection (block 767) within the Data Transformation process of Figure 16. Machine learning allows for the opportunity for continuous learning based on the athlete's workout characteristics. The subsequent decision fusion step ensures that results are valid and serves as a check for the machine learning.

[0152] In an example embodiment, machine learning 775 is a two-part process that occurs following 'Set extraction' (762) and may occur simultaneously when implementing blocks 763 to 766. Since the list of exercises are labelled within the mobile application, a variety of machine learning algorithms are executed using the linear acceleration axes (X, Y, Z) and the orientation axes (angles about X, Y, Z). Seven criteria (e.g. exercise name, acceleration axis data for each of the three axes, and the orientation data for each of the three axes) are used to 'train' the machine learning algorithm to determine the parameters to make real-time exercise detection possible. The machine learning process is further applied to aid the standard repetition process to provide more accurate results better adapted to the athlete's characteristics. Use of the machine learning algorithm results in a repetition detection process, which includes: (a) the standard repetition detection method is used as described in Figure 16; (b) the machine learning algorithm also attempts to determine if repetitions have occurred; and (c) a 'decision fusion' step, which takes the standard repetition detection and machine learning algorithm results as inputs, and generates a definitive 'answer' as to whether a repetition has actually occurred. Specific algorithms used for the machine learning process can include and are not limited to, support vector machine, conditional Markov random fields, and/or bag of features.

[0153] The decision fusion process of block 776 analyzes the two input parameters and produces a true or false result. If operations from both (a) and (b) generate a result that a repetition has occurred, the decision fusion operation (c) outputs that a repetition has indeed occurred. Conversely, if the operations from both (a) and (b) do not detect a repetition, the decision fusion operation (c) outputs that a repetition has not occurred. However, results are not as easily obtained if operations (a) and (b) provide conflicting information, whereby one method indicates the presence of a repetition while the other does not. In such situations, the confidence levels of (a) and (b) are evaluated where either "repetition has occurred" or "repetition has not occurred" is selected accordingly. For example, if the standard repetition detection algorithm produces 10% confidence level that a repetition has occurred, but the machine learning algorithm is 95% confident that a repetition has not occurred, then the latter is selected and the decision fusion outputs that a repetition has not occurred.

[0154] It can be appreciated that the algorithm and machine learning processes of the systems and methods described herein solve inefficiencies and resolve issues related to interpreting data from an accelerometer. An automatic method of tracking and recording repetitions reduces the level of user interaction between an athlete and a mobile device. Additionally, though not shown, the algorithms used following the collection of data are executed to provide advanced analytics to an athlete.

[0155] Although not shown, the EMG data could also be used to determine whether a repetition occurred. The EMG data is used to determine if the athlete's muscle is being strained in a certain way when performing a repetition, as opposed to a relaxed movement that does not cause the muscle to strain. This EMG data is factored into the decision fusion process 776.

[0156] Figure 17b shows an exemplary embodiment of executable instructions instructing a mobile device to perform machine learning 775 as a supplement to standard repetition detection 766 algorithm, followed by subsequent decision fusion 776 as in the above noted method embodiments. In such embodiments, a standard repetition detection 766 algorithm may be applied to data received from signals 780 received from a user sensor device to determine whether a repetition has occurred or not occurred. A machine learning algorithm 775 may also be applied to determine whether repetitions have occurred. The mobile device may then perform a decision fusion 776 operation, using the repetition detection 766 algorithm and the machine learning 775 algorithm as inputs. The decision fusion 776 may then generate a definitive 'answer' as to whether a repetition was performed. In other words, the decision fusion 776 may operate to verify the results of the repetition detection 776 and machine learning 775.

[0157] In this embodiment, the repetition detection 766 may be continuously trained and updated on a server promulgating updates to the repetition detection 766 to a mobile device. New parameters (i.e., variables updating the effectiveness of the machine language 775 algorithm) are uploaded to the mobile device as part of a synchronization process.

[0158] Figure 18 provides example executable instructions, performed by the mobile device, including the pre-workout steps executed using the GUI of the mobile application. At block 800, a GUI is presented for an athlete to sign in to the application. A further check of whether the athlete has a scheduled workout is performed; if not, then the GUI leads the athlete to create a workout (802). If yes, the selected workout is loaded (803). Block 804 provides an option to modify the workout, where no changes lead to block 806 to begin the workout. Otherwise, if changes are desired to be made, as detected by receiving a user input, the mobile device makes the modifications in block 805.

[0159] Figure 19 illustrates the login process of the mobile application. Following the opening of the application (850), the application checks whether the user has logged in before (851). If the response is negative and previous log-in credentials are not found, the GUI redirects the athlete to the login page (852). Block 853 determines if athlete has an account, and may prompt with the options to login using social media sites (855) or using an account password (860). In the event that an athlete forgets existing account credentials, the GUI presents a form (858) that accepts an email address (856), and a temporary password is sent to the athlete (857). Otherwise, the athlete may proceed to login (861) and the data is synchronized with a back-end server (859).

[0160] If the athlete opts to use a social media site, the GUI displays a login page

(855) and the athlete may enter social media credentials (864). If the athlete does not have an existing account, the GUI displays a registration page (862) for the athlete to create an account (863). Once the athlete enters the necessary information, a check is performed to determine if a corresponding account exists (865); this also occurs following block 864 leading to block 866. If an athlete attempting to create an account has previously logged on to the application, the GUI will redirect to the initial login page (852).

[0161] After a successful login at block 851 or 861, the GUI may load a start page

(867). Following checks for an existing account at block 865 or 866, if a matching account is not found, the GUI may prompt an athlete to enter personal data (868). Following data entry, the GUI proceeds to present an application tutorial (869) and checks for a user sensor device from which to synchronize data (870). If the application is unable to detect the device, the GUI presents the start page at block 867. If a user sensor device can be synchronized with the mobile device (870), the application proceeds to search (871) for said user sensor device. Upon discovery (872) and selection (873), a user sensor device is synchronized with a mobile device (874). The user sensor device is saved in the memory of the mobile device (875); subsequently, the GUI loads the start page at block 867.

[0162] Figure 20 is an example flow diagram of the settings page of the mobile application for the system and method described herein. Following a successful login process (900) described in Figure 21, the application GUI can further load a settings page (905). If an automatic synchronization between a user sensor device and a mobile device has not occurred or has failed, block 906 allows for manual synchronization. The application proceeds to search (907) for said user sensor device; upon discovery (908) and selection (909), a user sensor device is synchronized (910) with a mobile device. The user sensor device is saved in the memory of the mobile device (911); subsequently, the GUI reloads the settings page at block 905.

[0163] Similarly synchronization between a server and the mobile application can be pushed manually (902). Any athlete profile changes (903) such as weight, height and targets are also reflected in the server; both blocks proceed to the synchronization flow 904, described by Figure 36. Lastly, the GUI also allows for traversal from the settings page 905 to other pages, such as the main page or the profile page, using block 901.

[0164] Figure 21 illustrates the process of selecting a scheduled workout using the mobile application GUI. Following the successful login of an athlete at block 950, the GUI displays the schedule page (951), which contains a list of scheduled workouts created and pushed by a coach or trainer. The selection of a scheduled workout (952) proceeds to the workout flow (953) illustrated by Figure 23.

[0165] Figure 22 illustrates methods of selecting a workout using the mobile application GUI. Following the successful login of an athlete at block 1000, the GUI displays a list of exercises on the workout page (1003). It can be appreciated that the workouts can either be created by the user, or automatically uploaded from the server, or shared from a friend via the application's social network. Though not currently shown, custom workouts as developed by the athlete can also be added by combining exercises.

[0166] Block 1003 can lead to the favorite workout page (1001), or if a workout is selected (1004), to the workout flow of Figure 23 (1005). The workout page also allows for the filtering of workouts (1002). Filters are subsequently shown (1006) and selected (1008) before an updated list of workouts with said applied filters is displayed. Lastly searching through workouts (1007) is also possible, proceeded by filtering through workouts (1009) before an updated list of workouts with said applied filters is displayed.

[0167] Figure 23 illustrates example executable instructions performed by a mobile device for starting and completing a workout using the mobile application GUI. Following the successful selection of a workout, the GUI displays said selected workout (1052). If a set was recently finished (1057), the GUI allows for editing (1060) of previous set information

(1061) . Once editing is completed or if no editing was needed, the workout page 1052 is displayed. If there are no unfinished sets, modifications of the workout (1055) can be performed before proceeding to the modify workout flow of Figure 24 (1058). If there are unfinished sets (1056) in the workout, the athlete may start the set (1059) on the GUI. The live page and timer (1063) is subsequently displayed; if the user sensor device is connected

(1062) , data is collected and continuously communicated to the mobile device. From block 1063, the GUI also allows for the option to pause (1064) and further resume (1065) the timer. It can be appreciated that this functionality allows an athlete to temporarily rest or take a break during the set of a workout.

[0168] Following the completion of a set (1067), if a user sensor device is connected

(1070), metrics are calculated (1071) using the algorithms outlined in Figure 14. The GUI subsequently presents a review of the set with the rest timer and metrics shown (1069). If no sensor was connected the same review is presented by the GUI, except an additional advertisement for a user sensor device is shown (1068). Both blocks 1068 and 1069 proceed back to the main workout page 1052 of the GUI.

[0169] The GUI of the main workout page 1052 allows an athlete to modify a workout (1055), before proceeding to the modify workout flow shown of Figure 24. Block 1052 also allows an athlete to favorite, or conversely, un-favorite the workout for future easy access. Lastly, the selected workout page also extends to block 1053, which checks if a workout is finished or if the user wishes to quit. Block 1053 proceeds to the post-workout flow of Figure 37 (1054).

[0170] Figure 24 is an example of executable instructions performed by the mobile device to modify a workout page, using the modification page GUI, following the selection of a workout as previously described from Figure 23 (1100). If the workout is modifiable (1101) and the athlete wishes to edit said workout (1102), options to add, remove, swap or edit the exercise (1103) are presented by the GUI. If the workout is not modifiable or if no editing is desired, the GUI proceeds back to the workout page of Figure 23. Adding an exercise (1104) to the workout proceeds to show a list of exercises (1112) that can be filtered (1108) based on a variety of filter options (1109) presented by the GUI. After filters) are selected (1110), the list of exercises is updated (1111) and shown in the GUI of the mobile application. The selection of an exercise (1113) proceeding block 1112 allows the athlete to add the selected exercise to the workout (1114) and the GUI promptly returns the user to the beginning of the flow at block 1100.

[0171] The option to remove an exercise (1105) is also available from block 1103.

Following the removal of the exercise from the workout (1115), the GUI promptly returns the user to the beginning of the flow at block 1100.

[0172] Swapping an exercise (1106) prompts the GUI to show a list of similar exercises, (1116), which are evaluated based on pre-determined and pre-set characteristics known by the central server. The subsequent selection of a similar exercise (1117) updates the workout with said swapped exercise and the GUI promptly returns the user to the beginning of the flow at block 1100.

[0173] The option to edit an exercise (1107) is also available from block 1103.

Following the change of exercise characteristics such as the number of sets, weight or duration (1119) and subsequent update of the exercise list (1120) within the workout page, the GUI promptly returns the athlete to the beginning of the flow at block 1100. Through Figure 18 to Figure 24 it can therefore be seen that the mobile application envelops the functionality of the traditional pen and pad method that current athletes employ while adding additional functionality for ease of use.

[0174] Figure 25 is an example embodiment of the login page as demonstrated by block 852 in Figure 19. The GUI presents options to login using any one of a variety of options. Such options may include using a custom account with accompanying user name and password (elements 1150 and 1151), or through an existing Twitter (1152) or Facebook (1153) account.

[0175] Figure 26 is an example embodiment of the 'Favorite' page where a list of favorite workouts (1204) and exercises (1205) are presented. It can be appreciated that a favorite workout or exercise need not be selected by an athlete, but it may also represent most commonly finished. A large 'Go' button (element 1201) allows for quick start access. Within Figure 26 a 'Schedule' tab (1150) exists on the GUI, leading to Figure 27. 'Schedule' presents a list of scheduled workouts created by the user or pushed from a server by a coach. A list of upcoming dates (1251) with accompanying workouts (1252) is displayed by the GUT. Once again a large 'Go' button (1251) allows for quick start access. From both Figures 26 and 27 the GUI allows for quick access to the menu tab (1200) as seen in Figure 28, with a list of possible options shown (1300).

[0176] The selection of a workout from either Figure 26 or 27 leads to the workout settings page of Figure 29. A list of exercises is presented (1351) with a brief synopsis of the number of sets (1355) and the option to show additional details (1356) made possible. Along the menu bar the GUI allows for traversal back to the previous page (1350) or to provide workout details (1354) such as the muscle groups used. Within the screen the GUI also presents quick launch icons to access a calendar (1353), favorite workouts (1352) and to start the workout (1357).

[0177] Selecting the option 'Workouts' from the tab menu of Figure 28 leads to

Figure 30. A list of workouts (1402) that exist within the database of the central server is presented. The GUI allows for specific filtering techniques (1403) to be applied if the list of workouts, or if the name of the workout is known a quick search can be used (1401). Element 1400 opens the menu tab of Figure 28, while the selection of a workout leads to the start of said workout.

[0178] Figure 31 shows example executable instructions performed by the mobile device for starting a free form or impromptu workout. This is desirable when an athlete wishes to exercise without using a structured or pre-scheduled workout. Following a successful login (1450) from Figure 19, the free-flow page (1451) can be accessed from the GUI. A list of exercises is displayed (1452), along with filtering options for quick access to a specific exercise. Following the selection of an exercise (1453), the GUI displays options to input settings (1454), including but not limited to, name, weight, number of sets and number of repetitions. Once all required parameters are inputted, the free-from page continues to the workout flow of Figure 23 as shown by block 1455.

[0179] Figure 32 is an example depiction of the free-form page that was accessed through the tab menu of Figure 28. A list of prepopulated exercises (1500) is displayed with a similar filtering feature previously described in Figure 30. Following the selection of an exercise the GUI updates to the workout settings page of Figure 33. For the selected exercise the number of repetitions (1550) and weight (1552) must be inputted. Additional sets can be added using the plus button as shown by element 1551. A collapsible menu accessed through element 1553 hides additional details of the specific exercise.

[0180] Figure 34 is an example depiction of the GUI during an active workout. In this example embodiment the athlete has recently completed the first set of 'Barbell Bench Press'

(1600) and is resting with 1 minute and 45 seconds remaining (1602). The 'pause' button

(1601) allows for a stop of the timer while the 'stop' (1603) button promptly skips the remaining sets of an exercise.

[0181] Figure 35 is an example review page where metrics are presented to the athlete following the completion of a set. In this example the athlete has completed two sets out of three, as shown by element 1650, and is resting with 39 seconds remaining in the break (1657). New sets can always be added through the plus button of element 1655. The GUI presents metrics (1652) for a variety of parameters, including but not limited to force, velocity, and power, as shown by element 1651. Personal records are also recorded (1653) and compared to for quick analysis. Element 1657 allows for quick access to immediately start the exercise though break time remains, while element 1654 restarts the exercise. [0182] Figure 36 is a flow diagram outlining criteria for synchronization between a mobile device and a server within a separate thread of the mobile application. A thread is a sequence of instructions that can be scheduled for execution by the operating system. If an internet connection is available (1701), the mobile device initiates a call to a server to check for the most recent synchronization time (1702). If the server has new data available (1703) from a time more recent than block 1702, then said data is added to a mobile device (1704). Following the check for new data from the server is a check for modified data (1705); if the server has modified data to add, the mobile phone's local data is updated with the server modifications (1706). Following the check for modified data from the server is a check for new data from the mobile device (1707); if the mobile device has new data to add, the server is updated with the most recent data (1708). Following the check for new data from the mobile device is a check for modified data (1709); if the mobile device has modified data to add, the server is updated with said local data modifications (1710). After all four criteria are checked or if no internet connection was initially available, the synchronization thread within the mobile applications is killed (1711).

[0183] Figure 37 is a flow diagram outlining the processes that occur following the completion of a workout. Block 1750 is an extension of previous steps encountered in block 1051 of Figure 23. Once the workout is completed the data is uploaded and synced with the server (1751) as described in Figure 36. The GUI also shows a workout review page (1752) providing analytics and a history of exercises performed in the most recent session. An option to switch the page (1756) or to publicly disclose the workout history is available. Following an attempt to post the workout (1753) is a check for a social media account (1754). If an account is synchronized the post is updated (1757) and the GUI redirects the athlete back to the main workout page. If no account was available, the option to select an account is shown (1755), followed by the social media network's login page (1758). The post is then updated at block 1757 and the GUI redirects the athlete back to the main workout page.

[0184] Figure 38 depicts an example athlete profile page of the mobile application, specifically showing athlete statistics (1800). The social network component of the application is evident as shown by the number of athlete followers (1801) and athletes following (1806). A series of statistics demonstrating performance for a given exercise is shown on the GUI by element 1802, including but not limited to, power, volume load, velocity and balance. The GUI is robust to filter through all exercises the athlete has performed (1807). Achievements and progress are also shown (1803), along with quick access buttons on the GUI for settings (1804), a log to view a more detailed workout history (1805).

[0185] Figure 39 is a sample embodiment of the 'Feeds' page where social statuses of both the athlete and athletes on the social network (1851), are shown. In this example, time- stamped new personal bests (1850) of athlete's that are followed are displayed on the GUI. Supplementary information displayed through bar graphs (182) is used to provide a historical reference for the viewing athlete. It can be seen that changes in height of the bar graph demonstrate an increase or decrease of an output.

[0186] It can be appreciated that ability to record, log and further display collected data from a portable device surpasses functionality provided in prior art. Furthermore, though not shown, the capability of analyzing workouts resolves the issue of overexertion and fatigue. Algorithms are executed to recommend specific exercises and target weights to athletes to improve performance. Moreover technique correcting measures are communicated through the haptic feedback controller 208 to athletes new to weight lifting who are unsure of proper technique and exercising practices that protect athletes from physical injury.

[0187] It can also be appreciated that data uploaded to a central server establishes a communication system between athletes, coaches and other interested parties where workout information is conveniently archived. Historical data is automatically parlayed to coaches and trainers, who can further optimize routines to increase athlete performance. Furthermore, the social network system promotes participation and supports athlete competition.

[0188] Figure 40 is an example flow diagram illustrating the interactions of a trainer with a portal management system that aids in monitoring the progress of one or more athletes. The example executable instructions are performed by a computing device that can connect with the portal 110. The system begins by opening the portal (1900). First, the GUI presents a login page (1903) and, upon logging in, the trainer is able to view a list of workouts (1901), a team dashboard (1902), an athlete dashboard (1904), a test dashboard (1905), and a plan dashboard (1906).

[0189] From block 1901, the trainer may select a particular workout (1907) to duplicate (1918), edit (1919), add exercises (1920) or remove exercises (1921). Once changes have been made, the trainer may assign the workout to one or more of the listed athletes (1923).

[0190] From block 1902, the GUI provides the trainer with options to select a team

(1908), edit a team (1909), or create a new team (1910). Upon selecting a team, the GUI allows for the selection of an athlete from said team (1921) in order to view the athlete's personal information and historical summary (1924). From block 1924, quick access is provided to the workout page (1901) or to continue to view detailed exercise statistics (1928). Additionally, upon creating a new team, athletes can be added (1922) to said new team.

[0191] Following block 1904, the GUI allows a trainer to select an athlete (1911) to again view the athlete's information and progress summary (1924). The GUI also has search capabilities (1912) for inviting and adding athletes (1925) to a trainer's network of teams.

[0192] When arriving at the test dashboard (1905), the GUI allows for the selection

(1915) or to edit a specific test (1913), or to create a new test (1914) to best observe an athlete's abilities at any point in time. Upon finalizing a test, the GUI shares the upcoming test with the said athlete (1926).

[0193] From block 1906, the GUI permits the trainer to search for (1916) or create a periodization plan (1917). The GUI again assigns a finalized plan to a particular athlete (1927) as requested by a trainer.

[0194] Figure 41 shows example executable instructions performed by a computing device that is in communication with the portal 110. The instructions describe in further detail the procedure for logging into the portal mentioned in Figure 40. The process is initiated by opening the portal (1950). The application then verifies if a trainer can log in to the application (1952). If the trainer is provided with the proper credentials, access is granted to a dashboard (1951). Otherwise, continuing with block 1953, the GUI presents a login page with options to login with an application account (1956) or with social media credentials (1954).

[0195] From block 1956, the trainer may enter credentials for a registered account. If the user correctly enters the password, the user is able to login to the account (1959) and the GUI redirects to the dashboard (1951). If the user forgets the account password (1960), the GUI retrieves the forgotten password form (1962). The GUI accepts an email address (1965) and sends a temporary password to the trainer by email (1966).

[0196] From block 1954, if social media credentials are used to login, the GUI presents the specified login page (1955). Appropriate credentials are entered to login (1958) and the system will search for a corresponding existing account (1964). If a matching account is found, the GUI redirects to a dashboard (1951). If a matching account is not found, a prompt to enter personal data to create the corresponding social media account is presented (1967); the GUI then proceeds to the dashboard (1951).

[0197] Following block 1954, in the event the trainer does not select a particular social media account, the GUI may present an account registration page (1957). The trainer may attempt to create an account (1961) and the application will check for matching, existing account information. If the information matches, the GUI will redirect to the original login page (1953). If the entered registration information is unmatched, an account is created and the GUI prompts the trainer for additional personal data. The GUI subsequently redirects to the dashboard (1951).

[0198] Figure 42 displays example executable instructions by which a trainer can present a periodization plan to an athlete. The process begins with block 2000, which includes the login procedures described in Figure 41. Next, the GUI displays the plan page (2001). The trainer then uses the plan page to input a workout strategy for one or more athletes (2002). At block 2003, the GUI presents the trainer with the ability to enter training phase information. The capability to search for and add workouts to each training phase (2004) is provided by the application. Finally, the plan is assigned to a team or one or more athletes (2005). The GUI also provides the trainer with the option to change pages (2006).

[0199] Figure 43 is an example flow diagram of the team dashboard where trainers gain access to select, edit and create new teams. Block 2050 incorporates the login procedures as previously described in Figure 41. The GUI proceeds to the team tab (2052), where if a team does not yet exist, the flow continues to block 2055 to create a new team. Otherwise, the possibility to add a team is shown; if the desired team does not exist, the flow continues to block 2055 to create a new team. If the desired team does exist, the flow continues to block 2054 where the team is selected. [0200] Following block 2055, the GUI prompts the trainer to fill in team information

(2058). Multiple athletes or individual athletes can then be added at once (2061). If an individual athlete is added (2067), the GUI prompts to fill in athlete information (2071) before returning to block 2067, or, if editing is completed (2077), to switch pages (2076). If athletes are to be added in a batch (2063), the application allows for a CSV (comma separated value) file to be uploaded; if no CSV file exists then the flow proceeds to block 2067. If the corresponding file exists, athletes can be imported (2068) before proceeding to block 2077.

[0201] At block 2053, if the desired team was previously created, the flow proceeds to the selected team (2054). The team dashboard is then shown (2056), and the GUI proceeds to allow for the editing of an existing team (2059) or to select an athlete from the list (2057). The latter proceeds to the athlete dashboard (2060), as shown in Figure 45. If the editing of the team is desired in block 2059, the GUI allows for adding, editing or removing athletes within the team (2065) or to edit or remove the team entirely (2066). If the latter is selected, the option to remove (2070) and further removing the team (2074) or to edit (2075) and further editing team information (2080) is available, both of which proceed to check if editing is completed (2077) before switching pages (2076). Meanwhile if the former is selected to proceed to block 2065, the GUI allows for three additional alternatives; add one or multiple athletes (2069), remove athletes (2072) or edit athletes (2073). Block 2069 proceeds to block 2061 to add athletes, while 2072 provides the option to remove an athlete from the team (2078) and block 2063 allows for editing of athlete information (2079). Both 2078 and 2079 proceeds to block 2077 to check if editing is completed.

[0202] It can be appreciated that the team dashboard allows a trainer to quickly and efficiently view historical data of athletes. The robust dashboard serves as an organizer for trainers and also provides the flexibility to edit team credentials and to update team information. Though not shown, the team dashboard provides summaries to trainers for quick access to recent workouts performed by athletes.

[0203] Figure 44 demonstrates example executable instructions by which performance tests can be created and assigned to one or more athletes. First, block 2100 incorporates the entire login process as previously shown in Figure 41. Next, the GUI opens the test dashboard (2101). From here, the GUI permits changing pages (2012) or to retrieving past tests (2104). By staying on the test dashboard page, the trainer may select an existing test (2107) or create a new test (2108). [0204] Following block 2107 whereby an existing test is selected, the GUI allows a trainer to edit a test (2106), view test results (2109), or add the test to a schedule (2110). Having selected the edit function at block 2106, the trainer may alter the test as necessary (2103). If the trainer elects to view test results, the trainer may view comprehensive statistics by clicking on results (2112). At block 2115, the GUI will present the trainer with a visual comparison of historic test data for all tested athletes. If the trainer opts to schedule a test from block 2110, the GUI will display the schedule section (2113); a trainer will be able to set start and end times for the test (2116) and assign said test to specified teams or athletes (2118). The GUI then redirects to show the test dashboard (2101).

[0205] From block 2105, if the creation of a new test is selected, the GUI will display the page for creating tests (2108). A trainer can then enter test specifications and requirements which will be accepted by the GUI (2111). From here, the test may be scheduled (2110). Else, the trainer may choose to simply save the test record (2114), and the application stores the entered test information (2117). Finally, the GUI redirects to show the test dashboard (2101).

[0206] Figure 45 is an example flow diagram of the athlete dashboard where athlete information can be updated or added. Block 2150 incorporates the login procedures as described in Figure 41 before proceeding to block 2151, where a check of existing athletes is made. If athletes do not exist, a search is conducted (2156) to add new athletes. If athletes exist, the GUI proceeds to the athlete dashboard (2152) where specific athletes can be selected (2153), or athletes can be added (2154) by a trainer. The former proceeds to show athlete information and a summary of workout history (2155). Block 2155 allows for the selection of test results (2159), the further results of the tests the athlete completed (2163) and subsequently hiding the list (2168) before the GUI is returned to the athlete information and summary page of block 2155. Block 2155 can also proceed to check if a periodization plan has been created (2158). If a periodization exists, a review is presented (2162) by the GUI; if updates are required the application proceeds to the update periodization plan page (2170), otherwise returning to block 2155. If no periodization exists, a plan can be added (2157) which proceeds to the workout flow described in Figure 46 (2169).

[0207] The application GUI allows for the selection of a previous exercise performed by the athlete (2161) from the athlete information and summary page of block 2155. The athlete page is subsequently updated with the selected exercise (2166) before returning to block 2155.

[0208] From the athlete dashboard of block 2152, the application allows for new athletes to be added to the existing athlete's social network. Therefore if an athlete is wished to be added (2154) the GUI prompts for a search for said athlete (2156). If the athlete does not exist (2160) within the application database, an invitation to join is sent via email (2164); otherwise an in-application invitation is sent (2165).

[0209] Figure 46 is an example flow diagram of the workout dashboard where trainers can create, edit or remove workouts before being assigned to athletes. Block 2200 incorporates the login procedures as described in Figure 41 before proceeding to the workout dashboard (2202). The application GUI allows for switching pages (2201) or searching for workouts (2203), where the latter either leads to using a search bar (2206) before selecting a workout (2205), or selecting a workout directly. Once a workout is selected at block 2205, workouts can be added (2208), edited (2209), duplicated (2210) or deleted (2211). If the latter is selected, the workout is deleted (2217) before returning to the workout page of block 2202.

[0210] At block 2210, the workout name is edited (2216) before specific exercises and workout information is shown (2215). It can be appreciated that block 2209 also leads to 2215. Both blocks 2215 and 2208 lead to a check if the workout name should be edited (2214); if yes then the name can be updated (2219) before both options proceed to the add exercise option of block 2211. If exercises wish to be added, the GUI allows for a search of exercises (2223) before exercises are added to the specified workout (2224). Exercise information can be updated (2225) before returning to block 2221. If no exercises wish to be added, a further check of whether all editing is done is made at block 2204. If editing is not finished, the GUI redirects the trainer to the main workout dashboard of block 2202. Otherwise, an option to save and schedule the workout is presented (2207). It can be appreciated that saving the workout (2212) allows for quick access to viewing and assigning said workout for future reference without having to recreate the workout again. Scheduling a workout (2213) leads to the show schedule section (2218) presented by the GUI before specifying the start and end dates for the workout (2220). The workout is subsequently assigned to one or more athletes or teams before the application is returned to the workout page of block 2202. [0211] Figure 47 is an example depiction of the Plan dashboard as shown by block

1906 of Figure 40. In this embodiment a chart with weeks of a month are shown in element 2250, detailing the time available until competition, as shown in orange. Element 2251 of the GUI allows a trainer to add new exercises to a periodization plan. In this example periodization plan, Olympic Lifts are the exercises to be performed. At the bottom of the page, the plus button as shown by element 2252 allows for new periodization plans to be added. In this example Strength, Power, Speed and Rugby are all different periodization plans. Element 2253 specifies which day of the weeks the exercises is to be performed. Additional details, including but not limited to, time, duration and percentage of one rep maximum can also be included to the periodization plan.

[0212] Figure 48 is an example embodiment of the team dashboard as shown by block 1902 of Figure 40. A list of athletes within the team 'Oakville Phantoms' is shown, along with information and a brief summary of statistics. Different teams can be selected using the menu on the right, as shown by element 2304. Element 2303 shows a snapshot of recent activity relating to Power. The orange line graph may show activity within a recent period of time, while the numbers situated above may show personal bests or recent achievements. Element 2300 of the GUI allows for quick filtering to show a subset of listed athletes based on the filtering criteria. Element 2301 provides an overview of sample statistics relating to the team. Moreover element 2302 shows recent activity of workouts performed by athletes within the team. It can be appreciated that these elements are only samples of potential information that could be presented on the team dashboard.

[0213] Figure 49 is an example embodiment of the athlete dashboard as shown by block 1904 of Figure 40. All athletes are shown in this dashboard, with the ability to select individual athletes, as shown in element 2350, to proceed to view specific athlete statistics. Element 2351 allows for quick searching of athletes based on varying search criteria.

[0214] Figure 50 is an example embodiment of the athlete statistics page after selection of an athlete in Figure 49. Element 2400 of the GUI shows a graph of recent activity for a test performed by the athlete. The orange and white lines represent data obtained from the individual athlete and the team average. It can be appreciated that this quick comparison shows how the athlete is progressing compared to peers. Element 2401 is an example container for athlete information that is managed by trainers, where details including but not limited to name, team, age, weight, and most recent session are shown. Element 2402 illustrates details regarding most recent workout information. In this embodiment, the force exerted is shown for three exercises: power cleans, bench press and back squat. It can be appreciated that the peak force is highlighted in orange for ease of viewing.

[0215] Figure 51 is an example embodiment of the test dashboard as shown by block

1905 of Figure 40. A list of tests is shown in element 2450, with varying criteria included. Such criteria may include, but are not limited to, the last time a test was conducted, the type of test, and results. Element 2451 shows the 'Bad' column of test results, where the worst result of the test is displayed. Element 2452 shows a button within the GUI that allows for the creation of new tests. Though not shown, selecting a test may load a pop-up window on the GUI to allow for said test to be assigned and scheduled to one or more athletes.

[0216] Figure 52 is an example embodiment of the workout dashboard as shown by block 1901 of Figure 40. Element 2500 allows for quick filtering of workouts previously made by a trainer. Element 2501 provides a list of exercises contained within the workout. In this example, the workout 'Strength Total Body' is viewed with the exercises Back Squat, Bench Press and Bent Over Rows included. Element 2502 contains an 'Add New' button on the GUI where trainers can add new exercises to the workout. Similarly, element 2503 provides a quick overview of exercises contained within the workout. Element 2505 represents specifications of the workout, where details such as the number of sets, repetitions and the percentage of maximum load are shown.

[0217] It can be appreciated that the portal facilitates immediate access for trainers to review athlete workout data in a clear and concise manner. Now, the trainer need not manually input workout data, such as the number of repetitions performed and weight used. Furthermore, advanced analytics are now available to trainers. It can therefore be seen that more detailed conclusions can be obtained with regards to fatigue or overexertion that may lead to injuries. The real time and live updates obtained from the user sensor device that is further visualised on the GUI of the portal solves challenges previously shown in prior art.

[0218] The schematics and block diagrams used herein are just for example. Different configurations and names of components can be used. For instance, components and modules can be added, deleted, modified or arranged with differing connections without departing from the spirit of the invention or inventions. [0219] The steps or operations in the flow charts and diagrams described herein are just for example. There may be many variations to these steps or operations without departing from the spirit of the invention or inventions. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified.

[0220] The functionality described herein can be implemented by numerous modules or components that can perform one or multiple functions. Each module or component can be executed by a computer, such as a server, having a non-transitory computer-readable medium and processor. In one alternative, multiple computers may be necessary to implement the functionality of one module or component.

[0221] Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "transmitting" or "determining" or "authenticating" or "selecting" or "displaying" or "identifying" or "verifying" or the like, can refer to the action and processes of a data processing system, or similar electronic device, that manipulates and transforms data represented as physical (electronic) quantities within the system's registers and memories into other data similarly represented as physical quantities within the system's memories or registers or other such information storage, transmission or display devices.

[0222] The exemplary embodiments can relate to an apparatus for performing one or more of the functions described herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a machine (e.g. computer) readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs and magnetic-optical disks, read only memories (ROMs), random access memories (RAMs) erasable programmable ROMs (EPROMs), electrically erasable programmable ROMs (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a bus.

[0223] The exemplary embodiments described herein are described as software executed on at least one server, though it is understood that embodiments can be configured in other ways and retain functionality. The embodiments can be implemented on known devices such as a personal computer, a special purpose computer, cellular telephone, personal digital assistant ("PDA"), a digital camera, a digital tablet, an electronic gaming system, a programmed microprocessor or microcontroller and peripheral integrated circuit element(s), and ASIC or other integrated circuit, a digital signal processor, a hard-wired electronic or logic circuit such as a discrete element circuit, a programmable logic device such as a PLD, PLA, FPGA, PAL, or the like. In general, any device capable of implementing the processes described herein can be used to implement the systems and techniques according to this invention.

[0224] It is to be appreciated that the various components of the technology can be located at distant portions of a distributed network and/or the Internet, or within a dedicated secure, unsecured and or encrypted system. Thus, it should be appreciated that the components of the system can be combined into one or more devices or co-located on a particular node of a distributed network, such as a telecommunications network. As will be appreciated from the description, and for reasons of computational efficiency, the components of the system can be arranged at any location within a distributed network without affecting the operation of the system. Moreover, the components could be embedded in a dedicated machine.

[0225] Furthermore, it should be appreciated that the various links connecting the elements can be wired or wireless links, or any combination thereof, or any other known or later developed elements) that is capable of supplying and/or communicating data to and from the connected elements. The term module as used herein can refer to any known or later developed hardware, software, firmware, or combination thereof that is capable of performing the functionality associated with that element. The terms determine, calculate and compute, and variations thereof, as used herein are used interchangeably and include any type of methodology, process, mathematical operation or technique.

[0226] The embodiments described above are intended to be exemplary. One skilled in the art recognizes that there are numerous alternative components and embodiments that may be substituted for or included in the particular examples described herein and such additions or substitutions still fall within the scope of the invention.

[0227] It will be appreciated that the particular embodiments shown in the figures and described above are for illustrative purposes only and many other variations can be used according to the principles described. Although the above has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art as outlined in the appended claims.

Claims

CLAIMS What is claimed is:

1. A processor-implemented method comprising:

wirelessly connecting, by a mobile device comprising a processor, to a sensor device comprising a motion-measurement unit capturing motion data and a musculature-measurement unit capturing biometric data;

receiving, by the mobile device, one or more user inputs from a user interface of the mobile device;

receiving, by the mobile device, motion data and biometric data from the sensor device; identifying, by the mobile device, a first repetition of an exercise being performed by a user according to at least one of the motion data, the biometric data, and the one or more user inputs; and

responsive to identifying the first repetition of the exercise:

analyzing, by the mobile device, the biometric data and motion data in view of the identified exercise.

2. The method according to claim 1, further comprising identifying, by the mobile device, a next repetition in a set of one or more repetitions of the exercise being performed by the user, wherein each successive next repetition identified by the mobile device is in the set of one or more repetitions.

3. The method according to claim 2, wherein identifying each respective repetition further comprises:

determining, by the mobile device, a displacement of the sensor device based on a velocity of the sensor device and an acceleration of the sensor device, wherein the motion data for the repetition comprises the velocity, the acceleration, and the displacement.

4. The method according to claim 3, wherein identifying each respective repetition in the set further comprises:

receiving, by the mobile device, a user input indicating the exercise being performed; and comparing, by the mobile device, a motion pattern associated with the exercise against the motion data received from the sensor device, wherein the motion pattern defines a baseline expected for the motion data associated with each repetition for the exercise.

5. The method according to claim 4, wherein identifying each respective repetition in the set further comprises:

identifying, by the mobile device, a start of the repetition and an end of the repetition based on the motion data associated with the repetition and the pattern of motion expected for the exercise.

6. The method according to claim 4, further comprising identifying, by the mobile device, at least one repetition as a false repetition upon comparing the motion data of the one or more repetitions in the set for the exercise against the motion profile associated with the exercise.

7. The method according to claim 1 , wherein the motion data is selected from the group consisting of: acceleration of the sensor device, velocity of the sensor device, a displacement of the sensor device, change in acceleration of the sensor device, change in velocity of the sensor device, an orientation angle of the sensor device, duration between the repetition start and the repetition end, peak acceleration, peak force, peak power, average acceleration, average force, average power, tempo, and ground reaction force.

8. The method according to claim 1, further comprising determining, by the mobile device, whether a drift exceeds a drift threshold associated with the sensor device capturing the motion data for the set of repetitions,

wherein the drift of the set is based on one or more value offsets identified for each repetition of the set.

9. The method according to claim 1, further comprising, responsive to the mobile device identifying the first repetition of a set of one or more repetitions:

continuously receiving, by the mobile device, motion data and biometric data from the sensor device associated with each respective repetition in the set of repetitions being performed by the user.

10. The method according to claim 9, further comprising automatically identifying, by the mobile device, a final repetition for the set of repetitions being completed by the user based upon the motion data and the biometric data.

11. The method according to claim 1, wherein identifying the first repetition further comprises:

receiving, by the mobile device, from an interface of the mobile device a user input indicating commencement of the first repetition.

12. The method according to claim 1 , further comprising:

checking, by mobile device, the motion data associated with a set of one or more repetitions, wherein the motion data comprises acceleration data and orientation data; and

identifying, by the mobile device, an irregularity in the motion data based on the acceleration data and the orientation data.

13. The method according to claim 12, further comprising automatically generating, by the mobile device, a notification indicating the irregularity upon identifying the irregularity.

14. The method according to claim 13, further comprising replacing, by the mobile device, the irregularity in the motion data associated with the set of repetitions with an average value calculated by the mobile device.

15. The method according to claim 1, further comprising:

generating, by the mobile device, a haptic feedback based on a performance by a user of the one or more repetitions; and

transmitting, by the mobile device, to the sensor device the haptic feedback indicating the performance by the user.

16. The method according to claim 15, wherein the performance indicated by the haptic feedback is selected from the group consisting of: completing a repetition, completing a set, completing a workout, improperly performing a repetition, and deviating from a range expected motion for an exercise.

17. The method according to claim 1, further comprising transmitting, by the mobile device, to a server device storing exercise data of one or more users the motion data and the biometnc data for each repetition in the set for the exercise.

18. A mobile device for monitoring exercise information, the mobile device comprising: a wireless interface component configured to communicate wirelessly with a user sensor device and receiving inertial measurement data for a motion performed by a user from the user sensor device;

a display screen configured to display a user interface, receive one or more user inputs, and display a number of repetitions identified; and

a processor configured to compare the inertial measurement data against a motion profile of an exercise selected by a user input, and identify one or more repetitions of the exercise performed by the user based on the selected exercise and the inertial measurement data.

19. The device according to claim 18,

wherein the wireless interface component is further configured to communicate with a server storing a profile of the user containing historical data associated with one or more exercises performed by the user, and

wherein the processor is further configured to determine whether the profile of the user contains the inertial measurement data, and update the profile in response to determining the inertial measurement data is not stored in the profile.

20. The device according to claim 18, wherein the wireless interface component is further configured to identify a wireless ID transmitted from the sensor device, and initiate the communication with the sensor device upon associating with the wireless ID.

21. The device according to claim 18,

wherein the wireless interface component is further configured to receive from the user sensor device biometric data of the user associated with the repetition being performed; and wherein the processor is further configured to determine a musculature state of the user based on the biometric data from the sensor device, and identify the repetition based on the biometric data and the motion data.

22. A processor-implemented method capturing motion and biometric data comprising: capturing, by a sensor device attached to a user, motion data for a repetition performed by the user, the motion data containing acceleration data and orientation data;

capturing, by the sensor device, biometric data from the user performing the repetition of an exercise;

transmitting, by the sensor device, the motion data for the repetition and the biometric data for the repetition to a mobile device; and

generating, by the sensor device, a haptic response based on an indicator received from the mobile device.

23. The method according to claim 22, wherein the motion data for the repetition comprises a velocity of movement, an acceleration of movement, and a displacement of movement.

24. The method according to claim 22, further comprising:

detecting, by the sensor device, a start of the repetition based on the motion data and the biometric data for the repetition, wherein the sensor device begins transmitting the motion data and the biometric data to the mobile device upon detecting the start of the repetition; and

detecting, by the sensor device, an end of the repetition based on the motion data and the biometric data for the repetition.

25. The method according to claim 22, further comprising:

receiving, by the sensor device, from a touch-sensitive interface a first input to start the repetition, wherein the sensor device begins transmitting the motion data and the biometric data to the mobile device upon receiving the first input; and

receiving, by the sensor device, from the touch-sensitive interface a second input to end the repetition.

26. The method according to claim 22, further comprising:

capturing, by the sensor device, motion data and biometric data associated with a next repetition; and

continuously transmitting, by the sensor device, motion data and biometric data associated with each next repetition in a set of one or more repetitions.

27. The method according to claim 22, further comprising automatically detecting, by the sensor device, a strain on a muscle of the user based on the biometric data.

28. The method according to claim 22, wherein the indicator indicates the user has completed a predetermined number of repetitions for the set of one or more repetitions.

29. The method according to claim 22, wherein the indicator indicates the user has improperly performed the repetition.

30. The method according to claim 22, wherein the indicator indicates the user has completed a set of one or more repetitions and at least one of the repetitions was improperly performed.

31. The method according to claim 22, further comprising calibrating, by the sensor device, an inertial measurement unit of the sensor device in accordance with one or more gravity vectors, wherein the inertial measurement unit of the sensor device collects the motion data associated with the repetition.

32. A user sensor device for measuring exercise information, the user sensor device configured to be attached to an athlete's body, the user sensor device comprising:

an inertial measurement unit configured to measure acceleration of the sensor device and orientation of the sensor device about X, Y, and Z axes;

an electromyography (EMG) sensor forming at least part of an outer surface of the user sensor device and positioned on the user sensor device such that the EMG sensor touches the athlete's body when the user sensor device is attached to the athlete's body, and configured to measure biometric data associated with the athlete's body;

a processor configured to calibrate the inertial measurement unit based on one or more gravity vectors, and determines a beginning of a repetition of an exercised performed by the athlete based on the acceleration and the orientation of the sensor device;

a wireless communication device configured to transmit data obtained from the inertial measurement unit and the EMG sensor; and

a haptic feedback generator configured to generate a haptic feedback in response to instructions received from the processor, the processor receiving haptic feedback instructions from the mobile device.

33. The device according to claim 32, wherein the inertial measurement unit further measures a velocity based on one or more acceleration measurements.

34. The device according to claim 32, wherein the processor is further configured to detect an end of the repetition based on the data obtained from the inertial measurement unit and the EMG sensor.

35. A computer-implemented method for managing exercise data, the method comprising: transmitting, by a computer, a machine-readable computer file containing a workout to a mobile device associated with a user, wherein the workout comprises one or more exercises to be performed and a motion pattern associated with each respective exercise;

receiving, by the computer, from the mobile device exercise data associated with each respective exercise of the workout, wherein the exercise data contains repetition data associated with each respective repetition of the exercise;

storing, by the computer, in a non-transitory memory the exercise data in a workout record associated with the user; and

generating, by the computer, a profile page of the user based on the workout record of the user, wherein the profile page displays exercise data for one or more workout records of the user.

36. The method according to claim 35, further comprising obtaining, by the computer, the workout from a non-transitory memory storing one or more workouts.

37. The method according to claim 35, further comprising transmitting, by the computer, a profile page of the user to the mobile device of the user.

38. The method according to claim 35, further comprising transmitting, by the computer, the profile page to one or more computing devices communicatively coupled to the computer over a network.

39. The method according to claim 35, wherein the mobile device obtains the repetition data from a sensor device comprising an inertial measurement unit in communication with the mobile device.

40. The method according to claim 35, further comprising:

receiving, by the computer, an update to the workout from a computing device; and updating, by the computer, the work according to the update, wherein the one or more exercises are changed based on the update.

41. The method according to claim 35, further comprising:

identifying, by the computer, an exercise improperly performed by the user according to a comparison of the exercise data of one or more records against the motion pattern associated with the exercise improperly performed; and

identifying, by the computer, a corrective measure for the exercise improperly performed by the user based on the motion pattern.

42. The method according to claim 41 , further comprising transmitting, by the computer, the corrective measure to the mobile device.

43. The method according to claim 41 , further comprising generating, by the computer, a page displaying the corrective measure, wherein the computer transmits the page displaying the corrective measure to the mobile device.

44. A system comprising:

a sensor device comprising an inertial measurement unit configured to capture motion data of a user, an electromyography sensor configured to capture biometric data of the user, and a wireless communication interface configured to communicate with a mobile device;

a mobile device comprising a wireless communication interface configured to receive motion data and biometric data received from the sensor device, and a processor configured to identify a start of a repetition based on the motion data associated with one or more repetitions of one or more sets of an exercise performed by the user; and

a server computer comprising a networking interface configured to receive the workout data from the mobile device, and a non-transitory storage medium configured to store the workout data in a record of the user, wherein the workout data comprises the motion data and biometric data for each respective repetition in the one or more sets of the exercise.

45. The system according to claim 44,

wherein the server further transmits a workout plan to the mobile device containing one or more exercises to be performed by the user, each respective exercise being associated with a motion pattern of expected motion, and

wherein the mobile device further identifies one or more repetitions of the exercise being performed by the user based on the motion pattern associated with the exercise.

46. The system according to claim 45,

wherein the mobile device further compares the motion pattern of the exercise against the one or more repetitions performed by the user, and transmitting a haptic feedback message to the sensor device based on the comparison, and

wherein the sensor device further comprises a haptic feedback generator providing haptic feedback in response to receiving the haptic feedback message from the mobile device.

47. The system according to claim 46,

wherein the server further generates one or more pages containing the workout data of the user; and

wherein the mobile device further accesses the one or more pages and displays the workout data on a user interface.

48. The system according to claim 44,

wherein the sensor device calibrating the inertial measurement unit based on one or more gravity vectors upon communicating with the mobile device, and

wherein the mobile device displaying a live page showing the motion data of the inertial measurement unit for each repetition in the set.