[time-nuts] Z3816A and UT GPS questions

[Rex]

Does anyone remember much about the old Motorola Oncore UT GPS receivers?

I have an HP Z3816a GPS timing receiver. I've been meaning for a long 
time to add a display for UTC time to it for a while. Today I finally 
got that project built and installed, and it works as intended, but I'm 
seeing something that doesn't make too much sense to me.

On the display -- others have done similar things before me, like this:
http://www.realhamradio.com/dclock.htm

For mine I built a board that uses a 16F628A PIC micro to drive a 4-line 
LCD display. Inside the Z3816A, I probed around and found an unused row 
of header pins that has the serial lines to the UT receiver board. It 
also, conviently, has +5 V power. I soldered wires to 4 of these pins 
and added a 4-pin mini-DIN connector to bring 4 lines out of the box -- 
UT RX, TX, +5V and Ground. From this connector I have a cable that runs 
to my board with the PIC and display. I only actually tap into the one 
serial line that has the serial data coming out of the UT board. (No 
sense trying to drive, or monitor, the line into the UT that is already 
being driven by the Z3816A main board.)

I wanted to leave the Z3816A functioning normally and leave the DB-9 
serial out connector for GPSCon or other software, but also add this 
display so that I can get some useful information from the box without 
needing to devote a PC to the task.

I put up a temporary web page, with some pictures of what I have done, here:
http://www.xertech.net/ClockUT/ClockUT1.html
You can click the thumbnails for bigger versions. No detailed 
description on the web yet.

So I capture the @@Ea message that comes out of the Oncore UT board once 
a second and parse that to get the UTC time and date to display. The LCD 
display looks like this...
  --------------------
   UTC: 20:14:19
  DATE: 29-MAY-2009
        NS Typ Rst Ovr
  STAT: 07  81  08 000
  --------------------

The first two lines should be obvious. They come from parsing the time 
and date in the @@Ea message.

The next two lines are for a few bytes of status information. The last 
number, below 'Ovr' on the LCD, is a counter for serial overruns in the 
PIC hardware/software, which so far remains 000 all the time. The other 
three numbers, under NS, Typ, and Rst are hex status bytes from the @@Ea 
message. I thought they would be good for a sanity check on the 
operation of the Z3816A with no PC connected and limited information 
from the four Z3816A front-panel LEDs.

These status bytes, or more correctly 2 of the 3, are what is confusing 
me and what I'd like any help understanding. The most useful byte (as I 
expected) seems weird.

The first, labeled NS, is the byte representing number of satellites 
tracked from the @@Ea message. This number makes sense on my 
observations and matches What I see from GPSCon when the PC is connected 
at the same time.

On the other two bytes, Typ is the 'DOP type' byte and Rst is the 
'receiver status flag' byte. These two bytes seem to change 
simultaneously and at appropriate times but the values I see don't make 
sense to me based on the descriptions in the Motorola Oncore documentation.

Here is a link to a documant like the one I used to parse the @@Ea message:
http://gpsd.berlios.de/vendor-docs/motorola/ch6.pdf
(Note - some other versions have no info about a lot of these bits)

It says this about the DOP type byte:
t DOP type
 (msb) Bit 7: antenna undercurrent *
       Bit 6: antenna overcurrent *
       Bit 5: automatic survey mode
       Bit 4: not used
       Bit 3: not used
       Bit 2: not used
       Bit 1: not used
 (lsb) Bit 0: set = HDOP (2D)
              clear = PDOP (3D)


and for the receiver status byte:
s receiver status flag
Each bit represents one of the following:
 (msb) Bit 7: position propagate mode
       Bit 6: poor geometry (DOP > 12)
       Bit 5: 3D fix
       Bit 4: 2D fix
       Bit 3: acquiring satellites/position hold
       Bit 2: differential fix
       Bit 1: insufficient visible satellites (< 3)
 (lsb) Bit 0: bad almanac


When I start my Z3816A cold, I see this general sequence of status over 
a couple of hours, with all but the last change in the first several 
minutes...

 NS Typ Rst
 __ ___ ___
 00  81  09
 01  81  09
            [time becomes valid around here]
 02  81  09
 03  81  41
 04  81  41
 04  80  21
 05  80  21
            [GPS Lock LED around here]
 06  80  21
 05  80  20
            [Loong delay - NS goes up and down]
            [No change of Typ or Rst]
            [GPSCon says survey is happening]
 06  81  08
            [The above last change may be when survey ends
             but I never witnessed the exact point]
 ..  81  08 [seems to be normal operation forever]


So, my observations of the three status bytes...

NS makes sense and tracks with GPSCon

Rst makes sense if I assume the bit-3 has two different meanings
   aquiring early and
   position hold later after it has gone off for a while

DOP type seems all wrong
    high bit 7 is always on and I have no antenna alarm LED or GPSCon 
warnings
               if I unplug the antenna I get an alarm eventually but no 
change here
    low bit 1 changes at various stages of startup but seems not related 
to 2D/3D

As an experiment, I put various resistances in parallel with the antenna 
coax. I dropped it down to eventually 33 ohms. At this point the 
satellite signals went to crap but the high bit of DOP type was still on.

So, that's my story.

I don't think my PIC software is broken. If it was, first guess is 
offset into the @@Ea message. I have the time / date right, last byte of 
chksum computes, near-by bytes don't make sense as values if I was off 
in finding the byte.

Does anyone have any knowledge of this 'DOP type' byte I am trying to 
use? When GPSCon sees the box in survey mode, bit 5 of this byte is not 
on and seems it ought to be. Probably I should just ignore this strange 
byte but I like to have things understood.

And of course, all is working fine beyond these status bytes. I don't 
think anything needs fixing except my understanding and possibly some 
dumb thing in my PIC code. I'd like to clean up or reduce the display 
before moving the box to a nice home spot.

Note: If some of the above is hard to read, you may want to try a fixed 
pitch font. If that doesn't help, it's probably my fault.