Ventilator Challenge – Part 2

Some more thoughts on the before-mentioned Ventilator Challenge:

As mentioned in the first part, I am not a medical professional, and everything I say here is my shot-from-the-hip opinion and should not be taken as fact or good practice.

The specifications of the Codelife Ventilator Challenge are a bit thin. There is a longer, well done specification for an emergency-type ventilator from the UK government.

If we look at the history of ventilators, most of them seem to have volumetric pumps as pressure sources, often a kind of bellows that moves with the same frequency as the lungs of the patient. Accordingly, there are some designs of emergency ventilator concepts (example) that use bag valve masks and add a motor-driven mechanism to push on the bag – and therefore air in the patient’s lungs.

If I had to design a ventilator from scratch, I would split the air-supply side from the control side. That would mean, the air supply would be continuous, and a set of electronically controlled valves would take care of regulating pressure, calculating flow, volume, frequency and eventually oxygen, etc.

Air Supply

The specifications of Code Life Challenge talk about 40 cmH2O (or about 40 mbar). In this British specification, a maximum pressure of 80 mbar is demanded. That is more than what -let’s say- a kitchen fan can deliver, but much less than what an air compressor for workshops can deliver (8 to 10 bar). A quick research online showed anecdotal evidence that a blower from a vacuum cleaner can deliver 200 mbar, so well within what we need. Of course there would be cleaning and filtering involved, and a vacuum cleaner could supply a couple of persons with air – the point is that producing an air supply at this pressure is not a technical challenge.


The valves can’t be simple on/off valves, for example of the solenoid type, but they should be able to open a defined percentage to precisely regulate air flow. Looking at my Arduino-starter-kit, there are servo motors for RC cars that could easily operate the valves. The valve body could be 3D printed, although, among many other challenges, the tightness of this valve would be an issue due to low precision of 3D prints.


One of the key components would be the pressure sensors, since they are used for pressure and flow (via venturi tubes) measurement. The venturi tube would be another part to be 3D printed (or already is!).

Control & UI

The control board would have to manage min. 2 or 3 inputs of the pressure sensors, and manage min. 2 servos: the inlet- and the outlet valve. It would need to manage a screen to show status and buttons or a knob to setup. Since I am already elbow deep in the Arduino toy box: there is a screen in a lot of starter kits one could use.

Pros and Cons

I am aware that there are a lot of unanswered questions, including compliance, reliability, cleanability, availability of components and so on.

  1. I would argue that the availability of Arduino starter kits is much higher than the availability of ventilators, even if it’s nothing you will find in every household.
  2. Breaking down the system in its functional components allows developing each functional group on its own.
  3. Making the software on the microcontroller the central brain of the respirator allows for later updates with improved firmware and great flexibility.
  4. Using Arduino is very popular platform, which would help on the side of availability of hardware and in terms of community knowledge.
  5. Arduino is preferable to the suggested Phones and Raspberry Pis since they are less complex and have fewer points of failure. (You don’t want an Android update to happen when someone’s breathing is halted during.)
  6. The gas supply could be centralized, with a daisy chain of patients on a main line for low resource air production, or decentralized for more mobility.

Selected links

3D-Printing, at last

Since my first contact with 3D printing, about a decade ago, I have had some prototypes printed, but never got into operating a printer myself. That has changed.
About a year ago, I bought a Creality Ender 3, a ridiculously popular and very affordable FDM-Printer. I am still amazed at how much high-tech you can get for the price of a good pair of shoes.

That being said, getting the Ender 3 to work properly was quite a hustle in my case. At this price point, not much is spent on quality control. Creality is said to have good customer service, but I decided to take the hard way and spend some evenings debugging and learning:

Warped Bed

The building platform arrived deformed, which appears to happen often. The platform needs to be perfectly planar, so the first layer of plastic can be evenly squeezed onto it by the nozzle. I found that taking apart the platform assembly and carefully bending (hand and knee) the Aluminium sheet can get you within about 0.05 mm, from initially ca. 1.5 mm “concavity”.

Nozzle Temperature

This one seems to be less common, or is at least not mentioned in the plethora of YouTube videos about the Ender 3. The temperature sensor of my model is round about 20 K too low, so my prints would not stick to the bed when I used the recommended settings for the material used. Also, the layer adhesion was extremely bad. Fortunately, I have a small USB thermal camera (that cost more than the printer, by the way), so I found the issue filming the hot-end and adjusted the temperature setting in the slicer accordingly.

Contorted X-Axis Profile

Granted, this one was my fault. I carried the printer without taking off or securing the spool, which fell on one edge of the bed. Enough to twist the 20 by 20 mm Aluminium profile forming the X-axis. The effect of this is a literal brain twister because the bed seems to be perfectly level during manual bed levelling, but prints fail miserably. With a lot of measuring, I managed to twist the profile about half a degree back in the other direction.

With this, and a lot of other, less essential modifications, I think my Ender 3 is a fantastic machine for its price, but definitely nothing for someone who is not interested in the process, but in results out of the box.