Now I'm going to turn my attention to the software for the stand-alone controller shown in the previous post.
Before I ever started working on the UI for the device, the first order of business was to get the code needed to actually perform it's primary function written.
So I knew that the timing resolution needed to be very high because the items being sensed may pass by at > 3000 feet-per-second or about 915 meters per second. With 1 foot between the screen stages, at 4000 feet-per-second, it takes 250us to travel 1 foot... The Arduino is clocking at 16Mhz, so if I set the timer prescaler to divide by 8, the timer will increment at 2Mhz.
I wrote special fast timer and stopwatch classes that ended up with a 1 microsecond resolution, instead of the 4 microsecond resolution of the standard micros() function. Internally, however, the stopwatch timer had a resolution of 500 nano-seconds (billionths of a second) or 1/2000000.
The implementation is over here. It should work on an Arduino Uno and Mega.
Now that I have a fast timer, I can actually start timing things. Here is the Chronograph screen class:
Call SetScreenLEDState() to turn the IR emitters on or off. Each stage can be independently controlled, but it's not surfaced in this class. Once, timingFinished goes to true, you can call GetScreenData or GetVelocityData to read the actual timing information.
Remember, I said that the timer resolution is 1us, and the screens are 1 foot apart so to get the actual feet-per-second, simply divide 1000000.0 by the elapsed number of microseconds. If it took 250us travel between two of the screens, that would be 4000 feet-per-second, so 1000000.0 / 250 = 4000. A combination of the physical dimensions and proper timer setup, makes the calculations very fast and simple.
Oh, those CheckTimingStarted() and CheckTimingFinished() functions? Those are used by the Event loop class to check for certain break-out states or events. I'll cover the event loop later. The whole idea of the event loop was to keep the UI fully responsive and functional even while timing. The actual screen timing is done in interrupt routines, so that part is fully pre-emptive.
Initial tests were done by standing the screens up vertically and dropping an object through them. Since the acceleration of gravity is a known constant, 32.3 ft/s2 (9.8 m/s2), it's easy to calculate the expected timings.. except that the second screen stage will always be faster than the first since the object is accelerating. Also, the timing is effectively an average because it cannot measure instantaneous speed. So, using equations like these, I figured out what I should expect for timings. I should see timings that result in about 5.7 feet-per-second. That is precisely what I was seeing with a little variance for inconsistent drop heights.
Next up, we'll start to look at the UI, event loop, and the touch-screen.