But you might be able to just poll your sensors very quickly. If you are all set with 12, go for interrupts. You may have some issues though…
Have a look at this interrupt driven pinewood derby code I wrote:
Electrons travel at the speed of light typically (well close to that anyways)… so wirelength only affects resistance of the wire, coupled with any capacitance on your input you can have an RC timeconstant affect… basically the slew rate of the signal transitions can be governed by this capacitance. Fortunately it’s really small… all you need to do is pull up your vibration sensor with a lower value resistor, say 1k ohm from the sensor input pin to 3V3. Then tie your vibration sensor from the sensor input to ground. When the sensor wiggles you’ll get a bunch of HIGH to LOW transitions.
I know bouncing can be a problem with these vibration sensors, you mentioned bouncing as an issue in your thread. Do you think it will accomodate these sensors?
You commented out your LED code at the bottom. Is it because that code was not operating successfully? In the documentation it says that delay will not work in an interrupt function. Maybe delayMicroseconds does?
In your header notes you mention D0, D1, D2, A0, A1, A3, A4 are all tied to one interrupt handler Is this going to cause a problem if I want more than 4 “lanes” ?
These sensors will bounce by their very nature - vibration sensing! You can easily add a delay in the interrupt service routine that makes use of millis() to effectively “remove” bounce. @chap, wrote a simple button interrupt debouncer recently:
You cannot call ANY delay function in an ISR and neither should you. The “delay” in @chap’s ISR uses the millis() counter instead of a delay to achieve the same thing.
I have not looked at the code @BDub is referring to but given that he’s pretty smart, then I would have to agree. Having a single ISR called for multi-pin changes just means having to do more work in that ISR to detect which pin(s) triggered the interrupt.
My question is whether you need debounce at all. What you need is to start a timer and then wait for the vibration sensors to react. Assuming that each sensor has no “noise”, that is ambient vibrations that set them off randomly, then you can record the time for a given sensor on the first “event” from that sensor, then ignore further events until you reset everything. So the ISR fires, looks at which pin changed states and records the time for that pin in a pin timer array. Once all times are recorded, then your cycle is complete. At least that’s what I guess your trying to do.
You may be right about not needing to worry about debounce too much. As long as it requires user intervention before the loop is allowed to sense those pins again, it will prevent it from running more than once.
I think @bdub’s code will work perfectly for my scenario. I am basically building an airsoft shot-timer where an operator would push a button, the code would delay for a random number of millisenconds before playing a sound, upon the sound playing, the shooters time to hit each target would be recorded. It would also change a NeoPixel on the target from green to red.
I then want the system to log the performance to a cloud service like Xively and differentiate each shooter somehow. (I can get into that stuff later)
So if my sensor/led “lane” cables are about 20-30’ long. Do I need any additional circuitry over on the lane side? I’m new to circuit design so I’m not sure when signal noise and interference become a problem. Or if power fluctuations at that distance are a factor.