Tuesday, August 11, 2015

Upgrading the GPS in the Lucent KS-24361 REF-1

This post will document my exploration of the GPS module in the Lucent KS-24361 REF-1 unit. This information may be useful if you desire to remove or upgrade the Motorola Oncore GPS in the REF-1.

The Motorola Oncore GPS module in the REF-1.


Introduction

Recently I posted about standalone operation of the Lucent KS-24361, aka HP/Symmetricom Z3812A, REF-0 unit. In the process of figuring out how to do that, it was necessary to examine the serial transmissions sent to the REF-0 from the REF-1. I did that by examining the serial pin on the external interface connector. Today, I decided to poke around inside the REF-1, remove the GPS module, dump serial strings, and evaluate options for hacking a new GPS into the unit.

My motivation for this was two-fold. First, I wanted to make sure I hadn't missed any critical messages between the REF-0 and REF-1 that might cause problems down the road. By examining the actual connection between the GPS and the REF-1 mainboard, I can see everything the REF-1 sees, and thus everything the REF-0 could see. Second, I wanted to see if it is possible to remove, replace, and/or upgrade the GPS and still make the REF-1 work. The Motorola Oncore is a very old GPS receiver, and it might be desirable to upgrade it. Or, perhaps you want to discipline the REF-1 to a PPS signal without having to supply real GPS serial data. Kind of like running a REF-0 standalone.

Back When Things Were Simple

Accessing the internals of the REF-1 is very simple. You can actually see everything through the vent holes even before removing the cover. Ten screws get you past the cover, and four screws free the Oncore from the mainboard. It is interesting to note that one of the screws is so close to the can, the assembler had to bend the metal edge of the can downward to seat it.

Carefully pull the Oncore up and out. You will immediately notice the 10-pin rectangular header. We will explore that in a second. Also notice the strange RF connector. That is what gets the GPS signal from the connector on the front panel to the Oncore. If you ever decide to replace the Oncore, you will almost certainly want to desolder that connector and use something else, or mount a completely new one.

The 10-pin header that connects the Oncore to the mainboard is very simple and useful, as you can see below. I do not know how much current that +5V pin can supply, but surely it could support a new GPS, a microcontroller, and other gadgets. The 5V backup pin connects to a .022F supercap on the mainboard. This could be useful for backup supply to a new GPS, or an RTC.

The really interesting pins are the serial and PPS. Simply connect to the serial pin at 9600 baud 8N1 and you can read out what the REF-1 sends to the Oncore. If you replace the Oncore and power the unit up, you can read both sides. The signal on the PPS pin is 5V normally high with a 200ms wide pulse. You will have to apply a new PPS signal here if you later replace the Oncore.

I do not know what the "unknown" pins are for. #1 seems to go to a pull-down resistor and decoupling cap on the GPS, and #2 seems to go to an unpopulated pad on the GPS.

The header for the Oncore GPS inside the REF-1. This view is with the front panel to your left, and the OCXO closest to you, with the Oncore still seated.

The Bootup Process

I examined the serial communications between the processor in the REF-1 and the Oncore. This is the sequence of messages that start nine seconds after a cold boot:

  • @@Ea Position and status, one time request
  • @@Cj Request receiver ID
  • @@Fa Self-test
  • @@Ea Request position and status, once a second
  • @@Cj Request receiver ID
  • @@Ab GMT offset 0
  • @@Ao Select datum #49
  • @@Aq Ionospheric correction mode on
  • @@Aw Time mode, select GPS format
  • @@Ay Poll current UTC offset
  • @@Bb Request satellites visible message
  • @@Bo Request UTC offset when updated
  • @@Ag Set mask angle
  • @@Ap Set user datum
  • @@Az Set PPS cable delay
  • @@At Position hold select, query
  • @@At Position hold select, disable
  • @@En Setup T-RAIM message and request once a second
  • @@Bj Poll leap second pending status

After this, all setup messages repeat at regular intervals. This allows hot-swap of a REF-0 unit. Remember that the REF-0 sees many, if not all, of these messages as well. Though it's not actively in control, it needs to know the current GPS status, and enter holdover mode when necessary.

If you cold boot the unit with the Oncore completely removed, the processor asks for Position and status as normal. Seeing no reply, it requests the receiver ID three times, spaced five seconds apart. Then it sends an @@Aa message three times, also five seconds apart. @@Aa is a strange message that just queries the time of day. After this the @@Cj and @@Aa messages repeat, presumably forever. The NO GPS light on the front panel and the red fault LED inside on the board flash. It is unknown if you can hot-swap an Oncore module onto the board. I wouldn't try it, but if you do, let me know what it does.

Trying to Hack It

I programmed an ATmega168 microcontroller to try and take the place of the Oncore GPS module. My program monitors for requests from the REF-1 and sends back appropriate replies. I also applied a real GPS PPS signal to the header pin from a Navman Jupiter T. This process was only partially successful.

The serial strings going to the REF-1 prevented the internal red fault LED from coming on. However, the NO GPS light on the front panel was still indicating a problem. I hooked up SatStat and found that the REF-1 was unhappy. Initially, it will think that the Oncore is okay because it receives correct responses to receiver ID, self test, etc. However, it seems the processor then forces the Oncore out of position hold mode to start a survey. Even changing my strings to indicate a survey was in progress did not satisfy the REF-1. It was not seeing the exact responses to the messages it had configured.

Trying to modify the REF-1 unit is completely different from hacking the REF-0 to operate standalone. The processor in the REF-1 has two-way communication with the GPS and is in complete control. It knows exactly what it has requested of the GPS, and it gets upset when it sees incorrect messages come back.

Going Forward

Currently I have no plans to pursue modifying the REF-1. I was happy to make a tiny bit of progress here, but it's not worth a whole lot more of my time. The REF-1 unit doesn't have a 10MHz out, it's less available, and more expensive. Also, hacking the GPS out of a GPSDO is kind of odd. It's certainly not something that would be useful to everyone.

If you want to work on your own REF-1, I suggest that you start by hooking up to the serial pins and dumping out the messages from a cold boot. You will especially want your receiver ID message from the Oncore. That is a 294 byte message, and there's little value in trying to modify that. Just capture it and send it back to the REF-1 when it asks for @@Cj. You will need the other messages, and their timing, to see what the REF-1 asks for and in what order. You may end up needing to program a 1-2 hour fake survey. Virtually jiggle some satellites around, increment the time, and try to make it happy. If you can get to position hold mode, you will be in really good shape.

Of course you could replace the Oncore with... another Oncore. As long as it's software version understands all of the same messages, it should be a very easy swap. Potentially as easy as "hook up the right pins". This approach has limited usefulness as you don't really gain anything. You would probably only do this if you need to repair a KS-24361 and don't have the correct GPS replacement part.

It's possible you want real GPS data going to the REF-1, but from a unit that doesn't support the Oncore's format. In this case, you could program a microcontroller to translate between the two formats. Or, at least translate enough useful information for your purposes. To do this you will still want to understand the message sequence and timing, at least enough to make sure your program can handle all commands from the REF-1 correctly.

Another approach is to dump the firmware on the mainboard of the REF-1 and modify it. That could open up some really interesting options for you.

I hope this information is useful. Good luck modifying your REF-1 unit.

Thanks for reading!

-Dan W.

No comments:

Post a Comment