# Testing camera framerate variability by filming clock time

I would like to test the framerate variation from nominal value in a range of consumer video cameras. For this I intend to film some sort of high frequency clock and compare the displayed clock time with the ideal time derived from the selected camera framerate.

Regarding specs, at the moment I'm not looking to measure errors lower than 1ms from the specified frame interval. The framerates I will test for are likely to be within 30 to 300 fps. In the future I might want to measure microseconds errors in 1000Hz cameras.

So I think I just need to be able to film a "clock" display device with a 1000Hz refresh rate and at least 1ms time precision. My first idea was to use a set of 10 LED, using them as bits, which would allow me to encode 1024 values. The LED pattern would be updated every millisecond with the corresponding value, and I could measure the actual time interval between frames.

However I feel there is probably something already existing doing what I want.

Are there existing devices displaying time down to the millisecond and with a 1000Hz refresh rate ?

I am aware that the results will also depend on the use of a rolling shutter by the camera and the ability to manually change shutter speed.

• If you build/buy some kind of a clock and start filming it you need to think about this: How do you know what the variability of the clock is? It is possible that the camera will keep better time than your reference clock. If they are both derived from crystals they will drift with time and temperature. – Will Jun 12 '14 at 14:13
• I'm not sure what exactly you're hoping to prove here. Also, I'd suggest you need to film something that's a significant multiple faster than the FPS, EG a white disc with a dot that rotates once every frame, so if the dot visibly moves you know it's drifting. However, the problem of making your reference accurate enough in the first place (again, it needs to be several times more accurate than the thing you're trying to measure) is not a simple one. – John U Jun 12 '14 at 14:33
• @John U, I'm trying to evaluate the systematic and random error in framerate of the "high speed" feature of consumer cameras. I'm using video to derive velocities of filmed objects and although spatial distortions are well documented, time distortions not so much. – Joan Charmant Jun 12 '14 at 15:14
• In that case I'd suggest that any drift in the device is going to be well within the error bounds of your measurement method anyway. – John U Jun 12 '14 at 16:31

## 1 Answer

A binary count is going to be very hard to read in the image; if the exposure time is long enough to capture more than one displayed value, the reading will be very ambiguous.

I recently had a need to measure both shutter delay (latency) and exposure time for various DSLR cameras. I set up a microprocessor to drive an array of 40 LEDs (NOT multiplexed!) counting at a 10 kHz rate. The display is arranged such that each digit is represented by a column of 10 LEDs, where each column only has one LED on at a time.

100ms 10ms 1ms 0.1ms
o    o    o    o  9
o    o    o    o  8
o    o    o    o  7
o    o    o    o  6
o    o    o    o  5
o    o    o    o  4
o    o    o    o  3
o    o    o    o  2
o    o    o    o  1
o    o    o    o  0


Looking at the resulting images, it's actually quite easy to estimate both the starting and ending times of each exposure.

ADDITIONAL

A variation of this idea might be more appropriate for your application of evaluating the accuracy/stability of the video frame rate. Simply put the 40 (or whatever number) LEDs in a straight line (or maybe in a circle) and turn them on one at a time at 40× the nominal video frame rate. Viewing the resulting video directly will show you in real time whether the rate is correct and how much it is varying.

• Wow, that is great. If the image has a column with several lit LEDs you can infer the start and end time of the exposure. Did you decide to go this route because of a lack of existing device suitable for the job ? – Joan Charmant Jun 12 '14 at 15:22
• Would multiplexing be a problem if the multiplex rate were 10KHz or faster [I'm assuming if you wanted to measure times shorter than 0.1ms you'd have another digit]? I know a lot of display-multiplexing code uses refresh rates that are designed for viewing by stationary human eyeballs, but multiplexing a display that size at even 100KHz would likely be easier than using 28 or 40 I/O pins. – supercat Jun 12 '14 at 15:54
• @JoanCharmant: Yes, plus I had a PIC32MX demo board that had plenty of I/O to drive all of the LEDs directly. It only took a few hours to wire it up and another day to sort out the programming. I really didn't even try to shop for a COTS device. – Dave Tweed Jun 12 '14 at 16:07
• @supercat: As long as the multiplex rate is fast enough to scan several times during each exposure, it should be fine. Frankly, I didn't want to even think about it, and I had a microprocessor at hand that had enough I/O to do everything directly. – Dave Tweed Jun 12 '14 at 16:09