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.

Valves

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.

Sensors

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

Medical Ventilator Challenge

One of my friends sent me the link to this, knowing that I recently got into “functional” 3D printing. I’d like to share some first thoughts on the Code Life Ventilator Challenge:

To design a low-cost, simple, easy-to-use and easy-to-build ventilator that can serve the COVID patients, in an emergency timeframe.

Note that I am not a medical professional, and most of what I write here I just learned about myself. The rest is speculation.

**** SEE BELOW FOR UPDATES ****

Initially I was confused because the German word for fan is Ventilator. It turns out a medical ventilator has (almost) nothing in common with the thing you use to cool you down on hot days.The list of requirements is short, but packs quite a punch. There is a reference to ISO 80601-2-12:2020, but it is not mentioned explicitly to comply with this norm.

So let’s start and build this thing…

Fan*

It is called ventilator, because it pushes air into the patients lungs, so we need a fan capable of doing this: 40 cm water column of pressure (about 0.04 bar) is a considerable pressure for a fan. CPAPs are machines that do remotely the same thing, and they use a kind of centrifugal fan. (See the insides of CPAP here) I would assume that ventilators use the same principle. Laying out this kind of fan is work for specialist in fluid dynamics. A flow optimized geometry of the fan and housing is a typical case for a 3D printer. The fan itself will be spinning at a high RPM, so in order to minimize the balancing, I would see if it could be resin printed. The housing could be printed with widely available FDM printing.

Fan Motor*

A fan needs a motor, probably a brushless electronic motor to be able to control the speed, and by that the pressure created by the fan. In terms of availability, this is one of the most critical parts, together with the electronics. An interesting approach would be to design around a commonly available motor like a heater fan from a car, but this kind of motor would require more components to control the speed, and lose the advantage of availability.

Control

A major part of the design will be electronics and programming. The task is to check present flow and pressure, compare them to the set values: how often per minute should the patient breathe, how much, at which pressure and so on. The board would then adjust the RPM of the fan. Then there is the oxygen concentration to measure and the oxygen valve to control. Finally, the board has to put out an alert on a number of occasions. Given that these tasks are important but not too demanding, I assume an Arduino board would have the necessary calculation power, and they (and their clones) are also widely available. The “eyes and ears” of your control board would be electronic pressure sensors. They can be used to measure the air flow in a Venturi tube. There is a project about this on hackaday.io. I would consider electronic pressure sensors as another critical component.

Power Supply

Since backup batteries are required, I would opt for 12 V lead acid batteries for availability reasons. Worst case you can get a spare from every car standing around.

Team

A minimal team would certainly include an electrical engineer for circuitry and a mechanical engineer (fluid dynamics) for 3D modelling and the manufacturing process, both working together closely with the medical professional.

So far my first thoughts, maybe some finds something useful.

*) Updates

CPAP stands for Continuous Positive Airway Pressure, so the pressure is continuous. That means that the fan of a CPAP is likely not speed controlled.

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.

SolidWorks: Equation Syntax Problem

I’ve been having a tiny, yet very annoying problem working with SolidWorks 2016 lately. Now I seem to have found a solution I would like share:

Problem

sw_syntaxerror01I am using a text file with equations to propagate global variables to the parts of my model. In general that works really fine. Yet in some parts it occurred that some variables were not recognized. Trying to solve the problem, I disabled the link to file (no effect) and tried to change the value (no effect either). SolidWorks kept on telling me:

The syntax of this equation is incorrect.sw_syntaxerror03

which is clearly wasn’t. I searched for similar problems and found some people having problems with the internal VBA execution of SolidWorks, that in some cases failed after a Windows update. Fortunately my problem finally was not that severe.

(running SolidWorks 2016 Standard SP 4 x64 Edition on Windows 10 Home)

Fix

After a lot of trying around I noticed that the problem occurred only in parts whose unit was set to inch. Now the imperial system in itself is a terrible mistake (how much is 17/32 of a barleycorn again?), but it usually does not cause errors in CAD-programs. In this case however, turning the parts unit to millimetres (Options –> Document Properties –> Units –> MMGS) and a subsequent opening and rebuilding of the Equations-window in the tree will resolve the issue. 

By the way, for those who think in hands, inches and poppyseeds: switching back the part to imperial will not cause the problem to return.

The BOM Tool in Inventor

Today is one of the days where I discovered a very handy tool, and I feel a bit stupid for not having discovered or used it earlier. I am talking about the Bill of Materials in Inventor, which lets you bulk edit the iProperties of your Assembly in an Excel-fashion, giving you perfect control over the meta-data side of your work. This video sums it up nicely:

Add Help to Your iLogic Form

If you want to provide additional information on, for example how to configure a iLogic component, one way would be to write it directly into the form as text such as labels. Of course, by doing that consequently, you will end up with a huge and confusing form. Much more elegantly, you can use the tooltip field when you edit your form elements, which shows information only when your mouse is hovering over this form element. Actually, when you fill out the comments of the parameters you want to have in the form immediately, the comment will be set as tool tip when you create the form element for this parameter.

However, only text might not be sufficient, maybe you want to use images or videos as a documentation. A very appealing way to do this is to link to a document or page in you intranet, for example a wiki page that contains additional information for this part. To do this, just create an iLogic-rule and add the line:

Process.Start("http://myintranet/wiki/pageforthispart.html")

Create a button called Help for this rule.

There are many reasons to take it one step further and use the iProperty-field WEB Link to put in the URL and use the following rule text:

'First check if the "WEB link" iproperty resembles a URL,
'(thus starts with a "http")...
If  Microsoft.VisualBasic.Left(iProperties.Value("Project", "WEB Link") , 4) _
								= "http" Then
	'...try to start the browser with the URL from the iProperty field...
	Process.Start(iProperties.Value("Project", "WEB Link"))
Else
	'...or complain if the URL is not valid
	MsgBox("No valid web link found!",,"Help")	
End If

The advantages could be:

  • Fill out and maintain the URLs without opening the files in Inventor (access from Vault etc)
  • Copy and paste rule into other documents
  • Use an external rule to call help site
  • Create an Add-In that adds a Help button to your ribbon

Let me know what you think!