Volume Calculation

[dtgerson]

This issue is meant to cover the issues/thoughts around estimation of volume.

Related issues: RespiraWorks/SystemDesign#17 and (software needs to be implemented) https://github.com/RespiraWorks/VentilatorSoftware/issues/50

High level: tidal volume is not directly measured but is calculated based on other sensors.

Current design: Venturi 1 (using a single DP sensor) before patient and Venturi 2 (using a single DP sensor) after patient both measure flow rate. A single pressure sensor exists between the two (right before Venturi 2). No temperature or humidity measurements.

Volume is then calculated by measuring the flow through Venturi 1 and subtracting out the flow through Venturi 2 and integrating this over time to calculate the amount of volume delivered to the patient.

Currently there is a challenge in getting accurate volume measurements. As can be seen in this post, the volume measurement seems to drift steadily - rather than integrating out to around zero for most breaths. See this post for example data with actual flow (and lots of discussion): https://respiraworks.slack.com/archives/C011CJQV4Q7/p1589251234436800

and this for data with blower off (and lots of discussion): https://respiraworks.slack.com/archives/C011ABVBS21/p1589590403271900?thread_ts=1589583371.264500&cid=C011ABVBS21

This behavior seems to be driven by noise/drift from the DP sensors - causing the flow measurements to be off, driving the volume measurement to be off. We believe that for our particular DP sensors, the offset is very temperature dependent.

Ideas to investigate for improving this:

1. Add processing in software to compensate --Could we estimate the linear drift and then subtract this out? Or could we reset the volume to 0 after each breath (because theoretically the patient should exhale all of the volume)? Or could we use a filter that incorporates information about the expected behavior? --Concerns with this approach: If the volume measurement is sufficiently off, it seems like this is problematic for estimating volume of a single breath (breaths that are too big and breaths that are too small are both problematic). There are also concerns with breath stacking and being able to catch problematic trends across breaths. But we still don't fully understand this requirement that well.

2. Add more DP sensors and then integrate the readings - or get better DP sensors

3. Add temperature sensing/humidity sensing to the DP sensors and use that to compensate the measurements

4. Change sensors (e.g. mass flow sensors? - Edwin has more info)

5. Do more characterization of the DP sensors to understand their drift/offsets

Related open questions:

1. What resolution do we need on this volume measurement?

[jlebar]

This behavior seems to be driven by noise/drift from the DP sensors

Specifically it's drift. There is also a lot of noise in the sensors, but we have enough time to take lots of samples and average out the noise, no prob. But when the noise average changes, and changes very quickly like it did in these examples (average went from -1.2L to 0L basically instantaneously), that's where we get into trouble.

[neelfirst]

Follow-up from RespiraWorks/SystemDesign#9

[jlebar]

Some traces of pressure/flow/etc are available at https://github.com/RespiraWorks/VentilatorSoftware/tree/master/sample-data. I am not sure if these drift, though.

[esc-works]

@ebhillstrom:

• Datasheet says 1.5% maximum error for 0 to 100 mm H2O - this is usually % full scale, making the error +/- 1.5mmH2O
• @jlebar data for the "zero" test has all measured values below .2mmH2O - it now makes sense that the offsets are different because they're all well within sensor precision - you won't get better measurements than that no matter what you do. If we plotted it out, the random drift is also probably well within this accuracy meaning you probably won't be able to correct it.
• From the venturi spreadsheet, 1.5mmH2O (the sensor accuracy) corresponds to ~7lpm, which is a lot! Plus this error gets doubled when you subtract two dP measurements.
• From this it seems like the sensor isn't fine enough (or the orifice is too big) to measure low flows."

[esc-works]

• We could zero/bring very low the flow "every breath" if we don't always have bias flow.
• We could schedule the "inhale" valve to fully close right at the beginning of expiratory flow. (If there is leakage I think we could characterize the leakage and subtract it out but zero is an easier value to know.) Even just a few miliseconds here would help.
• Similarly on the expiratory side right at the start of inhale we could close the exhale valve. That should temporarily zero the exhale flow.
• we can't do this currently because there was no way to 'zero' the inhale flow. but with the valve we can. I wonder if we could try this on one of the solenoid pizzas just on the exhale side. It would limit the walk of one sensor at least which should cut down on the overall walk.

[neelfirst]

Datasheet: https://datasheet.octopart.com/MPXV5004DP-Freescale-Semiconductor-datasheet-12520.pdf

Autozero app note 1: https://www.nxp.com/docs/en/application-note/AN1636.pdf

Autozero app note 2 (not the one I posted last night): https://sensing.honeywell.com/auto-zero-calibration-technique-pressure-sensors-technical-note.pdf

[neelfirst]

In particular, that 1.5% is with regular autozero calibration!

[asmodai27]

There is also a lot of noise in the sensors, but we have enough time to take lots of samples and average out the noise, no prob

This is something we are not doing for now, but should be pretty straightforward, both with oversampling and filtering. Said filtering will be much easier now we have a timer interrupt that allows us to have constant time between samples, though it requires setting the timer interrupt on a higher frequency than it currently is (100 Hz) and running the PID calculations every Nth interrupt.

[jlebar]

There is also a lot of noise in the sensors, but we have enough time to take lots of samples and average out the noise, no prob

This is something we are not doing for now,

https://github.com/RespiraWorks/VentilatorSoftware/commit/e86aec199b2748f25e2f9200bb0df8c47a86793d landed, so we are oversampling and averaging (without any filtering).

[esc-works]

How do we define acceptable volume integration accuracy? There are two criteria I am proposing:

1. The measured flow rate / naively integrated volume error shall be sufficiently small to enable leak detection based on our minimum allowable leak rate and to resolve flow rates within a required error. For this I propose an accuracy of the larger of +/- 10% of net flow or +/- 1 lpm whichever is larger.
2. Any auto-zero correction applied to the flow rate implemented in order to meet (1.) shall have the following requirement:

• change sufficiently slowly (derivative limit) so that our auto zeroing does not mask other signals we're trying to observe.

In order to define the requirement in 2, I tried to define the largest allowable change in derivative that can occur in the smallest amount of time. If we specify that as the instantaneous derivative, we have to worry about signal noise. The goal is to not have this derivative result in a 10% or large miscalculation in TV, either larger or smaller, from the "true" value. Based on a conservative MV of 4000 ml/min and a conservative Respiratory Rate of 10 bpm, a tidal volume of 400 ml over 6 seconds is set as the performance benchmark. In order to have the computed value fall within the range of 360 ml to 440 ml, we can calculate the integral average of error over this time and compare it to the 'actual' value. Based on my math, attached, this works out to limiting the instantaneous derivative to -2.3 < 0 < 2.3 mL/s/s. To avoid noise I think its acceptable to expand this to the 100ms running average of the derivative. Any derivative larger than this results in an error larger than 10%. For the record I did the integral in excel but i should have done it by hand because its a line....

[bruprescott]

The use of an SFM3300 proximal sensor could solve this issue.

Is the implementation viable?

[jlebar]

I believe the main concern is cost.

[bruprescott]

The cost is not that high. Two DP sensors are the value of that sensor.

https://br.mouser.com/ProductDetail/Sensirion/SFM3300-D?qs=u16ybLDytRa%2FjhQAbeBcMw%3D%3D

[asmodai27]

"Disposable Single Use Version" not sure what that really means, but would it need to be replaced every so often? Also, it looks like we are on the right path to make the volume estimation work with the current sensors (see #flow_measurement on slack). Need some more characterization and testing but we have outlined some solutions that work on paper.

[esc-works]

Yeah, I think those would be great. When we last looked at it, the issue is not cost, we had evaluated those and couldn't get them in any quantity, ("This part number is not currently available from Mouser. Product may be in limited distribution or a factory special order.") and they cannot be sterilized so need to be replaced with every patient ("Disposable Single Use"). So the cost for one is pretty comparable, but the Venturi can hopefully be sterilized. I think in general, the mouser flow sensors are better. But we decided we really wanted to target availability. We should re-evaluate if we were wrong.

[bruprescott]

This restriction warning appears, but I just bought 5 units to test.

I'll see how the circuit is set up. We can evaluate a way to sterilize and not just use one per patient. The AW version can be sterilized, but it costs more than 100USD.

I have tested the venturi with this team's code, but I find many error values at low volume. In all the tests I saw using the SFM3300, they were super stable and it is not necessary to recalibrate.

[esc-works]

@bruprescott cool! thanks. please let us know how it goes. @inceptionev we tested one of these once, right? Do you still have it?

[bruprescott]

Has anyone tested automotive MAF sensors?

I found an approach on the subject. https://github.com/hydronics2/COVID-19-Airflow-Sensor-AFH55M12

[asmodai27]

My attempts at building an algorithm that can take care of the flow bias and drift of our current flow sensor finally yield very promising results. Many parameters will need tuning and testing on actual hardware (which I will try as soon as I have a full pizza setup), and here it goes:

For now, this needs to have 0 flow at some point, but I think I can come up with a similar solution when the flow is constant but not 0:

• build rolling average of pressure delta signal over a reasonably long period (in my tests: 0.2s, long enough to average the noise pretty well but short enough to not filter too much of the actual dynamic of the system).
• integrate flow with a 2L/min deadband (corresponding to the sensor noise level).

Every so often (for implementation convenience I am using the same duration as the rolling average window: 0.2s), re-zero the sensor if both of these are within reasonable bounds meaning they are caused by noise and drift, not an actual signal:

• flow(average pressure delta) < time since last auto-zero * max allowable drift on flow (meaning that the current average value can be attributed to drift)
• integral of flow since last check < max volume for auto-zero (indicating the averaged pressure delta isn't hiding an actual small flow: because of the noise, a constant 1L/min flow leads to a measurable integral of flow during these 0.2s, even with a 2L/min deadband. This also prevents re-zeroing when the average pressure delta is hiding a dynamic signal, which also leads to a significant flow integral).

Results of this algorithm on synthetic pressure signals, built from sample data available on VentilatorSoftware repo, simulating 100 s "vent off" followed by twenty 5s breaths (built from 2020-05-14-pip25-peep10-rr12-ie23.csv). noise and drift are built to match values from 2020-05-14-vent-off.csv and my own characterization of the sensors on non-zero flow noise level.

On the flow:

For the volume integration, I am also using the 2L/min deadband to get rid of the noise and so long as the re-zeroing algorithm is working properly, this gives me very good results (in the simulations I am running, accurate to within 50 mL over 5 minutes, re-zeroing every 10 breaths brings it back with ease to within 5 mL and shouldn't cause too much trouble).

Results for the volume:

Octave scripts that allow me to run these (renamed as .txt so github will let me attach them):

PressureDeltaToFlow.txt RollingAverage.txt volume_simulation.txt

[asmodai27]

Results with the actual ventilator software available on slack, similar to the ones here. No volume measurement for now since I don't have a full setup and the only thing I can do is feed flow to the venturi. Most of the code is located in https://github.com/RespiraWorks/VentilatorSoftware/blob/jtravert/drift_correction/controller/lib/core/sensors.cpp

[martukas]

@asmodai27 what should the criteria for considering this problem solved? Can we document a reproducible test to confirm this (still) works with whatever our current set up may be?