I’ve been working on a way to triangulate a bullet impact on a steel plate using an arduino uno. The speed of sound in the steel will be a conservative 220,000 in/sec. I desire a resolution of 1 inch. To obtain this I figure the three digital inputs will need to sample at-least every 4.55 microseconds. I plan to use high/low vibration detecting switches (http://www.dfrobot.com/index.php?route= … ltdmhB1n9o)
The idea is that with a solid connection to the plate a shock wave through the plate will trip these sensors and the event will be time stamped. This information will then be used for the triangulation calcs.
I plan on running a loop only to collect the three time stamps (should be faster to isolate this task right?). Once this is done the information will then be sent via Xbee to an arduino next to me where the actual triangulation calcs will be done by the second arduino.
My questions stem from a very basic understanding of these electronics and there capabilities.
As far a sampling rate will the arduino uno be able to meet this demand using the digital inputs?
With regards to the sensors I am using; Does anyone have any experience with digital (high/low) vibration sensors that may work better(if the ones I have are not good enough)? I started trying this with piezos and that proved to be tricky. I couldn’t even get a clean knock sensor working.
Any other concerns about something I may be missing would be great information as well!
As far a sampling rate will the arduino uno be able to meet this demand using the digital inputs?
I plan on running a loop only to collect the three time stamps (should be faster to isolate this task right?). Once this is done the information will then be sent via Xbee to an arduino next to me where the actual triangulation calcs will be done by the second arduino.
I think those vibration sensors have a swinging wire inside, and they are probably way too slow for your application. Do you have a data sheet that gives their frequency response?
I’ve had no problem using piezo transducers for similar applications, using an edge detector rather than analog sampling (as most do).
I emailed the seller asking for the frequency response of the sensor and await their reply.
I’m not familiar with edge detection rather than analog sampling. My hopes was to apply a simple time stamp and be done with it, but the fast speed of the wave in the steel is proving to make it a bit more cumbersome.
I dropped the piezo approach because I couldn’t get any repeatability out of the analog read to apply a basic knock sensor. This was done using the simple knock sensor code in the arduino tutorials using a piezo (SEN-10293) super glued to the steel. Also I have come to learn that the Uno’s analog read is much slower than the digital and because all I need for a time stamp is a High/low I decided to take this approach.
With regards to sensors and controllers I am trying to keep it cheap by using an arduino uno and affordable sensors. I feel like this is something that an arduino can do with the right setup.
To use the piezo follow it with an op-amp and a Voltage comparator. Or just a digital Schmidt trigger buffer/invert (74xx14) if the Voltage goes to a digital logic high value to shape the waveform into square digital edge. Then use the arduino digital input to detect and time the edge.
I would condition the piezo output as required and then use the digital inputs that have “Interrupt on Change” (IOC) capability. Setup the 16 bit timer/counter to run at 16 MHz and when each interrupt occurs read the count. When all 3 (or 4 as I’ve previously mentioned) interrupts have occurred you’ll have your time differences.
As for conditioning the piezos … the simplest I’ve seen are on the drum kits that use piezos as hit detectors and the Arduino as a MIDI controller. I’m not sold that the simplest provide enough protection to the Arduino pin but …
I’d add a one-shot to the piezo conditioner output or an impact may trigger a single interrupt so many times you use up all your latency processing one piezo.
lyndon:
I’d add a one-shot to the piezo conditioner output or an impact may trigger a single interrupt so many times you use up all your latency processing one piezo.
Agreed. That diagram schematic I posted does just that. The ecu clears the knock sensor value out when ready
Because you can’t know if the initial spike out of the piezo will be a positive or negative voltage, and because timing is important, I propose that a window comparator w/a pulse stretcher is the optimal conditioning circuit. Bias the piezo at Vcc/2 and detect excursions beyond +/- Vcc/4 … ???
Again keep in mind that for accuracy the absolute delay introduced by any circuit is not important, the relative delay (btw circuits) must be (nearly) equal.
I’ve been playing with the interrupts as Mee n Mac suggested. I have a code working to time stamp one sensor but I don’t understand how to add another while keeping them on the same time for time stamp comparison purposes.
At the moment I am using the sensors I listed above while I try to figure out how to make the piezos work. Lots of info on the topic thanks guys. I have an op amp knock sensor working through analog but what I’m trying to nail down is a comparator set up.
A concern I have is that I am using an UNO and it only has 2 interrupts. This set up clearly isn’t a true on/off. If i do get a comparator circuit working that would be a true on/off and then I could use any and all digital inputs to get the job done right?
Thanks for all the good info guys I’m learn much more than I expected to about this stuff. Great first real project I think!
The interested might want to read this PDF on the testing done to measure average Interrupt latency for various methods; pins 2/3 direct external, “pin change” Interrupts for various code versions. The end few (summary) pages are a must read. I’ll reserve further comment except for 2 points;
latency almost doesn’t matter so long it’s consistent, except that …
you need to find a way to detect and handle 2+ simultaneous interrupts (2 CCP units ?)
ATmega16/32U4 11. External Interrupts The External Interrupts are triggered by the INT6, INT3:0 pin or any of the PCINT7…0 pins. Observe that, if enabled, the interrupts will trigger even if the INT[6;3:0] or PCINT7…0 pins are configured as outputs. This feature provides a way of generating a software interrupt. The Pin change interrupt PCI0 will trigger if any enabled PCINT7:0 pin toggles. PCMSK0 Register control which pins contribute to the pin change interrupts. Pin change interrupts on PCINT7 …0 are detected asynchronously. This implies that these interrupts can be used for waking the part also from sleep modes other than Idle mode. The External Interrupts can be triggered by a falling or rising edge or a low level. This is set up as indicated in the specification for the External Interrupt Control Registers – EICRA (INT3:0) and EICRB (INT6). When the external interrupt is enabled and is configured as level triggered, the interrupt will trigger as long as the pin is held low. Note that recognition of falling or rising edge interrupts on INT6 requires the presence of an I/O clock, described in “System Clock and Clock Options” on page 27. Low level interrupts and the edge interrupt on INT3:0 are detected asynchronously. This implies that these interrupts can be used for waking the part also from sleep modes other than Idle mode. The I/O clock is halted in all sleep modes except Idle mode. Note that if a level triggered interrupt is used for wake-up from Power-down, the required level must be held long enough for the MCU to complete the wake-up to trigger the level interrupt. If the level disappears before the end of the Start-up Time, the MCU will still wake up, but no interrupt will be generated. The start-up time is defined by the SUT and CKSEL Fuses as described in “System Clock and Clock Options” on page 27. 14. 16-bit Timers/Counters (Timer/Counter1 and Timer/Counter3) The 16-bit Timer/Counter unit allows accurate program execution timing (event management), wave generation, and signal timing measurement. The main features are: • True 16-bit Design (i.e., Allows 16-bit PWM) • Three independent Output Compare Units • Double Buffered Output Compare Registers • One Input Capture Unit • Input Capture Noise Canceler • Clear Timer on Compare Match (Auto Reload) • Glitch-free, Phase Correct Pulse Width Modulator (PWM) • Variable PWM Period • Frequency Generator • External Event Counter • Ten independent interrupt sources (TOV1, OCF1A, OCF1B, OCF1C, ICF1, TOV3, OCF3A, OCF3B, OCF3C and ICF3)
Perhaps an upgrade in HW might make for a better solution ? Use 2 of the timers in external capture mode ? For that matter, what’s the longest time expected btw any 2 sensor “pings” ? Perhaps the two 8 bit counters of the Uno are sufficient ?
I don’t use an Arduino, but I do have a project that runs on a 16MHz Mega169 that accepts six simultaneous inputs on the Pin Change Interrupt pins. As far as I can tell it’s worked perfectly for years. The procedure is to set up what used to be called a “polled interrupt” structure (probably have some fancy name for it these days).
You link your ISR to the PCI and in the ISR poll the inputs to determine which pin triggered the interrupt and which edge it was. As long as you can get out of the ISR quickly, latency is measured in small numbers of microseconds and is exactly the same each time.
Mee_n_Mac:
The interested might want to read this PDF on the testing done to measure average Interrupt latency for various methods; pins 2/3 direct external, “pin change” Interrupts for various code versions. The end few (summary) pages are a must read. I’ll reserve further comment except for 2 points;
latency almost doesn’t matter so long it’s consistent, except that …
you need to find a way to detect and handle 2+ simultaneous interrupts (2 CCP units ?)
lyndon:
I don’t use an Arduino, but I do have a project that runs on a 16MHz Mega169 that accepts six simultaneous inputs on the Pin Change Interrupt pins. As far as I can tell it’s worked perfectly for years. The procedure is to set up what used to be called a “polled interrupt” structure (probably have some fancy name for it these days).
You link your ISR to the PCI and in the ISR poll the inputs to determine which pin triggered the interrupt and which edge it was. As long as you can get out of the ISR quickly, latency is measured in small numbers of microseconds and is exactly the same each time.
How does the AVR handle “simultaneous” interrupts ? I might assume it’s like PICs in that they pend, an indication remaining in some register, even if the ISR has momentarily turned off some global interrupt enable. The user code should then check that register before doing a clear of it and re-enabling all interrupts. I don’t think the hidden Arduino interrupt code normally does this and so, w/o modifications, later but close interrupts get lost.
The OP thinks he needs ~5 usec resolution, should be easily had w/a 62.5 nsec clock, but the link I posted had measured the Pin Change Interrupt “latency” (for a few C/C++ versions of “hidden” handler code) to be on the order of 13+ usec … w/o the user code for the ISR … much longer than I’d have guessed. Admittedly the “hidden” library code is finding out which pin changed and storing that, but if another interrupt happens only 1 usec after the 1’st ???
That’s why I’m wondering if 2 timers in capture mode might not be the better route, even if it means some more conditioning circuitry btw the piezo and the MCU … and maybe even a better MCU. I have to read up on the details of how AVRs time external events and how deep the storage of captured times is ? Then the MCU HW does the heavy lifting and the ISR can run a whopping number of usecs to fetch the captured times and see if they are a complete set. Background processing then does the calcs need to compute off-center distances and send/display that info.
One timer per input would be the ideal situation, but remember that you can always program the Arduino without using their libraries if performance is a problem.
lyndon:
… but remember that you can always program the Arduino without using their libraries if performance is a problem.
True enough but I get the feeling that the OP would rather drink a pint of bile than have to learn to program an AVR in Assembly. I'm stumped ATM as to which is the optimal path to recommend, SW interrupts to store timing btw sensors or using the CCP HW, meaning more external circuitry (perhaps) ?