COSV - Cam Open Source Ventilator

Roller cam based portable BVM ventilator.

Similar projects worth following
COVID-19 sucks. Ventilators are needed.
This is our take for turning a bag-valve-mask (BVM) into a ventilator.

Compresses the bag much like a hand would to reduce the stress on it.

Simple/robust mechanism, a roller cam.

Active feedback is utilized to accurately provide most commercial ventilator modes, without the need for any specialty flow or differential pressure sensors via the VISP companion project.

The base unit laser cuts in 20-80 min, mills in 2 hours, or 3D prints in about 18-24 hours.

About $120 in parts for the mechanical bits.
Add another $100 for a local UI touchscreen display.

The parts are all interchangeable.

Files are up on GitHub.

Hardware is done until testing reveals issues with it.  

Source and rendered files are up on Github.  Laser cut files are here.  3D printable files are here.

So far you can use a BLDC gear motor, a small worm drive gear motor, or a Nema 23 stepper to drive this.

Torque requirement is 15-30 kg/cm and speed requirement is 22 to 30 rpm.

We need to deliver a faster inhale stroke than previously specified, so torque requirement is now 30 kg/cm and speed requirement is 48 rpm.  This may put it beyond what our (cheap) Nema 23 can do and probably puts my first pick for the BLDC out of the running as well.  The previous number for inhale time was 1.5s.  I picked the parts based on 1s.  The actual time from the UK document is now 0.3s.  Ooof.  Everything gets harder.

Electronics and sensing are sorted, but not completed.  Still missing some parts.

Software is in progress.  With the sensor stack in place, will be capable of assist ventilation, or static rate ventilation.

Pressure and volume delivered will be directly adjustable.  Maximum pressure will be configurable.  Maximum pressure should also likely be backed up by a physical pop-off valve.  We have a reliable 3D printed valve already developed for us.

MPEG-4 Video - 2.50 MB - 03/25/2020 at 19:55


  • Assembly and merge conflicts. :)

    Daren Schwenke11 hours ago 0 comments

    Attempted to assemble the latest revision of the hardware.  Most things 'worked'.

    I had no hope of it actually turning on here as I know I did not properly implement what @Steven.Carr had changed for the backend.  I had merge conflicts which I did not resolve and he is ahead of me.

    So here is the no net, back of my head, unpublished, unedited version of that experience.  Be kind..

    We did learn some things from this.  We are implementing them.

  • Minutiae

    Daren Schwenke05/18/2020 at 07:29 0 comments

    First off, using individual jumpers sucks.  This choice alone has probably cost me 20 hours of debugging time.  Some pin header ceases to fit perfectly and you partially lose ground, which makes things fail only when the majority of signals are above the halfway point between ground and Vcc as the the low going pulses also provide a partial ground.  Argh.

    Narrowing this down to the jumpers happened when everything finally got hand soldered directly, and all the strange issues happening during testing just went away.  

    Hand soldering wires still also sucks though.  So I have now specified pre-made IDC connectors and matching keyed sockets for all the internal connections.  

    I have also settled on using an RJ45 connection to our current #VISP - Ventilator Inline Sensor Package module which uses dual I2C, by splitting the four pairs of wires of the Cat 5.  

    One leg of the each of the four twisted pairs will run SDA1,SDC1,SDA2,SDC2 and the other half of those four pairs will run our Vcc/ground.  This seems to be a reliable way to get what we need for running dual I2C channels, out of an existing and robust connection like RJ45.  Much more so than trying to run the SDA/SCA on a single twisted pair anyway, as they essentially work against each other then as they are not intended to be halfsies of a differential signal.  :)  

    This also probably means generating two tiny daughterboards just to make our IDC to RJ45 jack connection, and to plug into our new optical interrupters, but so be it. Reliability is kinda key here.  Which leads me into the next design choice.

    Using unshielded hall effect sensors anywhere near a DC or stepper motor, unless they were designed for that particular motor, also sucks.

    They will read perfectly, until you start your motor (if you are lucky).  If you are not lucky, they may still read perfectly.. for a while.  Eventually though it seems they reach some saturation or auto-leveling point, and cease to work reliably until you remove the field generated by the motor/stepper.

    Our hall effect sensor for detecting 'home' got replaced by optical gates and a laser cut encoder.  I also attempted to future proof this bit by adding a second encoder we could use to read the rotational rate.  That led to four more design variations on how to space the encoders/encoder slots.  I have arrived at the final revision for this.

    I've built out a single glue board for hooking all of this up.  Assembly and testing will happen tonight, if I don't run out of steam.

  • Full stack developer

    Daren Schwenke05/14/2020 at 11:44 0 comments

    Assembly using the 'all at once' mantra was very annoying.

    The front and rear are now split into panels held together by screws.  This means you can assemble all the mechanical bits, and then assemble all the electrical bits.  The latter I'm shooting for four screw terminals and two ribbon cables.  Time will tell.

    Mounting the Pi touchscreen needed a couple layers...

    A whole new category of full stack developer.  :)

  • Hand wiring really sucks.

    Daren Schwenke05/14/2020 at 05:00 0 comments

    I finished up the latest version of the acrylic tab/slot version and promptly set about manually wiring up my control panel for it.  Looks good right?

    Several hours later I realized how much this sucks.  There is absolutely zero chance anyone not in a third world country who desperately needs this, and has no other choice, would do this for 1000 units.  This issue could be fixed with a suitably large PCB I could through-hole, but that also sucks.

    I promptly put that idea on the back burner and decided to stick our other display (Pi touchscreen) directly on the unit.

    It still uses the serial protocol @Steven.Carr  came up with to interface between the critical code running on the 'core' and the Pi.  This means we could still split the two and use some wireless protocol instead... or run it on a tablet, or have it go away altogether and the core will just keep truckin..

    This also led to the discovery that wiring this thing up and *then* assembling it also sucks hard core.

    I am in the process of redesigning the front/back panels so they can be now removed without having to split the case.  This will translate to the ability to assemble the entire unit, plug stuff in, and then put the front/back on as the last step.  That is going to waste some material, but it will save a whole buttload of time.  Everything goes together pretty quickly, right up until you start getting wires caught in the tabs and such.

    The time lost is far more valuable than the material in this case.  Doing it.

  • Everything is on a cob

    Daren Schwenke05/10/2020 at 10:09 0 comments

    And it has been terrifying.  A whole lot in the physical design has changed, very quickly. 

    In fact, the overall goal of the project, has changed

    We started out using the American version of the design requirements document. which specified a 1.5s breath interval.  

    That varied greatly from the later released UK ventilator design document.  That actually seemed a lot more sane and specifies a 0.3s inhale timing.  Switching documents resulted in a five fold increase in our power requirement.

    That five fold increase now puts our drive system requirement coming in between 30W and 60W.

    Finding a capable motor that can do that for 400k cycles without breaking a sweat increased the weight of the drive section beyond where it was feasible to place this unit on the patient.

    Since we are now moving beyond our strict weight limit, I also decided to add a battery backup.

    That led to designing a better body to house all of our new toys.  

    I decided to go all-in on an interlocking pin/slot panel design.  The new body and battery meant we now had a transportation ventilator on our hands here, so it got a handle.  This meant we needed to move all of our controls and cable connections to where they are less likely to get knocked around when this gets tossed into an ambulance.

    Next step of adding an extension hose to the ventilator bag, and then kinking it off with the pressure release disabled just to see what happened, resulted in us shattering the cam.  We have power to spare here.  

    The cam got redesigned as a solid disc, and the cam arms now clear the disc on either side.

    If we were to suddenly lose our active feedback for volume/pressure, we decided it would be best to alarm, but still keep doing what we were doing.  To do that it is probably necessary to add an encoder to our dumb motor, so we actually know how hard/fast we are pushing.  We added an encoder and a spot to put our reader for it.  

    To keep in simple, our encoder disc is missing one pulse at our two home positions. We can find home by using missing pulse detection and a single photo interrupter.  We had a hall sensor before, but it only told us when we were at 'home'.  This is much more useful and uses the same number of pins.

    The interrupter slots I picked here are cut at 4x the kerf width of our laser cutter.  

    That allows for 200 slots and still having more blocked space than cut.

    Two hundred probably sounds really familiar, and it should.  That is also the step count for the vast majority of NEMA 34/NEMA 23 stepper motors.  I think you see where this is going....

    As for the kerf to do this, don't get nervous here.  Totally dialed in, the best our laser can do right now is 0.15mm.  That's about 50% over spec.  You'll be fine. 

    The complexity of all these new parts led me to model the outline of every single part. The clearance to some of them is really close, and I have been bitten here.  

    For example... the first version of this just eyeballing the motor position ended up with the threaded rod the stack was built from going ever so slightly through where the motor case was.  Yep.

    The files are cutting now.

    Tomorrow is going to be very exciting..  :)

  • UI work.

    Daren Schwenke04/24/2020 at 07:31 0 comments

  • FFF files rendered

    Daren Schwenke04/15/2020 at 18:49 0 comments

    The changes I made to the laser cut version have been applied to the FFF version.  The arm bearing and lower mounts have been altered to use threaded rod.

    The primary difference for FFF is that it uses single bearings whereas I have opted for two bearings stacked on the laser version.  This lets me use the same model for both and just have the laser cut parts be thicker to get the added strength I need.

    I also did not put the cutouts back into the FFF files.  Printing them with low infill is probably stronger than adding the cutouts.  They will definitely print slower this way though.

  • Laser cut revisions

    Daren Schwenke04/07/2020 at 21:45 0 comments

    Nope.  Didn't get these cut yet.

    Yes, all the files have been reworked.  

    I gave myself a little more space between the cam bearings to allow for a larger (12mm) shaft.  This larger shaft is a wiper motor.  Worst case, I *know* I have at least one motor with the right torque and speed and I can move forward.

    Eliminated all the sharp transitions of the arm model to avoid concentrating stress in the acrylic to a single point, and made it thicker.  It is now built from intersecting cylinders instead of lines.

    Smoothed out the base where it contacts the bag some more.

    Changed the cam to use pins instead of bolts for the bearings.  We'll see how this works.  Saves me some height..

    Changed the base bearings to use 8mm/5/16in bolts instead of 3mm and bushings.

    Regenerated all the files.  New rendered files are up.

  • Posting Parallel Project Progress

    Daren Schwenke04/02/2020 at 23:19 0 comments

    Tested the #Human Lung Analog idea and it works.  I can control the pressure and compliance now to better simulate our load.

    #VISP - Ventilator Inline Sensor Package pcb's have passed review and the gerbers have been shipped up to @oshpark for three of the prototype boards.  

    Parts are here.  We also dropped an Atmega 328 on the board and it actually routed.  

    Tried to get into the Dallas Makerspace to cut the new laser version, and they weren't having it.  I can understand.

    An alternate contact on LinkedIn may have been able to hook me up with a lab though.  Sweet. 

    <EDIT> I decided not to take them up on the lab as that would actually put a member of my family here at risk.  We are going to attempt to do the same thing, remote.</EDIT>

  • Laser cut thickness.

    Daren Schwenke04/02/2020 at 13:40 0 comments

    The thickness for the bearings versus the parts when laser cut was a little bit of a problem.  The bearings are 7mm and common material is 6.35mm or 3.175mm.

    14mm is a nicer number, and also allows us to use washers on both sides of the arm bearings, which eliminates the stress on the bushings and the odd thickness requirement there.

    So two arms cut from 6.35mm sandwiching a third cut from 3.175mm and we got a total thickness of 15.875mm.

    Two regular washers positioned on either side of the bearings will make up that difference, and provide a larger clamping surface for bolting it together.  The bushings then just keep the bearings centered and don't have to support the compressive load anymore.  Also keeps things from flopping around.

    Then for the cam we also use two stacked bearings.  More area to wear on, and the bolt heads from the cam bolts no longer needs as much clearance as they will be at the same height as the now thicker cam surface.

    I'll model it today and put up an image of this so you can see what I'm talking about, but I think this will be better.  No new parts needed either, just duplicates of what we already have too, minus the paddle.  It will need a wider hole.

View all 25 project logs

Enjoy this project?



Mr Name Required wrote 04/08/2020 at 22:43 point

This is a fantastically worthwhile project, kudos for the design. Just a comment on the OpenSCAD script - bearings are almost always referred to by their diameters: OD, ID, width rather than in radii. It is easy to seach eBay and engineering supplies using the diameters for ballraces.

  Are you sure? yes | no

Daren Schwenke wrote 04/09/2020 at 04:20 point

Yes, and everything in OpenSCAD is radius.  :)  Rather than use diameter for just these, I put them in as D/2.  

These are just 608 bearings, aka, skateboard bearings.  No engineering store needed.  I should probably document that..

  Are you sure? yes | no

Eden Harrison wrote 04/04/2020 at 11:02 point

Hi, this is a really great project, really exciting to watch it move forwards!

I drew this up as a response to worries about the arms suffering fatigue damage, and to keep the ball rolling with bvm style pandemic ventilators.

I'm doing some fluid mechanics work at the moment and would be happy to help out where and if you need it. Otherwise good luck with future development. 

  Are you sure? yes | no

Daren Schwenke wrote 04/08/2020 at 22:04 point

Just finished reworking the models targeting acrylic as the material.  I hope to get them cut today and then hopefully a visual aid will emerge.  Thank you for the offer.  You are welcome to join us if you like.

  Are you sure? yes | no

Ocelot wrote 03/30/2020 at 18:05 point

Hi, I don't know if you were able to find an up-to-standard motor yet. I found this company, based in *Corona*, CA, that might carry what you need.

  Are you sure? yes | no

racoon wrote 03/25/2020 at 10:48 point

Have you looked into automotive MAP Sensors? a lot a older car model were using these before MAF sensors. They mesure absolute vacuum and pressure.

  Are you sure? yes | no

Daren Schwenke wrote 03/25/2020 at 16:04 point

And work by heating resistive wire and measuring the amount of power required to maintain a certain resistance.  The heated wire part, in my opinion, made it unsuitable for O2 use.  But thank you for your suggestion.

  Are you sure? yes | no

racoon wrote 03/25/2020 at 16:22 point

no that is a MAF (Mass air flow) sensor. The heated wire react to the flow of air making if colder.

A MAP sensor is a pressure sensor and work just like your differential pressure sensor but measure the absolute value. So at rest It would have a measure of the atmospheric pressure. But you could log that value at startup and then go on with measuring pressure when the system is working. Look at the section in the link called "Analog Map Sensor"

You can tell the difference between the two type of sensor by their shape. A MAP sensor only has a small input tube without output

A MAF(the wrong one) is made to fit into the intake tube to be exposed to the airflow

Example found on amazon:

Typical shape, usually 3 wires, 5v GND and signal (analog)

  Are you sure? yes | no

Daren Schwenke wrote 03/25/2020 at 19:38 point

@racoon Ah.. that is more useful.  Wonder if they got one in 22mm, or one where the sensor and the pitot are split....  The latter would be very, very useful.

  Are you sure? yes | no

racoon wrote 03/25/2020 at 21:05 point

Unfortunatly there is no pitot in those sensor, it has a internal reference chamber and the input chamber so if you need two test points, you need two sensors. They are used to measure absolute pressure since its necessary for an engine to know if air is more dense or no (read different altitude)

  Are you sure? yes | no

diego.diez wrote 03/25/2020 at 22:04 point

A think that @racoon was thinking in one of those:

you should be carefull in the selection of the sensor, cause there are absolute, relative (with two inputs) and relative to ambient pressure and everyone is for an specific purpose.  For the small research I have been doing, the more usefull for medic purposes are the absolute (but please do some research), if the absolute sensor gives you "real" readings that you do not need to calibrate, thats a huge bonus, cause you can inform that in the GUI and a health carer could understand easily. Mind that the unit used is  cmH2O.
Sorry about my english. 

  Are you sure? yes | no

clive wrote 03/24/2020 at 08:34 point

Deeply impressed with your project.
I will be building it and try writing some software.
Is there a stl for the latest modifications?
Or openscad files?
Great work guys!

  Are you sure? yes | no

Daren Schwenke wrote 03/24/2020 at 15:48 point

The stl's that are attached are the latest, but missing two files I forgot to post.  I need to get around to actually pushing this up to github.

  Are you sure? yes | no

amd_athlonxp wrote 03/24/2020 at 04:49 point

Do you have make a simulation? The arm does not looks so stable.

It needs a slightly more organic shape.

You need to heat the air up a bit and increase the humidity of the air.

It feels very bad if the air is dry and cold.

  Are you sure? yes | no

Daren Schwenke wrote 03/24/2020 at 05:11 point

Thank you for your comments.  In PLA, the arms are at least 10x stronger than they need to be.  The members under only tension are 2.4mmx7mm.  The members under compression are 7.2x7mm.  In acrylic this number is lower, but I can increase/decrease the wall size with a single variable if needed.  I do have the means to have a finite element analysis performed, and I do have someone testing them to destruction as well.

Yes, it does need a better shape.  Once the cover is on the motor it will be more organic.  I was more concerned right now though with not wrapping up peoples hair on the cam.

Humidity was to be provided by bubbling the input O2 through water.  For warming the air, I was going to warm the water with a fish tank heater, only exposing the sealed glass area to it.  This doesn't help if the patient is not on any O2, but I'll cross that bridge when I get there.

  Are you sure? yes | no

Muhammad Bin Sohail wrote 03/23/2020 at 22:33 point

hello anyone help plzzz

  Are you sure? yes | no

Nazaret García wrote 03/23/2020 at 19:33 point

Really nice work!!! I love it! I'm a programmer myself, so it would be an honor to help you with this project! Let me know how I can help please!

  Are you sure? yes | no

Nazaret García wrote 03/23/2020 at 19:34 point

Plus: I have a medical doctor in my family so she can help us if we get stucked with something.

  Are you sure? yes | no

Daren Schwenke wrote 03/23/2020 at 21:00 point

Responded in PM.

  Are you sure? yes | no

Dan Maloney wrote 03/23/2020 at 16:54 point

Nice work, I like the design. Good luck with further development.

  Are you sure? yes | no

Daren Schwenke wrote 03/24/2020 at 04:32 point

Thank you.  Hoping to have this ready for DOD Project VULCAN Hack-a-Ventilator Hackathon.  Deadline is Wed at midnight.

  Are you sure? yes | no

TyGuy wrote 03/23/2020 at 05:07 point

@Daren Schwenke I might be interesed/able to help with some software - I will message you directly.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates