Spent the day trying to figure out whether I can use a cheap barometric pressure sensor to detect (altitude) compression depth and speed for a low-cost CPR training monitor. I googled it and got essentially zero hits for the basic concept, so I'm forging into unknown territory. Later this evening I'll have the code fleshed out and see if the concept even basically works.
Actually, I'm using TWO of the cheap sensors: one for a static reference inside the body, one hot-glued to the chest of the manikin. The reference is to account for pressure changes during compression cycles. I'm running the parts right to the limit of detection to get 1cm accuracy, which is just barely enough.
It may be a complete bust, but it's fun trying. If this version blows, the next up to bat is an accelerometer from a cellphone.
FWIW, a limit switch would probably be the cheapest for mass production, however it would be on/off. That's it, it would tell you that you got Enough compression, but not if you went too far. (Unrealistically, it wouldn't have a too far unless you hit it hard enough to break.)
Pneumatically, it would be more realistic, and expensive if you had a lung bladder inside, and that would also provide feedback through the mouth. The flow rate, and pressure could be measured normally, with simple pneumatic gauges.
I'm not sure what the sensitivity on the Barometer would be. I don't have one with me for testing.
Yeah, I'm actually trying to measure compression depth, as well as speed. I've seen EMTs use something that looks like a cellphone between their hand and the chest during training, which I'm guessing is using an accelerometer. I don't want the students fiddling around and wasting time dropping a cellphone; I want them
focused on the job at hand, so I need it built inside the manikin and fairly reliable.
So far, the pressure sensor is a bust. The best resolution I can get at 120 strokes per minute is ~2 inches, and I was hoping for a centimeter (half inch) accuracy. I can get the accuracy in the right range, but not fast enough. I have to average too many samples to get those extra two bits. For something designed to measure meters, I didn't do too bad.
The math for real-time conversion of acceleration to distance is
ugly << link. I'm using a reasonably fast processor, so I should be able to crunch the numbers quickly enough. I only have one accelerometer on hand, so I guess that's the next one to play with. Dunno if it's as accurate as the ADXL330 they used in the article, as I don't have any decent data on it.
There's not a lot of room inside the manikin, what with that spring in the center of the chest. I'd put something inside the spring tower, but it doesn't want to come apart. It's a two-piece plastic assembly with a spring inside, and it's been fighting me. If I break it, I buy another one.
