[MyHosting.com]   [KO4BB Home Page]   [Manuals Home Page]   [KO4BB Wiki]
 

From the Time-Nuts mailing list:


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:

DOP type seems all wrong:

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.

Rex

 
precision_timing/a_monitor_for_the_z3816a_timing_receiver.txt · Last modified: 2013/01/08 19:00 (external edit)
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki
Except as noted, this entire site Copyright © 2002-2017. KO4BB All rights reserved.