# Visual clock with millisecond display refresh rate

I need to create a millisecond capable visual clock - I will use the clock for visual frame synchronization of multiple cameras. I found this project but it seems to use a LED display that only has resolution of one 1/100th of a second. Not sure if the digits can be shifted to show milliseconds.

I guess I need to use LED instead of LCD display because of the ms refresh rate? Can someone help with my project please? I am a SW programmer and have zero experience in HW programming. So I am new to Arduino too - I have not done any project at all yet. I do own neither Arduino nor LED display.

Thanks!

• What is the project for? Take another project an modify it. It only really needs to show the right mills when you stop it so don't worry about the refresh rate. Commented Aug 13, 2014 at 9:54
• Thanks for the clarifications. What is the maximum time you would need to measure? I have seen this done with a ring of white LEDs going around in a circle. Commented Aug 13, 2014 at 10:51
• Most cameras run at 50 of 60 frames per second. That means that 2 numbers appear during the recording of one frame. If those numbers are e.g. 6 and 7, the frame will probably show something like a 8. In other cases weird thinks will appear in the last segment, rendering it completely useless, and giving you only 1/10th of a second accuracy. You could use the 7-segment for the first few numbers and a circle of leds for the 1/100th seconds. I'd suggest buying an arduino with more pins than the arduino uno, as you'd need quit a few pins for all those leds. Commented Aug 13, 2014 at 15:22
• @Gerben: You are one order of magnitude too big - 60 Hz yields 16ms resolution which is aprox. 1/100th of a second. But I want to get 16x more accurate - from 16ms to 1ms. The idea of having circle of LEDs is nice though - I could have one circle for 1/100th digit and one for 1/1000th (ms) digit. I could at least measure the exposure time like that if more LEDs shine within one circle. Commented Aug 13, 2014 at 19:58
• Unless you have high speed cameras, I don't see the point. Also cameras have a "rolling shutter" creating inaccurate led-readings. Commented Aug 14, 2014 at 11:08

You need to define the parameters of the problem more clearly.

First, and most importantly, what is the shutterspeed you'll be using? If it's longer than 1 ms, then you can't use a 7-segment display to show the MS count, since the camera shutter would be open for multiple values.

Even if your shutterspeed is a single MS, your shutter won't be synchronized with your timer, so sometimes the shutter will be open when the display switches. That can even happen with the seconds digit of your time display.

If you're using a video camera, assume the frame rate is 60 fps, which gives a likely shutterspeed somewhere around 16.6 ms. That's way too long to display ms time values using 7-segment displays.

The ring of LED idea is good, but I would tweak it.

Here's what I would do: Build an LED clock to display whole number seconds. Don't multiplex, use latches and drive each 7-segment display constantly. (There are off-the-shelf CMOS chips that are latching 7-segment drivers.) If you only care about the 1s digit of the second value, only use 1 7-segment display. That will make things easier to wire.

Use 3 rings or columns of 10 LEDs for the MS display: tenths, hundredths, and thousandths. I would lean towards using columns since it would be visually easier to read.

The display will show your seconds as numbers, and 3 columns of 10 LEDs, showing the sub-second time range in 10ths, 100ths, and 1000ths. If the shutter opening spans multiple MS, as it will very likely do, all the LEDs that represent the sub-second time will be lit in the image, so you will get a nice clean visual image of the time SPAN that the shutter was open (All the LEDs from the start to the end of the shutter opening will be lit.)

You could drive the 3 columns of LEDs using 3 4017 divide-by-10 counters. These chips have both a 1-of-10- output, which will drive an LED, and a count/10 output, which would feed the next stage.

Write Arduino code that generates a short positive pulse every MS. Feed that into the clock input of the 4017 driving the thousandths digit. Feed the out/10 output of that chip to the clock input of the hundredths 4017, and the output of the hundredths 4017 into the clock input of the tenths 4017.

You can drive the whole ms display with 2 Arduino lines: The ms clock, and a reset line tied to all your 4017 counters' reset lines. To start timing, first pulse the reset line to zero them all out, then start your ms clock.

My CMOS cookbook doesn't say how much current the 4017 will put out to it's 1-of-10 outputs, but I bet it's enough to drive a display LED directly. You could wire all 10 LEDs in each column as common cathode, with a single current limiting resistor between each column's common cathode and ground.

You could probably set up a timer pin on the Arduino to generate a millisecond pulsed output, but that's not something I've learned how to do yet.

Occasionally you'll get a whole second 7-segment display with 2 different values captured in a frame, but that will be rare, and you will be able to figure out what happened from the frames immediately before and after it. (Previous frame shows a 5. Current frame shows a 5 and a 6 superimposed, so it's a mess. Conclusion, this frame shows the end of second 5 and the beginning of second 6.)

• Thanks for a very long and valuable answer! As I am new to HW I dont even know what a HW "counter" (like the 4017) is. So to bypass the counter I guess I could connect everything directly to GPIO outputs on the Arduino board itself? If I would do all in LED without 7-segment (40 LEDs) does that mean I need 40 GPIO pins + 1 for the input voltage? Which board can provide 41 or at least 31 pins (I could omit the seconds probably)? Commented Aug 15, 2014 at 15:04
• I mean, since I am a SW programmer it would be easier for me to implement all the necessary logic in SW only without any integrated circuits (HW counters etc.). Commented Aug 15, 2014 at 15:23
• Yes, you would need 40 pins to do it directly from the Arduino, plus 7 pins for the 7-segment display. Do yourself a favor and buy a copy of the "CMOS Cookbook." It's very helpful for stuff like this. Commented Aug 15, 2014 at 15:40
• I'm a programmer too, but I don't think you will be able to do that. You'd need 47 logic lines. The chip I mention, the 4017, is very easy to use. You give it a clocked input, and it sends a logic 1 to 1 of 10 outputs, and switches outputs on each pulse of the clock. Then it resets back to the beginning and starts again. It also has an output that is a clock count that's 1/10 of the input frequency. Check this link for an explanation of using the 4017: doctronics.co.uk/4017.htm Commented Aug 15, 2014 at 15:43
• It might be counterintuitive, but it's actually easier to do this sort of project with ICs. You will drive yourself nuts trying to wire up 47 output lines to an Arduino, then troubleshoot everything. The Mega 2560 does have enough I/O lines, but then you won't be able to do much else with the board. Commented Aug 15, 2014 at 15:49

I think Duncan C's 'user interface' is excellent. It is clean, simple and elegant.

Using individual LEDs is much better than digits. IMHO it is much more flexible, and avoids the ambiguity of digits. +1 for the concept.

However, I would make it 'softer', and use a lot fewer components.

By going 'softer' you could have more flexibility, which would give you the ability to expand the useful resolution of the 'clock'.

Duncan C made a very important point that digits are useless if a digit changes during the photograph. However, that is still a potential problem with the three lines of LEDs. When the exposure time is longer than the duration of the 'lower digit' line of LEDs, information is lost.

Certainly Duncan C's design could be speeded up or slowed down to adjust for that, but it has a built in resolution limit because it counts in 10's. Imposing the digital idea of '10' on an analogue system (which is similar to a child's abacus) loses some of three inherent flexibility in the fundamental superiority (in this case) of an analogue display. I suggest making it 'soft' so that the system can be 'tweaked' in software after the electronics are completed.

Instead of fixed function decade counters, use shift registers . Then there is complete flexibility to change the 'user interface' in software.

To reduce the number of components use shift registers designed to drive LEDs.

For example, Texas instruments make many LED-drivers. The lowest cost ones, in Dual-In-Line packages (which can be used in a breadboard, and so would be easier to prototype) that I found on RS were TLC5916/TLC5917. Each device drives 8 LEDs, so Duncan C's design would use 4. This is more expensive than decade counters. However, I think the cost (about 5GBP) may be worth it.

One benefit is they are 'constant current' drivers, and so eliminate the current-limiting resistors on each LED. Each device uses one resistor to program the current for all 8 LEDs. That won't save much money, but it will save a lot of wiring.

These shift registers are fed a pattern of data bits, one at a time, using a second 'clock' signal to tell the shift-register when the data bit is valid. Toggling the clock loads the data bit. So you could cascade them, end-to-end, exactly like cascaded counters. To reduce the CPU load, the input to the chain of shift registers could be loaded autonomously, 8 bits at a time by using the SPI peripheral in the Arduino.

Alternatively, you could use 4 pins to load data simultaneously, with one pin driving a shared clock. Those shift registers can operate much faster than even Arduino assembler (upto 30MHz/bit). So this needn't take much time.

The outputs of the shift registers do not change until a further signal is sent. Then they all change output simultaneously. So your cameras won't be confused by seeing the data being loaded.

So there is more software complexity than cascaded counters. However, there is no constraints on what data they show. For example, you might decide that you would like 20 LEDs worth of resolution, so that cameras have a wider exposure time and the frames can still be synchronised or 'positioned' relative to one another in time.

Anther advantage of this 'soft' behaviour is, you could add lots more LEDs and get pretty much any resolution you might need, using exactly the same hardware technology.

This approach shares an advantage of Duncan C's design. Time is indicated by discrete points of light, and not shape. So it should be relatively straightforward to use image processing to process images. That might be very important if the cameras are video cameras.

Edit:
To clarify a few points.

It is purely software which determines the behaviour of the LEDs in a shift-register based approach. Hence it is practical and straightforward, to simulate decade counters. So the 'user interface' can not be worse.

The complexity of a chain of shift-registers is the same as decade counters, if you want to use them that way. However for a few pins more, the shift registers could be loaded independently, which might have some benefits.

Using constant current LED drivers reduces the number of resistors to wire by a factor of 8. TI and others sell devices with 16 and 24 LED drivers, so the number of packages might be reduced.

The decade counter has a built in restriction. Not suprising, it gives no more than 10% resolution. However if you need 5%, it can't do it.

The shift-register-based electronics could emulate a 'clock face', so if 5% is needed, use 20 LEDs for that part. If 1% is required, add some more shift registers and LEDs

Summary:
Duncan C's concept of using an 'analogue abacus' display is, IMHO, a more robust user interface than LED Arabic digits.

However, IMHO a hard-wired implementation using decade counters is an unnecessary restriction, limiting resolution. Shift registers make the display 'soft'. Wiring up shift registers is the same complexity as decade counters. Using LED drivers, saves a lot of wiring.

• Your suggestion of shift registers would be more flexible, but I think it's waaaay past the OP's comfort level in working with hardware. He pushed back on my suggestion, which would use 3 chips and very few connections. As for the resolution of my suggestion, if the shutter is open for more than 1 MS, a range of LEDs will be lit, showing the start and end time for the shutter. If the shutter is open for 5 ms, 5 of the thousandths LEDs will be lit in the picture. Beyond 10 MS, you'd lose MS level of detail because all the "thousandths" LEDs would be lit, but I think that's ok. Commented Aug 16, 2014 at 13:35
• @DuncanC - 1. Using shift registers can be exactly the same electronic complexity as decade counters. 2. using LED drivers removes 26 components, which is quite a lot of extra work to build and debug. 3. Kozuch wrote "I am a SW programmer ...", so shifting complexity to software appears to be the most helpful thing to do. 4. It is straightforward to emulate a decade counter in software, so the user interface can't be inferior. I agree with your analysis. My point is extremely simple and pertinent; the user interface is improvable to suit the application after the electronics completed. Commented Aug 16, 2014 at 13:53
• your point on flexibility is well taken. What 26 components does your approach remove, though? If you read my description carefully, I recommend driving the LEDs directly from the 4017, and wiring each set of 10 LEDs with a common cathode and a single current limiting resistor between each common cathode and ground. Only one LED in each "decade" will ever be lit, so that should work perfectly. My design needs 3 chips, 3 resistors, and 30 LEDs. LED drivers would eliminate the 3 resistors, but use several more ICs. Commented Aug 16, 2014 at 18:37
• Actually, after reading up on the TLC5916/17 (and the related TLC5925) I found that it was both a shift register AND LED driver in 1 package. Each chip takes a resistor that sets the output current for all the LEDs it drives, so I think the component count would be nearly identical. If you used two TLC5925's (each of which will drive 16 LEDs) then you'd need one less current limiting resistor, but a difference of 1 or 2 resistors is not important. Commented Aug 16, 2014 at 21:17

Assuming you camera's shutter is fast enough to capture a display updating every millisecond:
Get individual digit seven segment (LED) displays. The ones with multiple digits together are usually multiplexed and that might not work for your application(the multiplexing frequency would have to be higher than 1000 Hz or only one/some digits would be visible at a time). Using single digit displays, hook up each digit to a shift register such as the 74HC595. Then you only need two Arduino pins to control each digit (Data and clock, latch clock can be shared by all the shift registers). Use protection resistors for each individual segment diode and mind the current limit of the shift register when lighting all segments.

At 16 MHz you have 16000 instructions per ms so that shouldn't be an issue.

I don't know too much about LCD displays, but with LED's and a latching shift register transitions should be update pretty much instantaneous(from a millisecond perspective).

• No, you have 16,000 instructions per ms. (16,000,000 per seconds / 1,000 ms in a second) Commented Aug 14, 2014 at 2:12
• Yes, you are right, corrected the answer(you are also welcome to edit). Commented Aug 14, 2014 at 10:56
• You wrote "The ones with with multiple digits together are usually multiplexed and that won't work for you application(only one digit will be visible at a time)". That is likely incorrect and may be misleading. For example if the application is a video camera, the 'shutter speed' is 16ms or 20ms. Even at 1/1000 of a second, one millisecond, there is enough time to draw all of the digits of a multiplexed LED, so that it looks fine. Commented Aug 14, 2014 at 16:40
• Except that the display update isn't going to be synchronized with the shutter, so when the display changes, a given picture will likely contain lit LEDs from both values. If the shutterspeed is 20 MS and the clock changes it's screen every MS, the picture will capture 20 different values, which will be an indecipherable mess. Commented Aug 14, 2014 at 22:01
• @gbulmer I didn't consider the shutter time, but it would have to be fast for a 1 ms timer display. I usually multiplex at 200 Hz(whole display) when done on the MCU, to avoid burning too many CPU cycles, but of course it could be done faster or with a dedicated driver IC multiplexing at 1000+Hz. I updated the answer to be more elaborate. Commented Aug 16, 2014 at 6:22