CALCULATING ENERGY EXPENDITURE FROM ATHLETIC MOVEMENT ATTRIBUTES

Abstract

A system for estimating power consumption of a user that selects a power estimation model based upon a type of sensor and/or a type of sensor data available to a power estimation system.

Description

BACKGROUND

While most people appreciate the importance of physical fitness, many have difficulty finding the motivation required to maintain a regular exercise program. Some people find it particularly difficult to maintain an exercise regimen that involves continuously repetitive motions, such as running, walking and bicycling. Devices for tracking a user's activity may offer motivation in this regard, providing feedback on past activity, and encouragement to continue with an exercise routine in order to meet various exercise goals.

However, certain exercise metrics for athletes are assessed in formal lab-based settings, and using cumbersome equipment to monitor an individual while he/she exercises at a fixed location (e.g. on a treadmill or stationary bike). As such, these exercise metrics may not be readily available to the general population. Therefore, improved systems and methods to address at least one or more of these shortcomings in the art are desired.

BRIEF SUMMARY

The following presents a simplified summary of the present disclosure in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key or critical elements of the invention or to delineate the scope of the invention. The following summary merely presents some concepts of the invention in a simplified form as a prelude to the more detailed description provided below.

In one aspect this disclosure relates to an apparatus, method, and a non-transitory computer-readable medium for calculating a power estimate for a user performing an athletic activity, and includes capturing data from a sensor worn by the user, the data generated in response to a user's athletic activity. The apparatus, method, and non-transitory computer-readable medium may also include detecting a type of sensor from which data is received, in selecting, based on the detectives sensor type, a sampling scheme. Additionally, the captured data may be grouped into sampling windows, and a power model type may be selected based on the detected sensor type. Further, an attribute may be calculated based on the selected model type. An estimation of power may be calculated using the selected model type and the calculated attribute.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. The Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example system that may be configured to provide personal training and/or obtain data from the physical movements of a user in accordance with example embodiments;

FIG. 2 illustrates an example computer device that may be part of or in communication with the system of FIG. 1.

FIG. 3 shows an illustrative sensor assembly that may be worn by a user in accordance with example embodiments;

FIG. 4 shows another example sensor assembly that may be worn by a user in accordance with example embodiments;

FIG. 5 shows illustrative locations for sensory input which may include physical sensors located on/in a user's clothing and/or be based upon identification of relationships between two moving body parts of the user;

FIGS. 6A-6C depict graphs of exercise data associated with three exercise intensity domains, according to one or more aspects described herein;

FIG. 7 schematically depicts an activity monitoring device, according to one or more aspects described herein;

FIG. 8 schematically depicts a flowchart diagram for calculation of a critical tissue oxygenation percentage and/or an anaerobic work capacity, from a tissue oxygenation sensor data, according to one or more aspects described herein;

FIGS. 9A-9B depict graphs of muscle oxygenation sensor data from multiple exercise sessions, according to one or more aspects described herein;

FIG. 10 depicts a flowchart diagram for determination as to whether a user is exercising at an unsustainable work rate within a severe exercise intensity domain, according to one or more aspects described herein;

FIG. 11 depicts a flowchart diagram for determination as to whether a user is exercising at an unsustainable, a sustainable, or a critical work rate, according to one or more aspects described herein;

FIG. 12 depicts graphs of speed and muscle oxygenation output data generated during an exercise session, according to one or more aspects described herein;

FIG. 13 depicts a flowchart diagram for determination as to whether a user is exercising within a severe exercise intensity domain, according to one or more aspects described herein;

FIGS. 14A-14B depict graphs of power and muscle oxygenation output data from two exercise sessions, according to one or more aspects described herein;

FIG. 15 depicts a flowchart diagram for determination as to whether the received tissue oxygenation data represents exercise at a critical intensity, according to one or more aspects described herein;

FIG. 16 depicts a graph of muscle oxygenation percentage for different exercise sessions, according to one or more aspects described herein;

FIG. 17 depicts graphs of speed and muscle oxygenation output data generated during a same exercise session, according to one or more aspects described herein;

FIG. 18 depicts a graph of power output data from an exercise session, according to one or more aspects described herein;

FIG. 19 depicts a flowchart diagram for calculation of a critical power associated with an exercise session, according to one or more aspects described herein;

FIG. 20 depicts a graph of output speed data for an exercise session, according to one or more aspects described herein;

FIG. 21 is a flowchart diagram that may be utilized to calculate a critical speed and an anaerobic work capacity based upon speed sensor data, according to one or more aspects described herein;

FIG. 22 is a flowchart diagram that may be utilized to calculate a critical speed and/or an anaerobic work capacity of the user, according to one or more aspects described herein;

FIG. 23 is a chart that plots distance data for multiple exercise sessions of a user, according to one or more aspects described herein;

FIG. 24 schematically depicts a model for prediction of a critical velocity fraction for running, according to one or more aspects described herein;

FIG. 25 schematically depicts a model for prediction of a critical velocity fraction for running, according to one or more aspects described herein;

FIG. 26 schematically depicts a model for prediction of a critical velocity fraction for cycling, according to one or more aspects described herein;

FIG. 27 schematically depicts a model for prediction of a critical velocity fraction for cycling, according to one or more aspects described herein;

FIG. 28 is a flowchart diagram that may be utilized to calculate a critical velocity and an anaerobic work capacity based upon a single input data point, according to one or more aspects described herein;

FIG. 29 is a flowchart diagram that may be utilized to estimate a volume of oxygen consumption in response to a received rate of perceived exertion of the user, according to one or more aspects described herein;

FIG. 30 schematically depicts an anaerobic work capacity replenishment rate, according to one or more aspects described herein;

FIG. 31 is a flowchart diagram that may be utilized to calculate a power value using sensor data generated during an athletic activity, according to one or more aspects described herein;

FIG. 32 is a flowchart diagram that may be utilized to build a power model from data generated in response to prescribed activities, according to one or more aspects described herein;

FIG. 33 is a flowchart diagram that may be utilized to calculate attributes, according to one or more aspects described herein;

FIG. 34 is a flowchart diagram that may be utilized to verify data received from one or more sensors; and

FIG. 35 is a flowchart diagram that may be utilized to compare attributes calculated from received sensor data to one or more expert models, according to one or more aspects described herein.

DETAILED DESCRIPTION

Aspects of this disclosure involve obtaining, storing, and/or processing athletic data relating to the physical movements of an athlete. The athletic data may be actively or passively sensed and/or stored in one or more non-transitory storage mediums. Still further aspects relate to using athletic data to generate an output, such as for example, calculated athletic attributes, feedback signals to provide guidance, and/or other information. These and other aspects will be discussed in the context of the following illustrative examples of a personal training system.

In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which aspects of the disclosure may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope and spirit of the present disclosure. Further, headings within this disclosure should not be considered as limiting aspects of the disclosure and the example embodiments are not limited to the example headings.

I. Example Personal Training System

A. Illustrative Networks

Aspects of this disclosure relate to systems and methods that may be utilized across a plurality of networks. In this regard, certain embodiments may be configured to adapt to dynamic network environments. Further embodiments may be operable in differing discrete network environments. FIG. 1 illustrates an example of a personal training system 100 in accordance with example embodiments. Example system 100 may include one or more interconnected networks, such as the illustrative body area network (BAN) 102, local area network (LAN) 104, and wide area network (WAN) 106. As shown in FIG. 1 (and described throughout this disclosure), one or more networks (e.g., BAN 102, LAN 104, and/or WAN 106), may overlap or otherwise be inclusive of each other. Those skilled in the art will appreciate that the illustrative networks 102-106 are logical networks that may each comprise one or more different communication protocols and/or network architectures and yet may be configured to have gateways to each other or other networks. For example, each of BAN 102, LAN 104 and/or WAN 106 may be operatively connected to the same physical network architecture, such as cellular network architecture 108 and/or WAN architecture 110. For example, portable electronic device 112, which may be considered a component of both BAN 102 and LAN 104, may comprise a network adapter or network interface card (NIC) configured to translate data and control signals into and from network messages according to one or more communication protocols, such as the Transmission Control Protocol (TCP), the Internet Protocol (IP), and the User Datagram Protocol (UDP) through one or more of architectures 108 and/or 110. These protocols are well known in the art, and thus will not be discussed here in more detail.

Network architectures 108 and 110 may include one or more information distribution network(s), of any type(s) or topology(s), alone or in combination(s), such as for example, cable, fiber, satellite, telephone, cellular, wireless, etc. and as such, may be variously configured such as having one or more wired or wireless communication channels (including but not limited to: WiFi®, Bluetooth®, Near-Field Communication (NFC) and/or ANT technologies). Thus, any device within a network of FIG. 1, (such as portable electronic device 112 or any other device described herein) may be considered inclusive to one or more of the different logical networks 102-106. With the foregoing in mind, example components of an illustrative BAN and LAN (which may be coupled to WAN 106) will be described.

1. Example Local Area Network

LAN 104 may include one or more electronic devices, such as for example, computer device 114. Computer device 114, or any other component of system 100, may comprise a mobile terminal, such as a telephone, music player, tablet, netbook or any portable device. In other embodiments, computer device 114 may comprise a media player or recorder, desktop computer, server(s), a gaming console, such as for example, a Microsoft® XBOX, Sony® Playstation, and/or a Nintendo® Wii gaming consoles. Those skilled in the art will appreciate that these are merely example devices for descriptive purposes and this disclosure is not limited to any console or computing device.

Those skilled in the art will appreciate that the design and structure of computer device 114 may vary depending on several factors, such as its intended purpose. One example implementation of computer device 114 is provided in FIG. 2, which illustrates a block diagram of computing device 200. Those skilled in the art will appreciate that the disclosure of FIG. 2 may be applicable to any device disclosed herein. Device 200 may include one or more processors, such as processor 202-1 and 202-2 (generally referred to herein as “processors 202” or “processor 202”). Processors 202 may communicate with each other or other components via an interconnection network or bus 204. Processor 202 may include one or more processing cores, such as cores 206-1 and 206-2 (referred to herein as “cores 206” or more generally as “core 206”), which may be implemented on a single integrated circuit (IC) chip.

Cores 206 may comprise a shared cache 208 and/or a private cache (e.g., caches 210-1 and 210-2, respectively). One or more caches 208/210 may locally cache data stored in a system memory, such as memory 212, for faster access by components of the processor 202. Memory 212 may be in communication with the processors 202 via a chipset 216. Cache 208 may be part of system memory 212 in certain embodiments. Memory 212 may include, but is not limited to, random access memory (RAM), read only memory (ROM), and include one or more of solid-state memory, optical or magnetic storage, and/or any other medium that can be used to store electronic information. Yet other embodiments may omit system memory 212.

System 200 may include one or more I/O devices (e.g., I/O devices 214-1 through 214-3, each generally referred to as I/O device 214). I/O data from one or more I/O devices 214 may be stored at one or more caches 208, 210 and/or system memory 212. Each of I/O devices 214 may be permanently or temporarily configured to be in operative communication with a component of system 100 using any physical or wireless communication protocol.

Returning to FIG. 1, four example I/O devices (shown as elements 116-122) are shown as being in communication with computer device 114. Those skilled in the art will appreciate that one or more of devices 116-122 may be stand-alone devices or may be associated with another device besides computer device 114. For example, one or more I/O devices may be associated with or interact with a component of BAN 102 and/or WAN 106. I/O devices 116-122 may include, but are not limited to athletic data acquisition units, such as for example, sensors. One or more I/O devices may be configured to sense, detect, and/or measure an athletic parameter from a user, such as user 124. Examples include, but are not limited to: an accelerometer, a gyroscope, a location-determining device (e.g., GPS), light (including non-visible light) sensor, temperature sensor (including ambient temperature and/or body temperature), sleep pattern sensors, heart rate monitor, image-capturing sensor, moisture sensor, force sensor, compass, angular rate sensor, and/or combinations thereof among others.

In further embodiments, I/O devices 116-122 may be used to provide an output (e.g., audible, visual, or tactile cue) and/or receive an input, such as a user input from athlete 124. Example uses for these illustrative I/O devices are provided below, however, those skilled in the art will appreciate that such discussions are merely descriptive of some of the many options within the scope of this disclosure. Further, reference to any data acquisition unit, I/O device, or sensor is to be interpreted disclosing an embodiment that may have one or more I/O device, data acquisition unit, and/or sensor disclosed herein or known in the art (either individually or in combination).

Information from one or more devices (across one or more networks) may be used to provide (or be utilized in the formation of) a variety of different parameters, metrics or physiological characteristics including but not limited to: motion parameters, such as speed, acceleration, distance, steps taken, direction, relative movement of certain body portions or objects to others, or other motion parameters which may be expressed as angular rates, rectilinear rates or combinations thereof, physiological parameters, such as calories, heart rate, sweat detection, effort, oxygen consumed, oxygen kinetics, and other metrics which may fall within one or more categories, such as: pressure, impact forces, information regarding the athlete, such as height, weight, age, demographic information and combinations thereof.

System 100 may be configured to transmit and/or receive athletic data, including the parameters, metrics, or physiological characteristics collected within system 100 or otherwise provided to system 100. As one example, WAN 106 may comprise server 111. Server 111 may have one or more components of system 200 of FIG. 2. In one embodiment, server 111 comprises at least a processor and a memory, such as processor 206 and memory 212. Server 111 may be configured to store computer-executable instructions on a non-transitory computer-readable medium. The instructions may comprise athletic data, such as raw or processed data collected within system 100. System 100 may be configured to transmit data, such as energy expenditure points, to a social networking website or host such a site. Server 111 may be utilized to permit one or more users to access and/or compare athletic data. As such, server 111 may be configured to transmit and/or receive notifications based upon athletic data or other information.

Returning to LAN 104, computer device 114 is shown in operative communication with a display device 116, an image-capturing device 118, sensor 120 and exercise device 122, which are discussed in turn below with reference to example embodiments. In one embodiment, display device 116 may provide audio-visual cues to athlete 124 to perform a specific athletic movement. The audio-visual cues may be provided in response to computer-executable instruction executed on computer device 114 or any other device, including a device of BAN 102 and/or WAN. Display device 116 may be a touchscreen device or otherwise configured to receive a user-input.

In one embodiment, data may be obtained from image-capturing device 118 and/or other sensors, such as sensor 120, which may be used to detect (and/or measure) athletic parameters, either alone or in combination with other devices, or stored information. Image-capturing device 118 and/or sensor 120 may comprise a transceiver device. In one embodiment sensor 128 may comprise an infrared (IR), electromagnetic (EM) or acoustic transceiver. For example, image-capturing device 118, and/or sensor 120 may transmit waveforms into the environment, including towards the direction of athlete 124 and receive a “reflection” or otherwise detect alterations of those released waveforms. Those skilled in the art will readily appreciate that signals corresponding to a multitude of different data spectrums may be utilized in accordance with various embodiments. In this regard, devices 118 and/or 120 may detect waveforms emitted from external sources (e.g., not system 100). For example, devices 118 and/or 120 may detect heat being emitted from user 124 and/or the surrounding environment. Thus, image-capturing device 126 and/or sensor 128 may comprise one or more thermal imaging devices. In one embodiment, image-capturing device 126 and/or sensor 128 may comprise an IR device configured to perform range phenomenology.

In one embodiment, exercise device 122 may be any device configurable to permit or facilitate the athlete 124 performing a physical movement, such as for example a treadmill, step machine, etc. There is no requirement that the device be stationary. In this regard, wireless technologies permit portable devices to be utilized, thus a bicycle or other mobile exercising device may be utilized in accordance with certain embodiments. Those skilled in the art will appreciate that equipment 122 may be or comprise an interface for receiving an electronic device containing athletic data performed remotely from computer device 114. For example, a user may use a sporting device (described below in relation to BAN 102) and upon returning home or the location of equipment 122, download athletic data into element 122 or any other device of system 100. Any I/O device disclosed herein may be configured to receive activity data.

2. Body Area Network

BAN 102 may include two or more devices configured to receive, transmit, or otherwise facilitate the collection of athletic data (including passive devices). Exemplary devices may include one or more data acquisition units, sensors, or devices known in the art or disclosed herein, including but not limited to I/O devices 116-122. Two or more components of BAN 102 may communicate directly, yet in other embodiments, communication may be conducted via a third device, which may be part of BAN 102, LAN 104, and/or WAN 106. One or more components of LAN 104 or WAN 106 may form part of BAN 102. In certain implementations, whether a device, such as portable device 112, is part of BAN 102, LAN 104, and/or WAN 106, may depend on the athlete's proximity to an access point to permit communication with mobile cellular network architecture 108 and/or WAN architecture 110. User activity and/or preference may also influence whether one or more components are utilized as part of BAN 102. Example embodiments are provided below.

User 124 may be associated with (e.g., possess, carry, wear, and/or interact with) any number of devices, such as portable device 112, shoe-mounted device 126, wrist-worn device 128 and/or a sensing location, such as sensing location 130, which may comprise a physical device or a location that is used to collect information. One or more devices 112, 126, 128, and/or 130 may not be specially designed for fitness or athletic purposes. Indeed, aspects of this disclosure relate to utilizing data from a plurality of devices, some of which are not fitness devices, to collect, detect, and/or measure athletic data. In certain embodiments, one or more devices of BAN 102 (or any other network) may comprise a fitness or sporting device that is specifically designed for a particular sporting use. As used herein, the term “sporting device” includes any physical object that may be used or implicated during a specific sport or fitness activity. Exemplary sporting devices may include, but are not limited to: golf balls, basketballs, baseballs, soccer balls, footballs, powerballs, hockey pucks, weights, bats, clubs, sticks, paddles, mats, and combinations thereof. In further embodiments, exemplary fitness devices may include objects within a sporting environment where a specific sport occurs, including the environment itself, such as a goal net, hoop, backboard, portions of a field, such as a midline, outer boundary marker, base, and combinations thereof.

In this regard, those skilled in the art will appreciate that one or more sporting devices may also be part of (or form) a structure and vice-versa, a structure may comprise one or more sporting devices or be configured to interact with a sporting device. For example, a first structure may comprise a basketball hoop and a backboard, which may be removable and replaced with a goal post. In this regard, one or more sporting devices may comprise one or more sensors, such as one or more of the sensors discussed above in relation to FIGS. 1-3, that may provide information utilized, either independently or in conjunction with other sensors, such as one or more sensors associated with one or more structures. For example, a backboard may comprise a first sensor configured to measure a force and a direction of the force by a basketball upon the backboard and the hoop may comprise a second sensor to detect a force. Similarly, a golf club may comprise a first sensor configured to detect grip attributes on the shaft and a second sensor configured to measure impact with a golf ball.

Looking to the illustrative portable device 112, it may be a multi-purpose electronic device, that for example, includes a telephone or digital music player, including an IPOD®, IPAD®, or iPhone®, brand devices available from Apple, Inc. of Cupertino, Calif. or Zune® or Microsoft® Windows devices available from Microsoft of Redmond, Wash. As known in the art, digital media players can serve as an output device, input device, and/or storage device for a computer. Device 112 may be configured as an input device for receiving raw or processed data collected from one or more devices in BAN 102, LAN 104, or WAN 106. In one or more embodiments, portable device 112 may comprise one or more components of computer device 114. For example, portable device 112 may be include a display 116, image-capturing device 118, and/or one or more data acquisition devices, such as any of the I/O devices 116-122 discussed above, with or without additional components, so as to comprise a mobile terminal.

a. Illustrative Apparel/Accessory Sensors

In certain embodiments, I/O devices may be formed within or otherwise associated with user's 124 clothing or accessories, including a watch, armband, wristband, necklace, shirt, shoe, or the like. These devices may be configured to monitor athletic movements of a user. It is to be understood that they may detect athletic movement during user's 124 interactions with computer device 114 and/or operate independently of computer device 114 (or any other device disclosed herein). For example, one or more devices in BAN 102 may be configured to function as an all-day activity monitor that measures activity regardless of the user's proximity or interactions with computer device 114. It is to be further understood that the sensory system 302 shown in FIG. 3 and the device assembly 400 shown in FIG. 4, each of which are described in the following paragraphs, are merely illustrative examples.

i. Shoe-Mounted Device

In certain embodiments, device 126 shown in FIG. 1, may comprise footwear which may include one or more sensors, including but not limited to those disclosed herein and/or known in the art. FIG. 3 illustrates one example embodiment of a sensor system 302 providing one or more sensor assemblies 304. Assembly 304 may comprise one or more sensors, such as for example, an accelerometer, gyroscope, location-determining components, force sensors and/or or any other sensor disclosed herein or known in the art. In the illustrated embodiment, assembly 304 incorporates a plurality of sensors, which may include force-sensitive resistor (FSR) sensors 306; however, other sensor(s) may be utilized. Port 308 may be positioned within a sole structure 309 of a shoe, and is generally configured for communication with one or more electronic devices. Port 308 may optionally be provided to be in communication with an electronic module 310, and the sole structure 309 may optionally include a housing 311 or other structure to receive the module 310. The sensor system 302 may also include a plurality of leads 312 connecting the FSR sensors 306 to the port 308, to enable communication with the module 310 and/or another electronic device through the port 308. Module 310 may be contained within a well or cavity in a sole structure of a shoe, and the housing 311 may be positioned within the well or cavity. In one embodiment, at least one gyroscope and at least one accelerometer are provided within a single housing, such as module 310 and/or housing 311. In at least a further embodiment, one or more sensors are provided that, when operational, are configured to provide directional information and angular rate data. The port 308 and the module 310 include complementary interfaces 314, 316 for connection and communication.

In certain embodiments, at least one force-sensitive resistor 306 shown in FIG. 3 may contain first and second electrodes or electrical contacts 318, 320 and a force-sensitive resistive material 322 disposed between the electrodes 318, 320 to electrically connect the electrodes 318, 320 together. When pressure is applied to the force-sensitive material 322, the resistivity and/or conductivity of the force-sensitive material 322 changes, which changes the electrical potential between the electrodes 318, 320. The change in resistance can be detected by the sensor system 302 to detect the force applied on the sensor 316. The force-sensitive resistive material 322 may change its resistance under pressure in a variety of ways. For example, the force-sensitive material 322 may have an internal resistance that decreases when the material is compressed. Further embodiments may utilize “volume-based resistance”, which may be implemented through “smart materials.” As another example, the material 322 may change the resistance by changing the degree of surface-to-surface contact, such as between two pieces of the force sensitive material 322 or between the force sensitive material 322 and one or both electrodes 318, 320. In some circumstances, this type of force-sensitive resistive behavior may be described as “contact-based resistance.”

ii. Wrist-Worn Device

As shown in FIG. 4, device 400 (which may resemble or comprise sensory device 128 shown in FIG. 1), may be configured to be worn by user 124, such as around a wrist, arm, ankle, neck or the like. Device 400 may include an input mechanism, such as a depressible input button 402 configured to be used during operation of the device 400. The input button 402 may be operably connected to a controller 404 and/or any other electronic components, such as one or more of the elements discussed in relation to computer device 114 shown in FIG. 1. Controller 404 may be embedded or otherwise part of housing 406. Housing 406 may be formed of one or more materials, including elastomeric components and comprise one or more displays, such as display 408. The display may be considered an illuminable portion of the device 400. The display 408 may include a series of individual lighting elements or light members such as LED lights 410. The lights may be formed in an array and operably connected to the controller 404. Device 400 may include an indicator system 412, which may also be considered a portion or component of the overall display 408. Indicator system 412 can operate and illuminate in conjunction with the display 408 (which may have pixel member 414) or completely separate from the display 408. The indicator system 412 may also include a plurality of additional lighting elements or light members, which may also take the form of LED lights in an exemplary embodiment. In certain embodiments, indicator system may provide a visual indication of goals, such as by illuminating a portion of lighting members of indicator system 412 to represent accomplishment towards one or more goals. Device 400 may be configured to display data expressed in terms of activity points or currency earned by the user based on the activity of the user, either through display 408 and/or indicator system 412.

A fastening mechanism 416 can be disengaged wherein the device 400 can be positioned around a wrist or portion of the user 124 and the fastening mechanism 416 can be subsequently placed in an engaged position. In one embodiment, fastening mechanism 416 may comprise an interface, including but not limited to a USB port, for operative interaction with computer device 114 and/or devices, such as devices 120 and/or 112. In certain embodiments, fastening member may comprise one or more magnets. In one embodiment, fastening member may be devoid of moving parts and rely entirely on magnetic forces.

In certain embodiments, device 400 may comprise a sensor assembly (not shown in FIG. 4). The sensor assembly may comprise a plurality of different sensors, including those disclosed herein and/or known in the art. In an example embodiment, the sensor assembly may comprise or permit operative connection to any sensor disclosed herein or known in the art. Device 400 and or its sensor assembly may be configured to receive data obtained from one or more external sensors.

iii. Apparel and/or Body Location Sensing

Element 130 of FIG. 1 shows an example sensory location which may be associated with a physical apparatus, such as a sensor, data acquisition unit, or other device. Yet in other embodiments, it may be a specific location of a body portion or region that is monitored, such as via an image capturing device (e.g., image capturing device 118). In certain embodiments, element 130 may comprise a sensor, such that elements 130a and 130b may be sensors integrated into apparel, such as athletic clothing. Such sensors may be placed at any desired location of the body of user 124. Sensors 130a/b may communicate (e.g., wirelessly) with one or more devices (including other sensors) of BAN 102, LAN 104, and/or WAN 106. In certain embodiments, passive sensing surfaces may reflect waveforms, such as infrared light, emitted by image-capturing device 118 and/or sensor 120. In one embodiment, passive sensors located on user's 124 apparel may comprise generally spherical structures made of glass or other transparent or translucent surfaces which may reflect waveforms. Different classes of apparel may be utilized in which a given class of apparel has specific sensors configured to be located proximate to a specific portion of the user's 124 body when properly worn. For example, golf apparel may include one or more sensors positioned on the apparel in a first configuration and yet soccer apparel may include one or more sensors positioned on apparel in a second configuration.

FIG. 5 shows illustrative locations for sensory input (see, e.g., sensory locations 130a-130o). In this regard, sensors may be physical sensors located on/in a user's clothing, yet in other embodiments, sensor locations 130a-130o may be based upon identification of relationships between two moving body parts. For example, sensor location 130a may be determined by identifying motions of user 124 with an image-capturing device, such as image-capturing device 118. Thus, in certain embodiments, a sensor may not physically be located at a specific location (such as one or more of sensor locations 130a-130o), but is configured to sense properties of that location, such as with image-capturing device 118 or other sensor data gathered from other locations. In this regard, the overall shape or portion of a user's body may permit identification of certain body parts. Regardless of whether an image-capturing device is utilized and/or a physical sensor located on the user 124, and/or using data from other devices, (such as sensory system 302), device assembly 400 and/or any other device or sensor disclosed herein or known in the art is utilized, the sensors may sense a current location of a body part and/or track movement of the body part. In one embodiment, sensory data relating to location 130m may be utilized in a determination of the user's center of gravity (a.k.a, center of mass). For example, relationships between location 130a and location(s) 130f/130l with respect to one or more of location(s) 130m-130o may be utilized to determine if a user's center of gravity has been elevated along the vertical axis (such as during a jump) or if a user is attempting to “fake” a jump by bending and flexing their knees. In one embodiment, sensor location 1306n may be located at about the sternum of user 124. Likewise, sensor location 130o may be located approximate to the naval of user 124. In certain embodiments, data from sensor locations 130m-130o may be utilized (alone or in combination with other data) to determine the center of gravity for user 124. In further embodiments, relationships between multiple sensor locations, such as sensors 130m-130o, may be utilized in determining orientation of the user 124 and/or rotational forces, such as twisting of user's 124 torso. Further, one or more locations, such as location(s), may be utilized as (or approximate) a center of moment location. For example, in one embodiment, one or more of location(s) 130m-130o may serve as a point for a center of moment location of user 124. In another embodiment, one or more locations may serve as a center of moment of specific body parts or regions.

Exercise may be categorized into multiple intensity domains. In one example, exercise may be categorized into four intensity domains, including: moderate, heavy, severe, and extreme, which are defined based on distinct metabolic profiles of an athlete or user. In one example, an athlete's exertion may be monitored using a power metric. FIG. 6A depicts three graphs; 606, 608, and 610, corresponding to three exercise sessions undertaken by a user, and such that exertion is graphed as power (y-axis 602) versus time (x-axis 604). Accordingly, graphs 606, 608, and 610 may correspond to three separate exercise sessions carried out at an approximately constant work rate. As such, graphs 606, 608, and 610 are depicted in FIG. 6A as approximately level graphs. In one specific example, the exercise sessions associated with graph 606, 608, and 610 may correspond to a user cycling against an approximately constant resistance (approximately constant speed, approximately constant gradient, approximately constant wind resistance, among others). In one example, each of the exercise sessions associated with graph 606, 608, and 610 may be carried out in a controlled environment, such as a lab-based environment, and such that an athlete may cycle on a stationary exercise bicycle against a controlled, and approximately constant resistance, and at an approximately constant speed. As such, a power associated with an exercise session may be calculated based on a resistance applied to the exercise bicycle, and a speed at which the person being monitored (referred to as the athlete or user) is cycling. In another example, graphs 606, 608, and 610 may correspond to three monitored running exercise sessions carried out against an approximately constant resistance (at an approximately constant speed, and an approximately constant gradient). As such, graphs 606, 608, and 610 may correspond to a user running on a treadmill at approximately constant speed and an approximately constant gradient. Additionally or alternatively, graphs 606, 608, and 610 may correspond to three exercise sessions monitored as a user cycles at three approximately constant work rates (approximately constant power) in a non-lab-based environment on a regular bicycle, or as a user runs at three approximately constant work rates in a non-lab-based environment. Furthermore, graphs 606, 608, and 610 may correspond to alternative forms of exercise (e.g. cross-country skiing, speed skating, among others).

Graphs 606, 608, and 610 schematically depict a same exercise type carried out by a same user at three approximately constant work rates corresponding to three different exercise intensity domains for that user. In particular, graph 610 may correspond to a moderate exercise intensity domain, graph 608 corresponds to a heavy exercise intensity domain, and graph 606 corresponds to a severe exercise intensity domain. In one example, a moderate exercise intensity domain may be defined as corresponding to an exercise intensity (power level) below a lactate threshold (LT), which is schematically depicted as threshold line 612 in FIG. 6A, and otherwise referred to as a gas exchange threshold (GET), lactate inflection point (LIP), or anaerobic threshold (AT). As such, a lactate threshold may correspond to an exercise intensity at which lactate (in particular, lactic acid) starts to accumulate in the bloodstream of the exercising user. In one specific example, graph 610 may be approximately 10% below the lactate threshold for the user being monitored.

In one example, graph 608 may correspond to a heavy exercise intensity domain, and such that a heavy exercise intensity domain may be defined as an exercise intensity carried out between the lactate threshold associated with line 612, and a critical intensity (CI) (otherwise referred to as a critical power (CP)). In one example, a critical intensity for the user associated with graphs 606, 608, and 610 may be denoted by line 614. As such, when an exercise intensity is below the critical intensity, any elevation in blood lactate and oxygen consumption (VO₂) may be stabilized after approximately 10 to 15 minutes. The work rate at a critical intensity may be defined as the highest sustainable work rate for a prolonged duration that does not elicit maximal oxygen uptake. In one example, graph 608 may be approximately 15% below the critical intensity 614.

Graph 606 may correspond to a severe exercise intensity domain. A severe exercise intensity domain may correspond to an exercise intensity above the critical intensity schematically depicted by line 614. As such, a work rate within the severe exercise intensity domain may lead, inexorably, to maximal oxygen consumption, which may be referred to as acute fatigue. The amount of work a user is able to do above the critical intensity may be capacity-limited, but rate-independent. In other words, the amount of work that a given user is able to perform above a critical intensity may be fixed, regardless of the rate at which the work is done (i.e. the power). This amount of work that the user is able to perform may be referred to as a finite reserve capacity, and may be denoted as W′. In one example, the finite reserve capacity may, alternatively, be referred to as an anaerobic capacity, or anaerobic work capacity. In one example, where the finite reserve capacity is expressed as a distance, it may be alternatively denoted by D′. In one example, the severe exercise session associated with graph 606 may be approximately 15% above the critical intensity associated with line 614.

Line 616 schematically denotes maximal oxygen consumption (VO_2max) for the user associated with graphs 606, 608, and 610. This maximal oxygen consumption may, alternatively, be referred to as maximal oxygen uptake, peak oxygen uptake, or maximal aerobic capacity, and may be the maximum rate of oxygen consumption for the user. In one example, the maximal oxygen consumption may be expressed in liters of oxygen per minute (L/min), or in milliliters of oxygen per kilogram of body mass per minute (mL/(kg·min)).

The length of each of graphs 606, 608, and 610 corresponds to the durations of the three exercise sessions within the moderate (graph 610), heavy (graph 608), and severe (graph 606) exercise intensity domains. Accordingly, the severe exercise intensity session 606 was carried out for a duration corresponding to time 618. Similarly, the heavy exercise intensity session 608 was carried out for a duration corresponding to time 620, and the moderate exercise intensity session 610 was carried out for a duration corresponding to time 622. In one implementation, knowledge of the critical intensity corresponding to line 614, an intensity above the critical intensity (e.g. an intensity associated with an exercise session corresponding to graph 606), and a duration 618 of the exercise session within the severe exercise intensity domain (i.e. above the critical intensity) may be utilized to calculate the finite reserve capacity for a user. In one example, the finite reserve capacity may be calculated as an integration of a power graph above the critical power. For the example of graph 606 (at constant power), the area under the graph but above the critical power may be calculated as:

Finite reserve capacity, W′(J)=Intensity above a critical intensity (W)×time to fatigue (s).

In one example, once a critical intensity and a finite work capacity associated with a given athlete are known (i.e. are identified and/or calculated), real-time monitoring of an athletic performance of the athlete, by an activity monitoring device, such as one or more of devices 112, 114, 128, 200, and/or 400, among others, may be used to provide feedback regarding a current exercise intensity relative to a critical intensity for the athlete. Additionally or alternatively, given a critical intensity and a finite work capacity associated with the athlete, the activity monitoring device may be utilized to predict one or more outcomes of a current exercise session. As such, an activity monitoring device may be utilized to, among others, predict a race time for an athlete. Further details related to utilization of critical intensity and finite work capacity information to provide feedback to a user are discussed later in the various disclosures that follow.

Muscle oxygenation, MO₂, may be utilized as a metric for monitoring exercise performance of an athlete. In one example, muscle oxygenation may be monitored in order to identify, among others, a critical intensity and/or anaerobic work capacity associated with an athlete. An activity monitoring device incorporating a muscle oxygenation sensor is discussed in further detail in relation to FIG. 7. FIG. 6B schematically depicts three graphs 628, 630, and 632 of muscle oxygenation percentage, MO₂(%) (y-axis 624) versus time (x-axis 626). The three graphs 628, 630, and 632 correspond to the three graphs 606, 608, and 610 from FIG. 6A (i.e. the muscle oxygenation percentage data used to plot graphs 628, 630, and 632 was received from the exercise testing associated with graphs 606, 608, and 610). In one example, graphs 628, 630, and 632 may each depict muscle oxygenation percentage associated with a quadriceps muscle of an athlete, and such that for each of graphs 628, 630, and 632, the muscle oxygenation percentage data may be detected by a same sensor type (as described in further detail in relation to FIG. 7), and detected from an approximately same location on an athlete's body (i.e. proximate a quadriceps muscle of the athlete).

Graph 628 schematically depicts a progression of muscle oxygenation percentage of a quadriceps muscle of an athlete exercising within a severe exercise intensity domain (i.e. exercising at an intensity corresponding to graph 606). As depicted in FIG. 6B, graph 628 depicts a steady decline in muscle oxygenation percentage, without exhibiting an increase in muscle oxygenation percentage before the end of the exercise (point of fatigue) at time 618. Graph 630 schematically depicts a progression of muscle oxygenation percentage of a quadriceps muscle of an athlete exercising within a heavy exercise intensity domain (i.e. exercising at an intensity corresponding to graph 608). As depicted in FIG. 6B, graph 630 depicts a decline in muscle oxygenation percentage during a first time period, until point 634. At point 634, graph 630 exhibits a recovery in muscle oxygenation percentage before the exercise is completed (before the athlete fatigues) at time 620. Graph 632 schematically depicts a progression of muscle oxygenation percentage of the quadriceps muscle of the athlete exercising within a moderate exercise intensity domain (i.e. exercising at an intensity corresponding to graph 610). As depicted in FIG. 6B, graph 632 depicts a decline in muscle oxygenation percentage during a first time period, until point 636. At point 636, graph 632 exhibits a recovery in muscle oxygenation percentage before the exercise is completed at time 622.

As previously discussed, the data used to plot graphs 628, 630, and 632 may be received from a sensor configured to detect muscle oxygenation of a quadriceps muscle of an athlete. Further, the exercise sessions associated with graphs 628, 630, and 632 may include cycling or running sessions, among others, and such that the athlete's leg muscles are considered active muscles for the exercise sessions (i.e. as opposed to the athlete's arm muscles, among others). In summary, FIG. 6B schematically depicts that muscle oxygenation percentage of an active quadriceps muscle for a given exercise section may exhibit recovery from an initial decline when exercising within a moderate (graph 632) or a heavy (graph 630) exercise intensity domain, but that muscle oxygenation percentage will not recover when exercising within a severe exercise intensity domain.

FIG. 6C schematically depicts three graphs 644, 646, and 648 of muscle oxygenation percentage (y-axis 640) versus time (x-axis 642). The three graphs 644, 646, and 648 correspond to the three graphs 606, 608, and 610 from FIG. 6A (i.e. the muscle oxygenation percentage data used to plot graphs 644, 646, and 648 may be received from the exercise testing associated with graphs 606, 608, and 610). In one example, graphs 644, 646, and 648 may each depict muscle oxygenation percentage associated with a forearm muscle of the athlete. As such, graphs 644, 646, and 648 may be associated with an inactive muscle for an exercise session that concentrates on the athlete's leg muscles (e.g. cycling or running, among others). As such, graphs 644, 646, and 648 may be plotted from data detected by a same sensor type (as described in further detail in relation to FIG. 7), and detected from an approximately same location on the athlete's body (i.e. proximate a forearm muscle of the athlete).

In one example, graphs 644, 646, and 648 may exhibit similar trends to graphs 628, 630, and 632 from FIG. 6B. In particular, graph 644 depicts a steady decline in muscle oxygenation percentage, without exhibiting an increase in muscle oxygenation percentage before the end of the exercise (at point 618). As such, graph 644 may be associated with a severe exercise intensity domain, and with graph 606 from FIG. 6A. Graph 646 schematically depicts a progression of muscle oxygenation percentage of a forearm muscle of an athlete exercising within a heavy exercise intensity domain (i.e. exercising at an intensity corresponding to graph 608). As depicted in FIG. 6C, graph 646 depicts a decline in muscle oxygenation percentage during a first time period, up until point 650. At point 650, graph 646 exhibits a recovery in muscle oxygenation percentage before the exercise is completed at time 620. Graph 648 schematically depicts a progression of muscle oxygenation percentage of a forearm muscle of the athlete exercising within a moderate exercise intensity domain (i.e. exercising at an intensity corresponding to graph 610). As depicted in FIG. 6C, graph 648 depicts a decline in muscle oxygenation percentage during a first time period, up until point 652. At point 652, graph 648 exhibits a recovery in muscle oxygenation percentage before the exercise is completed at time 622.

Accordingly, FIGS. 6B and 6C schematically depict that similar trends in muscle oxygenation percentage may be exhibited by both active and inactive muscles when exercising within moderate, heavy, and severe exercise intensity domains. In this way, a muscle oxygenation sensor, such as that described in further detail in relation to FIG. 7, may be positioned on an active or inactive muscle in order to detect useful activity data for an athlete.

FIG. 7 schematically depicts an activity monitoring device 700. In one example, the activity monitoring device 700 may include one or more elements and/or functionality similar to devices 112, 114, 128, 200, and/or 400, among others. Accordingly, the activity monitoring device 700 may comprise a processor 702, which may be similar to one or more of processors 202-1 and 202-2. Processor 702 may comprise one or more processing cores configured to execute one or more computational instructions in parallel. Additionally or alternatively, processor 702 may utilize one or more processing cores to execute computational instructions in series, or a combination of series and parallel processing. Further, processor 702 may be embodied with any computational clock speed (clock speed may be related to a rate at which computational instructions may be executed by the processor 702) disclosed herein or generally known in the art. In one example, the processor 702 may be configured to execute computer-executable instructions stored on a non-transitory computer-readable medium, such as memory 704. As such, memory 704 may be similar to memory 212, and may include, but may not be limited to, persistent or volatile memory. As such, memory 704 may include one or more of random access memory (RAM), read only memory (ROM), solid-state memory, optical or magnetic storage, and/or any other medium that can be used to store electronic information.

In one implementation, electrical energy may be provided to one or more of the components (i.e. components 702, 704, 706, 708, and/or 710) of the activity monitoring device 700 by a power supply 703. As such, the power supply 703 may comprise one or more of a battery, a photovoltaic cell, a thermoelectric generator, or a wired electrical supply from an external source. Further, the power supply 703 may be configured to supply one or more components of the activity monitoring device 700 with an electrical output having any voltage, and configured to supply any current, without departing from the scope of these disclosures.

The activity monitoring device 700 may include a sensor 706. As such, sensor 706 may comprise an accelerometer, a gyroscope, a location-determining device (e.g., GPS), temperature sensor (including ambient temperature and/or body temperature), sleep pattern sensors, heart rate monitor, image-capturing sensor, moisture sensor, force sensor, compass, angular rate sensor, and/or combinations thereof among others. In one implementation, the activity monitoring device 700 may include an interface 708. As such, the interface 708 may be embodied with hardware and/or firmware and software configured to facilitate communication between the activity monitoring device 700 and external device or network, not depicted in FIG. 7. In one example, the interface 708 may facilitate wireless and/or wired communication between the activity monitoring device 700 and an external device or network. In one example, interface 708 may facilitate communication using one or more of Wi-Fi, Bluetooth, an Ethernet cable, a USB connection, or any other connection type disclosed herein or known in the art. As such, interface 708 may facilitate communication between the activity monitoring device 700 and an external device across a local area network (LAN), a wide area network (WAN), or the Internet, among others. Additionally or alternatively, interface 708 may facilitate communication between the activity monitoring device 708 and a user interface. As such, a user interface may include a display device, such as display device 116 and/or one or more input interfaces (e.g. one or more button interfaces, touchscreen interfaces, microphone interfaces, and the like).

Additionally or alternatively, the activity monitoring device 700 may include a muscle oxygenation sensor 710. In one example, the muscle oxygenation sensor 710 may be configured to emit electromagnetic radiation in a near-infrared wavelength range. As such, the muscle oxygenation sensor 710 may utilize near-infrared spectroscopy (NIRS). By positioning the muscle oxygenation sensor 710 proximate an area of skin 716 of a user, the emitted electromagnetic radiation, which is schematically depicted by arrow 722, may travel into the user's body through, in one example, a layer of skin 716, fat 718, and into a muscle tissue 720. In one example, oxyhemoglobin and deoxyhemoglobin may act as chromophores (absorbing differing amounts of light at different wavelengths). Further, oxyhemoglobin and deoxyhemoglobin may exhibit comparatively larger differences in absorption characteristics across a range of near infrared electromagnetic radiation. As such, the emitter 712 may be configured to emit electromagnetic radiation in a near infrared spectrum having a wavelength range of approximately 600 to 900 nm. In another example, the emitter 712 may be configured to emit infrared light having a wavelength range of approximately 630 to 850 nm. In yet another example, the emitter 712 may be configured to emit infrared light across another range, without departing from the scope of these disclosures. In one example, the emitter 712 may comprise one or more light emitting diode (LED) elements. In one specific example, the emitter 712 may comprise four light emitting diodes.

Accordingly, a portion of light emitted from the emitter 712 may be backscattered and detected by detector 714. In one example, line 724 may represent a portion of back scattered light detected by detector 714. As such, the muscle oxygenation sensor 710 may be configured to calculate an attenuation in intensity between emitted and detected light. This attenuation may be related to an amount of light absorbed by, among others, the oxyhemoglobin and deoxyhemoglobin chromophores. As such, by detecting an attenuation in emitted near infrared light, the muscle oxygenation sensor 710 may determine a concentration of oxyhemoglobin or deoxyhemoglobin. In turn, based upon the determined concentration of oxyhemoglobin or deoxyhemoglobin, the muscle oxygenation sensor 710 may calculate a muscle oxygenation percentage associated with the muscle 720.

In one implementation, the muscle oxygenation sensor 710 may calculate a muscle oxygenation percentage associated with muscle tissue 720 according to the Beer-Lambert law:

log(I_out/I_in)=ε·L·c

where I_in is an intensity of near-infrared radiation emitted from the emitter 712, I_out is an intensity of near-infrared radiation detected by detector 714, ε is a molar attenuation coefficient of the chromophore, c is an amount concentration of the chromophore, and l is a path length that the emitted near infrared radiation travels through the body (i.e. one or more of skin 716, fat 718, and muscle 720.

It will be appreciated that the light emitted from emitter 712 is schematically represented by line 722, and that portion of emitted light detected by detector 714 is schematically represented by line 724. In practice, a path of light emitted from emitter 712 traveling into a user's body (i.e. through one or more of skin 716, fat 718, and muscle 720), and light detected by detector 714 may be complex, and comprise a plurality of different paths.

In one example, the muscle oxygenation sensor 710 of the activity monitoring device 700 may be configured to be positioned proximate an area of skin 716 of a user. As such, in one example, the emitter 712 and the detector 714 may be positioned such that there exists substantially no separation between the emitter 712 and the skin 716, and similarly, substantially no separation between the detector 714 and the skin 716. In another example, the activity monitoring device 700 may be configured to be positioned proximate an area of skin 716 of a user, such that a gap between the emitter 712 and the skin 716, and/or the detector 714 in the skin 716 does not include a layer of clothing. In yet another example, the activity monitoring device 700 may be configured to be positioned proximate an area of skin 716 of a user, such that one or more layers of clothing may be positioned between the emitter 712 and the skin 716, and/or the detector 714 and the skin 716.

In one example, the activity monitoring device 700, and in particular, the muscle oxygenation sensor 710, may be utilized to determine (in one example, to calculate) a critical intensity and/or an anaerobic work capacity associated with a user. In one specific example, the muscle oxygenation sensor 710 may be utilized to determine a critical muscle oxygenation percentage at which a user reaches a critical intensity of exercise. Accordingly, FIG. 8 schematically depicts a flowchart diagram 800 that may be utilized to calculate one or more of a critical tissue oxygenation percentage and/or an anaerobic work capacity of a user from data outputted from a tissue oxygenation sensor, such as sensor 710. As such, the critical tissue oxygenation percentage may, in one example, be a critical tissue oxygenation percentage of muscle tissue, among others.

In one implementation, in order to calculate one or more of a critical tissue oxygenation percentage and/or an anaerobic work capacity, a user may provide an activity monitoring device, such as device 700, with test data. In one example, test data may be generated by the sensor, such as sensor 710, during an exercise period, which may otherwise be referred to as an exercise session. In one example, an exercise period may comprise a prescribed duration during which a user is instructed to run as quickly as possible (i.e. as far as possible) within the prescribed time limit. In certain specific examples, an exercise period may instruct a user to run as far as possible within, for example, a minute, two minutes, three minutes, four minutes, five minutes, six minutes, seven minutes, eight minutes, nine minutes, 10 minutes, 12 minutes, 15 minutes, 20 minutes, or any other duration. Accordingly, a tissue oxygenation sensor, such as sensor 710, may be configured to output a tissue oxygenation percentage data point each second during an exercise period. Alternatively, the tissue oxygenation sensor, such as sensor 710, may be configured to output a tissue oxygenation percentage data point at a different frequency, which may be 0.25 Hz, 0.5 Hz, 2 Hz, 3 Hz, 4 Hz, or any other frequency. In one example, an exercise period prescribed for a user in order to generate test data may ensure that the user exercises at an intensity above a critical intensity for the user during at least a portion of the prescribed duration of the exercise period. Accordingly, in one example, one or more processes may be executed to instruct a user to begin an exercise period at block 802 of flowchart 800.

As previously discussed, a tissue oxygenation sensor, such as sensor 710, may be used to detect, and to output data indicative of, a tissue oxygenation percentage. In one example, the tissue oxygenation sensor 710 may output a data point indicative of a current tissue oxygenation percentage for each second of an exercise period. Accordingly, in one example, the outputted tissue oxygenation data may be received for further processing by, in one example, processor 702, at block 804 of flowchart 800.

In one implementation, a tissue oxygenation percentage for each second of a prescribed exercise period may be stored. As such, tissue oxygenation percentages for each second of a prescribed exercise period may be stored in, for example, memory 704. Upon completion of a given exercise period, a number may be calculated corresponding to a total number of the stored tissue oxygenation percentages for each second of a duration of a prescribed exercise period. This number may be referred to as a total number of tissue oxygenation data points for an exercise period. This total number of tissue oxygenation data points may be calculated by, in one example, processor 702, and at block 806 of flowchart 800.

An exercise period utilized to generate data in order to determine a critical muscle oxygenation percentage and/or an anaerobic work capacity of the user may be summarized as a data point comprising two pieces of information. This exercise period summary data point may comprise the total number of tissue oxygenation data points, as determined, in one example, at block 806, in addition to the total time (i.e. the duration) of the exercise period/session. In one example, the two pieces of information (i.e. the total number of tissue oxygenation data points, and the total time) may be expressed as a coordinate point. In one example, this coordinate point P may be of the form P(x₁, y₁), where y₁ may be the total number of tissue oxygenation data points (muscle oxygenation percentage (%) x time (s)), and x₁ may be the total time (s). In this way, the exercise period summary data point expressed as a coordinate point may be plotted, as schematically depicted in FIG. 9. In one example, the exercise period summary data point may be calculated at block 808 of flowchart 800.

In one implementation, in order to calculate one or more of a critical tissue oxygenation percentage and/or an anaerobic work capacity of a user, two or more exercise period summary data points may be utilized. In one example, the durations of the exercise periods used to generate the two or more exercise period summary data points may be different. Accordingly, in one example, one or more processes may be executed to determine whether a threshold number of exercise periods have been completed by the user in order to calculate one or more of a critical tissue oxygenation percentage and/or an anaerobic work capacity for the user. As previously described, this threshold number of exercise periods may be at least two, at least three, at least four, or at least five, among others. In one specific example, one or more processes may be executed by processor 702 to determine whether the threshold number of exercise periods have been completed at decision block 810 of flowchart 800. Accordingly, if the threshold number of exercise periods has been met or exceeded, flowchart 800 proceeds to block 812. If, however, the threshold number of exercise periods has not been met, flowchart 800 proceeds from decision block 810 back to block 802.

In one example, a regression may be calculated using the two or more exercise period summary data points that were calculated from two or more prescribed exercise periods. This regression may be a linear, or a curvilinear regression. As such, any computational processes known in the art for calculation of a linear or curvilinear regression may be utilized with this disclosure. In one implementation, at least a portion of a calculated regression may be utilized to determine one or more of a critical tissue oxygenation percentage and/or an anaerobic work capacity of the user. In one specific example, one or more processes may be executed to calculate a regression at block 812 of flowchart 800.

At least a portion of a regression calculated using the two or more exercise period summary data points may be utilized to determine a critical tissue oxygenation percentage for a user. Specifically, the critical tissue oxygenation percentage may correspond to a slope of the regression line (or a slope of a linear portion of a curvilinear regression). One or more processes may be executed to output a critical tissue oxygenation percentage calculated as a slope of a regression line through the two or more exercise period summary data points at block 814 of flowchart 800.

At least a portion of a regression calculated using the two or more exercise period summary data points may be utilized to determine an anaerobic capacity of the user. Specifically, the anaerobic capacity may correspond to an intercept of the regression line (or an intercept of a linear portion of a curvilinear regression). In one example, the anaerobic capacity may be expressed as a total number of tissue oxygenation data points (tissue oxygenation percentage (%) x time (s)) above a critical oxygenation percentage (%). In one implementation, one or more processes may be executed to output an anaerobic capacity calculated as an intercept of a regression line through the two or more exercise period summary data points at block 816 of flowchart 800.

FIG. 9A is a chart that plots testing data from multiple exercise periods, or sessions, for a given user. In particular, FIG. 9A is a chart 900 plotting total muscle oxygenation points 902 against time 904. Points 906, 908, and 910 are each exercise period summary data points, as described in relation to FIG. 8. As such, the exercise period summary data points 906, 908, 910 may be calculated for a same user, and for, in this example, three separate exercise sessions. Accordingly, each of the exercise period summary data points 906, 908, and 910 may represent a separate exercise session. In particular, the exercise sessions associated with the exercise period summary data points 906, 908, and 910 may have durations of approximately 300 seconds, 720 seconds, and 900 seconds, respectively. Further, during the respective exercise sessions, muscle oxygenation percentage data detected for the user may be integrated for each second of a total duration of a given exercise session to give a total number of muscle oxygenation points equal to approximately 6000, 25,000, and 30,000 for the respective exercise period summary data points 906, 908, and 910.

In one example, the exercise period summary data points 906, 908, 910 may each represent a separate exercise session, and such that a portion of each of these exercise sessions is carried out within a severe exercise intensity domain for a user. In one implementation, the exercise period summary data points 906, 908, 910 may each represent a separate exercise session carried out in a continuous manner (nonstop exercise without breaks, e.g. continuous running and/or cycling). However, in another implementation, one or more of the exercise period summary data points 906, 908, 910 may each represent a separate exercise session carried out in an intermittent manner (a non-continuous exercise session with one or more periods of inactivity/low activity and one or more periods of high activity, e.g. participation in team sports, such as basketball, soccer, and the like).

In one implementation, a regression line 912 may be calculated using the three exercise period summary data points 906, 908, and 910, as plotted on chart 900. In one example, this regression line 912 may be of the form:

y=m _a x+c _a

where y is a total number of muscle oxygenation points (y-axis), x is a time (s) (x-axis), m_a is the slope of the regression line 912, and c_a is the intercept of the regression line 912 on the y-axis.

For the example experimental data used to generate the exercise period summary data points 906, 908, and 910, the regression line 912 may have the form: y=39.62x−5112.13, with an r² value of 0.99999. It is noted that this regression line 912 formula is merely included as one example result, and may not correspond to the example values discussed above for exercise period summary data points 906, 908, and 910.

In one example, a regression line, such as regression line 912, through two or more exercise period summary data points, such as the exercise period summary data points 906, 908, and 910, may be used to calculate a critical muscle oxygenation percentage and/or a total number of muscle oxygenation points above a critical muscle oxygenation percentage (which may be proportional to an anaerobic work capacity) for a user. In one example, given regression line 912 of the form: y=mx+c, the critical muscle oxygenation percentage may be equal to m, the slope of the regression line 912, and the total number of muscle oxygenation points above the critical muscle oxygenation percentage may be equal to c (or |c|, the absolute value of c), the intercept of the regression line 912 on the y-axis. In particular, given the experimental data depicted in chart 900, the critical muscle oxygenation percentage for the user may be 39.62%, and the total number of muscle oxygenation points above the critical muscle oxygenation percentage may be 5112.13.

In another example, the regression line 912 may be calculated through a plurality of exercise period summary data points greater than the three exercise period summary data points 906, 908, 910 depicted in FIG. 9A. Further, any methodology known in the art for calculation of a linear regression may be utilized with these disclosures to calculate a regression line 912. Additionally, while FIG. 9A graphically depicts a regression line 912, the activity monitoring device 700 may be configured to calculate a critical muscle oxygenation percentage for a user and/or a total number of muscle oxygenation points above a critical muscle oxygenation percentage, without requiring that a regression line be plotted. I.e. the activity monitoring device 700 may calculate one or more of a critical muscle oxygenation percentage and/or a total number of muscle oxygenation points above a critical muscle oxygenation percentage from muscle oxygenation data outputted from the muscle oxygenation sensor 710 without calculating and/or plotting a regression line through exercise period summary data points. As such, the depiction of regression line 912 may a pictorial description of methodology used by the activity monitoring device 700; however the activity monitoring device 700 may utilize alternative computational processes to calculate the same resulting critical muscle oxygenation percentage and/or total number of muscle oxygenation points above the critical muscle oxygenation percentage.

FIG. 9B depicts a chart 920 plotting test data from multiple exercise periods for a same user. In particular, FIG. 9B depicts chart 920 plotting muscle oxygenation percentage (%) 922 against inverse time (s⁻¹) 924. In one example, the data points 926, 928, and 930 may each represent a separate exercise session. In one implementation, a data point, from the data points 926, 928, 930, may be of the form (x₂,y₂), where y₂ is an average muscle oxygenation percentage over a total exercise session, and is calculated, in one example, as a sum of muscle oxygenation percentages for each second of an exercise period (in seconds), divided by the duration of the exercise period (in seconds). Those of ordinary skill in the art will recognize that the time resolution (or sampling rate) utilized may be different than the one second resolution described herein, without departing from the scope of these disclosures. For example, y₂ may be calculated, in another example, as a sum of muscle oxygenation percentages for each half second interval an exercise period divided by the total number of half seconds in the exercise period, among many other resolutions. Accordingly, x₂ may be calculated as 1/(total duration of a given exercise period), giving a result as an inverse time, with units of seconds⁻¹ (s⁻¹). In one specific implementation, data point 926 may include the same information as exercise period summary data point 910. Similarly, data point 928 may include the same information as exercise period summary data point 908, and data point 930 may include the same information as exercise period summary data point 906.

In one implementation, a regression line 932 may be calculated using two or more data points, such as data points 926, 928, 930. In one example, the regression line 932 may be of the form:

y=m _b x+c _b

where y is a muscle oxygenation percentage (%) (y-axis), x is an inverse time (s⁻¹) (x-axis), m_b is the slope of the regression line 932, and c_b is the intercept of the regression line 932 on the y-axis.

In one example, for the specific data depicted in chart 920, the regression line 932 may have the form: y=−5102.35x+39.6, with an r² value of 0.99999. Accordingly, m_b the slope of the regression line 932 (or |m_b| the absolute value), may equal the number of muscle oxygenation points above a critical muscle oxygenation percentage for a user. Similarly, c, the intercept may be equal to the critical muscle oxygenation percentage for the user.

FIG. 10 is a flowchart diagram 1000 that may be utilized to determine whether a user is exercising at an unsustainable work rate within a severe exercise intensity domain. In one implementation, an activity monitoring device, such as device 700, may receive tissue oxygenation data indicative of a real-time tissue oxygenation percentage for the user while exercising. Accordingly, this tissue oxygenation data may be generated by, in one example, muscle oxygenation sensor 710. As such, one or more processes may be executed by, in one example, processor 702, to receive the tissue oxygenation data. These one or more processes to receive the tissue oxygenation data may be executed at block 1002 of flowchart 1000.

In one implementation, received tissue oxygenation data may be compared to a critical tissue oxygenation percentage for the user. As such, a critical oxygenation percentage for a user may be calculated by an activity monitoring device, such as processor 702 of device 700, and stored memory, such as memory 704. Further, the critical muscle oxygenation percentage for a user may be calculated using one or more processes described in relation to FIG. 8. In one example, the received tissue oxygenation data may be compared to the critical tissue oxygenation percentage for the user by processor 702. As such, one or more processes executed by processor 702 to compare the received tissue oxygenation data to the critical tissue oxygenation percentage for the user may be executed at block 1004 of flowchart 1000.

A comparison of received tissue oxygenation data to a critical tissue oxygenation percentage for a user may include a determination as to whether the received, real-time tissue oxygenation percentage is above or equal to the critical tissue oxygenation percentage. This determination may represented by decision block 1006 of flowchart 1000. Accordingly, if the received tissue oxygenation data represents a tissue oxygenation percentage that is equal to or above a critical tissue oxygenation percentage for the user, the activity monitoring device 700 may output a signal indicating that the user is exercising at a sustainable work rate. In one example, this output signal may be communicated to a user via one or more indicator lights, a user interface, an audible signal, or a haptic feedback signal, among others. As such, the output signal may be communicated through interface 708 of the activity monitoring device 700. In one example, the one or more processes executed to output a signal indicating that the user is exercising at a sustainable work rate (i.e. outside of a severe exercise intensity domain) may be executed at block 1008 of flowchart 1000. In one implementation, if the received tissue oxygenation data represents a tissue oxygenation percentage that is below a critical tissue oxygenation percentage for the user, the activity monitoring device 700 may output a signal indicating that the user is exercising at an unsustainable work rate. In one example, this output signal may be delivered in a similar manner to the output signal described in relation to block 1008. Further, the one or more processes executed to output a signal indicating that the user is exercising at an unsustainable work rate (i.e. within a severe exercise intensity domain) may be executed at block 1010 of flowchart 1000.

FIG. 11 is a flowchart diagram 1100 that may be utilized to determine if a user is exercising at an unsustainable, a sustainable, or a critical work rate. In one implementation, an activity monitoring device, such as device 700, may receive periodic data from a tissue oxygenation sensor, such as sensor 710, indicative of a real-time oxygenation percentage of a tissue of a user while exercising. Accordingly, tissue oxygenation percentage data may be received by, in one example, processor 702, from sensor 710, and with a periodicity of one sample per second (1 Hz). In another implementation, the sensor 710 may output a data point indicative of a tissue oxygenation percentage once every two seconds (0.5 Hz), once every three seconds (0.33 Hz), or once every four seconds (0.25 Hz), among others. Further, tissue oxygenation data may be generated by, and received from, the sensor 710 at any rate, without departing from the scope of these disclosures. In one example, one or more processes may be executed to receive, by a processor, such as processor 702, periodic data from a tissue oxygenation sensor indicative of a tissue oxygenation percentage at block 1102 of flowchart 1100.

In one implementation, tissue oxygenation data received from a tissue oxygenation sensor, such as sensor 710, may be stored in memory, such as memory 704. Accordingly, in one example, a trend in tissue oxygenation data may be calculated based upon a comparison of a most recently-received tissue oxygenation percentage data point to one or more previously-stored tissue oxygenation percentage data points. In one example, one or more processes may be executed by processor 702 of the activity monitoring device 700, to calculate a change in tissue oxygenation percentage over a time spanning between a saved tissue oxygenation percentage data point, and a most recently-received tissue oxygenation percentage data point. In one implementation, this change may be calculated as a positive number, which may be indicative of an increase in tissue oxygenation percentage, as the negative number, which may be indicative of a decrease in tissue oxygenation percentage, or as a zero value, which may be indicative of no change in tissue oxygenation percentage. In another implementation, one or more processes may be executed by processor 702 of the activity monitoring device 700 to calculate a trend in tissue oxygenation percentage as a slope of a regression line, and calculated using two or more tissue oxygenation percentage data points. As such, if the slope of the calculated line has a negative value, it may be indicative of a decrease in tissue oxygenation percentage. Similarly, if the slope of the line is calculated as having a positive value, it may be indicative of an increase in tissue oxygenation percentage, and if the slope of the line is calculated as having a zero value, it may be indicative of no change in tissue oxygenation. In one example, one or more processes for calculation of a tissue oxygenation trend may be executed at block 1104 of flowchart 1100.

In additional or alternative implementations, a trend in tissue oxygenation may be calculated, such as at block 1104, according to the one or more processes described in relation to FIG. 15.

Decision block 1106 may represent one or more processes executed by processor 702 to determine if the calculated tissue oxygenation trend from block 1104 represents a negative trend. Accordingly, if it is determined that the calculated tissue oxygenation trend is negative, flowchart 1100 may proceed to block 1108. In one implementation, upon determining that data received from a tissue oxygenation sensor is representative of a negative trend, one or more processes may be executed to output a signal indicating that the user may be exercising at an unsustainable work rate. As such, one or more processes configured to output a signal indicating that the user may be exercising at an unsustainable work rate may be executed at block 1108. In another implementation, if it is determined that data received from a tissue oxygenation sensor is not representative of a negative trend, flowchart 1100 may proceed to decision block 1110. Accordingly, decision block 1110 may be associated with one or more processes executed to determine whether the calculated tissue oxygenation trend is positive. If it is determined that the calculated tissue oxygenation trend is positive, flowchart 1100 may proceed to block 1112. Accordingly, in one example, if it is determined that the calculated tissue oxygenation trend is positive, a signal may be outputted to indicate that the user is exercising at a sustainable work rate. In one example, the output signal indicating that the user is exercising at a sustainable work may be executed at block 1112 of flowchart 1100. In another example, if it is determined that the calculated tissue oxygenation trend is not positive, flowchart 1100 may proceed to block 1114. In this way, it may be determined that the calculated tissue oxygenation trend is approximately level (unchanged). As such, a level tissue oxygenation trend may be indicative of a user exercising at a critical work rate. Accordingly, in response to determining that the tissue oxygenation trend is approximately level, one or more processes may be executed to output a signal indicating that the user is exercising at a critical work rate. In one implementation, these one or more processes may be executed at block 1114 of flowchart 1100.

It is noted that flowchart 1100 may calculate a tissue oxygenation trend from two or more data points indicative of muscle oxygenation percentages at two or more different time points. As such, any numerical methodology known in the art may be utilized to calculate a trend between two or more such points, including, among others, calculation of a slope of a line connecting two points, or calculation of a regression line using a plurality of points, among others.

FIG. 12 depicts two graphs of data generated during a same exercise session. The two depicted graphs include muscle oxygenation percentage data 1208 and running speed data 1210 plotted against a common timescale 1206. In one implementation, the muscle oxygenation percentage data 1208 may be generated by a muscle oxygenation sensor, such as sensor 710. Further, the running speed data 1210 may be calculated based on sensor data generated by sensor 706, which may include, among others, an accelerometer, or a location-determining sensor. Accordingly, the graph of running speed 1210 may be associated with scale 1202, and the graph of muscle oxygenation 1208 may be associated with scale 1204. In one example, graphs 1208 and 1210 schematically depict relationships between muscle oxygenation percentage and a running speed. In one example, the period between points 1218 and 1220 on the muscle oxygenation percentage graph 1208 may represent a substantially level trend in muscle oxygenation percentage. Accordingly, points 1214 and 1216 on the speed graph 1210 may correspond to points 1218 and 1220, and such that the approximately level trend in muscle oxygenation percentage between points 1218 and 1220 corresponds to a critical speed, as schematically indicated by line 1212. In another example, a substantially negative trend in muscle oxygenation percentage between points 1220 and 1224 on the muscle oxygenation graph 1208 may correspond to an increase in speed above the critical speed between points 1216 and 1222 on the speed graph 1210. In yet another example, a positive trend in muscle oxygenation between points 1226 and 1228 on the muscle oxygenation graph 1208 may correspond to a decrease in speed below a critical speed between points 1230 and 1232 on the speed graph 1210.

FIG. 13 is a flowchart diagram 1300 that may be utilized to determine if a user is exercising within a severe exercise intensity domain. In one implementation, an activity monitoring device, such as device 700, may receive periodic data from a tissue oxygenation sensor, such as sensor 710, indicative of a real-time oxygenation percentage of a tissue of a user while exercising. Accordingly, tissue oxygenation percentage data may be received by, in one example, processor 702, from sensor 710, and with a periodicity of one sample per second (1 Hz). In another implementation, the sensor 710 may output a data point indicative of a tissue oxygenation percentage once every two seconds (0.5 Hz), once every three seconds (0.33 Hz), once every four seconds (0.25 Hz), among others. Further, tissue oxygenation data may be generated by, and received from, the sensor 710 at any rate, without departing from the scope of these disclosures. In one example, one or more processes may be executed to receive, by a processor, such as processor 702, periodic data from a tissue oxygenation sensor indicative of a tissue oxygenation percentage at block 1302 of flowchart 1300.

In one implementation, tissue oxygenation data received from a tissue oxygenation sensor, such as sensor 710, may be stored in memory, such as memory 704. Accordingly, in one example, a trend in tissue oxygenation data may be calculated based upon a comparison of a most recently-received tissue oxygenation percentage data point, to one or more previously-stored tissue oxygenation percentage data points. In one example, one or more processes may be executed by processor 702 of the activity monitoring device 700 to calculate a change in tissue oxygenation percentage over a time spanning between a saved tissue oxygenation percentage data point, and a most recently-received tissue oxygenation percentage data point. In another implementation, one or more processes may be executed by processor 702 of the activity monitoring device 700 to calculate a trend in tissue oxygenation percentage as a slope of a regression line calculated using two or more tissue oxygenation percentage data points. In one example, one or more processes for calculation of a tissue oxygenation trend may be executed at block 1304 of flowchart 1300.

Decision block 1306 may represent one or more processes executed by processor 702 to determine if the calculated tissue oxygenation trend from block 1304 represents a negative trend. Accordingly, if it is determined that the calculated tissue oxygenation trend is negative, flowchart 1300 may proceed to decision block 1308. In one implementation, decision block 1308 may execute one or more processes to calculate an absolute value of a negative trend (negative slope) identified at decision block 1306. Additionally, decision block 1308 may represent one or more processes configured to compare the absolute value of the negative trend to a threshold value. In one example, if the absolute value is above a threshold value, flowchart 1300 may proceed to block 1310. Accordingly, the threshold value may comprise any value, without departing from the scope of these disclosures. In one example, upon determining that the absolute value is above a threshold value, one or more processes may be configured to output a signal indicating that the user is exercising in a severe intensity domain. As such, these one or more processes configured to output a signal indicating that the user is exercising within a severe intensity domain may be executed at block 1310. If, however, the absolute value is below a threshold, flowchart 1300 may proceed to block 1312. Accordingly, block 1312 may comprise one or more processes that may be executed to output a signal indicating that the user is exercising at an unsustainable work rate.

In another implementation, if it is determined that data received from a tissue oxygenation sensor is not representative of a negative trend, flowchart 1300 may proceed to decision block 1314. Accordingly, decision block 1314 may be associated with one or more processes executed to determine whether the calculated tissue oxygenation trend is positive. If it is determined that the calculated tissue oxygenation trend is positive, flowchart 1300 may proceed to block 1316. Accordingly, in one example, if it is determined that the calculated tissue oxygenation trend is positive, a signal may be outputted to indicate that the user is exercising at a sustainable work rate. In one example, the output signal indicating that the user is exercising at a sustainable work may be executed at block 1316 of flowchart 1300. In another example, if it is determined that the calculated tissue oxygenation trend is not positive, flowchart 1300 may proceed to block 1318. In this way, it may be determined that the calculated tissue oxygenation trend is approximately level (unchanged). As such, a level tissue oxygenation trend may be indicative of a user exercising at a critical work rate. Accordingly, in response to determining that the tissue oxygenation trend is approximately level, one or more processes may be executed to output a signal indicating that the user is exercising at a critical work rate. In one implementation, these one or more processes may be executed at block 1318 of flowchart 1300.

FIG. 14A depicts two graphs plotted using data from two separate exercise sessions participated in by a same user. In particular, graph 1406 comprises output data from a ramped work rate exercise session. In one example, work rate (W) may be depicted on the y-axis 1402. Accordingly, the data associated with graph 1406 may be generated from data outputted during an exercise session that prescribes a linearly-increasing work rate that increases from a work rate below a critical intensity, to a work rate above a critical intensity for the user. Graph 1408 may be generated from data outputted during an exercise session that prescribes a constant work rate. In one example, the constant work rate associated with graph 1408 may be approximately 15% above a critical intensity for the user. Accordingly, the exercise session associated with graph 1408 may be within a severe exercise intensity domain for the user. In one example, the x-axis 1404 represents a percentage of time to the end of an exercise session. Further, point 1410 represents an approximate time at which the ramped work rate exercise session reaches the critical intensity for the user.

FIG. 14B depicts two graphs plotted using data from the same two separate exercise sessions from FIG. 14A. In particular, graph 1424 may correspond to the ramped work rate exercise session associated with graph 1406. Additionally, graph 1426 may correspond to the constant work rate exercise session associated with graph 1408. In one example, graphs 1424 and 1426 may be plotted as tissue oxygenation percentage on a y-axis 1420 versus percentage of time to an end of exercise session on an x-axis 1422. In one example, graphs 1406, 1408, 1424, and 1426 may share a common x-axis scale.

In one implementation, graph 1426, which is plotted using data from a constant work rate exercise session with a constant work rate at approximately 15% above a critical intensity for the user, may exhibit a steep slope between points 1432 and 1434 at the beginning of the exercise session (i.e. between approximately 0 and 20% of the time to the end of the exercise session). However, a graph 1426 may transition to a shallower slope between points 1434 and 1430 as the constant work rate exercise session is completed.

In one example, graph 1424, which may commence at a work rate below a critical intensity, may exhibit a shallower slope between points 1432 and 1428. Accordingly, point 1428 may approximately correspond to a point at which the ramped exercise intensity session associated with graph 1406 reaches the critical intensity for the user (i.e. transitions from a heavy to a severe exercise intensity domain for the user). As such, a slope of the graph 1424 may steepen between points 1428 and 1430. Accordingly, in one example, a slope of graph 1424 between points 1428 and 1430 may represent a slope with absolute value above a threshold value, said threshold value corresponding to a critical intensity for the user. In one example, a slope of graphs 1424 between points 1428 and 1430 may be approximately equal to a slope of graph 1426 between points 1432 and 1434.

FIG. 15 is a flowchart diagram 1500 that may be executed as one or more processes, such as by device 700, to determine if received tissue oxygenation data represents exercise by a user at a critical intensity. In one example, tissue oxygenation data may be received from a sensor, such as sensor 710 associated with the device 700. As such, the tissue oxygenation data may correspond to muscle oxygenation, and may be expressed as muscle oxygenation percentages. Accordingly, one or more processes may be executed to receive tissue oxygenation data from a sensor at block 1502 of process 1500. Further, tissue oxygenation data may be received from a sensor, such as sensor 710, with any periodicity, or at non-periodic intervals, without departing from the scope of these disclosures. In one implementation, data received from a tissue oxygenation sensor at block 1502 may be stored in memory, such as memory 704.

In one example, a change in tissue oxygenation may be calculated as a difference between a current rolling average and a previous rolling average of tissue oxygenation. Accordingly, a current rolling average may be calculated as an average value of tissue oxygenation percentage over a first duration, whereby the current rolling average may include a most-recently received sensor data point. In another implementation, a current rolling average may be calculated as an average value of tissue oxygenation percentage over a predetermined number of received sensor data points (which may be received with a periodicity, or non-periodically). In certain specific examples, a current rolling average may be calculated as an average muscle oxygenation percentage for those muscle oxygenation percentage data points received during the past five seconds, including a most-recently received data point. However, alternative times for the first duration may be utilized, without departing from the scope of these disclosures. For example, the first duration may be one second, two seconds, three seconds, four seconds, and six seconds, seven seconds, eight seconds, nine seconds, ten seconds, or any other duration. Further, the previous rolling average may be calculated as an average value of tissue oxygenation percentage over a second duration, whereby the previous rolling average does not include the most-recently received sensor data point (i.e. may include at least all the data points used to calculate the current rolling average, except the most-recently received sensor data point). In one example, the previous rolling average may be calculated for a second duration, equal to the first duration. In one implementation, the difference between the present rolling average, and the previous rolling average may be calculated by subtraction, thereby resulting in a percentage muscle oxygenation difference. In one implementation, one or more processes utilized to calculate a change in tissue oxygenation may be executed at block 1504 of process 1500, and by, in one example, processor 702.

In order to determine whether a calculated change in tissue oxygenation corresponds to a critical tissue oxygenation (critical intensity) for a given user, the calculated change in tissue oxygenation may be compared to a threshold value. In one example, this threshold value of change in tissue oxygenation percentage may include any oxygenation value. In one specific example, the threshold value of change in tissue oxygenation percentage may be less than 0.1 (i.e. the received tissue oxygenation percentage may not correspond to a critical tissue oxygenation percentage unless a difference between a current rolling average of tissue oxygenation percentage and a previous rolling average is less than 0.1 (units of tissue oxygenation percentage)). In another example, the received tissue oxygenation percentage may not correspond to a critical tissue oxygenation percentage unless a difference between a current rolling average of tissue oxygenation percentage and a previous rolling average is less than or equal to 0.1 (units of tissue oxygenation percentage). Additional or alternative tissue oxygenation thresholds may include 0.2, 0.3, 0.4, 0.5, 0.6 among others. In one example, one or more processes may be executed to determine whether a change in tissue oxygenation is less than a threshold at decision block 1506 of process 1500.

If it is determined that a calculated change in tissue oxygenation is greater than or equal to a threshold value (or in another implementation, if it is determined that a calculated change in tissue oxygenation is greater than to a threshold value), one or more processes may be executed to output a signal indicating that the user is not exercising at a critical tissue oxygenation. Accordingly, these one or more processes may be executed at block 1510, and by a processor, such as processor 702. If, however, it is determined that the calculated change in tissue oxygenation is less than a threshold value (or in another implementation, less than or equal to the threshold value), flowchart 1500 may proceed to decision block 1508.

Accordingly, decision block 1508 may represent one or more processes executed to determine whether the change in tissue oxygenation (that is less than the previously-described threshold value, or in another implementation, less than or equal to the threshold value) is consistent/steady for a threshold duration (i.e. that the change in tissue oxygenation percentage is less than a threshold change, and for a predetermined threshold duration). Accordingly, any threshold duration may be utilized with these disclosures. In certain specific examples, the threshold duration may be equal to at least one second, at least two seconds, at least three seconds, at least four seconds, at least five seconds, or at least 10 seconds, among others. If it is determined that the calculated change in tissue oxygenation is not consistent for the threshold duration, flowchart 1500 may proceed to block 1510. If, however, it is determined that the calculated change in tissue oxygenation is consistent for the threshold duration, flowchart 1500 may proceed to block 1512.

As such, upon determining that the calculated change in tissue oxygenation is consistent for a threshold duration, one or more processes may be executed to output a signal indicating that a user is exercising at a critical work rate/critical tissue oxygenation (which may be expressed as a tissue oxygenation percentage). These one or more processes configured to output a signal indicating that the user is exercising at a critical work rate may be executed by processor 702. Further, one or more processes may be executed at block 1512 to output a tissue oxygenation percentage corresponding to those received sensor values for which the difference between the current rolling average and previous rolling average is less than the threshold. This tissue oxygenation percentage may be a critical tissue oxygenation percentage for the user.

In one example, there may be variation in a critical muscle oxygenation percentage calculated for a user during different times of a same exercise. Accordingly, in one example, the critical tissue oxygenation percentage outputted at block 1512 may be averaged across multiple separately-calculated critical tissue oxygenation percentages for a same user during an exercise session, among others.

In one implementation, the tissue oxygenation discussed in relation to flowchart 1500, as well as throughout this disclosure, may comprise a muscle oxygenation for any muscle within a user's body. Further, this calculated critical tissue oxygenation percentage value may be utilized to calculate an anaerobic work capacity (M′) for the user (in one example, this anaerobic work capacity may be expressed as a total number of muscle oxygenation points), and calculated as a difference between a current muscle oxygenation percentage (MO_{2 current}) (above the critical muscle oxygenation percentage) and the critical muscle oxygenation percentage (MO_{2 crit}), summed over a duration of an exercise session to fatigue:

M′=Σ _t=0 ^fatigue(MO_{2 current}−MO_{2 crit}) (Units: muscle oxygenation points);  (First anaerobic work capacity equation)

FIG. 16 depicts a graph 1602 of muscle oxygenation percentage (%) plotted on the y-axis 1604 versus duration (time) (s) on the x-axis 1606. In one example, graph 1602 comprises data points 1608, 1610, 1612, and 1614, wherein data points 1608, 1610, 1612, and 1614 represent separate exercise sessions. As such, a data point, from data points 1608, 1610, 1612, and 1614, may be associated with a total time of an exercise session, and a muscle oxygenation percentage associated with that exercise session. In one example, this muscle oxygenation percentage may be an average muscle oxygenation over the total time of the exercise session. In another example, this muscle oxygenation percentage may be a muscle oxygenation percentage at the end of the exercise session, among others. In one implementation, graph 1602 displays a trend in muscle oxygenation percentage for different exercise session durations. In particular, graph 1602 may indicate that a comparatively shorter exercise session, such as that exercise session associated with data point 1614, may be associated with a lower muscle oxygenation percentage. This trend may be due to a user exercising at a comparatively higher work rate for a comparatively shorter time. In contrast to a data point 1614, data point 1608 may be associated with a comparatively longer exercise session, and may be associated with a higher muscle oxygenation percentage as a result of a user exercising for a comparatively longer time, and adopting, in one example, a less strenuous pacing strategy in order to conserve energy for the comparatively longer exercise session duration. In one example, graph 1602 may comprise a curvilinear regression plotted through data points 1608, 1610, 1612, and 1614. As such, any processes known in the art may be utilized to construct graph 1610, without departing from these disclosures.

FIG. 17 depicts two graphs of data generated during a same exercise session. The two depicted graphs include muscle oxygenation percentage data 1702 and running speed data 1704 plotted against a common timescale 1706. In one implementation, the muscle oxygenation percentage data 1702 may be generated by a muscle oxygenation sensor, such as sensor 710. Further, the running speed data 1704 may be calculated based on sensor data generated by sensor 706, which may include, among others, an accelerometer, or a location-determining sensor. Accordingly, the graph of running speed 1702 may be associated with scale 1708, and the graph of muscle oxygenation 1704 may be associated with scale 1710. In one example, graphs 1702 and 1704 schematically depict relationships between muscle oxygenation percentage and a running speed. In one implementation, given the critical intensity (critical running speed) denoted by line 1712, and the critical intensity (critical muscle oxygenation percentage) denoted by line 1714, a relationship between the speed 1702, and the muscle oxygenation percentage 1704 may be recognized. In particular, when a user's speed is below a critical speed, such as within shaded area 1716, a corresponding muscle oxygenation percentage for the user will be above a critical muscle oxygenation percentage 1714, such as within that shaded area 1718, and vice versa.

FIG. 18 depicts a graph 1802 of power on a y-axis 1804 versus time on the x-axis 1806 for an exercise session. As will be readily appreciated, the data associated with FIG. 18 may be derived from any exercise/sport type, without departing from the scope of these disclosures. For example, the graph 1802 may comprise data outputted from a power sensor during a running session, cycling session, tennis game, basketball game, or soccer game, among others. In one example, graph 1802 may comprise power data received by a processor, such as processor 702 of activity monitoring device 700. As such, the activity monitoring device 700 may comprise, or may be configured to communicate with, a power sensor from which power data is directly outputted, or from which power values may be calculated. Accordingly, as described herein, a power sensor may comprise an accelerometer from which acceleration data input may be utilized to calculate a user's speed, and further, a user's rate of energy consumption (power). In another example, a power sensor may comprise a dynamometer that may be operatively coupled to an exercise bike on which a user is exercising, among others.

In one example, the data points 1808, 1810, and 1812 may represent calculated critical power values for the user. Accordingly, in one example, these critical power values may be calculated using one or more processes described in relation to FIG. 19. As such, FIG. 19 depicts a flowchart diagram 1900 that may be executed by activity monitoring device 700. In one implementation, flowchart diagram 1900 may be utilized to calculate a critical power associated with an exercise session undertaken by a user. Further, this exercise session may comprise at least a portion undertaken within a severe exercise intensity domain. In one example, flowchart diagram 1900 may utilize a tissue oxygenation sensor, such as sensor 710, and a power sensor, which may comprise one or more of a dynamometer, or an accelerometer, among others. In one example, the tissue oxygenation sensor may be configured to output data indicative of a tissue oxygenation percentage with a periodicity, or at a non-periodic rate. Accordingly, a periodicity with which the tissue oxygenation sensor outputs data points indicative of a tissue oxygenation percentage may have any value, without departing from the scope of these disclosures. Further, the activity monitoring device 700 may execute one or more processes to receive tissue oxygenation data at block 1902 of flowchart 1900. The activity monitoring device 700 may, in one example, execute one or more processes to receive power data from a sensor, at block 1903 of flowchart 1900.

A change in tissue oxygenation may be calculated as a difference between a current tissue oxygenation value and a previous tissue oxygenation value. Accordingly, in one implementation, the current tissue oxygenation value may correspond to a rolling average, and similarly, the previous tissue oxygenation value may correspond to a previous rolling average of tissue oxygenation. As such, the current rolling average may be calculated as an average value of tissue oxygenation percentage over a first duration, whereby the current rolling average may include a most-recently received sensor data point. In another implementation, a current rolling average may be calculated as an average value of tissue oxygenation percentage over a predetermined number of received sensor data points (which may be received with a periodicity, or at a non-periodic rate). In certain specific examples, a current rolling average may be calculated as an average muscle oxygenation percentage for those muscle oxygenation percentage data points received during the past five seconds, including a most-recently received data point. However, alternative times for this first duration may be utilized, without departing from the scope of these disclosures. For example, the first duration may be at least one second, two seconds, three seconds, four seconds, and six seconds, seven seconds, eight seconds, nine seconds, ten seconds. In another example, the first duration may range between zero and one seconds, one and three seconds, two and six seconds, or five and ten seconds, or any other duration or time range.

In one example, the previous rolling average may be calculated as an average value of tissue oxygenation percentage over a second duration, whereby the previous rolling average may not include the most-recently received sensor data point (i.e. may include at least all the data points used to calculate the current rolling average, except the most-recently received sensor data point). In one example, the previous rolling average may be calculated for a second duration, equal to the first duration. In one implementation, the difference between the current rolling average, and the previous rolling average may be calculated by subtraction, thereby resulting in a percentage muscle oxygenation difference. In one implementation, one or more processes utilized to calculate a change in tissue oxygenation may be executed at block 1904 of process 1900, and by, in one example, processor 702.

In one implementation, in order to determine whether a calculated change in tissue oxygenation corresponds to a critical tissue oxygenation (critical intensity) for a given user, the calculated change in tissue oxygenation may be compared to a threshold value. In one example, this threshold value of change in tissue oxygenation percentage may include any oxygenation value. In one specific example, the threshold value of change in tissue oxygenation percentage may be less than or equal to 0.1 (i.e. the received tissue oxygenation percentage may not correspond to a critical tissue oxygenation percentage unless a difference between a current rolling average of tissue oxygenation percentage and a previous rolling average is less than or equal to 0.1 (units of tissue oxygenation percentage)). Additional or alternative tissue oxygenation thresholds may include, among others, 0.2, 0.3, 0.4, 0.5, 0.6. In one example, one or more processes may be executed to determine whether a change in tissue oxygenation is less than a threshold at decision block 1906 of process 1900.

If it is determined that a calculated change in tissue oxygenation is greater than a threshold value, one or more processes may be executed to output a signal (output to, in one example, an interface, such as a graphical user interface, or a wireless interface/transceiver) indicating that the user is not exercising at a critical tissue oxygenation. Accordingly, these one or more processes may be executed at block 1910, and by a processor, such as processor 702. If, however, it is determined that the calculated change in tissue oxygenation is less than or equal to a threshold value, flowchart 1900 may proceed to decision block 1908.

Accordingly, decision block 1908 may represent one or more processes executed to determine whether the change in tissue oxygenation (that is less than or equal to the previously-described threshold value) is consistent/steady for a threshold duration (i.e. that the change in tissue oxygenation percentage is less than or equal to a threshold change, and for a predetermined threshold duration). Accordingly, any threshold duration may be utilized with these disclosures. In certain specific examples, the threshold duration may be equal to at least one second, at least two seconds, at least three seconds, at least four seconds, at least five seconds, or at least 10 seconds, or range between approximately 1 and 10 seconds, or 5 and 15 seconds, among others. If it is determined that the calculated change in tissue oxygenation is not consistent for the threshold duration, flowchart 1900 may proceed to block 1910. If, however, it is determined that the calculated change in tissue oxygenation is consistent for the threshold duration, flowchart 1900 may proceed to block 1912.

As such, upon determining that the calculated change in tissue oxygenation is consistent for a threshold duration, one or more processes may be executed to output a signal indicating that a user is exercising at a critical work rate/critical tissue oxygenation. Specifically, in one example, one or more processes may be executed to output a critical power of the user equal to the current power as indicated by the power sensor at a time corresponding to the identified critical tissue oxygenation. Alternatively, a critical power may correspond to an average power as indicated by the power sensor over a time period corresponding to the calculation of the calculated consistent change in tissue oxygenation. As such, these one or more processes configured to output a critical power to an interface may be executed by processor 702. Further, one or more processes may be executed at block 1912 to output the critical power corresponding to those received sensor values for which the difference between the current rolling average and previous rolling average is less than or equal to the threshold.

In one example, there may be some degree of variation in a calculated/identified critical power for a user based upon multiple calculations of the critical muscle oxygenation during different times of a same exercise. Accordingly, in one example, the critical power outputted at block 1912 may be averaged across multiple separately-calculated critical tissue oxygenation percentages for a same user during an exercise session, among others. Accordingly, in one example, the data points 1808, 1810, and 1812 may represent exemplary data points from a plurality of critical power results corresponding to multiple calculations of critical tissue oxygenation of the user. As such, in one example, the critical power values associated with data points 1808, 1810, and 1812 may be averaged.

In one implementation, the tissue oxygenation discussed in relation to flowchart 1900, as well as throughout this disclosure, may comprise a muscle oxygenation for any muscle within a user's body. Further, the critical power value calculated at block 1912 may be utilized to calculate an anaerobic work capacity (W′) for the user (in one example, this anaerobic work capacity may be expressed as a power (units: W)), and calculated as a difference between a current muscle oxygenation percentage (Power_current) (above the critical muscle oxygenation percentage) and the critical power (Power_crit), summed over a duration of an exercise session. As such, these calculated differences may be referred to as positive difference values. In one example, an exercise session may end in user fatigue. Accordingly, one or more processes utilized to calculate an anaerobic work capacity may be executed by processor 702 at block 1914:

W′=Σ _t=0 ^fatigue(Power_current−Power_crit) (Units: W);  (Second anaerobic work capacity equation)

In certain examples, a critical velocity and an anaerobic work capacity for a user may be calculated based upon sensor output data indicating, or used to calculate, a speed of the user. As such, a critical velocity and an anaerobic work capacity for a user may be calculated based upon sensor data received from, among others, an accelerometer, a location-determining sensor, or a bicycle speedometer, and without utilizing a tissue oxygenation sensor, as previously described. In one implementation, the present disclosure describes results of a plurality of validation tests utilized to validate a relationship between speed data and a critical intensity for a user. Accordingly, in one example, an end speed may be calculated in order to estimate a critical speed for a user.

FIG. 20 depicts a graph 2000 that may be utilized to calculate an end speed of the user during an exercise session, and comprising speed on the y-axis 2002 versus time on the x-axis 2004. The plotted data points, of which data points 2006, 2008, 2010 are an exemplary sub-set, comprise measurements of a speed of the user at a given time during a same exercise session. In one example, the end speed, denoted by line 2012, may be calculated as an average of a sub-set of the plurality of data points that make up the graph 2000. In particular, the end speed 2012 may be calculated as an average of those data points during a final 30 seconds of the duration of the exercise session (e.g. an average of those data points between lines 2014 and 2016). However, an end speed may be calculated as an average speed for different durations, such as, among others, a final 20 seconds, 10 seconds, or 5 seconds of an exercise session, or any other duration. In one example, graph 2000 may represent data points associated with an exercise session having a prescribed duration. Accordingly, the prescribed duration may range from 1 minute to 10 minutes. In one specific example, the exercise session associated with graph 2000 may be a three minute all-out trial, whereby a user is instructed to exercise as a highest subjective intensity level for the prescribed duration (three minutes). Additional or alternative exercise session prescriptions (times and/or intensity levels) may be utilized without departing from the scope of these disclosures.

In one example, based upon validation testing comparing calculated end speeds for multiple users across multiple separate exercise sessions, a relationship between a calculated end speed and a critical speed for a given user may was identified. In particular, for a plurality of validation tests, 90% of a sample population of users were found to be able to sustain exercise for up to 15 minutes when exercising between 5% and 10% below a calculated end speed for a three minute all-out trial. Additionally, for the plurality of validation tests, 85% of the sample population of users were found to be able to sustain exercise for up to 20 minutes when exercised between 5% and 10% below the calculated end speed for the three minute all-out trial. Accordingly, in one example, a critical velocity for a user may be estimated by reducing a calculated end speed by 5 to 10% (e.g. calculating 90-95% of an end speed of a user). In one specific example, a critical velocity may be estimated for a user by calculating 92.5% of an end speed, among others.

In one implementation, an anaerobic work capacity, expressed as a distance, it may be calculated based upon a calculated end speed for a user. Accordingly, from a plurality of validation testing comparing a distance above end speed to an anaerobic work capacity for a given user, it was found that an anaerobic work capacity may be estimated by increasing a calculated end speed by, in one example, 25% to 35%. In another specific example, an anaerobic work capacity may be estimated by increasing the calculated end speed by 30%. Accordingly, in one example, the distance above end speed may be as that area 2018 from FIG. 20 (e.g. an integration of differences between speed data points and the calculated end speed 2012 across the duration of the exercise session associated with graph 2000).

FIG. 21 is a flowchart diagram 2100 that may be utilized to calculate a critical speed and an anaerobic work capacity for a user based upon sensor data indicative of a speed of the user. Accordingly, in one example, one or more processes associated with flowchart diagram 2100 may be executed by an activity monitoring device, such as device 700. It is noted that flowchart diagram may utilized a sensor, such as sensor 706 of device 700, but may not utilize an oxygenation sensor, such as sensor 710. In one example, the activity monitoring device 700 may receive sensor data from a sensor, such as sensor 706. The received sensor data may comprise data points indicative of a speed of the user at various time points during an exercise session. In another example, the received sensor data points may comprise data indicative of a location of the user, and may be utilized to calculate a speed. In one example, data points may be received periodically, and with any periodicity, without departing from the scope of these disclosures. The received data points may be associated with an exercise session having a prescribed duration and intensity. In particular, the exercise session may comprise a three minute all-out trial that instructs a user to exercise as a highest subjective intensity for a three minute duration. In another example, a prescribed duration of 2 to 5 minutes maybe utilized. In other examples, alternative durations may be utilized, without departing from the scope of these disclosures. In one example, one or more processes may be executed to receive sensor data at block 2102 of flowchart 2100.

An end speed may be calculated from received sensor data as an average speed of a sub-set of a plurality of sensor data points received during an exercise session. In one specific example, an end speed may be calculated as an average speed during a last 30 seconds of the prescribed duration of the exercise session. However, alternative sub-sections of a prescribed duration of an exercise session may be utilized to calculate an end speed, without departing from the scope of these disclosures. In one example, one or more processes may be executed, such as by a processor 702 to calculate an end speed at block 2104 of flowchart 2100.

A distance above the end speed may be calculated by summing differences between instantaneous speeds (Speed_current) and the calculated end speed (Speed_end) across the duration of the exercise session (i.e. between time t=0 and the end of the session, time t=session end). In one implementation, one or more processes may be executed to calculate a distance above an end speed at block 2106 of flowchart 2100:

Distance above end speed=Σ_t=0^{session end}(Speed_current−Speed_end) (Units: m);   (Distance above end speed equation)

In one example, a critical speed may be calculated/estimated based upon the calculated end speed. In one implementation, a critical speed may be calculated by decreasing the calculated end speed by between 5 and 10%:

Speed_critical=Speed_end*(90-95%).

In one specific example, a critical speed may be calculated as 92.5% of a calculated end speed:

Speed_critical=Speed_end*(92.5%).

In one implementation, one or more processes may be executed to calculate a critical speed, based upon the calculated end speed, at block 2108 of flowchart 2100.

In one example, an anaerobic work capacity may be calculated based upon the calculated distance above an end speed. Accordingly, the anaerobic work capacity may be calculated as 125% to 135% of a distance above the calculated end speed:

Anaerobic work capacity=(distance above end speed)*(125-135%).

In one specific example, an anaerobic work capacity may be calculated as 130% of a distance above the calculated end speed:

Anaerobic work capacity=(distance above end speed)*(130%).

In one implementation, one or more processes may be executed to calculate the anaerobic work capacity, based upon the calculated distance above the end speed, at block 2110 of flowchart 2100.

In one implementation, a critical speed and an anaerobic work capacity associated with a user may be calculated from data received from a sensor configured to output data indicative of a distance traveled by the user during an exercise session (e.g. distance traveled while running, cycling, and the like). As such, the sensor may comprise one or more of an accelerometer, a location determining sensor, or a bicycle speedometer, among others. As such, the sensor may be configured to output data indicative of a location of a user, which may in turn be used to calculate a distance traveled by the user, as well as to determine a time taken to travel the recorded distance. Accordingly, FIG. 22 schematically depicts a flowchart diagram 2200 that may be utilized to calculate one or more of a critical speed and/or an anaerobic work capacity of a user from data outputted from a sensor, such as sensor 706.

In one implementation, in order to calculate one or more of a critical speed and/or an anaerobic work capacity, a user may provide an activity monitoring device, such as device 700, with test data. In one example, test data may be generated by a sensor, such as sensor 706, during an exercise period, which may otherwise be referred to as an exercise session. In one example, an exercise period may comprise a prescribed duration during which a user is instructed to run as quickly as possible (i.e. as far as possible) within the prescribed time limit. In certain specific examples, an exercise period may instruct a user to run as far as possible within, for example, a minute, two minutes, three minutes, four minutes, five minutes, six minutes, seven minutes, eight minutes, nine minutes, 10 minutes, 12 minutes, 15 minutes, 20 minutes, or any other duration. Accordingly, a sensor, such as sensor 706, may be configured to output a location of the user for each second of an exercise period. In turn, this location data may be utilized to calculate a total distance traveled by the user during the exercise period. Alternatively, the sensor 706, may be configured to a location data point at a different frequency, which may be 0.25 Hz, 0.5 Hz, 2 Hz, 3 Hz, 4 Hz, or any other frequency. In one example, an exercise period prescribed for a user in order to generate test data may ensure that the user exercises at an intensity above a critical intensity for the user during at least a portion of the prescribed duration of the exercise period. Accordingly, in one example, one or more processes may be executed to instruct a user to begin an exercise period at block 2202 of flowchart 2200.

In one example, the sensor 706 may output a data point indicative of a current location and/or a distance traveled by the user for each second of an exercise period. Accordingly, in one example, the outputted data may be received for further processing by, in one example, processor 702, at block 2204 of flowchart 2200.

In one implementation, a data point associated with each second of a prescribed exercise period may be stored. As such, location data for each second of a prescribed exercise period may be stored in, for example, memory 704. Upon completion of a given exercise period, a total distance traveled during a prescribed exercise period may be calculated. In one implementation, this total distance traveled may be calculated by, in one example processor 702, and at block 2206 of flowchart 2200.

In one example, an exercise period utilized to generate data in order to determine a critical speed and/or an anaerobic work capacity of the user may be summarized as a data point comprising two pieces of information. This exercise period summary data point may comprise the total distance traveled, as determined, in one example, at block 2206, in addition to the total time (i.e. the duration) of the exercise period/session. In one example, the two pieces of information (i.e. the total distance, and the total time) may be expressed as a coordinate point. In one example, this coordinate point P may be of the form P(x₃, y₃), where y₃ may be the total distance (m), and x₃ may be the total time (s). In this way, the exercise period summary data point expressed as a coordinate point may be plotted, as schematically depicted in FIG. 23. In one example, the exercise period summary data point may be calculated at block 2208 of flowchart 2200.

In one implementation, in order to calculate one or more of a critical speed and/or an anaerobic work capacity of a user, two or more exercise period summary data points may be utilized. In one example, the durations of the exercise periods used to generate the two or more exercise period summary data points may be different. Accordingly, in one example, one or more processes may be executed to determine whether a threshold number of exercise periods have been completed by the user in order to calculate one or more of a critical speed and/or an anaerobic work capacity for the user. As previously described, this threshold number of exercise periods may be at least two, at least three, at least four, or at least five, among others. In one specific example, one or more processes may be executed by processor 702 to determine whether the threshold number of exercise periods have been completed at decision block 2210 of flowchart 2200. Accordingly, if the threshold number of exercise periods has been met or exceeded, flowchart 2200 proceeds to block 2212. If, however, the threshold number of exercise periods has not been met, flowchart 2200 proceeds from decision block 2210 back to block 2202.

In one example, a regression may be calculated using the two or more exercise period summary data points that were calculated from two or more prescribed exercise periods. In one example, this regression may be a linear, or a curvilinear regression. As such, any computational processes known in the art for calculation of a linear or curvilinear regression may be utilized with this disclosure. In one implementation, at least a portion of a calculated regression may be utilized to determine one or more of a critical tissue oxygenation percentage and/or an anaerobic work capacity of the user. In one specific example, one or more processes may be executed to calculate a regression at block 2212 of flowchart 2200.

In one example, at least a portion of a regression calculated using the two or more exercise period summary data points may be utilized to determine a critical speed for a user. Specifically, the critical speed may correspond to a slope of the regression line (or a slope of a linear portion of a curvilinear regression). In one implementation, one or more processes may be executed to output a critical speed calculated as a slope of a regression line through the two or more exercise period summary data points at block 2214 of flowchart 2200.

In another example, at least a portion of a regression calculated using the two or more exercise period summary data points may be utilized to determine an anaerobic capacity for of the user. Specifically, the anaerobic capacity may correspond to an intercept of the regression line (or an intercept of a linear portion of a curvilinear regression). In one example, the anaerobic capacity may be expressed as a total distance (m) above a critical speed (m/s). In one implementation, one or more processes may be executed to output an anaerobic capacity calculated as an intercept of a regression line through the two or more exercise period summary data points, at block 2216 of flowchart 2200.

FIG. 23 is a chart that plots testing data from multiple exercise sessions for a given user.

In particular, FIG. 23 is a chart 2300 plotting distance 2302 against time 2304. Points 2306, 2308, 2310, and 2312 may each represent a separate exercise sessions, and such that at least a portion of each of these exercise sessions is carried out within a severe exercise intensity domain for the user. In one implementation, the exercise period summary data points 2306, 2308, 2310, and 2312 may each represent a separate exercise session carried out in a continuous manner. However, in another implementation, one or more of the exercise period summary data points 2306, 2308, 2310, and 2312 may represent a separate exercise session carried out in an intermittent manner.

In one implementation, a regression line 2314 may be calculated using the four exercise period summary data points 2306, 2308, 2310, and 2312, as plotted on chart 2300. In one example, this regression line 2314 may be of the form:

y=m _d x+c _d

where y is a total distance (y-axis), x is a time (s) (x-axis), m_d is the slope of the regression line 2314 and c_d is the intercept of the regression line 2314 on the y-axis.

For the example experimental data used to generate the exercise period summary data points 2306, 2308, 2310, and 2312, the regression line 2314 may have the form: y=4.21x+181.96, with an r² value of 0.99979. It is noted that this regression line 2314 formula is merely included as one example result.

In one example, a regression line, such as regression line 2314, through two or more exercise period summary data points, such as the exercise period summary data points 2306, 2308, 2310, and 2312, may be used to calculate a critical speed and/or a total distance above a critical speed (D′) (which may be proportional to an anaerobic work capacity) for a user. In one example, given regression line 2314 of the form: y=mx+c, the critical speed may be equal to m, the slope of the regression line 2314, and the total distance above the critical speed may be equal to c (or |c|, the absolute value of c), the intercept of the regression line 2314 on the y-axis. In particular, given the experimental data depicted in chart 2300, the critical speed for the user may be 4.21 m/s and the total distance above the critical speed may be 181.96 m.

In certain examples, a critical velocity, a critical power, and/or an anaerobic work capacity may be calculated based upon a single input data point. In one implementation, this single input data point may comprise a race time (comprising a distance and a time taken to complete the race distance). In one example, a race time may be utilized based upon an assumption that at least a portion of the race was carried out within a severe exercise intensity domain. However, a single input data point comprising a distance completed and a time taken to complete the distance derived from an exercise session other than a race (i.e. an informal running session untaken by a user) may be utilized with the systems and methods described herein. In another implementation, a single input data point may be utilized to calculate a critical power and/or an anaerobic work capacity, and such that the single input data point may comprise the total amount of work done, and a total time taken.

In one implementation, a single input data point may be utilized to calculate one or more of a critical velocity, critical power, and/or an anaerobic work capacity based upon relationships (models) developed through analysis of multiple exercise sessions by multiple different users. In particular, FIG. 24 depicts a model 2402 that may be utilized to predict a fraction of a critical velocity (y-axis 2404) based upon an input of a total athletic session time (x-axis 2406) for running. The data points 2408, 2410, and 2412 are exemplary data points from a plurality of data points that may be utilized to develop the model 2402. Accordingly, data points 2408, 2410, and 2412 may represent separate exercise sessions (for a running exercise session) by a same user, or by different users. In one example, model 2402 may be of the form: y=1.8677*x^−0.082, with an r² value of 0.6816. In another example, model 2402 may be of the form: y=1.87*x^−0.1.

FIG. 25 depicts a model 2502 that may be utilized to predict a fraction of a critical velocity (y-axis 2504) based upon an input of a total athletic session distance (x-axis 2506) for a running exercise session. The data points 2508, 2510, and 2512 are exemplary data points from a plurality of data points that may be utilized to develop the model 2502. Accordingly, data points 2508, 2510, and 2512 may represent separate exercise sessions (for a running exercise session) by a same user, or by different users. In one example, model 2502 may be of the form: y=2.2398*x^−0.09, with an r² value of 0.6779. In another example, model 2502 may be of the form: y=2.2*x^−0.1.

FIG. 26 depicts a model 2602 that may be utilized to predict a fraction of a critical velocity (y-axis 2604) based upon an input of a total athletic session time (x-axis 2606) for cycling. The data points 2608, 2610, and 2612 are exemplary data points from a plurality of data points that may be utilized to develop the model 2602. Accordingly, data points 2608, 2610, and 2612 may represent separate exercise sessions (for a cycling exercise session) by a same user, or by different users. In one example, model 2602 may be of the form: y=1.9199*x^−0.088, with an r² value of 0.8053. In another example, model 2602 may be of the form: y=1.9*x^−0.1

FIG. 27 depicts a model 2702 that may be utilized to predict a fraction of a critical velocity (y-axis 2704) based upon an input of a total amount of energy expended during an athletic session (x-axis 2706) for cycling. The data points 2708, 2710, and 2712 are exemplary data points from a plurality of data points that may be utilized to develop the model 2702. Accordingly, data points 2708, 2710, and 2712 may represent separate exercise sessions (for a cycling exercise session) by a same user, or by different users. In one example, model 2702 may be of the form: y=3.0889*x^−0.086, with an r² value of 0.6769. In another example, model 2702 may be of the form: y=3.1*x^−0.1

In one implementation, models 2402, 2502, 2602, and/or 2702 may be calculated using any mathematical modeling methodology known in the art (e.g. regression modeling methodologies, among others).

FIG. 28 is a flowchart diagram 2800 that may be utilized to calculate one or more of a critical velocity (or critical power) and an anaerobic work capacity based upon a single input data point. Accordingly, the one or more processes associated with flowchart 2800 may be executed by a processor, such as processor 702. In one example, a single input data point may comprise a total time in combination with a total distance for an exercise session. In one example, at least a portion of the exercise session may be carried out within a severe exercise intensity domain. In another example, a single input data point may comprise a total power expended and a total time associated with an exercise session. Accordingly, one or more processes executed to receive the single input data point may be executed at block 2802. In one specific example, a data point may indicate that a user completed a 5 km race in 1300 seconds.

A mathematical model may be utilized to calculate a critical velocity fraction or a critical power fraction. Accordingly, an input to a model, from, in one example, models 2402, 2502, 2602, and/or 2702, may comprise a total distance traveled during an exercise session, a total time to complete an exercise session, or a total power expended during an exercise session. Further, the selection of a model, from, in one example, models 2402, 2502, 2602, and/or 2702, may be based upon an activity type (e.g. running or cycling, among others). In one implementation, one or more processes may be executed to calculate a critical velocity fraction or a critical power fraction at block 2804 of flowchart 2800. For the specific example of a 5 km race run completed in 1300 seconds, the critical velocity fraction may be calculated as y=1.8677*(1300)^−0.082 (model 2402), which implies that the critical velocity fraction (y)=1.045.

Additionally, an average velocity may be calculated as a total exercise session distance divided by a total time taken to complete the distance. In another implementation, an average exercise session power may be calculated as a total exercise session power divided by a total time taken to complete the exercise. Accordingly, one or more processes may be executed to calculate an average exercise session velocity, or an average exercise session power, at block 2806 of flowchart 2800. For the specific example of a 5 km race run in 1300 seconds, the average exercise session velocity may be 5000/1300=3.85 m/s.

A critical velocity may be calculated as an average velocity divided by the critical velocity fraction. Alternatively a critical power for a user may be calculated as an average power divided by the critical power fraction. Accordingly, one or more processes may be executed to calculate a critical velocity, or a critical power, at block 2808 of flowchart 2800. For the specific example of a 5 km race run in 1300 seconds, the critical velocity may be calculated as 3.85/1.045=3.68 m/s.

A total distance traveled below a critical velocity may be calculated as an average velocity multiplied by a total time associated with an exercise session. Alternatively, the total amount of energy expended below a critical power may be calculated as an average power multiplied by a total time associated with an exercise session. Accordingly, one or more processes may be executed to calculate a total distance traveled below a critical velocity, or a total amount of energy expended below a critical power, at block 2810 of flowchart 2800. For the specific example of a 5 km race run in 1300 seconds, the distance traveled below the critical velocity may be calculated as 3.68*1300=4784 m.

An anaerobic work capacity may be calculated as a distance above a critical velocity, or as a total amount of energy above a critical power. Accordingly, an anaerobic work capacity may be calculated (e.g. for running) as a difference between a total distance traveled during an exercise session and a total distance traveled below a critical velocity, as calculated at block 2810. Alternatively, an anaerobic work capacity may be calculated (e.g. for cycling) as a difference between a total amount of energy expended during an exercise session and a total amount of energy expended below a critical power, as calculated at block 2810. Accordingly, one or more processes may be executed to calculate an anaerobic work capacity at block 2812 of flowchart 2800. For the specific example of a 5 km race run in 1300 seconds, the distance traveled above the critical velocity (i.e. the anaerobic work capacity, D′) may be equal to 5000−4784=216 m.

In certain implementations, a volume of oxygen consumption associated with an exercise session participated in by a user may be estimated without using any sensors. In particular, a volume of oxygen consumption of the user may be estimated based upon an athletic profile constructed using one or more questions answered by the user. This questionnaire may be administered to the user in an electronic format, and may comprise one or more questions. In one example, answers to these questions may be based on a scale. In one example, the scale may comprise numbers from 0 to 10. However, additional or alternative scales may be utilized, without departing from the scope of these disclosures. Specifically, the questions may include, among others: an estimation of bone size, an estimation of leanness of the user, an estimation of muscle size, an estimation of sleep quality, an estimation of relaxation habits, an estimation of nutrition quality, an estimation of smoking status, an estimation of drinking habits, and an estimation of an activeness of the user. Additional or alternative questionnaire questions utilized to construct an athletic profile for the user may include, a user's age, gender, height, waist circumference, weight, as well as an indication as to whether the user is pregnant. Still further questionnaire questions may include an estimation of a 5 km running race pace (or a pace associated with another distance), and an estimation of a number of days active during the week.

FIG. 29 depicts a flowchart diagram 2900 that may be utilized to estimate a volume of oxygen consumption of the user in response to a received rate of perceived exertion of the user, and using an athletic profile constructed using one or more questionnaire questions. In particular, a user may be asked to respond to one or more questionnaire questions, which may include one or more of those questions described above. Accordingly, one or more processes may be executed by a processor, such as processor 702 to receive one or more questionnaire responses at block 2902 of flowchart 2900.

An athletic profile may be calculated and stored, such as within memory 704, based upon one or more of the received questionnaire responses. Accordingly, this athletic profile may account for one or more physical and/or behavioral attributes associated with user, which may impact a volume of oxygen consumption for the user. In one example, the athletic profile may estimate a maximal volume of oxygen consumption associated with user, based upon one or more physical and/or behavioral attributes of the user. Accordingly, one or more processes may be executed to calculate and store the athletic profile at block 2904.

In one example, a user may input a rate of perceived exertion following an exercise session. This rate of perceived exertion may be received by a processor, such as processor 702 via an interface, such as interface 708. In one example, the rate of perceived exertion may be received as a number on a scale of 0 to 10. However, those of ordinary skill in the art will recognize that additional or alternative scales may be utilized with his rate of perceived exertion, without departing from the scope of these disclosures. In one example, the rate of perceived exertion may be received from the user at block 2906.

The received rate of perceived exertion may be mapped to an oxygen consumption scale for the user, based upon the constructed athletic profile for the user. In one example, the scale of the rate of perceived exertion may be linearly mapped to a volume of oxygen consumption scale delimited by a maximal oxygen consumption estimated for the user based upon the calculated athletic profile for the user. In other implementations, nonlinear mappings of the rate of perceived exertion scale to the volume of oxygen consumption scale may be utilized, without departing from the scope of these disclosures. Accordingly, one or more processes to map the received rate of perceived exertion to the oxygen consumption scale may be executed at block 2908. Additionally, one or more processes may be executed to output an estimated volume of oxygen consumption, based upon the inputted rate of perceived exertion of the user, at block 2910.

In one example, an anaerobic work capacity of the user may be replenished when the user exercises at an intensity that is below a critical intensity (i.e. within a moderate or heavy exercise intensity domain). As previously described, an anaerobic work capacity may be expressed as a total number of muscle oxygenation points, as derived from muscle oxygenation sensor data, such as data outputted by oxygenation sensor 710. As such, the anaerobic work capacity may be denoted M′. In one example, replenishment of anaerobic work capacity may be denoted M′_rate and calculated as a difference between a current muscle oxygenation percentage and a critical muscle oxygenation percentage: M′_rate=% MO2−critical % MO2. In one example, the M′_rate may be continuously summed throughout a duration of an exercise period/trial in order to determine an M′ balance (i.e. a total number of muscle oxygenation points). Accordingly, when a current muscle oxygenation percentage is below the critical muscle oxygenation percentage, the calculated M′_rate may be negative, and indicative of a finite work capacity (anaerobic work capacity) being consumed. Further, when a current muscle oxygenation percentage is above the critical muscle oxygenation percentage for a user, the M′_rate may be positive, and the finite work capacity may be replenished. FIG. 30 schematically depicts this consumption and replenishment of total muscle oxygenation points. In particular, FIG. 30 graphs M′ replenishment on the y-axis 3002 for four different exercise intensity domains (i.e. severe 3004, heavy 3006, moderate 3008 and rest 3010). As such, FIG. 30 schematically demonstrates that an M′_rate associated with a severe exercise intensity domain may be negative, but the anaerobic work capacity of the user may be replenished as the user transitions to exercise within a heavy exercise intensity domain 3006, in a moderate exercise intensity domain 3008, and when the user is at rest 3010.

Various systems and methods are described in this disclosure for calculation of a critical intensity (critical velocity, or a critical power) for a user. Additionally, various systems and methods are described in this disclosure for calculation of an anaerobic work capacity/finite work capacity (M′, D′) associated with user. As such, given these calculated critical intensity and finite work capacity values, various activity metrics may be predicted. As such, those of ordinary skill in the art will recognize various methodologies that may be utilized predict athletic metrics using one or more of a critical intensity and a finite work capacity for a user, without departing from the scope of these disclosures. In one example a prediction of a time, t (s), to completion of an athletic event (e.g. a race), given a present velocity, v_p (m/s), a critical velocity, v_crit (m/s), and a finite work capacity, D′ (m), may be given by: t=D′/(v_p−v_crit).

In one implementation, the systems and methods described herein may be utilized to predict/calculate a power value associated with an athletic activity completed by a user. FIG. 31 is a flowchart diagram of one implementation for calculating a power value using sensor data generated during an athletic activity by a user. It is contemplated that the one or more processes described in relation to FIG. 31 may be executed by at least one processor, such as processor 202 described in relation to FIG. 2. Further, the one or more processes described in relation to FIG. 18 may utilize data received from one or more sensor devices, which may include one or more of devices 112, 126, 128, 130, and/or 400, among others. Accordingly, one or more of devices 112, 126, 128, 130, and/or 400 may be configured to output sensor data responsive to motions of a user's body during an athletic activity. It is contemplated that the one or more sensors may be positioned on the user (e.g. on an appendage, torso, or head of the user, among others), or may remotely monitor the user's motion. It is further contemplated that flowchart 3100 may be utilized to calculate an estimated or a predicted power value corresponding to an athletic activity in which a user has participated. Additionally or alternatively, multiple power values may be calculated for a single athletic activity, or multiple athletic activities may be processed as a group, and a single power value may be calculated for the group, among others.

A process may be executed to detect one or more sensor types of devices connected to the processor 202. Is contemplated that any network connection hardware, firmware, and/or software may be utilized to facilitate communication between the processor 202 and one or more connected sensor devices. Further, it is contemplated that any detection methodology may be utilized. In one example, a sensor device may be detected and/or identified when data is received at a dedicated input port (physical and/or virtual input port). In another example, a sensor device may be detected and/or identified based upon header data communicated with payload data from the sensor device to a non-dedicated input port. Those of ordinary skill in the art will recognize various additional or alternative connection methodologies that may be utilized to detect and/or identify a connected sensor device, without departing from the scope of these disclosures. The sensor devices may include, among others, a triaxial accelerometer, a triaxial gyroscope, a triaxial magnetometer, a heart rate sensor, a muscle oxygenation sensor (e.g. sensor 710), and/or a location-determining sensor. However, it is contemplated that a single axis, or two-axis accelerometer, gyroscope, or magnetometer may be utilized, without departing from the scope of these disclosures. In the description that follows, a micro-electromechanical systems device (MEMS) may refer to a combination of one or more of the accelerometer, gyroscope, and/or magnetometer. It is contemplated that this MEMS device may be implemented as a single integrated circuit, or as multiple discrete hardware elements in communication with one another. In the description that follows, flowchart 1800 may be utilized to select a model that may be utilized to calculate power (i.e. the rate at which work is done by the user during an athletic activity) based upon one or more sensor devices that are detected as being connected to the processor 202. In one implementation, the process to detect the connected sensor devices may be executed at block 3102.

A process may be executed to select a sampling scheme that may prescribe a manner in which sensor data is collected as a user performs an athletic activity. The sampling scheme may be selected based upon the detected sensor type connected to the processor 202. In one implementation, data may be collected/sampled as data windows. The data stored within a window, in turn, may be utilize to analyze the frequency content of the store data, or to calculate attributes, among others. It is contemplated that multiple attributes may be calculated from received MEMS (accelerometer and/or gyroscope, among others) data and/or heart rate sensor data. In one implementation, received accelerometer sensor data may be parsed into data associated with three orthogonal axes: an x-axis, a y-axis, and a z-axis. The one or more calculated motion attributes comprise one or more attributes selected from a group of: a vector normal calculated as a square root of a sum of squares of x-axis, y-axis, and z-axis values; a range of x-axis values; an arm swing frequency; a trimmed mean of x-axis values; an interquartile range of z-axis values; an arm swing power; a skew; an integral of x-axis values; a step frequency determined from a vector normal using a time domain frequency; a summation of max of quartered windows; a standard deviation of a derivative; a sum of a standard deviation of x-axis, y-axis, and z-axis values; an integral of a vector normal; a step frequency power; a mean of a standard deviation values of quartered windows; a maximum of a vector normal; a median absolute deviation of a derivative of a vector normal; an interquartile range of x-axis values; a trimmed mean of a vector normal; an absolute value of a median data point of x-axis data; a median absolute deviation of data associated with x-axis; a standard deviation of x-axis data; an integral of y-axis values; an integral of z-axis data; a range of z-axis data; a minimum value of z-axis data; an interquartile range of data from the x-axis, y-axis, and z-axis; a sum of a median absolute deviation of data from the x-axis, y-axis, and z-axis; a sum of a median of data from x-axis, y-axis, and z-axis; a maximum derivative of a vector normal; a minimum derivative of a vector normal; an absolute trimmer mean of a derivative of a vector normal; a standard deviation of a vector normal; one or more zero crossings of vector normal data; a skew of vector normal data; an interquartile range of vector normal data; and a standard deviation of x-axis values.

It is contemplated that any process for analyzing the frequency content of sampled sensor data, and for calculation of one or more sensor data attributes may be utilized, without departing from the scope of these disclosures. Additionally, further details related to the calculation of attributes, as well as the analysis of the frequency content of sampled data from connected sensor devices are described in the proceeding disclosure. In one implementation, if a MEMS device is detected as being connected to the processor 202, data may be sampled at a frequency of 50 Hz. Accordingly, the sampling frequency of 50 Hz may be utilized to capture information in order to effectively analyze the one or more user motions during and an athletic activity. As such, the systems and methods described herein utilize high-frequency sampling and analysis that, in turn, necessitates a microprocessor that executes at a frequency of multiple kiloFLOPS, megaFLOPS, gigaFLOPS, or teraFLOPS or more. It is contemplated, however, that alternative sampling frequencies may be utilized, without departing from the scope of these disclosures. For example, a sampling frequency of 30 Hz-120 Hz, among others, may be utilized, without departing from the scope of these disclosures. In one implementation, if a heart rate sensor is detected as being connected to the processor 202, data may be sampled at a frequency of 1 Hz. However, it is contemplated that alternative sampling frequencies may be utilized, without praying from the scope of these disclosures. For example, a sampling frequency of 0.1 Hz-10 Hz, may be utilized, without departing from the scope of these disclosures. In one implementation, the process to select the sampling scheme may be executed at block 3104.

A process may be executed to group data samples into sampling windows. It is contemplated that data sampled from a connected sensor device may be stored in memory (e.g. memory 212, among others) in a sample window using any storage system or methodology, without departing from the scope of these disclosures. In one implementation, data sampled from a MEMS device may be stored in multiple windows, each containing 256 samples, and corresponding to a 5.12 second period of time when sampled at a frequency of 50 Hz. As such, the number of samples stored within a window for a MEMS device may be adjusted based upon a rate at which the data sampled. In one implementation, there is no overlap between sample windows. In another implementation, sliding window sample methodology may be utilized, without departing from the scope of these disclosures. In one implementation, data sampled from a heart rate sensor device may be stored in multiple windows, each containing 5 samples. However, similar to the MEMS device, the number of samples stored within a sample window for the heart rate sensor device may be adjusted based upon the rate at which the data sampled from the heart rate sensor. In one implementation, the processes executed to group samples into sample windows may be associated with block 3106.

A process may be executed to select a model type, based on one or more sensors connected to the processor 202. In one implementation, the model type may be utilized to calculate a power associated with an athletic activity participated in by a user/athlete. In one example, the systems and methods described herein may utilize one of four separate power model types. Accordingly, a first power model type may be utilized when only a heart rate sensor is connected. A second power model type may be utilized when only a MEMS sensor is connected. A third power model type may be utilized when both a MEMS sensor and a heart rate sensor is connected. A fourth model type may be utilized when it is detected that the user is sitting (i.e. participating in an athletic activity that involves sitting down, which may include certain weight machine exercises in a gym environment, or cycling, among others), and when both a MEMS sensor and a heart rate sensor is connected. The process for selection of the power model type may be executed at block 3108.

A process may be utilized to calculate model-appropriate attributes for sample windows. In one implementation, attributes may be calculated for each stored sample window. For example, for each 256-sample window of acceleration data, attributes associated with a selected power model type may be calculated. Accordingly, a Heart Rate power model that utilizes sensor data received from a heart rate sensor only, may utilize, in one example, 11 attributes. However, it is contemplated that additional or alternative attributes may be utilized with the Heart Rate power model, without departing from the scope of these disclosures. A MEMS power model that utilizes sensor data received from a MEMS sensor only, may utilize, in one example, 28 attributes. Similar to the Hard Rate power model, additional or alternative attributes may be utilized with the MEMS power model, without departing from the scope of these disclosures. A MEMS & HR power model that utilizes sensor data received from a MEMS sensor and a heart rate sensor may utilize, in one example, 37 attributes. It is contemplated, however, that additional or alternative attributes may be utilized with the MEMS & HR power model, without departing from the scope of these disclosures. Further, a MEMS & HR (Sitting) power model that utilizes sensor data received from a MEMS sensor and a heart rate sensor for one or more activities during which a user is sitting, may utilize, one example, 37 attributes. It is contemplated that the attributes presented in Table 1 may be calculated using any data analysis processes, without departing from the scope of these disclosures.

In one implementation, calculation of attributes associated with the four power model types may comprise calculation of a vector normal of accelerometer data and/or gyroscope data received from respective communication channels. In one example, at least three heart rate data samples may be utilized to interpolate heart rate on a 5-second grid. It is contemplated, however, that another number of heart rate data samples may be utilized to interpolate the heart rate, without departing from the scope of these disclosures. Further attributes calculated for the four power model types may include a mean-centered vector normal, a derivative of a vector normal, a smoothed vector normal, a Fast Fourier Transform of the data, quartile windows and quartered windows of vector normal data. Further, the attributes associated with each of the four power models are described in Table 1 below. In one implementation, the processes utilized to calculate model-appropriate attributes may be executed at block 3110.

TABLE 1
Power Model Types and associated attributes
POWER MODEL TYPES
1. Heart Rate	2. MEMS	3. MEMS & HR	4. MEMS & HR (Sitting)
May utilize expert	May utilize expert system with	May utilize expert system with	May utilize expert system
system with 8 experts	16 experts	15 experts	with 16 experts
Attributes may include:	Attributes may include:	Attributes may include:	Attributes may include:
HR_normalized:	P_tot_bin1:	P_tot_bin1:	P_tot_bin1:
approximation of max	total power in the first	total power in the first	total power in the first
heart rate (HR)	frequency bin for	frequency bin (for	frequency bin (for
Der HR:	accelerometer data (acc)	accelerometer data)	accelerometer data)
derivative (deriv) of	Max_power:	HR_normalized:	HR_scale:
heart rate	maximum Fast Fourier	approximation of max HR,	approximation of max
Mad HR:	Transform (FFT) power	scaled by age, gender, height	heart rate, scaled by age,
median absolute	Weight_kg:	Gyro_der_bs_num_inc:	gender, height and sitting
deviation of heart rate	Weight measured in kg	number of stretches of	heart rate
HRRange	Quartile1_papr:	increasing values in binary	Gyro_ZC:
HR	peak-to-average power ratio	representation of derivative of	number of zero crossings
range of heart rate	(papr) statistic of first quartile	gyroscope (gyro) signal	of mean centered
Weight_kg:	values	Weight_kg:	gyroscope data
Weight measured in kg	H_peak_powA:	Weight measured in kg	Weight_kg:
Height_cm:	arm swing peak power	Gyro_L_peak_freqA: bounce	Weight measured in kg
Height measured in cm	Jerk_bs_num_dec_stretches:	frequency from gyroscope	DerHR:
Cardio_tag:	number of decreasing stretches	signal	derivative of heart rate
Input information from	in binary representation of jerk	DerHR:	Quartile4_burstiness:
user identifying the	signal (differenced	derivative of heart rate data	burstiness statistic on
type of athletic activity	acceleration data)	Gyro_bs_num_total_stretches:	fourth quartile values (for
as cardio	Quartile2_pearson_skew:	number of continuous	accelerometer data)
Strength_tag:	pearson skew statistic on	stretches of a single value in	Quartile3_papr:
Input information from	second quartile values (for	binary representation of gyro	peak-to-average power
user identifying the	accelerometer data)	signal	ratio statistic of third
type of athletic activity	Gyro_bs_std_inc_stretch:	Quartile1_papr:	quartile values (for
as strength training	Standard deviation (stdev) of	papr statistic of first quartile	accelerometer data)
Mobility_tag:	increasing values in	values	Gyro_p_tot_bin3:
Input information from	accelerometer data binary	Quartile2_pearson_skew:	total power in third
user identifying the	representation	pearson skew statistic on	frequency bin
type of athletic activity	F_bin2	second quartile values (for	Gyro_der_bs_mean_inc_stretch:
as mobility exercise	frequency (freq) at max power	accelerometer data)	mean length of increasing
No_tags:	in second frequency bin	Mad HR:	stretches in binary
No user input of	Avg_freq_bin_1_2:	median absolute deviation of	representation of gyro
information related to	average frequency computed	heart rate data	derivative
the type of activity	from the frequencies with the	Quartile1_stdev:	F_bin1:
carried out	maximum powers in the first	stdev of first quartile	frequency at max power in
	two bins	Quartile4_absmedian median	first frequency bin
	Quartile1_stdev:	of fourth quartile values (for	Quartile1_papr:
	Standard deviation of first	accelerometer data)	peak-to-average power
	quartile	RMS_integral:	ratio statistic of first
	Quartile2_burstiness:	root mean square (RMS) of	quartile values
	burstiness statistic on second	the cumulative sum for	Quartile2_pearson_skew:
	quartile values (for	accelerometer data	pearson skew statistic on
	accelerometer data)	Der_median_peak_values:	second quartile values (for
	IQRange interquartile range	median of peaks in derivative	accelerometer data)
	Gyro_pearson_skew:	signal	Gyro_bs_std_inc_stretc:
	pearson skew	Gyro_der_bs_longest_dec_stretch:	standard deviation of
	P_tot_bin3:	Longest stretch of decreasing	length values of increasing
	total power in the third	values in binary representation	stretches in binary
	frequency bin (for	of derivative of gyro signal	representation of
	accelerometer data)	TimeDomainFrequency:	gyroscope data.
	Jerk_mad_peak_values:	time domain approximation	Quartile1_stdev:
	median absolute deviation of	of dominant frequency (for	standard deviation of first
	peak values in the jerk signal	accelerometer data)	quartile
	Med_abs_dev:	Absmedian:	TimeDomainFrequency:
	median absolute deviation	median of accelerometer data	time domain
	(for accelerometer data)	signal	approximation of dominant
	7 local MEMS models:	Mean_median:	frequency (for
	walking, running, rowing, 3	mean of median values	accelerometer data)
	training models, mobility	computed on subwindows of	Jerk_bs_ratio_mean_stretches:
	Cardio_tag:	data (for accelerometer data)	ratio of the mean number
	Input information from user	Gyro_p_tot_bin3:	of values in increasing
	identifying the type of athletic	total power in third frequency	stretches and decreasing
	activity as cardio	bin (for gyroscope data)	stretches in the binary
	Strength_tag:	Jerk_bs_ratio_mean_stretches:	representation of the jerk
	Input information from user	ratio of the mean number of	signal
	identifying the type of athletic	values in increasing stretches	Quartile4_absmedian:
	activity as strength training	and decreasing stretches in the	median of fourth quartile
	Mobility_tag:	binary representation of the	values (for accelerometer
	Input information from user	jerk signal	data)
	identifying the type of athletic	Avg_freq_bin_2_4:	RMS_integral:
	activity as mobility exercise	average frequency of the	root mean square of the
	No_tags:	frequencies with the maximum	cumulative sum of
	No user input of information	powers in the second and	accelerometer data
	related to the type of activity	fourth frequency bins	Der_median_peak_values:
	carried out	Quartile4_min:	median of peaks in
		minimum value of fourth	derivative signal
		quartile	Quartile2_burstiness:
		Gyro_p_tot_bin1_norm:	burstiness statistic on
		normalized total power in the	second quartile values (for
		first frequency bin (for	accelerometer data)
		gyroscope data)	Jerk_trimmed_mean:
		Num_valleys:	trimmed mean of jerk
		number of valleys in	signal
		accelerometer data signal	IQRange:
		P_tot_bin2_norm:	interquartile range
		normalized total power in	Der_absmedian:
		second frequency bin (for	median of derivative
		accelerometer data)	signal (for accelerometer
		8 local MEMS models:	data)
		cycling, walking, running,	Jerk_mad_peak_values:
		rowing, 3 training models,	median absolute deviation
		mobility	of peak values of jerk
		Cardio_tag:	signal
		Input information from user	Med_abs_dev:
		identifying the type of athletic	median absolute deviation
		activity as cardio	(for accelerometer data)
		Strength_tag:	8 local MEMS models:
		Input information from user	cycling, walking, running,
		identifying the type of athletic	rowing, 3 training models,
		activity as strength training	mobility
		Mobility_tag:	Cardio_tag:
		Input information from user	Input information from
		identifying the type of athletic	user identifying the type of
		activity as mobility exercise	athletic activity as cardio
		No_tags:	Strength_tag:
		No user input of information	Input information from
		related to the type of activity	user identifying the type of
		carried out	athletic activity as strength
			training
			Mobility_tag:
			Input information from
			user identifying the type of
			athletic activity as mobility
			exercise
			No_tags:
			No user input of
			information related to the
			type of activity carried out

In one example, sitting recovery data across a range of heart rate values may be repeated for the cardio, mobility, strength tags, (Cardio_tag, Strength_tag, Mobility_tag), as well as the no tags scenario (No_tags), as described in Table 1.

Accordingly, a power value associated with sensor data generated in response to an athletic activity may be calculated using a power model type selected from the power model types described in Table 1. The calculated power value may represent an average power over a period of time during which an athletic activity is undertaken by a user. It is contemplated that any period of time may be utilized in the calculation of the power value. In one example, the calculated power value may be measured in units of Watts [W]. The calculated power value may further be utilized to calculate one or more energy consumption values (e.g. an average energy consumption of a user, which may be measured in units of calories [cal], or Joules [J]) by integrating over a second period of time. Further, it is contemplated that the second period of time may include any duration, without departing from the scope of these disclosures. In one implementation, one of the four power model types may be utilized to calculate a power estimate for a user from sensor data generated during an athletic activity at block 3112 of flowchart 3100.

In certain implementations, or more of the four power models described in relation to Table 1 may include attributes calculated using muscle oxygenation data generated by a muscle oxygenation sensor, such as sensor 710, among others.

Power Model Building

Sensor data from a plurality of users may be utilized to build the power calculation models described in Table 1. As such, FIG. 32 is a flowchart diagram 3200 of one implementation that may be utilized to build a power model from data generated in response to a number activities prescribed to the plurality of users. Accordingly, one or more activities (detailed in Table 2) may be prescribed to a user, from the plurality of users at block 3202.

In one example, the plurality of users may be referred to as test subjects, and test data may be gathered from sensors worn by the test subjects as they execute prescribed motions, otherwise referred to as training activity types. Accordingly, one or more processes to sample and store the sensor data may be executed at block 3204. In one example, the training activity types may be prescribed based upon the type of sensors worn by the test subjects, and hence, the type of sensor data available to be sampled during a prescribed activity type. In one example, a plurality of test subjects may execute each of the prescribed activity types. Accordingly, for a given activity type prescription, a user may be instructed to perform multiple repetitions, or sets of repetitions (otherwise referred to as bouts). Further, for each prescribed activity type, a number of data windows (sampling windows) may be sampled and stored. Data gathered from the test subjects may be divided into training data and validation data, such that the training data is utilized to build the four models described in Table 1, and the validation data is utilized to test the accuracy of the build models. Table 2 presents one example of types of activities prescribed for execution by test subjects in order to generate training sensor data to be used to build the MEMS power model (column 2 from Table 1). Table 3 presents one example of types of activities prescribed to test subjects in order to gather validation sensor data to validate the MEMS power model. Table 4 presents one example of types of activities prescribed to test subjects to generate training data for building of the MEMS+HR power model (column 3 from Table 1). Table 5 presents one example of activity types prescribed to test subjects to generate validation data for the MEMS+HR power model.

TABLE 2
Activity types for generation of training data for MEMS power model type
Activity type
2-foot forward-backward hops in place
2-foot lateral hops in place
Agility Ladder - In/Out
Agility Ladder - Lateral Step Shuffle
Alternating forward lunge
Alternating forward step lunge + bicep curl
Alternating lateral lunge
Alternating one-foot lateral jump
Alternating split jumps
Alternating step back lunge
Back Squat
Battle Rope (alternating)
Bent Over Upper Back Stretch
Bent over row
Bicycle Crunch
Box Cross Over Glute Stretch
Box Jump
Broad Jump
Burpee
Butt kickers in place
Cross-Body Shoulder Stretch
Deadlift
Deadlift + arm curl
Dips (bar)
Dips (bench)
Double Under
Dumbbell Floor Press
Foam Rolling
Forearm plank
Forearm side plank
Goblet Squat
High knee run in place
Hurdler Stretch
In-sport running
Jump Rope
Kettlebell Swing
Knee forearm plank
Knee push up
Kneeling Hip Flexor Stretch
Lateral shuffle
Medicine Ball Slam
Mountain climber
One-arm Chest Stretch
Opposite arm/leg plank extension
Plank Row
Power Clean
Power Snatch
Pull-ups (pronated)
Pull-ups (supinated)
Push Press
Push Up
Rowing Machine
Russian twist
Should Reach Test
Shoulder press
Sit-Up
Sitting Recovery
Soccer corner kick
Soccer dribble
Soccer shot on goal
Squat
Squat Press
Squat hold
Squat jump
Standing Calf Stretch
Standing Quad Stretch
Standing bicep curl
Standing triceps extension
Step touch
Thruster
Treadmill Running
Treadmill Walking
V-Ups
Wide Leg Forward Bend Stretch
Yoga Downward Dog
Yoga Forward Bend
Yoga Side Bend
Yoga Tree Pose
Yoga Triangle Pose
Yoga Upward Dog
Yoga Warrior I Pose
Yoga Warrior II Pose
Yoga Warrior III Pose

TABLE 3
Activity types for generation of validation data
for MEMS power model type
Activity type
2-foot forward-backward hops in place
2-foot lateral hops in place
Agility Ladder - In/Out
Agility Ladder - Lateral Step Shuffle
Alternating forward lunge
Alternating forward step lunge + bicep curl
Alternating lateral lunge
Alternating one-foot lateral jump
Alternating split jumps
Alternating step back lunge
Back Squat
Battle Rope (alternating)
Bent Over Upper Back Stretch
Bent over row
Bicycle Crunch
Box Cross Over Glute Stretch
Box Jump
Broad Jump
Burpee
Butt kickers in place
Cross-Body Shoulder Stretch
Deadlift
Deadlift + arm curl
Dips (bar)
Dips (bench)
Double Under
Dumbbell Floor Press
Forearm plank
Forearm side plank
Goblet Squat
High knee run in place
Hurdler Stretch
In-sport running
Kettlebell Swing
Knee forearm plank
Knee push up
Kneeling Hip Flexor Stretch
Lateral shuffle
Medicine Ball Slam
Mountain climber
One-arm Chest Stretch
Opposite arm/leg plank extension
Plank Row
Power Clean
Power Snatch
Pull-ups (pronated)
Pull-ups (supinated)
Push Press
Push Up
Rowing Machine
Russian twist
Should Reach Test
Shoulder press
Sit-Up
Sitting Recovery
Soccer corner kick
Soccer dribble
Soccer shot on goal
Squat
Squat Press
Squat hold
Squat jump
Standing Calf Stretch
Standing Quad Stretch
Standing bicep curl
Standing triceps extension
Step touch
Thruster
Treadmill Running
Treadmill Walking
V-Ups
Wide Leg Forward Bend Stretch
Yoga Downward Dog
Yoga Forward Bend
Yoga Side Bend
Yoga Tree Pose
Yoga Triangle Pose
Yoga Upward Dog
Yoga Warrior I Pose
Yoga Warrior II Pose
Yoga Warrior III Pose

TABLE 4
Activity types for generation of training data for
MEMS & HR power model type
Activity type
2-foot forward-backward hops in place
2-foot lateral hops in place
Agility Ladder - In/Out
Agility Ladder - Lateral Step Shuffle
Alternating forward lunge
Alternating forward step lunge + bicep curl
Alternating lateral lunge
Alternating one-foot lateral jump
Alternating split jumps
Alternating step back lunge
Back Squat
Battle Rope (alternating)
Bent over row
Bicycle Crunch
Box Jump
Broad Jump
Burpee
Butt kickers in place
Deadlift
Deadlift + arm curl
Dips (bar)
Dips (bench)
Double Under
Dumbbell Floor Press
Forearm plank
Forearm side plank
Goblet Squat
High knee run in place
In-sport running
Jump Rope
Kettlebell Swing
Knee forearm plank
Knee push up
Lateral shuffle
Medicine Ball Slam
Mountain climber
Opposite arm/leg plank extension
Plank Row
Power Clean
Power Snatch
Pull-ups (pronated)
Pull-ups (supinated)
Push Press
Push Up
Rowing Machine
Russian twist
Shoulder press
Sit-Up
Sitting Recovery
Soccer corner kick
Soccer dribble
Soccer shot on goal
Squat
Squat Press
Squat hold
Squat jump
Standing bicep curl
Standing triceps extension
Stationary Cycling
Step touch
Thruster
Treadmill Running
Treadmill Walking
V-Ups

TABLE 5
Activity types for generation of validation data for
MEMS & HR power model type
Activity type
2-foot forward-backward hops in place
2-foot lateral hops in place
Agility Ladder - In/Out
Agility Ladder - Lateral Step Shuffle
Alternating forward lunge
Alternating forward step lunge + bicep curl
Alternating lateral lunge
Alternating one-foot lateral jump
Alternating split jumps
Alternating step back lunge
Back Squat
Battle Rope (alternating)
Bent Over Upper Back Stretch
Bent over row
Bicycle Crunch
Box Cross Over Glute Stretch
Box Jump
Broad Jump
Burpee
Butt kickers in place
Cross-Body Shoulder Stretch
Deadlift
Deadlift + arm curl
Dips (bar)
Dips (bench)
Double Under
Dumbbell Floor Press
Forearm plank
Forearm side plank
Goblet Squat
High knee run in place
Hurdler Stretch
In-sport running
Kettlebell Swing
Knee forearm plank
Knee push up
Kneeling Hip Flexor Stretch
Lateral shuffle
Medicine Ball Slam
Mountain climber
One-arm Chest Stretch
Opposite arm/leg plank extension
Plank Row
Power Clean
Power Snatch
Pull-ups (pronated)
Pull-ups (supinated)
Push Press
Push Up
Rowing Machine
Russian twist
Should Reach Test
Shoulder press
Sit-Up
Sitting Recovery
Soccer corner kick
Soccer dribble
Soccer shot on goal
Squat
Squat Press
Squat hold
Squat jump
Standing Calf Stretch
Standing Quad Stretch
Standing bicep curl
Standing triceps extension
Stationary Cycling
Step touch
Thruster
Treadmill Running
Treadmill Walking
V-Ups
Wide Leg Forward Bend Stretch
Yoga Downward Dog
Yoga Forward Bend
Yoga Side Bend
Yoga Tree Pose
Yoga Triangle Pose
Yoga Upward Dog
Yoga Warrior I Pose
Yoga Warrior II Pose
Yoga Warrior III Pose

It is contemplated that the activity types presented in Tables 4 and 5 may be utilized for the MEMS & HR (Sitting) model (column 4 of Table 1), without departing from the scope of these disclosures.

In one implementation, data related to mobility activities may be excluded from the training data for the MEMS & HR and MEMS & HR (Sitting) (Columns 3 & 4 of Table 1) mixture of expert models in order to improve predictive performance for sitting recovery.

In one example, sample windows for specific activities may be weighted in a gating network and expert models associated with the four power model types of Table 1. Sample window weights may be utilized for treadmill walking, treadmill running, rowing, stationary cycling and sitting recovery to improve process performance (accuracy) for these activities. In another example, for the non-sitting recovery activities, weights may be utilized to improve high/low wattage power predictions. Additionally, sample window weights may also be utilized for other activities to improve process performance.

As previously described, data may be sampled as test subjects perform prescribed activities. The test data, in turn, may be divided into two sets: (A) Training and (B) Validation. One or more processes executed to divide the data into training and validation data may be executed at block 3206. In addition to dividing the test data into training and validation data, the data may be stratified, or separated, based on the test subjects' age, height, weight, among others. In one example, the separations, or strata, may include test subjects: ≦30 years, 30-40 years, >40 years; ≦64 inches, 64-69 inches, >69 inches; ≦150 pounds, 150-175 pounds, 175-200 pounds, >200 pounds. In one implementation, data stratification may be executed by one or more processes as block 3208. In one implementation, this stratification may be executed on a per-activity basis. As such, for a given activity (i.e. walking), an individual's data may appear only in the training or validation data set, but not both. However, an individual's data may appear in both the training and validation data sets for different activities (e.g. a given test subject's data may be present in a training data set for walking but in a validation dataset for running, among others). In one implementation, training and validation data sets may be constructed by subject, with approximately 70% of the data employed in training and 30% retained for validation. In one example, after stratification described above, sitting recovery may be subsampled down to a reduced data set, which may be utilized to prevent an unreasonably large number of sitting recovery windows from being present within the that model training data.

The power models presented in Table 1 may be built using test data generated by sensors mounted to test subjects as they carry out prescribed activities. As previously discussed, a given test subject may be instructed to repeat a prescribed activity multiple times during a bout. An additional and independent truth metric may be calculated during a given bout, and utilized to validate the test data when building the power models. In one implementation, external power may be utilized as the truth metric. Further, one or more processes may be executed to calculate one or more truth metrics at block 3210 of flowchart 3200. Accordingly, different processes may be utilized to calculate external power based upon the activity being sampled. For activities such as cycling or rowing, for which a prescribed wattage may be employed in data collection, the prescribed wattage for the activity may be used as the truth power. In one specific implementation, a cycling wattage may be inaccurate for cadences below a threshold value (e.g. 60 rpm, although it is contemplated that any cadence threshold may be utilized, without departing from the scope of these disclosures), and the systems and methods described herein may utilize bouts where the cadence does not drop below the threshold value. In one specific implementation, cadences may be calculated by analyzing the dominant frequency of movement (via Fast Fourier Transform) of a shank-mounted sensor device.

In one example, weight training and other strength training activities may be tested as a user executes prescribed activities/motions while standing on force plates. It is contemplated that any force plates sensor technology may be utilized, without departing from the scope of these disclosures. In one example, a summed vertical force recorded by the force plates may be employed to determine an associated power of the activity. In one implementation, a baseline force associated with the weight of the test subject in combination with any associated external weights employed in the activity may be subtracted from the force recorded by the force plates. Accordingly, a force recorded by the force plates during testing may be divided by a baseline mass to the test subject in combination with any external weights employed in the activity to determine a vertical acceleration signal. This acceleration signal may be filtered and integrated in the frequency domain to obtain a vertical velocity. The velocity may also be filtered in the frequency domain and then multiplied by an exercise force in the vertical direction to obtain an instantaneous power signal. A truth power for weight training may be calculated as (for a 5.12 window, among others):

Power=mean positive power+eccentric fraction*|mean negative power|

In one implementation, the eccentric fraction may be 0.25. However, it is contemplated that different eccentric fractions may be utilized, without departing from the scope of these disclosures.

In one implementation, a single equation may be utilized to calculate a truth power for running and walking activities as:

$\mathrm{Power}=\left[0.25C_{\mathrm{aero}}+C_{\mathrm{run}}\varepsilon -\frac{0.5C_{\mathrm{run}}\varepsilon V}{8.33}\right]\mathrm{VW},$

where

$C_{\mathrm{aero}}=\frac{0.01V^2}{H^3},$

where c_run=155.4G⁵−30.4G⁴−43.3G³+46.3G²+19.5G+3.6,

where ε=0.054V+0.25,

and where, V=velocity (m/s), W=subject weight (kg), H=subject height (m), and G=grade (decimal).

In one implementation, oxygen consumption for mobility (i.e. yoga and stretching) and soccer/in-sport running activities may be converted to power values via the conversion factor of 1 Watt=10 mL O2. However, in other implementations, it is contemplated that different conversion factors may be utilized. The truth oxygen consumption metric for a given window of sample data may be determined by computing a median of the oxygen consumption for 15 seconds before and after the midpoint of the sample data window of interest.

Normalized heart rate attributes may be calculated using test subject information in the denominator of normalized heart rate equations. Two such equations are presented below. The normalized heart rate attribute equations may be utilized in a linear model to predict steady-state oxygen consumption for a variety of activities. In one example, the coefficients utilized in the heart rate equations may minimize the root mean square error in oxygen consumption predictions in a linear model based upon the attribute. The attribute expressions are:

${\mathrm{HR}}_{\mathrm{normalized}}=\frac{\mathrm{HR}}{103.1367-0.4217\mathrm{Age}+0.1075\mathrm{Height}+6.5625\mathrm{Gender}}$ ${\mathrm{HR}}_{\mathrm{scale}}=\frac{\mathrm{HR}}{\begin{array}{c}58-0.3425*\mathrm{Age}+0.1020\mathrm{Height}+\\ 0.9983{\mathrm{HR}}_{\mathrm{sit}}+6.5625\mathrm{Gender}\end{array}}$

In the above equations for heart rate, age is specified in years, height is specified in centimeters, sitting heart rate is specified in beats per minute, and gender is −1 for male and 1 for female. The heart rate value in the numerator is the median heart rate computed from the values in the window of data (in beats per minute).

In one implementation, the data received from sensor devices connected to the processor 202 may be utilized calculate a large number of attributes. As such, in order to arrive at the attributes listed in Table 1 for the four power model types, one or more attribute selection processes may be executed. In one example, a greedy feature selection strategy may be utilized to determine a sub-set of the total number of possible attributes that may be utilized to predict the power output for each of the model types. In one implementation, 50 attributes may be selected as being predictive of the power output for each of the four model types presented in Table 1. However, fewer or more than 50 attributes may be utilized, without departing from the scope of this disclosure. In one example, the attributes may be utilized using bootstrap replicates to determine the attributes that will provide a generalization to unseen data and their order of importance. In one example, for each candidate attribute set, 25 bootstrap replicates may be created from the original training data. Each bootstrap replicate may be constrained to differ by, in this example, no more than 0.5% in its number of windows from that of the original training set. Alternative percentage differences may be utilized, however, without departing from the scope of these disclosures. In one implementation, replicates may be created using sampling with replacement, and on a per-subject basis. One exemplary process for creating a bootstrap replicate may randomly select a subject identifier for all available subjects. Accordingly, all bouts from this subject may be subsequently included in the bootstrap replicate. This process may be repeated until the total number of windows is within the specified threshold percentage of the total number of windows in the original training set. As sampling may be done with replacement, all bouts from a particular subject may appear multiple times in the replicate. After construction of a bootstrap replicate, a linear model may be developed using the candidate attributes and the bootstrap replicate windows as the training set. The performance of the linear model with the candidate attributes may be subsequently evaluated over all bootstrap replicates to provide an estimate of the generalizability of model performance.

Local Weighted Linear Regressions

The power models presented in Table 1 may, in one implementation, include local linear regression models. In one example, eight local linear regression models may be utilized. Of these eight local linear regression models, seven may be utilized in the second power model (MEMS model from column 2 of Table 1). The seven models may include models for walking, running, rowing, mobility, and 3 training models. The third power model (MEMS & HR model from column three of Table 1) may utilize eight local linear regression models, including cycling, walking, running, rowing, mobility, and three weight training models associated with different types of weight training. Similarly, the fourth power model (MEMS & HR (Sitting) model from column 4 of Table 1) may utilize eight local linear regression models, including cycling, walking, running, rowing, mobility, and three training models.

In one example, the eight local linear regression models may be constructed from attributes calculated using sensor data from a MEMS device. In one implementation, the local linear regressions may be calculated utilizing one or more processes at block 3212 of flowchart 3200. Further, the eight local linear regression models may be utilized as attributes themselves in the list of attributes associated with the four power models presented in Table 1. As such, these eight local linear regression models may be utilized to improve the performance of a mixture of experts solution associated with the four power models.

In one implementation, one or more mixture of experts processes may be executed as one of the four power models is used to estimate a power value associated with a user. In particular, the first power model (heart rate) may utilize 8 local experts, the second power model (MEMS) may utilize 16 local experts, the third power model (MEMS & HR) may utilize 15 local experts, and the fourth power model (MEMS & HR (Sitting)) may utilize 16 local experts. It is contemplated, however, that additional or alternative experts may be utilized with any of the four power model types, without departing from the scope of these disclosures. In one implementation, as a power model is calculating a power value associated a user, one or more processes may be executed to utilize predictions from the local linear regression models with the local experts of the mixture of experts methodology. As such, the local regression models may be applicable to (constructed from data associated with) walking, running, stationary cycling, rowing, three different combinations of weight training and other training activities, and mobility.

The local linear regression models may utilize attributes determined by a bootstrap replication feature selection process on a subset of data of interest. In one implementation, attributes available for selection may be limited to the 50 best attributes previously identified for the MEMS-only power model (column 2 of Table 1).

For the local linear regression model associated with weight training and additional training activities, groupings of activities for attribute selection and model generation may be identified by creating Gaussian mixture models (with increasing numbers of clusters) with the training data of interest using the 50 MEMS-only attributes identified using feature selection. Activities with comparatively small truth power values may be excluded from this process (Forearm plank, Russian Twist, Forearm side plank, Knee forearm plank, Squat hold). Further, a number of clusters to be utilized may be determined by monitoring the Akaike Information Criterion (AIC) and selecting a number of clusters at which the AIC begins to level off. In one implementation, all windows of an activity may be assigned to a cluster that contains the most windows of that activity. Details of the activities that are present in each local model are provided in Table 6.

Local weighted linear regressions may be constructed with window weights determined by the bin assignment for each window. Bins may be adjusted across a truth power range for each activity (or set of activities) to improve power predictions at the range extremes by minimizing an objective function that is a combination of the root mean square error and the squared correlation coefficient. Individual window weights for windows within a specific bin may be determined by the following formula:

$w_i=\frac{p_i}{N_i}N$

where N is the total number of windows, N_i is the number of windows in bin i, and p_i is the expected probability of users operating with power values in the bin range (sum of all probabilities across the bins must equal unity). In the regression constructed, bin probabilities may be assumed equal, such that p_i was equal to 1/(number of bins) for each bin.

Given the window weightings for each of the training activity windows, a weighted linear regression may be constructed with the attributes listed in Table 6 as inputs and power as the output. The resulting regression may be subsequently applied on all training and validation data in construction of the local activity model attributes employed in the mixture of experts solution.

TABLE 6
Local Weighted Linear Regression Model Details
Local Model
Name	Attributes Employed	Activities Included
Walking	Weight_kg	Treadmill Walking
	Height_cm
	StepRate
	P_tot_bin1
	IQRange
	BS_mean_dec_stretch
	Der_median_valley_values
	Max_median
	Quartile1_papr
	Gyro_der_stdev
Running	Weight_kg	Treadmill Running
	Height_cm
	StepRate
	Num_valleys
	Der_median_valley_values
	Der_absmedian
Cycling	Der_median_peak_values	Stationary Cycling
	Weight_kg
	P_tot_bin2_norm
	Height_cm
	F_bin2
	Jerk_bs_num_dec_stretches
	TimeDomainFrequency
	Gyro_der_stdev
	Gyro_quartile4_range
	Jerk_med_abs_dev
Rowing	Height_cm	Rowing
	BS_mean_dec_stretch
	Der_absmean
	Der_absmedian
	Max_median
	Mean_range
	Quartile1_papr
	Quartile2_pearson_skew
Training_Weights1	Mean_range	Jump Rope
	Gyro_bs_num_total_stretches	Box Jump
	TimeDomainFrequency	Double Under
	Weight_kg	Butt kickers in place
	Jerk_med_abs_dev	2-foot forward-backward
	P_tot_bin2_norm	hops in place
	Jerk_mad_peak_values	2-foot lateral hops in place
	Mean_std	High knee run in place
	Der_absmean
Training_Weights2	Der_absmedian	Deadlift
	Weight_kg	Push Up
	Gyro_quartile4_rms_integral	Back Squat
	Max_median	Alternating forward lunge
	P_tot_bin1	Alternating lateral lunge
	H_peak_powA	Knee push up
	Jerk_med_abs_dev	Standing triceps extension
	Gyro_bs_num_total_stretches	Alternating forward step
		lunge + bicep curl
		Alternating step back lunge
		Bent over row
		Deadlift + arm curl
		Mountain climber
		Standing bicep curl
		Opposite arm/leg plank
		extension
		Shoulder press
		Squat
		Squat press
Training_Weights3	P_tot_bin1	Push press
	Jerk_bs_num_dec_stretches	Power snatch
	Jerk_trimmed_mean	Power clean
	Weight_kg	Kettlebell swing
	Quartile1_papr	Thruster
	H_peak_powA	Burpee
	Quartile2_burstiness	Squat jump
	BS_mean_dec_stretch	Step touch
		Alternating one-foot lateral
		jump
		Alternating split jumps
		Lateral shuffle
Mobility	P_tot_bin1	Yoga side bend
	Max_power	Yoga forward bend
	Weight_kg	Yoga upward dog
	Quartile1_papr	Yoga downward dog
	H_peak_powA	Yoga warrior III pose
		Yoga triangle pose
		Yoga warrior I pose
		Box cross over glute stretch
		Yoga child's pose
		Should reach test
		Standing quad stretch
		Standing calf stretch
		Kneeling hip flexor stretch
		Seated hamstring stretch
		Foam rolling
		Yoga warrior II pose
		Yoga tree pose
		Cross-body shoulder stretch
		Wide leg forward bend
		stretch
		Bent over upper back stretch
		One-arm chest stretch
		Hurdler stretch
		Seated spinal twist stretch

Window Weighting

In one example, local linear regression models for walking, running, rowing, and stationary cycling at high and low wattages may utilize a window weighting scheme during a mixture of experts model process. Similar to the weighting scheme that may be utilized in constructing the local attribute models, bins may be determined for each activity and individual window weights for windows within a specific bin may be calculated using the following formula:

$w_i=\frac{p_i}{N_i}N$

where N is the total number of windows, N_i is the number of windows in bin i, and p_i nominally represents the expected probability of windows being within the bin range. In one example, each of the bin probabilities for an expert model may be set to be equal, and the sum of all probabilities constrained to equal unity. Uniform weights may be utilized for all sitting recovery windows (in one example, a weighting value of 2 may be utilized).

Following one or more processes to execute the gating network associated with each mixture of experts model, bin probabilities may be further varied to improve performance at the edges of the training range. Accordingly, changes in probabilities in these instances may not affect how windows are allocated to local experts, but instead modify the local expert regressions to predict windows weighted more heavily. In certain examples, the probabilities used for the gating network, the sum of probabilities may not be constrained to equal unity. Instead, probabilities may be assigned in an iterative fashion to improve performance at the edges of the training range. This improvement may be achieved without significantly negatively impacting performance in the middle of the training range. Further, uniform weights may be employed for select activities either across the entire training range or above/below specified thresholds.

Mixture of Experts Model Development

A number of attributes and experts utilized in the mixture of experts strategy is determined using one or more grid search processes. A two dimensional grid that has a number of experts and a number of attributes may be established. Attributes may be selected in order, from an ordering calculated by an attribute selection process. In one example, at each grid point (number of experts, number of attributes combination), the mixture of experts model may be optimized on the training data set for a specified number of iterations. Further, in one implementation, to obtain consistent and comparable performance across grid points, an optimization process may be repeated (e.g. repeated three times) at each grid point from different expert weights initializations, and a best result may be retained.

Attributes may be selected using one or more greedy forward selection strategy processes that utilized N bootstrap replicates of the training set. Bootstrap replicates may be created, with replacement, by randomly selecting a subject identifier from a training data set, and adding training windows associated with the subject identifier to the bootstrap replicate. This process may be repeated until the total number of windows in a bootstrap replicate is within a specified percentage difference of a total number of windows present in the training data set.

The greedy forward selection strategy for attributes cycles through each attribute in turn, gauging the performance of each attribute in combination with the set of previously selected attributes. For each potential attribute combination, N regression models are created using the current attribute set and the bootstrap replicates. The performance on each bootstrap replicate is averaged across all replicates and the best performing attribute is retained. The cycle repeats until a specified number of attributes have been selected.

Attributes identified using sequential feature selection using bootstrapping from the entire training data set may be subsequently used to construct a set of local linear regression experts. Further, each mixture of k local linear experts may use a gating network that determines the probability p_i that expert i is responsible for predicting the output via the softmax function:

$p_i=\frac{{}^{m_i^Tx}}{{\Sigma }_k{}^{m_k^Tx}}$

where x is the vector of input attributes and m_i is a vector of weights for expert i, of the same size as the number of input attributes. In the competitive framework utilized, the expert with the maximum probability for the input window may be entirely responsible for the output prediction via the linear regression for that expert. The expert weights and associated linear regressions may be trained simultaneously. In one example, they may be simultaneously trained using a Matlab pattern search function available in Matlab's global optimization toolbox. Accordingly, a mesh-adaptive direct search process may be utilized in exploring the input space. Further, at each iteration of the optimization, a set of expert weights may be provided. For every window, the expert probabilities may be determined via the softmax function and the expert responsible for each window may be identified by the maximum probability among all experts. All windows assigned to a particular expert may be subsequently collected and a least-squares linear regression may be performed using the input attributes and output truth. These one or more processes may be repeated for all experts to obtain predictions for all windows. Entire bout predictions may be determined by summation of the predictions for the windows comprising each bout. Individual bout performance may be evaluated using the absolute percent error in the bout prediction, or bout truth. The objective function employed in optimization of the expert weights may be the integral of the percent accuracy vs. percent population curve constructed from the performance analysis of all bouts.

One or more processes may execute stratified sampling to construct the training and validation data sets. In one example, an entire training data set may be employed in determining an objective function for each iteration of the stratified sampling. In one implementation, the data stratification may create training and validation data sets that contain similar representations of the population sample. As such, the entire training data set could be employed in determining the objective function.

The systems and methods described herein may be implemented to estimate power associated with an athletic activity that a user has participated in. The estimation of power may come in turn, be utilized to calculate an energy expenditure, among others. For example, block 3301 of flowchart 3300 from FIG. 33 shows another example implementation of calculating power from one or more attributes.

Accordingly, the systems and methods described herein may utilize data received from one or more different sensor types, including, among others, an accelerometer, a heart rate sensor, a gyroscope, a location-determining device (e.g., GPS), light (including non-visible light) sensor, temperature sensor (including ambient temperature and/or body temperature), sleep pattern sensors, image-capturing sensor, moisture sensor, force sensor, compass, angular rate sensor, and/or combinations thereof.

Furthermore, while the example of attributes associated with acceleration data output from an accelerometer sensor are described, those of ordinary skill will appreciate that other sensors may be used, alone or in combination with other sensors and devices, without departing from the scope of this disclosure. For example, a heart rate monitor may be used, wherein the data output from a heart rate monitor may output data representative of a heart rate in units of beats per minute (BPM) or equivalent. Accordingly, one or more transformations may be performed on outputted heart rate data to interpolate a heart rate signal between heart rate data points, and allowing for signal dropouts at certain points. Furthermore, the attributes calculated for sensor data associated with a heart rate monitor, or any other sensor, may be the same, or may be different to those described above in relation to accelerometer data.

In another implementation, the systems and methods described herein may analyze sensor data from combinations of sensors. For example, a device may receive information related to a heart rate of a user from a heart rate monitor, in addition to information related to motion of one or more appendages of a user (from one or more accelerometers, and the like). In one example, the device may determine that a user has a heart rate indicative of vigorous exercise, but accelerometer data may indicate that said user has been at rest for a period of time. Accordingly the device may determine that the user has a sustained elevated heart rate after a period of activity but is now resting after said activity, and the like.

In one implementation, training data may be used to construct one or more models, otherwise referred to as experts, or expert models, for predicting, among others, a volume of oxygen consumption based upon (at least in part) one or more individual-specific properties such as a gender, a mass and/or a height of a user. Accordingly, information from one or more sensors associated with a device, such as device 112, 126, 128, 130, and/or 400, may be used to calculate one or more attributes. In turn, the calculated attributes may be used in one or more power estimation models (e.g. the four power models presented in Table 1) predict a power associated with a user while outputting motion signals (sensor output values) corresponding to the calculated attributes. For example, a user may be performing an activity, such as playing soccer, while wearing a sensor device on an appendage. The sensor device, in turn, may output sensor values, which may be processed to calculate one or more attributes. Subsequently, the one or more calculated attributes may be utilized in one or more power models, and an estimation of a power associated with an activity being performed by a user while playing soccer may be made. Furthermore, said estimation of a power may be used to estimate energy expenditure values by the user playing soccer. In certain embodiments, all of the sensor data comes from a unitary device. In one example, the unitary device is an appendage-worn device. In certain configurations, the appendage worn device comprises at least one of an accelerometer, a location-determining sensor (e.g., GPS) and a heart rate monitor. In another example, the unitary device comprises a sensor configured to be placed on or within athletic apparel, such as a shoe. In yet another example, a sensor from at least two different devices may be utilized to collect the data. In at least one embodiment, the device comprising a sensor utilized to capture data may also configured to provide an output of energy expenditure. In one embodiment, the device may comprise a display device configured to display an output relating to energy expenditure. In further embodiments, the device may comprise a communication element configured to transmit information relating to energy expenditure to a remote device.

FIG. 33 is a flowchart showing an exemplary implementation of attribute calculation. In one example, this attribute calculation may be used to estimate one or more metrics associated with an activity being performed by a user, and wherein said estimation may include a power value associated with one or more athletic activities. In one example, an energy expenditure and/or speed of walking and/or running may be estimated using a same set of attributes, or a sub-set of attributes from a common group of attributes, and the like.

Information related to the movement of the user may be outputted as one or more data signals from one or more sensors associated with one or more sensor devices monitoring the user. In one implementation, FIG. 33 represents one or more processes carried out by at least one processor, such as processor unit 202, which may be associated with a sensor device, such as, among others, device 112, 126, 128, 130, and/or 400. Accordingly, devices may not directly monitor a rate at which work is done (power) by a user during an activity. In one implementation, one or more sensor devices may monitor one or more motions associated with one or more activities being performed by a user. Furthermore, in one arrangement, received activity data may be correlated with observed oxygen consumption values for activities that may exhibit certain attributes, and associated with one or more oxygen consumption models.

One or more embodiments receive sensor data from one or more sensors (see, e.g., block 3302). In certain embodiments, the sensor data may be associated with a device worn by a user. In one example, and as previously described, said device may be, among others, device 112, 126, 128, 130, and/or 400. Accordingly, the sensor data may be received by a processor, such as processor 202 from FIG. 2, and may be received from one or more sensors described herein and/or known in the art. In one implementation, sensor data may be received at block 3302 from an accelerometer at a frequency of, among others, 50 Hz. Additionally or alternatively, sensor data may be received from the sensor, such as accelerometer, in windows of between 5.0 and 5.5 seconds. In one embodiment, the window (or time frame) may be about 5.12 seconds in length. A window may be a period of time during which sensor data is recorded for one or more motions of a user associated with one or more activities being performed by a user. In one implementation, a sample window may include 256 samples (data points) of sensor data, wherein a sample of sensor data may include a value for each of three orthogonal axes of an accelerometer (x-axis, y-axis, and z-axis), and/or a vector normal value. In yet another implementation, sensor data received from, in one implementation, an accelerometer, may be received in windows that do not overlap (e.g., 5.12 second-length groups of sensor data each containing 256 samples, and received singly, rather than simultaneously, and/or discrete from each other). However, in alternative embodiments, the systems and methods described herein may be employed with any frequency of operation of an accelerometer, with a window length measuring any length of time, and using any number of samples of sensor data from within a given window. Data may be validated as it is received, such as for, for example, at block 3304. Data validation may include, among others, comparison of one or more values of received sensor data to one or more threshold values, and the like. Various examples of example data validation embodiments are described in further detail in relation to FIG. 34.

Further aspects of this disclosure relate to calculating one or more attributes from the data (see, e.g., block 3306). Calculation of one or more attributes may occur after validation protocols, such as those described herein, including in relation to FIG. 34. However, it is contemplated that attributes may be calculated without utilizing one or more prior validation processes. In one implementation, one or more attributes may be calculated for one or more of the received samples in a sample window (e.g., the 256 sample window described above). In one example, attribute calculation may occur in real-time as the data is collected. In another example, attribute calculation may be executed using stored data. In certain implementations, one or more processes may be executed at block 3360 to calculate one or more of the attributes listed in Table 1 associated with the four power models.

Further embodiments may compare one or more calculated attributes associated with data received from one or more sensors, and indicative of one or more activities being performed by a user, to one or more attributes associated with one or more models. In one example, one or more attributes may be compared to one or more power models (see e.g., block 3308). One or more calculated attributes may be used as inputs to one or more models such that, in one example, a model for estimation of an power may be executed separately from a model for calculation of a step rate, a walking speed, and/or a running speed, and the like. As previously described, one or more models may be stored in a memory, such as memory 212, and the like, and associated with a device, including a sensor device.

In one implementation, a model may include information (e.g. training data) collected during one or more user's performance conducting one or more activities. The models may include training data from activities that, despite being different from the activity that an athlete is performing, may have similar relationships between attributes. As such, the models may serve as predictors of power. Accordingly, a model may include training data associated with one or more different activities. For example, a model may include training data received from one or monitoring processes associated with, among others, playing soccer and playing basketball. In this way, power data associated with certain movements of soccer and basketball activity data may be similar (within one or more predetermined numerical ranges for different periods during the activities, and the like).

In another implementation, a power model may comprise data from a same one or more users as those one or more users' data used in a second power model. In another configuration, a first model and a second model may use a same one or more users' data. In yet another configuration, data associated with a model may have been captured from a same one or more users during a single data collection period, or from multiple collection periods across a same or a different day, and the like. In one implementation, a first model may be associated with data from a first group of one or more sensors and a second model may be associated with a second group of one or more sensors, and wherein the first group may share one or more, or none of the same sensor types. In one implementation, the systems and methods described herein may compare calculated attributes from activity data (real-time activity data, and the like) to one or more models wherein the one or more models may not include data captured for that activity type. In this way the one or more models may be agnostic to the specific activity being performed by a user. For example, an activity device may receive information from a user performing a basketball activity. In response, the device may process the received basketball activity data (such as, for example, block 3306 of flowchart 3300), and compare calculated attributes to one or more models (such as, for example, block 3308). In one implementation, the one or more models may or may not comprise data related to basketball. In this way, the computed one or more attributes for received sensor data may correspond to one or more models, and wherein the models need not comprise training data related to the specific activity being performed by a user.

In one configuration, a plurality of models, each with their own attributes, which may or may not overlap attributes of other models, may be utilized. In one example implementation, each model may be associated with 50 attributes. In another configuration, the systems and methods described herein may store 1-500 attributes for each model. However, it is also contemplated that the systems and methods described herein may store any number of attributes with each model, and in certain embodiments a first number of attributes stored in with a first model may differ from a second number of attributes stored in with a second model. Furthermore, the one or more attributes stored in association with a model may be alternatively referred to as weights, or may be used to calculate related weighting values that may be used to compare a model to those attributes calculated from sensor data received from a device. Accordingly, in one implementation, the number of attributes calculated from data received from a sensor device (or multiple sensor devices) collecting movement data of a user may be equal to a number of attributes, or alternatively, a number of weights associated with one or more stored oxygen consumption models.

One or more aspects may calculate a probability that a first model will provide the most accurate estimation of power consumption from the total number of stored one or more models. For example, a probability that a specific model, from a group of different (e.g., 4) models is most likely to provide the most accurate output of power consumption may be calculated. The calculations may be performed, for example, as part of block 3308, and be based on one or more attributes calculated from received sensor data indicative of an activity being performed by a user. In one implementation, a level of closeness between attributes calculated from received sensor data, and those attributes, or alternatively, those weights, associated with one or more of the stored oxygen consumption models may be calculated, such as for example as part of block 3308. In one implementation, the systems and methods described herein may execute one or more processes to compare input attributes with corresponding weights associated with a stored model (expert). In one example, block 3308 may calculate a probability for each stored model. Accordingly, said probability may represent a likelihood that the calculated one or more attributes are a best-fit for a given model. For example, a probability may be calculated for each of, in one example, 4 stored power models (e.g. those 4 power models from Table 1), and the like. The highest probability value, from the 4 calculated probabilities, indicates the model with the best-fit for the calculated attributes, and the like. Further details related to a comparison of calculated attributes to stored models, and subsequent selection of a best-fit model for those calculated attributes, are explained in relation to FIG. 35.

In one example, block 3310 may represent one or more processes executed to select a model with a best-match, or best-fit to those calculated attributes from block 3308. As previously described, this best-fit model may represent stored training data that most closely approximates the data received from a sensor device monitoring an activity of the user. In one implementation, the best-fit model may be the model corresponding to a calculated probability value that is closest to a value of 1.0. In another implementation, block 3310 may select two or more models. For example, models fitting within a predefined deviation, variation, and/or threshold may be selected (referred to as a hybrid-model strategy).

As shown by illustrative block 3312, one or more embodiments may estimate an output value from a selected model (expert). In one example, an output may be in estimation of a volume of oxygen consumption as a result of one or more activities being performed by a user. Accordingly, in one example, block 3312 may correlate an activity being performed by a user with an estimated oxygen consumption value, and based on a selected model (e.g., a best-fit model) that most closely matches attribute values calculated from sensor data. In one implementation, a model may store one or more estimates of power consumption, wherein the one or more estimates of power consumption may be stored based on at least one individual-specific value, such as a gender, a weight and/or a height of a user. Accordingly, and based upon the one or more attributes associated with the sensor data received from a sensor device, block 3312 may return an estimate of power consumption by the user based upon an activity carried out by the user.

FIG. 34 depicts a flowchart 3400 showing an example implementation that may be utilized in the verification of data received from one or more sensors. In one example, flowchart 3400, either in whole or in part, may be implemented as part of executing verification implementations of block 3304 from FIG. 33. Block 3402 may represent one or more processes for receiving data from one or more sensors. As previously described, data may be received from sensors of different types, including, but not limited to, accelerometers, heart rate monitors, gyroscopes, location-determining device (e.g., GPS), light (including non-visible light) sensor, temperature sensor (including ambient temperature and/or body temperature), sleep pattern sensors, image-capturing sensor, moisture sensor, force sensor, compass, angular rate sensor, and/or combinations thereof. Data may be received, at block 3402, as one or more data points, or samples. Furthermore, data may be received as part of a continuous, or in intermittent data stream. Additionally, and as will be readily understood to those of ordinary skill in the art, data received at block 3402 may be from a single sensor, or multiple sensors, and may be received as a serial input, or as a parallel import (simultaneously). Block 3402 may encompass portions of block 3302 in certain embodiments.

Block 3404 may include one or more processes to identify a source of received data. Accordingly, block 3404 may identify a sensor type from which data is received. In one implementation, the information contained within a data point (a sample) may include an identification of a sensor type, sub-type, model and/or specific instance of a sensor from which the data was generated and communicated. For example, block 3404 may identify received data that has been received from an accelerometer, and the like. In another example, block 3406 of flowchart 3400 may identify the received data as being from one or more sensors. If one or more received data points are received from separate sensors, the data stream may be parsed (e.g., block 3408). In one example, block 3408 may be implemented to separate received data points based upon a sensor type from which the data has been received, and the like.

A value of a received data point may be compared to one or more threshold values (e.g., 3410). Accordingly, block 3410 may validate a received data point. In this way, a data point may be identified as representing a motion of a user, and distinguished from one or more values representing noise, and the like. For example, for an accelerometer data point, a threshold value may be, among others, 10% of a maximum output value from an accelerometer sensor. Accordingly, if a received data point from an accelerometer has a numerical value (in one example, an absolute numerical value, and the like), of less than 10% of the maximum output value from the accelerometer sensor, the data point may be identified as noise, and disregarded. Correspondingly, if the received data point from an accelerometer has a numerical value of greater than 10% of the maximum output value from the accelerometer sensor, the data point is it identified as a valid acceleration. It is contemplated, however, that a threshold value may take any numerical value, or otherwise, that is appropriate for a particular sensor type, and based upon, among others, an output range of numerical values from a particular sensor type. Furthermore, the exemplary 10% threshold associated with an accelerometer may additionally or alternatively be a 5% threshold, a 15% threshold, a 20% threshold, or 25% threshold, or any other numerical value, and the like. Furthermore, there may be more than one threshold associated with a specific sensor type. For example, a sensor may have two or more thresholds associated with data outputs. A first threshold may distinguish between noise and true acceleration data, and may be, for example, a 10% threshold. Furthermore, a second threshold may distinguish between true acceleration data and saturated data, and may be, for example, a 95% threshold, and the like.

Data from multiple sensors or inputs may be validated, such as at block 3410. As one example, one or more data points from a heart rate sensor, wherein a heart rate sensor data point may be compared to one or more thresholds. In one example, if a received heart rate is between 20 and 220 bpm, the heart rate data point is considered proper, and maybe subsequently communicated to a data buffer, such that the buffer described in relation to block 3412, and the like. In another example, a validation of heart rate sensor data may execute one or more processes to check that a number of heart rate data points are within a one or more predetermined beats per minute thresholds while a buffer is being populated with acceleration data.

One or more data points may be validated as being representative of useful data, such as for example at block 3410, wherein useful data may be representative of one or more activities or performances being carried out by a user. Accordingly, subsequent to validation of one or more data points, the validated data points may be stored (temporarily or otherwise) in a buffer (see, e.g., block 3412). It is contemplated that various types of buffers may be used, without departing from the scope of this disclosure. Accordingly, in one example, a buffer may be a dedicated hardware chip that includes elements configured for storage of digital information. A buffer may be implemented in a form of persistent memory, such as a hard disk drive (HDD), a solid state drive (SDD), an optical disk, and the like. Additionally or alternatively, buffer may be implemented in a form of volatile memory, such as, among others random access memory (RAM), and the like.

Certain embodiments may be configured to add one or more data points to a buffer, wherein said buffer may, in one example, store 256 data points (samples) before communicating the contents of the buffer to a transformation module. It is contemplated that, in one example, fewer than 256 data points may be stored in the buffer. For example, the buffer may store 128 samples, 64 samples, 32 samples, 16 samples, and the like. Similarly, it is contemplated that, in another example, greater than 256 data points may be stored in the buffer, and without departing from the scope of the disclosure described herein. Additionally or alternatively, the number of samples and/or data points stored in a buffer may be dependent upon the sensor type from which the data is received. For example, data received from an accelerometer may occupy more storage space than data received from a heart rate monitor, and the like. Furthermore, in one example, a transformation module may include one or more processes for manipulating and/or identifying features of received data, and the like.

In one implementation, a time stamp may be associated with a data point as it is added to the buffer. In another implementation, a timestamp may be associated with a validated data point independently of a buffer, and the like.

Certain embodiments may confirm whether a threshold number of data points are within a buffer, or series of buffers (see, e.g., block 3414). In this way, block 3414 may represent one or more processes to identify the number of stored data points in a buffer, and compare this stored number of data points to a threshold number of data points before flowchart 3400 proceeds to block 3416. For example, block 3414 may check the number of data points stored in a buffer, and compare this number of stored data points to a threshold number of 256 data points, and the like. In one example, once block 3414 identifies 256 samples stored in a buffer, flowchart 3400 may proceed to block 3416, and the 256 samples may be communicated to a data transformation module. If, however, it is determined at block 3414 that the number of samples stored in a buffer is less than a threshold number of, for example, 256 samples, flowchart 3400 may proceed to block 3402 for processing of additional data points, and the like. Those of ordinary skill will recognize that block 3414 may be omitted from flowchart 3400, without departing from the scope of the disclosure, and one or more data points may be communicated to a transformation module continuously, and without having received a threshold number of data points, and the like.

In accordance with one embodiment, a threshold of 256 data points may represent a window of data, wherein a window of data, which if collected at a frequency of 50 Hz would result in a length of time of about 5.12 seconds. Accordingly, a sample window may comprise a number of samples other than 256, sampled at any given frequency, and for any length of time, and the like. Furthermore, a transformation module may be one or more processes configured to execute on data received from one or more sensors. The one or more transformation processes may aggregate data into a dataset, wherein a dataset may be a group of data points representative of a motion and/or an activity of a user, and the like.

FIG. 35 depicts a flowchart 3500 which may represent one or more processes to compare one or more calculated attributes from received sensor data with one or more expert models. Accordingly, FIG. 35 may be described as an expert selection module. Those of ordinary skill in the art will readily understand statistical analysis methodology described as a mixture of experts. Accordingly, in one implementation, an expert may be a model that may be used to estimate an output value. Further, multiple experts may be utilized within a single power model, such as those power models described in Table 1. In one example, an output value may be an estimation of power associated with one or more activities being performed by a user.

As described briefly in relation to FIG. 35, in one example, 16 experts (models) may be stored in a device, such as device 112, 126, 128, 130, and/or 400. Additionally, there may be a number of attributes (otherwise referred to as weights) stored in association with each expert. In one example, 37 attributes may be compared with 37 weights associated with each expert model. In one example, the attributes calculated may correspond to those attributes presented in Table 1.

In response to receipt, at block 3502, of calculated attributes, weights associated with each stored expert model may be selected (block 3504). For each expert model, a probability may be calculated that said expert model is the best match for those received attributes, wherein the best match represents a model that will predict with highest accuracy an output of the model, given the calculated attribute inputs. In one example, block 3506 may represent one or more processes to calculate a probability that an expert is a best match for received attributes using a Softmax regression function, and according to a “mixture of experts” methodology, and the like.

Accordingly, given, in one example, 37 input attributes calculated from sensor data received from an accelerometer and/or a great sensor, and indicative of an activity being performed by a user, those 37 attributes may be compared to an equal number of weights associated with each of the models stored in the energy expenditure system. A calculated Softmax regression may return a probability value associated with each stored model, wherein each probability value represents a likelihood that the associated model will give a best available estimate of, in one example, a power being consumed by a user. For example, an energy estimation system may store four models (e.g. those power models from Table 1). Accordingly, using attributes calculated from received acceleration sensor data, a Softmax regression may be calculated for each of the four models. In one example, this Softmax regression may calculate a probability for each of the four models. Accordingly, the model corresponding to the highest calculated probability is the model to be used to give a best available estimate of a power being consumed by a user. In one implementation, a Softmax regression may be calculated using the formula:

$p_i=\frac{{}^{m_i^Tx}}{{\Sigma }_k{}^{m_k^Tx}}\left(\mathrm{Softmax}\mathrm{regression}\mathrm{equation}\right)$

As described in the Softmax regression equation above, p_i represents the probability that model i is the best model, from k different models, to use to predict a volume of oxygen consumption, given the vector of input attributes, symbolized by vector x, calculated from sensor input values. Furthermore, m_i is a vector of weights associated with model i.

Block 3506 may produce one or more outputs representing one or more probabilities that an associated expert model represents a best-much for calculated attribute values. Block 3508 may select an expert with a highest probability from those outputs of block 3506. Accordingly, block 3508 may estimate an output using the selected expert, and wherein the output may be an estimated power consumption by a user, and based on one or more activities being performed by the user, and the like.

Further aspects relate to systems and methods for calculating one or more other metrics, such as the athlete's speed, distance, and or other one or more parameters. In one embodiment in which speed is an attribute being calculated, a speed calculation module may be provided. Provided with the relevant attributes for the window of interest, systems and methods may be implemented to determine whether to calculate speed for one or more windows of data. In one implementation, if a data window is determined to contain walking or running data, the relevant attributes may be utilized, such as by being sent to a speed and distance module, to calculate speed and distance. Thus, it goes from the foregoing that certain aspects of this disclosure relate to determinations of speed or distance that comprises categorizing athletic data. As discussed above, certain aspects relate to calculating energy expenditure values without categorizing the athletic data into activity types (walking, running, basketball, sprinting, soccer, football, etc.), however, categorizing at least a portion of the same data utilized to calculate energy expenditure for the calculation of other metrics, such as for example, speed and/or distance is within the scope of this disclosure. Speed (or another parameter determined from the categorization of athletic data may) be computed from the same attributes utilized for the determination of energy expenditure values. In this regard, the same exact set of attributes may be used, however, in yet another embodiment, a sub-set of the same attributes may be used; and in yet additional embodiments, there may be only a single common attribute value utilized in the determination of two different metrics (such as, for example, speed and/or energy expenditure). In one implementation, speed (or another metric) may be determined from at least a portion of data derived from the determination of energy expenditure values.

Aspects of the embodiments have been described in terms of illustrative embodiments thereof. Numerous other embodiments, modifications and variations within the scope and spirit of the claims will occur to persons of ordinary skill in the art from a review of this disclosure. For example, one of ordinary skill in the art will appreciate that the steps illustrated in the illustrative figures may be performed in other than the recited order, and that one or more steps illustrated may be optional in accordance with aspects of the embodiments.

Claims

1. A unitary apparatus configured to be worn on a user, comprising: a processor;a sensor configured to capture motion data of the user;a non-transitory computer-readable medium comprising computer-executable instructions that when executed by the processor perform at least: capturing, from the sensor while being worn by the user, data comprising one or more data points generated as a result of a motion of the user;detecting a sensor type of the sensor;selecting, based on the detected sensor type, a sampling scheme;grouping the data stream into one or more sample windows;selecting, based on the detected sensor type, a model type;calculating an attribute for a selected sample window, from the one or more sample windows, based on the selected model type; andcalculating, using the selected model type and the calculated attribute, a power estimate for the user.

2. The unitary apparatus of claim 1, wherein the calculating using the selected model type comprises a mixture of experts process.

3. The unitary apparatus of claim 1, wherein the calculating an attribute comprises calculating a local linear regression model.

4. The unitary apparatus of claim 3, wherein the local linear regression model comprises a window weighting scheme.

5. The unitary apparatus of claim 1, wherein the capturing from the sensor is conducted while being worn on an appendage of the user.

6. The unitary apparatus of claim 1, wherein the attribute is selected for the selected model type using a greedy feature selection strategy.

7. The unitary apparatus of claim 1, wherein the detecting the sensor type is based on header data received from the sensor.

8. A method for calculating a power estimate for a user performing an athletic activity, comprising: capturing, from a sensor worn by the user, data comprising one or more data points generated as a result of the athletic activity;detecting a sensor type of the sensor;selecting, based on the detected sensor type, a sampling scheme;grouping the data stream into one or more sample windows;selecting, based on the detected sensor type, a model type;calculating an attribute for a selected sample window, from the one or more sample windows, based on the selected model type; andcalculating, using the selected model type and the calculated attribute, a power estimate for the user.

9. The method of claim 8, wherein the calculating using the selected model type comprises a mixture of experts process.

10. The method of claim 8, wherein the calculating an attribute comprises calculating a local linear regression model.

11. The method of claim 10, wherein the local linear regression model comprises a window weighting scheme.

12. The method of claim 8, wherein the attribute is selected for the selected model type using a greedy feature selection strategy.

13. The method of claim 8, wherein the detecting the sensor type is based on header data received from the sensor.

14. The method of claim 8, wherein the entire method is performed on a single device.

15. A non-transitory computer-readable storage medium comprising computer-executable instructions that when executed by a processor are configured to perform: capturing, from a sensor worn by a user, data comprising one or more data points generated as a result of an athletic activity;detecting a sensor type of the sensor;selecting, based on the detected sensor type, a sampling scheme;grouping the data stream into one or more sample windows;selecting, based on the detected sensor type, a model type;calculating an attribute for a selected sample window, from the one or more sample windows, based on the selected model type; andcalculating, using the selected model type and the calculated attribute, a power estimate for the user.

16. The non-transitory computer-readable storage medium of claim 15, wherein the calculating using the selected model type comprises a mixture of experts process.

17. The non-transitory computer-readable storage medium of claim 15, wherein the calculating an attribute comprises calculating a local linear regression model.

18. The non-transitory computer-readable storage medium of claim 17, wherein the local linear regression model comprises a window weighting scheme.

19. The non-transitory computer-readable storage medium of claim 15, wherein the attribute is selected for the selected model type using a greedy feature selection strategy.

20. The non-transitory computer-readable storage medium of claim 15, wherein the detecting the sensor type is based on header data received from the sensor.