Timing accuracy & Interrupts

I have an idea for a project and just want to make sure the Spark was the right fit for microcontroller.

I want my device to begin a timer and measure how long it takes for any one of multiple sensors to detect impact.

  1. Can the Spark record this timing down to the millisecond?
  2. How many vibration sensors can I put on the Spark?
  3. Will they sense in an interrupt fashion where the code can keep running and count the time to impact each sensor individually so I can report a summary?
  4. How do I accommodate for latency in wire length between the sensors and Spark? Its likely to be a few meters (do I need signal amplification?)

Would it be better to have a small microcontroller at each sensor location with an I2C bus connecting back to the Spark?

infinity and beyond! Down to the nanoseconds :slight_smile:

16! That's how many digital inputs the Spark Core has :smile:

You can implement 12 interrupt routines:
http://docs.spark.io/firmware/#interrupts-attachinterrupt

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.

1 Like

All yeses! These are the best kind of answers!

Thanks @BDub! you are a great value in the forum.

A few questions regarding the interrupts.

  1. 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?
  2. 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?
  3. 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” ?

@scsc_tech, I am going to beat @BDub to the reply, muahaha! :stuck_out_tongue:

  1. 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:
  1. 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.

  2. 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. :smile:

1 Like

thanks @peekay123

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)

@BDub’s the man! Keep us updated as you progress. Cool project! :smile:

Thanks!

Maybe I can get the code to randomize the neopixel color so blue targets are good guys and amber targets are bad guys and it records your accuracy for shooting only bad guys! :smile:

2 Likes

Glad to see you guys continued the discussion!

Here's some randomizing code as well :smile:

1 Like

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.

1 Like