Wireless sound/knock to USB HID spacebar signal.

Status
Not open for further replies.
T

TFritz

New member
I would like to create a long range wireless device that will translate the sound/shock from a starting pistol or an air horn ( possibly using NFR24L01 tranceivers and teensy(s)) to a receiving teensy that will output a HID keyboard spacebar signal to a computer to start software. Once this is figured out I would like to also incorporate a stopwatch device on the transmitting end that can store the time of day of each start signal sent.

I am a total newby to this stuff, but have some electronic experience. Anyone interested in helping?
 
If it's as simple as scanning for a loud impulse-like sound in a low-level background then you could start with the example code for a mono-peak meter:
File > Examples > Audio > Analysis > PeakMeterMono

Scanning for the value to rise above some threshold shouldn't be too hard.

If you need to limit to some portion of the audio spectrum then a low-res FFT object could be used (https://www.pjrc.com/teensy/gui/?info=AudioAnalyzeFFT256) but then defining what constitutes a valid trigger becomes the hard part.

You could pre-filter the audio before feeding it to a peak object to attenuate frequencies outside of the band you're interested in. This could be easier to 'tune' by altering the filter parameters than it would be to analyze the FFT bin data.
 
Oddson,

I think you understand what I am trying to do, but I am hoping to not have it continually scanning, but more like a discrete switching signal of some type at the instance the gun is fired or the air horn is activated. Could this be done with a simple Piezo device/Piezo switch with threshold set at some level that would screen out noises at lower levels than the sound of the gun/horn. I am thinking there must be a simple way to latch the sound to a digital output and then send that signal to the receiver wirelessly and translate that signal in to a HID spacebar.
 
Yes there is only a single sound detector. I am not sure the ESP8266 would have the range I am looking for.
 
Indeed the range should be better with NRF24 - or a LORA unit. And perhaps simpler ands more direct without making a network.

Wasn't sure of the distance - that's partly why I wondered about STOP signal after getting a remote start.

I was looking after such a noise event detector - but haven't gotten back to it yet. As oddson notes - there should be ways to begin that - as long as you can count on the magnitude or perhaps frequency to separate it from other noise that may intrude.
 
I know zero about wireless so I can't comment on that or on the appropriate protocol to transmit a simple trigger event over a short distance.

On the issue of translating an audio event into a trigger within your code...

Almost certainly you will want to use Paul's Audio Library.

The built-in ADC on any library compatible Teensy should be fine but you will need to learn the basics of the library and the Audio Design Tool.

Once you have the bare basics of this (which is all I have) you can connect the ADC object to the Peak object.

Auto-generate the starter code from that and then try to figure out how to use the read() function.

The mono Peak meter example file in the Teensyduino distribution will handle most of the same issues you will have to cover so you might want to start with that code:
File > Examples > Audio > Analysis > PeakMeterMono

Once you can follow how it works it should not be difficult to alter it to monitor the values between each read() you perform.

You need to set the time intervals depending on how responsive you need this too be (considering there's already a time delay from sound transmission of many milliseconds).

Also you will need to set a threshold value that indicates the signal intensity warrants firing your wireless event to the second teensy. You may wish your code to turn off for some time after an event is recognized (i.e. stop monitoring for events) to avoid retriggering from sound reflections etc. Could be as simple as a long delay command after the trigger is sent.

FYI - a piezo disc would do a fine job providing a signal but you have to condition the output to make it Teensy safe and to provide positive bias for the built in ADC. It might be easier to stick to a 3.3v MEMS microphone module (or something similar) that handles biasing and signal conditioning for you. My local brick and mortar store sells one for CND$7 so about five bucks US. I'm sure online they drop to a buck or two.
 
TFritz said:
...I am hoping to not have it continually scanning, but more like a discrete switching signal... I am thinking there must be a simple way to latch the sound to a digital output...
Click to expand...

For my thinking, your approach has the advantages of: less CPU demand (avoid continually scanning); simplicity (...there must be a simple way...); and letting the hardware do the heavy lifting (...like a discrete switching signal...).

The only piece of the puzzle that you needed was the "sound to MCU" thingy. First, I must say how I admire the skills/wisdom of the posters who gave advice:"...biasing and signal conditioning ..." and "...FFT object..." are topics that make my head spin! I'm not doubting them, because they are over my head! But sometimes less is more. So being a "less" kind of poster, let me focus on this aspect: "...latch the sound to a digital output..." That is all you want to do, so avoid anything concerning analog such as MEMS microphone, or really all audio in general. I'm in love with the Teensy Audio Library (really!), but you don't need it here. All you want is (IIUC): to know if the trigger sound in heard or not heard (latching to digital). For this task the hardware already exists. Google "arduino sound detection module" and the first pictured device (when I did the google on 2018-02-11 @ 6:11PM) will find its way to your snail-mailbox for less than a buck (USD $1).

I 'm only going by googled info, not from experience. Presumably this thing can be made to work; if so, you are golden. Meaning that the issue of ...defining what constitutes a valid trigger... is eliminated, or rather, is replaced by a precision trim-pot (dial-in your threshold the easy way). What I can say based on experience, is that the ESP8266 is reliable, Arduino IDE friendly, and has snazzy connection range. My project ran for 8 months without crashing before I re-purposed it.

Also, googling "arduino sound detection module" gives a link to a tutorial <<<one very minor and trivial gripe with the tutorial is where it says, "Sound is detected via a microphone and fed into an LM393 op amp." Ahem, the LM393 is a Dual Differential Comparator, NOT an op amp! ;+D >>> on using the module, which includes oh-so-short-and-sweet-code which takes care of keeping a GPIO in real-time agreement with the detection module. This makes your "...hoping to not have it continually scanning..." a matter of attaching an interrupt to a pin (I've never done this, but I think this is right!)

So my (remedial) opinion is: arduino sound detection module attached to a GPIO on the ESP8266 for the detect end. Then another ESP8266 to make the Teensy aware of the trigger sound (using a GPIO). (Although the ESP8266 is a WiFi device, linking 2 ESPs doesn't require a router if the ad-hoc mode is used.) Then the Teensy can use its USB and the Keyboard Library to send the space bar key-press to your PC. Time/Date stamping could be done at any point in the chain. Teensy would be my choice. Use EEPROM or SD depending on how much data is logged. A breadboard power supply lets you use a junk-drawer power adapter (6.5 Volts min, 12 Volts max). Total cost (not including power adapters, SD card, or PC) would be less than 24 bucks (delivered), using a Teensy LC, 2 ESP8266-12e, 2 power supply modules, and the detection module.
 
Beavis said:
For my thinking, your approach has the advantages of: less CPU demand (avoid continually scanning); simplicity (...there must be a simple way...); and letting the hardware do the heavy lifting (...like a discrete switching signal...).

The only piece of the puzzle that you needed was the "sound to MCU" thingy. First, I must say how I admire the skills/wisdom of the posters who gave advice:"...biasing and signal conditioning ..." and "...FFT object..." are topics that make my head spin! I'm not doubting them, because they are over my head! But sometimes less is more. So being a "less" kind of poster, let me focus on this aspect: "...latch the sound to a digital output..." That is all you want to do, so avoid anything concerning analog such as MEMS microphone, or really all audio in general. I'm in love with the Teensy Audio Library (really!), but you don't need it here. All you want is (IIUC): to know if the trigger sound in heard or not heard (latching to digital). For this task the hardware already exists. Google "arduino sound detection module" and the first pictured device (when I did the google on 2018-02-11 @ 6:11PM) will find its way to your snail-mailbox for less than a buck (USD $1).

I 'm only going by googled info, not from experience. Presumably this thing can be made to work; if so, you are golden. Meaning that the issue of ...defining what constitutes a valid trigger... is eliminated, or rather, is replaced by a precision trim-pot (dial-in your threshold the easy way). What I can say based on experience, is that the ESP8266 is reliable, Arduino IDE friendly, and has snazzy connection range. My project ran for 8 months without crashing before I re-purposed it.

Also, googling "arduino sound detection module" gives a link to a tutorial <<<one very minor and trivial gripe with the tutorial is where it says, "Sound is detected via a microphone and fed into an LM393 op amp." Ahem, the LM393 is a Dual Differential Comparator, NOT an op amp! ;+D >>> on using the module, which includes oh-so-short-and-sweet-code which takes care of keeping a GPIO in real-time agreement with the detection module. This makes your "...hoping to not have it continually scanning..." a matter of attaching an interrupt to a pin (I've never done this, but I think this is right!)

So my (remedial) opinion is: arduino sound detection module attached to a GPIO on the ESP8266 for the detect end. Then another ESP8266 to make the Teensy aware of the trigger sound (using a GPIO). (Although the ESP8266 is a WiFi device, linking 2 ESPs doesn't require a router if the ad-hoc mode is used.) Then the Teensy can use its USB and the Keyboard Library to send the space bar key-press to your PC. Time/Date stamping could be done at any point in the chain. Teensy would be my choice. Use EEPROM or SD depending on how much data is logged. A breadboard power supply lets you use a junk-drawer power adapter (6.5 Volts min, 12 Volts max). Total cost (not including power adapters, SD card, or PC) would be less than 24 bucks (delivered), using a Teensy LC, 2 ESP8266-12e, 2 power supply modules, and the detection module.
Click to expand...

Thank You for your feedback. You have confirmed the direction I was leaning. I am totally new to this and your feedback has given me confidence that the direction I was leaning may hold a solution for me.
 
That's great to hear, your feedback made the time taken in writing the post TOTALLY worth it!

If you do wind up getting the sound detection module that I linked to, let me know how it worked out. Actually, I'd be interested in hearing about how your project turns out, regardless of the approach that you settle on.

Cheers!
 
Before you build too much, I would suggest testing that sound detector in the actual environment you wish to monitor. It may work great. But it very likely will detect all sorts of other sounds or even vibrations from nearby movement.
 
Status
Not open for further replies.
Back
Top