Blower response time is too slow

[neelfirst]

John Batteh: We definitely need to nail down the blower inertia value. Currently it is set at 0.69s but with this sort of time constant, I think the response will be pretty slow. We'll set up the latest test to try and achieve 20 breaths/min and see how the system responds.

Just thinking about it quickly- there will definitely be a problem and we don't even need to run a sim. For 20 bpm and IE=1/2, then the intake event is 1s long. So if the time constant is 0.69s, your speed response alone will make it difficult to hit your PIP target. On your target hardware, are you able to run something like the breathing parameters above and hit the PIP target? If so, that is interesting and we need to re-evaluate the blower inertia. It is critical.

[esc-works]

@inceptionev: Attached below are two files running the same profile, a step response from 0 to 20%, 40%, 80%, and 100% command, in sequence, with the frequency of the hall sensor plotted (essentially speed). The first file is open flow, the second is with the inlet and outlet of the blower blocked. The triggering of the data recording was a little inconsistent, so I tried my best to capture a whole test cycle. In any case, you should be able to get inertia data from these step responses. BlowerInertiaTest-OpenFlow.xlsx BlowerInertiaTest-PortsBlocked.xlsx we can also add a fixed bypass bleed between the inlet and outlet to prevent stall when the outlet solenoid is closed. You notice that the blocked-flow plot is much slower to spin down

[esc-works]

It doesn't seem like the fan is nearly quick enough to respond to a higher RR and high pressure. The trace barely gets to 20 cmH2O before switching to exhale. So the lung volume we're getting is like 300 ml. We played with a number of sensitivities (volume and pressure drops) here and by far the biggest effect is the fan time constant. Things we are considering are one/all of the following: 1) increasing the voltage of the driver board (either over driving the 12v or buying a 24v) 2) two fans in parallel 3) using a throttle valve to keep the fan spun up during idle 4) other ideas?

[DavidC-RW]

Basic Questions (will also post in Github): A. Is the blower inertia value still at 0.69s (for minimal back pressure)? B. The BOM says "No" under "Likely to Change". Is this the optimal blower for our application and no need to check for others? (No problem if it is, just want to make sure the BOM note is accurate). C. Has anyone checked to see if how Medtronic do this on the PB560 and what blower they are using (is it worth the time to check these?)

[esc-works]

Stephen Glow: I have been playing with the Aliexpress blower that @Ethan S. Chaleff sent me today. I'm driving it with a servo amp running off 30v. I've been able to get up to over 30k RPM in about 0.2 seconds. I can also stop it equally quickly. To get this response I'm pushing up to 20A into the motor. That is the limit of the servo drive I'm using, I could probably accelerate faster with more current. The real question is how long the motor will last being pushed like this. It's definitely over spec!

[sglow]

Here's the same test as above using a blower we received from Moog, looks like part number AMP45-DC-EH. It's rated for 5A @24V, but I had to push harder then that to get really quick acceleration. Here's the best I could do:

The results were similar to the WS7040-12-V200 blower which is the one I tested in the post above. The big difference was that the WS7040 blower was very obviously over stressed being pushed this hard (got very hot and started to smell like melting plastic) and the Moog seemed to take it more in stride. The Moog has a large metal base which acts like a heat sink. Either way, I think our best bet is to run a blower at constant high speed and use a valve to quickly regulate airflow. This will be easier on the blower and will require a less expensive amplifier to drive it.

[inceptionev]

WS7040 (Alibaba) blower running at constant throttle using an automotive stepper-type idle air control valve for flow control (by creating a variable resistance on the outlet of the blower). This is an open loop step response cycling at 500ms period. data is here with closed loop tests to follow.

[inceptionev]

Blower + Idle Air Stepper Valve open loop step response data: https://drive.google.com/open?id=1OceIwfI62gkKCaW1NrcK_0qxuli10JDP

Setup: Blower > IAV > Pressure sensor > Venturi (for backpressure)

Notes: this is full scale 10-100% actuation, and the rise and fall traces seem to be mostly linear, hence a simple 0.67x can approximate time constant. Bottom command was 10% to avoid blower surge. This is probably more actuation than we would probably use in practice. Smaller moves will be faster, as can be seen in the previously posted cycle test. A delay is observed between the command and the fall of pressure because 100% actuation is well above what is essentially full flow in the valve, so it takes a while for the stepper to move the pintle into the area of effect.

[neelfirst]

IAV/pinch valves both cannot fully close. We need to get them to fully close.

Pinch valve is front-runner. Handles o2 compliance. IAV still worked on in parallel.

Edwin and Steve both working on this.

Chuck's idea to change pipe cross-section: can't deal with this right now. Need to stay focused on current design. Likely for other issues to arise from that change. Chuck will continue to research this.

[inceptionev]

The software being used to test the IAV and pinch valves is here: https://github.com/inceptionev/FML-Blower-IAV, specifically the softeare used to test the stepper-driven pinch valve is in this branch: https://github.com/inceptionev/FML-Blower-IAV/tree/FML-Blower-PinchValve

[inceptionev]

This software will be ported to STM32 shortly to continue testing using the ventilator mainboard

[esc-works]

Summary of recent slack discussions:

• For the air valve there really is no O2 concern if we don't blow O2 through the fan. I don't think we're going to blow O2 through the fan. Therefor an automotive IAV including the valve body could totally be used. Just whats cheaper and better and easier to source.

• For the exhale, there is the reality that we will blow 95% + O2 through this. but we aren't going to the patient after wards, so the real question then is sparks/fire, which is 1) a UL issue (in the actual sense that it really can't spark) and 2) checking there is no residual oil/cleaning / materials that aren't O2 compliant. So Pinch seems like the way to go there but IAV is an option

• For the O2 I don't think an IAV really works since the pressure could be high and high pressure O2 is a different game. Also, I don't think we can really get high O2 concentrations without a flow controller or an O2 compliant fan. Considering that MOOG basically said no way on the O2 I haven't invested a lot of effort in looking into this, but that was before we knew that Micronel and others did sell O2 fans. So we could maybe go back to it but it does seem like a dead end if our aim is cheap + supply chain). Therefore we need a valve for O2, either a pinch or a proportional solenoid.

These thoughts may inform the pinch vs IAV decision down the line, and we may end up with both.

[inceptionev]

Blower+IAV response (note that the PEEP was erroneously set below 0 which is why it can't reach it)

[inceptionev]

Blower+stepper pinch valve response (same issue as above with the impossible PEEP)

[inceptionev]

Performed closed loop testing with blower and pinch valve. Results look very good. This test was done at 7.5bpm for the sake of comparison to previous tests, but the the system will reach PEEP without any trouble even at 20bpm. The rising and falling time constant are in the 200ms range.

The test lung I have here is limited in its compliance (it looks like its going to pop above 10cmH2O so we should test this at higher PIP to PEEP ratios, but the initial test looks very good.

Dataset here: https://drive.google.com/open?id=1Wi2U0hHRq0BEjaUxTj6Eq7F_pi3vgAHT

[inceptionev]

Note to think about. The pinch valve, when unpowered, will default to open, because the springiness of the hose is enough backdrive the unpowered stepper motor. This is not true of the stepper-driven plunger (formerly called IAV) valve. This may have implications on the anti-asphyxiation design of the system.

[sglow]

That's a good point. We should also plan to wire the reset line of the stepper drivers up to a pin on the STM32 with a pull down resistor to ensure that if the processor crashes for some reason the stepper drivers will immediately be put into reset and disabled. The pins on the STM32 are high impedance on reset, so a pull down should do it.

[inceptionev]

dataset: 2-35cmH2O, 20bpm:

https://drive.google.com/open?id=13Knhy0zO3D_INCfPGVnWj73_zMR7KzgQ

[inceptionev]

More detailed discussion of pinch valve and anti-asphyxiation brought over from slack:

part of it has been the decision to pursue the stepper-driven pinch valves as the primary source of pressure control, which snap open in the absence of power. So in a power failure case, both the inspiratory and expiratory valves will open, through which the patient will be able to breathe (though we will not know until the full loop is built how much resistance there will be). Due to this, and the simple design of the pinch valves, it is highly unlikely that a mechanical failure will result either of these valves becoming stuck-closed. The likelihood of both becoming stuck-closed is extremely small. This leaves the case in which the valves are actively commanded by the electronics to stay closed. In the event of a computing failure in either the UI Computer or the Cycle Controller, a watchdog timer monitors each and will reset the offending computer, which should then be able to regain control of the valves. Furthermore, it will need to be confirmed in the final design that the UI Computer cannot command any modes that will cause the Cycle Controller to hold these valves closed. Assuming this is the case, then only the cycle controller needs to be considered in the anti-asphyxiation concept of operations. In that case, the Cycle Controller watchdog timer can also be connected to the stepper motor drivers which will default them to an unpowered state in the event of a Cycle Controller computing failure, which will again cause them to snap open, adding another layer of anti-asphyxiation protection.

[inceptionev]

@neelfirst with the pinch valve implemented, is this ticket ready to close?

[neelfirst]

I know in practice the pinch valve is done and is our primary solution for improving blower response time. So this ticket can be closed.

However I don't see enough of a paper trail in GH issues that declare the pinch valve fully implemented. In particular -

655 should have at least a pointer to the final design and

629 should have a pointer to the completed test data, for that design.

The Slack discussion for the pinch valve failure modes should be in #655 and tagged for future FMEA work. (did this)

[inceptionev]

Decision is generally made, pending completeness of test data. Closure pending closure of the two tickets called out above.

[martukas]

Life leader pinch valve has proven valve to work for over 4 million cycles (12 continuous weeks of operation). Tracking of testing continues in #629 Mechanical design of pinch valve superseded by #941 We consider the general question closed, and specific response scenarios will be addressed in detailed integration testing with a more mature design.