example

How to use the KIWI OSD video time inserter

Introduction

Most (analog) video cameras generate sixty (50 for PAL) images (fields) per second. However dependant on the recording system used, you may not get to see all those individual images (fields). This page gives examples of using KIWI OSD with both 'field' review and 'frame' review of a video recording, explaining how to determine an event time from the screen. Dave Gault (Blue Mountains, Australia) used a PC164 camera to record the times when a couple of LEDs (connected to GPS 1PPS) were lit.

A reminder (from Dr David Dunham) re timing astronomic occultations when the event occurs over several fields. "The geometric occultation occurs at the 25% level of unocculted intensity for a point source, due to Fresnel diffraction. If the star has a significant angular diameter, as is the case for most relatively bright K and M (orange and red) stars, that spreads out the diffraction effects so that the geometric event becomes nearly 50% of the unocculted intensity for the largest stars."

### HANDY HINT ### After starting the video recorder, always use the "info" button on KIWI OSD to enable the startup sequence that records position and date - this also clears any glitch conditions that may have been generated on the power supply when starting the video recorder!

Field replay Timing

Dave used his digital camcorder (Canon ZR65MC) to record the PC164. KIWI OSD records an incrementing field count on the bottom right of each field, you can see the following images were one field apart (#78162, #78163,#78164).

8:40:48.969 UTC = Beginning of exposure.

8:40:48.985 UTC = End of exposure.

If we see a video event within this field, it would have occurred between the above two times.

Therefore we would give the time of the exposure as being halfway between the above two times.

Time of exposure is thus: 8:40:48.977 UTC (plus or minus 8 milliseconds)

8:40:48.985 UTC = Beginning of exposure.

8:40:49.001 UTC = End of exposure.

Time of exposure is thus: 8:40:48.993 UTC (plus or minus 8 milliseconds)

8:40:49.001 UTC = Beginning of exposure.

8:40:49.018 UTC = End of exposure.

Time of exposure is thus: 8:40:49.009 UTC (plus or minus 8 milliseconds)

Note how in the above field #78163, the LED was "lit" for only one millisecond at the very end of the 16 ms exposure. With NTSC, a 1PPS LED appears to drift through the field as the seconds tick by. With PAL/SECAM the 1PPS stays constant to the field timing. Indeed, when first writing the OSD software, I thought there was a problem, because the 1's digit on the millisecond counters did not change. Only over a period of a few minutes did it change - showing the Quartz crystal calibration error in the video camera. However with NTSC, the 1's digits appear as a blur, watching the OSD in real time.

Dave made the following comments regarding his "field" experiments.

I have been investigating my camcorder and the more I use it the more impressed I am with it's performance and features.

I heard a hint on IOTA-Yahoo that an older model than mine played even fields in +frame advance and odd fields in -field advance. There is no hint of this in the manual so I gave it a go anyway and.... lo and behold mine does it too :-)

There is a bit of a trick to get to the target field as the change from +frame advance to -field advance can consume 3 to 7 fields so you have to go well past and sneak up on it real quiet like...

Frame replay Timing

In this experiment Dave used a laptop to record the PC164 video, using the Avermedia USB2.0 frame grabber. This saves images as frames rather than fields. This results in one of the two millisecond timers appearing as 2 superimposed numbers. However the other millisecond timer will appear 'distinct' because it does not change during a frame - and indeed gives us the middle of the exposure time.

The bottom of the video screen has this format:

HH:MM:SS EEEE OOOO FFFFFF (where)

HH:MM:SS = Hours, Minutes, Seconds UTC time

EEEE = latest Even field Vsync offset to UTC second (in milliseconds).

OOOO = latest Odd field Vsync offset to UTC second (in milliseconds).

FFFFFF = Contiguous field count since initial GPS sync

With most video cameras, the time of an event is bracketed by the Even and Odd Vsync times (in 'field' step mode). Vsync is the video sync pulse that denotes the top of the screen.

In frame viewing mode, each exposure has a duration of 34 mS, so if an event occurs within this frame, we can only give the time of the event as the 'middle' of the exposure (plus or minus) 17 mS.

When viewing in frame mode, the millisecond timestamps indicate the following (assuming your recording device shows both fields together on the single frame).

- The blurred counter indicates the beginning and end of the exposure.

- The 'distinct' counter is the middle of the exposure.

The following examples, have their timestamps explained in detail.

Even field counter is blurred because it reads 935 and 969 milliseconds.

09:02:53.935 UTC = Beginning of exposure.

09:02:53.969 UTC = End of exposure.

Odd field counter reads 952 milliseconds.

Exposure is therefore 09:02:53.952 (plus or minus) 17 msecs

Leds (at top of screen) become visible in this frame.

Seconds are blurred, because 53 and 54 are valid.

Even field counter is blurred because it reads 969 and 3 milliseconds.

09:02:53.969 UTC = Beginning of exposure.

09:02:54.003 UTC = End of exposure.

Odd field counter reads 986 milliseconds.

Exposure is therefore 09:02:53.986 (plus or minus) 17 msecs

Even field counter is blurred because it reads 3 and 36 milliseconds.

09:02:54.003 UTC = Beginning of exposure.

09:02:54.036 UTC = End of exposure.

Odd field counter reads 20 milliseconds.

Exposure is therefore 09:02:54.020 (plus or minus) 17 msecs

The second frame indicates the LEDs came on at 09:02:53.986 (plus or minus) 17 msecs.

Notice how the LEDs were not very bright in the 2nd frame (compared to the 3rd frame). Because LEDs can turn on very rapidly, this indicates it would have been nearer the end of the exposure that the LEDs came on, somewhere nearer 09:02:54.003

The actual time the LEDs would have come on is 09:02:54.000

The text in the pictures (at 90 degrees) is the screen of the PC program KIWI, and because this was being run on a laptop with an LCD screen, it is interesting to note, that even by 36 milliseconds into the second, the LCD screen was not showing any sign of the second having just ticked over. This would not happen on a CRT type screen, which does not suffer the latency of switching that a (especially in the cold) LCD display has. We know this latency is due to the LCD, because the left hand LED (in the above images) is driven by the "PC KIWI" software, the right hand LED is driven straight off the GPS 1PPS signal.

The number on the right of the display is the number of video fields since the GPS obtained FIX and the time code was integrity checked by the OSD. This number can be used to derive timings if the GPS timing information should falter.

KIWI OSD tests each PPS (pulse per second) signal from the GPS. If out of spec (due to interference or local receiver issues) the OSD will flash XXXXXXXX over top of the HH:MM:SS each odd second. We can see in the above example that the timer had been running for 19,060 fields (about five minutes and 18.0 seconds). Because the odd seconds in the OSD have not got XXXXXXXX superimposed, we do not need to make use of the field count to determine the time. We can be highly confident that the time displayed is correct.

The above example is how most frame advance VCR's show the OSD display. However some may show the two millisecond counters as being "clean", indicating that the VCR is only displaying every second field and not combining the 2 field images. So careful inspection of the display is required to see how your VCR or DV system displays the images. Step through a timing run, and note how the counters change each step. In the above example you can see how the field counter has the units blurred because it is showing both fields make up a single frame.

Note: The above images are heavily compressed JPG images, so the time display is not as "easy to read" as the original video, they were compressed to allow a fast web page.

KIWI OSD can auto detect the video format being used, so there are two font types used for displaying the text. An Italics font is used for NTSC, and a standard font for PAL/SECAM. So at a glance, one can see what video system was used for the recording.

Using the Backup Timing Feature:

The backup timing feature uses the OSD field counter to supply a time base independent of the GPS derived time. The other piece of information used is the initial time (at field #1) which is deemed more accurate than subsequent GPS timestamps, because it has a larger number of integrity checks made on it. The field rate from the camera is Quartz Crystal controlled, providing a short term timing standard good enough over short periods - if the subsequent GPS receiver timing is found to be in error.

Dave used KIWI OSD to time a Lunar Occultation, however at the end of the timing run, the OSD reported "ERROR: Use Field Count". This meant that one of the various "integrity timing systems" on the OSD found an error in the GPS receiver time information.

Dave firstly used his camcorder to locate the three fields where the Moon ran over top of the star.

10:46:26.009 field 11570 (star on)

10:46:26.025 field 11571 (star dimmed)

10:46:26.042 field 11572 (star off)

So are the times correct or just random numbers?

To find out we need to use the following formula:

Derived Time = Initial Time + (Field count difference / Field Rate)

Dave rewound the tape and found the initial timestamp to be 10:43:13.000 at field #1

Dave used the pre-determined field rate of his PC164C camera (see next section) of 59.9404 fields per second.

So grabbing the calculator we divide the difference in fields by 59.9404 (to give seconds) and add to initial time.

(11,572 - 1) / 59.9404 = 193.042 seconds = 3:13.042

10:43:13.000 Initial Time read off screen

3:13.042 Derived delta using Dave's PC164C rate of 59.9404

10:46:26.042 Derived timestamp

10:46:26.042 Actual timestamp read off screen

.000 Difference between actual and derived timestamp

We can see the two values agree exactly, so the fault that was detected would have occurred "after" our occultation! If the times were not in close agreement, we would use the "derived" time as being the more correct - when the OSD reports the GPS to be in error!

Determining camera field rate:

To make use of the backup timing system with KIWI OSD, we need to know the 'field rate' of the camera as accurate as possible. This is easily achieved to parts per million, using the following method. At this level of precision, we are measuring below the temperature coefficient of the camera quartz crystal - so make sure the temperature you measure at is similar to the temperature it will be used at.

To get to parts per million, we need to time the camera for at least 1 million milliseconds (approx 17 minutes).

We can use this formula:

Field Rate = Field Difference / (End Time - Start Time)

Dave Gault measured his PC164C camera at 22 DegC

FIELD

TIME COUNT COMMENTS

09:36:53.239 65470 After approx 18 minutes of recording

09:18:41.004 00001 Initial reference start time

18:12.235 65469 Diff = 1,092.235 seconds

Field rate = 65,469 / 1,092.235 = 59.940397 fields per second.

This number (59.9404) can be used by Dave with his PC164C

camera to derive the time in the future 'if' the GPS is

reported as having issues.

Although a single (at one temperature) 'camera rate' is often

good enough, to gain an insight into the behaviour of the camera

quartz crystal with respect temperature - the following is

recommended.

Dave repeated his experiment at two other temperatures, giving

this summary:

11 degC ( 51.8F) - 59.940393 fps (6.55 ppm fast to NTSC 59.94)

22 degC ( 71.6F) - 59.940397 fps (6.63 ppm fast to NTSC 59.94)

44 degC (111.2F) - 59.940432 fps (7.20 ppm fast to NTSC 59.94)

Relative rate:

11 degC ( 51.8F) = -0.08 ppm wrt 22 degC

22 degC ( 71.6F) = 0.00 (reference temperature)

44 degC (111.2F) = +0.57 ppm wrt 22 degC

fps = fields per second ppm = parts per million

These results tell us much about the quartz crystal in Dave's PC164C camera - it is a perfect 'AT' cut quartz crystal with extremely low frequency change over normal temperatures.

For a detailed understanding of the camera's temperature coefficient, you should make 3 measurements centred on 25 degC (77F) which is the inflection point of an 'AT' cut quartz crystal. Then 10degC above and below 25 degC (59F and 95F). Using the procedure above, you can use the difference in ppm numbers to determine the 'delta angle' your crystal is cut to, by referring to FIGURE 2. The curve that best matches your 3 readings can be used to predict the temperature behaviour of the camera.

The above example is for a NTSC camera, the same method can be used for a PAL camera - except the field rate should be very close to 50.000 fields per second.

Sharing one GPS with many OSD's

A useful consequence of the above backup system, is the possibility of using one GPS with a number of OSD's.

Consider if a person had three stations (but only one GPS receiver) then they would connect up the GPS to the first station they set-up. As soon as they had started recording to video, they would press the 'info' button on KIWI OSD. This will then (in about 20 seconds) give all the relevant data (position, altitude, GPS quality and date). As soon as it starts giving the the UTC time on the screen, you would remove the GPS. This will cause the UTC time on the video to freeze, however the "field counter" (derived from the video camera quartz crystal) now becomes the "clock" as it continues accurately counting.

You could now go to the 2nd station, set-up the gear and connect the GPS and proceed as above - then remove the GPS.

On the 3rd station you could leave the GPS connected throughout the event.

When reviewing tapes 1 and 2, you would need to do a bit of simple maths to recover the true UTC time, click here for details. Once the cameras have been calibrated (can be done afterwards), you can do precision timing (to the millisecond) even though NO gps receiver was present at the event.

This concept would have made more sense a few years ago (when GPS receivers were a lot more expensive). The cost of a suitable GPS receiver is now about $70 - $80, so it means if you have 3 stations you wanted to video-timestamp, you could save about $140 if you just used ONE gps to serve the three stations.

Determining the Video Camera Reaction Time

The following procedure, determines if your camera and KIWI OSD, correctly timestamp optical events.

On the circuit board of KIWI OSD there is a LED that flashes once per second. This is driven directly from the 1PPS signal from the GPS, so the instant it turns ON is the beginning of a new UTC second (accurate to a millionth of a second). A standard CCD camera takes 2 fields to process an image, the first field collects and integrates photons over 17mS (20mS for PAL). At the end of the first field, the electrons (converted from photons) are quickly transferred to a memory storage area in the camera. During the 'next' field these electrons are read out of the camera at normal video scan rate, to display or record.

To test that your camera behaves in the above way, make a short recording of the LED flashing, along with timestamps from KIWI OSD. On replay of the video, determine what time the LED first comes on. The following example is what Steve Messner (MN, USA) recorded with his "Watec 902H2 Ultimate" camera. Steve gives the timestamps for the video fields that were lit by the 1PPS LED. At first it looks like a list of random numbers, however they do tell us quite a bit of information about the camera and OSD's ability to accurately time an optical event - see below:

--LED flash #01--

.986-.003

.003-.019

--LED flash #02--

.987-.004

.004-.020

--LED flash #03--

.988-.005

.005-.021

--LED flash #04--

.989-.006

.006-.022

--LED flash #05--

.990-.007

.007-.023

--LED flash #06--

.991-.008

.008-.024

--LED flash #07--

.992-.009

.009-.025

--LED flash #08--

.993-.010

.010-.026

--LED flash #09--

.994--.011

.011-.027

--LED flash #10--

.995-.012

.012-.028

--LED flash #11--

.996-.013

.013-.030

--LED flash #12--

.997-.014

.014-.031

--LED flash #13--

.998-.015

.015-.032

--LED flash #14--

.982-.999

.999-.016

.016-.033

--LED flash #15--

.984-.001

.001-.018

.018-.034

--LED flash #16--

.985-.002

.002-.019

.019-.035

--LED flash #17--

.986-.003

.003-.020

.020-.037

--LED flash #18--

.988-.004

.004-.020

-----------------

Steve's first timestamp indicates the LED came on sometime between .986 and .003 which straight away tells us (because we know the answer should be .000) that the on-screen timestamps correctly bracket the optical event. We use the LED flash as the precision optical reference - to see if the timestamps make sense. This first timestamp also indicates to me that the jumper setting on the KIWI OSD pcb is correct. Because the Garmin GPS has been configured to give a 20ms pulse each second, if the jumper (JP1 on the pcb) was 'open' rather than 'closed' the microcontroller would use the falling edge of the 1PPS as the UTC reference. The correct setting for JP1 (when using a Garmin 18 GPS) is for JP1 to be closed, and we can see from Steve's first reading that the timestamp is NOT delayed by 20ms - so his KIWI OSD has JP1 set correctly.

The next thing to notice is how each second the field timestamp is generally 1 millisecond 'later' than the second before. This tells us (as well as each field duration being 16-17 milliseconds) that it is an EIA (monochrome NTSC) camera being used, which samples slightly slower than 60 fields per second. Click here for an explanation of why 59.94 fields per second. We can use this fact to our advantage, and wait for this "sliding window" to line up the beginning of the 1PPS LED flash with the END of a video field. The reason we choose the END of the video field, is that most cameras use the end of the optical field - if light intensity restricts the exposure time from the full 17ms. We can see in Steve's sample #14, where the field ends with a timestamp of 999 milliseconds. So we have the timestamp and a LED flash within one millisecond of each other. At this point one might say, isn't the timestamp 1 millisecond late? To answer this, we need to know that the timestamp is made at the Vertical Synchronizing pulse - which occurs about 1 millisecond "before" the end of the optical exposure. This is better explained here where an example from Walt Morgan shows how the LED flash can occur with a timestamp of 999 milliseconds.

So the above results from Steve Messner show his camera and OSD are able to timestamp optical events to within the stated accuracy for KIWI OSD of +/- 1 millisecond, without requiring any other test gear or equipment.

Most cameras should give results similar to the above, except for "integrating cameras". Gerhard Dangl (Austria) has a Watec integrating camera (greater sensitivity achieved by camera internally stacking fields) that has a one frame delay (40ms) when used in non integrating mode. Gerhard shows this 40ms (camera reaction time) on this page. Because of this delay (caused by the way the integrating camera works), Gerhard needs to subtract 40ms from the KIWI OSD timestamps given on the screen. It is assumed that all integrating cameras operate this way (when not adding fields).

However all other cameras (PC164C etc) should work the same as Steve Messner's Watec, and so the Personal Equation (PE) of the camera and OSD is basically zero milliseconds, and the time can be read directly off the screen.

Screen Shots of GPS data

On the top left is the Deluo GPS, which connects to the white box (containing KIWI OSD). The two gold connectors are video IN and OUT. The red switch is the "info" switch. Notice how the OSD is connected in series (but wired in parallel) with the RS232 to USB converter. So Dave just plugs the USB connector into the laptop, which powers the GPS and OSD. This provides simultaneous use of the GPS for the laptop navigation software, and the OSD for time stamping video. A very neat and innovative timing and navigation system - to hunt asteroid shadows in the great Australian outback.