Great! Can you point me to a good reference for coding a deceleration ramp?

I'm not aware of any reference off hand. The basic gist is that you arbitrarily slow down the motor as you approach your target point. There are a variety of ways to accomplish this. A first pass crude approach would be to pick a couple points prior to your target stopping point and reduce the motor speed first to 2/3 speed, then to 1/3 speed. The end goal is to have the motor come to a more controlled stop as it approaches it's target reducing overshoot and inaccuracies in where you stop. By adjusting the points at which you reduce motor speed and the amount of speed reduction you can fine tune your specific setup for optimal performance. You can also increase the number of deceleration points if you want to provide a smoother rate of deceleration, but that should have little affect on your end goal of stopping at a specific location. That goal could very well be accomplished with a single deceleration point.

PeterH

No, it's not at all cool and nowhere near as elegant as the other solutions being suggested. Basically you arrange the motor so that it stops in a consistent position. Probably, being a DC motor it will already have several positions that it likes to settle in due to the position of the magnets, and which one it falls into is just a game of roulette. If you bias the motor, for example by putting an eccentric cam with a sprung follower, you can arrange for it to always stop in the same place.

Thanks for all the help, folks. I'm getting closer...At the moment, my encoder pulse counter ("encPos" in my code above) appears to be giving me a HIGHER value than it should for a given number of motor rotations, even accounting for inertial overshoot. While this gives me hope that I'm not missing encoder transitions at this high rotation frequency (something I was originally worried about), I'm not sure what to make of it. Is it possible that I'm picking up "bounce" in my signal, causing the interrupt to trigger more frequently than it should?? I've seen references of bounce coming from hardware switches, although I'm unclear on whether it can happen in quadrature encoder signals as well?

In any event, If I can sort out the encoder signal to give me an accurate reading, then I'll use it to implement a crude deceleration ramp (thanks, jraskell.) If I can't tame the encoder, then I'll revert to holmes4's photoresistor method, which sounds very promising. I'll come back to update with progress...

I would not expect bounce but looking at the motor description it says it runs upto 1000 rpm with 480 pulses per revolution.

I've removed the motor gearbox, though, so I'm down to 48 counts per revolution of the motor output shaft. And I'm only listening to one encoder channel, so 24 counts per revolution. If I rotate the motor at 230 Hz, then I'm triggering the interrupt every 181 microseconds. I dug up this thread, where someone states that the Arduino can distinguish between 64 and 68us:http://arduino.cc/forum/index.php/topic,19671.0.html

Nevertheless, I hear your concerns. I'm definitely up there in frequency, which might produce an unreliable encoder signal.

A high wattage resistor can be installed in the braking loop if it is a high inertia load or it just plain stops too fast. Of course your motor may not have enough residual energy to work well with braking but it may get the number of encoder changes down to a useable level. You may have to use a relay contact to disconnect the motor from the controller when the brake is applied. The same relay will work N.O. to the brake and N.C. to the controller.