SHOWTIME.EXE
Version 2.85
Tom Clark, W3IWI
clark@tomcat.gsfc.nasa.gov
- or -
w3iwi@amsat.org
Dec. 1, 1995
I have written the program SHOWTIME.EXE to provide a number of display
functions for the MOTOROLA PVT-6 "ONCORE" receivers that are being used for
high accuracy timing by both the Space Geodesy and Amateur Radio communi-
ties in a project that I have dubbed the "Totally Accurate Clock" ("TAC",
which I immodestly note happens to be my initials!).
SHOWTIME is a stand-alone program designed to run on an IBM-PC clone and is
intended to provide a number of useful display and control functions. When
you run it, you will see that the screen is divided into 3 general areas:
- The top half (the TIME screen) displays the current time and date
information. The most striking feature is the HH:MM:SS field which
has BIG characters that update once per second. You have the option
of displaying either UTC or local time. The bottom part of the TIME
screen is called the CALENDAR area where the current UTC date, day-of-
year, day-of-week, GPS week, modified Julian Date (MJD) and both the
Greenwich and Local mean sidereal times (GMST and LMST) are displayed.
Also displayed (optionally) is information on the 1 pulse-per-second
(1PPS) output timing (with a resolution of 1 nsec) and an estimate
of the current accuracy of the 1 PPS signal.
- The bottom half of the screen is divided into two windows. The lower right-
hand quadrant (the SAT screen) displays information on the satellites that
are currently in view. For all satellites in view (defined by the current
elevation mask, up to a maximum of 12), the current azimuth and elevation
are shown, along with an arrow showing whether the satellite is rising or
setting. For the satellites that are locked, the SNR is also displayed.
The SNR (in approximate dB) is given both digitally and in a simple bar-
graph "S-meter" format. The lower right-hand corner of the SAT window also
shows a tally of the satellites in view, locked and in use.
- The lower left-hand quadrant half does double duty. In normal operation the
display shows information on receiver status (tracking modes, xDOP, etc),
and either position or timing data (the POS screen). In this screen you will
see the fixed reference position, the long-term average position and the last
position reported by the GPS receiver (at a 1/second rate).
- The lower left-hand quadrant also functions as a help screen and for
parameter input for menu-driven commands. The basic menu is activated
by hitting the SPACE key, and the POS screen is restored with the
<esc> key. Hopefully the menu keys are fairly self-explanatory!
------------------------------------------------------------------------------
Getting started:
Two files (in addition to SHOWTIME.EXE) are required to make SHOWTIME work:
1. A *.GPS control file containing at least an approximate Lat/Lon/Height
position (which should be accurate to 1 degree initially). The details
of this file are described below. SHOWTIME can re-write the control
file as you change parameters. The default file name is SHOWTIME.GPS
2. A read-only file named SHOWTIME.TAC which contains a legal disclaimer
that I felt needed to be included.
These two files MUST be in the MSDOS subdirectory that you start SHOWTIME from.
Don't try using a PATH or DOS ENVIRONMENT statement. I put the .EXE files in
the \TAC\BIN directory and then have the files SHOWTIME.GPS, SHOWTIME.TAC and
SHOWTIME.BAT file in my \TAC directory. The SHOWTIME distribution software disks
set up this directory structure for you by running the SETUP file like
A:\> SETUP C:
If you have already installed SHOWTIME with the SETUP.BAT file, then use the
UPDATE.BAT file by typing
A:\> UPDATE C:
The latest version of SHOWTIME can be obtained by anonymous ftp from
ftp://aleph.gsfc.nasa.gov/GPS/totally.accurate.clock
where you will find files named like SHOWTM28.ZIP, SETUP.BAT and UPDATE.BAT.
If you need a complete distribution disk, you can fetch a complete image of
my distribution floppies from the aleph host in the ~/distribution directory
where you will find files named like tac.951024.distrib.zip. Use a binary
get to bring this file to your PC as a temporary file (like temp.zip):
ftp: binary
ftp: get tac.951024.distrib.zip temp.zip
Then use PKUNZIP to make an installation floppy, usind the -d option to
create the directory structure on the floppy:
pkunzip -d temp a:
-----------------------------------------------------------------------------
SHOWTIME assumes that you have a MOTOROLA PVT-6 "ONCORE" receiver connected
to either the COM1 or COM2 port. You specify COM1/2 by either of 2 ways:
a. Include it in the *.GPS set-up file described below
b. Do nothing and you will get COM1 as a default
The PVT-6 "ONCORE" receiver MUST be equipped with the timing option, which
MOTOROLA denotes as OPTION A (and which costs about $100 extra). The 1 PPS
signal needs to be supplied to the PC on the COMx DCD handshaking line.
As a part of our "TAC" project, I designed a piggyback board to mount on top
of the receiver which supplies this function (along with a number of other
"neat" things which I won't discuss here).
Nominally this signal should be at RS232 levels, but it will work on most
PCs by connecting the receiver's CMOS-level (0/+5v) 1 PPS signal directly to
the COM1/2 RS232 connector on most PC's; if your PC works OK with 0/+5 volt
signals, then the following minimal configuration works for an IBM standard
9-pin RS232 connection. The battery (a 9V transistor radio batter works fine)
is optional but highly recommended.
CAVEAT EMPTOR #1: Use either the +5V OR the +12V power input BUT NOT BOTH!!
Also note that I have followed MOTOROLA's pin numbering scheme on the PVT-6
connector; this is different from the normal numbering sequence which has ODD
pins on one side of the connector and EVEN pins on the other. MOTOROLA denotes
their pin #7 as "1PPS Return" -- however the Power Ground, 1 PPS Return and
Data Return (pins #3, #7 and #10) are connected together on the receiver board.
CAVEAT EMPTOR #2: DO NOT use these connections for the smaller Motorola "ONCORE
VP" receiver board. While the pin numbers are similar to the PVT-6 "ONCORE
BASIC", Motorola decided to use a different (and more conventional) way to
number the pins (odd numbers on one side, even on the other) and you WILL burn
up the receiver if you use the connections shown below !!!!
top PVT6 bottom PC's RS232
5 10 (9-pin)
+12 VDC------o o---------------o 5 = data gnd
o o------<--------o 3 = TXD to GPS
Power Gnd----o o------>--------o 2 = RXD from GPS
+5 VDC-------o o
+ Battery----o o------>--------o 1 = DCD input
1 6
----------------------------------------------------------------
To run SHOWTIME what to do, the command is
SHOWTIME xxx.GPS or SHOWTIME ?
[?] will display a brief sign-on message. If you include a [?], then
SHOWTIME halts after displaying the message.
[xxx.GPS] denotes the name of a control file (default = SHOWTIME.GPS)
which contains all normal operating parameters for the receiver. At a
minimum, your startup file contain at least the three lines:
LON: ñdd.ddd = your approximate longitude (-West, +East)
LAT: ñdd.ddd = your approximate latitude
HGT: ñmmm = your approximate height
which will be used to "seed" the receiver and get things started.
Other parameters have reasonable defaults built-in to SHOWTIME. After
SHOWTIME is running you can bring up the [F]iles menu and [U]pdate a
complete list of operating parameters in whatever file you choose. If
you want to be able to restart a particular operating configuration,
you can choose from amongst any of the different files you have saved.
The xxx.GPS file contains a number of commands. If you enter the list manu-
ally, they can be in any order. When you tell SHOWTIME to write a file (with
the [F] command), they are in a fixed order and the resulting file looks
something like this -- hopefully most of the entries are self explanatory!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#### ® SHOWTIME v2.85 ¯ File
#### 1 Dec. 1995 = #310 + 02:59:54.0
#### Posns: Ref Avg Delta RMS #Sec
LAT: +39.1883333333 +39.1883756070 +4.697 6.89 9065
LON: -76.9350833333 -76.9351177120 -2.961 3.49 9065
HGT: +100.000 +110.546 +10.546 17.06 9059 Geoid +34.0
REFID Testing SHOWTIME v2.80
#### Control ----------+----------
COM2 |COM1/2
TZ: UTC 0 |Time Zones: PC
LTZ: EST 5 | Local
TimeSwap EST | Initial
AUTOSET 0 |AutoSet rate
XTIME .85 |Time Seq Slice
LOCKHYST 2 |Alarm Hyst,s
PCRATE 1 |PC Update,1-3s
#### Receiver ----------+----------
NDim 3 |0/2/3-D
ELEV 1 |Min El
AIV |All-in-View
PDOP |xDOP Selection
HIGHest in Sky |not PDOP
APtype 4 |=Fixd
IGNORE +++++++++++++++++++í+++++++++++|Accept=+
; PRN=31^ 21^ 11^ 1^| PRN31=>1
GEOID 0 |Corrections:
IONO 1 | Geoid:N Ion:Y
#### Avg Window Length ----------+----------
POS 43200 |Pos
RMS 43200 |RMS
SigmaT 43200 |SigmaT
DOPWeight |DOP weighted positions
Tsigma: 100.5 58.6 64.2 9058 |max/min/avg Tsigma,#Sec
Locked: #309 + 23:50:36.0 1 |Since,#Unlock
#### Timing ----------+----------
Epoch 0 |Epoch Offset
Cable 92.4 |Cables,ns
Inst 8 |Rcvr Delay,ns
Early 0 |Early offset,ns
#### Ticks ----------+----------
Stone 1000 |Sec tick,Hz
Mtone 1200 |Min tone,Hz
SLong 0 |Min tone@sec
#### Colors in order: ----------+----------
## BkGnd,BigUTC,Calndr,SatInfo,Epoch,Faint,Frame
## Msec Offset,Posn,DOP/Stat,Help,Red Warning
Colors: 1 14 10 10 12 9 8 7 6 13 14 12
#### END OF FILE
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you have an incomplete *.GPS file, then SHOWTIME will supply suitable
default values. When you re-write the file to disk (from the [F] menu), the
new file will will contain all the parameters. The entries in the list can
be in any order but will be re-written in fixed format. Lines starting with
#'; or a blank character are ignored. The numeric data can be in any column
providing a couple of blanks are between the command and the data (the file
written by the machine has most data starting in column 10). Except for the
longer lines (like LAT:/LON:/HGT:/Colors:), columns to the right of 40 are
not parsed and are intended for text comments. Some commands are a single
key-word with no numeric parameters. As an example, AIV/BEST4 are alter-
natives for the receiver operating mode. Some parameters need additional
explanation:
- [TZ: xxx #] and [LTZ: xxx #]: SHOWTIME includes several clock display
options, and so it keeps three different times internally. The TZ
parameters are used to set your PC's internal clock to high-accuracy
GPS time. The numeric part of the TZ parameter specifies the offset of
you PC's clock from UTC in hours earlier than UTC. The format is
therefore like TZ: UTC 0 or TZ: EST 5 or TZ: MET 23 ( or MET -1),
with a 3- or 4- character time-zone designation followed by the UTC
offset in hours. (Personally, I keep my PC running in UTC, as you can
see from the example above.)
- The LTZ parameter follows the same conventions for an alternate Local
time display. At any time you can hit the [!] key and swap the main
time display window between UTC and Local time. When you select Local
time, then the Calendar window will display the time that your PC is
keeping. The Calendar portion of the screen shows only the UTC date,
day-of-year, day of the week, etc.
- The TimeSwap parameter lets you decide on whether the intialization
routine starts in UTC time or your local time as defined by the LTZ
parameter. When you [F]ile [U]pdate the current position of the [!]
switch is saved as TimeSwap. If the TimeSwap line is missing from the
file, or if the line reads "TimeSwap UTC", then the display clock
initializes in UTC time. If the line reads "TimeSwap anythingelse",
then the default is given by the LTZ parameter.
- [EXIT or EXIT BINARY]: When you exit SHOWTIME with the
[X] command, the EXIT switch determines if the receiver is left running
in 4800 baud ASCII NMEA mode or in 9600 baud Motorola Binary mode. (The
Motorola controller software will run OK whichever position is used,
but it takes longer to initialize if the receiver was left running in
4800 baud NMEA mode). The next time SHOWTIME is run, it doesn't care
which mode the receiver was left in and timing functions set up by
SHOWTIME continue to function after you exit. If the EXIT line is
omitted from the file or just EXIT appears, then the default is 4800
baud NMEA format the message rates used in SHOWTIME. Prior to Version
2.50, and additional option "EXIT NMEA" allowed you to specify the
rates of NMEA messages upon exit. This was dropped in Version 2.50.
- [STONE, MTONE and SLONG]: To make it easier to manually set the seconds
on another clock (like the Mark-3 VLBI formatter or your wrist-watch)
SHOWTIME can generate WWV-like audible time ticks, which are toggled
with the [N]oise key. STONE (default 1000 Hz) is the frequency in Hz
for the one-second ticks. You may need to change it if your PC has a
really bad speaker! The [N]oise ticks can be turned on so that a longer
tick with a different MTONE (default 1200 Hz) pitch on the SLONG second
(default 0) of the minute. SLONG can be changed in the [T]iming menu,
but you must set STONE and MTONE in the xxx.GPS configuration file.
- Most of my testing was done on a 486/66 machine. If you have a much
slower machine, you may want to try tuning the XTIME parameter --
XTIME is the fractional second after the last tick that the software
quits looking for RS232 data and updates the screen (see next
section). You can also insert a command PCRATE = 1,2 or 3 into the
control file. If PCRATE > 1, then the NMEA GGA/GSA/GSV messages
are sent by the receiver to once every 2 or 3 seconds. Because of
vagaries of the PVT-6 ONCORE receiver, I have not been able to
develop a foolproof algorithm that guarantees that this will work.
Most of the time, if PCRATE=2 then the shorter GGA/GSA messages are
in one second and the longer GSV messages are in another second,
but the assignment is not perfect. Similarly, if PCRATE=3 the 3
messages are supposed to be in different seconds. To see how the
roll of the dice worked, hit the [&] key to see the time slicing
in action. Two numbers are displayed -- the first is the number of
10 msec "slices" that have elapsed, the second is the number of times
passing thru the inner loop waiting for an NMEA "sentence" to arrive.
Type [%] to re-roll the dice if not OK. PCRATE and XTIME can be
set from either the xxx.GPS file or from the [G]PS screen. PCRATE
is displayed and can be set from the [A]veraging Parameters screen.
- The parameter line like "IGNORE ++++++í+++" (and the comment line which
follows it in the example above) are new in SHOWTIME Ver 2.50. This line
(and the manual entry with [G]PS Ignore/Use in the [G]PS Mode screen)
shows which satellites are to be used/ignored. The "+++í++++" field
has 31 characters in it, corresponding to GPS PRNs 31 thru 01 (left-
to-right) When SHOWTIME reads this line, it takes "+" to enable a
satellite as good. Any other character (like "-" or "í" or a space)
will disable the satellite. For the example shown above, PRNs 12, 22
and 27 have been turned off.
{Note: The IGNORE switch does not work for PRN32 due to the fact
that a 32-bit un-signed number (1 bit/satellite) needs to be sent to
the Motorola receiver, but Microsoft only allows for 32-bit SIGNED
long integers and I didn't want to take the effort to kludge a full
32-bit solution! Perhaps this will happen when SHOWTIME is implemented
in a REAL computer language!}.
- [DCDmask #] -- Note -- this function deleted in V2.60. SHOWTIME now
REQUIRES the RS232 1PPS to be on the DCD pin (pin #1 on a 9-pin RS232
connector) and DCDmask is hardwired to &80H in the SHOWTIME software.
--------------------------------------------------------------------
WHAT DOES SHOWTIME DO?
The software initially collects together all the parameters it needs and
then starts running. The first thing is to make certain that it sees the
1PPS signal from the GPS receiver. It takes about 5 seconds to look for a
pattern on the appropriate I/O pin (COM1/2 base address = &H3F8/&H2F8 +6 is
the status port I/O address, and the port data is ANDed with DCDmask). Then
SHOWTIME initializes communications with the GPS receiver. This involves
sending receiver parameters at 9600 baud in Motorola binary format, and then
listening for responses as 4800 baud ASCII NMEA0183 messages.
For various reasons (too mentionable to be numerous) I chose to have SHOWTIME
get data from the GPS receiver using NMEA0183 ASCII strings (specifically, it
uses the $GPZDA, $GPGGA, $GPGSA and $GPGSV NMEA "sentences") at 4800 baud.
However detailed control of the receiver's parameters and switches must be
done at 9600 baud with MOTOROLA's proprietary binary protocol. Both at startup
and whenever you want to make a fundamental change in the receiver config-
uration, it is necessary to toggle between the two speeds -- a nuisance, but
not insurmountable! (Maybe someday this code will be re-written to only use
the 9600 baud binary protocol, but for now we just accept the annoyance!)
A lot of work was done to accommodate the detailed timing of the PVT6 re-
ceiver outputs. The receiver's 1 PPS "tick" occurs on the UTC second (delayed
by a user-defined offset to be discussed later) and lasts for 200 msec; the
accuracy of the leading edge of the 1 PPS signal is what the "TAC" project is
all about! About 50-100 msec after the start of the 1PPS tick, the receiver
starts sending data (time, date, status, etc.) on its RS232 port. The time it
sends lags the pulse and is akin to an announcement on WWV "At the tone, the
time WAS xx:xx". The RS232 data continues for a large fraction of the second,
with the sequencing order of the messages dependent on the details of how the
receiver was initially set up (and hence the order is unpredictable).
The different NMEA messages sent each second are each terminated by a <cr><lf>
sequence and range in length from about 40 and 80 bytes. In SHOWTIME, we use 4
different NMEA messages, each sent once per second:
$GPZDA: HH,MM,SS,YEAR,MONTH and DAY data
$GPGGA: position data and status information
$GPGSA: PDOP, HDOP, VDOP and other status data
$GPGSV: AZ, EL and SNR data for each satellite in view
Each $GPGSV message gives data on only 4 satellites, so there may be 1,2 or
3 such messages each second, depending on the number of satellites in view
(i.e. above the Elevation mask limit), up to a maximum of 12.
Therefore each second we have at least 4 and sometimes as many as 7 NMEA
messages to parse. The messages average 50-60 bytes long (about 500-550 bits,
since each async byte has a start and stop bit) and hence take 100-120 msec
each. Therefore when the maximum of 7 messages are occurring, nearly 800 msec
are consumed in data transfer. The software doesn't care in what order the
ZDA/GGA/GSA/GSV messages arrive; the important HH:MM:SS data is taken from
the first valid ZDA or GGA message to be sent each second.
The inner loop of SHOWTIME is a big "chain" which is paced by the 1PPS GPS
signal and the PC's 55 msec internal clock. About 10 msec after the "tick",
the software starts looking for NMEA data terminated by the <lf> character --
each NMEA sentence ends with a "* checksum <cr> <lf>" sequence. As a line is
received, it is parsed for content and some brief computations are done if the
data is valid; as the software has evolved, a number of validity tests have
been added. The software then waits for another NMEA message terminated by <lf>.
At XTIME = 850 msec (default) since the last 1 PPS tick (measured using the
PC's internal 55 msec clock) we stop looking for RS232 input. The time read
from the GPS receiver in this second is incremented to the upcoming second,
a number of "calendar" and status calculations are done, and the SAT and POS
screens are updated.
{ Note -- the best time for the mode change has been experimentally deter-
mined to be about 0.85 seconds after the 1 PPS tick. Your PC may
be different. The parameter is called XTIME in the xxx.GPS setup file.
It can be changed in SHOWTIME with the [^] (i.e. the up-arrow or carat)
command in the [G]PS menu. You can see a "stopwatch" that shows the timing
of the incoming data by using the main-menu key [&] to show (in 10 msec
units, on the top line of the screen) when RS232 data is being received.
The [&] "stopwatch" also displays the number of passages thru the inner
timing loop waiting for NMEA "sentences" to arrive from the receiver. }
After XTIME, the PC then waits for the leading edge of the 1 PPS "tick" on the
DCD pin of the RS232 connector to do time-critical tasks. These include posting
the new time and calendar data to the screen, making a "WWV-like" tick sound
(if requested), accurately setting the PC's internal clock, etc.
After doing these "on the second" tasks, SHOWTIME then looks to see if a
keyboard entry is present. If a menu key has been struck, the appropriate
action is taken. Finally, SHOWTIME loops back to look for the next second's
NMEA data arriving from the GPS receiver. The input buffer on the COMx port
is big enough so that if some data (especially GSV information) arrived
after XTIME, it is processed at the start of the new second.
The various single-key menu requests set logical switches so that appropriate
tasks are enabled in the once/second timing loop. Because the keyboard is only
polled once/second, the response will seem sluggish. However you will quickly
learn that you can hit several keys in succession and not lose manual input
data. The most important single keys are the SPACE BAR (which activates the
main Help menu) and <esc> (which deactivates the Help menu).
Some menu requests are for operations that will change the receiver config-
uration and/or foul up the synchronization of the GPS => PC communications.
These include changes to basic receiver parameters (timing, positions and
operating modes) and disk file operations. For all these requests, you are
asked to respond with a [Y]es in order to break the communications link.
On completion of the "off-line" operations, the GPS => PC communications
are re-established and the complete receiver parameter set is loaded.
The high-accuracy timing pulse from the receiver continues with no change
during any of the parameter change operations. Only when you see the screen
clear and "Init:" appears will the changes actually effect the receiver.
At any time you can stop SHOWTIME (or unplug the PC from the "Totally
Accurate Clock") and the timing pulse will be unaffected. The computer is
NOT required for normal operation -- its only function is to control the
receiver and to display time and status information.
For various reasons, the SHOWTIME code is written in MicroSoft QuickBASIC and
is therefore subject to some annoying limitations! The distribution version of
SHOWTIME is compiled as a stand-alone .EXE file using the QuickBASIC (v4.5)
compiler. As I was writing the code, I kept adding features until it was at
the limit that QuickBasic's compiler could handle (÷65.5k of executable code,
÷65.5k of parameter storage, since I could never figure how to get QuickBasic
to handle large code models! Clearly the next version should be written in
a real programming language!). The distribution version is smaller (about 83 k)
than the "real" 65.5k+65.5k since the distribution SHOWTIME.EXE file is squeezed
with the PKLITE utility.
Initial SHOWTIME software development/testing was done on my personal 486 machine
(486 DX2/66) under MSDOS 6.2 and PCDOS 7.0. It should not need a 486's CPU
power, but I have done little testing on slower machines. I tried the code on
an antique Toshiba T1000 (8088) laptop and it did not work at all. It runs OK on
an old Toshiba 3100 (80286) laptop with the PCRATE=3 switch enabled. The code
runs as a background task under DESQVIEW -- I have even run two copies on
different receivers at the same time. It has been reported that it runs OK in
IBM OS/2 WARP. I have been able to make it run marginally as a DOS application
in WINDOZE 3.1-- you can play SOLITARE and see SHOWTIME at the same time!
Recent (SHOWTIME v2.60 onwards) software development has been in a W95 MSDOS
window on my new Pentium box; the multi-tasking environment of W95 does work,
but some RS232 inputs are clobbered depending on what else the machine is doing.
This has been a blessing in disguise since it allowed me to find a number of
places where the software needed "sanity" checks on data read from the GPS
receiver. Extensive work (culminating in v2.70) has (hopefully) improved the
ruggedness of the code when running on small PCs or in a Windows environment.
-----------------------------------------------------
USING SHOWTIME -- THE MAIN "HELP" SCREEN:
Now let us discuss some of the operating commands in SHOWTIME. When you hit the
SPACE key, you will see the POS window replaced with a "help" screen telling
about the single-keystroke commands. You can use any of these commands from
either the Help screen or while SHOWTIME is operating normally. The escape <esc>
key removes the Help screen and restores the normal display.
[C]OLORS:
You can customize the screen to your preference with the [C]olors menu key.
SHOWTIME assumes only the most minimal IBM-PC video configuration which can
be used on a monochrome or CGA monitor. Hence for the colors, you only have
16 choices. The [C]olor screen lets you assign any of the 16 colors to 10
different screen features. When you [U]pdate the xxx.GPS file in the [F]iles
menu, the latest color choices are saved. I have provided you with default
colors that look nice on my VGA CRT.
[N]OISE (TICKS):
I have often found it useful to have some audible feedback when manually
setting another clock (like the Mark-3 VLBI formatter or my wrist-watch).
SHOWTIME can make "WWV-like" ticks. Hitting the [N]oise key toggles you
through a 3-step sequence: Ticks off / Ticks ON / Ticks ON plus a long tick on
some pre-defined second during the minute. You can select the second for the
long tick in the [G]PS menu. You can also define the pitch of the tick tones
in the *.GPS configuration file. The default tones are 1000 Hz for the seconds
tick and 1200 Hz for the long minute tick.
Note that the time ticks and the screen update are triggered by the 1 PPS
output from the receiver which is sent to SHOWTIME on the RS232 port. If you
set a [T]iming [E]poch offset of 500 msec, the tick souds (and the screen
update) will occur half-way through the second, out of phase with the ticks
you would hear from a radio listening to WWV.
[S, @, D, H, 0-9]: SHOWTIME allows you to set your PC clock to the GPS rec-
eiver either manually or automatically. At any time, hitting [S]et PC Clock
will set the PC's clock with an offset specified in the *.GPS file. Hitting
[@] will enable/disable an automatic PC clock updating at pre-determined
intervals. The keys [1] [2] .... [9] set the automatic update period to be
1.2...9 updates/day. The [D] key sets it one update per day. The [H] key
sets it one update/hour. The [@] key toggles the automatic updates on/off.
The [0] key disables automatic updates (and therefore the [@] key toggle is
disabled). The status of these switches is shown on the [SPACE] help screen.
In case an automatic or manual setting operation wants to set the PC clock
at the top of the minute (between seconds 58 and 02), the setting operation
is deferred for a few seconds since the minute is a busy time for SHOWTIME.
The status of the AutoSet configuration is saved in the xxx.GPS configuration
file in a line that reads "AUTOSET xxx" where xxx is the AutoSet period.
If xxx=0 then the AutoSet operations are disabled until enabled interactively.
All PC clock settings use the TZ: parameters read from the *.GPS file to
determine the appropriate clock offset from UTC. The TZ: parameters do
nothing else in the operation of SHOWTIME and the actual time on the PC's
internal time clock is not used by SHOWTIME.
AutoSet does nothing to set the PC clock's date, so it is possible to set
The PC's clock and lose/gain one day. Sorry, but the logic to set the PC
date was beyond what I wanted to tackle at this time!
THE SCREEN TOGGLE SWITCHES -- [\], [/], [!], [=], [M], and [L]
In addition, there are some other single-key on/off toggle switches which
can be used interactively to change some screen display parameters.
The [\] key turns the POS screen updating on/off and [/] turns the SAT
screen on/off. These are useful if you want to copy down some numbers from
the screen and freeze the display. Also, if you [R]efresh Screen with SAT
and/or POS turned off, then those portions of the screen are blanked out.
If the [\] and/or [/] switches are turned off (so that the sub-screens are
not displayed), the switch positions are saved in the xxx.GPS file as lines
with the words POSOFF and/or SATOFF so that the program can resume operation
in the previously defined mode. If the lines POSOFF and/or SATOFF do not
appear in the xxx.GPS file, SHOWTIME defaults to having the POS and SAT screens
enabled. On the main help menu, a + or - appears following the [\] and [/]
menu entries to show you if the appropriate screens are enabled.
The [!] key allows you to toggle the main time display between UTC and your
Local time (as defined by the LTZ: parameters in the *.GPS file). The position
of the [!] switch is saved in the *.GPS file in a line reading "TimeSwap UTC"
or "TimeSwap anythingelse". If the TimeSwap line is omitted from the *.GPS
file, the default is "TimeSwap UTC".
The [=] key toggles the display of the current timing offsets (in the top
right-hand corner of the screen) on and off. The main reason for this switch
is to reduce the screen "clutter". The [=] switch makes no changes in the
operation of SHOWTIME and the current timing parameters continue even if they
are not displayed. When you are operating in zero-D timing mode, the [=] key
defaults to ON, and to OFF when operating in 2-D or 3-D positioning mode.
The status of the [=] switch is not saved in the *.GPS configuration file.
The [M]aidenhead Grid Square/G[M]ST key toggles a "ham" feature -- the GMST
field is replaced by the "Maidenhead" grid locator for the current average
Lat/Lon. A typical grid locator might be like FM19me. The first letter is
the longitude modulo 20 degrees measured east from 180 degrees and the second
letter corresponds to the latitude north from -90 degrees modulo 10 degrees.
The next two digits are the Longitude modulo 2 degrees and the Lon/Lat with
quantization of 5/2.5 arc minutes. I have augmented the conventional grid
locator in SHOWTIME with two additional digits for Lon/Lat with 30/15 arcsec
resolution. Thus the "augmented" field is shown with a format like FM19me.75,
corresponding to my home QTH at Long=76d56.098'W and Lat=39d11.292'N. The 7
means that you are 70% of the way in the F1m Longitude band and the 5 means
50% of the M9e Latitude band. The status of the [M]aidenhead/G[M]ST switch is
not saved in the *.GPS configuration file and the program initializes with the
switch in the G[M]ST position. (Just for information, Trimble has included
Maidenhead Grid Square locator readout in their "Scout" handheld GPS receiver
for the amateur's convenience, and I wouldn't allow SHOWTIME to have any
lesser capabilities!)
The [L] key toggles on/off an audible alarm (revised in SHOWTIME V2.30) that
beeps when the GPS receiver has lost lock on all satellites. The unlock
condition is triggered when the receiver has been unlocked for more seconds than
the Lock Hysteresis parameter (initialized by the *.GPS file, and which can be
changed in the [G]PS Mode screen). When this happens, a large flashing "L" char-
acter appears in each of the 6 digits of the time display and beeps once/second.
In addition, the number of seconds during which the receiver has been unlocked
and the "valid since" Date/Time (the last time the receiver achieved full lock)
appear on the [A]veraging parameters screen. When operating in time-keeping 0-D
mode, the "Valid since" date and # Unlocked counter are shown continuously in
the lower left-hand quadrant of the screen. The visual "L" indicator is always
activated and the [L] menu key can be used to toggle the noise on/off.
-----------------------------------------------------
GPS RECEIVER OPERATING MODE CHANGES -- THE [G]PS SCREEN:
Many of the basic PVT-6 operating parameters are set in the [G]PS menu. Single-
key commands optimize the receiver for [p]osition determination or [t]ime-
keeping functions. [Note that the [p] and [t] commands are case sensitive;
the uppercase [P] and [T] commands take you to the [P]osition and [T]iming
setup screens.]
The PVT-6 has the ability to run in the [A]ll-in-view mode (all channels that
are tracking satellites are used in a least-squares determination of time/
position), or in a mode where it makes use of only the [B]est-of-4 satellites
("Best" determined by the lowest possible xDOP value). Since both position and
timing accuracy are improved by letting the receiver average over the maximum
possible number of satellites, I can think of no logical reason to use the
[B]est-4 mode, but it is included since Motorola allowed for it.
The PVT-6 can make its decision about which satellites to devote its 6 channels
to on the basis of a DOP (dilution of precision) calculation. It can optimize
based on General criteria (GDOP, based on 3-D position and timing accuracy),
3-D position (PDOP), Horizontal position (HDOP), Vertical position (VDOP) or
Timing (TDOP). If you are doing position measurements, I suggest you use PDOP.
You [S]elect the DOP type using the [S] key. Repeated pressing of [S] cycles
thru the various options. If you select the [p]osition or [t]ime options, the
selection is made for you automatically. If you select on the basis of xDOP,
make sure that the [E]levation mask is reasonable since the xDOP criteria want
to include some low-elevation satellites which might not be visible depending
on you local elevation obscurations.
Alternatively, you can also allocate channel resources based on [H]ighest-in-
Sky criteria with the 6 channels allocated to the 6 GPS satellites with the
highest elevation -- particularly suitable for accurate [t]imekeeping. If you
select [H]ighest, SHOWTIME selects a 1ø [E]levation mask automatically, but
this can be changed with [E]levation if you want to set a different limit.
The [%]APtype switch is included for experimentation. Motorola describes it
in their documentation. I have found it of little use in a non-dynamic
environment and suggest you use the default Aptype 4=Fixed position. Beginning
with SHOWTIME V2.20, [%]APtype is a "rotary switch" -- press the [%] key
repeatedly until the desired value appears.
In SHOWTIME 2.50 a new switch, [G]PS Ignore/Use, has been added to allow you
to selectively ignore any of the PRN01 thru PRN31 satellites. After hitting
[G] you will be asked for a GPS PRN #, and that satellite will be toggled
between on/off. Responding with a "0", or hitting <cr> will unconditionally
enable all satellites. The screen shows PRN31 thru PRN01 (in clusters of
eight with PRN31 on the left-hand end) with either a "+" or "í" to show
on vs. off. The "í" symbol for disabled satellites also appears next to the
PRN in the satellite status display in the lower right-hand quadrant of the
screen. The Ignore feature only works for PRN's 01 thru 31 (i.e. NOT PRN32)
because I was too lazy to solve a problem withe Microsoft's long integers.
-----------------------------------------------------
POSITIONS and AVERAGING -- THE [P] and [A] SCREENS:
The POS window displays the fixed "REFerence" position, an average position and
the most recent instantaneous position, all defined in the right-handed NEU
(North/East/Up positive) WGS84 coordinate system. The differences (REF-AVG),
(AVG-LAST) and (REF-LAST) and their RMS values are given in meters (where 1ø of
Lon=111.111km*cos(Lat) and 1øLat=111.111km). All SHOWTIME heights are referenced
to the WGS-84 ellipsoid, and NOT to local mean sea-level (MSL). The WGS84 vs.
MSL difference can be as much as about 50 meters. When running in the Zero-D
(timing) mode, only the fixed reference position is displayed on the screen
since the receiver is not determining any positions.
The avgerage positions computed in SHOWTIME are NOT weighted with the GPS xDOP
(dilution of precision) for simplicity. Both the average positions and their
RMS deviations are smoothed by a filter that works like like:
AVERAGE = [(Filter Length - 1)*oldvalue + newvalue] / (Filter Length)
Initially, the filter is set = 1, and then it is incremented by 1 per second. Simple
algebra shows that the average thus computed is the running average. When WEIGHT
hits the defined filter length "clamp" value, the incrementing is stopped. When
the filter length reaches the "clamp" value, the Averages are then exponentially
weighted with a time constant related to the "clamp" value. If you are running
with PCRATE > 1, then the receiver sends position data at a lower rate, so the
running filter length is incremented by 2 or 3. See FAQ #23 for some more
details on this new capability.
With Version 2.85, a new capability to weight the average position/rms with
the HDOP/VDOP (Horizontal/Vertical Dilution Of Precision) for the actual
satellite geometry. The [A]veraging [D]OP Weighting switch toggles the DOP-
weighted averaging on/off. The [D]OP Weighting switch can be set from and
saved to the *.GPS configuration control file.
When SHOWTIME is running, hitting the [A]verage key will display a small menu
that allows you to manipulate the averaging parameters. You can reset the
[r]ms or [p]osition or [t]ime counters to start a "fresh" average and you
can zero the [U]nlock counte, or you can zero all four with the [z] key.
Note that the [p], [r] and [t] "zeroizer" keys are all lower case.
You can change the "clamp" time constant for the [P]osition, [R]MS or [T]ime
averages. When you enter a new "clamp" time constant, you can simplify the
entry by using the "hint" units shown in the menu -- for example, 2H sets the
averaging period to 2 hours = 7200 seconds. Note that the [P], [R] and [T]
commands must be entered in UPPER CASE. When you [F]ile [U]pdate, the *.GPS
configuration file in the [F]iles menu, all the current "clamp" filter time
constants are saved and can be restored the next time you run SHOWTIME.
For really accurate time-keeping, the GPS receiver needs to be constrained to a
fixed position, which should be accurate at the 10-15 meter level. The position
that is used for this is called the REFerence position. Also, if you chose to
operate in the 2-D (height fixed) mode, the receiver fixes the height to the
REFerence height.
When you begin operation at a new location, you will probably not know your
position accurately. The raw positions reported by the GPS receiver will wander
by up to ñ100 meters horizontally and ñ250 meters vertically because of weak
geometry of the satellites, errors in the broadcast ephemerides, atmospheric
propagation errors and especially because the US Military degrades GPS by
dithering the spacecraft clocks (known as SA = Selective Availability).
To overcome these errors, it is desirable to average position measurements for
several hours to get an accurate position. When the receiver has been running
in position mode for a while, you can use the [P]osition menu to transfer the
average position into the REFerence position. The [P]osition menu also allows
you to manually enter coordinates. You should also use the [R]eference ID
command to enter a brief (36 character max) text description describing the
setup conditions. The Reference ID appears on the bottom of the POS screen
(unless an RTCM SC-104 DGPS beacon is being received, in which case the DGPS
information is shown on the bottom line). If you make any Position changes, the
Averaging filters are zeroed so that the position averages will be "fresh".
SHOWTIME assumes all position coordinates are in the GPS WGS84 reference frame
(which is insignificantly different from the ITRF reference frame used by the
geodetic science community). The main confusion about WGS84 comes in the defin-
ition of heights. Conventional (old) topographic maps and civilian applications
have historically referred heights to Mean Sea Level (MSL) which differ from the
WGS84 global reference geoid by up to about 100 meters (in the Washington DC
area, MSL heights are about 34 meters greater than WGS84 heights -- i.e. local
MSL corresponds to a WGS84 altitude of about -34 meters on the USA east coast).
When running in 3D position determining mode, SHOWTIME gets its height inform-
ation from the $GPGGA NMEA message which reports both the height and the Geoid
reference offset. The NMEA messages are intended for maritime navigators and the
$GPGGA height is (supposed to be) referenced to MSL. In May, 1995 I stumbled on
the rude discovery that Motorola's ONCORE firmware releases 5.x/6.x (pre-1995
firmware) incorrectly reported the $GPGGA height in WGS84 coordinates; since the
intital Totally Accurate Clock and SHOWTIME development was done with 5.x/6.x
receivers, early versions of SHOWTIME simply ignored the geoid correction.
SHOWTIME was always intended to always run in WGS84 coordinates for time-
keeping purposes. The position you enter as the REFerence position is loaded
into the receiver in WGS84 Geoid units. The positions displayed were intended
to be WGS84 positions.
[Note: The AVGPOS.BAT utility I have provided uses Motorola's GPS53
controller software, not SHOWTIME and produces WGS84 coordinates.]
To my surprise, in mid-May '95 I received the first ONCORE receivers with their
firmware release 8.0 (which shows a release date Jan.11, 1995 -- use the
VERSION.BAT utility to verify what version you have). In version 8.0, Motorola
has corrected the earlier NMEA GEOID error. This caused me to revise SHOWTIME
to accommodate the old vs. new firmware differences.
I have added a new switch called "GEOID" in the SHOWTIME V2.20 code. If the
switch GEOID=0, then no geoid correction is applied, as appropriate for old
Motorola 5.x and 6.x firmware releases. If the switch GEOID=1, then the geoid
correction is applied to reported heights as required with new Motorola 8.x
firmware. The switch appears as GEOID 0 or GEOID 1 (0=off, 1=on) in the *.GPS
configuration file and it can be toggled on/off with the [W]GS84 GEOID key in
either the [P]osition or [G]PS Receiver screens (which also show the words "old"
and "new"). The current GEOID switch value is saved when you update the *.GPS
control file on the [F]iles screen. If GEOID is not specified in the *.GPS file,
the default is GEOID 0 for compatibility with earlier SHOWTIME versions. The
position of the Geoid switch is also displayed as "Geoid:N" or "Geoid:Y" in
the "Rcvr:" status line in the lower-left hand quadrant of the screen. Both the
WGS84 and MSL heights (which differ by the value of the Geoid offset) are shown
in the [P]osition screen, with the sign of the correction depending on the
current position of the GEOID on/off switch. [See also FAQ #7 for more detail]
-----------------------------------------------------
TIMING FUNCTIONS -- THE [T] SCREEN:
Finally, we come to the real reason for doing the "Totally Accurate Clock"
project -- producing high accuracy timing data. Repeated tests of the "TAC"
with respect to a Hydrogen Maser show that the 1PPS tick from the PVT-6 has
a precision of 45 nsec or better when the receiver is running in a mode
"[t]iming -- best parameters" command (set in the [G]PS Mode menu) and with an
accurate reference position).
Two early independent tests (one by MOTOROLA in cooperation with the US Naval
Observatory, and one by me comparing the prototype "TAC" against a USNO
traveling clock) showed that the PVT-6 has an intrinsic accuracy of ÷20 nsec
with respect to the USNO master clocks -- providing that you account for all
the instrumental effects! Subsequent tests I have run confirm the earlier
traceability to the USNO master clocks with several "production" "Totally
Accurate Clocks". [See FAQ#14 at the end of this document for details]
One of the instrumental biases that must be included is the propagation delay
in the coax cables connecting the GPS antenna to the receiver and the cable
connecting the receiver's 1PPS output to whatever is the "time sink". Both
cables make the delivered pulse be LATE and so the receiver must be advanced
by a corresponding amount.
Another instrumental bias that needs to be removed is any delay added in the
receiver system. In the "TAC", we buffer the 1 PPS output through a pair of
high-speed 74AC04 logic gates (my prototype used 74HC14's with a bit more
delay) which further delay the pulse. For the 74AC04 gates used in the TAC
package, the appropriate instrumental delay is ÷8 nsec (SHOWTIME default).
In Motorola's GPS53 OEM controller software, these delays are compensated with
the PPSDELAY command. In SHOWTIME there are [T]iming commands to account for
[C]able and instrumental [D]delays separately. For both these SHOWTIME commands,
you can enter the number followed by suitable units character(s).
For example, you can enter the [C]able delay as either 50 FT or 25 METERS and
SHOWTIME will compute the appropriate number of nsec for a 50 foot or 25 meter
cable length (assuming a velocity factor of 0.66 for typical coaxial cables).
On any of the [T]iming commands, you are told what are the default units, and
you are given a "hint" of the alternative units you can use.
In many applications, you will want to offset the tick epoch from the UTC
second. The ONCORE PVT-6 (with Option A) allows 3 ways to do this offset:
- The basic measurement epoch of the receiver can be stepped in 1 msec
steps. (In the MOTOROLA GPS53 controller software, this is done with
the EPOCH command.)
- The pulse can be moved LATE with respect to the receiver epoch in 1
nsec steps from 0 to 999999999 nsec. (MOTOROLA GPS53 command PPSOFF.)
- The pulse can be moved up to 1 msec EARLY with respect to the epoch in
1 nsec steps (MOTOROLA GPS53 command PPSDELAY).
The bookkeeping on these 3 numbers can lead to much confusion, which I have
attempted to remedy in SHOWTIME. Parameters for setting the time epoch are
all handled in the [T]iming menu.
- The [C]ABLE delay and INSTrumental [D]elay offsets can be entered
separately. (These are used like MOTOROLA's PPSDELAY inputs.)
- You enter separately a nominal msec coarse [E]poch offset and a de-
sired fine [u]sec offset (the letter [u] is used since the Greek æ is
not easy to type on a PC). The fine æsec offset can be either earlier
or later than the msec [E]poch and the software will take care of the
arithmetic signs for you (The computed values are used like MOTOROLA's
PPSOFF and EPOCH parameters). You can also [S]lew the current values
either earlier or later or [Z]ero both the [E] and [U] offsets.
- You can offset the tick early by a small [I]ntentional offset which is
not cleared by the [Z]ero command (This is applied like the [C]able
and Instrumental [D]elay parameters equivalent to Motorola's parameter
PPSDELAY). The purpose of this extra offset is to allow you to have
the GPS tick occur earlier than the "house" time standard to facilitate
unbiased time-interval measurements. While you are in the [T]ime setup
screen, the display shows the total [E]+[U]+[I] offset from UTC.
- Back on the main CLOCK screen, the 3-digit msec field (shown in large
digits at the end of the time field) is the nearest msec epoch to the
tick time. The "1 PPS offset" field shows the TOTAL offset (+late, - early)
of the tick from the UTC second.
In SHOWTIME I separated these various contributions and do all the arithmetic
for you because in the VLBI world I have often seen time synchronization
problems because of sign confusion when several contributions are combined.
Another parameter that is displayed on the main screen is my estimate of
the current timing accuracy. The basic algorithm for estimate is
Timing sigma = û[àý+(áý/N)]
where N is the number of "extra" satellites contributing to the timing:
N = (# Satellites being tracked) for the zero-D timing mode,
or N = (# Satellites being tracked - 2) for a 2-D position fix,
or N = (# Satellites being tracked - 3) for a 3-D position fix,
and where my experience shows à ÷ 10 nsec and á ÷ 100 nsec seem appropriate.
In addition to the current Timing sigma in the upper-right hand part of the
UTC time field, the maximum, minimum and average values of Timing sigma are
shown at the bottom of the POS screen. The averaging parameters are set on
the [A]verage screen.
-----------------------------------------------------
FILE UPDATES -- the [F] COMMAND:
At any time you can hit the [F]ILE command. In the [F]ILES screen, you are told
if there have been any major changes to the screen colors, receiver operating
parameters or epoch timing parameters. You can [U]PDATE the current receiver
configuration data file so that you can resume operation later with the same
setup. If you change the [F]ile name, then you Update to a different file. If
you select a [F]ile name that already exists, you are given the option of over-
writing the existing file. The old file name is changed from *.GPS to *.GP$ as
a backup. The file you write with the [U]pdate or [F]ile command is a complete
snapshot of the important receiver and software parameters.
You can [L]oad a different configuration file. All parameters that are defined
in the file you [L]oad will override the existing values and the file name for
the next [U]pdate is changed to the file you just [L]oaded.
In the file screen you can do a few DOS operations like [D]IR *.GP? to get a
listing of the *.GPS and *.GP$ files in the active directory and [C]hange to a
new directory. You can also [S]hell out of SHOWTIME to execute DOS commands.
When you [S]hell to DOS, you lose about 140 kbytes of memory since the SHOWTIME
code is still resident. If you change directories while in the DOS [S]hell,
SHOWTIME will use the new directory for any subsequent file read or write
operations. To return to SHOWTIME from the DOS [S]hell, type EXIT.
-----------------------------------------------------
EXITING SHOWTIME -- THE [X] COMMAND:
From the main menu (or from the [P]osition, [T]iming [F]ile and [G]PS screens)
you can type [X] to exit SHOWTIME. You are told if there have been any parameter
changes since the last update and you are asked TWICE to confirm that you want
to exit. Responding with two "Y" answers will terminate the program. Responding
with an "F" will take you to the [F]ile update screen. <esc> will abort the exit.
If you abort the e[X]it with <esc>, the receiver will re-synchronize the RS-232
communications and resume normal operations.
If you have a glitch in the the receiver's power or the RS-232 communications,
SHOWTIME may abort with an unrecoverable I/O error message and return to MSDOS.
This is a Microsoft QB45 error message. I have tried to trap this error without
having SHOWTIME abort, but I have been unsuccessful. Sorry, but this quirk has
to be tolerated until SHOWTIME is ported to a "real" computer language.
--------------------------------------------------------------------
FAQ's -- IS THE GPS RECEIVER LOCKED UP? IS IT WORKING? HOW ACCURATE IS IT?
I have received number of questions (especially for the NASA/GSFC versions of
the "Totally Accurate Clock") on receiver performance, so let me answer some
FAQ (Frequently Asked Questions) here, en masse:
----------------------------------
(1) The SHOWTIME program seemed to start OK on my TAC. The initial signon
messages appeared, and then the initial "AM I CONNECTED? test" sounded beeps
and showed a pattern like .........#..#..............#..#....... -- but then
nothing happened. What's wrong?
In this case, the user had an old RS232 port on his computer, and it was
equipped with a 25-pin RS232 connector. The SHOWTIME initialization routine
ONLY looks for the presence of a 1PPS signal on the DCD wire, but does not
check for other RS232 data signals. Their 9/25 pin adaptor widget had pins
2 and 3 swapped. The correct wiring for the cable is:
TAC RS232 PC RS232 -or- PC RS232
(9-pin) (9 pin) (25 pin)
DATA gnd 5-------------------------5-----------------7
TXD to GPS 3-------------------------3-----------------2
RXD from GPS 2-------------------------2-----------------3
DCD input 1-------------------------1-----------------8
Note that only the 4 wires shown in this sketch are used in the production
TAC's and all other wires are ignored and un-needed.
----------------------------------
(2) Occasionally I see excursions of several microseconds between the TAC
output and a good frequency standard. Why?
In ALL my testing I have never seen any spurious timing pulses generated
except when the receiver becomes disconnected from the antenna or when RFI
is present and no GPS satellites are being tracked! Therefore I suspect your
antenna connection was faulty in some way. When you have no GPS signals being
received, the 1PPS from the ONCORE is generated by crystal oscillator running
at the rate last steered by GPS. Its drift rate depends on your operating
conditions, but seems to be a few hundred nsec/minute typically.
In version 2.10 (logic revised in version 2.30) of SHOWTIME I have helped
this problem -- I added a "loss of signal" unlock indicator that warns you
when the receiver has lost lock. When this happens, each digit of the UTC
time displayed on the PC is over-written with a large flashing "L" (in the
color defined by the warning parameter ColorRED). The total number of
seconds that the fault has occurred appear on the screen when you are in
[G]PS [t]iming mode and also in the [A]veraging parameters menu screen.
The counter of the total seconds of data loss is reset by blipping the
[A]veraging [t]ime or [A]veraging [z]ero all 4 controls. This obnoxious
alarm can be toggled ON/OFF with the [L] key but it defaults to being turned
ON whenever SHOWTIME is started. The flashing "L" on the screen and the
audible alarm are triggered whenever the receiver has been unlocked for
a time longer (in seconds) than defined by the [L]ock Hysteresis parameter
which is initialized in the *.GPS file and by the [G]PS Mode [L]ock Hyst
parameter. Note that LockHyst is set negative to silence the audible alarm.
The default is (positive=alarm noise on) but the audible alarm can be
defeated by the main help menu [L] key.
If the fault is persistent, then I'd suggest you first check the TAC's
antenna connector and verify that it has the +5VDC bias voltage present.
If the cable developed a short, then it is likely that the fuse inside
the TAC has blown and nothing will work including the front-panel LED.
Also, you should look for possible RFI (the old Rogue GPS receivers are
notorious RFI generators, and the newer TurboRogue receivers can also cause
problems). Try relocating the antenna and/or receiver to clear the problem.
----------------------------------
(3) The TAC displays a bogus date and/or time when I turn it on. After ÷10
minutes it finally starts working OK. Why?
It is likely that the small 9 Volt battery inside the TAC is discharged.
This could be because you have not used the clock for several months. The
battery is a NiCd unit and its main purpose is to keep a low-accuracy
wrist-watch crystal controlled clock on the Motorola ONCORE receiver
running.
In our TAC implementation, the battery is charged at a very low (÷1 mA)
rate thru a diode and a 3kohm resistor. The clock requires a few tens of
uA and will discharge the battery after a few weeks of non-use. Applying
power to the TAC will start the battery charging, but it will take several
days to become fully charged. If this slow charge rate causes you problems,
you can increase the charging rate to ÷10 ma by putting a 470 ohm resistor
across the 3kohm resistor supplied with the TAC.
If the GPS receiver wakes up with a "dead clock", it will go into a
"sky search" mode and start looking blindly for GPS satellites. As soon
as it acquires the first satellite (which may take 5-15 minutes), it will
get an approximate time synch that is good enough to continue operation.
The ONCORE receiver stores GPS "almanac" data (low-accuracy Keplerian
elements) in non-volatile RAM, so as soon as it knows the current time
and an approximate position, it can begin searching for satellites that
it knows should be visible. Even if the receiver has lost this data, the
complete set of almanac data for ALL the GPS satellites is broadcast by
each GPS satellite every 12.5 minutes. Hence a completely "cold" ONCORE
receiver should take no more than about 15 minutes to begin working.
Beginning with SHOWTIME V2.20, I have added a "Coldstart The Clock" option
in case you have trouble with a receiver with a dead battery. Go to the
[P]OSITION screen where you will find an entry [D]ate/Time Coldstart.
Simply enter the current UTC date and Time. The time should be accurate
to about 10-15 minutes. If you miss the date by a day or two, don't worry.
When the receiver locks up on the first satellite, it will correct the UTC
time and date in a few seconds. If you use [D]ate/Time and the receiver
already has a valid date/time, the receiver simply ignores the request.
----------------------------------
(4) Occasionally the time display misses a second and then jumps ahead by 2
seconds. The WWV-like [N]oise ticks also skip a beat. It is most "ragged"
when the satellite status display shows 9 or more satellites are visible
above the elevation limit. Why?
It takes 600-800 msec for the ONCORE receiver to send all its 4800 baud
NMEA messages. The length of time depends on how many satellites are in
view because each $GPGSV message reports on only 4 satellites -- hence
with 9 satellites, GSV messages are required in addition to the other
3 messages that the receiver sends ($GPZDA, $GPGSA, $GPGGA). The SHOWTIME
software has an internal timer (called XTIME) that paces when it is
listening for messages. The software then does some display updates and
computes the next second's display, and then waits for the 1PPS tick to
arrive on the DCD RS232 wire.
You can change the XTIME slice from the default value in the [G]PS screen
with the [^] key. If this doesn't fix the problem, then slow down the NMEA
message rate with the PCRATE parameter on the [G]PS screen. I find that
an XTIME of 0.85 (850 msec) works fine for me on my personal 486/66.
----------------------------------
(5) The bar-graph display shows the Signal-to-Noise Ratio (SNR). What are the
units for the SNRs? What are "good" values? What range should I see?
Motorola returns the SNR in the $GPGSV messages in units that are nominally
equal to dB. The maximum value the ONCORE reports is 36dB and the SHOWTIME
bar-graph display can accommodate SNRs up to 38 dB.
If you are using an antenna with a really good noise figure which is in the
open (no trees to attenuate the signal), you will probably see satellites
at high elevations showing 33-36 dB SNR's. The small Trimble and Motorola
patch antennas will probably show about 30 dB maximum SNR since they are
more lossy and have poorer system temperatures.
Since the bar-graph "S-Meter" is sorted by satellite elevation, you can get
a good feeling for the gain pattern of your antenna. The amplitudes should
not bounce around more than ñ 1 dB from second to second unless you have
high multipath or spotty obscuration by trees. Since the "S-Meter" display is
easy to read and has a fast 1 second response, I have used SHOWTIME as a "GPS
OHMMETER" to make certain that another GPS antenna/receiver is working OK!
Motorola provided little information about units it uses for SNRs, so let me
give my speculations. The GPS signal structure uses a 1.023 MB/s pseudo-random
CDMA (code-division multiple-access) spreading code. Each operational GPS
satellite has a unique 1023 bit PRN (1 msec period) called the CA (Coarse
Acquisition) code -- in essence the satellite serial number. These CA codes
("Gold Codes") were selected to have maximum mutually orthogonality. The CA
codes are made by convolving two different 10-bit shift-register sequence
generators. Two different taps on one shift-register (with 10 choices for
the position of the first tap and 9 choices for the 2nd, resulting in 45
unique codes) and the output of the second 10-stage generator are multiplied
in a 3-way XOR gate to generate the 45 possible codes. GPS reserves 32 PRNs,
several more are reserved for pseudolites, and the rest of the 45 are unused.
[Note: If anybody wants to study these codes in more detail, I have included
a small QUICKBASIC program called GPS_CODE.BAS in MISC.ZIP for your use.]
The GPS digital data has a bit rate of 50 bits/second, i.e. it takes 20 CA
code repetitions to convey one bit and the matched-filter data bandwidth is
hence 50 Hz. Therefore the signal "spreading gain" = 10*log(1.023Mb/50b)
or 43 dB for each satellite. The downlink signal from the strongest GPS
satellite is about half the noise in the 2 MHz (approx) passband of a simple
CA code GPS receiver. Therefore the best SNR=S/(S+N) we can expect is about
38-39 dB. If there are several satellites in view, each receiver channel
sees all other satellites as uncorrelated noise, so the 36 dB SNR "clamp"
that Motorola set is a reasonable, practical upper limit to the SNR.
Since the 1023 bit CA codes are of finite length, we expect some random
correlation with a one-sigma dynamic range of about 10*log(1023) ÷ 30 dB.
The correlators in typical GPS receivers are one-bit devices (like those
used in VLBI) so they suffer about 2 dB (the normal ã/2 Van Vleck factor)
in SNR loss, with the lost power appearing as code-to-code cross-modulation,
further decreasing the dynamic range. The practical maximum (i.e. several
sigma) dynamic range for GPS is in the 23-25 dB range. If the strongest GPS
satellite has SNR = 33 dB, then the weakest detectable satellite will have
an SNR of about 10 dB (assuming Motorola's numbers are really dB).
----------------------------------
(6) The time displayed in SHOWTIME "sticks" at a strange value, and this
seems to repeat. The only way I can get it to work is to restart SHOWTIME.
"The best laid plans of mice and men aft gang agaly" -- this problem arose
because of a bizarre "feature" Motorola decided to implement which I had
ignored. When running in zero-D "timekeeping" mode, the time field in the
$GPGGA message does not get updated. The only valid time-of-day is in the
$GPZDA message. Versions of SHOWTIME prior to 2.20 took the time from
whichever GGA or ZDA arrived first, providing it was larger than the
previous report. Hence the clock display could "stick" at the invalid
time reported in the GGA message in zero-D mode if the GGA messages
happened to arrive each second before the ZDA message. The bug is now
fixed in 2.20 (I hope -- if you see it happen, let me know!).
----------------------------------
(7) A new switch GEOID is in the V2.20 code. What is it? Why have my reported
heights changed? My newest (1995 production) ONCORE receiver seems to report
different heights than my earlier receivers. Why?
All these seemingly unrelated questions have to do with the WGS84 reference
system for positions and a change Motorola seems to have made in their ONCORE
firmware in early 1995 (Version 8.x). See the new discussion in the POSITIONS
AND AVERAGING section earlier in this document. The bottom line is:
- If you have an older ONCORE receiver (Version 5.x or 6.x code dated prior
to Jan.11, 1995), then set the SHOWTIME GEOID switch off (set GEOID 0 in
the *.GPS file or use the [W]GS84 switch on the [G]PS/[P]osition screens).
- If you have a more recent ONCORE receiver (Version 8.x firmware
dated Jan.11, 1995 or later), then set the GEOID switch on (set
GEOID 1 in SHOWTIME.GPS or use the [W]GS84 switch).
- If you want to verify your software release version/date, fire up
the Motorola controller software (GPS53), hit [F8] to run a self-
test, then type "id" to have the receiver dump its configuration
information. When you finish, type "mode fix". Or you can run the
utility I have provided called "VERSION.BAT" (which uses EXC.EXE
to run the Motorola controller software and issue the necessary
commands to determine the version with minimal intervention).
All this confusion applies ONLY to the units for the height when you are
running the receiver in the positioning averaging mode in SHOWTIME. The
only effect on the receiver's operations occurs if you let SHOWTIME average
the positions and the GEOID switch is wrong, you will get a bad Reference
height, which will introduce a timing bias error when you run in zero-D
timing mode with the bogus reference height -- see FAQ #14 below for a
discussion of the magnitude of the error. The error (Geoid separation) is
÷34 meters on the east-coast of the USA, corresponding to a timing bias
of about (34 meters)/(c = 0.3 meters/nsec) * 63% ÷ 70 nsec.
[Note: If you generate the REFerence coordinates using the AVGPOS.BAT
utility I have provided, the positions in the POSITION.GPS file are
are guaranteed to be in the correct WGS84 reference frame regardless of
the setting of the GEOID switch.]
----------------------------------
(8) I have an older PVT-6 equipped with "Option A", but SHOWTIME doesn't
work with it. Why?
Motorola made some significant code changes beginning with their 5.0
release. Their 4.x receivers (and presumably earlier ones also) did not
implement the $GPZDA message (that reports the date & time in all modes)
and $GPGSV (reporting on the visible satellites and their SNR). Also,
their code versions prior to 5.0 had a ÷560 nsec time bias error, so they
are not recommended for precise timing use. Contact Motorola to arrange
for a firmware update! Versions 5.0 and later all seem to work similarly.
----------------------------------
(9) Will SHOWTIME run with other GPS receivers (i.e. not ONCORE with Option A)?
Probably not. Many of the receivers do not generate all four of the NMEA
messages that SHOWTIME uses. SHOWTIME requires that a ÷200 msec 1 PPS pulse
is sent by the GPS receiver to the computer on an RS232 status line. Someday
I may write a similar, but more general GPS time display program.
----------------------------------
(10) The UNLOCK counter on the [A]veraging screen shows a few counts each
day even though the "Totally Accurate Clock" seems to be working OK. Why?
The receiver can unlock for 1-2 seconds when it begins tracking a new GPS
satellite after an old one sets. It can "glitch" briefly if there is local
RFI. (See FAQ#2 above) Don't worry if you see a few counts.
If you start seeing 100 counts or more, something is definitely wrong! You
should look for possible problems in the coax cable feeding the GPS antenna
(connectors are always a likely culprit). Perhaps your power supply is noisy
or the DC power connector is loose. Wiggle everything to find the problem.
----------------------------------
(11) Regarding the satellites reported as "Locked" and "Used (*)" -- sometimes
a satellite is Locked but not Used? Why?
When a satellite is added "fresh" to the receiver (it just came above the
elevation limit, or now deserves to be in the "HIGHEST IN SKY" list, or it
now needed to make the optimum xDOP), the satellite must be tracked long
enough to decode a complete set of ephemeris data. A GPS satellite sends it
own precise ephemeris every 30 seconds, and you have to wait for a complete
block to be decoded. If a satellite is still weak, the carrier phase and CA
code tracking loops may be locked, but some bit errors occur during the
decoding of the ephemeris, so the receiver must wait for another 30 seconds
to try again to decode a complete 1500 bit message.
Or, you may have the receiver in the "Best-4" mode in which case only 4
satellites are used (not recommended but permitted!).
Or, if you happen to be running with a DGPS beacon correcting the receiver
and the beacon is not reporting corrections on a satellite your receiver
is tracking, then it will not be used.
----------------------------------
(12) I am running in the receiver in the "Highest-in-Sky" mode and a satellite
that should be in the "tracking" list is not there. Why?
This could be for several reasons. First, you could have an obstruction in
the part of the sky where the satellite is located, so it can't be detected.
Or, the satellite in question may currently be flagged as "unhealthy" --
the DoD people who control the satellites can instruct a satellite to report
itself as unreliable. The DoD may do this if they are uploading new commands,
or if they are maneuvering the satellite, or if there is a problem, or
perhaps just because the feel grumpy. C'est la vie!
Or, perhaps you have added the sattelite to the "ignore" list ([G]PS [Y]es
[G]PS ignore), in which case the satellite's PRN will be followed with a
"í" character on the satellite status screen and will appear in the *.GPS
file in a line reading like "IGNORE +++++++++++++++++++í+++++++++++|"
----------------------------------
(13) When SHOWTIME starts up, the little up- and down-arrows that show when
the satellite is rising or setting don't appear for a while. Why?
The up/down arrows are generated in SHOWTIME by looking at the elevations
reported by the receiver (quantized in 1 degree steps). When the elevation
report changes, then SHOWTIME can make the rising/setting determination.
SHOWTIME has to wait a few minutes to see the elevation change.
----------------------------------
(14) What is the accuracy and precision of the "TAC" 1 PPS output signal?
First, about the precision: The 1 PPS output from the ONCORE receiver is
derived from a ÷9.5 MHz crystal. There is no phase-resolver on it, and the
individual tick pulses are derived from this oscillator. You can expect any
single tick to be anywhere (uniformly distributed) in a 104 (i.e. ñ 52) nsec
window centered on the correct epoch. The pulses will wander in a "saw-tooth"
pattern thru the ñ 52 nsec window at an indeterminate rate. Experience has
shown that averaging the measurement over a 5-10 second period is needed to
remove noise from this sawtooth. Since the peak-to-peak error is ñ 52 nsec,
the per-pulse RMS error is about 30-35 nsec (÷ one-third of the p-p value).
Averaging for 10 seconds then reduces this effect as ûN to ÷ 10 nsec RMS.
The DoD "dithers" each GPS satellites Cesium clock in a process called Sel-
ective Availability (SA). The SA modulation spectrum has an RMS amplitude of
÷100 nsec RMS (÷300 nsec peak-to-peak) with modulation time scales from 1 to
2000 seconds. The SA modulation is not coherent between the different GPS
satellites, so that when you are running in zero-D "All-in-view" time-keeping
mode tracking N=5 or 6 satellites, the SA effects are reduced as ûN. Thus the
÷100 nsec RMS errors are reduced to the 40-50 nsec RMS level (assuming 5-10
second averaging is used to remove the pulse-to-pulse "sawtooth" jitter). The
RMS precision goes down to ÷30-35 nsec with 30-100 second averaging times, and
the Allan Variance ëT/T scales as ÷ 50 nsec/T, where ëT is the uncertainty in
measuring over an elapsed time interval T.
Accuracy is affected by several factors, some of which (a, b, c and d in the
following list) are beyond our control and must be tolerated, and some of
which (e, f and g) we can some control:
(a) The timing effects of SA, plus the (in)accuracy of the satellite ephem-
erides, satellite clock models, ionosphere corrections, etc. that the
DoD chooses to provide us in each satellites's real-time data stream.
(b) The observing geometry -- where are the GPS satellites in the sky?
(c) The "correctness" with which Motorola has implemented their internal
receiver firmware.
(d) Propagation delays of the signals in the earth's atmosphere.
(e) The accuracy of the REFerence station positions that are used.
(f) The accuracy with which we account for all the cable and instrumental
delays in our measurement setup.
(g) Errors caused by multipath at the GPS antenna.
To test the a+b+c+d+e+f+g "bottom line", we have done a number of tests at
the Goddard Geophysical & Astronomical Observatory (GGAO) and AlliedSignal
Technical Services Corp. (ATSC) which have yielded the following results:
- We routinely show a measurement repeatability of 40-45 nsec comparing
a "TAC" against a Hydrogen Maser when we use 5-10 second time-interval
averages, after a simple linear drift is fit to account for Maser
frequency offsets.
- When these results are smoothed, systematic biases at the 10-20 nsec
level are seen over times of hours to days. Assuming that the Hydrogen
Maser is not at fault, these are likely due to (a) GPS ephemeris and
clock model errors, although the (d) propagation delay errors are
undoubtedly also present. (Robin Giffard at HP (Palo Alto) reports
seeing similar long-term "wandering".)
- We compare a "TAC" against the USNO master clocks using a "TV line 10"
time synchronization scheme (calibrated by traveling clocks which go
between GGAO, ATSC and USNO monthly) and by direct comparisons when
the traveling clocks visit us. The USNO-to-TAC offsets are rarely
bigger than 20 nsec. (Mihran Miranian at USNO and I plan future tests
using a TAC at the USNO master clock whenver we get around to it.)
- The most critical REFerence position parameter is the station height. To
test the (e) dependence, I have intentionally corrupted the station
height by ñ30 meters (equivalent to ñ100 nsec). With the height error of
+30 meters (HIGH), the TAC pulse was observed to be LATE by 61ñ3 nsec
(the results being obtained with 1000 second averaging times on an HP5328A
counter with 10 nsec one-shot time-interval capability). When the height
error was set -30 meters (LOW), the pulse was seen to be 64ñ2 nsec EARLY.
From the average of these tests, we get the "63% rule":
(Timing Error) ÷ +63% * (Height Error)
where a positive time error means LATE, and where the height error is
expressed in nsec. The coefficient is not 100% because of geometric
effects; each satellite contributes to the error as sin(Elevation) and
the error is averaged over 5-6 satellites and the mean satellite elevation
(at mid-latitudes) is typically ÷40ø and sin(40ø) = 0.64.
- As a partial test of the (c) Motorola contribution and on the repeat-
ibility of our "TAC" hardware fabrication, I carefully compared three
different TACs with three different Motorola firmware releases (versions
5.1, 6.0 and 8.0) running from the same GPS antenna thru an 8-port GPS
power splitter and with identical length cables. Again I used 1000-sec
averaging and the three TAC packages showed ZERO differences ñ2 nsec.
As a test of other possible Motorola receiver "quirks", I have run tests
where the "TAC" is powered down or the antenna is disconnected for
several minutes. In all cases, the receiver recovers in a minute (after
it shows that it has re-acquired the GPS satellites) with no loss in
accuracy/precision and with no discontinuities at the few nsec level.
- Regarding (d) atmospheric biases, the troposphere contributes a zenith
path delay of 1-3 meters (3-10 nsec) which maps thru the receiver as
the equivalent of an error in the station height. Using the "63% rule"
described above, this can induce systematic errors in the 2-6 nsec
range. Motorola does not state if they make any attempt to correct for
tropospheric delay in their documentation so I must presume that they
do not. The ionosphere contributes up to 10 meters of delay at L-band.
See the following FAQ (#15) for comments on [I]onospheric corrections.
- Multipath induced errors (g) are tricky and beyond the scope of this
discussion! The main thing you can do is to make sure your antenna has
a clear view of the sky and that there are few reflecting surfaces
nearby. You can get a clue when you may be having multipath problems
if you see the SNR "bar-graph" bouncing around by more than than 1 dB
over time scales of a few seconds, especially at low elevation angles.
- A number of tests similar to those I have described here were done
by Mike King and David Busch (Motorola) and Mihran Miranian (USNO) in
1993 and are described in the Institute of Navigation (ION) Jan.1994
Conference Proceedings. I have enclosed a reprint of this paper (with
some additional notes on my measurements appended) with all the TACs we
at GSFC are distributing. Their results are quite comparable to mine.
Assuming that you have determined your REFerence station positions to the
5-10 meter level by suitable averaging and that you account for all the
cables in your setup, and that you average over the ñ 52 nsec "sawtooth",
the "bottom line" is that the ONCORE/TAC clock performance is summarized:
Precision ÷ 40-50 nsec (with 5-10 sample time interval averages,
improving to ÷ 30 nsec with 100 second averaging times)
Accuracy < 20 nsec (relative to USNO with multi-hour averages)
SHOWTIME's clock Tsigma error model (described earlier in this document)
performs a real-time estimate of the performance based on my experience
in parametrizing the performance.
----------------------------------
(15) What does the Ionosphere correction do?
The GPS satellites send down an approximate global-average ionospheric
parameter that the user may chose to use; the Motorola ONCORE receiver
permits it to be used, and the [I]ono switch turns it on/off. I have
done tests to check this correction. When the correction was turned OFF,
the 1 PPS epoch time was observed to shift LATE by 18ñ2 nsec (using the
same 1000-second averaging techniques described above in FAQ #14).
----------------------------------
(16) PRN12 has been mis-behaving. How can I solve the problems it causes?
With Version 2.50, a new "Ignore the bad actors" switch has been added to the
[G]PS Modes screen with the Ignore [G]PS Satellite command; this allows you
to ignore any of the PRN01-31 satellites.
----------------------------------
(17) My "TAC" seems to have locked up. The front-panel LED is on all the time
and nothing seems to work. What do I do?
This glitch has been observed to happen occasionally (most recently to Joe
Taylor at Princeton, who sent his TAC to me for checkout). I have no idea
why it happens, but here is what I did to clear Joe's problem:
(a). I ran his receiver with the Motorola GPS53 controller. It came up
running just fine. Apparently the Motorola software send some binary reset
command I haven't identified in its initialization proceedure.
(b). I also did a "soft" reset on Joe's receiver by disconnecting the 9V
battery. The easiest way to do this on MOST of the TAC's we made is to
unplug the 10-pin ribbon cable from the top board for about a half-hour.
This causes the receiver's BBRAM to get amnesia, and also resets the date/
time clock on the receiver. If you do this, follow the instructions in
FAQ #3 when you start SHOWTIME to set an approximate time into the receiver.
----------------------------------
(18) Sometimes (especially when a really bad set of Lat/Lon coordinates are
in the receiver or when the antenna is in a bad location) SHOWTIME seems to
reset itself a lot, and it then it bounces bad to MessDOS with a nasty,
untelligible error message. Why?
SHOWTIME uses the stock QuickBASIC/DOS "Open COMx" RS232 I/O. It seems that
the PVT-6 receiver can send some garbage characters occasionally and this
caused a lot of problems. In Version 2.60 I spent a lot of effort trapping
the most common of these error and changing the port reset philosophy.
HOPEFULLY the new code cures most of these problems that seemed to occur
only when operating under marginal conditions. Even more work has gone into
solving this problem in the v2.70 release.
In addition to the RS232 I/O problems, there were cases when the NMEA string
parsing routines glitched when satellies were dropping in and out rapidly.
I hope I caught all these cases also.
----------------------------------
(19) Will SHOWTIME and the TAC operate under WINDOZE 3.11 and W95?
In September'95, I got a new 133 MHz Pentium at home, and it came loaded
with WIN95. All the development of SHOWTIME afeter v2.60 was done in an
MSDOS prompt screen in W95. A lot of the testing to try to force glitches
was done by loading W95 with a lot of tasks (including running TASKMON,
NETSCAPE, and playing SOLITARE concurrently with SHOWTIME running in the
background). When I started with the 2.51 code, it crashed all the time in
W95. With v2.60, I seem to be able to run it OK with W95 programs, but it
is unreliable with multiple MSDOS windows open -- presumably because SHOWTIME
has a hard-loop wait for the next 1PPS signal. With v2.70 a number of other
timing-related problems were fixed.
----------------------------------
(20) Occasionally the words "Timing Unreliable" flash on the position/timing
screen. Should I be worried?
The "Timing Unreliable" indicator is computed based on the estimated Timing
sigma, which is based on the number of satellites being tracked. Occasionally
(a) an NMEA message will have bad data or (b) a satellite is dropping in and
out of lock or (c) a new satellite has just been added to the receiver's
tracking list. When these rare events happen, the NMEA message may lag the
event by a second or two, and the calculations get out of step. Don't worry
about an occasional message that flashes briefly; it is only important if it
persists.
----------------------------------
(21) The [&] "speedometer" now (since v2.82) has two numbers. Why?
To better access the internal timing of the program I added a second "stop-
watch" display parameter on the top line (toggled on/off with [&]). The inner
loop of SHOWTIME waits for a new <lf> terminated NMEA "sentence" until XTIME
has elapsed. The first number is the time since the last 1 PPS tick in 10 msec
units, and the second number is a counter of the number of times the software
has passed thru the inner loop waiting for an <lf>.
----------------------------------
(22) I see that I have an "Unlocked for 10 sec" indication, but the "Locked
since" date/time hasn't changed. Why?
The "Unlocked for" counts even brief 1 second dropouts, which may happen
because the receiver re-sorts its satellite list or because there was a
glitch in the RS232 communications. The "Locked Since" is triggered when
the receiver has REALLY been unlocked (i.e. no satellites are detected for
more than LockHyst seconds, the time display is over-written with "LLLLLL"
characters, and then the receiver re-acquires lock). A few "Unlocked for"
counts are not unusual and the counter can be reset to zero by hitting the
[A]veraging [u]nlocked reset keys.
----------------------------------
(23) SHOWTIME ignores the HDOP and VDOP quality flags when I'm running in 2-D
or 3-D positioning mode. Can you put in DOP weighted averaging?
I had resisted this request because for me, SHOWTIME and the TACs were
intended to be used for TIMING tasks, not positioning! But in Ver 2.85
I relented and added the capability. You turn HDOP/VDOP weighting on/off
with the [A]veraging [D]OP Weighting switch (or you can turn it on with
a line that reads "DOPWEIGHT" in your *.GPS file. When turned on, the
position and rms data is weighted proportional to (1/HDOP)^2 for Lat/Lon
and to (1/VDOP)^2 for heights.
The filter length strategy is simiilar to that used before. The positions
and rms differences are still exponentionally averaged as with a weight W:
(Filter Length-W)*(old avg) + W*(new value)
(new avg number) = -------------------------------------------
Filter Length
with the Filter Length still increasing as PCRATE until it reaches a clamp
value (which you set on the [A]veraging screen). This results in a simple
average when Filter Length < Clamp and an exponential averaging after it
reaches the clamp. What is new is the weight W. In the older SHOWTIME code,
and in v2.85 when DOP weighting is turned off, W is set = 1.
In v2.85 when DOPWEIGHT is ON, W is computed as
W = (1.5/HDOP)^2 for Lat/Lon
and W = (2.0/VDOP)^2 for Heights
The 1.5 and 2.0 are chosen as typical "fairly good" HDOP/VDOP values, so
the W coefficients are normally nearly = 1. Better values of HDOP/VDOP than
these averages will "speed up" the averaging and poorer values will "slow it
down". The filter algorithms are somewhat ad hoc, but I think they achieve
the desired objectives.
-----------------------------------------------------------------------------
POSTSCRIPT:
The SHOWTIME software has been, and continues to evolve -- hence it has
either been blessed by (or suffers from) "creeping featurism". User inputs
are solicited. Send them to me by Email to
clark@tomcat.gsfc.nasa.gov -or- w3iwi@amsat.org
Tom Clark February 7, 1995
revised March 17, 1995
re-revised April 1, 1995
re-revised May 23, 1995
re-revised June 1, 1995
re-revised June 4, 1995
re-revised August 1, 1995
re-revised September 11, 1995
re-revised September 16, 1995
re-revised September 27, 1995
re-revised October 16, 1995
re-revised October 17, 1995
re-revised October 24, 1995
re-revised November 6, 1995
re-revised November 11, 1995
re-revised November 14, 1995
re-revised November 21, 1995
re-revised December 1, 1995
-=-=-=-=-=-=-=-=-=-= SHOWTIME REVISION HISTORY =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Ver 1.x -- Developmental "Beta" releases. [Dec'94 to Apr'95]
Ver 2.0 --- The first "public" releases of SHOWTIME. [April 1, 1995]
Ver 2.10 -- May 23, 1995
- Added the alarm unlock indicator feature.
- Minor bug fixes & display enhancements.
Ver 2.20 -- June 1, 1995
- Improved the unlock alarm functioning from 2.10.
- Added [L] toggle switch to turn the unlock alarm on/off.
- Fixed the "clock sticks in zero-D" bug (due to "feature" in
Motorola's $GPGGA message that doesn't report time in Zero-D).
- Added the [W]GS84 GEOID correction on/off switch ([P]os & [G]PS
screens and GEOID in the *.GPS file) to accommodate Motorola's
new (Version 8.x) firmware changes in the way heights are reported.
- Added [D]ate/Time Coldstart Clock initialization in [P]os screen.
- Stripped out a lot of spurious code and cleaned up a lot of the
screens to make them more legible and to save code space.
- Improved wording on [SPACE BAR] main help screen menu.
- Deleted the [#] Channel number display (which nobody was using).
- Several menu inputs changed from manual "type a number" entry to
"rotary switches" -- for these, you press the key to cycle thru
the legal values ( [%]ApType, [S]elect DOPtype, [I]on, [W]GS Geoid,
[$]PCrate and [N]oise ticks all run this way now).
- Satellite Status "billboard" rearranged to make room for the new 8-
channel ONCORE display (Untested - I haven't tried an 8-Ball yet!).
Ver 2.21 -- June 2, 1995
- Corrected a minor bug in reported heights when running in
positioning mode with old (pre-V8.0) ONCORE code. The [W]GS84
switch in the [P]osition screen now reads "new" vs. "old" to
correspond with pre- and post- Version 8.0 receiver firmware.
- Entering a [M]anual position in the [P]osition screen now
"seeds" the average position with the new reference position.
- In the [M]anual [H]eight entry, you can now enter either WGS84
or MSL heights and SHOWTIME will do the conversion for you,
providing the [W]GS GEOID switch is in the correct position for
your receiver's firmware. The correction is based on the WGS84
minus MSL Geoid separation computed in the Motorola receiver (the
value of which is reported to you on the [P]osition screen).
Ver 2.22 -- June 4, 1995
- Cleaned up & added some more logging info to the *.GPS file.
The logging data in the file now includes the number of seconds
included in the Lat/Lon/Hgt/Tsigma averages, the "Valid Since"
last locked time, and the number of times it was unlocked. Note
that these parameters reflect the last time you write the *.GPS
file with a [F]ile [U]pdate.
- The [P]osition screen now shows the RMS of (REF minus AVG)
- When you are in zero-D timing mode, the reported Average position
is set to the 3-D REFerence position. In 2-D mode, the Hgt is set
to the REFerence Hgt.
- Removed the [F]ile [K]ill *.GP$ command (not needed with [S]hell)
Ver 2.23 -- June 19, 1995
- Made a few minor changes to make software recover from temporary
data outage on RS232 cable better.
- Small change to screen that tells when PC clock has been [S]et.
Ver 2.30 -- August 1, 1995
- The Lock Alarm logic that was added in Ver 2.10 had problems!
A new, more robust logic was added in 2.30. The problem occurred
because of the way that I counted the number of satellites that
were in lock using the GSA message. The new logic uses the GGA
report directly from the receiver. Showtime now has an added
parameter (LOCKHYST in the *.GPS file, which can be set manually
on the [G]PS Mode Screen) to act as a hysteresis "damper" to
supress brief dropouts. A value ÷ 2-3 seconds for the hysteresis
seems to work well.
Ver 2.40 -- Sept. 11, 1995
- Corrected minor bug in entering cable lengths -- Meters units
didn't work correctly, and the units code got confused if the
units had an "S" in them (i.e. MSEC).
- The Time Offset screen was made a bit more explanatory. Several
other cosmetic screen changes also were made.
- The Timing Offset "mini-screen" in the upper right-hand corner
(toggled on/off with the [=] key) was streamlined and (hopefully)
made more explantory. This screen is now framed in a box.
- The (ham) Maidenhead Grid Square computation was streamlined.
- Change to RS232 COM1/2 port initialization seems to improve glitch
recovery reliability.
Ver 2.50 -- Sept. 16, 1995
- Added the ability to allow the user to disable & ignore multiple
GPS satellites. In the [G]PS Screen, the [G]PS Use/Ignore key
allows you to toggle any of the satellites PRN01-31. (You cannot
toggle PRN32 on/off. This is because the ON/OFF status is sent to
the Motorola as a 32-bit unsigned array, one bit/satellite. Alas,
QB45 does not have an unsigned long integer type, and it would have
been a huge pain to add the 32nd bit to the field. Sorry!). This
was added because the antique Block-1 PRN12 satellite has been
unreliable. In the [G]PS modes screen, good satellites are shown
as "+" and bad ones are flagged "í". The "í" character also is
shown next to ignored satellite's PRN in the satellite status
window in the lower right-hand quadrant of the screen.
- A new parameter "IGNORE" appears in the *.GPS control file to save
the status of the new parameter as a 31-character string where
a "+" means that the satellite is to be used an any other character
(like a "-" or "í" or a blank) means that the PRN is to be ignored.
- To make room for the Ignore feature, the ability to exit SHOWTIME
with any of the 7 "legal" NMEA messages being set to user-defined
rates ("EXIT NMEA") has been discarded. "EXIT BINARY" still works.
- In general, a lot of cleanup was done on various screens to make
the SHOWTIME code more compact. Also, several small, related
subroutines were merged and/or put into inline code to make the
program a bit smaller and faster.
- The display that shows the testing of the 1PPS RS232 tick at
startup has been changed from ....#..#.... to something that looks
more like an oscilloscope trace.
- The calculation of Local/Greenwich Mean Sidereal Time (LMST/GMST)
was streamlined. Earlier versions included the quadratic (but not
cubic) term to calculate the GMST at 00:00 UTC based on elapsed
time from the J2000 epoch. For computational efficiency, the small
quadratic term is now "locked" to 1996.0. The error for the next
several years is < 1 msec.
Ver 2.51 -- Sept. 27, 1995
- In 2.40 & 2.50 I streamlined the RS232 configuration. Unfortunately,
it didn't work on all machines. Some RS232 ports default to having
the CTS and RTS lines low and some default to high. The 2.51
software has been modified to IGNORE the unused handshaking lines.
(thanks to the folks at Onsala for giving me an opportunity to
duplicate this problem).
Ver 2.60 -- Oct. 15, 1995
- A lot of work was expended to better trap RS232 I/O problems. The
PC's 16450/16550 UART is now issued a hard reset each time the I/O
is initialized. Error trapping has been improved. Several variables
are now tested to make sure they don't go beyond reasonable bounds
if the PVT-6 receiver send some garbage data.
- The DCDmask variable was hard-coded instead of being set in the
*.GPS file, so users MUST input the 1PPS signal on the DCD line.
Ver 2.61 -- Oct. 17, 1995 (minor maintenance fixes)
- Still had to trap a couple of more bad data instances. Minor update
from Ver. 2.60
Ver 2.70 -- Oct. 22, 1995
- Did a lot of testing to force errors that could cause SHOWTIME to die
and implemented a LOT of new traps. All these involve possible bogus
data returned in NMEA messages if the computer loses sync with the
RS232 NMEA messages while running in W95.
- To make space for all the new traps, a number of separate subroutines
were made into in-line code or subroutes in the MAIN module. This
should also speed execution a bit.
- A few minor cosmetic changes were made to the display,
Ver 2.71 -- Oct. 24, 1995 (minor maintenance fixes)
- Found another sanity test that was needed.
- Cleaned up and slightly revised the [F]iles screen logic
Ver 2.72 -- Nov. 4, 1995 (never released publicly)
- Fixed minor bug in the display of the nsec portion of the [U]+[I]
total time offset in the [T]iming screen and the [=] display window.
Calculations were done correctly -- the display was wrong because
an integer number was displayed in a floating point field.
- The PCrate switch somehow had gotten broken a few versions ago.
It was made to operate again and the logic to set the GGA/GSA/GSV
NMEA messages at a slower rate (PCrate seconds) was revamped to
be more reliable at both 2 & 3 second "slow" rates. The new logic
may glitch if you try to start SHOWTIME withing about 10 seconds
of the PC's Midnite marker.
- The [$] PCrate switch is now available on the [A]veraging screen
in addition to the [G]PS Receiver Mode screen. On either screen,
hitting [$] increments PCrate in a [1,2,3,1,2,3...] sequence.
After hitting [$] on the [A]veraging screen, the entry changes to
the ColorRED color and SHOWTIME resets to initialize the new rate
on exiting with <esc>.
Ver 2.80 -- Nov. 6, 1995
- Made a number of changes in the logic behind the Position/Timing
window so that the top line more correctly reports the receiver's
status and that the unlock detection is more reliable.
- Additional "sanity" checks were added to prevent bogus coordinates
from being included in the position (especially heights).
- Cleaned up & tested the new widgets added in 2.72 for public release.
Ver 2.81 -- Nov. 8, 1995
- A minor bug caused an error in [F]ile [L]oad -- a new *.GPS file was
not loaded correctly. A global variable got used for two different
purposes during one of the recent changes.
Ver 2.82 -- Nov. 11, 1995 (minor maintenance fixes)
- The earlier versions of SHOWTIME would report incorrect Lat/Lon
if either Lat or Lon was between 00 and -01 degrees. This is a
common problem with a lot of software since it is hard to represent
a signed negative zero integer! This minor problem is now fixed.
- The -00 problem was not trivial to fix. Added a new parsing function
(Pd$) to make it possible. This resulted in a slight display change,
namely that Longitudes under 100 degrees (+ or -) now have the
degrees field zero-padded to 3 characters plus sign.
- I also made it possible to [P]osition [M]anual enter Lat/Lon in the
-00 to -01 degree band.
- Fixed a minor bug that somehow crept in that made the [C]olor and
[A]veraging screens not work right when in zero-D timing mode.
- The [&] "speedometer" has a second number displayed -- this is the
number of times thru the inner loop trying to read an NMEA message
during the current second.
- A screen which shows the "Locked Since" and # Unlocked information
appears when a non-operative menu key is struck. <esc> clears this
information panel and resumes operation. (The same info also appears
when you manually [S]et the PC's clock.)
Ver 2.83 -- Nov. 14, 1995 (minor maintenance fixes)
- Found a minor glitch (which crept in from earlier changes) when
running in forced 2-D mode with SHOWTIME not recognizing the
reported rcvr state properly.
- Fixed glitch where [A]veraging [z]ero didn't reset all the reported
statistical parameters -- some variables had been left out of COMMON.
Ver 2.84 -- Nov 21, 1995 (minor maintenance fixes)
- Fixed minor bug that caused program to lock up if you tried to
[F]ile [L]oad a non-existent file -- an IF test was wrong.
- It was possible for the [P]osition or [R]MS or [T]iming Sigma filter
lengths to not "clamp" at the proper values if you decreased the
numbers and they were already greater than the new filter lengths.
- The Pos/RMS filter weights had been a mish-mash of floating and
integer values. They are now uniformly long integers and a single
subroutine handles incrementing them each time new data arrives.
- There had been some confusion on the Position screen about ëAvg &
ëRef. The nomenclature was changed to ë(RA) (meaning the difference
Ref-Avg), ë(AL) (meaning Avg-Last) and ë(RL) (meaning Ref-Last).
- Some essentially useless (and probably buggy) code that attempted
to sort the "S-meter" display panel when two satellites are at the
same elevation to have the rising satellites listed above the setting
satellite was deleted. The ordering for this rare case is now only
determined by the order the satellites are reported in the NMEA msg.
Ver 2.85 -- Dec 1,1995
- In response to a request, the 2-D or 3-D positions can now be
averaged based on (1/HDOP)^2 [Lat/Lon] or (1/VDOP)^2 [Hgt].
A new switch [A]veraging [D]OP Weight has been added -- pressing
the [D] key will toggle the xDOP weighting on/off. In the normal
Position window, you can see when the weighting is turned on
by a letter "w" appearing before the positions differences and
rms indicators.
- A new switch has been added to the *.GPS file called DOPWEIGHT.
If the line is present, then the xDOP weighting is to be applied,
if it is absent, then the weighting is not used.
- To squeeze the [D]OP Weight item into the [A]veraging screen, the
[A]veraging screen layout was changed.
- To accomodate this change, the weighting filters inside SHOWTIME
were changed from LONG (integer) to DOUBLE (floating).
- The filter length strategy is similar to that used before. See
FAQ #23 for more details.
Ver 3.00 -- Jan 7, 1996
- MAJOR update -- changes are documented in the separate file
named SHOWTM30.DOC.