Design Intent

Here are some photos of a stand-alone monitor for my Thunderbolt GPSDO. I plan to use the 10MHz output as a master reference for all my RF gear. The idea here was to display as much info on the health of the Thunderbolt as a 64x128 LCD would allow.
I think I got most of the important info in there...

The Thunderbolt has lots of info available, via the trimble "TSIP" binary protocol (Useful Links). I display some of the more relevant data, given that my objective is not to use this unit as a standard GPS to show my location, but rather as a disciplined oscillator.

Hardware/Firmware Design

This is a really simple project, and is split into 2 halves:

  • The amplification, spliiting and filtering of the 10MHz output.
  • The decoding and display of the Thunderbolt status.

The schematics for the project are shown below. Again, the trusty ATMEGA64 is used for the data decoding and display.

The 10MHz splitter
Microcontroller and Display

The 10MHz splitter is really only a series of emitter followers, coupled to some isolating transformers (from Ethernet cards).

The photo on the right shows the Trimble Thunderbolt mounted in an enclosure. My unit is built into an old HP case (I think the case originally held a tracking generator, but by the time I got the unit it was well and truly for parts only).

The ATMEGA64 is used to display data received and decoded from the Thunderbolt. The TSIP packet is first constructed from data received via the interrupt driver UART (watch out for Trimble's implementation of data - it is Little-Endian).
Once a complete packet is received, it is then parsed and relevant data extracted and displayed on a graphic LCD.
Alarm conditions are monitored and displayed (up to a maximum of 5 alarms). Critical alarms take precedence over minor alarms.
Some extra error-catching and serial time-outs round off the firmware - no user input is required for this project.

The LCD display is a little crowded, but by using some custom fonts, I think I've managed to get most of the important information all onto one screen.
The simplicity of the hardware allowed me to build on veroboard, making this a quick and cheap project.

What is displayed:

  • Time and Date:
    • GPS or UTC depending upon what the Thunderbolt is decoding.
    • If the Thunderbolt detects that UTC info is unavailable, the "UTC" marker is highlighted.
  • Numerical Fields:
    • 10MHz offset (in parts per billion).
    • DAC voltage.
    • Thunderbolt temperature.
  • Thunderbolt Status:
    • GPS Status.
    • Receiver Status.
    • Discipline Mode.
    • Discipline Activity.
  • Alarms:
    • Up to 5 Alarms are displayed at any one time.
    • Critical Alarms are displayed in preference to Minor Alarms.
    • Critical Alarms cause the "Alarm" marker to be highlighted.

There is no user input, making this a very "minimalist" build. There is however provision to connect the GPSDO to a PC (via RS232). This will allow you to use something like Lady Heather software to log the thunderbolt data or (more importantly) to command the thunderbolt to perform a site survey. This need be performed only once, for a given location.

Thunderbolt Roll-Over

The GPS system uses a 10-bit word to represent a "GPS Week Number", starting on the 6th January, 1980. This means that there is a rollover of the week counter that occurs every 1024 weeks (19.6 years) and there is no mechanism for the GPS system to report to users which 1024 week epoch the GPS week number refers. The Thunderbolt has made some small provision for this and can correctly calculate the UTC time and date up till 30th July, 2017.

Beyond this date, the thunderbolt UTC time and date will report incorrect values.

But all is not lost, as the thunderbolt will continue to track and properly hold sync of the 10MHz reference and all we need do is correctly calculate the time and date from the GPS TOW (Time Of Week) and GPS WN (week number) fields from the TSIP primary timing packet.

The GPS TOW field contains the number of seconds elapsed since the start of the week, and so it is a trivial matter to extract from that the number of hours minutes and seconds elapsed.

The easiest way to correctly calculate the date from the GPS Week Number is to manually account for the GPS 1024 week epoch and add dates in Julian Date format, based on our known GPS starting epoch of 6th Jan, 1980. I include a snippet of code to show how I did this. No doubt there are better implimentations available:

GPSEpoch	= 2444244.5;	// JD of GPS Epoch

if(TBOLT.GPSWeek < 948){	// This code was implimented during week 949 of the current cycle and since we
	GPSCycle = 2;}		// are not going back in time, we can safely assume that the next time we are
else{				// at any week number < 948, we have incremented another 1024 week cycle
	GPSCycle = 1;}

GPSDays = (1024*GPSCycle)+TBOLT.GPSWeek;
GPSDays += (TBOLT.GPSTOW-TBOLT.UTCOffset)/86400;
GPSJd = GPSEpoch + GPSDays;

// Now convert the GPS Julian Date to UTC format
X = GPSJd + (float)0.5;
I = floor(X);		// Day without time
F = X - I;
A = floor((I-1867216.25)/36524.25);
if(I > 2299160){
	B = I + A - floor(A/4) + 1;}
	B = 1;}
C = B+1524;
D = floor((C-122.1)/365.25);
E = floor(365.25*D);
G = floor((C-E)/30.6001);
d = C-E;
d = d+F;
d = d-floor(30.6001*G);
UTC.Day = floor(d);	
if(G < 13.5){
	UTC.Month = G-1;}
	UTC.Month = G-13;}
if(UTC.Month < 2.5){
	UTC.Year = D-4715;}
	UTC.Year = D-4716;}
// Now determine time of UTC day
while(UTT >= 86400){
	UTT -= 86400;			// strip off whole days
TimeSecs = UTT;
UTC.Hour = TimeSecs/3600;
TimeSecs = TimeSecs % 3600;		// strip off the hours
UTC.Minute = (uint16_t)(TimeSecs/60);
TimeSecs = TimeSecs % 60;		// strip off the minutes
UTC.Second = TimeSecs;				
The very boring front panel