                  Emulating the "Totally Accurate Clock"
                             Tom Clark, W3IWI
                              April 14, 1996

       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

A number of people have expressed an interest in making clones of my "Totally 
Accurate Clock" (TAC). This note will document ways you can fabricate a 
simple, but functional version of the TAC with little more than an extra wire 
in the cable.

       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

HARDWARE DESCRIPTION:
The core of the TAC is a commercial OEM GPS receiver board. The boards that 
are supported are

  1. Motorola ONCORE BASIC and BASIC EVAL models
  2. Motorola ONCORE VP and VP EVAL
  3. Motorola ONCORE XT
  4. Garmin GPS-20 (and probably GPS-25, but it hasn't been tested)

To function as a TAC, I require that the receiver has

  a. Computer serial I/O - at least with NMEA messages at 4800 baud (and for 
     the ONCORE receivers, Motorola's proprietary binary protocol at 9600 
     baud).
  b. A 1 Pulse per second output nominally synchronized with the UTC second. 
     For the Motorola receivers, this means that either Option A (1 PPS 
     Output) or Option I (RAIM + 1PPS) must be installed; the EVAL 
     developer's kits have these options standard. The Garmin GPS-20 receiver 
     has 1 PPS as standard feature. The Motorola 1 PPS signal is 0.2 seconds 
     in duration and the Garmin 1 PPS is 0.1 seconds. Both have "TTL" level  
     1 PPS signals which rise zero to ~+5 volts at the nominal timing epoch. 
     
The TAC project uses stock receivers with one important addition - the 1 PPS 
signal is available for precise epoch timing by the user (usually on a BNC 
connector) and it is also sent to the attached computer. I have adopted the 
convention that the 1 PPS signal to the computer will be on the RS232 DCD 
handshaking line. The TAC-to-computer interface requires 4 wires (preferably 
shielded):

            FUNCTION	         RS232 with	      	 RS232 with
          		      25-pin connector	    with 9-pin connector
     GPS TXD from GPS	         pin #3		         pin #2
     GPS RXD to GPS	         pin #2		         pin #3
     1PPS from GPS (DCD)         pin #8		         pin #1
     Signal Ground	         pin #7		         pin #5
     Cable Shield	         pin #1		         pin #5
		
The GPS receivers also require the user to provide external DC power:

  * The Motorola ONCORE BASIC and XT (and the VP EVAL models in a metal box) 
     all have DC-to-DC converters and power regulators so that the user can 
     supply any supply voltage between +10VDC and about +30VDC. In this note 
     I will call this +12VDC.

  * The ONCORE VP and Garmin receivers require the user to provide regulated 
     +5VDC power and will be damaged if the wrong voltage is applied. This 
     can be easily generated by a 7805-type regulator chip.

All the GPS receivers have a multi-pin connector to supply power, provide 
computer I/O connections, and deliver the 1 PPS signal to the user. The 
Motorola BASIC and VP receivers use a 2x5 10-pin connector with pins on 0.1" 
centers; the user is warned that the BASIC and VP series of receivers use 
different connections and a receiver may be damaged if wiring for the wrong 
receiver type is used! The Motorola XT and VP EVAL receivers are housed in an 
extruded aluminum box and has a DB-9 connector. The Garmin receivers use a 
single-row 12-pin connector.

In addition to the power+I/O connector, all the receivers have a coaxial 
cable connector for an external antenna. +5VDC power is supplied on this 
connector for an antenna mounted RF preamplifier. All the receivers use a 
small MCX-series connectors, except for the metal-cased Motorola XT/VP EVAL 
models which use a BNC connector.

All the receivers except for the Motorola VP have RS232 voltage levels for 
their TXD/RXD serial I/O. The RS232 signals 'idle' at a voltage between -3 
and -10 volts. They go to a voltage between +3 and +10 volts when a data 
"one" is sent. The Motorola VP uses 'inverted TTL' levels, idling at +5V and 
going to zero with data. Thus normal computer RS232 voltages must be inverted 
and level shifted if you are using a VP-series board-level receiver.

Motorola sells a developer's version of the VP receiver called the VP EVAL. 
The VP EVAL version of the VP has an internal circuit board that provides the 
RS232 level conversion and a +12-to-+5 volt DC-to-DC power converter. The 
same mechanical package is sold by Motorola as the XT model, except that the 
XT apparently uses the older ONCORE BASIC board.

       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

SYNCHRONIZING THE COMPUTER:
The receivers all transmit time, date and position data to an attached com
puter via the RS232 link. For simplicity I have chosen to use the NMEA-0183 
(National Marine Electronics Association) standardized messages at 4800 baud. 
All GPS receivers have to develop precise timing in order to perform their 
navigation tasks. Each second they perform a lot of computations and then 
output the time and navigation results to the user. However, the user report 
is the lowest priority task, so the time-tag contained in the ASCII text in 
the NMEA message lags true UTC (Universal Time Coordinated) time by a fraction
of a second. This has the effect of the voice announcement on WWV/CHU/JJY 
radio being like "At the tone the time WAS xx:xx:xx". Some users of GPS 
receivers have tried to determine (a real kludge, in my opinion!) ad hoc 
"lateness" errors so that they could obtain more accurate time. 

I chose to adopt a more rigorous scheme to achieve computer synchronization. 
I determined that the timing of the  1 PPS signal generated on the receiver 
boards was very good -- for the Motorola receivers I can obtain 20-50 nano-
second (nsec) accuracy and precision if I set up the receiver properly, which 
was the genesis of the TAC project. The Garmin GPS-20 is less accurate with 
~1 microsecond (usec) performance -- still very impressive.

To achieve computer synchronization, I decided to send the hardware-generated 
1 PPS signal to the computer using the Carrier Detect (DCD) RS232 handshaking 
wire. In software I would get the date/time from the NMEA test message, 
increment to the next second, and then wait for the DCD hardware signal to 
arrive. As the 1 PPS signal is received, the software applies the time that 
was calculated as appropriate to the next second. Thus the computer's time is 
accurate to the level of the latency of the recognition of the DCD hardware 1 
PPS signal.

Although the RS232 specifications call for signal levels of -3 to -10v (low) 
and +3 to +10v (high), I have found that most modern PCs work reliably when 
driven with 'TTL level' signals (0v and +3 to +5v). 

       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

THE 'REAL' TAC DESIGN:
My initial TAC hardware design was designed around the original Motorola 
ONCORE BASIC (then called PVT-6) receiver. I designed a small circuit board 
to provide a number of interface tasks:

  * Isolated, fast rise-time buffers to provide clean 1 PPS signals to the 
     user
  * RS232 line driver for the DCD 1PPS signal
  * RS232 isolators to protect the receiver from user errors ('idiot fuses')
  * An L-band preamplifier to improve receiver RF performance (and provide an 
     'RF idiot fuse')
  * The ability to re-bias the antenna-mounted preamplifier with a voltage 
     other than +5V
  * Battery backup for the receiver's time-of-day clock and BBRAM

At NASA/GSFC we produced more than 50 such TACs which are in daily use at 
geodetic and astronomical observatories around the world. Their performance 
is documented in the many data files on my ftp server at the URL

	ftp://aleph.gsfc.nasa.gov/GPS/totally.accurate.clock/

On aleph you will find a block diagram of the TACs we produced in the file

	ftp://aleph.gsfc.nasa.gov/GPS/totally.accurate.clock/tac-blok.gif

and you will find a photo of the TAC at Onsala Space Observatory (Sweden) in

	ftp://aleph.gsfc.nasa.gov/GPS/totally.accurate.clock/tac-foto.gif

The original Motorola ONCORE BASIC receiver used in the TACs is still 
available, but Motorola is phasing it out for the lower cost and higher 
performance (with 8 instead of the original 6 channels) ONCORE VP. 

In addition to the Motorola receivers, I have developed the first prototype 
of the Garmin-based "TAC Lite" as a lower cost alternative for the radio 
amateur community. I am now developing a new TAC interface board that will 
support any of these receivers, but it is not yet available. It will probably 
be made available thru the Tucson Amateur Packet Radio (TAPR) amateur R&D 
group. TAPR has already announced the availability of the Garmin GPS-20 
receivers for the TAC Lite design. Information on the TAPR-related 
developments can be found on TAPR's WWW page at URL:

	http://www.tapr.org/

My aleph file server also serves as the repository for TAC support software 
and documentation. In particular, you may want to fetch the most current 
version of my SHOWTIME controller/display software and its documentation. 
With version 3.10 of SHOWTIME is included minimalist support for the Garmin 
GPS-20 'TAC Lite'.

       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

TAC HARDWARE EMULATION:
Until the new TAC interface boards are available, I have drawn up some simple 
"TAC Emulation" sketches for each of the receivers is included in this 
emulate.zip distribution - the files are emulate.ps (in Postscript) and 
emulate.gif (in .gif format).  The following discussion refers to these 
schematics.

All 4 versions shown in emulate.ps and emulate.gif have in common

  * They assume you have +12VDC power
  * The RS232 connections shown assume a standard IBM-PC 9-pin connector
  * They all lack a 'proper' RS232 driver for the DCD 1 PPS connection and 
     assume your PC will work with TTL levels.
  * They show a 1 PPS BNC connector for your use in parallel with the DCD 
     signal. The receiver's 1PPS output drive is limited, so the rise times 
     are not as fast as I'd like to see.

An optional battery is shown. I highly recommend that you use a battery to 
help the receiver 'wake up' in a 'smart' mode. Some receiver boards already 
have a batter installed; if this is the case for you, then omit the option 
battery, diode and resistor. Each of the receivers seems to work OK with 
battery voltages from +3.5v to +9v. The NASA/GSFC produced TACs use a 9v NiCd 
rechargable battery and I have also used disposable 9v alkaline batteries 
without the resistor/diode charger. If your receiver has a battery built-in, 
it is probably a 3.6v unit.

If you need to provide a battery, you could use a 3.6v cordless telephone 
battery or a 9v NiCd battery (either obtained at Radio Shack). You will need 
a Silicon diode like a 1N4001 to prevent the batter from discharging when 
power is off. 

You now need to compute the proper charge current limiting resistor. A fully 
charged NiCd cell ends up at a voltage of 1.4v. A "3.6v battery" has 3 cells, 
so its float voltage is 4.2v. A "9v battery" has 6 cells, so it floats at 
8.4v. The diode will have a drop of ~0.6v across it. You will want to 
trickle-charge the battery with 5 to 10 ma. So for a "9v" battery being 
charged from 13.8v (not an untypical "12 volt" supply), the series battery
charge current limiting resistor would be:

   R = [(13.8v supply) - (8.4v battery) - (0.6v diode)] /(0.005 to 0.01 amps)
     =   480 to 960 ohms (I'd use 680 ohms)

or for a "3.6v" battery charging from +5V (out of the 7805 regulator):

   R = [(5.0v supply) - (4.2v battery) - (0.6v diode)] /(0.005 to 0.01 amps)
     =  40 to 80 ohms (I'd use 68 ohms)


The most complicated of the emulator circuits is that for the ONCORE VP, 
since the RS232 logic levels must be inverted. In the new TAC interface board, 
I plan to use a MAX232/LT1181 RS232 level converter chip. Since the MAX232/ 
LT1181 has two TX and two RX level converters, if you use it, you might as 
well buffer the DCD 1PPS line also. You could probably use a CMOS inverter 
chip (like a 74HC04) also.

       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Tom Clark
