|
I first integrated a pressure sensor based on NXP 7002.
Its analog values, once read from ADC,? ranges from 0 to 613 (integer number).
Someone provided a formula where those values are translated to -3.57 to 41.08 BANANAS.
I mean BANANAS because one individual calls it cmH2O and a seconds InchH2O.
Anyways... once I implemented the integration nobody questioned the values being displayed nor the alarm thresholds hardcoded to 4 for low and 35 for high BANANAS.
Now we are up to replace NXP 7002 for pressure to a BMX280. In a normal world we KEEP THE SAME UNITIES. So my logical approach is to keep? the very same -3.57 to 41.08 BANANAS range regardless the sensor we are using for PRESSURE (I am not talking about Flow sensor).
Therefore, if there is any objection please step in and clarify.
Thanks,
MV
which provides voltages that transpates to integer values
|
Hi Marcelo - I've never used units other than cmH2O for patient side pressures.
You really need 4 separate alarm conditions: - sustained high - machine/algorithm fault (aka a Vasalva manoeuvre, leading to occlusion of blood return to the heart, and then a fall in blood pressure) (eg >20cmh2O for > 15 seconds)
- sustained low - apnoea or disconnect (eg < 10cmh2O for > 15 seconds)
- too high (even for for just a second 60cmH2O risks popping a lung, probably no excuse for ever exceeding 40)
- too low (pressures should never fall far below PEEP, and sub-zero values lead to a condition called negative pressure pulmonary oedema)
Potentially there are also separate conditions set on "failed to reach PEEP" and "failed to reach Pi" to within certain tolerances.
(all these alarm limits should be user configurable)
hope that helps e
Erich Schulz,?mbbs, mba, fanzca 0410 277 408
On Tue, 14 Apr 2020 at 09:50, Marcelo Varanda via <mv_email= [email protected]> wrote:
I first integrated a pressure sensor based on NXP 7002.
Its analog values, once read from ATD,? ranges from 0 to 613 (integer number).
Someone provided a formula where those values are translated to -3.57 to 41.08 BANANAS.
I mean BANANAS because one individual calls it cmH2O and a seconds InchH2O.
Anyways... once I implemented the integration nobody questioned the values being displayed nor the alarm thresholds hardcoded to 4 for low and 35 for high BANANAS.
Now we are up to replace NXP 7002 for pressure to a BMX280. In a normal world we KEEP THE SAME UNITIES. So my logical approach is to keep? the very same -3.57 to 41.08 BANANAS range regardless the sensor we are using for PRESSURE (I am not talking about Flow sensor).
Therefore, if there is any objection please step in and clarify.
Thanks,
MV
which provides voltages that transpates to integer values
|
|
|
Hi Erich, now about Tidal Volume,
What is the unit used for it in ventilators and what kind of alarm it would require?
What method do you recommend to establish a baseline to calculate the coefficients ? I guess a same controller monitoring sensors in pipers with different diameter will need different coefficients in order to get same result.
Thanks
|
please refer to engineering specifications document V1.6 posted here, it describes the alarm conditions.
?
Cheers,
Dave
toggle quoted message
Show quoted text
[External Email]
Hi Marcelo - I've never used units other than cmH2O for patient side pressures.
You really need 4 separate alarm conditions:
- sustained high - machine/algorithm fault (aka a Vasalva manoeuvre, leading to occlusion of blood return to the heart, and then a fall in blood pressure) (eg >20cmh2O for > 15 seconds)
- sustained low - apnoea or disconnect (eg < 10cmh2O for > 15 seconds)
- too high (even for for just a second 60cmH2O risks popping a lung, probably no excuse for ever exceeding 40)
- too low (pressures should never fall far below PEEP, and sub-zero values lead to a condition called negative pressure pulmonary oedema)
Potentially there are also separate conditions set on "failed to reach PEEP" and "failed to reach Pi" to within certain tolerances.
(all these alarm limits should be user configurable)
hope that helps
e
Erich Schulz,?mbbs, mba, fanzca
0410 277 408
On Tue, 14 Apr 2020 at 09:50, Marcelo Varanda via
<mv_email= [email protected]> wrote:
I first integrated a pressure sensor based on NXP 7002.
Its analog values, once read from ATD,? ranges from 0 to 613 (integer number).
Someone provided a formula where those values are translated to -3.57 to 41.08 BANANAS.
I mean BANANAS because one individual calls it cmH2O and a seconds InchH2O.
Anyways... once I implemented the integration nobody questioned the values being displayed nor the alarm thresholds hardcoded to 4 for low and 35 for high BANANAS.
Now we are up to replace NXP 7002 for pressure to a BMX280. In a normal world we KEEP THE SAME UNITIES. So my logical approach is to keep? the very same -3.57 to 41.08 BANANAS range regardless the sensor we are using for PRESSURE (I am not talking about Flow
sensor).
Therefore, if there is any objection please step in and clarify.
Thanks,
MV
which provides voltages that transpates to integer values
|
Thanks Dave, but the other questions still stand:
What method do you recommend to establish a baseline to calculate the coefficients ? I guess a same controller monitoring sensors in pipers with different diameter will need different coefficients in order to get same result.
|
Generally there is a calibration stage.
Open to air =0,
Hose in x cm in bucket of water with expiration allows calibration to matching pressure.?
On Wed., 15 Apr. 2020, 12:10 am Marcelo Varanda via , <mv_email= [email protected]> wrote: Thanks Dave, but the other questions still stand:
What method do you recommend to establish a baseline to calculate the coefficients ? I guess a same controller monitoring sensors in pipers with different diameter will need different coefficients in order to get same result.
|
I am not talking about a "dynamic" calibration (a zero reference for ambient pressure)
But a "calibration" about the physic aspects where the sensor is located.
For example:
? if the sensor is located in a wider pipe then its Tidal Volume would be greater for a same given pressure than when installed in a narrower pipe.
|
Sorry Marcelo, not completely following you but hopefully the following is groggily
It's more turbulence, bends and diameter changes that could effect pressure readings, rather than diameter when gas is flowing. (dynamic pressure)?
The critical peak and plateau pressures are recorded at end of inspiration so flow should be minimal (actually nil for formal plateau value measurent, static pressure)?
Calibration is your friend??
On Wed., 15 Apr. 2020, 12:44 am Marcelo Varanda via , <mv_email= [email protected]> wrote: I am not talking about a "dynamic" calibration (a zero reference for ambient pressure)
But a "calibration" about the physic aspects where the sensor is located.
For example:
? if the sensor is located in a wider pipe then its Tidal Volume would be greater for a same given pressure than when installed in a narrower pipe.
|
Thanks. Once I get the system (still with FedEx) I will play with it and I may better to understand the numbers I will be getting.
|
On Tue, Apr 14, 2020 at 07:10 AM, Marcelo Varanda wrote:
different diameter will need different coefficients in order to get same result.
Hi, Here is the information Dr. Schmidt created on orifice disc meter flow sensors.?
Tom, wb6b
|
I am playing with BMP now... it outputs 101,982.90 which makes sense (30.11 Inch of Mercury).
However, 101,982.90 Pascals converted to cmH2O is 1039.936.
How that scale fits in the requirement which expects range with 1 or 2 digits (-3 ~ 40)?
Plateau pressure: Limited to 35 cmH2O
Peak pressure< 2cmH2O + Plateau
(BTW... I guess the doc is wrong... should be low, right)?
|
Is that measuring absolute pressure (ie relative to a vacuum) ? In physiology we use relative (to atmospheric) pressure (a process to "zero" the sensor is common)
On Thu., 16 Apr. 2020, 6:29 am Marcelo Varanda via , <mv_email= [email protected]> wrote: I am playing with BMP now... it outputs 101,982.90 which makes sense (30.11 Inch of Mercury).
However, 101,982.90 Pascals converted to cmH2O is 1039.936.
How that scale fits in the requirement which expects range with 1 or 2 digits (-3 ~ 40)?
Plateau pressure: Limited to 35 cmH2O
Peak pressure< 2cmH2O + Plateau
(BTW... I guess the doc is wrong... should be low, right)?
|
Hi, now I understand what you¡¯re asking, when clinicians talk about it they are always talking about gauge pressure, that is the amount of the pressure that is above atmospheric. ?
Somewhere in your program, likely at the beginning, and then I have a way to do it after a pause also, you capture what is atmospheric pressure and then from then on you subtract it from the measurements of the PMP 280. that turns your pressures into gauge pressures. Does that make sense?
|
No, it does not. Well, in part. Zero'ing reference is one thing. We need to know the scales.
A variation of 1Pa does not mean 1 cmH2O.
So far people are referring pressures in cmH2O. But all physics I read the range they are referring to does not make? sense.
|
The "zero" pressure may need to be taken at regular intervals, if you are not doing that now, not just on start up as has been discussed in previous posts. Or if an ambient BMP280 sensors has not been included. However, it was stated in a post that the ventilator is a timed cycle design and the pressure sensor is not used in the actual control of the ventilator. In that case the absolute accuracy of the pressures may not be as much as an issue.?
Looking at January 2020 data at San Francisco airport, in one day the atmospheric pressure changed 0.2 inHg, or 10.4 cmH2o. over the whole month the atmospheric pressure varied by 0.87 inHg, or 30 cmH20.
Tom, wb6b
|
A standard atmosphere is 101 325 Pa or 1033.23 cm water (in absolute pressure). The conversion is 1 Pa equals 0.0101972 cm water, or 1 cm water equals?98.0665 Pa.
As Gordon indicated, once you know the air pressure in the room (in appropriate units), you can subtract that value to determine gauge pressure in the ventilator lines.
Maybe use a second sensor for external pressure, and then look at the difference between the two sensors for the gauge pressure inside the ventilator lines (again, making sure to use appropriate units).
-CB
|
OK... here is the problem:
I reset, get 101325 Pa and store it as my ref.
First read I get 101325, so my gauge is (101325 -101325) * 0.0101972 = 0
Second read I get 104978, then (104978 - 101325) *? 0.101972 = 372.5
Note the scale that I am talking about... expecting 1 or 2 digits and we are getting 3 digits to a small pressure difference.
|
On Wed, Apr 15, 2020 at 03:10 PM, Marcelo Varanda wrote:
I reset, get 101325 Pa and store it as my ref.
It might be possible that the sensor is reading hPa or kPa. The data sheet states the range of the sensor as in?300 ... 1100 hPa. Tom, wb6b
|
Nop... the sensor is providing the correct Pa values... matches with local Airport.
cmH2O range in the spec DOES NOT MAKE SENSE according to what I read.
With no help we are stuck here.
|
Marcelo Varanda