Updated 25 March 2020
This section provides a description of the system architecture, the control strategy and the underlying logic. All ventilation requires a clinician in the loop to titrate parameters, in response to direct observation of patient physiology. The earliest successful ventilators had limited parameters and we aim to replicate this, with specificity to COVID-19.
Ambu bags are readily available and provide a convenient means to connect to an intubated patient and deliver ventilation. However:
Ambu bags have limited safeties beyond a pop-off valve for pressure release and a PEEP that is set manually. Any ventilator design must incorporate pressure sensing and actively monitor both peak and plateau pressures. Peak pressure exceeding 40 cm H2O (or a pressure set just below the pop-off pressure of the selected bag) must trigger an alarm.
All decisions are being made on the basis of safety and minimizing complexity, which sometimes means omitting features. Please reference our other documents for more information on these tradeoffs.
This is a living design and will continue to be updated as we receive more information and learn from our ongoing testing.
In the interest of simplicity and ease of use our prototype system has only two modes of operation:
Mode 1 – Volume Control (VC) – Clinician selected breaths are delivered at a constant rate automatically, with pressure monitoring only for safety. VC is only suitable for sedated and paralyzed patients. Tidal Volume, BPM and I:E are set as per clinical guidance.
Mode 2 – Assist Control (AC) – When the patient tries to breathe in, the pressure sensor will see a pressure drop, and the machine will begin squeezing the bag in order to assist in the breath. (Because the compression is triggered by the patient’s breath, the machine will be operating in sync with the patient’s natural breathing.) In AC mode the desired BMP is set slower than the patient’s expected breath rate. This sets a timer that is reset each time a patient takes a self-initiated breath. If the timer runs out the system initiates a breath.
Activation of the assist control must trigger an alarm to indicate that a patient is not self breathing.
Caution: Assist control has not yet been tested in a porcine model due to the additional complexity and failure modes.
- Breaths per minute (BPM)
- Tidal volume (TV)
- Inspiration to Expiration ratio (I:E)
- Trigger pressure (only active in AC mode)
We direct your attention to the following information:
Estimate of the required motor power, validated with bench testing
Minimal electrical hardware architecture
High Level Control Strategy
List of Alarms that are implemented
170 Replies to “Controls & Electrical”
Amazing! Some feedback.
Specify pressure sensor range in this doc?
I/e max ratio listed as 1:2. On the clinical doc it was up to 1:3
Spell out potentiometer somewhere (not just POT)?
POT 1 last sentence is not complete
Mode 2 last sentence seems incomplete
The diagrams need work to match the text. Let me know if I can help. Both also appear to be for assist mode.
Great job everyone. Thanks for your hard work.
Sisu is working on miniaturizing this circuit with off the shelf components that are currently available in large quantities.
I did have a couple of questions.
Why the redundant position sensors (encoder and pot). Could we use just one or are you expecting to need redundancy?
Did you have a thought on how to re-use the pressure sensor between patients? Right now we are expecting to have to switch sensors because it will become contaminated by the patient.
Adafruit component on prototype is unavailable (orders closed as of 3/18/2020). I understand other sites list availability of similar components.
Note Adafruit is taking orders for medical projects and building PPE https://blog.adafruit.com/2020/03/22/covid/
Excuse me I cannot find the codes for arduino, Iwill be delighted if you can help me to find it,
اعملي رساله ي بش مهندس وبرسلك الكود
Amgd can you send me the codes plz ?
Many thanks to the team for working on this project. It feels good to see people are working on such a potentially life-saving product in an open-source environment. I find this effort very inspiring, and I would like to share my thoughts, in the hope that they would be useful to make the system better.
Due to the nature of this system, I believe extreme care must be taken to prevent any corruption and common glitches from compromising the operating state of the system. The goal of the following suggestions is to maximize the system reliability and safety. If these suggestions are implemented from the very beginning, they should not be too complex to implement.
Even with all these measures, I think the system will be far simpler and much less reliable than normal medical systems, but hopefully 80% of the required reliability will be achieved with minimal effort and a short development.
1) WATCHDOG TIMER
First, I think it is paramount that any crash of the microcontroller should be detected.
The first step would be to enable the watchdog timer on the microcontroller to detect any hard crash or fault, and automatically reboot the system if that happens.
2) HANDLE UNEXPECTED RESETS
Because there can be a reset at any moment (software glitch, watchdog timer, power spike, …), make sure that the software can handle a reset whatever the current state of the system is. i.e. if someone resets the microcontroller while the system is operating, all parameters must be intact and the system must resume operation transparently.
What I mean here, is that it is OK that the system does nothing at initial power up, but once it is running, it must resume if the software resets at any random moment. There should be a distinction between the state of the system, and the state of the microcontroller (i.e. it is not because the microcontroller is rebooting, that the system is being powered up for the first time). The current state of the system (e.g. RUNNING, STOPPED, …) can be stored in non-volatile memory.
I am a bit concerned when I read sentences as “(no motion at power up)”, this is OK as a functional requirement at a system level, but that does not mean the microcontroller itself must do nothing when it resets, because in that case, if it crashes, it will stop working.
It also means the system must be able to resume operation whatever the current state is (exhaling, inhaling).
3) USE CHECKSUM ON ALL DATA
I believe all parameters should be stored in non-volatile memory (the microcontroller has an EEPROM), with a checksum.
Checksum of the parameters must be verified before being used. After each write, re-read the data to make sure it has been written properly, then re-compute the checksum for all the settings and make sure nothing got corrupted.
This process can be repeated up to 5 times (for example) if it is not successful. If it still fails, assume it is uncorrectable and sound an alarm and use fail-safe defaults.
To prevent the non-volatile memory from wearing out, only store significant changes (e.g. unless an operating parameter is changed, nothing new should be written on the internal memory).
4) COPY-ON-WRITE SCHEME
To prevent corruption if the system if rebooted for any reason during a write operation in the internal EEPROM, there should be two sets of parameters (numbered 0 and 1) and one pointer determining which set is active (the other one is standby). Any new write is first written into the standby bank. Once the standby bank has been proofread, the pointer is updated, and then the system applies the new parameter.
The pointer must be a full EEPROM erase unit, so that it can be atomically erased or programmed.
To know which set to use, the software reads the pointer. If its value is 0, then the active parameter set is parameter set 0, and any other value make it the other set of parameter.
This way, there can be no corruption. If the system is reset during a write of the new parameters, it will simply revert back to the previous parameters which have been left untouched. And it will only change to the new parameters once they have been proofread.
As above, any write must be checked and attempted again up to 5 times if it fails.
5) USER INTERFACE CLARITY AND POSITIVE FEEDBACK
I am very concerned by the current user interface of the product as described in the page currently, and I believe it is unsafe and error prone.
What happens if one potentiometer is broken ? The operator can change the position of the potentiometer, and believe they have changed the parameter, but in fact, they have not, as far as the microcontroller is concerned. And now they have to try to understand what the problem is, loosing valuable time, and debugging the system instead of debugging the patient’s health.
This type of problem has been the source of multiple accidents, in the nuclear field (TMI for example), and also in the medical field (THERAC-25) and has killed people. We don’t want this to happen here.
I would suggest to change the user interface as following :
– Change the I2C LED display to an I2C LCD display, such as a 2×16 display.
– Display ALL operating parameters and current mode, as seen by the microcontroller, on the LCD display at all times, allowing the operator to positively make sure the settings are what they believe it is at any moment
– Instead of using one potentiometer for each parameter, use one optical encoder (example: KY-040 or similar), one SELECT button, and one SET button (which could be the encoder’s integrated pushbutton).
To change a setting :
– The operator enters the setting mode by long-pressing the SET button
– The last changed parameter starts blinking. The operate select the parameter they wish to change using the SELECT button which cycles through all available parameters. The currently selected parameter is blinking.
– The operator changes the value by turning the encoder
– The operator can continue changing values of other parameters by pressing the SELECT button and modifying them
– Once the operator has done all the changes, they press SET for 2 seconds to latch the value (which triggers the storage in memory as described above and apply the parameter).
– The display is then updated with the new values, the system emits a short BEEP, and applies the new parameters
– If the operator does not press SET to latch the new values after 10 seconds, no change is made and the system keeps the current values, and emits a long BEEP.
This way :
– There can be no undue change of the parameters (someone touching a potentiometer inadvertently)
– In case a button no longer works or returns unplausible values, the operator will know immediately
– At any moment, the operator can read the state of the system and make sure it is right and expected (this allow nurses to come and check the state of the systems)
Again, if this is not done, there is a safety risk (ergonomic problem).
To save valuable screen real-estate, use the front panel of the system to write any unit and legend, and only write useful data on the LCD itself.
6) EXTERNAL INPUT VALIDATION
The system should detect if any external sensor goes bad and returns erroneous data. This is not always easy to do but there can be general safeguards.
Example : a pressure sensor goes bad and always return 0.004 or 23.34542, the system must not start pumping too much or too little air. Instead, it should detect that no operating parameter has been changed, and yet the values returned are not plausible and changed significantly. The system could also detect stuck values (example, if we expect the pressure to change at least by a given number during each breath, we should check for this).
There are different ways to accomplish this :
– Store in memory a table with a range of plausible values. If any external input is out of the range, detect it
– Use multiple sensors and cross-check the values
– Every time a new parameter is changed, monitor the result at the sensors and detect any change greater than the expected change.
When an unplausible value is detected, different things can happen depending on the affected sensor and current operating state :
– Stop the system
– Revert back to hardcoded open-loop defaults. This is akin what a car ECU would do when a sensor goes bad, go into limp mode.
Every time a fault like this is detected, the alarm must be sounded.
7) SENSOR LIFESPAN
Care must be taken with the selection of the potentiometers and especially the angle measurement pot due to the high duty cycle. A potentiometer may worn out due to the high duty cycle. Non-contact measurement techniques such as hall-effect sensing would possibly be more reliable, maybe coupled with an optical encoder + an optical limit switch to recalibrate it. If using a potentiometer, the firmware should implement debouncing as the track can age and cause glitches at some points.
8) MONITORING THE SYSTEM and EXTERNAL WATCHDOG
It is not possible to make sure the system is working if it is not being monitored.
I would suggest the system outputs machine readable (CSV) data over the UART, each message starting with a respirator ID stored in EEPROM, software version ID, and message ID, so that the respirators can be later networked and monitored using a PC or similar, showing all sensor inputs and settings and system status. It would also open the possibility of data logging on the PC, this way if there is a problem, it can be audited and debugged.
This also allows for external detection of any crashed, disconnected or generally malfunctioning respirator.
9) REMOTE MONITORING
We cannot expect a nurse/technician/doctor to be next to each patient at any moment. If an alarm sounds, there might be nobody around to react in a timely manner. So there must be a way to remotely monitor the respirators.
There should be :
– An output to the serial port for each alarm condition (CSV like above). Later, if a PC software for monitoring/logging is developped, the alert can be relayed to any system over the network, including pagers, SMS, …
– A normally closed dry contact relay for alarms. This way all ventilators can be daisy changed and if one goes in alarm, it can be reported in a central place. Or an external transmitter can be connected.
10) SANE CODE HANDLING AND AUDITING
All code and design documents should be on a version control system. All version should have a unique release ID and the binary files be archived for debugging purposes. For each version, the same binary file must be used (to prevent different compiler versions/settings from generating different codes for each same source code, making it a nightmare to debug in case of failures in the field). Keep a copy of the compiled code and only distribute that binary, do not allow multiple people to compile the same code and call it the same version (it is OK for development but NOT for production use).
Ideally, an hardware ID should be used, but I don’t see one in the current system. One could be stored in the Arduino EEPROM but it creates logistical issues (it needs to be programmed somewhere). So I would suggest using a 1-wire sensor (DS18B20 or similar) and use its ID as the system ID. This way, every respirator has a globally unique ID.
11) SANE CODING TECHNIQUES
Care should be taken when designing the software architecture. Communication between each software block should be well defined, and coupling between each different part must be avoided (example : the user interface handling code must not directly call code everywhere in the system, instead it should have a well defined interface).
If the respirators are connected to a PC for monitoring, they should not be connected using the Arduino USB port as it has the capability to reprogram the Arduino. Instead, a serial USB converter with only the Arduino TX and GND connected should be used. This way, no data can be transmitted from the PC to the Arduino, no parameter can be changed and no reprogramming can be done.
13) OTHER RELIABILITY CONSIDERATIONS
All registers and external actuations should be rewritten in their entirety regularly, because we cannot assume external systems have not been reset or changed (due to glitches) without us knowing. This includes the LCD interface.
These concepts should not be too hard to implement and should greatly enhance the reliability and the safety of the system. Hope this helps !
Agree with Mr Achard
Considering a Safe MCU that incorporate watchdog and CRC could be a good option. Such as NXP S32 and Kinetic EA MCU. The NXP Safe MCU evaluation boards are Arduino R3 shield compatible and relatively low cost. They could be available in large quantity ( 8 weeks lead time from Digikey). Waiting for the NXP representative callback about availability. Also, NXP have good IDE and proven s/w libraries for safe system development
All of these are very good ideas. I like the way you think Bertrand.
I especially like the ideas of a 2 line LCD display and remote monitoring.
SELECT and SET buttons are a nice, requiring SET be pressed for several seconds would prevent someone from bumping pot and changing settings. If design using pots is kept, I’d suggest an alarm every time a pot changes by more than a certain percentage (to prevent ADC noise from triggering alarm), alarm ceases after a few seconds. Lets user know their change was entered and could warn of accidentally changing a setting.
I’d like suggest dumping the data to a raspberry pi with wifi. If we ignore your security concern (due to scarcity of resources), we could use pi’s USB ports to receive from several arduinos. Pis could make networking a bunch ventilators and sending data to a central monitoring station fairly simple, especially if using later generation pis with built in wifi (though older ones can be used with pretty common wifi USB adapters stuffed in one of the USB ports). Regards security we might be able to modify the pis USB drivers to prevent writes out the port.
Using a pi for monitoring might get rid the need for unique ID for each arduino, since each pi would be assigned a unique IP address, which could be used as ID. There were over 30 million pis sold as of Dec 2019. They are always low in stock at most sources, but we could ask folks to donate them, I have several I’m not using at the moment I’d gladly donate.
The arduino chip EEPROM is guaranteed for 100K write cycles. That is probably enough for this application as in my experience number of EEPROM write cycles is temperature dependent, at room temp you should get several times more. If we decide we need more write cycles we could use more than your 2 blocks of copies, with each block having a checksum. Each block has a 1 byte write counter. The block with the highest write counter and a valid checksum is the last block of valid data. This limits the amount of data you can store though, but could work with your technique.
Sanity check: if doc changes a setting every 5 minutes on ventilator, 1440 (minutes in a day)/5 = 288 days = about 9 months (and probably more like 1.5 years). If you change interface so that doc can change several parameters and then press set that might extend lifetime a bit. Might be nice to add an overall eeprom write counter to detect when arduino is nearing end of life.
SANE CODE HANDLING AND AUDITING:
This should include rigorous unit testing (when possible), code review, bug tracking and regression testing. Code reviews can be tedious, but there are millions of software engineers (many of whom have used arduinos) sitting home, dying for some way to help. All these steps should be done before any new code gets put in repository as “production” code.
Stress testing the code might also prove helpful. If we ask the arduino to do too many separate time sensitive tasks it will eventually start to fall behind. Adding a clock task and a time wasting task could check how much processing time we really have left. Up the amount of time the time wasting task consumes till the clock starts getting slow. We would of course need to be sure the time wasting task was disabled in production code.
Thanks. Just a quick note to explain that the copy-on-write purpose is not to do wear leveling, but rather than to ensure that the integrity of the data can be guaranteed even if the system is being reset while a data writing is in progress.
I see that the team has done great progress and is now testing, it’s exciting !
Just a comment to what Bertrand wrote (#5 above) about ‘User Interface Clarity and Positive Feedback” , and
specifically addressing this problem in the list of alarm conditions:
“NOT SET Potentiometer has been moved but change was not confirmed Machine maintains settings Pressing Set button sets values and clears alarm”
If you were providing a larger LCD display, could you display TWO lines of settings: the one actually in force, and the pending changed setting(s) below it? The pending ones could be in a different color, or flashing, until set. This way it would be immediately obvious if someone had changed (inadvertently or not) some setting.
RE: REMOTE MONITORING
While Raspberry Pis do offer a cheap solution, I would recommend using Android tablets instead. They also have a USB port and are relatively affordable. They have touchscreens, cameras, native 4G/Bluetooth/wifi capabilities, NFC, 12-24hr batteries (in case of power outage), and are more complete computers than a Raspberry Pi. They are also widely available.
Arduinos are uniquely suited for the hardware aspect of this, but Raspberry Pis would be unnecessarily “makerspace-ish” IMO.
Pi’s SD cards fail where Arduino has an EEProm. There is no need for storage in a basic logic model. I would strongly recommend against this.
Lovely thought to suggest an Android and they’re pretty bulletproof; however, I believe you are suggesting an N-stage design. The object is inexpensive and simple to build. Adding in serial communications/bluetooth adds another layer of unnecessary complexity and another surface to “touch”.
Great ideas, thank you for sharing! I agree with you on creating a simple multi-tasking framework using finite state machines. As long as you have a time base that is interrupt driven (such as a 1 millisecond timer) you can use this to control timing and timeouts in each state of each FSM. Using one FSM per task will basically allow one to have a concurrent system with accurate timing. I have done this on two bare metal MSP430s and on several Arduino systems and it works quite well.
RE: REMOTE MONITORING
I suggest adding and SD card module that collects any monitoring data from the patient. This may be a useful back up of information for post-clinical analysis. In the event that the remote connection fails, you still have all the data available on the card.
In ADDITION to a serial/wired connection to the PC (as suggested by Bertrand) I suggest adding a Bluetooth module to the device. You can periodically push monitoring data to a phone which can sync to central servers or computers accessed by clinicians and healthcare workers. This may be important if a patient is in transit and needs to be moved to a different bed or building or ship. In additionally, it provides a safety barrier for healthcare workers that don’t need to be physically present in the room to look at the PC. It also provides a more instantaneous real-time view of the patient’s status to any healthcare worker which could potentially access information on an tablet or smartphone on the go. I imagine they are all very busy and quite mobile.
FORGOT TO ADD TO MY POST:
I would consider adding a remote, “over-the-air” software update capability. In the event that there is a critical software bug that needs to be fixed, its valuable to have the ability to update the software fo many devices remotely. This is done for many software and hardware products in industry.
This may be an interesting way to fix problems, however it also introduces the ability to deactivate or cripple devices remotely. Additionally, the simpler the system can be (no massive over-the-air systems with self-flashing capability), the more likely it is to work out of the box. Our current plan is to exhaustively test simple, self-contained designs before they go out.
I would also add that if the counts for these units are as high as some numbers project, there will could be a large number of systems flooding the airwaves. Remote monitoring alone may be swamped.
Two thing I would like to point out. The EEPROM on an arduino is only supposed to be good for 100k write erase cycles so writing to it too much might not be a good idea. Also using only precompiled binaries in production might not work since the specification is flexible enough to accommodate whatever parts might be available. The motor controller could run on SPI or any number of serial communication protocols.
In relation to “9) REMOTE MONITORING”
I have a system able to do remote monitoring (and also remote control) of arduino based systems.
I was developing a tool for developers to build IOT applications for remote monitoring and control when coronavirus came along. This is a video of such an IOT project controlling ventilators https://iotleaf.co.uk/screen_recorder/ventilator_demo_charts.mp4
For my own purposes a built a ventilator, using a stepper motor to drive bellows and a pressure sensor to detect peak pressure. I hooked it to the internet. I am able to prove the concept with this.
For the data in and out I have a special serial library that can work in parallel with the stepper motor and pressure sensor without blocking anything or losing data. Kind of multitasking, but my multitasking library is based on milliseconds so I had to hand code for microseconds in a form of state-machine way.
The output can be viewed on a PC, or Tablet or Phone – anything with chrome/firefox browser.
I was working on this for about 2 years and was about to announce it for a heart monitor project. Seems like a good idea to try it out with e-vent..?
Website is https://iotleaf.co.uk
My email is firstname.lastname@example.org
Mr. Achard covered a wide breadth of important basic requirements for the control system. I’d just like to add a couple application-specific concerns regarding the chosen Honeywell sensors.
Honeywell makes good stuff, but these sensors would benefit from redundancy. I’ve had Honeywell flow sensors subtly drift over time to the point of being well outside manufacturer accuracy specifications in less than a month. Eg reporting non-zero readings at rest.
Additionally, I2C is not inherently robust, and the Arduino Wire library does not have a bit-bang reset built in that I’m aware of. Any simple I2C state machine like the pressure sensor linked here can hang the bus without warning and only be reset by resetting the state. The Arduino Wire library checks for I2C timeouts, but needs to be modified to reset the bus on timeout instead of simply reattempting or abandoning communications. This can be done by manually “finishing” an I2C communication to force the active sensor to release the bus.
If your plan is to be redundant using two of the same sensor, you’ll need to add an I2C mux, since these sensors have fully static I2C addresses.
Finally, these sensors are low volume with long lead times. I’m not sure about this specific sensor, but some of Honeywell’s sensors are manufactured in China, which poses obvious problems. Sourcing these specialty components from local/fast sources in high volumes and protecting them from contamination during use may become a significant bottleneck to scaling up production of this design.
Thank you for all your hard work.
Do you have any experience with the MPXV2010DP by NXP? It appears to be a very similar sensor.
I haven’t used any NXP sensors, sorry. Looking at the datasheet, though, it is a very different interface.
The Honeywell sensor has a digital I2C output. The NXP appears to be an unamplified analog output, so that would necessitate an instrumentation amplifier and possibly some extra work to isolate your analog traces since the analog output is accurate to somewhere around 100uV.
Additionally, depending on what type of pump you use and the flow damping in the system, either sensor could alias. Eg, if the sensor is hooked up right next to a high RPM rotary vein pump or diaphragm pump, the 1ms response time could present issues with the rapid fluctuations in pressure. I’ve had this happen on a different sensor, but that had significantly longer response times. Still, if you have >100Hz components in your line pressure fluctuations, you could start to see a filter effect on actual pressure magnitude.
Finally, the NXP device has a nominal Vdd of 10V, which does not appear to be standard on your platform (though you may be able to use 12V if that’s what your motor is running if you can isolate and smooth it). Running it off of a boost converter could also introduce noise problems due to the ripple.
If you’re worried about robustness, then we/you/this project should be pretty careful about using Arduino libraries in general, since they do little error checking and can quite easily end up in undefined states. I’ve had experiences getting nonsense data from the serial functions because it wasn’t even checking the number of bytes written/available, and reads uninitialized data or overruns the buffer. It’s also full of virtual functions (largely for their easiness of development, not need for actual runtime polymorphism), and thus brings in all the problems of heap usage, runtime memory corruption, and such.
+1 Alexander, I totally agree that most Arduino libraries are hobbyist-grade and not suitable for a project that should run 24/7. I shared that thought before and feel like I need to share it again because it’s so important !
For a project like this, I would rewrite the libraries, plain and simple, specifically for the LCD display and any communication with the sensors.
I would also disable dynamic allocation entirely (replace the malloc/calloc by a #error, and possibly change the linker script to deregister the heap section, to make sure no code is compiled with dynamic memory code !), it does not seem necessary here and can introduce a huge amount of issues.
Recommend redundant angle measurement – 2 channels allow you to sound alarm if there is a disagree. 3 channels allow the control system to determine which channel is wrong. Rotary encoders may be cheaper and/or more reliable than rotary potentiometers.
For commercial aircraft structure we conduct a “Systems Safety Analysis” which is a logic tree where each failure mode and estimated likelihood of failure is evaluated. It might be a good idea for an expert in SSA, to review the overall design to identify critical failure modes so that those modes can either be made less likely (more reliable) or that redundancies can be added to the design.
Really good recomendations from Mr Achard
I would recommend to use the ESP32, it is dual core, and has by default wifi capabilities, I’ve worked with them and I’ve been able to dedicate one core for measuring/controlling a process and other just for communications, so the communication doesnt affect the process control, each chip I’m almost sure has a unique chip ID, so by default it has the unique identifier too, as Mr Ackard proposed.
I think this would be really helpful in this case, due the dual core each device can have wifi capabilities (without affecting the main task), and this with an open source or free IoT server, can be matched to track the behavior of the devices and alarms from a single workstation, cellphone or tablet, or many, just being in the same network.
I’m not a huge experienced coder, but of course I’m available to work on this.
Among the challenges that will be encountered is the AVAILABILITY of the microcontroller(s).
Interestingly, stock levels (of various microcontroller families) at just one electronics supplier were (approx):
* 24,000 Arduino
* 78,000 ESP32
* 12,000 Raspberry Pi
So that is another “plus” for the ESP32 (not to mention its other “siblings” that might also suffice for this application).
Ideally, software versions for EACH of the various controller platforms might be prudent to consider in order to satisfy demand.
Agreed about ESP32. Arduinos might be maker-friendly but ESP32 have a large professional community and offer comparable flexibility.
Is there a Github site where the code is posted?
The UNO sketches run on a single thread and that can present challenges when non-critical components hang the system.
After letting the potentiometer cycle 8000 times we can see that the data is completely unsuitable for any sort of control.
I would like to recommend the use of the Mass Flow Meter SFM3300 sensor which is a very good quality sensor and excellent response to perform inspiratory / expiratory flow measurements, has standard connections to AMBUs and can be used either for single use or multiple uses (sterilization). In Bogotá, but mainly from Colombia, we are making efforts to manufacture mechanical ventilators, but if you can share any type of information with us, it would be very helpful, since our country is close to requiring these devices.
attached the sensor link
thanks and regards
This looks like a great sensor — but I notice that they have very, very little inventory. And a statement that says, “Do not use this product as safety or emergency stop devices or in any other application where failure of the product could result in personal injury (including death).”
That sentence is (almost) always present in any datasheet and is here to reduce liability claims from customers.
I would say a proper way to reduce liability issues and also have the required reliability would be to do a failure mode analysis and ensure not a single sensor can cause system malfunction (unlike the 737 MAX…….). This might involve doubling the sensors, but may cause supply chain issues. It’s a balance between “do we make more respirators with 2% less reliability” or “do we make 50% less respirators and let people die for that 2% reliability, but ensure that those on the respirators can count on it”.
I don’t have the answer.
Further considerations, and a few opinions (welcome to argue :)) :
Nowadays there are much more powerful microcontrollers at the same price. ESP32 has been cited, ESP8266 too, but also ARM Cortex-M0/M3 microcontrollers. Here are my thoughts.
==> This is not the time for a technology show-off. It is time to use well proven and simple technologies. The Apollo AGC had 2K RAM and 32K ROM, less than an ATmega328, the microcontroller of an Arduino Uno. I think we can control a respirator with this 🙂
– The ATmega328 will come with restrictions. Namely, no OS, and limited capabilities (no networking), when compared with solutions such as ESP8266/ESP32. However, these solutions come with a big chunk of software of unknown quality and reliability, and which is closed source (!!!), whereas the ATmega328 is much more bare-bones and can be controlled fully and is well understood.
The less code there is, the less bugs there can be.
I believe this project should be closer to a state machine / PLC, rather than a computer, for reliability reasons.
Would you rather trust your life to a well-programmed ATmega328 running a simple program, or to a computer with an OS of unknown quality ?
An option would be using an ESP32/ESP8266 without its OS, but what’s the point, and also these micros have no practically no analog capabilities. As to an ARM solution, why not, totally, but again, I would stay away from complex OSes and libraries and stay low level.
I would like to explain why I suggest a 2×16 LCD. It is tempting to use graphical LCDs, but they require more internal memory (character font tables, more drivers) and I am afraid we may run short on the Arduino. So I believe the character LCDs should be a good compromise for this project given its requirements. It is possible to move to a 4×20 LCD to get more screen real estate if needed. Also, these character LCDs are available everywhere, and are possibly easier to find than the I2C 7-segment LED display originally planed (which also presents ergonomic problems which I already explained).
– I do not believe the lack of a true OS is a problem. In fact, I believe it has some merit as it will force writing reliable code (no thinking “it is OK if my task hangs as other tasks will be unaffected”). It is possible to implement a simple cooperative multitasking OS. In that case all tasks MUST be non-blocking by design. It is perfectly do-able but this must be done from the beginning.
If I were to be connected to a machine controlled by this, I would prefer a simple cooperative multitasking OS with simple tasks with well defined behavior, rather than a complex OS with multitasking, dynamic allocation, lots of drivers and a lot of things that can go wrong. Wouldn’t you ?
– Each task can be a state machine that is ran in turn. Every time it is ran, it looks at its inputs and current state, and changes its output and current state as required. That’s it. We can allocate a decide a maximum time for each task, and we can then guarantee by the code that the task will never exceed that allocated time (by ensuring everything it calls executes within a certain time – no while(…) without a timeout !). Them, realtime operations can be performed in interrupts (with only simple, time-critical code in interrupts, and no complex library calls). Finally, communication between tasks and interrupts can be done with variables, being very careful with synchronisation (cli/sti).
A system like this can have a very well defined behavior which is what we want here. It is possible to do a graph showing all execution paths. If a reliability analysis is ever to be done, it will be so much simpler, rather than calling OS API calls which end up in a binary blob we can’t analyse.
The watchdog timer can be used to enforce non-blocking tasks. It would be kicked in the main loop, when all tasks have been executed. If any task is stuck, system will reset.
– Many common Arduino libraries are not production quality and even less medical quality. A lot have poor error handling and can readily crash or hang. Many of them do not have timeouts or retrying. To guarantee non-blocking operation, it is possible that a lot of the common libraries would have to be rewritten, which is why it is important to stay away from complex peripherals (graphical LCDs…) to limit the amount of software engineering required to the least minimum.
Hope this helps.
When the design is finished we can provide assembly and testing in the Houston TX area. We manufacture, and design Measurement While Drilling equipment. It is small, has lots of electronics, and micro processor control needs so we have the right tooling and expertise. Let me know if and when you need to scale up. As well if and when you hit supply limits on the Arduino or other based boards. We design and build MicroChip based micro controller boards from components, so we have capacity, including programmers to move to this platform if other supply options dry up.
If we’re truly interested in high assurance systems (and I think medical devices should be in general) I think you’re very right on the state machine idea. It might also be a good idea to look into formal methods languages like Bedrock 2, but I fear the biggest problem in producing something quickly would be that there’s very little experience with it in the software engineering community as a whole (I don’t even know it, just people who do). A couple papers have been written on using formal methods in small IoT devices, where they can prove the absence of these problems, so it’s totally *possible*.
I would like to second the sentiment of sticking to the most basic software architecture available and using character displays. If you need more connectivity than the Atmega328 can provide, I’d recommend something like the Arduino Mega or Due or the Teensy 3.6 before jumping to an SBC or the ESP or Particle devices. It also doesn’t hurt to avoid wifi/bluetooth connectivity for security purposes.
Redundancy, error checking and error/interrupt tolerance are the real heroes here at the low level. The higher you abstract the processing, the easier it is to program (given appropriate drivers and libraries), but the easier it is for bugs to appear. The level of complexity of a simplified ventilator like this doesn’t justify the jump to a full OS or parallel processing.
One aspect we may want to account for is the IN STOCK availability of the microcontroller. With that in mind, there may be significant advantage in STANDARDIZING the controller connections (either with something as simple as wire colors or signal designations) or using a widely-available connector. This would allow a failed component (like a controller) or mechanical mechanism to be easily swapped out – REGARDLESS OF THE MICROCONTROLLER. Using this modular approach could make it much easier to maintain these units and keep them going for as long as possible. Also, it would allow a “lay person” to easily perform swap-outs. Finally, with something as simple as a standard wiring harness (maybe using a common “Phoenix-style” removable screw terminal connector, ANY MICROCONTROLLER could be swapped for another REGARDLESS of its family, brand, microprocessor, etc. Just something to consider
Checking out microchipdirect.com which is microchips online store for all their microcontrollers which is great because it shows stock. Link below:
What could be done is choosing a couple form factors that are available in wide use and then design boards which fit those sizes. And ideal solution would be the same board/mounting but as an alternative which wouldn’t be terrible would be having two or three flavors of PCBs which would allow for those mountings.
I am also wondering about converting code for the atmega328, can someone point me to the arduino source code? I can start the conversion process to atmega328 on a github hosted page. It is known/assumed the arduino code will change as updates are made though getting an initial version in will help us then have a baseline to make edits on.
Your are right on, ESP32 running Free RTOS, run critical process (PV measurements, setpoint, alarms, etc.) on one core and run non-critical (display, printing, comms, etc.) on the second core. ESP32 includes watchdog functions for alarms.
ESP32 also has built in PWM controller for DC motor and stepper motor. Check out the built in APIs on the Espressif website. The ESP32 has many, many API that can be used for this. I am currently building an automated high voltage test set for my company. Has many I/O points, current, voltage, timing inputs, and outputs for printer, HMI, MQTT messaging. I would love to work on this if I can find a team to join.
Any thought to using a milking machine with a reduced pulse rate as a negative pressure ventilator
I could’t agree more with your criteria Mr. Achard, honestly since I’ve read your first post I learned a lot, and the reasons explained why to avoid the usage of ESP32.
I’m thinking on this as the experience read in other countries, that the virus is not known totally and sometimes the medical team overwork due the lack of them (even by the same disease), so maybe the mayor amount of information that can be registered and sorted, makes easier the analisys, that’s why I think if the devices can send the evolution of the variables to a server that can give graphic analisys is very appropriate in this particular situation, even I would think to add a temperature sensor, to get the air’s temperature, and a heart rate monitor (and maybe this could help in case where the main sensor fails before going open loop control, I don’t know and haven’t read about this, just trying to think out of the box and dropping my ideas as a brainstorming), adding sensors is not difficult for us and may give valious information for them.
The idea is to give to the health care team a tool so they can have the mayour amount of information centralized and accesible, so they can analyze it easier and decypher the disease behavior faster and track the evolution of patients easier.
Is just me or someone else knows that something really good is going to rise from this?
Let’s keep thinking and making fellows 😉
Have you considered using high density Li Ion batteries as a smaller mobile alternative to a Car Battery? Batteries like the ones used in Medtronic’s HeartWare LVAD or Abbott’s Heartmate III LVAD. Using batteries of this size and weight make the process moving a patient far easier on the staff, and these moves (to/from the OR, room transfer, to radiology, etc.) are usually on the time scale of minutes, not hours. Additionally, when a patient is moved, the staff use the bed as table and often lay equipment all over the place and it may be difficult to add something the size and weight of a car battery into the mix.
Also for your consideration, most (all?) hospitals have a redundant power system that is supplied by generators independent from the local power grid. In the event of a black out, these systems typically takeover the power generation in several seconds. Additionally, there are outlets in every patient care area that are tethered to the redundant generators, which all patient life support equipment must be plugged into.
Best of luck.
The reason that the generators might not be sufficient for this is that they usually take 10 seconds (at least) to startup, which means that the ventilator has to at least be smart enough to retain all settings through a reset.
Ok I see. The FDA has a history of requiring a back-up power source specifically for the control circuit of Class 3 devices. Would it be easier to avoid the Controller shutting down altogether by placing an internal battery, such as a 9V, to act as a backup and reduce the chance of the settings being reset?
I agree that it is prudent for the system to have a battery backup (and large enough bulk capacitance to maintain power to the MCU for the milliseconds that switchover takes). However, as Mr. Achard has pointed out, it is also crucial that the firmware and hardware be fault tolerant to resume operation from any point without loss of state given a component failure or power failure. Both battery backup and fault tolerance are necessary features.
Another thought would be if the patient needs to be moved the system needs to run during the move.
I have seen generator switchover take over a minute, depending on the system.
Reading this section, it seems maybe we are talking about two kinds of backup power: Low-power backup of settings (during some kind of re-set or external power loss), and higher-capacity backup power to actually RUN the machine during such a loss. The first kind absolutely should (and can) be portable/unobtrusive and embedded in the circuitry (like CMOS batteries). The second might necessarily be heavier.
Supply chain is the issue. If only 1000 units can be made, the effect will be negligible. Can you get all the parts in quantity 100K plus? For example, you could use Throttle position sensor, MAP sensor and electric drill motor? Designs using junkyard/auto parts from GM/Ford/Toyota/VW and drill motors from Makita, DeWalt, etc. would need to be developed. Cell phones have two audio outputs and one audio input, or can bluetooth to other devices. Can these be used to control and monitor the device?
How are you going to train the RTs to use this device? It might be good to make the interface look like a standard ventilator such as a PB 940 with some of the controls and indicators grayed out.
When a clinician uses an Ambu bag manually they know when and how much to squeeze the bag, and monitor the patient, based on their Ambu training. Our goal is to have knobs for the exact bag ventilation they already know how to do, with no extra complications. For example, if they see the patient needs fewer breaths per minute, they will adjust the breaths per minute knob accordingly.
If we need upwards of 700,000 of these things then both hardware and software need to be able to support a wide variety of component parts. It is doubtful today if, for example any motor manufacturer could supply this quantity of motors. Likewise processors or even Ambu-Bags. Therefore the design scope must be readily able to accept or me easily modified to support almost any type of motor, to stick to one component no mater be it a stepper type geared or otherwise or some other type of motor scavenged from a an appliance.
I built a very rudimentary ventilator based loosely on the original MIT design. I just happened to have a NEMA 17 motor with a 51:1 stepper motor and a DRV8825 driver. I have no ides what motor MIT used. I just used what was to hand.
The final design needs to be versatile.
This great work.
Currently, we are designing a very similar ventilator with parts that can be sourced from a car. We are designing with manufacturing in mind. Check it out: https://sifted.eu/articles/coronavirus-windscreen-ventilator/
My company has mechanical engineering, manufacturing, and outreach/communications support we would like to contribute for this effort.
Are you available for a brief call so we can discuss how we can collaborate? +1-305-792-8778 email@example.com
Here are some ideas for areas we can assist with:
– Technical design, assembly instructions, and shop drawings for manufacturers (we use SolidWorks 2019).
– Hosting webinars and creating email campaigns to keep people informed and generate more support.
– Government outreach. We are based in Miami, FL and we currently work with cities in the US and Australia.
– Spanish and Portuguese language support.
– Supporting fundraising efforts.
– Manufacturing and supplier outreach.
I am making a schematic and PCB layout that will have all the components so no shield will be needed. All components (or most) will be through-hole to be cheaper for DIY and low volumes. On the circuit diagram page, Arduino A4 is the input for the pressure sensor?
There is no pressure sensor, only a pressure potentiometer
oops I misspoke!
If using wall power, do you have a conversion module identified?
Hi everyone!, can someone share me the source code?, I could packet the functions that can be used in other microcontroller models and development boards like the TI-MSP430.
Also interested in the source code for translation to Atmega328 microcontrollers!
just realized the arduino runs this microcontroller.. in that case it seems if porting to the same chip on a PCB design without the arduino interface one can use the avrdude command for downloading the program code so it can be reprogrammed to the other chips
Also interested in the source code!
In the meantime, recently this code appeared in the Open Source Ventilator’s GitLab:
As of 4/6/20, Arduino code seems to have been taken down…? I couldn’t find it.
Yes, it is still missing from OpenLung. And I wonder why the MIT team doesn’t share the code. Maybe they worry about liability — but we will anyway have to do on our testing depending on location. Surely someone on the planet has posted Arduino code!
I may be way off but thought I would throw this out for an “outside the box” thought.
I have a varied background so please bare with me.
Tool and Die Engineer,CNC Machinist,Mobile Audio Electronics Tech.,3D Animation/Instructor,Computer Technician
I was thinking if you got rid of the motor, gears, claws, all the mechanical pretty much, and just put the bag in a box, and triggered a air valve to pressurize the box, squeezing the bag, would be less parts, and simpler, easier on the bag.
Sure the technician cant grab the bag if the machine fails, but they cant do that with a real machine either.
Its a quick disconnect at the hose and connect the AMBU bag, seconds of time.
I don’t know if you were measuring tidal volume on the output or not at all, but it could be measured easier this way I would think.
Also you could get rid of a bunch of the hardware if you used software instead, I am basing this on the use of SideFX software’s Houdini, you could use inputs and output to the channel operators(CHOPs) monitoring wave forms, and setting trigger points…..and then in the software you can quickly build a user interface so the technician has simple visual controls and readouts. Rubs on any PC, Even better Linux.
Would get rid of half the hardware you are using.
what do you think of this design ,I totally agree with you that the Jaws of claws is a little too much over Engineering , the design should be as simple as possible with the fewest moving parts.
I think the fluid control requirements to limit overpressure, transients associated with velocity pressure, and exhaust to occur within the short cycle time could prove problematic and dangerous, not to mention the fact that you’d need to have a medically clean source of compressed air in the event the bag breaks AND to prevent damaging oils from making contact with the bag.
Further, you’d need to have a sufficiently strong container to prevent leaks from this ongoing cycling. Depending on what materials make sense, fatigue and seal lives need to be considered.
Using water might be a bit more plausible, but again pressure control and high flow requirements could make this untenable.
A simple mechanism as originally specified literally mimicks the human hand for which, obviously, these bags have been tested and perfected.
It also makes troubleshooting vastly easier as all parts are visible and can be observed working.
Not saying this is a bad idea, just throwing out the additional potential problems which might not be obvious on first glance.
Justin, can you share the type of filter you use in your model? Great work, by te way.
For pressure sensing, how about using a cheap MEMS barometer. They are very accurate and have an appropriate pressure range. Digikey has stock of 37K of this one right now:
I am building a multi channel active pressure control system for a machine at my work right now using similar sensors from ST.
Ooops sorry posted on wrong thing 🙂
They are absolute sensors so to get true lung pressure you would need an extra one to measure ambient pressure. But in quantity they are less than $2 so this should not be hard to do. These sensors are digital out by I2C or SPI. There are typically no mechanical ports but I designed a small machined part to seal around the sensor on the PCB with an o ring and allow a tube fitting to connect to it.
Anyone know how the pressure sensor port works on one of the bag units? Is there a piece of silicone tubing that comes off to go to a sensor? Or is there an embedded sensor in the tube?
The Ambu bag has a small nipple/barb/press-on tube port. This is only a location to attach tubing to sensors, it doesn’t sense or digitize anything for you. As for ambient pressure, a differential pressure sensor can be used to compare the patient pressure to the ambient pressure. Two sensors should also work. Part of the Open-Source goal is for people like you to find cheap, source-able solutions. Thanks!
Problem with absolute sensor is their measurement range which is big (e.g. 2 bars) and the poor resolution you will get in the target range of the application, which is pretty small (+/-100mbar at 1bar = 200 mbar range).
Thanks to all for your hard work. Is the full design that is currently in testing available? Would love to get a prototype going.
have you considered using the cubic_7500E or something like that? This is an ultrasonic oxygen sensor also has an (analog) 0-5V output proportional to the flow, so with a single sensor it is possible to measure the flow and the percentage of O2, quite cheap and works very well.
I would like to suggest you add a UD1006FR diode or similar, between the 12v voltage output and the H-bridge, and filter on the cathode of the diode, not before. I have often seen the 7805 controller break due to the switching spikes. By placing a second diode (like the previous one) where the anode is grounded and the cathode connected to the cathode of the first, the recirculation of the extra current is ensured. And the masses of power close, close, close to bridge H. I have been designing circuits for years and I allow myself to make my small contribution.
A Covid-19 patient who exhales air through the respirator could also inject the viruses into the outgoing air.
I am aware of various studies, including your MIT university, according to which the ultraviolet rays UVC at 222 – 264 nm manage to break the RNA of bacteria and viruses. The idea could be to convey the patient’s outgoing air into a tube connected to a sanitization box, make a approx 30x30x30 cm box with a forced labyrinth that maximizes air transition time with the aim of allowing the longest exposure time to UVC rays.
Congratulations on your work.
this is the prototipe made by a startup near my town…
very nice design
like e-vent, but i don’t think they are measuring pressure…
Now i builking a uvc box killer for exhaust air take from mechanical respirator to clean ari at 100%. Do you think it could be useful to prevent the patient from breathing the air infected by Covid19 and at the same time that medical personnel can breathe the uncontaminated air? Effect of UVC 254 nm is studied for several years with proven efficacy.
I am not sure if this is the right place to post this, but in consideration of the designs, there is an open request from Ardunio on conserving hardware. I urge everyone in development to consider others. There is a Call on April 2nd to talk about it, I hope this team has a representative.
Thanks for info, I’ll be there!
Buen dia… alguien me podria facilitar el codigo que estan implementando en el arduino? Mi correo ez firstname.lastname@example.org gracias quedo atento.
My company, Robot Power, makes the Arduino-mounted H-bridge motor control that is pictured on the front page diagram for this project. We are recommending our MegaMoto Plus unit.
We are surging production of these units to support this project up to several thousand units per week. We are offering them for a discounted price as well. If you are interested in building one or two units please order through our Web store. If you are building hundreds or thousands of these ventilators using our MegaMoto Plus please contact me. chris – at – robotpower dot com
We are extremely busy and cannot help you with code issues or Arduino development issues. Please seek help online for those issues.
And does you have any experience with regulatory approval? Indirect or direct. Thanks.
What about monitoring the phrenic nerve impulses to the diaphragm? (simple 1 channel EMG)
Could be useful for monitoring patients fighting the vent, or even as a method to control the ventilator?
(For Patients without induced paralysis for intubation)
or alternatively deriving required respiration from ECG heart data or sats monitor?
Iam working on developing the code for adruino and have a question on the math. IE mentioned in the calculation is the ratio of Tin/ Tex . Based on the formula Tin > Tex. My understanding is the Tin <TEx with ratios from 1:2 to 1:4.
If my understanding is correct IE should be E/I which will bring the Tin <Tex.
Any clarifications are highly appreciated.
There was an error in the equations for the inspiration and expiration time on the Controls page of the E-Vent website. I believe that the correct equations are
Tin=T * IE / (1+IE)
Tex=T * 1/ (1+IE)
To verify these equations, calculate their sum and ratio: Tin+Tex=T * (IE+1)/(1+IE)=T and Tin/Tex=IE
Thank you for adding this explanation, but this is incorrect.
The confusion might have been caused by the use of IE in our expressions. IE is x when 1:x = I/E. We have added a note explaining that on the page above.
Your understanding I.e…”understanding is the Tin <TEx with ratios from 1:2 to 1:4." is correct but ratio will b the sam as I:E varying from 1:2 to 1:4 ONLY .Kindly link some graphs for IE wrt time which will also clarify.
1) STATUS LEDs
One idea : adding two 10mm LEDs
– One red alarm LED
– One white OK LED (when there is power and the system is active)
Reason : If there are multiple ventilators in a room, having these big indicators will allow to easily see, from a distance, which ventilator is in alarm (if any), and check visually from a distance that there is no major issue (lack of power or other)
The white LED can be made to pulse at every breath (always lit if system is active, except one 250ms dark pulse at the beginning of each inhalation/exhalation for instance), this acts as a system heartbeat.
Reason for not using a green LED : because it implies everything is OK, including the settings. The purpose of the white LED is just to show there is power and the system is active, not that everything (settings) is OK. Using a green LED may cause operators to be complacent and just check the LED.
LEDs need to be diffused so they can be seen from any angle (no “high brightness” clear LEDs, very bright but only from a narrow angle).
Also LEDs need to be separate (no RGB LED), there are colorblind doctors, I’ve seen that first hand.
Too complex ? At least add a red LED in parallel with the buzzer.
I like the availability of the ATmega328P microcontroller chip on DigiKey, etc, however I do have a concern on its ability to do all this checking of buttons state, while serial writing (I assume) to the LCD, while also doing near real time control (maybe linear PID control?) of the airway pressure vs “finger” angle. This last part, the near real time control needs a very fast sampling rate with little noise from the pressure sensor, and may bog down the system thus preventing the system from doing anything else effectively. You may want to consider a microcontroller for the UI and a separate on for the pressure control, while having them talk to each other.
Have we successfully accomplished the 2nd type of control, in where one follows the breath and assists the patient? I worry this will be hard to accomplish.
The arduino software offers a polling scheduler which is not meant for hard real time purposes .
In fact Altair offers a free tool called the embed basic which offers auto code generation and also the ability to schedule using on chip timers and also manage interrupts, state machines, multiple software derived rates for different pieces of code .. Etc. And most importantly helps debug the code running in the micro through a serial interface in an idle loop.
Would be glad to help put up a quick diagram and help with this.
Yes I work on that approach and would be the easiest and fast way to get the control side done .
Initially I was thinking about using PM FOC sensorless, but I note that there will be periods where the rotor is locked, so that can cause issues, with PM or hybrid steppers (no EMF at standstill)
A good alternative is to use an induction machine, running FOC with FAST as we have it in Altair Embed running for example a TI 069M MCU with a suitable platform, that can handle the motor controller. Challenge is to find a small IM like my TI EMsynergy motor, but that is out of production. Maybe someone has an induction motor that can fit that MIT setup.
Happy to help set this up if needed.
Hard real time on Arduino (and on microcontrollers of this type in general) is implemented in interrupts, often timer interrupts, and it is possible to guarantee a certain degree of real time performance if required.
These microcontrollers are very deterministic due to their simplicity.
Not saying your approach is not good, but clearly there is no problem in doing real-time stuff with Arduino code.
The quantities needed are very large. The world is at a stand still. Existing stock piles must be used. The design must be partitioned and specified to be modular rather than monolithic. That way individual companies can work on smaller chunks and change their modules without changing electrical interfaces and S/W. This also eases acceptance by US authorities, and simplifies proving. I see MIT with all its medical contacts morphing to a design acceptance role. Industry works on funding, not volunteers. Infrastructure needs to be set up to fund this work. The US now has massive COVID-19 funds backed by authority to get teams ‘going’ instantly.
(I am a member of an “off the shelf design team” within a US multinational design/manufacturing company. This Tightly knit and proven team of S/W, MechE, EE and Project management are making a suite of items with stepper motors, electronics, RaspberryPi’s, sheet metal and plastics. Adjacent engineers have worked with, and have contacts in the automotive industry which may solve the motor supply. A dual redundant design may be more readily accepted.
Paul Riddoch B.A. M.A. Oxon)
Hi Paul Riddoch,
Your work sounds on point, very good! I would love to help out where I can. Please loop me in.
I am a Senior Mechanical Reliability Engineer with a background in Mechatronics. I am happy to help any way I can, including manufacturing, reliability testing, rapid prototyping, etc.
Thanks Ben may be useful. The partition I am looking for is to have a shaft coupler between the motor and the rest of the system and a generic electrical interface/connector conveying parameters “direction” “step” “shaft position” “version” and red STOP button to kill power. All GPIO except STOP. We optocouple the GPIO. Then consider all the stepper motors/gears “in the world” big enough to drive the system (>15Nm? 60W?) and buy some. To keep things simple the position encoding could be a limit switch only. The stepper motor contollers I use are Trinamic, so I would look to buying/cloning these. This approach could be scrubbed by a design team Monday, with parts arriving before the end of the week. Proceeding at risk to save time.
The stepper would be reversible once power is cut by the red button. The motor power supply would be included in this motor module. Metal cradles with the supplies/motor/controller would be fabricated for each variant of motor to a standard mechanical interface specification. (Week long)1 millon cycle proving being accelerated by getting the motor to work at faster cycles and higher loads. This way any motor module fits any vent module. A third of the design is delegated for mass production, next week.
Sounds like a good plan!
Please message me directly on LinkedIn to discuss how I specifically can help. I want to ensure we are being effective with our time since it’s very limited right now.
I was thinking in the same line of thoughts. Is DC motor control with encoder loop and feedback really required here? using an appropriate size stepper/driver with just count and constant velocity command should be sufficient, considering the jaws of the gripper speed should not be extremely high and realistically almost no inertia load (since Ambu is resisting force) for it to overshoot. And even if it overshoots by few counts, at a new cycle it would be homed with limit-switch and the count reset to zero. Thoughts ??
I see “Raspberry Pi”, it gives me shivers, for a medical-grade system, considering how people generally use these things.
Please, if anyone decides to use this, please, make sure the SD card is mounted read-only and the watchdog timer is enabled and used properly (reset in the highest application level possible to detect crashes everywhere in the software stack).
And preferably, put the entire system in an initrd (read from the SD card once and then ran from RAM). This can be done with buildroot, I’ve done it before, and it gives the system a higher reliability, at the cost of needing more skills during the development.
Bertrand, do you have a reference link for how the RPi can be configured to read from SD card once, then only run from RAM?
We have a prototype of the first control function that is to provide cycling control of the ventilator. Now we are working on the assist mode on the ventilator. This design is using an differential approach of the airway pressure. We are considering using a 3 sample with a known sample time ( let say 15 ms) and detect the pressure difference. If 2 of 3 pressures are -ve then we consider it as inspiratory mode and vice versa if +ve this will be expiratory mode. Currently in talks with some doctors and some bio designers to verify if the assumptions are correct.
A solution for the drive would to use hybrid stepper, running of a three-phase converter, sensorless FOC using an 069 and FAST as shown in my third Springer book ‘Applied Control of Electrical Drives’. You do not need torque at standstill I assume. So start-up with DC injection to align the flux vector and estimate the stator resistance. YOu can use on of the
TI board, eq GANINV board with Lauchpad and I use Altair Embed to generate the code.
Let me know if you more help, good luck Duco
ps currently in Holland.
Note my later comment (reply my colleague Prof Mohan): where I suggest the use of an induction machine running FOC sensorless with TI FAST on an Altair Embed real-time embedded control platform.
Duco W. J. Pulle
Is there a location where we can get access to the source code?
Currently there is some conflicting information. The “Minimal electrical hardware architecture” page suggests the use of a driver with position and speed control while the schematic suggests hooking the encoder straight into the arduino. I agree that having the MCU handle as little as possible is a good idea, but due to the limited availability of controllers I’m wondering if the intention is for the design to be flexible enough to work either way.
Hi. I was wondering if a scuba tank with regulator and soneloid valves could do the same job as the michanical actuator and bag?
I was thinking of attempting a design based on compressed air and bottled oxygen, but one major hurdle for an approach that uses compressed gas is that it is completely dry, so it has to get humidified and warmed before being put into a lung (expansion of the gas from high pressure to lung pressure cools it down). The warming part would be easy but the humidity part seems difficult. Don’t need scuba tanks since from what I understand most hospitals have house compressed air. I guess it is ok for scuba for the air to be dry since you are only breathing it for an hour or two, but for a sick person to be on it for a 24/7 for a week maybe it is a problem. On the other hand if too much fluid in the lungs is a typical issue with covid patients, maybe dry gas is a benefit?
Nice work thus far! I’m curious: have you already completed a HARA and FMEDA for this project? I know that there are some complex limitations on the design of this project (particularly with regard to use of materials, etc.) but I’m seeing a great deal of speculation in comments about “the best components to use,” etc. – and it would be great to have some hard guidance that drives decision-making around these kinds of things. When I hear “use a Teensy” over “use a readily-available safety MCU,” or optimization for memory constraints over safety, that’s when I tend to get worried.
If you do intend to release some board designs that move away from Arduinos, you might consider the TI Hercules line of safety MCUs. There are some extremely affordable variants in that line (~$5). Pairing it with something like an ASIL-D PMIC (like the TPS65919) might allow you to at least bring the processing side of the design to ASIL-D/SIL4 equivalent.
I’m sure your team is absolutely slammed. Thanks for doing all of this – it is extremely important work.
1 – This system has been described as transportable, for example moved with a patient on the way to surgery. The use of a brushed DC motor is not suitable in environments with anesthesia gasses.
2 – The AC power source pictures a ATX compliant power supply. These are likely to exhibit leakage currents far in excess of patient safety standards. At a minimum it would be necessary to use an isolation transformer on the AC mains in such an approach.
3 – As noted by others, a potentiometer is not suitable for angle measurement on the finger assembly; use an optical encoder. A pot is reasonable for low cost operator control.
4 – The mode selection switch should be DPDT with 2 bits generated to indicate the switch state: “01” for volume and “10” for assist mode. The “00” and “11” states should not exist steady state and would be a fault condition. Rational: a single open circuit fault would determine the operating mode. Similar for short circuit fault. The same argument can be made for the limit switches.
5 – The pressure transducer is located out near the patient. There will be galvanic connections in that area to bring the measurements back to the controller. An opto-isolated I2C link and a isolating DC to DC power source, rated at milliwatts, to remotely power the sensor might be appropriate. Guard against fluid spills at this transducer.
6 – ESD protection at the operator interface is reasonable. A static discharge at an operator pot will have direct access to the controller.
7 – Motor induced transients on the power (is it 12 V?) should not be suppressed by a 2000 UF capacitor. This capacitor would need a high voltage working voltage to provide a long life. The micro controller will be low power and and we could afford an R-C and TVS stage with a much smaller C. The big capacitor lives back in the power supply, and won’t help with the motor transients. The capacitor at the input to the linear 5V regulator should be chosen to optimize that regulator. A small R in series with a ferrite are possible solutions.
7 – This is described as a feedback control system. What is the minimum sampling rate necessary to achieve the desired degree of compliance with the scheduled respiratory waveform? My approach to this question: A waveform with a particular 150 ms feature (plateau pressure) might be crudely represented with a closed-loop system whose step response is 15 ms. Using a rule of thumb this means closed-loop BW = 0.35/0.015 = 23 Hz. Neglecting transport lag, this means a sample system of 46 Hz at a minimum. However transport lag cannot be overlooked.
This implies that the software controller loop needs to be responsive at significantly better than a 46 Hz rate; if it were able to support 500 Hz I would relax this concern.
Some very good remarks here !
Out of curiosity, what is the problem with brushed DC motors ? Sparks ? Are some anesthesia gasses flammable ?
Can’t find another place to put this:
Waiting for final plans is costly
As for what a difference a day makes –
3/31/2020 US Dead
587 dead in 10 hours
about ONE dead every minute
To save more lives please give potential manufacturers lead time between then and now to learn and do their own planning.
Jonathan E. Jaffe, MS/OTM
should have been
Great progress MIT – keep up the effort!
– controller could use a red LED light to flash when an alarm goes off, so ICU personnel can tell which unit has an alert if several are being used in the same area.
– motor and encoder need a temperature sensor, and a fan to cool if temp is measured outside desired parameters. Current NYC reports indicate ICU patients are often on a vent for up to 2 weeks, requiring a high endurance design.
– controller should have a persistent timer on board, so hours of use can be measured. May be useful for filter changes, measuring unit durability, and periodic maintenance.
Has anyone considered using a second arduino with a dumb industrial motor driver to handle the speed and position PID. This the benefit of being massively available and well documented, and available compared to the roboclaw or any motor controler with the required level of sophistication.
Electrical/ Controls Architecture:
I recently joined and so gathering all the info contributed by everyone. I take it MIT team has not released as build prototype compete design package? few questions if someone can help entertain:
– I see the mechanical finger mechanism autocad drawings posted on the site but does not show any location on the gripper where to install the home limit-switch.
– There’s an high-level electrical diagram that shows component selection to support the Ventilator’s functionality. It does not have BOM with vendor and cat#. Any guess on what spec on the differential pressure transducer (why differential?) , if just voltage output or I2C interface? what’s the purpose of the angle pot if the suggested motor control architecture is encoder with PID with a home limit switch ?
– Is a encoder feedback absolute necessary, perhaps it is if using DC motor with PWM speed control. if one employs simple stepper motor with counts and velocity command, it should work but perhaps with not very high accuracy, but is that level of high accuracy required ? the motor should not need to run at any high velocity, based on the BPM range and even if it overshoots by few steps it should not matter since due to the gear ratio of the gripper the error in distance should be very small. So the error does not propagate with every cycle, motor can be brought back to home with aid of limit switch and counter reset. Any thoughts ??
– I suppose software algorithm calculates the tidal volume of the inhale using a lookup table based on the Ambu bag air output flow rate curve for given pressure reading feedback through the transducer which should correspond to the velocity set for the motor ?? if that’s the case, different Ambu bags should have slightly different characteristics and have different lookup table ??
Any thoughts/feedback would be appreciated.
Great project! Can I suggest the addition of a ventilation timer in case the system fails and the clinician needs to revert to “hand bagging” the patient? For example, the user can input the desired ventilation rate onto the screen using the selector knobs (default 10 breaths per minute with range of 6-24 for example) and there can be visual and/or auditory feedback using the built-in buzzer and LED to alert the bagging clinic when to provide the breath.
Another easy addition would be a “code mode” for cardiac arrest. This can be one LED providing guidance for CPR compressions at a rate of 110/minute and another LED acting as the respiratory timer as described above. This can be quickly activated with the push of a button in the event of a cardiac arrest.
Any feedback would be appreciated, thanks!
It seems that the most likely unit to fail will be the code inside the arduino. If the motor and mechanics are over-provisioned they should not fail. Likewise the motor controller is very unlikely to fail or loose position, specially if it is completed with limit switches. . So, I can envision a board-shield for two arduino micro or similar small form factor interface. A watchdog could change the control from arduino one to two. That would provide an extra layer of protection, considering that an micro is, depending on the source, 3-25 usd.
Hi, I have few comments to make about the development of this machine.
First are some recommendations based on my own experience in industrial machine design and machine safety:
1. The main ON/OFF switch, if any, should be a flat push button so that it can’t be accidently actuated (during patient transfer to different area for instance). This button could also embed a white light to indicate that machine is ON as well as the machine state (blinking at different rate and pulse duration)
2. 2 types of users are at risk:
• Patient : As already identified, a device error/malfunction can lead to death or serious damage.
• Operator : Nobody talked about it but the operator can have his hand pinched by the robot fingers. Calculation gives 5kg pressure per robot finger, so a 10kg pinching. With x2 security factors used and depending on the power supply used, we could get more than 20kg at stall condition. That’s enough to crush a human finger badly enough so that he starts thinking about suing… and motion is not that slow.
3. Here are few scenarios and their solutions:
• Scenario 1: operator needs to securely and quickly disconnect the device from the patient: Solution: nothing to do. No need to stop the motor. The mask or tube can be removed from the patient directly
• Scenario 2: operator needs to switch to manual handling of a bag
– Solution 1: As mentioned already, place another spare bag close to the machine, so no need to stop the motor. Best solution for me.
– Solution 2: Reuse the bag installed on the machine. In this case, the mechanical power must be switched off for operator safety and motor backdriving. An emergency stop can be used to cut mechanical power.
• Scenario 3: operator needs to access the moving part to install a new bag or to remove a bag
– Solution: Use an emergency stop to cut mechanical power and install a safety barrier, preventing access to moving parts with a position switch detecting that the barrier is closed. It can then be chained with the emergency stop. Once the barrier is opened, it cut mechanical power. This barrier can be a simple acrylic U-shaped cover plate placed above the moving part. This cover could be attached with a hinge on one side and secured with a lock on the other side. It could also have a handle on top for carrying the device
– Complementary solution: limit motor current on driver settings so that we only have 10-15kg pinching force, no more.
• Scenario 4: a machine fault occurs triggering a warning or an alarm. Alarm should cut the mechanical power. Thus, an alarm output from the Arduino should attack a relay being put in series with the barrier safety switch and the emergency stop.
4. We only need to cut mechanical power here, not the whole system electrical power. As we are working with safety voltage 12V, nobody can be badly electrified. Then no need to switch off the digital part of the electronics (especially the Arduino…) which is preferable in order not to lose machine state, communication with computer etc… Mechanical power can be removed by switching off the motor driver. If the driver is a controller with 2 separate power supply (1 for logic, 1 for power), then only switch off motor power supply.
5. The presence of mechanical power should be highlighted with a light indicator (orange). It could also be retrieved by Arduino (using a voltage divider converting the +12V to +5V) to update the machine state.
6. To summarize the safety loop, the Emergency Stop push button, the barrier switch, and the alarm relay should have 1 contact set be put in series to switch on/off the motor driver power supply.
7. Fuse need to be installed, especially if working with a car battery which can create dangerous electrical arc and spark.
I agree with you. They need to perform a Safety Risk Assessment for this “machine” per OSHA and CE requirements . Based on the Safety Category, B, 1, 2, 3 or 4, that would dictate the safety circuits to be used. Based on the pictures that I see posted, the torque rating for the motor, plus the mechanical grip design , it appears that one could have a serious injury.
1. Perform a safety risk assessment ( contact a safety company like Pilz or Schmersal for help)
2. I do not think you need a E-Stop button
3. I would recommend to ( as you mentioned) install clear plexyglass guard
4. Install a Safety Swich on this guard. Safety switch must be of the positive type guidance, another words it cannot rely on a spring to open a circuit.
5, Depending on the Safety Category, you may have to add a safet relay ( safety rated)
6.If the Safety category is 2 or higher youl will require safety switch with redundant contacts
7. when opening guard, the safety circuit ( to be determined) will indicate ( hard wired to Controller digital input) ” guard open” on the display
8. The ” other ” safety contact ( from safety relay) should be wired to disconnect power to the motor
9. Do not disconnect power to the controller or anything else. Only the motor. Make sure that it can be done.
10. This is a “simple” machine , in other words , i do not believe that there is a chance for amputation. If there is, you may have to have a solenoid lockable switch guard.
11. Reiterating your comment, the safety switch ( or even E-Stop) contacts have to be protected by fuse or circuit breaker ( depending on the contacf ratings) in order to keep safety integrety
12. If the grip mechanism is designed ( mechanically) in such way that it is impossible to have a pinch or amputation point, ( everything is possible) then it would save a lot of money and aggravation.
Regarding machine functionalities and development priorities:
8. I would limit current development to functionalities that are only essential to the basic process (an automated ventilator) and do my best to make this robust.
9. I would forget connectivity/networking and other fancy features for now which are not essential to the process. These increase the machine complexity and development time. For now, medical staff in hospital is outnumbered and I am pretty sure they don’t care about this feature. What they want is a quickstart ventilator, simple and easy to handle in less than 5min. Have a look at french hospitals which are completely outnumbered. They don’t have time for fancy stuff. They want something which replaces their hand to handle a bag, not an ioT robot
10. The goal of this project (I think) is to have people in every country being able to replicate, build and produce this machine. With that in mind, care must be taken to carefully choose each component so that it is easily available in all countries (significant stock, delivery possible to most countries), especially the motor, motor driver, and the pressure sensor. Current confinement of some countries does not help.
Few words about my situation:
11. I live in French Polynesia, a big country of the size of Europe but lost in the middle of the Pacific Ocean and made of hundred of very small islands scattered all over the country. We have only 250000 inhabitants, 150000 are on Tahiti the main island and the others are disseminated in the other islands. Most of these islands counts around 1000 inhabitants with 1 nurse or 1 doctor, are only accessible by boat every 2 weeks and do not have internet access.
12. Me and my team would like to produce some ventilators to tackle the shortage we will face soon. Our country is currently under confinement. All external flight and freight are stopped and we will have to figure out how to import all the electronics components (our local small electronics shop only have the really basics (potentiometers, resistance, capacity, etc), no motors, no Arduino…).
13. Part of those ventilators will be for those remote islands having only 1 nurse or 1 doctor. I am pretty sure these users will not care about using their smartphone or a computer to retrieve data, because first they might not be really tech aware (or simply have a smartphone or a computer), and secondly because they will not have the time to do that while 20 patients will be waiting for them out there to get medical assistance.
Regarding the Honeywell pressure sensor:
14. Are we speaking about the SSCDRRV100MDAA5 – PRESSURE SENSOR, DIFF, 100MBAR, 5VDC ? Could you confirm please? That model is interesting since it is available with analog output, not only SPI. However, there is only very low volume available and it is out of stock right now at Farnell New Zealand. Also, I couldn’t find any other sensor having the same required features. For me, this is a major issue since no sensor means no machine to produce.
Regarding the Arduino software:
15. Would be good to have a software kept simple enough to leave it accessible to non-advanced software engineer so that they can more easily adapt the code if required (for instance to suit the needs for components replacement, as people might be limited to what they find locally).
I would like to suggest yet another development platform – Mbed. There are many brands of boards to choose from, see: https://os.mbed.com/platforms/
I consider the codes very portable between boards. Chances are you only need to change the hardware pins in the software. Like this, there is lesser chance of encountering out of stock situation.
It comes with rtos and well used libraries. Very easy to learn with many examples. Some boards can even support arduino shields, like nucleo boards by stm.
Can anyone provide Arduino code or has Medtronic code been converted? Call, text or email email@example.com (775) 762-4802
Did you manage to get the Arduino code? if yes, can you please forward to firstname.lastname@example.org Thanks
Same here. I’m working with very resourced Afghanistan and an Arduino unit would probably be ideal. (They are used to using the computer boards used in FIRST Robotics competitions.) Could you please forward to me the Arduino code?
I’m at: email@example.com
Many thanks. This is a fantastic effort.
Hey guys great work!
We are still waiting on a BOM. Part #s would be great that way we can get data sheets and find alternative parts if needed. Also Arduino code would be great lot of people have prototypes complete but are still working on code
or waiting for it.
great work you’re doing on this project, I’m really excited for the end result!
One question though: In Controls&Electrial>Controls you write that Tin = T / (1 + IE) but shouldn’t it be Tin = T * IE / (1 + IE) ?
Maybe just a typo or I’m wrong, just wanted to ask.
Good catch! In the limit IE->0, Tin should go to 0 but it does not with Tin=T/(1+IE).
It looks like the correct equations are
Tin/Tex=IE and Tin+Tex=T(IE+1)/(1+IE)=1
I am an FAE for Arrow Electronics in Boston.
I am trying to address the critical shortage on the Honeywell SSCDRRV100MDAA5 pressure sensor that is apparently specified for the E-Vent application and looking for alternatives.
Can someone confirm exact, minimal features required for this application?
Does an alternative sensor need to have the exact requirements as the SSCDRRV100MDAA5? Where can design trade-offs be made?
1) Pressure type – Differential?
2) Signal Output – SPI, I2C or Analog out?
3) Pressure range – 1 psi to 150 psi (60 mbar to 10 bar)
4) Supply Voltage – 3.3V, 5V, other?
5) PKG – DIP, SIP, SMP
There is a sensor series, MS4525 from Measurement Specialties, Inc, a TE Connectivity Co, which is a similar sensor series to the HW SSC, but has variations in specs and is not drop-in replaceable, i.e. pinout is different.
PCB Mounted Pressure Transducers
Amplified Ratiometric Analog Output
Differential, Gage, Absolute, Compound, &
3.3 or 5.0 VDC Supply Voltage
I am also looking at NXP, Amphenol and ST Micro. If you can shoot me the specific pressure sensor requirements for the E-Vent application, I will be glad to continue the investigation.
I’ve noticed the commercial Medtronics uses a combination of absolute and differential sensors:
BSDX0811-BARO and ASDX001D44R
The differential sensor has 0-1psi range which seems to be adequate for them but 2 sensors pushes the price up. I’m hopeful there are other methods that can be used to allow for other sensors.
The Arduino UNO has an onboard regulator, and takes a 7-12VDC input. Why does the circuit diagram include a voltage regulator to provide power to the UNO?
I want to clarify: I realize that isolation between the UNO and the motor is important, but there must be a better way to do that than to supply a board requiring 7-12V with a regulator that provides 5V. One simple change would be to use an 8V regulator such as the LF80ABDT-TR.
Has anyone written code for Arduino? refer to Circuit Diagram shared by MIT E-Vent team at https://e-vent.mit.edu/wp-content/uploads/2020/03/controls-schematic-arduino-hbridge-1536×1058.png
I’m debugging my attempt at the arduino firmware based on the diagram, control logic, and feedback from the forum. I hope to post this by tomorrow.
Excuse me I cannot find the codes for arduino, Iwill be delighted if you can help me to find it,
Does any body has a simulation model based o. MATLAB?
It seems to me that the pressure sensor could be either absolute, differential or gauge; the difference being measured is the difference between the expected PEEP and the actual PEEP.
I would suggest the following specifications for the pressure sensor:
* Absolute, differential or gauge pressure sensor
* Range of up to 1.5PSI (10 kPa). This is a 2x safety factor.
* Accuracy on the order of 0.007PSI (0.05 kPa), or 0.5%.
* Analog DC or I2C output
* 5VDC power supply
* Barbed or threaded input port (to prevent accidental disconnection from the manometer port)
Great news – Medtronics has open sourced their ventilator design. This could provide useful design ideas!
I saw the Thold, hold time, casually mentioned as 0.15s. Is this a constant fixed value that is used for 8BPM, IE = 1:1 all the way to 40BPM, IE = 1:4?
For the calculations, I express the IE ratio as E/I. 1:3 -> 3, for example.
T = 60/BPM
Tin = (T – Thold)*(1/(1 + IE))
Tex = (T – Thold)*(IE/(1 + IE))
Example: At 12 BPM, IE = 1:2
T = 5 s
Tin = 1.617 s
Tex = 3.233 s
Tin + Thold + Tex = 5.000 s
This makes more sense to me. Please let me know if I’ve missed anything.
Has anyone gone down the path of developing a temperature and humidity control component of this system? Some feedback from our pulmonary specialist colleagues suggest this is a critical feature. If this hasn’t been focused on, I can work with our team to develop something. Any thoughts? All the best, Eric
Hello, is there an estimated date for the published code?
Electrical & Controls architecture design.
There’s some deficiencies in the electrical design documentation released by the MIT team, perhaps because the final design and the code is not released yet and team is busy and hard at work.
The electrical hardware tab shows motor drive is “Motor Power” and the encoder is fed into the Arduino. This assumes Arduino is running the PID position profile algorithm. Further below in the description, it mention using RoboClaw controller which is position controller and H-bridge driver. Using RoboClaw would be a better choice for the architecture since it will not use up Arduino’s resource. Any comments ??
Also; since there’s just one pressure transducer used and no flow sensor, I’m assuming the tidal volume is calculated using lookup table based on the position of the mechanical gripper and by the amount the Ambu bag squeezed. If that is the case, each brand/type of Ambu bag will have it’s own look-up table. The table then would have a correlation between gripper position to air volume, and if the velocity is constant for each BPM the flow rate out of the bag should be linear. Again this logic is speculative since the final design and code has not been released. Any comments would be appreciated.
Usually, patients in ICU are on ventilators for 3-4 days. However, Covid19 patients are averaging 21 days on ventilator in ICU. It is a goal of e-vent to support 21 days of continuous operation?
My name is Nicole Bisimwa.
Can anyone provide to me Arduino code or has Medtronic code been converted? Call, text or email firstname.lastname@example.org (243) 975 150 5345 (whatsapp)
I have a suggested change to the controls that I am incorporating in the prototype that I am building based on the E-VENT design.
As another post has suggested, I am replacing the 3 control knobs (tidal volume, breath rate, I/E ratio) with a single knob, and one select button per setting. In addition to the Confirm button, I am adding a Cancel button. The procedure for changing a setting would be:
1) Push the select button for the setting to change. The LCD should indicate which setting has been selected, and the value of that setting.
2) Turn the adjust knob until the desired setting is displayed.
3) Repeat steps 1 and 2 for any other settings that need to change.
4) If the user decides to abandon the change, push the Cancel button. The LCD display should revert to the original setting values.
5) Once the user decides to use the displayed values, push the Confirm button. The LCD display should now display the new values in use.
It is important that the Mode Selection switch match the mode actually in use. This constraint will be violated when the software changes the mode in response to breathing attempts by the patient.
When the software automatically changes the mode from Volume Control to Breathing Assist or vice versa, I suggest that the following take place:
1) The alarm sounds and an alarm LED displays.
2) The LCD displays a warning about the change of mode.
3) The Silence button is disabled until the user has manually moved the mode selection switch to match the new mode.
4) If the user decides to revert to the original mode, the user then simply changes the mode selection switch.
Can anyone clarify what is meant by “loading” in the disclaimer “We have investigated and do NOT recommend stepper motors. They are very hard to control when loading changes.”?
I have created a development team based in Cape Town, South Africa and have been getting a design together over the past week or so. My focus is to try create something that is based on the work that is being completed here and that is a bit more Africa-centric in terms of having access to components, parts and manufacturing processes – obviously without losing anything on the reliability and medical requirements side of things.
I have a few questions/comments like I’d like to share and would appreciate any input available.
1 : Control of Tidal Volume, BPM and I:E
I haven’t seen the software proposed so perhaps this is covered, but I think it will be critical to manage these settings within the boundaries of a Minute Ventilation calculation.
From what I can see, a CV19 patient at rest should not need (or be forced to get) more than 10L of breath per minute at an absolute maximum.
If this is not checked once a Tidal Volume parameter is set with a BPM parameter then you could get a case where this Minute Ventilation amount is exceeded.
Say you were delivering 450ml Tidal Volume at 17 BPM you would have a calculated Minute Ventilation of 7.65L
If you took the BPM up to 30 then in theory you would be pumping 13.5L of air per minute into the lungs and this would be a big problem.
This is easy to manage if the calculations are checked whenever a setting is changed and must be included so that maximum values cannot be exceeded, obviously depending on the other settings.
This may be a bit more awkward to achieve though if normal 10K potentiometers are used as the adjusters as their rotated positions may not match the actual adjusted value.
2 : Plateau Pressure
From various sources it seems that Plateau Pressure is measured with the expiratory route temporarily blocked. This should also be measured around 0.5s after the end of the inspiration stroke.
This is from the MedScape website as an example (Some researchers have suggested that plateau pressures should be monitored as a means to prevent barotrauma in the patient with ARDS. Plateau pressures are measured at the end of the inspiratory phase of a ventilator-cycled tidal volume. The ventilator is programmed not to allow expiratory airflow at the end of the inspiration for a set time, typically half a second. The pressure measured to maintain this lack of expiratory airflow is the plateau pressure. Barotrauma is minimized when the plateau pressure is maintained at less than 30 cm water. – https://emedicine.medscape.com)
From what I can see in this design, there is no block of expiratory airflow and the BVM and the resuscitation valves do not prevent the patient lung pressure from immediately decreasing even if the bag is held closed.
I think that if this is the case, we should be careful and not label the reading as ‘Plateau Pressure’ as it is not actually correct.
But I am not a medical person so maybe I am misunderstanding this.
3 : Settings and Measurements and Watchdogs
I think it would be best if the system had different sets of components to set values to the set of components used to measure values.
I think I am going to have two separate LCD displays – one used to set the desired parameters and one used to measure specific parameters.
I am also looking at the solution architecture to see where it makes sense to have different (separate) hardware controlling or measuring something rather than sticking everything into one device.
This way I think we will be able to have well tested and reliable ‘modules’ and we can also have a watchdog system that can keep an eye on things a bit more accurately.
At the moment it feels like we have the wolf guarding the sheep having everything all in one processor.
I am thinking of having a Main Control (for the UIF and mainloop stuff with built in watchdog), a Breathing Controller (to control the motor and hence the Tidal Volume, I:E and BPM based on an i2c instruction to ‘breath at Volume x with BPM of y and I:E of a;b), a Pressure Reader (i2c interface that keeps a 200mS running average of the pressure) and a Watchdog Unit.
Anyway – I am not 100% fixed on this idea yet but it does appeal to my approach of ‘oversimplify things’.
I would appreciate feedback though on whether this approach makes a system less reliable or more reliable.
Apologies if some of the above have been covered already – I have tried to read through all the previous comments on the various pages but I may well have missed something.
Thanks very much – Ian
I’ve been working on my version of this ventilator for the last two weeks. I’m using a Siemens PLC, NEMA 34 stepper motor, and 1.45PSI pressure transducer. I have a few YouTube videos posted, and a link to my PLC code on my website.
Congrats! I think it’s the best solution to get something done fast, using a PLC. if I was going to build one and if I could, I wouod also use a PLC. to get something done quickly and super robust both software and hardware, its the best choice ( I think)
We need help finding a source for the pressure sensor and flow sensor do be shipped to the Philippines.
If you can assist please email me at Kmcqueen@ivfasiagroup.com
Topic: Optimization of alarms.
When using alarms in the medical ICU world, it usually helps the staff to immediately recognise, which type of device triggers the alarm and how serious the alarm is.
Therefore I’d recommend to design the alarm according IEC 60601-1-8. The standard describes requirements for different levels of alarms, including dB, Frequency, Duty Cycles and so on.
Instead of using the selected buzzer CEP-2260A from your BoM, I’d go directly with a model already designed according IEC 60601-1-8. That could also save you some headache, as some models directly include different alarm types.
One Model could be:
I also would consider the additional alarm LED, proposed before. If two units are operated directly beside each other a flashing LED gives a fast control, which one is the beeping one.
Also for the optical signals IEC 60601-1-8 gives some advice regarding the signals.
– Unfortunately the standard is not freely available:
– Some free information, maybe helpful: http://admin.altran.it/fileadmin/medias/IT.altran.it/Images/Publication/TechnologyReview/Technology_Review_n._8_-_Ottobre_2012_P.Sessa.pdf
Anecdotally I have heard of people having issues running uninterruptible power supplies off generators. I am wondering if anybody knows more and if this would particularly matter in a hospital or field hospital environment.
As of right now, the MIT Emergency Ventilator is designed to run on a 12-Voltage power supply. In certain situations, the ventilator can run off other power sources such as a car battery or motorcycle battery. Alternatively, it can also run off a UPS or generator, provided it produces clean sinusoidal power. If it does not, then a power adaptor with a line filter will be needed to generate the 12V power needed to run the ventilator.
is there any information accessible about the sensor’s manufacturer?
Hi Team, love the amazing work you are doing. I’ve recently posted an open source project for the Monitoring and Alerts of emergency ventilators. The concept is to make it easy for anyone creating an emergency ventilator to add simple remote monitoring and alerts. Project is available at https://www.ventmonitoring.com fro anyone interested.
In Volume control, to keep flow rate constant is it required to change the speed of motor at ceratin millisecond interval so that torque increases when pressure is rising? Or speed can be constant. Then how flow rate is constant when pressure is increasing?
In volume-controlled ventilation, flow is not necessarily always constant during the inspiratory cycle. Rather there are many ways in which the flow profile can be shaped. Using a square shaped flow profile, where flow is held constant, is harder on the motor, as the motor needs to accelerate rapidly in order to achieve the desired flow rate almost instantaneously. It is also important to note that the manual resuscitator bag’s unique geometry makes the relationship between motor velocity and flow rate not linear. This adds more complexity to the engineering problem of trying to hold the flow constant.
In order to achieve the desired inspiratory volume, while not stressing the motor beyond its capacity, or exceeding the desired peak airway pressure, a decelerating shaped flow profile may be optimal. In these profiles, the goal is to achieve the peak flow rate early in the inspiratory cycle, when the patient’s lung compliance is higher and airway pressure is lower.
The flow can then be reduced as the desired inspiratory volume is approached in order to refrain from exceeding a safe maximum airway pressure. In regards to the torque of the motor, it will have to increase as the flow is ramped up to, and maintaining, its maximum value. Then, as the flow rate is reduced during the latter part of inspiration, the velocity of the motor will begin to ramp down. Since the patient’s airway pressure is increasing during the entire inspiratory phase, the higher airway pressures in the latter part serve to aid the motor during the constant deceleration of the velocity toward zero at the final volume. This reduces the overall power required by the motor and can extend the lifetime of the mechanical system.
Is the homing position considered to be all the way closed or all the way open?
Hi – I believe that you have an error in how you handle Plateau Pressure.
Plateau Pressure is an end-inspiratory pressure measurement that is measured after the inspiration flow has effectively reached zero. This needs to be measured with the expiration route momentarily blocked and between 0.5 seconds and 1.0 seconds after the inspiration flow stops.
I do not have a medical background but this is what all my investigations are telling me. A google search for ‘what is plateau pressure” will yield some good youtube videos and numerous medical textbook excerpts explaining this.
At the moment I think there are two issues with how you handle plateau pressure.
1 : You don’t block the expiration route when you measure it (leaving the bag depressed does not stop expiration as the flapper valves on the resuscitation valves allow the expiration to pass immediately that the inspiration inflow stops.
2 : Your software adjusts the inspiration period to be shorter by the plateau hold time whereas actually the hold time should be part of the expiration time (as far as I can see).
Apologies if I have misunderstood the medical side or how you have implemented it – but at this stage it looks to me like there is an error.
Plateau Pressure seems to be an important value to monitor for ARDS patient treatment so I think it is worth just checking this.
The plateau pressure is considered to be part of the inspiratory phase because, during
the time at which the plateau pressure is measured, the elastic forces produced by the lungs
have not exceeded the airway pressure. Thus, the pressure measurement is taken before the
exhalation of gasses begins and is reflective of the actual pressure within the alveoli, which is
information that the peak pressure does not accurately reflect. Additionally, the exhalation port is still
closed during the period in which the plateau pressure is measured. Any puff of air that escapes
from the system during this time should be almost negligible. For these reasons though, the
inspiration time is considered to be equal to the upward slope, as well as the pause (point at
which plateau pressure is measured). If you would like more information on this topic as it
pertains to the E-Vent, please take a look at the “Bench Testing” page, which can be found under
the “Experiments & Results” tab on the website. Here you can see tests were performed where
the plateau pressure was measured using an inspiratory pause time of 0.1s. This 0.1s pause was
chosen arbitrarily and could be altered.
Is there constant pressure mode?
This ventilator is a volume control ventilator, which means that there is a set amount of air (tidal volume) given to the patient. As a result, the pressure, specifically the peak inspiratory pressure, will be variable in the patient. To find more information on the variables that can be controlled by the user, click on the “Controls and Electrical” tab at the top of the page (link: https://e-vent.mit.edu/controls/).
Hello All all of you are doing great job !!
I am working on Plateu pressure measurement using I2C honey weel transducer for pressure measurement and connecting Arduino uno controller. I am trying to sense plateu pressure. I tried with reepiration rate and I:E ratio and figure out the inspiration cycle end time if I took that reading from Transducer and took it as Plateu pressure is it ok? do i need to average Analog reading of pressure sensor ?
what is the use of limiting switch in mechanical part of your system and how it’s control motor
Comments are closed.