I am trying to learn by reading other posts here and in some cases building stuff to test my working knowledge about what I "think" I learned. I know I can use a photo transister to measure when a light is on/off or use a magnetic reed switch to test open/closed on any of the digital input pins. What I am unclear of is how fast the microcontroller can it sense these changes? For example if I have a magnet on a bike wheel I can "count" how many revolutions with a switch ( I realize this example is slow ), but is there a rate where the "counter" will start missing a closed switch? If i use a emmitter / receiver pair to measure pulses of light ( like inside a mouse ) is there a rate where the samples will begin to be inaccurate?
And in the opposite direction .. how fast can I measure changes on the digital pins and what is the fastest way to measure the changes on a digital pin.
Where I am going with this is to have TWO photo diodes on two different input pins and compare the times that both diodes sense a beam of light. I can use pulsein() to sense a pulse on first diode and micros() to timestamp the pulse then pulsein() to sense the pulse on the second diode and micros() to timestamp that one then a little math to get the difference in time between when the pulses come in and then calculate the speed. I just don't have a feel for how fast execution of functions happens within a program. For example if something is traveling very fast past two beams of light how long it takes to execute the sensing determines how far apart to put the sensors. When I say very fast try 62,830 feet/second ( when I did the math for what I was trying to do I went DAMN that is faster than I thought ). How far will it travel during the execution time of the program functions so I don't miss the second pulse?
When I say very fast try 62,830 feet/second ( when I did the math for what I was trying to do I went DAMN that is faster than I thought ).
Are you sure of your math? 62,830 foot/seconds is equal to 42,838.64 miles per hour! That is faster than Earth escape velocity. What could you possible be trying to measure that moves that fast?
When I say very fast try 62,830 feet/second ( when I did the math for what I was trying to do I went DAMN that is faster than I thought ).
Yours:
Are you sure of your math? 62,830 foot/seconds is equal to 42,838.64 miles per hour! That is faster than Earth escape velocity. What could you possible be trying to measure that moves that fast?
is possible I am wrong ... lets see .. Rotary Laser ... 1000ft range .. 600rpm
circumference = 1000ft X 2 X 3.14 = 3280feet
rotational speed is 600rpm so beam travels 3280feet 600times in a minutes or 3768000feet/min or 62800feet/second or 62.8feet/millisecond or .0628feet/microsecond or .75inches/microsecond
Assuming that 1000feet range and 600rpm (easy enough to measure rotational speed with only one photo diode) it will take the rotating laser 16microseconds to travel 12inches around the circle or 32microseconds to travel 24inches. However if only the 24inches between photodiodes is known ... could I measure the distance from the center by counting how long it takes for the laser to travel the 24inches?
I am thinking that micros() isn't accurate enough to get an accurate time measurment as it will always be multiple of 4 microseconds.
There might be some geometry I am forgetting about but I think what I was asking about is still valid How long does it take to do the functions and how long does it take to register the change in state of the digital pin. How slow does the event need to occur to be to be assured that EVERY event gets measured?
Well single machine instructions take about 62 nsec when using a 16Mhz clock. Register response to bit changes would be limited by the clock rate of the chip. However there is overhead programming time for all useful software functions and as you know the micros() function has a 4us resolution.
For real high speed event timing it's best to utilize external digital logic chips to build a high speed counter that could be clocked at say 50Mhz and have one photosensor start the counter and the second one stop the counter and then have the Arduino read the count value and reset the external counter for the next timing event. It would take just a couple of chips and a crystal oscillator to create such a critter.
The ATmega has built-in counters and timers... Perhaps use the light sensors to trigger interrupts. On the first one, reset a timer. On the second, save the timer value.
For real high speed event timing it's best to utilize external digital logic chips to build a high speed counter that could be clocked at say 50Mhz and have one photosensor start the counter and the second one stop the counter and then have the Arduino read the count value and reset the external counter for the next timing event. It would take just a couple of chips and a crystal oscillator to create such a critter.
The laser was the easiest way for me to experiment with the pulsein() I was reading about. I will look at building external logic on breadboard and using my UNO to control/reset the chips as you said. Endless fun with parts
Johnwasser said:
The ATmega has built-in counters and timers... Perhaps use the light sensors to trigger interrupts. On the first one, reset a timer. On the second, save the timer value.
This was what I was trying to do in the first place. But not using interrupts. In the laser example the actual first attempt had the two sensing diodes 4 INCHES apart and I was only 30 FEET from the laser (backyard) and trying to use millis() to compare the two events .. even with micros() none of the readings I got made any sense .. like I said .. there is some geometry I am forgetting about radians arc seconds etc that I didn't factor in .. but it was just an experiment to compare two sensed beams without actually haveing two transmitters aimed perfectly at two diodes. I think what I built would have worked for something as slow as a race car passing two transmitters at 400mph and breaking the beams to my breadboard. The rest was a quest for further understanding.
The on-chip timers have an external input but I don't think you can use it to gate a count which is what you need here.
Timer 1 can directly capture a count (no sluggish software problems). It can also be configured to run at the same speed as the processor. The key-phrase is "input capture". As luck would have it, I'm working on a library that turns timer 1 into a high-speed pulse timer.
Is a 1 / 16000000 = 0.0625 microsecond resolution enough? I think that comes out to a distance of 3.5 feet.
