The Perfect Shot Timer

[LOKNLOD]

Not to beleaguer the point but when you consider this, please consider "accuracy" and "repeatability" separately.
A less-than-precise but very repeatable (reproducible?) timer can judge an event accurately if the same timer is used for all participants, for example.

Technically, if it were very repeatable, it would be very precise, but could still be somewhat less accurate.

[RoyGBiv]

Technically, if it were very repeatable, it would be very precise, but could still be somewhat less accurate.

Eggzactly

[schult]

Don't most of the atomic clock watches only use the broadcast to correct the drift, syncrhonizing periodically, vs. taking some sort of constant feed? I have a casio watch somewhere (not a Gshock) with the atomic feature, and it was just an aid in setting it and keeping it synced, IIRC. I'm not sure how that type of setup would help with a shot timer?

Yes, this is pretty much why I'm not sure that option would work. It might be possible to do something with it anyway, if your local clock is accurate enough to span the gap between updates. Even then, I don't think the broadcast time is intended for anything better than second-level accuracy. GPS might be able to do better.

[schult]

Good news! I found an easily sourced part that I had missed before -- it turns out that Abracon makes some MEMS oscillators that should work. Problem solved.

[EMC]

Good news! I found an easily sourced part that I had missed before -- it turns out that Abracon makes some MEMS oscillators that should work. Problem solved.

Very cool. Looking forward to the results.

[Bradlykf]

Good news! I found an easily sourced part that I had missed before -- it turns out that Abracon makes some MEMS oscillators that should work. Problem solved.

That's awesome. Keep the updates comming

[LHS]

Consider my interest piqued.

[Fiddler]

I know I'm necro-ing a really old thread here - and I'm just a hobbyist without the experience of many of you engineering types --- but I do have a working shot timer on my Arduino Uno. 200 shot limit, no particular limit on length of string, par times, sensitivity, echo rejection, buzzer volume...

It has some flaws in timing - but on the short timescales we use it for the timing issues don't seem to create enough drift to cause a difference. Shows up on the millisecond scale, but not really in tenths or hundredths so much. Honestly, I use it all the time and it works well enough for practice.

I'm hosting the code on Codebender - although I'm thinking I may move it to Google Code.

Anyway - my version may not be up to snuff, but it was fun to play around with and it actually seems to be working pretty well for me. Figured I should share.


FWIW - I'm tinkering around with the code for a version that stores all settings and strings to an SD card, however it's too big for the 32k of flash memory on an Uno. I'm thinking I'll use a Teensy or a Due. Who knows how long before I actually scratch that all the way together so I can share it though.

[Fiddler]

Putting up a short video demonstration: http://youtu.be/lpuMynV3e8k

Yeah - that enclosure is a sugru monstrosity in all its glory. Sorry.

[ToddG]

That is awesome!

Regarding multiple PARs, you said something like "it adds to the last PAR" for each subsequent one. Can you explain? It seems to me the benefit of having multiple PARs would be at places like LE agencies for their qualifications. You could program the times for an entire qual into the device and have it jump to the next appropriate time automatically instead of having to change the PAR manually ten times during each qual.

The SD card thing is great. I have to imagine that's monstrously more simple than Bluetooth on both the timer and computer/download side.

Thanks for sharing and I hope it continues to develop!