Page last updated: February 2010
Kiwi OSD was in production from 2005 - 2009
Click this LINK for KIWI OSD instructions: https://sites.google.com/site/kiwiosd/example
Over time these pages will be expanded to link to the many studies people have made with KIWI OSD.
KIWI OSD (On Screen Display) is a project to allow precision
time-stamping of video, using GPS derived time. It introduces a level of
integrity timing not seen before (or even used) on existing
video inserters. It's also the world's first GPS timing OSD to
use a single low cost microcontroller to do all the timing and
An example of KIWI OSD timing a star reappearing from behind a
waning moon. The precision timing of this event allows
refinement of the Moon's profile.
We can read the time directly from the screen. The optical exposure
began at 17:54:02.528 and ended at 17:54:02.545 - a 17msec exposure,
implying a NTSC camera was used. This was field number 15,078 since the
GPS was sync'd to the video stream.
KIWI OSD - has the following features:
Auto detects and operates in NTSC, PAL, SECAM and MESECAM
(or monochrome versions of the preceeding) formats.
The bottom of the video screen has this format:
HH:MM:SS EEEE OOOO FFFFFF
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
( 6 digits allow 4.6 hours @ NTSC rate before counter rollover ).
( 6 digits allow 5.5 hours @ PAL rate before counter rollover ).
With most video cameras, the time of an event is bracketed by
the above two Vsync times.
The following four picture montage shows in 17 millisecond steps
(exposures) when a star appears from behind the Moon. The
gradual 'turn on' is due to the Fresnel Diffraction Effect at
the moon's limb.
Kiwi OSD measures every 1PPS from the GPS, if out of spec, the HH:MM:SS
will thereafter flash at a 1Hz rate, alerting the user not to trust the
time and use the contiguous field count for subsequent timing.
If the GPS (for whatever reason) does stammer, the camera field rate is
good enough over short periods to provide "backup" timing.
KIWI OSD goes through an extensive sync and check before using the GPS
timing data. It requires 10 self consistent readings in full FIX mode
before it starts. Thereafter, it ignores the NMEA data and only uses
the 1PPS for incrementing time - which is integrity checked against the
OSD quartz timing for errors (like the Garmin 35 missing 1PPS pulse,
or the Garmin 16 multiple pulses).
The first UTC "second transition" that occurs after the self
consistency check, is used to designate field number 1. This
provides a known time reference that can be used for any
subsequent time determination if the GPS 1PPS is reported as
going out of spec. The field rate from the camera is Xtal
controlled, and so provides a stable "clock" if the GPS time
signal is affected by interference, multipath or lack of
The reason KIWI OSD ignores the NMEA serial data after initial
FIX, is because experience has shown that it is the NMEA data
that is more likely to have timing errors as the GPS goes in and
out of FIX. This is when the CPU of the GPS is working the
hardest, and so errors like latency in serial transmission creep
in, or just plain "blunders" from multipath or interference. The
1PPS on the other hand tends to be more stable (except in some
Garmins) being driven by a temperature compensated XTAL when the
GPS has lost FIX.
After you have finished the timing run, pressing the "info"
switch requests that Kiwi OSD wait for the first valid GPS fix -
and then compare its internal clock to the GPS. If they agree,
a message "PREVIOUS TIMES OK" is displayed on screen. If GPS
does not agree, "ERROR: USE FIELD COUNT" is displayed, alerting
the user that there has been a previous GPS glitch, and to use
the video field count to extract timing information.
Pressing the "info" switch after reading the above summary,
gives the OSD chip a RESET, and so another timing run is
Kiwi OSD has informative messages describing what is happening,
and whether there is a fault, eg "RS232 OR 1PPS ABSENT".
At initial GPS sync - the following data is displayed:
- Latitude and Longitude (degrees and decimal minutes)
- Fix Status (non zero for valid FIX)
- Number of Satellites being used
- HDOP (Horizontal Dilution of Precision)
- Height of GPS aerial
- "M" for height units in metres.
- Geoidal separation (if GPS has an inbuilt table of values)
- UTC Date (DD MM YYYY)
GPS receivers can present the height data in two different
Here are 2 examples taken from KIWI OSD at my location.
DELUO (Evermore Chipset) displayed this line of info
1 07 1.5 00010.2 M 08.5
Where: 1=FIX, 07=satellites used, 1.5=HDOP, 10.2=Hgt,
M=Hgt in metres, 8.5=geoidal separation
Because the geoidal separation value is displayed here, this
means the GPS has a model of the difference between the WGS84
ellipsoid and Mean Sea Level. So the 10.2 metre value will
therefore be the height above "Mean Sea Level". So at my
location the Evermore has a value of 8.5 metres as the
difference between MSL and the WGS84 ellipsoid.
Motorola (GT+) displayed this line of Info
1 06 1.3 17.3 M
Notice there is NO value shown after the "M", this means the
Motorola does not have a table for geoidal separation, therefore
the 17.3 height value is the WGS84 value, NOT the height above
Mean Sea Level.
The "geoidal separation" accuracy varies between GPS units.
The Evermore says 8.5 metres, Trimble 11 metres, and the
Garmin 18 as 9.1 metres for my location. A small difference
compared to the normal 10 metre standard deviation for height
determination with standard GPS devices.
Because of the large number of GPS receivers out there now, the
KIWI OSD project is restricting itself to only using the Garmin 18
modules at the present time. It becomes too difficult to keep
up with other models - all with their own quirks.
Because the NMEA standard allows for variable length data, KIWI
OSD software allows for this - so latitude and longitude is
displayed to whatever resolution the GPS transmits. This also
applies to the display of number of satellites used, HDOP
(Horizontal Dilution of Precision) and height data.
HINT: Reducing the number of sentences to the bare minimum (GGA
and RMC only) improves the timing quality of the GPS over having
all NMEA sentences enabled.
Because the software requires 10 self consistent times from the
GPS, the code does not use the NMEA checksum, so the checksum
can either be present or not, and not affect the OSD.
Which edge of the 1PPS is aligned to UTC, can be selected
allowing either LOW to HIGH (most common) or HIGH to LOW (less
common) as the 1PPS reference for timing.
Initial Setting up:
Connect KIWI OSD to a power supply, camera to video IN
and a TV/monitor to video OUT.
You should have the words "RS232 OR 1PPS ABSENT" at the bottom
of the screen. You can adjust the overlay intensity with the
trimpot. Do not adjust the OSD intensity too bright - it will
upset the tracking of VCR's if OSD text is too bright.
Now connect Garmin 18, the GPS may take up to 5 minutes to
get a FIX, the screen will continue to display the words
"RS232 OR 1PPS ABSENT" until such time as a FIX is obtained.
Once the GPS has a FIX, the screen will go through the sequence
as described in the above text.
Things to do:
You may want to verify the OSD wiring by comparing the OSD time
with WWV, the audio "tick" from WWV should be at the same time
the two millisecond counters appear to blank out and the LED pulses.
This verifies the OSD is using the correct edge of the 1PPS.
Leave the circuit running for several hours, if "XXXXXXXX" is
flashing over the HH:MM:SS, this indicates the 1PPS was detected
as being too short or long at some stage - probably caused by
"noise" getting into your wiring or external electrical
interference into the GPS.
If the HH:MM:SS time freezes, the OSD is not receiving 1PPS signals
from the GPS.
Use a VCR to tape the OSD for 17 minutes or so. Then replay the
beginning to get the time when the "Field Counter" was
one, and the field count and time at the end of the recording.
Use these numbers to calculate your camera "field rate" so that
you can determine any timing situations in the future when the
OSD indicates the GPS information is invalid or corrupted.
An example of KIWI OSD, doing precision Astronomic Timing.
Depending on your video monitor - you should be able to
see the faint disc of the Moon that the star has just appeared
from under. The precision time of this image would be:
17:54:02.536 UTC (plus or minus 8 milliseconds).
Images on this page courtesy of Dave Gault, Blue Mountains, Australia - thanks Dave!
Kiwi OSD homepage