TECHNICAL FIELD

[0001] Embodiments described herein generally relate to systems and methods for detecting hypoxia and, more particularly but not exclusively, to systems and methods for detecting hypoxia through monitoring baroreflex sensitivity using wearable sensor devices.

BACKGROUND

[0002] Hypoxia is a condition caused by inadequate supply of oxygen in tissues and organs. People may experience hypoxia by operating or otherwise being in environments with limited oxygen supply such as in poorly ventilated rooms or at higher altitudes. People may also experience hypoxia by engaging in strenuous activity. For example, first responders, soldiers, and athletes tend to be at higher risk of hypoxia than others.

[0003] Symptoms of hypoxia may include light-headedness, fatigue, and nausea. More extreme instances of hypoxia may be accompanied by symptoms such as disorientation, tachycardia, myocardial infarction, stroke, low blood pressure, and even death.

[0004] Existing techniques for detecting hypoxia at the systemic level generally involve some type of body-invasive measurements. For example, one existing technique is to extract a blood sample from a user to determine lactate levels. However, these invasive measurements for measuring hypoxia are impractical for real-time monitoring and detection of hypoxia.

[0005] A need exists, therefore, for systems and methods that overcome these disadvantages of existing techniques of detecting hypoxia.

SUMMARY

[0006] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description section. This summary is not intended to identify or exclude key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0007] In one aspect, embodiments relate to a hypoxia detection system. The system includes an electrocardiography sensor configured to gather electrocardiography data of a user; a plethysmography sensor configured to gather plethysmography data of the user; a features extraction module executing instructions stored on a memory to generate at least one baroreflex sensitivity feature based on the electrocardiography data and the plethysmography data; a hypoxia detection module executing instructions stored on the memory to compute a hypoxia index in real time based on the at least one baroreflex sensitivity feature; and a communications interface in operable communication with the hypoxia detection module and configured to present a notification to the user upon the hypoxia index indicating the user is at risk of hypoxia.

[0008] In some embodiments, the at least one baroreflex sensitivity feature includes at least one of QRS amplitude, plethysmography amplitude, ratio of QRS amplitude to plethysmography amplitude, heart rate variability, average time interval between heart beats, Sp0 ₂ , total spectral power, spectral power in different frequency bands, and pulse transit time.

[0009] In some embodiments, the system further includes a pre-processing module configured to perform at least one of filtering the electrocardiography and plethysmography data, and calculating a signal quality index based on the electrocardiography data and the plethysmography data, wherein a signal quality index exceeding a predetermined threshold indicates that a hypoxia index should be computed.

[0010] In some embodiments, the system further includes an acceleration sensor configured to gather acceleration data of the user, wherein the hypoxia index is additionally based on the acceleration data. In some embodiments, the system further includes a context inference module to infer the user's context from at least the acceleration data and to adjust the hypoxia index based on the user's context. In some embodiments, the system further includes a sensor providing altitude information to the context inference module.

[0011] In some embodiments, the electrocardiography data and the plethysmography data are gathered over individual temporal segments, and a hypoxia index is computed for each individual temporal segment.

[0012] In some embodiments, the system further includes at least one database module configured to store the electrocardiography data, the plethysmography data, and previously computed hypoxia indices. [0013] In some embodiments, the system further includes a beat detection module extracting heartbeat data from the electrocardiography data and the plethysmography data and providing the extracted heartbeat data as an input to the features extraction module.

[0014] In some embodiments, a hypoxia index exceeding a predetermined threshold indicates the user is at risk of hypoxia.

[0015] According to another aspect, embodiments relate to a method of detecting hypoxia based on baroreflex sensitivity. The method includes receiving electrocardiography data of a user; receiving plethysmography data of the user; generating, using a features extraction module executing instructions stored on a memory, at least one baroreflex sensitivity feature based on the electrocardiography data and the plethysmography data; computing, using a hypoxia detection module executing instructions stored on the memory, a hypoxia index in real time based on the at least one baroreflex sensitivity feature; and presenting, using a communications interface, a notification to the user upon the hypoxia index indicating the user is at risk of hypoxia.

[0016] In some embodiments, the at least one baroreflex sensitivity feature includes at least one of QRS amplitude, plethysmography amplitude, ratio of QRS amplitude to plethysmography amplitude, average time interval between heart beats, heart rate variability, Sp0 ₂ , total spectral power, spectral power in different frequency bands, and pulse transit time.

[0017] In some embodiments, the method further includes performing, using a pre-processing module, at least one of filtering the electrocardiography and plethysmography data, and calculating a signal quality index based on the electrocardiography data and the plethysmography data, wherein a signal quality index exceeding a predetermined threshold indicates that a hypoxia index should be calculated.

[0018] In some embodiments, the method further includes receiving acceleration data of the user, wherein the hypoxia index is additionally based on the acceleration data.

[0019] In some embodiments, the method further includes determining the user's context from at least the acceleration data using a context inference module; and adjusting, using the context inference module, the hypoxia index based on the user's context. In some embodiments, the method further includes determining the user's context from at least altitude information using the context inference module. [0020] In some embodiments, the electrocardiography data and the plethysmography data are gathered over individual temporal segments, and a hypoxia index is computed for each individual temporal segment.

[0021] In some embodiments, the method further includes storing, using at least one database module, electrocardiography data, the plethysmography data, and previously computed hypoxia indices.

[0022] In some embodiments, the method further includes extracting heartbeat data from the electrocardiography data and the plethysmography data using a beat detection module and providing the extracted heartbeat data as an input to the features extraction module.

[0023] In some embodiments, the hypoxia index exceeding a predetermined threshold indicates the user is at risk of hypoxia.

[0024] According to yet another aspect, embodiments relate to a computer readable medium containing computer-executable instructions for detecting hypoxia based on baroreflex sensitivity, the medium comprising computer-executable instructions for receiving electrocardiography data of a user; computer-executable instructions for receiving plethysmography data of the user; computer-executable instructions for generating, using a features extraction module executing instructions stored on a memory, at least one baroreflex sensitivity feature based on the electrocardiography data and the plethysmography data; computer-executable instructions for computing, using a hypoxia detection module executing instructions stored on the memory, a hypoxia index in real time based on the at least one baroreflex sensitivity feature; and computer- executable instructions for presenting, using a communications interface, a notification to the user upon the hypoxia index indicating the user is at risk of hypoxia.

BRIEF DESCRIPTION OF DRAWINGS

[0025] Non-limiting and non-exhaustive embodiments of the invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.

[0026] FIG. 1 illustrates a system for hypoxia detection in accordance with one embodiment;

[0027] FIG. 2 illustrates wearable devices for detecting hypoxia in accordance with one embodiment; [0028] FIG. 3 depicts a flowchart of a method for detecting hypoxia in accordance with one embodiment; and

[0029] FIG. 4 illustrates an exemplary hardware device for implementing the methods described herein in accordance with one embodiment.

DETAILED DESCRIPTION

[0030] Various embodiments are described more fully below with reference to the accompanying drawings, which form a part hereof, and which show specific exemplary embodiments. However, the concepts of the present disclosure may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided as part of a thorough and complete disclosure, to fully convey the scope of the concepts, techniques and implementations of the present disclosure to those skilled in the art. Embodiments may be practiced as methods, systems or devices. Accordingly, embodiments may take the form of a hardware implementation, an entirely software implementation or an implementation combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.

[0031] Reference in the specification to "one embodiment" or to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one example implementation or technique in accordance with the present disclosure. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

[0032] Some portions of the description that follow are presented in terms of symbolic representations of operations on non-transient signals stored within a computer memory. These descriptions and representations are used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. Such operations typically require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared and otherwise manipulated. It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Furthermore, it is also convenient at times, to refer to certain arrangements of steps requiring physical manipulations of physical quantities as modules or code devices, without loss of generality.

[0033] However, all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices. Portions of the present disclosure include processes and instructions that may be embodied in software, firmware or hardware, and when embodied in software, may be downloaded to reside on and be operated from different platforms used by a variety of operating systems.

[0034] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each may be coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

[0035] The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform one or more method steps. The structure for a variety of these systems is discussed in the description below. In addition, any particular programming language that is sufficient for achieving the techniques and implementations of the present disclosure may be used. A variety of programming languages may be used to implement the present disclosure as discussed herein.

[0036] In addition, the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the disclosed subject matter. Accordingly, the present disclosure is intended to be illustrative, and not limiting, of the scope of the concepts discussed herein.

[0037] Several body mechanisms are triggered in response to hypoxia. Airway neuroepithelial bodies sense changes in inspired oxygen and carotid bodies sense arterial oxygen levels. Both respond to the decreased oxygen supply by, for example, increasing lung ventilation, enhancing oxygen extraction efficiency, and increasing cardiac output and tissue perfusion.

[0038] Evidence suggests that activation of carotid body chemoreceptors by hypoxia reduces baroreflex sensitivity (BRS) or at least shifts the baroreflex stimulus response curves to higher blood pressures and heart rates.

[0039] BRS is a reflex mechanism that uses baroreceptors to regulate blood pressure by detecting blood pressure changes. Activation of baroreceptors (e.g., due to an increase in blood pressure) leads to a decrease in the discharge of sympathetic neurons to the heart and the peripheral bloods vessels. On the other hand, a decrease in systemic blood pressure causes the deactivation of baroreceptors and the subsequent enhancement of the sympathetic activity and vagal inhibition. This may lead to tachycardia, an increase in cardiac contractility and peripheral resistance, and venous return.

[0040] In accordance with various embodiments described herein, electrocardiography (ECG) data and plethysmography (PPG) data may be used to detect hypoxia. From this data, baroreflex sensitivity may be quantified and subsequently used to detect hypoxia.

[0041] The ECG data and PPG data may be gathered by devices worn by a user. These wearable devices may include, for example, the Phillips VitalPatch and the Philips Health Watch. Wearable devices therefore can detect hypoxia without requiring invasive techniques such as those discussed previously. Accordingly, the proposed system and methods continuously monitor hypoxia using noninvasive sensors that can be implemented in wearable devices and used during physical activity. [0042] FIG. 1 illustrates the architecture of a hypoxia detection system 100 in accordance with one embodiment. The system 100 may include a sensing module 102, a pre-processing module 104, a beat detector module 106, a features extraction module 108, one or more databases 110, a BRS sensitivity estimation module 112, a context inference module 114, a hypoxia detection module 116, and a communication user interface 118.

[0043] The sensing module 102 may include or interface with sensor devices to gather data regarding the user. Specifically, this data may include physiological and kinematic data. The sensing module 102 may include wearable sensor devices to gather ECG data and PPG data.

[0044] In some embodiments, the sensing module 102 may also include acceleration sensor devices to gather acceleration data of a user, pressure gauges (e.g., to detect pressure on a user), and GPS-based sensor devices to gather location and altitude data. In some embodiments, for example, acceleration based features such as a normalized acceleration value norm = calculate signal quality, where a _x , a _y , and a _z are acceleration in the x, y, and z directions.

[0045] Data gathered by the sensing module 102, particularly the ECG and PPG data, may be communicated to the pre-processing module 104. The pre-processing module 104 may be any hardware device capable of executing instructions stored on memory to process the data gathered by the sensing module 102. The pre-processing module 104 may be a microprocessor, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or a similar type of device. In some embodiments, such as those relying on one or more ASICs, the functionality described as being provided in part via software may instead be configured into the design of the ASICs and, as such, the associated software may be omitted.

[0046] The pre-processing module 104 may be configured to denoise, detrend, and/ or filter the data gathered by the sensing module 102. This may additionally serve as a calibration step for the data gathered by sensing module 102.

[0047] In some embodiments the pre-processing module 104 may filter out or otherwise only extract data that is above and/or below a certain level. Additionally or alternatively, the preprocessing module 104 may calculate an initial signal quality index for a particular temporal segment that may be used to decide whether a hypoxia index should be calculated for that segment. [0048] In other words, the pre-processing module 104 may be configured to consider an initial set of ECG and PPG data to determine if the data indicates a user may be at risk of hypoxia. For example, if there are several ECG and PPG readings that are abnormal, the hypoxia index may suggest that further analysis is recommended. On the other hand, if repeated ECG and PGG readings are normal and give no cause for concern, it may not be necessary or worthwhile to conduct further analysis.

[0049] The pre-processing module 104 may be configured to, upon receiving the data from the sensing module 102, calculate various derivatives of the measured user data, including but not limited to simple averages (i.e., a mean(s)), weighted averages, standard deviations, etc.

[0050] Output from the pre-processing module 104 may be communicated to the beat detection module 106. The beat detection module 106 may be configured to detect user heartbeats from the pre-processed ECG and PPG data. Additionally, the beat detection module 106 may be configured to detect ECG and PPG peaks to calculate amplitude -based and time-based features. This information may then be used by the features extraction module 108, discussed below.

[0051] Output from the pre-processing module 104 and/or the beat detection module 106 may be communicated to the features extraction module 108. The features extraction module 108 may be any hardware device capable of executing instructions stored on a memory to process the data from the sensing module 102, the pre-processing module 104, and/or the beat detection module 106. The features extraction module 108 may be a microprocessor, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or a similar type of device. In some embodiments, such as those relying on one or more ASICs, the functionality described as being provided in part via software may instead be configured into the design of the ASICs and, as such, the associated software may be omitted.

[0052] The features extraction module 108 may be configured to generate at least one baroreflex sensitivity feature based on the ECG and PPG data. The at least one baroreflex sensitivity feature may be then used to estimate the baroreflex sensitivity of a user.

[0053] The generated baroreflex sensitivity features may include at least one of QRS amplitude, sympathetic/parasympathetic tone, cycle length variability, plethysmography amplitude, ratio of the QRS amplitude to the plethysmography amplitude, heart rate variability, average time interval between heart beats, Sp0 ₂ , total spectral power, spectral power in different frequency bands, cardio-respiratory coupling (pulse transit time), and envelopes of the gathered data signals.

[0054] The gathered data may be sorted into individual temporal segments. These segments may be, for example, 1 minute in length, 30 seconds in length, 10 seconds in length, or some other time interval.

[0055] The generated barorefiex sensitivity feature(s) may be communicated to one or databases 110 for storage and/or to the BRS sensitivity estimation module 112 for analysis. The database(s) 110 may store sensed data regarding the user including all extracted features, learned contextual parameters, previously calculated hypoxia indices, BRS sensitivity, and other parameters learned from the hypoxia detection system 100 related to one or more users.

[0056] The BRS sensitivity estimation module 112 may estimate BRS sensitivity of a user based on the barorefiex sensitivity features generated by the features extraction module 108. The BRS sensitivity estimation module may be structured similarly to the features extraction module 108 described above. The output of the BRS sensitivity estimation module 112 may be a value that represents how likely it is that a user has hypoxia or is at least at risk of hypoxia. The output value may be a normalized value between 0 and 1, for example.

[0057] The context inference module 114 may analyze data that maybe indicative of the user's context. For example, if acceleration data gathered by an acceleration sensor indicates the user is moving quickly, the context inference module 114 may infer the user is engaging in strenuous activity such as exercise and that the user is at a higher risk of hypoxia. Similarly, if altitude data suggests the user is at a high altitude, the context inference module 114 may infer the user is at an increased risk of hypoxia.

[0058] The hypoxia detection module 116 may execute a trained hypoxia model to calculate a hypoxia index. The hypoxia index may be based on the generated barorefiex sensitivity feature(s) as well as labeled data from the one or more database(s) 110. In some embodiments, the hypoxia detection module 116 may implement a machine learning approach that relies on deep neural network or logistic regression techniques. Additionally, the hypoxia detection module 116 may consider input from the context inference module 114 to consider the user's context when calculating the hypoxia index and account for any increased context-based risk. [0059] The hypoxia detection module 116 may combine the received data from the various sources using an ensemble learning method such as boosting or stacking. This in turn produces a hypoxia index that is adjusted for the risk associated with the user's environmental context.

[0060] The communications user interface 118 may deliver relevant information to the user as well as to other interested parties. This information may include whether or not the user, based on the processed data and the calculated hypoxia index, is at least at risk of hypoxia. This information may be presented in the form of a textual message, visual message, audio message, haptic-based message, or some combination thereof.

[0061] For example, FIG. 2 illustrates exemplary user interfaces 202 and 204 that may present indicia 206 and 208, respectively, that informs a user 210 about their hypoxia risk. In these embodiments, interface 202 is configured as a watch device and interface 204 is configured as a smartphone device executing a web page or a smartphone application. FIG. 2 also shows wearable sensor devices 212 and 214 for gathering ECG and PPG data, respectively. The patch sensor 212 and the smart watch 214 are merely exemplary. The systems and methods according to various embodiments may leverage any other types of sensor device(s) that measure ECG and PPG.

[0062] In addition to presenting the hypoxia index, the interfaces 202 and 204 may also present data regarding specific features of the user's health. For example, the interfaces 202 and 204 may display measurements related to the user's cardiovascular system such as heart rate, RR (cycle length) variability, BRS, and Sp0 ₂ .

[0063] As mentioned above, the hypoxia index and other data regarding a user may be communicated to other interested parties. These interested parties may include, for example, medical personnel, an accompanying first-responder and/or a supervisor or anyone else with access to a suitable interface.

[0064] FIG. 3 depicts a flowchart of a method 300 for detecting hypoxia in accordance with one embodiment. Step 302 involves receiving ECG data of a user. The ECG data may be gathered by a wearable device such as a smartwatch or other type of wearable sensor device.

[0065] Step 304 involves receiving PPG data of the user. The PPG data may be gathered by a a smartwatch or other type of wearable sensor device. [0066] Step 306 involves generating at least one baroreflex sensitivity feature. This step may be performed by the features extraction module 108 of FIG. 1, for example. Generated baroreflex sensitivity features may include at least one of QRS amplitude, sympathetic/parasympathetic tone, cycle length variability, plethysmography amplitude, ratio of the QRS amplitude to the plethysmography amplitude, heart rate variability, average time interval between heart beats, Sp0 ₂ , total spectral power, spectral power in different frequency bands, cardio-respiratory coupling (pulse transit time), and envelopes of the gathered data signals.

[0067] Step 308 involves computing a hypoxia index. This step may be performed by the hypoxia detection module 116 of FIG. 1 , for example. The hypoxia detection module 116 may compute a hypoxia index for each interval in which ECG data and PPG data are gathered. For example, if an ECG and PPG reading are gathered once every ten seconds, then a hypoxia index may be computed once every ten seconds. Effectively, the method 300 of FIG. 3 may be repeated multiple times over multiple time intervals.

[0068] Step 310 involves presenting a notification. This notification may be presented by a communications user interface such as the interfaces 202 and 204 of FIG. 2. The notification may be made by any suitable technique (e.g., auditory, visual, etc.), and may be presented if a hypoxia index exceeds a predetermined threshold thereby indicating a user at risk of hypoxia. Or, in other embodiments, a notification may be presented only if the hypoxia index exceeds a threshold after a certain number of consecutive readings. In yet other embodiments, machine learning techniques may be applied to recognize readings that are abnormal for a particular user and may be indicative of hypoxia for that user.

[0069] FIG. 4 illustrates an exemplary hardware device 400 for detecting hypoxia in accordance with one embodiment. As shown, the device 400 includes a processor 420, memory 430, user interface 440, network interface 450, and storage 460 interconnected via one or more system buses 410. It will be understood that FIG. 4 constitutes, in some respects, an abstraction and that the actual organization of the components of the device 400 may be more complex than illustrated.

[0070] The processor 420 may be any hardware device capable of executing instructions stored in memory 430 or storage 460 or otherwise capable of processing data. As such, the processor 420 may include a microprocessor, field programmable gate array (FPGA), application-specific integrated circuit (ASIC), or other similar devices.

[0071] The memory 430 may include various memories such as, for example LI, L2, or L3 cache or system memory. As such, the memory 430 may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read only memory (ROM), or other similar memory devices.

[0072] The user interface 440 may include one or more devices for enabling communication with a user. For example, the user interface 440 may include a display, a mouse, and a keyboard for receiving user commands. In some embodiments, the user interface 440 may include a command line interface or graphical user interface that may be presented to a remote terminal via the network interface 450.

[0073] The network interface 450 may include one or more devices for enabling communication with other hardware devices. For example, the network interface 450 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol. Additionally, the network interface 450 may implement a TCP/IP stack for communication according to the TCP/IP protocols. Various alternative or additional hardware or configurations for the network interface 450 will be apparent.

[0074] The storage 460 may include one or more machine-readable storage media such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, or similar storage media. In various embodiments, the storage 460 may store instructions for execution by the processor 420 or data upon with the processor 420 may operate.

[0075] For example, the storage 460 may include an operating system 461 that includes: a sensing module 462 for at least gathering ECG and PPG data of a user; a pre-processing module 463 for denoising, filtering, or detrending the gathered data; a beat detection module 464 for, among other things, detecting ECG and PPG peaks; a feature extraction module 465 for generating at least one baroreflex sensitivity feature; a BRS sensitivity module 466 for detecting BRS sensitivity; a context inference module 467 for inferring the context of a user; and a hypoxia detection module 468 for calculating hypoxia indices. [0076] The methods, systems, and devices discussed above are examples. Various configurations may omit, substitute, or add various procedures or components as appropriate. For instance, in alternative configurations, the methods may be performed in an order different from that described, and that various steps may be added, omitted, or combined. Also, features described with respect to certain configurations may be combined in various other configurations. Different aspects and elements of the configurations may be combined in a similar manner. Also, technology evolves and, thus, many of the elements are examples and do not limit the scope of the disclosure or claims.

[0077] Embodiments of the present disclosure, for example, are described above with reference to block diagrams and/or operational illustrations of methods, systems, and computer program products according to embodiments of the present disclosure. The functions/acts noted in the blocks may occur out of the order as shown in any flowchart. For example, two blocks shown in succession may in fact be executed substantially concurrent or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Additionally, or alternatively, not all of the blocks shown in any flowchart need to be performed and/or executed. For example, if a given flowchart has five blocks containing functions/acts, it may be the case that only three of the five blocks are performed and/or executed. In this example, any of the three of the five blocks may be performed and/or executed.

[0078] A statement that a value exceeds (or is more than) a first threshold value is equivalent to a statement that the value meets or exceeds a second threshold value that is slightly greater than the first threshold value, e.g., the second threshold value being one value higher than the first threshold value in the resolution of a relevant system. A statement that a value is less than (or is within) a first threshold value is equivalent to a statement that the value is less than or equal to a second threshold value that is slightly lower than the first threshold value, e.g., the second threshold value being one value lower than the first threshold value in the resolution of the relevant system.

[0079] Specific details are given in the description to provide a thorough understanding of example configurations (including implementations). However, configurations may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have been shown without unnecessary detail in order to avoid obscuring the configurations. This description provides example configurations only, and does not limit the scope, applicability, or configurations of the claims. Rather, the preceding description of the configurations will provide those skilled in the art with an enabling description for implementing described techniques. Various changes may be made in the function and arrangement of elements without departing from the spirit or scope of the disclosure.

[0080] Having described several example configurations, various modifications, alternative constructions, and equivalents may be used without departing from the spirit of the disclosure. For example, the above elements may be components of a larger system, wherein other rules may take precedence over or otherwise modify the application of various implementations or techniques of the present disclosure. Also, a number of steps may be undertaken before, during, or after the above elements are considered.

[0081] Having been provided with the description and illustration of the present application, one skilled in the art may envision variations, modifications, and alternate embodiments falling within the general inventive concept discussed in this application that do not depart from the scope of the following claims.