Visual clock with millisecond display refresh rate

Question

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!

Answer 1

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.)

Answer 2

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.

Answer 3

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).