Skip to main content

Abstract

Hypoxic hypoxia is a condition airborne soldiers can experience at high altitudes. It is caused by a lack of oxygen entering their system due to a reduced concentration of it in the atmosphere. If symptoms go unnoticed this condition can have severe consequences including loss of consciousness and death. We propose to develop a glove-integrated pulse oximeter to track soldiers’ oxygen levels live and transmit that data to relevant parties. Our system will emulate a microservice architecture which will allow for simpler integration of other sensors later down the line.

Problem Statement

Hypoxic hypoxia is a condition airborne soldiers can experience at high altitudes. It is caused by a lack of oxygen entering their system due to a reduced concentration of it in the atmosphere. Symptoms can go unnoticed because those experiencing them are engrossed in their tasks. At extreme altitudes of over 45,000 feet, a soldier has less than 12 seconds to react to an interruption to their oxygen supply before severe symptoms occur. At less extreme altitudes, the period of time after oxygen interruption is several minutes - a small amount of time itself. Symptoms of hypoxic hypoxia are caused by gradual organ failure and manifest themselves in different ways, including: poor judgment, coordination, and alertness; impaired flight control, speech, and intellectual function; and circulatory and nervous system failure, convulsions, and a loss of consciousness.

 

Proposal

Our proposal is to create a pulse oximeter integrated into a glove that soldiers already wear. This device will transmit live data of soldiers’ oxygen levels to higher command and other relevant parties. It will consist of three major microservices: an ATAK service, a wireless transmitter service, and a pulse oximeter service. These will run separately from each other, allowing for a flexible physical implementation of each separate piece that all communicate in a secure manner. Eventually, our system will be scalable to include other sensors in the data-stream pipeline.

Challenges and Unknowns

 

  • Special operations environment has a lot of unknown factors that may aid us in our development or add some challenges. The environment itself is largely unknown.
  • Distance HALO jumpers are from each other during a jump. Decides what strength frequency is required for communication with the device. (High frequency is better as it transmits data no longer than a certain distance and since the HALO jumps are meant to be stealthy, it is better if no enemy systems are able to detect the signals) 
  • What are possible obstacles that could affect radio communication? What measures can be taken if communication fails? 
  • What is the timeline for people receiving the information, and being able to properly respond to it? How will this affect the mission?
  • What kind of gear do soldiers in these environments have? How can we use that gear to aid in our development?
  • What kind of physical precautions do we have to take for operation security?
  • What kind of encryption precautions do we have to take for operation security

Comments

Danielle@LL | 5 November 2021

Hi team,

This is a great concept, and there are a lot of great challenges within this topic for you to make an impact. Some questions that you can start investigating to strengthen your proposal are as follows:

  1. Decide on a basic timeline for your product's operation to include sensing, processing, transmission, and decision making.  Make a "time budget" for how fast you need each component to do it's job to accomplish the mission.   
  2. What COTS components might be purchased to solve a portion of this problem.  Are there sensors out there, do they meet reasonable size, weight, and power (SWAP) constraints?  What is the normal range of COTS radio comms, etc?  Once you know what is available, you can work on filling the gaps to create the larger solution.
  3. What level of processing to we need to accomplish the analytics required.  Where do we want to have the processing be done (on the glove or elsewhere in the system)?
  4. What data do we want to pass around between the three system components, and to the end-users and command?  How would this information be displayed (or audio alarm, etc.)
  5. You bring up some great points about radio comms reliability and security.  These in themselves are potential topics for investigation, and are always good to consider in a system like this.

I look forward to meeting with you all to discuss.

Danielle