开云体育

Hey all, This is a demo of our current software design. v0.8 https://vimeo.com/411083157 It should be readily adaptable to the UF team's hardware design, for those who are following a similar approach. Our main focus is readability, adaptability for various sensors and valves, as well as aiming for an intuitive menu system. 75% Program Space 45% Dynamic Memory Highlights: sensor disconnect/reconnect support (still has some problems) alarm submenu, including muting alarms options submenu, including testing plateau pressure and calibration "Cancel/Confirm" validation for certain tasks What we are still missing use of a second BMP280 (we have analog pressure sensor support) Assisted breathing Flow measurement If anyone has any thoughts or concerns they would like to share, then we would like to hear them! Cheers, -Alex

Hi, It is worth a look at the UF site to see a bigger picture of the multiple ventilator projects in play. https://simulation.health.ufl.edu/technology-development/open-source-ventilator-project/ Even though our group is listed as a "Non-UF Affiliated Forum" best I can tell we are one of the primary contributors. Particularly Gordon, Ashhar, Jack and the many other people in this group that contributed, especially in the early days when the design was still in flux. Lots of interesting things on the UF site: Design specs. Map locations where volunteers (possibility associated with the UF project directly) are building ventilators. Interesting simulations to help understand ventilators and augmented reality concepts (I suspect the AR was developed before this project). Along with short videos of a number of different implementations of the ventilator. Tom, wb6b

Search OpenVent on thingiverse. German project using the infineon DPS310 Pressure Shield2GO pressure sensor. James

Hello everyone, looks like there's been some amazing work on this project. I just found out about it and I'm also new to Groups.io. I'm trying to get up to speed on this project and would like to contribute if I can find a way. I'm wondering where to find the physical design for the opensource vent. I've seen many posts about the code, and I found the code and wiring info on the github, but I haven't been able to find any schematics for the rest of the vent (tubing, valves, connectors) etc. Does this exist somewhere that I've missed? Thanks, Steve

FYI https://www.ft.com/content/5f393d77-8e5b-4a85-b647-416efbc575ec

This has been on my list for at least 48 hours and Zeeshan did such a MARVELOUS job documenting the excellent code from Marcelo that finally when I had nothing to do, I got to work on it. The attached is just a draft but it gets across most of the important stuff. hope it helps!!! Gordon

I would like to let more of the Amateur Radio world know of the huge volunteer effort that is behind the open-source ventilator development, and how amateur radio operators across the globe are contributing to the effort. I see it as another opportunity to demonstrate to the world the benefits of having skilled amateurs available to come forth in time of need. I do not want to slow down the effort, however, if I could get some key contact information to link to ARRL or IARU PR contacts, it could be the start on showing the world how valuable the hobby (and frequency allocations) can be. If this is off-topic. or not of interest, then let me know. Evan AC9TU PIO Lake County Illinois RACES/ARES Amateur Radio Club pio at races dor org

Gordon & other medical gurus out there. I got to think about a development program I was involved with back in the 70's.. A closed loop scuba system where we maintained a constant partial oxygen pressure and used a helium mix as inert component. Closed loop scuba are used by naval attack divers ( no bubbles), but they were in their basic form limited to a practical operational depth of about 33 ft due to the effect of pure oxygen (at about 60 ft it could be lethal in pure form). Thus the development of a close loop system with inert gas maintaining a set partial oxygen pressure and safely going beyond 60 ft. My question is would it not be a medical beneficial in some cases to use pure oxygen and recirculate. This as the reason for ventilating is after all poor lung function Air is only about 20% oxygen and the rest are inert gases. In the closed loop diving system they are using a Co2 scrubbing system (lime) and add oxygen as consumed and that is pretty simple to duplicate. Yes you will breathe the same volume as with air, but only use a small amount of oxygen and you will exhale carbon dioxide that needs to be removed. The side effect is that the scrubbing will add some heat that needs to be removed in a small air cooled heat exchanger. The ventilator that is being designed here will be the same. and the oxygen system would then be just an addition. From a design point it would be a simple mechanical system The ventilator routes the exhaled gas into a scrubber canister and from there into a bag that deflate and inflate as the ventilator goes about it's cycle. As you are consuming oxygen the volume in the bag will reduce and oxygen will be replenished through a mechanism similar to your toilet valve, but instead of a float just have an attachment to the bag. The bag is then connected to the ventilator inlet pumping mechanism. Thus, again are there any benefits for many of these patients to use 100% pure oxygen? Rolf K9DZT

This topic is dedicated to ask/answer questions related to the baseline code for documentation purpose. So far all we have is a bunch of videos in the following playlist. https://www.youtube.com/watch?v=gKr-EH8vHxM&list=PLtBsFN3o4c54h5fr7lDnGuZhvKIA5Fhd3 Luckily, we have more people stepping in to help. Over the weekend I will try to record more videos about the code architecture/organization.

I am a CPAPuser. Wondering if the technology would be simpler for many ventilator patients to use. Steve. KE7GO

The UF CSSALT OS-Vent team is considering interfacing with an Android UI. What are some expected problems with wireless connectivity?

I will continue maintaining the code that I have so far collaborating for at the following Fork: https://github.com/mvaranda/Open_Source_Ventilator Be free to grab updates from there. Notification for this group on off; If you need to contact me be free to email me to: mv_email AT yahoo DOT com Cheers, Marcelo

All: It seems like the liability issue is going to be a thorn in terms of getting this into the field. If a company produces the circuit board with all of the UI controls and "connection points" to the required sensors, valves, hoses, and other external parts, do you see that one company supplying all of the parts, or will they just sell "the box" and let the user supply their own external devices? If that's the case, does that lessen the "box" manufacturer's liability? If the vent doesn't have everything "hooked up" and distributed as a final, working, product but supplies all of the external components and sells it as a kit, does that less their liability? I assume that FDA is signing off on a complete unit. My fear is that no manufacturer is going to want to take on the liability for the final product. Jack, W8TEE

I've made a first pilot effort at adding "assisted ventilation" to my little ventilator at home, with a bit of code added to vent_slice() (see below) It is pretty crude, but it does indeed initiate an assisted breath (of sorts). Here is how it works: When measuring the pressure (only done at the end of a "slice" -- there are 20 of them in each respiratory cycle in my code) -- if that pressure goes below 2cm below atmospheric (and inspiratory_pause isn't active, just for simplicity of my code for this test) -- the code jumps the variable current_phase up all the way to the ending phase of the respiratory cycle. This causes the code to complete end-of-cycle calculations & displays, and move right into an INSPIRE sequence, forcing fresh gas into the patient. qui It worked -- I was easily able to intiate an assisted breath--- by doing the following. (CAUTION: many of us are using air compressors that literally are like little engines, with pistons and cylinders and rings and oil lubrication -- and the air coming out may have OIL etc in it -- you don't want to breathe that stuff if you can help it!!) Because I still have a breathing bag attached to my system (to simulate a patient) and I wasn't yet willing to take that off and breathe from that connection, I just quickly used a hand to occlude the bag entrance during an exhalation phase (I slowed the BPM to 10 to make my timing easier) and then sucked air out of the expiratory (pen) lawn sprinkler -- and got the system to recognize it, giving me a Serial.print of ***ASSISTED BREATH**** and moving right to the beginning of the respoiratory cycle and initiating an inspiration. Problems: it was too slow. I have a lot of code doing a lot of things AFTER the point at which I measured this, so the move toward assisting took >100 mSec. That could be speeded up I suspect to make this more useful! But it was a start and wanted to point out this possibility for the hardware that we now have. Gordon Full current code attached. void vent_slice(){ long now; float diffpressure[MAX_PHASES]; long differentialpressure; if (!vent_running){ alarm(ALARM_OFF); return; } now = millis(); if (next_slice > now){ // Serial.print("."); // With MAX_PHASES (number of slices to a ventilatory cycle) at 20, system printed 8 dots at resp rate of 28 // With MAX_PHASES (number of slices to a ventilatory cycle at 60.... did not print any dots MA -- unable to keep up. // So the maximum MAX_PHASES isn't that much.... return; } // Note that it may go through many times before it ever goes any further. // Zero the peak inspiratory pressure if this is our very first time // in this cycle. if(current_phase==0)peakinspiratorypressure=0; cut_off = MAX_PHASES - (MAX_PHASES * (ie_ratio))/(ie_ratio + 1); check_pressure_limits(); // check this at the end of every slice //we move to the next slice if (current_phase < cut_off){ pressure_on(); exLitersPerCycle = 0 ; // initalize for computations next exhalation } // During the expiratory phase we need to measure // 1) differential pressure across an obstruction // 2) compute the flow rate // 3) multiply by the time slice to get volume in that breath // 4) keep accumulating it. // 5) zero it out during inspirations. if (current_phase > cut_off){ pressure_off(); // we are in EXHALATIION // I have no idea what the proper constants are here..... diffpressure[current_phase] = ReadFlowPressureSensor(); #ifdef DELP-DISPLAY Serial.print ("Differential pressure: "); Serial.print (delP); Serial.print ("\n"); #endif // Now calculate the FLOW for that pressure difference: // The mlliseconds assigned to each slice is 60000l / ((long)beats_per_minute * (long)MAX_PHASES) // where 60000 l is (long) 60000 // so the SECONDS of each slice is float 60/( (float)beats_per_minute * (float)MAX_PHASES ) // and we use exLitersPerCycle to build up the expiredLiters per cycle as follows: exLitersPerCycle = exLitersPerCycle + ( CalculateInstantFlow() * 60 / ( (float) (beats_per_minute * MAX_PHASES)) ) ; // GLG -- Marcelo caught the erroneous PLUS sign where beats_per_minute wa supposed to be multiplied b

I first integrated a pressure sensor based on NXP 7002. Its analog values, once read from ADC, ranges from 0 to 613 (integer number). Someone provided a formula where those values are translated to -3.57 to 41.08 BANANAS. I mean BANANAS because one individual calls it cmH2O and a seconds InchH2O. Anyways... once I implemented the integration nobody questioned the values being displayed nor the alarm thresholds hardcoded to 4 for low and 35 for high BANANAS. Now we are up to replace NXP 7002 for pressure to a BMX280. In a normal world we KEEP THE SAME UNITIES. So my logical approach is to keep the very same -3.57 to 41.08 BANANAS range regardless the sensor we are using for PRESSURE (I am not talking about Flow sensor). Therefore, if there is any objection please step in and clarify. Thanks, MV which provides voltages that transpates to integer values