Electrical Engineering Department

California Polytechnic State University

Senior Project Final Report

Portable Ventilator
June 11th 2021

Jack Brewer

Sanders Sanabria

Brad Weeks

Client Rich Murray

Advisor Rich Murray

Professor Rich Murray

Table of Contents:
Section: Pages:
Abstract 2

Background 3-4

Product/Project Description 5

Product Research 6

Technology Research 6-7

Market Research 7-8

Customer Archetype 8 - 11

Market Description 11 - 14

Business Model Canvas Graphic 15

Marketing Requirements 16 - 17

Marketing Data Sheet 18

Block Diagram 19 - 20

Engineering Requirements 20 - 21

Testing and Verification 21 - 23

Team Project Roles 23

Schedule 24 - 25

Product Cost Estimation 26 - 27

Analysis of Senior Report 27 - 30

Preliminary Design Analysis 31 - 32

EE 461 Addendum 32- 43

EE 462 Addendum 43- 57

References 58 - 70

1
Abstract

The current COVID-19 pandemic has heavily impacted the healthcare system in the
United States and elsewhere. The need for patients to have access to a hospital with a ventilator
along with a shortage of ventilators for recovery and at-home care as a result of minimal hospital
vacancy for patients has been greatly stressed. The presented problem is both an unmet demand
and supply of portable and effective ventilators. Existing ventilators have many shortcomings
that should be addressed: size, weight, cost, and complexity of current ventilators confines users
to stay in a medical facility whilst being monitored by professionals. This both increases the risk
the user has of contracting other diseases and increases the cost to operate a ventilator. Therefore,
there is a need to create a ventilator that is both smaller and more accessible than what is
currently available.

The solution is to design a ventilator which can meet the symptoms and strains which
COVID-19 can put on various individuals, should they not have access to a commercial
ventilator as an economic constraint, or have restricted access to a medical facility attributed to
the influx of patients. This means that a portable ventilator targeted for lower risks patients to be
the ideal ventilator design. This ventilator would allow for short term out-patient care of low risk
patients, thus allowing hospitals to focus on high risk patients. The lower risk patients would
then be allowed to be at home and away from hospitals where both the expenses and risks of
catching diseases would be higher. This would also mean that there would be greater access to
care and less people denied care. While the focus is currently on COVID-19 patients, the use of
the ventilator will extend to other patients who also need help breathing. The ventilator would
include wireless communication, smartphone integration, and a portable power system which
would allow consumers to relocate the ventilator as needed and have back-up power in the event
of a power outage.

2
Background

A ventilator is a machine that uses mechanical ventilation to help patients breathe and
provide oxygen when their own body is not able to do this correctly.[1] The first widely used
ventilators were during the polio epidemics,1920s and 1930s, and called iron lungs. These were
large noninvasive devices that required most of the patient’s body to be in a box. Then it used
negative pressure to expand/contract the patient’s chest and thus also the lungs, drawing air
in/out. [2]

Figure 1 Iron Lung [3]

Following the polio epidemics, the use of mechanical ventilation continued as its benefits
were now more widely known, especially in sedated patients. This led to innovation and a focus
in minimizing the side effects. The following ventilators, East Radcliffe and Beaver models, used
electric motors, but this created a hazard when used around flammable anesthetics. To remove
this risk the Roger Manley model was created, 1952, which was gas-driven, thus removing the
explosion hazard, and introduced to the mainstream positive pressure ventilation. This model
remained the popular choice for anesthetic purposes for decades. Three years later in the US, the
Bird model was created which was pneumatic, or pressurized air driven. This allowed the device
to be operated without an electric source. Thus it became popular in the US army and, soon after,
in US hospitals.

In the following years, the ventilators were constantly improved to function better,
minimize maintenance, and increase reliability. However, the next big revolution in ventilator
design did not occur until the introduction of microprocessors. This third generation of
ventilators started with the Drager EV-A and finally allowed for monitoring of patients on a

3
screen. Immediately following, were the Puritan Bennett 7200, the Bear 1000, the Servo 300,
and the Hamilton Veolar models. These allowed for customized air delivery, improved
monitoring, and quick responsive action to patient changes.[4]

Figure 2 Hamilton Veolar Model[5]

Modern ventilators, fourth generation ventilators, did not have a clearly defining
innovation as previous generation but are different nonetheless. Current ventilators are controlled
by an embedded system that performs all the necessary controls and responses needed. There are
also many different alarms and failsafes in place to protect patients from any device
malfunctions. These ventilators are also mostly designed for specific needs, such as adult
ventilation, transport, and neonatal. They also require to be plugged into a power source, thus
limiting patients movement. Due to the complexity of the ventilators, professional monitoring
and hospitalization is needed further increasing the price and constraints on patients. This leaves
a need for a ventilator that can be operated outside the hospital and gives back freedom and
comfort to the patient.

Figure 3. Current ICU Ventilator Setup[6]

4
Product/Project Description

The Portable Ventilator is a mechanical ventilation device designed to tackle one of the
biggest problems with current ventilators, their restrictiveness. Currently patients are required to
either be hospitalized and occupy an ICU room risking contracting disease or forgoing care. This
leaves many patients with milder symptoms to have two bad options. Along with this, hospitals
are also at a loss. Every patient with milder symptoms that is hospitalized is one less ICU room
available for other patients with more severe symptoms. This also puts a strain on the limited
resources hospitals have, such as nurses, since the ventilator must be constantly monitored and
adjusted.

Figure 4[18]: The first FDA approved portable Figure 5 [13]: Current portable
Unified respiratory system. Ventilator by Philips Respironics

The Portable Ventilator seeks to solve these problems by providing a third option to
patients and hospitals. This is the ability to provide out-patient care for mild cases that require
help breathing and oxygen intake. This would be done by designing the Portable Ventilator to be
lighter, smartphone compatible, automatic monitoring and adjustment, and a simpler interface for
controlling the device. This would allow the ventilator to be used at the patients home with no
need for professional monitoring. This would meet both the patient’s need to be provided care
without hospitalization and the hospital’s need to keep available rooms and staff.

5
Product Research
Today most of the ventilators in the market and in use are designed for hospital use and to
address specific medical needs. This means that an ICU ventilator may not be able to be used for
neonatal ventilation. Having a many different types of ventilators allows most patients to be
treated for whatever condition they may get. Modern ventilators include many health safety
features to ensure that the patient remains safe even when there is an error.[4] This includes
alarms for dangerous changes in patients’ biometrics. Another safety feature is the monitoring
and displaying of both patient and device conditions. One of the most important features of
current ventilators is the ability to change the settings and provide precise control of the device.
However, this means that to operate a ventilator not only requires accurate ventilator knowledge
but also accurate medical knowledge. This causes ventilators to require professional monitoring
and administering.
The current portable ventilators in the market are mostly transport ventilators. These are
used to provide short ventilation to patients when they are being transported from one facility or
room to another. The remaining portable ventilators are meant for use outside a hospital.
However, both of these types of portable ventilators are still complicated and require a medical
professional to operate them. This leaves open a market for a portable ventilator that can be
operated and monitored by a non-professional, such as the patient or a family member.

Technology Research
Ventilators are controlled by microprocessors. These microprocessors are responsible for
controlling and communicating with various components. These components include the sensors,
compressors, pumps, displays, and etc. For the Portable Ventilator design we would need a
microprocessor that can perform those same duties using I2C communication protocol along
with having wireless capability. A Raspberry Pi 4 microprocessor is capable of this[8]. The
sensors needed are many, with flow rate, temperature, humidity, and O2 being a few. There are
many available sensors that could be used which are both small and require little power.

6
 Figure 6 [8]: Raspberry Pi 4 Model B microprocessor.

Focusing on mild symptom/low risk patients could allow the Portable Ventilator to be
designed without an air compressor and reduce the cost and complexity of it. Due to the
widespread use of advanced smartphones, the Portable Ventilator can use an app to easily
communicate with the user and allow the user to easily adjust the ventilator.
The most important feature of modern ventilators are the alarms and failsafe features to
protect the patient. This is done through the monitoring of the patient’s biometrics and ventilator
conditions. Any problem encountered by the ventilators would cause the alarms to set off and
failsafe features to activate, if needed, until a nurse can attend to the patient[9]. With the use of
an app, the portable ventilator can guide the patient or family member on the steps needed when
there is a problem and automatically call for medical attention.

Market Research
The ventilator market is a growing market due to both an increase in the geriatric
population and the COVID-19 pandemic.[10] The COVID-19 pandemic rapidly increased the
demand for ventilators and companies responded by increasing production of ventilators.
However, this increase in production was for ICU ventilators. This led to a saturation in the
market as the number of ventilators that can be used is limited by the number of ICU rooms
available. Therefore, the largest reason for patients not receiving the necessary ventilation they
need is not caused by a lack of ventilators but a lack of hospital space and medical staff. This
leaves a need for hospitals to alleviate their in-patient care and increase out-patient care. The
Portable Ventilator is designed to meet that need and fill that market.

7
 Along with opening up hospital space, the Portable Ventilator will also fulfill the need for
patients to remain active and comfortable. Presenting this new option should cause many current
patients to opt into using the Portable Ventilator over the current one they are using.
While the current demand is being driven mainly by the current pandemic, the demand
will continue to increase for years due to the geriatric population. The limitations for this
increase are due to high cost and operating requirements [15]. The Portable Ventilator would
address these issues by presenting a cheaper, lighter, and accessible alternative for out-patient
care in both nursing and private homes.

Customer Archetype
*The customer archetype was adapted from our CPE team
In order to create a customer archetype, one must fully understand the needs that the
portable ventilator must satisfy. To meet the needs of a customer, the device must be completely
reliable. In many cases, the user’s life will depend on the functionality of this device. Any patient
using the device will require the following:
● Constant monitoring of blood oxygen level
● Constant supply of oxygenated air (21%-100%)
● Adjustable flow rate of incoming air (0-40 L/min)
● War, (31-37°C) and humidified air (up to 100% humidity)
● Portability for at least 3 minutes
To meet these needs, the device needs an internal power supply, portable oxygen supply (likely
an oxygen tank), and needs to be lightweight (ideally less than 25 pounds).

Through research and advice from advisors, we have found two main customer
archetypes: high risk and low risk patients. The high risk archetype is a COVID-19 patient who
only intends to use our device temporarily during recovery. There is a great risk that their
condition may worsen rapidly, resulting in their return to the hospital. The other archetype, the
low risk patient, intends to use our device long-term and suffers from milder symptoms without
much risk of their condition worsening. Details of these two customer archetypes are explained
below.

8
High Risk
These patients have an active family member nearby who can assist them if needed in an
emergency. These patients also have a professional healthcare clerk checking in with them as
needed (to be determined by healthcare personnel).

Users in the high risk archetype have a hands-off approach to their ventilator, as they may rely on
others to actively monitor their physical state and adjust oxygen flow accordingly. A member of
this archetype must complete an initial health survey with a medical professional who will
provide the parameters for various ventilator modes. The user will then wear the ventilator as
often as the medical professional dictates.

The user or user’s caretaker will be responsible for monitoring their health status. If a healthcare
professional monitoring them (remotely) inquires about specific reading, the user can provide the
indicated data by observing their smartphone application or inspecting the app’s history setting.
Additionally, the user must monitor health status in the case of an emergency. Should the
ventilator fail, the user must seek medical assistance immediately. The patient should also have
an emergency bag-valve-mask (BVM) in case of a power outage.

Low Risk
For this product, low risk patients are those adult patients with chronic breathing ailments who
intend to use this device indefinitely. They may already be using an at-home ventilator due to
preexisting health conditions, such as chronic lung disease, spinal injuries, muscular dystrophy,
or other ailments that prevent effective breathing. These patients regularly visit their doctor but
otherwise have complete control over their daily oxygen supply/delivery level that they change
depending on how they feel or what activities they are doing.

These patients are not sick enough to be placed on an ICU ventilator for more than 14 days.
Beyond mild breathing ailments, these patients are physically fit and may desire to return to an
active lifestyle.They would greatly benefit from a return to a “normal” lifestyle by returning
home with a similar oxygen delivery device. They may live independently or in a group home
setting. Helping these patients would free up ER and hospital space.

The low risk patient would begin by completing the initial health history survey by themself or
with the guidance of a medical professional to create their ventilator presets. They will then wear
the ventilator whenever they feel that they need breathing assistance.This user is responsible for
monitoring their own health and hardware status. The ventilator may automatically adjust mode
based on biometrics, but this will be limited by user presets. For finer control, the user must
manually change their mode/inputs depending on what they feel is needed. The patient should
also have an emergency bag-valve-mask (BVM) in case of a power outage.

9
Currently Available Devices Manufacturers/Descriptions

Allied Healthcare Products Inc. [11]: Sells the

EPV200 which is a portable , lightweight, and robust
ventilator system for $700. It is designed to provide
effective ventilation for intubated or non-intubated
patients to maximize medical surge response during
inital stages of a mass casualty event. It can run up to
48 hours on two D cell batteries. It does not include
an oxygen tank.

Figure 7 [11]

Invacare [12]: Sells the Invacar Perfecto2 V Oxygen

Concentrator which is a two feet tall home oxygen
machine. It weighs 39 pounds and costs around
$677. It uses less power that most O2 concentrators
while maintaining the same oxygen output. It offers
quiet operation which is ideal for use while sleeping.
It offers up to 5 liters of continuous oxygen per
minute.

Figure 8 [12]

Philips Respironics [14]: Sells the SimplyGo

portable oxygen concentrator for $2500. This device
is extremely compact and lightweight at only 10
pounds. This device comes with multiple different
oxygen delivery modes for the patient to configure.
While this device is more expensive, it makes up for
it with more portability and easier functionality.

Figure 9 [14]
Table 1: Market Leaders/Industry Competitors

10
 For our product, we are expecting hospitals to purchase the devices and lease them out to
the patients described by our high risk customer archetype. These costs could be covered by
insurance agencies for the patients. For our low risk archetype customers which may require
more permanent use, we would expect them to purchase their own ventilator.

According to ReportLinker [13], “The Global Portable Ventilator Medical Ventilators

Market is expected to grow from USD 368 Million in 2019 to USD 846 Million by the end of
2025.” This is due to the high demand caused by COVID-19 related issues. Due to the size of
this market with the relatively low supply of manufacturers, our product could possibly break
into the market. Our product can bring functionality, portability, and price to an ideal spot which
can appeal to a large amount of customers.

Market Description

The portable ventilator aims to create an avenue for hospitals to provide out-patient care
so that they may increase the amount of rooms available for patients with more severe
respiratory symptoms while still administering adequate out-patient care for those with
less-severe symptoms. The ventilator will be driven with a desire to make sure all patients with
respiratory symptoms may receive the care they need appropriate to their symptom severity. This
is much inspired by the 2019 outbreak of COVID-19 and its impact on hospitals with a focus on
the United States.

Developmental Challenges and Limitations

Software Our team includes members who are proficient

in firmware/embedded systems development,
but limited high-level software development
experience. There is a separate team which
deals with external communication to other
devices (i.e. Smartphone, smartwatch), but
communication between the two groups may
be challenging.

Specialized Parts A fair portion of the parts included in the

materials required for construction of this

11
 system are quite foreign to this Electrical
Engineering team. Such parts include
pneumatic pumps, air filters, and valves. This
limited knowledge will have to be
compensated for by accelerated research so
that parts which fit together nicely in the rest
of the system will be able to meet the system
specifications and are able to be actuated
accordingly if necessary.

FDA Regulatory Process In order for this product to be legally

sold/used/prescribed for use in the United
States, the Food and Drug Administration
requires that the device to conform to a list of
regulations that make it suitable for different
applications: Declarations of Conformity,
Device Specifications and Instructions for
Ventilators and Accessories, Reprocessing and
Shelf-life Information, Facility Requirements,
and Labeling Requirements for Conditions of
Use. These standards will need to be heavily
researched and verified before, while, and after
construction for this product to be legally
market-viable. Additionally, the FCC’s
Electronic Code for Federal Regulation 47
FCC Ia. 15b §109a specifies that for Class B
devices, the field strength of field strength of
radiated emissions from a Class B digital
device, as determined at a distance of 3 meters,
shall not exceed 500 microvolts per meter
when operating above 960 MHz. In this case
because bluetooth operates within the ISM
band (2.45 GHz), this device falls within this
region and is subject to §15.109(a) regulation.
For reference, see Appendices A and B for
Ventilators on the FDA’s website [7], and see
[19] to view table (a) of §15.109 on the FCC’s
website to view acceptable emi emission
limits.

Manufacturing This system is not meant to replace ventilators

found in emergency rooms and ICUs, it is an
outpatient compliment to such systems.
Therefore the components and parts found
within hospitals will be far too expensive and
perhaps exclusive to obtain. Therefore, it will

12
 be necessary to source adequate parts in order
to have them assembled and tested together.
We can design and print circuit board
assemblies externally, but some of the
mechanical pieces such as the O2 tank may
have to be sourced pre-manufactured.

Time Limitations We are constrained by the strict deadline of the

CPE team who is working on the software and
connectivity of the ventilator to other devices.
This deadline requires a (working) alpha
prototype to be completed by the end of the
quarter, therefore it is necessary to develop our
component list early on and order parts as soon
as possible.

Proprietary Information Along with an FDA approval, other

biomedical device companies hold I.P. on
many products which makes it a difficult realm
to enter, checking parts to make sure they do
not require licensing for use or looking into
paying royalties for a part of the system may
be a heavily limiting factor.

Table 2. Limitations

Our product offers a solution over other ventilators in that is provides a solution to
hospitals and patients: hospitals will have more room to treat patients with more serious
symptoms (left to the in-house ventilators), and patients with minor symptoms will be able to
receive remote treatment from the comfort of their own homes, which is advantageous for
recovery of minor symptoms [16]. The portability of this device will also allow it to be
advantageous over those located within hospital premises. It allows the user to move the device
from room to room without the need to fear for their respirator well-being as it will be able to run
on a battery for a short amount of time before it will need to be charged again.
An area of this market we are not competitive in is the high-performance ventilators, this
is not the goal of this device and that market is extremely competitive. This segment is

13
dominated by professional biomedical, electrical, and mechanical engineers to be error-averse
and log highly accurate and sensitive data. This product aims to provide a sufficient level of care
for symptoms which require attention but not serious medical intervention.
The window of opportunity for our product is people who require medical attention for
their respiratory symptoms, but are not prioritized due to the lack of hospital vacancy and the
potential severity of other patients.
To penetrate the market, serious capital would have to be invested into getting this device
FDA approved, patent the device, visit trade shows and hospitals to talk with hospital business
administrators, and designing and building a working prototype. This will require a minimum of
$25,000 of funding to provide for the materials to produce a ventilator unit, for the labor of the
team, for the applications towards patents and FDA approval, and for travel to trade shows and
hospitals. The time investment would be large for the team involved. Due to the small team, it
could take around 20 hours per person in order to get a unit functional. It also may take two years
to get all of the approvals and begin to enter the market.

Advantages Disadvantages

More patients have access to medical care Not all patients will receive the same level of
care- rather receiving care that meets their
symptom severity.

Cost-Efficiency: Doctors and nurses are only Response to more serious symptoms may be
seeing the most symptomatic patients in delayed compared to the time care would be
person, which means more hospital rooms administered in a hospital.
available and time being spent more
effectively.

Outpatient Care Augments hospitalization access and acute

cases
Table 3: Advantages and Disadvantages

14
Business Model Canvas Graphic

Figure 10: Business Model Canvas

15
Marketing Requirements

Marketing Requirements Reasons

Affordable (Priced below $1000) This provides a cheaper ventilator alternative
than the expensive ones in the market
currently.

Biometric Monitoring Allows the user to easily access the

biometrics of the patient without need for
additional hardware.

Smartphone Integration Allows the user to use the ventilator without

needing to ensure the ventilator is visible(can
be carried in a backpack).

Portable Battery This lets the ventilator not have to always be

plugged in and will let the user move around
with the ventilator.

Lightweight Carrying the device is doable with one person

without need of help.

Humidifier Prevents mouth and throat dryness due to the

ventilation. Keeps the use comfortable during
ventilation.

Portable Oxygen Supply This will let the ventilator and user be mobile
without worrying about not getting necessary
oxygen.

Simple UI A simple UI will allow the device to be

operated by both medical professionals and
non professionals. Prevents information
overflow and ease of use.
Table 4: Marketing Requirements and Reasoning

The Portable Ventilator will be designed to include features that will solve the current
problem with available ventilators. Similar to current ventilators, the Portable Ventilator will
provide breathing and oxygen intake assistance to low risk patients. The differentiator between
current ventilators and the Portable Ventilator will be the greater accessibility, mobility, and

16
comfort the Portable Ventilator will provide to patients. This will be done by designing the
ventilator to be light, run on a battery, and be easy to use.

Importance Design Feature

High Portable power capabilities to last at least 10 minutes

High Wi-Fi/LTE

High Bluetooth Communication

High Smartphone integration

High Small, lightweight design

Medium Affordable Cost

Medium Simple User Interface

Low Visually Pleasing

Table 5: Importance and Design Feature

The Portable Ventilator places higher importance on features that add to the functionality
of the device. If there is a choice between a higher cost or a lower functionality of a smartphone
integration, the ventilator will have to receive the higher cost in order to provide the extra service
to the customer. This is necessary to stand out versus other portable ventilators on the market.
Without many of these beneficial design features, this device would not be able to break through
the market.

17
Marketing Data Sheet

18
 Figure 11: Marketing Data Sheet

Block Diagram

Figure 12: 0th Level Block Diagram

The high(0th) level block diagram for the ventilator displays the necessary inputs and
outputs for the system. The inputs for the system are the patient’s biometrics, patient input, air,
and a charger. The patient’s biometrics must be accurately measured to provide feedback to the
ventilator so it can adjust to provide the needed enriched air. The patient input sets and changes
the settings for the ventilator and defines how the ventilator will be used(e.g. high flow rate). The
air input is used by the system to provide the air flow rate and is enriched with oxygen to create
the enriched air for the patient. The charger input is necessary to charge the ventilator’s battery
and allow the ventilator to be portable. The outputs for the system are the enriched air and the
measured biometrics. The enriched air is humid, pressurized, oxygen-enriched air that is supplied
to the patient. The enriched air’s conditions must be carefully and accurately met to provide the
patients needs. The measured biometrics must be clearly and readily available to the patient.

19
 Figure 13: 1st Level Block Diagram

The 1st level block diagram shows the subsystems and connections between them in the
working ventilator system. A notable thing about the block diagram is that the Lion Battery and
Voltage regulator will connect and provide the power to the various components. The feedback
for the system is provided through the combination of the sensors and the Raspberry Pi. The
pulse oximeter and watch both measure the patient’s biometrics with the pulse oximeter being
the back up.

Engineering Requirements

The engineering requirements for this project were determined using the marketing
requirements established earlier. These engineering requirements are all necessary to meet the
goals of the project.

20
 Engineering Requirement Implementation

Chargeable Power System A rechargeable Li-ion battery with voltage

regulators

Measure Patient’s Biometrics An Apple watch with biometric capabilities,

and back-up pulse oximeter

Measurements of air output conditions Sensors right before the air is breathed by
(oxygen, humidity, air flow) the patient

Automatic control of systems to meet A Raspberry Pi reading sensors and

wanted air conditions controlling pump, oxygen tank, and
humidifier

Controllable Oxygen Content Oxygen tank with variable valve controlled

by servo.

Controllable Air Humidity Ultrasonic Atomizer

Controllable Air Flow Air fan

Patient and Ventilator Communication An app that communicates the input from
phone, and displays information on the
phone

Table 6: Engineering Requirements

Testing and Verification

Chargeable Power System

The power system will need to be tested for functionality. This will be done by measuring
the voltage of the battery and the output voltage of the voltage regulator along with keeping the
voltages steady while powering the components. The second test will be on how long the battery
lasts from full charge. This will need to be performed under two conditions. The first will be
with the ventilator operating at the lowest performance setting and the second with the ventilator
operating at the highest performance setting. The test will be done by powering the ventilator and
measuring how long it operates before stopping.

Measure Patient’s Biometrics

21
 This will require two tests, a functional test and accuracy test. The functional portion will
be done by reading and displaying what the watch is measuring and checking that the output is
reasonable. The accuracy test will be done by once again measuring with the watch and also the
pulse oximeter. The measurements will be compared to one another to check if they match.

Measurements of Air Output Conditions

The enriched will be measured through the use of multiple sensors. As such, each of the
sensors will have to undergo both a functional test and accuracy test. The test specifics for each
will vary but will follow a general structure. This structure is first performing the functional test
by reading the output of a sensor and checking that the sensor is measuring and outputting the
measurement. Next the accuracy test will be performed. To do this the sensor will be used in
known conditions and the output of it will be checked to match the known quantity.

Automatic Control of System

This will be a functional test that will be performed on the microcontroller and the
complete system. The functional test on the Raspberry Pi can be done by providing data that
simulates the sensor outputs and then checking that the Raspberry Pi’s outputs to the pump,
humidifier, and variable valve are correct. The data will then be changed to simulate a change in
air conditions and the Raspberry Pi outputs are checked to change accordingly to restore the air
conditions. The functional test on the completed system will be similar to the Raspberry Pi’s test
with the data now being provided from the sensors and the outputs of the pump, humidifier, and
variable valve being measured.

Controllable Oxygen Content

This functional test will be done through use of the Raspberry Pi connected to the servo
for the variable valve. To test this the Raspberry Pi will be told the wanted oxygen content and
the variable valve will be observed to open and close as needed.

Controllable Air Humidity

This functional test will be done through use of the Raspberry Pi connected to the
humidifier. To test this the Raspberry Pi will be told the wanted humidity and the humidifier will
be measured to check the provided water vapour is correct.

Controllable Air Flow

This functional test will be done through use of the Raspberry Pi connected to the pump.
To test this the Raspberry Pi will be told what the air flow should be and the pump will be
measured to provide the correct air flow.

22
Patient and Ventilator Communication

This will require both a functional and usability test. The functional test will be a check
that the phone/app is correctly communicating to the Raspberry Pi and the phone/app is correctly
displaying information. The usability test is to ensure that the ventilator’s setting can be easily
set and managed. This test will be done by having people outside the project use the app to set
the ventilator’s setting according to what they are told they should be.

Team Project Roles

Power System and Hardware Integration - Jack Brewer

This role’s responsibility is to integrate the voltage regulator and power supply into the
overall system. They need to design a safe and reliable system that supplies power to various
parts of the ventilator. This role also helps test and integrate other hardware devices to the overall
ventilator system.

Controller System and Hardware Integration - Sanders Sanabria

This role’s responsibility is to integrate the Raspberry Pi microcontroller into the overall
system. They need to be familiar with the various facets of the microcontroller and understand
how to properly design a system that incorporates the microcontroller into the ventilator. This
role also helps test and integrate other hardware devices to the overall ventilator system.

Firmware and Hardware Integration - Brad Weeks

This role’s responsibility is to communicate with the CPE team and incorporate firmware
that controls the various devices of the ventilator system. They need to produce code that reads
from many sensors and controls various components of the system. This role also helps test and
integrate other hardware devices to the overall ventilator system.

23
Schedule

24
Figure 14: Gantt Chart through June 2021

25
Product Cost Estimation

Figure 15: Bill of Materials

The BOM shown in Figure 15 above yields a Product Cost Estimation of around $650 for
the Portable Ventilator. This project will require financing by Cal Poly’s Electrical Engineering
Department. However, in order to finance this product for a company, the team could go two

26
routes. The first route would be to obtain a business line of credit from a bank or lender. The
business line of credit would allow the team to draw from a credit line up to a maximum amount
and the team only needs to pay back the amount that was actually used. The second route would
be to turn to crowdfunding and raise money from individuals. These investors would receive
early access to the product and perhaps other special treatment. Both of these routes would be
viable for this project.

Analysis of Senior Report

Project Title: Oxygen+

Student’s Names: Jack Brewer, Sanders Sanabria, Brad Weeks

Advisor’s Name: Prof. Rich Murray

Summary of Functional Requirements:

Oxygen+ is a portable ventilator which aims to provide a solution to mild respiratory

symptoms by providing an avenue for outpatient care to offset cost and vacancy thresholds for
patients and hospitals in the United States, allowing patients to recover while they are in the
comfort of their own residences. The system will consist of a smartphone-compatible and
operable high-pressure oxygen system that allows the patient some opportunity for cord-free
mobility.

In addition to manual adjustment, the system will be able to actively monitor and adjust
oxygen flow rate and pressure based on the patient’s blood oxygen content (SPO2). The system
will also be able to alert the patient if the system is unable to return their SPO2 to a healthy level
and recommend professional healthcare intervention. The final product will be an application
that interfaces with a high-pressure oxygen rich and humidified system that will utilize existing
components where necessary (due to time constraints).

Primary Constraints:

The primary constraints of the system are as follows: constant monitoring of blood
oxygen level, constant supply of oxygenated air (21%-100%), adjustable flow rate of incoming
air (0-40 L/min), water, (31-37°C) and humidified air (up to 100% humidity), and lastly,
portability for at least 3 minutes.

27
Economic:

a. Human Capital: Oxygen+ presents job opportunities within engineering, sciences,

marketing, health, manufacturing, and sales sectors.
b. Financial Capital: Our target customers will be able to obtain this device through a doctor
and lease the device through insurance, which will cost less than using a ventilator in a
hospital, and can be sanitized and reused with a different customer.
c. Natural Capital: This product will contain many electrical and mechanical components
including various sensors, a Raspberry Pi 4B+, an oxygen tank, a Lithium Ion battery,
and a variable valve. Many of these parts are not recyclable and therefore
d. Cost and Timing: The target cost of the Oxygen+ ventilator is under $1000, this is
heavily dependent on components used in the final design, and will increase with the
number of sensors and features implemented on the device

If Manufactured on a Large-Scale Basis:

Estimated number of devices per year: 1200

Estimated manufacturing cost of each device: $650

Estimated lease cost for device (billed from insurance): $150/week

Estimated profit per year (50 % Usage, device only): $3,900,000

Manufacturability:

Much of the circuitry will be able to be pre-fabricated by a pcb vendor, sensors, servos,
and the power supply will have to be attached manually. Mechanically, the casing will have to be
manufactured, and the oxygen tank, along with the raspberry pi will have to be installed
manually as well. Each device will also have to be rigorously and individually tested to meet
FDA and FCC requirements to ensure their compliance and quality is up to standard.

Environmental Impact:

One of the important features of this product is its ability to be reused by multiple people
after being sent back from the customer for sanitization. When parts break, we should make sure
that they are replaced, but the broken parts may not be salvageable/repairable, this negatively
affects the carbon footprint of the device as these parts may not be recyclable. This device is also
powered by a lithium-ion battery, this will reduce the usage of single-use batteries but ultimately
still leaves a carbon-footprint.

28
Sustainability:

In order to keep these devices out of landfills, the decision to reuse and repair is more
beneficial both economically and sustainably. When making the decision to reuse available parts
or repair a broken segment instead of tossing it into a landfill, this both extends the lifetime of
the device and keeps more devices out of landfills. With a longer device lifetime the ‘bottom’ of
the Weibull (bathtub) distribution is extended, and because the current business model is a
lease-per-time arrangement, the longer a device is in use the more value it adds to the company,
the more people it can help, and the longer it stays out of a landfill.

Ethical:

This device deals with the collection and radio transmission of sensitive health data,
therefore the discussion of secure transfer of sensitive data arises. This transmission and storage
must be encrypted and securely transferred to a secure healthcare server, where the contents will
remain unseen except by the specific healthcare professional intended.

Health and Safety:

In terms of safety, our plan for testing is to utilize 50psi air from an air pump in place of
50psi oxygen from an oxygen tank wherever possible. In cases where using concentrated oxygen
is required, proper cleaning and ventilation of all equipment will be used. Any oxygen tank(s)
will be properly constrained to reduce the risk of leaking and/or explosion.

Also, development of the Alpha prototype has led to some minor adjustments of the
medical hardware system, namely that the heater has been removed for safety reasons. It may be
added on later, time permitting. Additionally, the pump between the mixing chamber and
humidifier may not be necessary (further analysis during Winter Quarter will be conducted).

Social and Political:

This project is one born out of the current state of the world with COVID-19 ravaging
communities and rendering hospitals non-vacant. With such a device in the market the duty to
make certain the affordability and access to such a device is paramount. The average cost to rent
a ventilator is approximately $350/week [20]. Our presented cost is $150/week and the margin is
still very positive as far as profit is concerned. This means there is an opportunity to provide
healthcare to communities which would otherwise not be able to support it, given the insurance
would permit the device’s prescription.

29
Preliminary Design Analysis

After the engineering specifications and black box diagrams were completed, the team
searched for components that would achieve the goals of the portable ventilator’s alpha
prototype. The alpha design’s hardware requirements were to have hardware control of at least
two functional elements and have at least one sensor reading a measurement. The team also
generated a 3D model of a potential enclosure for the Raspberry Pi microcontroller.

Further design will be completed in the Winter 2021 quarter. A full system integration
between watch, phone, controller, and hardware will be completed. All sensors and movers will
be implemented and improved within the entire system. The prototype will be further adapted to
allow the ability of the controller to send at least four sensor status readings to an iPhone and
display at least two of those conditions on an apple watch. The next prototype must also allow a
user to initiate at least two ventilator operations via apple watch. The system will generate a
“warning” to the user on the watch when a preset bio metric is outside of a safe range. Overall,
the design goal of Winter 2021 will be to allow robust breathing capabilities with control and
feedback from an apple watch or iPhone.

Alpha Prototype

The alpha design’s hardware requirements were to have hardware control of at least two
functional elements and have at least one sensor reading a measurement. To accomplish this, we
obtained two ultrasonic atomization disks, a humidity sensor, a mass air flow sensor, an oxygen
sensor, and a servo motor. The EE team performed initial testing of the humidifier, humidity
sensor, and mass air flow sensor. These results were passed along to the CPE team who
constructed the alpha prototype. The air-oxygen mixer alpha prototype and diagram constructed
by the CPE team is shown in Figure 16 below.

Figure 16: Air-Oxygen Mixer Alpha Prototype and Diagram

30
Mechanical Housing Design

This is the mechanical housing for a Raspberry Pi 4B+. It is a rectangular housing to

protect the Raspberry Pi microcontroller and allows for external connections to the ethernet,
USB, and USB-C (power). The board sits on 10mm spacers to allow space from the board to the
bottom of the housing as well as to provide air flow under the board. It has four screw holes to
allow screws to fasten the board mechanically to the housing.

Figure 17: Solidworks model of the mechanical housing

31
EE 461 Addendum

The main goal of the EE team over the Winter 2021 quarter was to provide support to the
CPE Capstone team. The EE team developed the hardware for the portable ventilator system,
which included an in-depth schematic of the system, an oxygen sensor circuit, and a power
supply. When issues or questions arose, it was the EE team’s responsibility to help the CPE team
solve them. The next few pages will describe the actions the EE team took over the quarter in
order to support the CPE team.

Schematic (Sanders)

With more components being added to the ventilator there was a need to create a
schematic of the complete system. This schematic would help keep track of the connections
between the components and allow an easy way to replicate the system later. The schematic was
done using EAGLE, this gives the option to use the schematic for PCB layout. The schematic
was an ongoing task, being improved and updated as changes were made to the system and asked
for by the client. The schematic is currently on its 4th draft.

Schematic of Portable Ventilator system

32
The schematic uses device numbers (top) and component name abbreviations (bottom) to
differentiate and identify the components, with an abbreviation to full component name list on
the bottom right. Standard symbols were used for common components, such as resistors, op
amps, etc. Unique symbols were created for the rest of the components. It should be noted that
there are three different positive power rails: Vbat, 5V and 3.3V. The 3.3V is provided by the
raspberry pi. It should also be noted that the pins in the schematic were placed with clarity in
mind and not the physical placement they will be found in. The schematic must be used in
conjunction with component datasheets to ensure correct connections.
The next steps for the schematic will be to continue updating as more changes are made
to the system and asked for by the client. The pins should also be rearranged to match their
physical placement if a PCB will be created.

Power Supply (Jack)

The portable ventilator operates from a 14.8 V battery pack. This battery pack can vary
from 9 V to 16.5 V depending on charge status. A power supply needed to be developed to
supply separate voltages that stay constant during variations in battery voltage. A [21]
D24V22F5 5 V, 2.5 A step-down voltage regulator was chosen to supply the power lines for the
system.

Initial power supply system design.

By using a high power diode configuration, the voltage regulator could theoretically
supply a 6.2 V and a 5 V power line. The 6.2 V line would be optimal for running the servo and
the 5 V line would power the microcontroller, sensors, and other electronics in the system. The
voltage regulator, a battery connector, and pin headers were soldered onto a protoboard in order

33
to give easy access to the power lines. However, the power supply did not operate correctly when
tested. It was determined that the voltage regulator possibly utilized feedback current through its
ground port and the diodes interfered with its operation. Due to this, the diode configuration was
scrapped and the power supply was used for only a single 5 V line. The servo was adapted to use
a 5 V supply instead of a 6.2 Vsupply, so no new designs had to be made to create a 6.2 V power
line. The finished product was handed off to the CPE team which used it in their system. There
were no issues with the operation of the power supply.

Ultrasonic Atomizer (Jack)

A WG3166A ultrasonic atomizer was used to humidify the ventilator system. The
humidifier board works well and has had no issues. However, it is a goal of the EE team to have
our own dedicated board layout by the end of this senior project. To do this, the current
humidifier board needs to be reverse engineered so that the team can integrate it into our overall
design. In addition, some components of the board may be unnecessary for our purposes so the
team could possibly simplify our system.

To start, a schematic must be made of the system so the team can understand its operation
and how to replicate it. All of the components on the humidifier need to be identified to do this.
Some components on the board don’t have markings to identify them, which makes it difficult to
figure out their purpose. However, through testing and analysis, all components on the
humidifier have been identified. A detailed schematic is currently being drawn up which will be
helpful in analysis and testing of our own design. As of now, the system has been divided into
two sections. There is a power supply section, which converts the 5 V supply voltage into a ~20
V drive voltage. This is done through a MC34063A [22] boost switching regulator with an
accompanying system. The next section is the transducer driver portion. This section uses a
78L05 5V regulator [23] (which we won’t need in our design), a NE555 timer [24] for a 113kHz
oscillation, and a FQD2N60C N-channel power mosfet [25] in order to resonate the transducer
which atomizes water and creates the humidity. This work is being continued into the next
quarter and its goals will be defined in the Spring 2021 Goals section of the addendum.

Humidity Sensor (Brad)

Initially, there was the task of identifying and selecting sensors which measured within
the specified range and were cost-effective. I happened to own a DHT11 [26]
Pressure/Temperature chip, which was not I2C but already had code written for it. Unfortunately,
the DHT11 was not reliably giving consistent results when read. So the next step was to acquire
and write code for a different sensor, this time with I2C compatibility and much more reliable.
The HTU21D [27] fit all of the same measuring specifications as the original. When the chip was
hooked up to the I2C bus however, it shared the same address with the flow rate sensor (0x40).

34
Lastly, an even better chip was found which has a different I2C address and also included a
humidity sensor, the BME280 [28]. This chip has been working reliably within the system,
although the humidity collection capabilities are not being utilized.

O2 Interface Design (Brad)

Next, there was the task of creating an interface between the Oxygen Sensor and the
ADC. It involves the use of a simple 10x gain non-inverting op-amp from the sensor output to
the input of the ADC. The original goal was to prototype the 10-bit, I2C-compatible MCP3021
[29] on a breadboard. Upon the delivery of the ADC, the part was much too small to be
breadboarded or even soldered. Therefore a set of SMT to DIP adapters were ordered and used to
breadboard and prototype the final design onto. It does not appear that any I2C-compatible chips
are manufactured in any form but SMT. Additionally, a handful of 12-bit, I2C-compatible
MCP3221 [30] were soldered on some of the SMT to DIP adapters if higher resolution was
necessary. The original op-amp used in the design was the LM741 [31], but this does not
currently come in an SMT package. As a goal for the next quarter, the entire schematic (currently
curated by Sanders) will be laid out onto one PCB. This means most all parts will have to be
SMT. Fortunately, the LMC662 CMOS Dual Dual Op-amp [32] comes in an SMT package, with
some better specifications than the LM741. Below is the two schematic drawings, the top is the
SMT to DIP translations from the MCP3021/3221:

35
 Top: MCP3021 Mounted on SMT to DIP Chipset with Pin Translation
Bottom: Full O2 Interface - O2 Sensor->LMC662 ->MCP3021->I2CBUS/PI

The feedback and gain resistors’ value in the actual circuits are both lower than the actual
schematic, this is to try and keep the gain as close to possible at 10. Both 4.7k resistors on the
SDA and SCL lines are purely representative of the voltage that the resistors should be pulling
up to. They have been taken out in the final iteration because the ventilator bus already has
pull-up resistors.
When it came to the code, I ended up helping Jared write a lot of the ADC translation
functionality, always there to answer questions about LSB and how Vref affects the final
calculation. The biggest part was understanding that the oxygen sensor signal output was
9-14mV with an approximate gain of 10 from the op-amp leading into the analog in port of the
ADC. This means the values will range from 0.09V to 0.14V for the 10-bit ADC. It was then a
simple matter of linearly mapping the range of ADC outputs to a calculation of oxygen
percentages.

36
Air Flow Rate Sensor (Sanders)

Along with the schematic, I worked with the CPE team, in particular with Jared, to
troubleshoot and fix issues with the components. The first major issue was with the Air Flow
Rate Sensor. The CPE team was having trouble reading the I2C data. Once I received the sensor
I performed tests to identify the problem. Initial tests were done using an Aruduino and then a
MSP432 since the Raspberry Pi in my possession stopped working. Initial tests found that the
pull up resistors in the sensor did not interact correctly with the pull up resistors in an MCU and
prevented the SDA and SCL lines from being pulled to ground. This issue was found to be fixed
by using the level shifter.
After fixing this issue, further tests were performed and the I2C data was still a problem.
This second round of testing showed that writing to the sensor was able to be done correctly and
multiple times. This was not the case when reading data from the sensor. The first time data is
read from the sensor there is no problem and the data being read is correct. This was tested by
blowing air through the sensor and checking by hand that the data was different than when no air
would flow through and corresponds to the correct direction. However, when trying to read data
the second time the sensor would break I2C communication.

Yellow: SDA Blue: SCL

37
During the transmission of the second read, the sensor would take control of the SCL and hold
the line to ground. The reason that the sensor is thought to be responsible for this is that the SCL
is not pulled completely to ground. During testing whenever the sensor had control of either
SDA or SCL it would always pull the lines close, but not exactly, to ground. The MCU on the
other hand would be able to pull the lines exactly to ground. Further tests were done to try to find
the root cause, however, these were all unsuccessful. The tests showed that changing the type of
data being transmitted or telling the sensor to reset would not stop the SCL being taken over by
the sensor during the transmission of the second read.
Due to the nature of the ventilator a working flow rate sensor was needed by the CPE to
continue integration and testing. This time constraint meant that it was more important to find
some type of solution than it was to find the cause of the problem. Therefore, the focus changed
to finding a workaround to the problem. It was found that forcing the sensor to not send the third
byte would prevent the sensor from taking control of the SCL line. This was done in the
code[33]. The pros of this are that the first two bytes contain all the measurement data, but the
main con is that the third byte contains the error checking data (CRC8). This means that other
precautions must be taken to minimize possible errors in the data. One such precaution was to
add a capacitor between the ground and VDD pins to minimize crosstalk and errors.

Humidity/Temperature/Pressure Sensor (Sanders)

The second major component issue was conflicting addresses with the air flow rate
sensor and the humidity/temperature sensor. The temporary solution used was to use the
raspberry pi’s second set of I2C lines, pins 27 and 28. This was done by modifying the flow rate
sensor code. This was a temporary solution because documentation and other information on the
raspberry pi warned against using those pins as they could be unreliable. The permanent solution
was decided to then be finding a new humidity sensor with a unique address. The new sensor,
BME280 [28], was found by Brad and chosen due to it being a better sensor than the previous
with additional capabilities, such as measuring pressure and oversampling.
The next step was to get the sensor to work correctly. Along with the sensor being a
better performing and higher quality sensor, it was also a more complex and difficult to
understand component. After many iterations of code[34], the sensor was working correctly but
could not verify how accurate it is due to lack of equipment. This was left to the CPE team to test
and confirm. The most important and difficult part for correct and accurate measurements was
the compensation of the data.

38
I2C Addresses
To prevent future issues with I2C addresses a table was made that contains all current I2C
devices and their address.
Device Address

Flow Rate Sensor 0x40

Humidity/Temp/Pres Sensor 0x76

ADC 0x4D

Pressure Sensor 0x28

Component Specifications
This component specifications table contains information about both the operating
conditions and maximum/minimum conditions for the components used.
Parameter Minimum Typical Maximum Units

Battery

Output Voltage 12 14.7 16 V

Voltage Regulator

Input Voltage 5.3 - 36 V

Output Voltage - 5 - V

Continuous Output 1.4 - 2.6 A

Current

Quiescent Input - 1 - mA
Current

Quiescent Input 5 - 10 µA/V

Current

(low-power)

Raspberry Pi 4B

Supply Voltage - 5 6 V

Supply Current 3 - - A

GPIO Voltage 0 - 3.3 V

39
 GPIO Output 0 - 16 mA
Current

Pull-Up Resistors - 1.8 - kΩ

Humidifier

Supply Voltage 3.7 - 12.7 V

Rated Power - 2.5 - W

Humidity/Temp Sensor

Supply Voltage 1.71 - 3.6 V

Startup Time - 2 - ms

I2C Voltage -.03 - 3.6 V

Pressure Sensor

Supply Voltage 3 3.3 3.6 V

Supply Current - 2.1 2.8 mA

Startup Time - - 5 Ms

I2C Voltage -0.3 - 3.6 V

Air Pump

Rated Voltage 6 - 12 V

Rated Current - 1 - A

Rated Power - 10 - W

Air Flow - 16 - CFM

Oxygen Sensor

Output Voltage 9 - 14 mV

40
 Flow Rate 0.1 - 10 Lpm

Flow Rate Sensor

Supply Voltage 4.75 5 5.25 V

Supply Current 7.5 10 mA

I2C Voltage 0 - 5 V

Sampling time - 10 - Ms

Flow Rate Range -200 - 200 slm

Servo

Supply Voltage 4.8 - 7.4 V

PWM Range 500 - 2500 µs

Level Shifter

High Voltage - - 10 V

Low Voltage 1.8 - - V

Pull-Up Resistors - 10 - kΩ

ADC

Supply Voltage 2.7 - 5.5 V

Supply Current - - 370 µA

Input Voltage -0.6 - Vsupply + 0.6 V

I2C Voltage -0.6 - Vsupply + 1 V

Conversion Time - 8.96 - µs

41
 LMC66 (Op Amp)

Supply Voltage 4.75 - 15.5 V

Supply Current - - 35 mA

Input/Output -0.3 - Vsupply + 0.3 V

Voltage

Output Current -18 - 18 mA

Spring 2021 Goals

Brad

Next quarter I am planning on aiding Sanders with the PCB layout of the entire
schematic, this does not imply sending schematic files back and forth. Instead, it will be worked
on collaboratively so that the best decisions about layout may be made. Also, I’d like to work
more with Jared in improving any of the firmware where needed and look into any feedback
systems which need analysis. I would also like to apply any signal processing techniques which
may improve the readouts, as well as analyze closed loops in the feedback system and apply
control theory to check for stability or reduce sensitivity. I wager the firmware improvement will
be an ongoing-yet minimal time commitment every week through meetings. Given the PCB
turnaround time is shy of 3 weeks, The PCB layout needs to be completed before week 5. This
dictates each week a certain subsection of the total schematic must be completed. Any closed
loops will have to be analyzed using more modern-control theory, where the feedback is replaced
with a MCU. Some additional reading will have to be done on the translation between the two.
Lastly, any additional circuitry or problems either project lead Vanessa or continuation-member
Jared need my assistance with is also my obligation.

Jack

I am currently working on the Ultrasonic Atomizer reverse engineering project. Next

quarter, it is my goal to come up with a complete schematic for the system. I will then develop
and test my own design. Then after the system works on my own design, we can integrate my
design into the team’s overall board layout. I estimate that this project will take a few weeks to
accomplish because I need to completely figure out the system, order specific components, and
then build and test my own circuit. I also plan to help out the rest of the Portable Ventilator team
when needed. From the Capstone team, Jared and Vanessa will be continuing the portable
ventilator senior project. We will be in contact with them to determine how we can add more

42
functionality and improve the overall performance of the system. By the end of the quarter, we
hope to have a fully independent portable ventilator which operates off our single PCB design.

Sanders

Next quarter, I will continue with the responsibilities of this previous quarter. This will be
to update the schematic as needed and provide support in troubleshooting and fixing component
issues. Along with this, I will work in collaboration with Brad to create a PCB layout before
week 5. This will mean that any updates to the schematic must also be complete before week 5. I
would also like to develop and work on safety protocols for the components. This would be for
issues such as component malfunctions, error checking, and other possible dangers. To achieve
some of this, further research will need to be done into patients’ vital needs, such as max length
of time without proper air flow, max and min air pressure, and etc. Therefore, I will need to
continue working with Jared and, in particular, Vanessa from the capstone team.

EE 462 Addendum

PCB (Sanders)
Initially a breadboard and wires were being used to hold and connect the components of
the ventilator. While this was acceptable for the initial testing and prototypes, the final design
would use a pcb for the electrical components of the system. The pcb would provide more
reliable and secure connections between components, and a minimized area.
The first design pass of the pcb included the raspberry pi, voltage regulator, power sensor,
oxygen sensor amplifier, a/d soic board, level shifter, air pump/fan system, and the humidifier
system. Along with these components, there were connectors for the components that would be
off-board. To be able to use Eagle for the layout, a new schematic had to be made that only
included the on-board components.

43
 Layout Schematic 1st Pass

To be able to create the pcb layout, footprints were created for every component that
would be on-board. This required using the dimensions in the datasheets to create the footprints.
However, some components had no datasheet or did not have the dimensions in the datasheet.
This meant that those components had to be measured by the CPE team and they then would
relay that information to me. The design of the footprints took the longest time. After designing
the footprints a layout and route were done and then sent to the advisor for comments. After
some changes the layout was done and sent for manufacturing.

44
Layout 1st Pass Top(red) and Bottom(blue) Layer

45
Layout 1st Pass 2nd Layer

46
 Layout 1st Pass 3rd Layer
The size of the first iteration was about 62mm x 82mm. It is a 4 layer pcb with the 2nd
layer being used for 5V and 3.3V planes. The 3rd layer is used for ground. The top and bottom

47
layer are used for traces. Due to time constraints the capacitors, inductors, humidifier diode,
humidifier connector, a/d, and op-amps were not labeled correctly. The battery traces are wider
than the rest of the traces because those traces would have higher current going through them.
The mosfet A2 pinout was incorrect, it should be GDS not DGS. This was solved by adjusting
the mosfet leads used.
After the pcbs were manufactured and picked up, the board was assembled and tested. A
second pinout issue was noticed. In the schematic and layout the clock signal for the humidifier
was placed at pin 16, however it is pin 7 that is actually used to provide the clock signal. This
was a simple fix with a wire connecting pin 7 to pin 16 fixing the issue. Another issue noticed
was about clarity. There was confusion on how things were oriented, in particular U2, U$1 and
the unlabeled a/d.
For the second pass all of these issues were fixed. Along with this many components
were changed and a new schematic and layout were created.

Layout Schematic 2nd Pass

The largest changes for the 2nd pass were the replacement of the power sensing board
with the smd chip and the replacement of the a/d soic board with the a/d directly placed on the
pcb. Similar to the first pass the layout was submitted to the advisor and then adjusted as asked.

48
Layout 2nd Pass Top(red) and Bottom(blue) Layer

49
Layout 2nd Pass 2nd Layer

50
 Layout 2nd Pass 3rd Layer
The size of the second iteration is 59mm x 54mm. The smaller size was achieved by
replacing thru-hole components with smd components. The full list of changes made to the board
are as followed:
● The resistors, diode, a/d, power mosfet and power sensor are now smd.
● Removed 2n2222 transistor.
● All components are now labeled.
● The battery connector is now direct.
● The pins are fixed on the components that had an error.
● Large capacitor and inductors are now properly marked and spaced.
● Resistors, capacitors, inductors, diodes, and transistors are oriented the same, i.e. their
labels are oriented in the same direction.
● ICs, connectors, and boards are oriented the same.

51
 ● All component labels are now placed so that pin 1 is always the closest pin to the label.
(Pin 1 should be the same in the schematic and the component's datasheet).
● Battery and humidifier connectors have extra labels to help distinguish positive V (+) and
GND (-).

INA260 Voltage Sensing Circuit (Jack)

The portable ventilator will require a basic battery management system. The initial step to
accomplish a BMS is to integrate a power sensor. The power sensor will read the voltage and
current from the battery and relay the information to the raspberry pi microcontroller. With this
information, the microcontroller could potentially enter a low power mode and display “low
battery” warnings to the user.
An INA260 Power Sensor Adafruit Board was chosen to provide battery sensing for the
ventilator. The INA260 chip can support the ventilator’s battery voltage with currents up to 15A.
This board was integrated into the initial PCB design by Sanders. Next, an INA260 circuit
needed to be designed in order to remove the adafruit board from the PCB, as a goal of the
portable ventilator is to have a self sufficient PCB without the need of external boards. The
schematic below shows the simple circuit that was designed to produce correct operation of the
INA260 chip.

INA260 Power Sensor Schematic

52
 This circuit has been integrated into the second iteration of the PCB design. It will be
used to obtain voltage and current measurements from the battery. The INA260 circuit will be
the stepping stone for a more complex battery management system in the future for the portable
ventilator.

Ultrasonic Atomizer Design and Testing (Jack)

A large goal of the EE team was to have our own dedicated board layout by the end of the
senior project. To do this, we would need to not use premade boards and make our own designs
when possible.A WG3166A ultrasonic atomizer was reverse engineered to humidify the
ventilator system. In the process of reverse engineering, it was determined that many
components on the WG3166A board were unnecessary for our application. The final schematic
for the ultrasonic atomizer system is shown in two parts below.

Power Driver Circuit

The power driver circuit above utilizes a boost converter to produce a 26V drive signal
for the ultrasonic transducer drive shown below. This power driver features an “EN_active_low”
node that can be used to effectively turn off the buck converter circuit when not in use which will
reduce passive current draw. This feature would be used during a “low power” mode in which
the portable ventilator is low on battery life.

53
 Ultrasonic Transducer Driver Circuit

The ultrasonic transducer driver circuit above uses a power MOSFET to switch an
ultrasonic transducer at high voltages. The microcontroller provides the circuit with a 113kHz
square wave, which will resonate the ultrasonic transducer. This resonation along with the high
voltage supplied from the power driver circuit will cause water to atomize rapidly at the surface
of the ultrasonic transducer. This will be used to provide the humidity for the portable ventilator
system.

The first PCB iteration was populated with the various systems of the ventilator. After
initial testing from the CPE team, it was found that the ultrasonic atomizer system was not
operational. The board was then sent back to the EE team. Through testing, it was found that an
incorrect resistor had been soldered into the system, which saturated the power MOSFET and
restricted the transducer from resonating. It was then determined that some of the pinout
locations between the raspberry pi microcontroller and the PCB did not match up. The incorrect
pinout connections were corrected manually and the humidifier system became fully operational.
The second PCB iteration has changed the incorrect pinout locations which will fix these issues
in the future.

Fan Driver Circuit Improvement (Jack)

The advisor proposed an improvement to the fan driver circuit. This improvement would
eliminate the need for a switching BJT and one resistor. He proposed that the fan driver’s power
MOSFET could be driven directly from the microcontroller’s GPIO pin. This would reduce the
complexity of the circuit and the number of components on the PCB without degrading
performance or power consumption.

54
 →
Old design on the left. Improved design on the right.
The new design was constructed and tested using various resistive loads and a muffin fan.
The design was proven to work in scenarios requiring current up to 500 mA, which showed the
effectiveness of the circuit to reliably drive the fan for the portable ventilator. With this new
implementation tested, Sanders integrated the circuit improvement into the second iteration of
the PCB.

O2 Sensing Circuit Improvements (Brad)

Two issues arose with the original O2 sensing circuit. The first of which was the lack of
range the initial operational amplifier configuration yielded. The 10k feedback resistor with the
1k shunt resistor gives a 10x amplification for an amplified O2 range of 90-140 mV.
Unfortunately for the 10-bit ADC, this range is not ideal for precise oxygen percentage
measurements. Therefore, to offer more range for the ADC to sample is to increase the feedback
resistance to the LMC66, preferably above the hundred-thousand but below the mega ohm range.
A 100k feedback resistor augments the range to 0.9-1.4V, a 500 percent output range increase.
The second problem was the limited resolution of the ADC. While the original 10-bit MCP3021
was competent at detecting the required ranges, it still offered a limited range given the original
input signal range and the reference voltage. In order to increase this range, there is a 12-bit
ADC which operates similarly to MCP3021, the MCP3221. In the PCB, the area where this ADC
is mounted is occupied by an 8-pin DIP so that either the 10-bit or 12-bit may be placed
modularly, as the SMT ADCs sit on a smaller board which makes SMT devices mount onto a
DIP set.

55
MCP3021 Range (10-Bit)

MCP3221 Range (12-Bit)

56
 Bill of Materials & Assembly (Brad)

All the non-SMT components are all sourced from the same distributor, making the
turnaround for ordering parts approximately 2 weeks. The SMT components as well as the
hybrid SMT/DIP materials are sourced from a variety of distributors. It was unfortunate that
many components do not come in a SMT package, as it would have dramatically reduced the
amount of space used on the board. The through-hole resistors from the first iteration of the PCB
fit oddly and took up approximately a quarter of the board space. Additionally the height as well
as the radius of the capacitors (specifically C1, 2, and 3) were the cause of spacing issues.
Instead of having all of the capacitors on one side of the board, the proximity and size of the
capacitors meant soldering one of the capacitors on the underside of the PCB, meaning the fitting
of the PCB on top of the PI was not as snug due to the protruding underside capacitor.

Resistors Ohms Caps F Induct H ICs Transistors Diodes Header

R1 10k C1 100n L1 330u IC1 LMC66 Q1 2N2222A D1 JP1 2x1
R2 1k C2 100n L2 180u IC2 MCP3021 Q2 T0-220AB D2 JP2 2x1
R3 2.2k C3 220u Q3 T0-220AB JP3 3x1
R4 1k C4 100n JP4 3x1
R5 1k C5 1n JP5 4x1
R6 330 JP6 4x1
R7 100k JP7 2x1
R8 1
R9 15k
R10 2.7k
R11 1k
R12 180
R13 1
R14 180

57
References
[1] https://www.nhlbi.nih.gov/health-topics/ventilatorventilator-support
Explains the need for and operation of ventilators.
[2] History of Mechanical Ventilation. From Vesalius to Ventilator-induced Lung Injury.
American Journal of Respiratory and Critical Care Medicine 2015: Volume 191, Issue 10
Explains the function of negative pressure ventilation in the past.
[3] Penlite, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0>, via Wikimedia
Commons
Source for Figure 1
[4] The Mechanical Ventilator: Past, Present, and Future. Robert M Kacmarek. Respiratory Care
August 2011, 56 (8) 1170-1180
Provides the history of ventilators.
[5]
https://lh3.googleusercontent.com/proxy/gt3Vdia8HJczQA-5640ZWbEATwoSsDgvsCMF2j11vp
WUIFfm9BgzqbClinmO8IWrZzdgizJh8EWOpdqhzzIelfp4JH-HPfOIBF4g3zr62byOcDQfS2y6S
9jvVQoRtsIf39boFAfNUARAGMQWpPozBGIguoBbF4ge6I9CKN5mhVA5yx7qHd7dpMlj0-M
NqhEdyDQVoZCNIRQ0v3dNSU_pSylj7Q
Source for Figure 2
[6] Ronald Bonss/Picture Alliance
Source for Figure 3
[7] https://www.fda.gov/media/136437/download
Provide FDA regulatory process.
[8] https://www.raspberrypi.org/products/raspberry-pi-4-model-b/specifications/
Raspberry Pi 4 Model B specifications and image
[9] https://craighospital.org/resources/mechanical-ventilation
Definition of mechanical ventilation and when/why it’s needed
[10] Ventilator Market by Mobility (Intensive Care, Portable), Type (Adult, Infant), Mode
(Volume, Pressure, Combined), Interface (Invasive, Non-invasive), End User (Hospital, Home
Care, Ambulatory Care Center, EMS) - Global Forecast to 2023.
https://www.marketsandmarkets.com/Market-Reports/ventilators-market-11018337.html

58
 Market report on ventilators delineated by their portability
[11] Allied Healthcare Products, Inc., www.alliedhpi.com/zepv200.htm
Assortment of medical devices manufactured and sold by Allied Healthcare Products
[12] “Invacare Perfecto2 V Oxygen Concentrator 5-Liter w/O2 Sensor IRC5PO2V - Perfecto 2V
Oxygen Concentrator 5 Liter w/ O2 Sensor - Model V Lightweight - 39 Pounds, 3 Year Warranty
Each.” Vitality Medical,
www.vitalitymedical.com/invacare-perfecto2-v-oxygen-concentrator-5-liter.html?network=g
Market-available portable ventilator example along with specifications
[13] ReportLinker. “Portable Medical Ventilators Market Research Report by Mode, by Age, by
Interface, by End User, by Distribution - Global Forecast to 2025 - Cumulative Impact of
COVID-19.” GlobeNewswire News Room, "GlobeNewswire", 29 July 2020,
www.globenewswire.com/news-release/2020/07/29/2069597/0/en/Portable-Medical-Ventilators-
Market-Research-Report-by-Mode-by-Age-by-Interface-by-End-User-by-Distribution-Global-Fo
recast-to-2025-Cumulative-Impact-of-COVID-19.html
Report on the portable medical ventilator market and its projected growth, includes
demographic and distributor information
[14] Thecpapshop.com,
www.thecpapshop.com/respironics-simplygo-portable-oxygen-concentrator?utm_source=google
CPAP marketplace, includes pricing and quantity
[15] Mechanical Ventilator Market by Components (Devices and Services) Product Type,
(Intensive Care Unit/Critical Care, Transport/Portable/Ambulatory, and Neonatal Care
Ventilator), Mode (Non-invasive Ventilation and Invasive Ventilation), Age Group (Pediatric &
Neonatal, Adult, and Geriatric), and End User (Hospital and Clinic, Home Care, Ambulatory
Surgical Center, and Others): Global Opportunity Analysis and Industry Forecast, 2020-2027.
https://www.alliedmarketresearch.com/mechanical-ventilators-market
Statistics relating to the current mechanical ventilator market and its projected growth
within the next decade
[17] Science Direct. “Healing Environment: A Review of the Impact of Physical Environmental
Factors on Users” Huisman, E.R.C.M.; Morales E.; Hoof, J. van; Kort, H.S.M. 2012.
https://www.sciencedirect.com/science/article/pii/S0360132312001758
Study on the efficacy of healing at home over healing in a hospital

59
[18] “FDA Clears First Portable Unified Respiratory System For Patients On A Ventilator.”
Medical Product Outsourcing,
www.mpo-mag.com/contents/view_breaking-news/2017-04-12/fda-clears-first-portable-unified-r
espiratory-system-for-patients-on-a-ventilator/
Report on the first portable ventilator approved by the FDA
[19] FCC. “Electronic Code of Federal Regulations (ECFR).”, 2 Dec. 2020,
www.ecfr.gov/cgi-bin/text-idx?SID=a73c5079fe7bd2fb55ce406fa95b3107.
FCC regulatory guidelines for emi radiation to 3 meters when operating within ISM band
[20] KWIPPED, Inc. “Ventilators: Rent, Finance Or Buy On KWIPPED.” KWIPPED.com,
www.kwipped.com/rentals/medical/ventilators/237.
Data on the cost to rent/purchase a ventilator
[21] “Pololu 5V, 2.5A Step-Down Voltage Regulator D24V22F5,” Pololu Robotics &
Electronics. [Online]. Available: https://www.pololu.com/product/2858/specs. [Accessed:
10-Jun-2021].
[22] Texas Instruments, “MC3x063A 1.5-A Peak Boost/Buck/Inverting Switching Regulators,”
SLLS636N datasheet, Dec. 2004 [Revised Jan. 2015].
https://www.ti.com/lit/ds/symlink/mc34063a.pdf?ts=1615321792497&ref_url=https%253A%252F
%252Fwww.google.com%252F
[23] Texas Instruments, “uA78Mxx Positive-Voltage Regulators,” SLVS059T datasheet, Jun.
1976 [Revised Jan. 2015].
https://www.ti.com/lit/ds/symlink/ua78m.pdf?HQS=dis-mous-null-mousermode-dsf-pf-null-wwe&t
s=1615401688926&ref_url=https%253A%252F%252Fwww.mouser.com%252F
[24] Texas Instruments, “NE555 Precision Timers,” SLFS022F datasheet, Sep. 1973 [Revised
Jun. 2006]. https://datasheet.octopart.com/NE555P-Texas-Instruments-datasheet-7284017.pdf’
[25] ON Semiconductor, “FQD2N60C / FQU2N60C N-Channel QFET MOSFET,”
FQU2N60C/D datasheet, Oct. 2017. https://www.onsemi.com/pdf/datasheet/fqu2n60c-d.pdf
[26] Mouser Electronics, “DHT11 Humidity & Temperature Sensor,” 1143054 Technical
datasheet,
https://www.mouser.com/datasheet/2/758/DHT11-Technical-Data-Sheet-Translated-Version-114
3054.pdf

60
[27] Measurement Specialties, “HTU21D(F) Sensor, Digital Relative Humidity Sensor with
Temperature Output,” HPC199_3 datasheet, Oct. 2013.
https://cdn-shop.adafruit.com/datasheets/1899_HTU21D.pdf
[28] Bosch, “BME280 Combined Humidity and Pressure Sensor,” BST-BME280-DS001-18
datasheet, Nov. 2020.
https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme280-ds00
2.pdf
[29] Microchip, “MCP3021 Low-Power 10-Bit A/D Converter with I2C Interface,”
DS20001805C datasheet, Nov. 2016.
https://ww1.microchip.com/downloads/en/DeviceDoc/20001805C.pdf
[30] Microchip, “MCP3021 Low-Power 10-Bit A/D Converter with I2C Interface,”
DS20001732E datasheet, Nov. 2016
https://ww1.microchip.com/downloads/en/DeviceDoc/20001732E.pdf
[31] Texas Instruments, “MC3x063A 1.5-A Peak Boost/Buck/Inverting Switching Regulators,”
SLLS636N datasheet, Dec. 2004 [Revised Jan. 2015].
https://www.ti.com/lit/ds/symlink/lm741.pdf?ts=1616160086133&ref_url=https%253A%252F%
252Fwww.ti.com%252Fproduct%252FLM741%253Futm_source%253Dgoogle%2526utm_medi
um%253Dcpc%2526utm_campaign%253Dasc-null-null-GPN_EN-cpc-pf-google-wwe%2526ut
m_content%253DLM741%2526ds_k%253DLM741%2526DCM%253Dyes%2526gclid%253D
Cj0KCQjwl9GCBhDvARIsAFunhsnP-nvd61eQsf1WLKCxsTpyQUnwx8ffFIo6zPTYqu7RXwO
omrRTA1kaArH_EALw_wcB%2526gclsrc%253Daw.ds
[32] Texas Instruments, “LM741 Operational Amplifier,” SNOSC25D datasheet, May 1998
[Revised Oct. 2015].
https://www.ti.com/lit/ds/symlink/lmc662.pdf?ts=1616182416689&ref_url=https%253A%252F
%252Fwww.google.com.mx%252F
[33] Air Flow Rate Sensor Code
/* Flow Rate Sensor Code
Make sure i2c is turned on in raspi-config.
Also pigpio daemon should be off.
Uses sda1 and scl1.
stdio.h is only included for printf() and can

61
 be removed if not using printf().
*/
#include <stdint.h>
#include <stdio.h>
#include <pigpio.h>
#define FRSensor_ADDRESS 0x40

int main(void)
{
uint16_t value, flow=0;
uint8_t direction;
int handle;
unsigned char data[2];
unsigned char command[2];

if (gpioInitialise()<0) return 1; //Initialize pigpio and check for error

handle = i2cOpen(1, FRSensor_ADDRESS, 0); //Get handle(id) for sensor

command[0] = 0x10; //Set flow collection command,0x1000

command[1] = 0x00;

while(1)
{
i2cWriteDevice(handle, &command, 2); //Tell sensor to prepare data
i2cReadDevice(handle, &data, 2); //Read bytes into value array

//Get flow rate

value = (data[0] << 8) | (data[1] && 0xFF);

if(value > 0x7D00) //check direction of flow

62
 {
flow = ((value - 32000)/140);
direction = 1; //Forward direction
}
else if(value < 0x7D00)
{
flow = ((32000-value)/140);
direction = 0; //Reverse direction
}
else
{
flow = 0;
direction =1;
}

printf("%d and %d \n", flow, direction);

for(int i=2850; i>0; i--); //Delay before next read
}

i2cClose(handle);
gpioTerminate();
}

[34] BME280 Sensor Code

/* Temp/Humid/Pressure Sensor Code
Make sure i2c is turned on in raspi-config.
Also pigpio daemon should be off.
Uses sda1 and scl1.
stdio.h is only included for printf() and can
be removed if not using printf().

63
 Setting:
-Normal Mode (Continuous Measurements)
-Oversampling = 1 (All)
-No IIR Filter
-Standby time = 0.5ms

Max measure time = 9.3ms

Standby time = 0.5ms
Reading Rate = 1000/(9.3 + 0.5)= 102Hz

Chose rate of 50Hz

*/
#include <stdint.h>
#include <stdio.h>
#include <pigpio.h>

#define Sensor_ADDR 0x76

#define DATA_ADDR 0xF7
#define COMP1_ADDR 0x88
#define COMP2_ADDR 0xE1

int32_t Temp_Compens(int32_t adc_T);

uint32_t Pres_Compens(int32_t adc_P);
uint32_t Humi_Compens(int32_t adc_H);
void org_compens(unsigned char comp1[25], unsigned char comp2[7]);

int32_t t_fine;
unsigned char dig_H1, dig_H3;
uint16_t dig_T1, dig_P1;
int16_t dig_T2, dig_T3, dig_P2, dig_P3, dig_P4, dig_P5,

64
dig_P6, dig_P7, dig_P8, dig_P9, dig_H2, dig_H4=0, dig_H5=0;
signed char dig_H6;

int main(void)
{
int32_t un_temp, un_pres, un_humi, temp;
uint32_t pres, humi;
int32_t handle;
unsigned char data[8], compens1[25], compens2[7], reg_addr, set[2];

if (gpioInitialise()<0) return 1; //Initialize pigpio and check for error

handle = i2cOpen(1, Sensor_ADDR, 0); //Get handle(id) for sensor

for(uint32_t i=3000000; i>0; i--); //start up delay (2ms)

//Set Sensor Settings

set[0] = 0xF5; //standby time register
set[1] = 0; //standby time = 0.5ms, filter off, spi disabled
i2cWriteDevice(handle, &set, 2);

set[0] = 0xF2; //humidity sampling register

set[1] = 1; //oversampling = 1
i2cWriteDevice(handle, &set, 2);

set[0] = 0xF4; //Temp and Pres sampling, and mode register

set[1] = 0b00100111; //oversampling = 1, normal mode
i2cWriteDevice(handle, &set, 2);

//Get compensation parameters

reg_addr = COMP1_ADDR;

65
i2cWriteDevice(handle, &reg_addr, 1); //Prepare comp first part
i2cReadDevice(handle, &compens1, 25); //Read bytes into compens1 array
reg_addr = COMP2_ADDR;
i2cWriteDevice(handle, &reg_addr, 1); //Prepare comp second part
i2cReadDevice(handle, &compens2, 7); //Read bytes into compens2 array
org_compens(compens1, compens2); //Organize compensation parameters

while(1)
{
//Get uncompensated measurements
reg_addr = DATA_ADDR;
i2cWriteDevice(handle, &reg_addr, 1); //Prepare correct register
i2cReadDevice(handle, &data, 8); //Read bytes into data array

//Organize received data

un_pres = (data[0] << 12) | (data[1] << 4) | ((data[2] && 0xF0) >> 4);
un_temp = (data[3] << 12) | (data[4] << 4) | ((data[5] && 0xFF) >> 4);
un_humi = (data[6] << 8) | (data[7] && 0xFF);

//Get compensated measurements

temp = Temp_Compens(un_temp); //in DegC*100
pres = Pres_Compens(un_pres)/256; //in Pa
humi = Humi_Compens(un_humi)/1024; //in %RH

//Print out measurements

printf("T= %d and P= %d and H= %d \n", temp, pres, humi);
for(int32_t j=10; j>0; j--)
{for(uint32_t i=3000000; i>0; i--);}; //delay (20ms)
}

i2cClose(handle);

66
 gpioTerminate();
}

void org_compens(unsigned char comp1[25], unsigned char comp2[7])

{
dig_T1 = (comp1[0] && 0xFF) | (comp1[1] << 8);
dig_T2 = (comp1[2] && 0xFF) | (comp1[3] << 8);
dig_T3 = (comp1[4] && 0xFF) | (comp1[5] << 8);
dig_P1 = (comp1[6] && 0xFF) | (comp1[7] << 8);
dig_P2 = (comp1[8] && 0xFF) | (comp1[9] << 8);
dig_P3 = (comp1[10] && 0xFF) | (comp1[11] << 8);
dig_P4 = (comp1[12] && 0xFF) | (comp1[13] << 8);
dig_P5 = (comp1[14] && 0xFF) | (comp1[15] << 8);
dig_P6 = (comp1[16] && 0xFF) | (comp1[17] << 8);
dig_P7 = (comp1[18] && 0xFF) | (comp1[19] << 8);
dig_P8 = (comp1[20] && 0xFF) | (comp1[21] << 8);
dig_P9 = (comp1[22] && 0xFF) | (comp1[23] << 8);
dig_H1 = comp1[24] && 0xFF;
dig_H2 = (comp2[0] && 0xFF) | (comp2[1] << 8);
dig_H3 = comp2[2] && 0xFF;
dig_H4 = (comp2[3] << 4) | (comp2[4] && 0x0F);
dig_H5 = ((comp2[4] && 0xF0) >> 4) | (comp2[5] << 4);
dig_H6 = comp2[6] && 0xFF;

return;
}

// Returns temperature in DegC, resolution is 0.01 DegC.

// Output value of “5123” equals 51.23 DegC.
int32_t Temp_Compens(int32_t adc_T)
{

67
 int32_t var1, var2, T;
var1 = ((((adc_T >> 3) - ((int32_t)dig_T1 << 1))) * ((int32_t)dig_T2)) >> 11;
var2 =(((((adc_T >> 4) - ((int32_t)dig_T1)) * ((adc_T >> 4) - ((int32_t)dig_T1))) >> 12)
* ((int32_t)dig_T3)) >> 14;
t_fine = var1 + var2;
T = (t_fine * 5 + 128) >> 8;
return T;
}

// Returns pressure in Pa as unsigned 32 bit integer in Q24.8 format

// (24 integer bits and 8 fractional bits).
// Output value of “24674867” represents 24674867/256 = 96386.2 Pa = 963.862 hPa
uint32_t Pres_Compens(int32_t adc_P)
{
int64_t var1, var2, p;
var1 = ((int64_t)t_fine) - 128000;
var2 = var1 * var1 * (int64_t)dig_P6;
var2 = var2 + ((var1 * (int64_t)dig_P5) << 17);
var2 = var2 + (((int64_t)dig_P4) << 35);
var1 = ((var1 * var1 * (int64_t)dig_P3) >> 8) + ((var1 * (int64_t)dig_P2) << 12);
var1 = (((((int64_t)1) << 47) + var1)) * ((int64_t)dig_P1) >> 33;
if(var1 == 0)
{
return 0; // avoid exception caused by division by zero
}
p = 1048576 - adc_P;
p = (((p << 31) - var2) * 3125)/var1;
var1 = (((int64_t)dig_P9) * (p >> 13) * (p >> 13)) >> 25;
var2 =(((int64_t)dig_P8) * p) >> 19;
p = ((p + var1 + var2) >> 8) + (((int64_t)dig_P7) << 4);
return (uint32_t)p;

68
}

// Returns humidity in %RH as unsigned 32 bit integer in Q22.10 format

// (22 integer and 10 fractional bits).
// Output value of “47445” represents 47445/1024 = 46.333 %RH
uint32_t Humi_Compens(int32_t adc_H)
{
int32_t v_x1_u32r;
v_x1_u32r = (t_fine - ((int32_t)76800));
v_x1_u32r = (((((adc_H << 14) - (((int32_t)dig_H4) << 20) - (((int32_t)dig_H5) *
v_x1_u32r)) + ((int32_t)16384)) >> 15) * (((((((v_x1_u32r *
((int32_t)dig_H6)) >> 10) * (((v_x1_u32r * ((int32_t)dig_H3)) >> 11) +
((int32_t)32768))) >> 10) + ((int32_t)2097152)) * ((int32_t)dig_H2) +
8192) >> 14));
v_x1_u32r = (v_x1_u32r - (((((v_x1_u32r >> 15) * (v_x1_u32r >> 15)) >> 7) *
((int32_t)dig_H1)) >> 4));
v_x1_u32r = (v_x1_u32r < 0 ? 0 : v_x1_u32r);
v_x1_u32r = (v_x1_u32r > 419430400 ? 419430400 : v_x1_u32r);
return (uint32_t)(v_x1_u32r >> 12);
}

69
• Primary Constraints

The primary constraints of the system are as follows: constant monitoring of blood oxygen level,
constant supply of oxygenated air (21%-100%), adjustable flow rate of incoming air (0-40
L/min), water, (31-37°C) and humidified air (up to 100% humidity), and lastly, portability for at
least 3 minutes. Limiting factors also include the cost associated with the purchase of extremely
accurate commercial/medical sensors or components found in professional equipment.
Additionally, the turnaround time for PCB boards reduces the amount of time used to check for
errors or additional development time.

• Economic

Human Capital: Oxygen+ presents job opportunities within engineering, sciences, marketing,
health, manufacturing, and sales sectors.

Financial Capital: Our target customers will be able to obtain this device through a doctor and
lease the device through insurance, which will cost less than using a ventilator in a hospital and
can be sanitized and reused with a different customer.

Natural Capital: This product will contain many electrical and mechanical components including
various sensors, a Raspberry Pi 4B+, an oxygen tank, a Lithium-Ion battery, and a variable valve.
Many of these parts are not recyclable and therefore, if not carefully maintained, this product has
the potential to deplete many natural resources.

Cost and Timing: The target cost of the Oxygen+ ventilator is under $1000; this is heavily
dependent on components used in the final design and will increase with the number of sensors
and features implemented on the device.

The cost of the project happens at production and throughout the rest of the life cycle due to
maintenance and upkeep. Each device will need to be leased out a couple of months to cover the
production and maintenance. After the first year, most of the devices should be making only
profit.

Original estimated cost of component parts (as of the start of your project): $605
Actual final cost of component parts (at the end of your project): $677.30

Component BOM

Page
2
Resistors Value (Ohms) Cost ($)

R1 10k 0.65

R2 1k 0.93

R3 2.2k 0.92

R4 1k 0.93

R5 1k 0.93

R6 330 0.92

R7 100k 0.63

R8 1 0.58

R9 15k 0.92

R10 2.7k 0.92

R11 1k 0.93

R12 180 1.09

R13 1 0.58

R14 180 1.09

Capacitors Value (Farads)

C1 100n 0.43

C2 100n 0.43

C3 220u 0.76

C4 100n 0.43

C5 1n 0.36

Inductors Value (Henrys)

L1 330u 0.3

L2 180u 0.31

ICs

IC1 LMC66 2.46

IC2 MCP3021 1.12

Transistors

Q1 2N2222A 2.28

Q2 T0-220AB 1.77

Q3 T0-220AB 1.77

Diodes

D1 1N1444 1.33

Page
3
 D2 1N1444 1.33

Header

JP1 2x1 0.23

JP2 2x1 0.23

JP3 3x1 0.29

JP4 3x1 0.29

JP5 4x1 0.4

JP6 4x1 0.4

JP7 2x1 0.23

Misc.

SMT->DIP Mount 1.75

Total Cost 30.92

Page
4
BOM: Additional Materials

Page
5
The amount earned will be dependent on how long each device is leased. Leasing the devices at
$150/week it would take 5 weeks of leasing for the devices to make profit. Assuming a life cycle
of 2 years and 50% usage each device would make about $7,500. This profit would be made by
the leasing company.

• Timing

Page
6
The product would emerge after FDA approval and clinical trials conclude. This could take an
one or two additional years after the product is developed. The ventilator should last multiple
years as long as the proper care and maintenance is performed. The maintenance needed for the
ventilator will mostly be in cleaning and sanitizing the device. There will also be testing done to
ensure that the device is operating properly and fixed promptly.

The original Gantt chart was followed closely and therefore, save for some delivery dates of
components differing, this is the official Gantt chart for the project.

Page
7
The next steps of the project will be to test the 2nd iteration of the pcb and perform the necessary
safety tests. After this the ventilator will need to undergo trials to determine if it can perform its
function with actual patients. During these trials, the ventilator will continue going through
improvements.

Page
8
• If manufactured on a commercial basis:
Estimated number of devices sold per year: 1200
Estimated manufacturing cost for each device: 400
Estimated purchase price for each device: Lease Only
Estimated profit per year (50 % Usage, device only): $4,440,000
Estimated cost for user to operate device, per unit time (specify time interval): $150/week

• Environmental

The solder used to mount the components onto the circuit board includes lead. Lead can be
released into the air and groundwater throughout its life cycle in other sectors. However, at the
end of this device's life cycle the solder may pose a threat to such areas if not recycled properly.
Each device contains approximately an ounce of solder, and therefore each year an estimated 75
pounds of solder are potentially waiting to be released into the environment if not recycled
properly.

The project directly uses oxygen, air, and metal. It indirectly uses natural resources that are used
to provide power, such as coal, solar, wind, etc.

The project uses natural resources, thus, by itself it will harm those resources until more
sustainable methods are developed. However, the ventilator will use less power and materials
than what is currently available and being used. Due to this the overall impact of the project will
be positive and preserve natural resources.

The project’s impact will be indirectly by using natural resources that can have negative effects
on the environment. Due to the project's reusability and compactness, the impact should be
minimal and improve as better ways to produce power are developed.

• Manufacturability

Much of the circuitry will be able to be prefabricated by a PCB vendor. Sensors, servos, and the
power supply will have to be attached manually. Mechanically, the casing will have to be
manufactured, and the oxygen tank, along with the raspberry pi will have to be installed
manually as well. Each device will also have to be rigorously and individually tested to meet
FDA and FCC requirements to ensure their compliance and quality is up to standard.

• Sustainability

In order to keep these devices out of landfills, the decision to reuse and repair is more beneficial
both economically and sustainably. When making the decision to reuse available parts or repair a
broken segment instead of tossing it into a landfill, this both extends the lifetime of the device
and keeps more devices out of landfills. With a longer device lifetime, the ‘bottom’ of the
Weibull (bathtub) distribution is extended, and because the current business model is a lease-per-
time arrangement, the longer a device is in use the more value it adds to the company, the more
people it can help, and the longer it stays out of a landfill.

Page
9
• Ethical

This device deals with the collection and radio transmission of sensitive health data, therefore the
discussion of secure transfer of sensitive data arises. This transmission and storage must be
encrypted and securely transferred to a secure healthcare server, where the contents will remain
unseen except by the specific healthcare professional intended.

• Health and Safety

Proper cleaning and ventilation of all equipment is necessary between different users of the
device to prevent the spread of any diseases or pathogens. The systems also alerts the user when
the battery is low so that they may be aware of how much power is left on the device, or to notify
them they need to plug the device in if they wish to continue operating the device.

• Social and Political

This project is one born out of the current state of the world with COVID-19 ravaging
communities and rendering hospitals non-vacant. With such a device in the market the duty to
make certain the affordability and access to such a device is paramount. The average cost to rent
a ventilator is approximately $350/week. Our presented cost is $150/week, and the margin is still
very positive as far as profit is concerned. This means there is an opportunity to provide
healthcare to communities which would otherwise not be able to support it, given the insurance
would permit the device’s prescription.

• Development

A new tool that was used for development of this project was Eagle. Eagle was used initially for
creating schematics of the ventilator since it allowed creation and use of custom symbols. When
it came time to create a pcb for the project it was decided to use Eagle for the layout due to the
amount of information and tutorials readily available for it. This program was very simple and
useful, with one of its biggest benefits being that changes made to the schematic were
immediately and automatically implemented into the layout. This also allowed for component
footprint changes to be quickly implemented.

Page
10