Close

Absolute is relative

A project log for COSV - Cam Open Source Ventilator

Roller cam based portable BVM ventilator.

daren-schwenkeDaren Schwenke 03/27/2020 at 03:539 Comments

We were looking at using cheap barometric pressure sensors, but the issue is they are absolute pressure sensors.  They are exceedingly sensitive and work within the range we need for both positive and negative pressure, but they read the pressure applied to them relative to a vacuum within the device. 

Because of this, to determine where '0' is with regards to your current ambient pressure, you need to take a sample with no pressure above or below ambient pressure applied.  Where you are in the world (altitude) will move this number as well.

But... if you were already connected to a patient, and providing pressure, and lost power for a split second you would no longer know where '0' was.  You would take your sample and your 'relative to startup' number would be offset then, and that is dangerous as now you could be doubling the airway pressure of the patient!

We just solved that.  Use four of them.

Put three on one side of a PCB and epoxy that board into the ports on the pitot tube we have already designed.  That gives you forward flow, reverse flow and pressure.  Now the trick is have a fourth sensor, and point it back at atmospheric pressure.

Now you have your zero point independent of what you read at startup and can accurately calculate what each of the sensors is reading relative to that.  You have just turned all your absolute pressure sensors into relative ones.

One remaining issue is that all of the sensors share an I2C address, but they also have a pin to change that address by 1.  So if we pull those all those pins low with resistors, and then cycle through pulling them high with something like an LED driver also on the same I2C bus, then we can read all of the sensors from the same address. 

Better solution, use a proper I2C translator such as the LTC4316. We have enough unique addresses with just one as we can hang two sensors off the I2C bus before the translator, and two off after it by setting the SDO pin on every other one. We added a second bus translator to do level shifting and allow moving the address of the whole package so you can have two of them on the same bus, or avoid something else with a static I2C address

Four wires, better resolution, faster updates, and the sensors are $3 each.

Still working on the best way to flip that address pin.

We are working on spinning up a PC board for this. Right now it looks like it's 16 mm by 40 mm to house the four sensors, two I2C bus translators, an Eeprom, and a voltage regulator. 

Those components will allow the device to work with both 5 volts and 3.3 volts seamlessly, and if needed, put more than one completed device on the same bus.  Thanks to @Steven.Carr for brainstorming this with me and coming up with this layout, and @harit trivedi for also working on the schematic and parts placement.

Discussions

Bharbour wrote 03/28/2020 at 00:06 point

Are you going to put in any redundancy on the sensors?

Looking at the sensors for that BMP388 part number, and they don't have a hose barb or anything. How are you planning on tying them into the pitot assemble?

  Are you sure? yes | no

Daren Schwenke wrote 03/28/2020 at 03:08 point

No.  If we want redundancy, we will use two whole units.  I thought about adding a second atmospheric sensor, but then we would need another pressure sensor, and we might as well double the other two.... it became silly.  We can just plug them both inline with each other if we need that.

The sensors are getting put on their own PCB and epoxied/bonded directly to the pickup.  No tubes, no barb's.  The pitot tube part is getting redesigned right now to accommodate this with a pocket to fit the board.

  Are you sure? yes | no

Bharbour wrote 03/27/2020 at 14:56 point

Daren, please look at page 53 of the data sheet on those BMP388 sensors. Bosch says they can't be used for life support applications. That may not be relevant in this situation, but may cause problems in purchasing significant numbers. I have been bitten by this before.

  Are you sure? yes | no

Daren Schwenke wrote 03/27/2020 at 15:03 point

Good to know.  I'm running it by someone who may be able to answer if it is relevant.

  Are you sure? yes | no

Daren Schwenke wrote 03/27/2020 at 21:17 point

For now, this appears to not be an issue.  Someone in the industry described that as boilerplate liability code and you're going to find it on pretty much everything we're using.

  Are you sure? yes | no

Jarrett wrote 03/27/2020 at 21:41 point

I does generally mean you're not going to be able to get UL listing (without jumping through some hoops), but you don't care about that, just yet

  Are you sure? yes | no

Daren Schwenke wrote 03/27/2020 at 22:08 point

@Jarrett we're generating a life support device that has a specified life of 14 days. I'm not sure that category even exists. :)

  Are you sure? yes | no

Bharbour wrote 03/27/2020 at 14:31 point

Check out the LTC4316 I2C address translator. It would allow you to talk to all 4 sensors with minimal overhead. They also make some bus switches that allow you to run multiple bus segments, but you have to configure the switch each time you want to change segment.

  Are you sure? yes | no

Daren Schwenke wrote 03/27/2020 at 14:34 point

Yep.  That is exactly what @Steven.Carr suggested.  I've already updated my post.  Thank you.

  Are you sure? yes | no