Breath detecting with an environmental sensor

/

Turns you can do it. I’ve been wondering how I can detect people blowing into a trombone. As you do. A microphone is one possibility, but that involves analogue to digital conversion and sound processing and stuff. And owning a suitable microphone. I do however have a bunch of BMP20 environmental sensors. These contain an air pressure detector. They are supposed to be used for weather data and determining your height above sea level. Would it work for breath?

The answer is yes. If you put a sensor in a closed box (see above) and then blow into the box you can make a detectable difference to the pressure inside. All you have to do is sample the air pressure at the start and then look for a change of around 5 or so during gameplay.

It worked really well for a while. Then the BMP280 stopped working. I had a look in the box and discovered why. It was rather disgusting. Breathing into a box produces not just air, but a lot of water vapour too. The inside of the box and the sensor itself was covered in what you could politely call “dew” but was actually something slightly different. Trombones have a “spit valve” on one end to release all the stuff that accumulates. I’m happy to have proved the principle. I guess I could engineer some baffles or a waterproof membrane over the sensor to keep it dry, but the thought has occurred that in these virus laden times, passing around some thing that you take in turns to breath into might not be a great idea.

So I’m building a version of the controller that uses buttons rather than breathing.

Add graphs to your IoT projects

/

I’m building a trombone controller. And why not? I’m using a distance sensor to track the position of the trombone slide. The output is a bit noisy. But how noisy? A graph would help, but how do I get that? Very easily as it turns out. I just added a print statement to my Circuit Python application:

print(raw,",",average)

This prints out my raw and averaged values with a comma between them. Then I used Thonny to run the program in the trombone for a while and moved the slider. Then I stopped the program, copied the output of the terminal window into notepad and saved it with the file extension “.csv”. (Comma separated values).

Then I opened the file with Excel (other spreadsheets are available) and made the above graph. It shows how my rolling average (the red trace) cleans up a lot of noise but makes the values lag slightly (look at the how the red trace rises slightly after the blue one).

If you aren’t sure what your signals look like this is a very easy way to do it. The Arduino IDE has a graphing feature built in that I’ve used once or twice, but there’s nothing like dropping your values into a proper spreadsheet for analysis. And it is very easy to do using the magic of cut and paste.

Trombone Controller Fail

/

The beautiful distance sensor box that I made yesterday only has one problem. It just doesn’t work. When you put the tube over the distance sensor you get a fixed distance reading. I think it is something to do with reflection off the end of the pipe. Above you can see what happens to the light on the sensor, perhaps something similar is happening to the distance signal.

Oh well. Perhaps I should have tested this approach before I designed and printed the box, but I was concerned that to test the sensor I really had to have it mounted and aligned just right, and a proper box was the best way to do it. I just have to move the sensor outside the pipe and create a target. And anyway, it’s only a failure if you didn’t learn anything from it.

Trombone Controller Sensors

/

I’m supposed to be writing Chapter 6 of Begin to Code Cloud. But I keep been drawn towards designs for a trombone based game controller. Because of this game. I’ve bought a copy and it is hilarious. But I want to play it with something approaching a real trombone. To do that I’ll need a sensor to read the position of the trombone slide. First instinct was to use an ultrasonic distance sensor, so I wired one up and dropped out a bit of code. That’s the device on the top. The problem with this is that as the distances being measured increase the whole thing slows down, what with the time taken for the ultrasonic pulse to go out and bounce back. So I’ve switched to using lasers. The device on the bottom uses a laser-based sensor (which I love) which works very quickly at any distance.

I’m using the sensors from Circuit Python at the moment. I’m going to have to decide whether or not it can go fast enough to get smooth readings. Early tests indicate that it might be OK but the distance readings are a bit noisy. But I think it should work. And now back to chapter 6….