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