Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Getting different indications from parallel-connected stopwatches -- why?

Status
Not open for further replies.

Buzzed Aldrin

New Member
The system shown is to time an athlete running a sprint. At the starting end, the runner releases the start button to create a 0.5 sec pulse to the reed relays to start the digital stopwatches.

When the runner breaks the light beam at the finish line, the photo sensor outputs a 0.5 sec pulse to stop the timing.

3 stopwatches are used to verify accuracy, i.e. if all stopwatches agree, then I consider the system to be accurate.

PROBLEM: The stopwatches often don't agree -- The displays can be different by up to 0.04 seconds (40 ms).

=> I would like to know what could cause the different stopwatch indications?

Additional info:

1. At first I thought the problem was due to a transient current imbalance between the inputs to the 3 relays causing them to not operate the stopwatches at the same time, but this would cause a repeatable time difference affecting the same stopwatch(es), no? The time differences occur randomly -- any of the stopwatches can be faster or slower, from zero to +/-0.04 seconds, than the other 2 stopwatches for any timing instance.

2. I can tell that the stopwatches do not start / stop at the same instant, based on mis-synchronized "beep" sound, so the problem is not with the stopwatches themselves. They all use the same basic chip and circuitry, which is accurate to about 3 sec per day which is much less than the time differences.

3. Response time of the reed relays is only 0.5 ms, also much less than the time differences, so the relays are probably not an issue.

Any help appreciated!

Schematic.png
 
Welcome to ETO.

My first thoughts are:
1 Using a 5v regulator to control the voltage of a pulse sounds like a bad idea. The pulse rise time at the output of the regulator could be slow causing erratic operation of the relays.
2 Does the 5v regulator have the appropriate decoupling capacitors? The output could be oscillating causing erratic operation of the relays.
3 You would be better to do away with the 5v regulator and the relays and use transistors to switch the stop watches.

JimB
 
Yep, the regulator arrangement is a generally bad idea, not knowing the output rise time (regulator spec doesn't say). But I eliminated the regulator and still got erratic readings between the stopwatches.

I removed 2 stopwatches from the circuit, and directly compared them by triggering from a common switch. It turns out that the time differences are caused by delays in the stopwatches themselves, specifically the start / stop action, probably due to debouncing delay. The delays are not related to clock accuracy of the stopwatches since the max difference between them is .04 sec regardless whether the elapsed time is 5 seconds or 5 minutes, i.e. all the error comes from the start / stop action.

Had I not assumed the stopwatches to be "perfect," and recognized this source of error early on, I would've checked out the stopwatches per above before inserting into the circuit and wondering what's going on, oh well.

I can't bypass the debouncing or any other feature since the whole stopwatch circuit is on a single potted chip.... but no big deal, since .04 sec max difference is actually only .02 max error for a single stopwatch which is the intended configuration, good enough.
 
Your probably right the debounce could well bit it, you might be able to common all the stopwatches and use 1 reed relay to reduce the discrepancy.
 
If it is the software debounce then there's not much you can do except build your own stopwatches. In the built ones, the detection of the first contact would start/stop the watch and no second pulse would be allowed until 20mS has passed to allow for debounce.

Mike.
 
Just an idea, I've never tried this with xtal oscillators like you'd find in a stopwatch, however if you just connect the grounds together the 2 oscillators being very close in freq may pull together to the same freq, if the debounce is software done then this would match the readings (but then the relays might take slightly diffo times to energise).
 
just a thought that the higher voltage - in most cases !!! not all - speeds up things - but your clocks likely are of a fixed supply - so the idea of "voltage calibration" might be not doable

another point is to use your set as a black box and train a fuzzy logic to guess correct time (requires a better timing circuit against what to train - and if you have that better timing circuit in hand then why to train the worse one ??)

if your watches are halted at trailing edge of that 0.5s - as i assume from "debouncing" - it must be accurate 500ms

how you drive the herkons anyway everything in nature takes a least energy path also the coils as total set of 3 - why not use mosfets or (diode voltage-ramps -- not good if the STOP inputs are voltage driven at ??? threshold at near signal ground ???)

. . . if all your stopwatches are deviating to the same side from the actual/correct time - from statistics point of view - how using 3 of them improves anything

. . . unless they are pre calibrated to be at the same tolerance window - and their "actuating" systems would be isolated and also calibrated to be in the same tolerance window - - - - - - - - - only then paralleling of them gives you advance of greater failure-/fault tolerance e.g. the odds for all 3 systems failing the same time ... ?1/8-th e.g 12.5% - in other words - using 3 parallel systems is 4 times as reliable as using just 1 - where the odds of working also failing is 50% . . . in a first approach - as compared against the longest. operational time from the set of similar systems - if we assume the similarity with demographic age pyramids e.g. the faults per unit time reducing among the "long livers" - we get semi rhombic triangular lifespan distribution
pop_pyramid_grouped_annotated-900x503.png

where the preference of using parallel systems becomes more justified (also more close to presented percentages - 12.5 & 50) at the end of the service life

so if you don't know the distribution you can not assume the ramp down time is long enough to justify system cost of 3x or 2x against 1x
___________________

if you intend to get to the market -- notice the approvals http://www.finishlynx.com/about-us/reference-and-approval-letters/

maybe : 18.5 Introduction to Time Transfer
Many applications require different clocks at different locations to be set to the same time (synchronization), or to run at the same rate (syntonization). A common application is to transfer time from one location and synchronize a clock at another location. This requires a 1 pulse per second (pps) output referenced to UTC. Once we have an on-time pulse, we know the arrival time of each second and can syntonize a local clock by making it run at the same rate. However, we still must know the time-of-day before we can synchronize the clock. For example, is it 12:31:38 or 12:31:48? To get the time-of-day, we need a time code referenced to UTC. A time code provides the UTC hour, minute, and second, and often provides date information like month, day, and year.
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top