Prototyping a GPS Board for the KS-24361 REF-0

In this post I will describe how to mount a custom GPS board inside the Lucent KS-24361 REF-0 unit. I will also show a small board which I prototyped to neatly add all necessary circuitry for standalone operation of the REF-0 directly inside the housing.

This was my earliest success at getting the REF-0 to run standalone. It involved taking over the breakfast nook, and a lot of wires. What a mess! Time to clean things up.

Introduction

I have written a few posts on how to make the KS-24361 REF-0 run standalone. My initial write-ups were focused on just getting it working, with connections made externally using the Interface connector. This works great for testing, but for long-term use, it is desirable to get the GPS and all necessary circuitry inside the unit. Getting everything installed neatly in the unit will prevent dangling wires and likely improve reliability.

For standalone operation as I have described previously, several connections need to be made at the Interface connector on the front panel to simulate the presence of a REF-1 unit. This is less than ideal if you want a clean external appearance. I decided to probe around the board and find out where those pins connected to. I hoped that they would terminate at easily accessible pins or pads. Finding them on the top of the board would be even better, because removing the board is a real pain.

To my surprise, I found them in nearly the most convenient spot possible.

Connection Points for Standalone Operation

As you may recall, we need four pins from the Interface connector for standalone operation. One pin (which I have labelled "Present" below) tells the REF-0 that the Interface cable is present and connected. The "Pair A" pin tells it that everything is ok and it should turn its outputs on. Then of course we need the "Serial In" and "PPS In" pins. Technically the Pair B and Pair C pins are also important, but the condition we need them in is floating, so we don't need to connect anything to them. Finally, a regulated 5V supply pin on the board would be great for powering stuff.

All of these can be easily accessed on the board inside the REF-0, underneath the position where the Oncore GPS would sit in the REF-1. The Preset, Pair A, Serial In, and PPS In pins all go to inverter ICs U27 and U32 as shown below. There are also 5V and ground pins on the Oncore GPS header (which is unpopulated in a REF-0). I have labelled these connection points in the image below.

Necessary connection points on the REF-0 mainboard for standalone operation. You can find these where an Oncore GPS would normally be mounted in a REF-1.

It's quite a stroke of luck to find all of the necessary connection points EXACTLY where we need them. The only thing that could have been more convenient was if the pins had gone to the Oncore header. But hey, I'm not complaining. With these connection points located, it is now possible to design a custom GPS board that can mount directly inside the REF-0. This will require some soldering on the board to add jumper wires, but the modifications are simple and reversible.

Connecting to the Points and Installing the Prototype

Get out your good soldering iron, because there is a little fine soldering to be done if you want to access these points. The Present and Pair A pins (9 and 13 on U27) both need to be connected to ground. I decided to bridge them over to the ground pin of that chip (pin 7). I also cut apart some breadboard jumper wires to solder onto the Serial In and PPS In pins (11 and 13) over on U32. The results of this are shown below. Finally, I soldered a couple of wires to 5V and ground on the Oncore header.

Connecting to the necessary pins on U27 and U32.

I then prototyped a little board to install into the REF-0. It houses a Venus GPS, an ATTINY841 microcontroller, the necessary inverter chip, and a 3.3V regulator for the GPS. You can see below that it's quite simple. (There are just some passives underneath the board that you can't see, but the main components are visible) It secures nicely using two of the regular mounting holes for a real Oncore GPS. The final board I design will use all of them for more support.

The only thing that needs to run to the outside of the REF-0 is the GPS antenna. I think I will widen one of the vent holes at the rear of the cover to allow an SMA connector to fit through. I might even be able to find a square rubber grommet to hide the cuts and make it look really clean.

My prototype for a GPS board to install directly inside the REF-0. The only connection that needs to be made externally is to the GPS antenna.

Going Forward

I have run the prototype for over a week now and it works great. I added a few things to the code to increase reliability and monitor lock status as well. My plan is to take this and design a custom board to install in the REF-0. This board will include a modern GPS unit made for timing, such as a U-blox LEA-6T.

So that's it! I hope this information is useful in creating a long-term solution for REF-0 standalone operation. Having everything mounted neatly inside the case makes a world of difference, especially if you are running multiple units.

I tried to keep this from being horribly long, so let me know in the comments below if you need clarification on anything I described above.

Thanks for reading!

- Dan W.

Example Code for KS-24361 REF-0 Standalone Operation

In this post, I will provide some example AVR and Arduino code for running the Lucent KS-24361 REF-0 standalone.

An Arduino Uno, and a custom ATTINY841 breakout board with a TCXO.

A little bit about the code...

I posted previously about how to run your KS-24361 REF-0 standalone. In that post, I provided some modified message strings that could be sent to the REF-0 to make it run without the REF-1. It is necessary to program a microcontroller (or some other device with serial capability) to send the strings with the proper timing. Here, I share two example programs I wrote for doing that.

I originally prototyped the code on an Arduino Uno, then transferred it to Atmel Studio in proper C. The program I wrote in Atmel Studio is for an ATTINY841, which is one of my favorite AVR devices. Both programs are very similar as you will see. I tried to keep them simple and easy to read. There are a thousand ways to do anything in programming; this is just how I did it.

Before we dive in, let's take a look at some code. This is from the main loop in the AVR C version:

if (gotPPS == 1) 

  {

    PORTA |= (1 << PINA6);

    _delay_ms(75);

    advanceSecond();

    sendMessages();

    PORTA ^= (1 << PINA6);

    gotPPS = 0;

  }

This is a good starting template for what you need to do in any program to make the REF-0 run standalone. You need to: know when the PPS happens, increment the time, send the messages in the right order as scheduled, then wait for the next PPS.

The programs below are the absolute bare minimum to make this work. There is no checking of the fix status or the real message strings from the GPS. If may or may not be important to you, but by reading messages from your GPS, you can add some good features:

• Instead of time beginning at 00:00:00 when the microcontroller fires up, you can set it to UTC. This will help with re-syncing to the REF-0 if the microcontroller loses power but the REF-0 doesn't.
• Check the fix status and other things from the real GPS strings. Even though the REF-0 analyzes the stability of the PPS itself, you might want to force it into holdover immediately when the GPS signal quality degrades. Remember, it's running blind except for the PPS signal and what we tell it.

There are a couple of issues you might run into on other microcontrollers, or if you add features. First, the modified message strings take up a lot of space. You will quickly run out of RAM if you just store them as arrays, and you might want to consider using program memory. Second, watch the timing. If the program is doing nothing but waiting for the PPS interrupt, that's really easy. But if you start doing other things, you will need to be more careful with what happens when.

Finally, if you modify any message strings, don't forget to update the check character.

The Important Stuff

Ok, here's the code! I put these programs on Github as gists. Hopefully that works out well. Let me know in the comments below if you have any issues.

This first program is for an Arduino Uno. It will work on other Arduino models, but you may need to modify a couple of things. When you download the file, simply double click it after unzipping. The Arduino IDE will open and ask to put the file in a directory. Then you can check it out, compile and upload. The pinout is listed in the comments at the top of the program.

Arduino Uno Example (Github)

The second program was written in Atmel Studio 6 for an ATTINY841. You can easily modify it for other devices by changing the register setup and adapting to the pinout of your device. The pinout for the ATTINY841 is in the comments at the top.

AVR C Example (Github)

Wrap Up

Good luck getting your REF-0 working! After you test out these example programs, have fun modifying them and adding features. You have complete control over the messages that get sent to the REF-0, so there is great potential for experimentation. If you need help with the hardware setup, be sure to check out the original post on REF-0 standalone operation.

I hope this example code is useful to you. If you have questions, comments, or concerns about the example programs above, please post in the comments below.

Thanks for reading!

- Dan W.

Adding a 10MHz Output to the KS-24361 REF-1

This post will explain how to tap into the 10MHz test point signal in the REF-1 unit of the Lucent KS-24361, aka HP/Symmetricom Z3812A. I describe what is needed to route the signal to an external connector, and how I modified my own REF-1.

My REF-1 unit running standalone with a 10MHz output on the front panel.

Introduction

The KS-24361 GPSDO consists of two separate boxes. The REF-1 unit has the Motorola Oncore GPS inside and runs the show. The REF-0 box has its own OCXO and is used for redundancy. However, the REF-0 also has a useful 10MHz output, which the REF-1 does not have. For this reason, the KS-24361 is often run as a complete set, with both boxes powered up. One for the GPS, and one for 10MHz. This is quite wasteful of power, as both boxes consume about 15 watts continuously. Also, it wastes the very nice Milliren OCXO in the REF-1, which sits disciplined but unused with both boxes running.

I decided to remove and examine the board in the REF-1 to try and find the 10MHz signal. Instead of the 10MHz test point that the REF-0 has, the REF-1 uses this spot on the front panel for the GPS antenna connection. On the board, the unpopulated position for the 10MHz SMA is directly below the TNC connector for GPS. One or the other got populated, depending on whether the board would end up in a REF-0 or REF-1.

I figured that the 10MHz and 15MHz signals would be generated closer to the 15MHz connector, since that is the primary output. I also assumed that the center pin of the 10MHz SMA would have to go to unpopulated pads for a resistor or coupling capacitor. I started toning out unpopulated pads near the 15MHz side of the board and quickly found the source.

Accessing the 10MHz Test Point Signal

The 10MHz test point on the REF-0 is driven by U206, which is a 74ACT14 hex schmitt inverter. Three gates on the IC drive the output, each through separate 100 ohm resistors. The resistors feed a common trace which goes all the way to the other side of the board and the 10MHz TP output. There is also a position for a capacitor, which is used to form a low pass filter for the 10MHz TP. (I don't know what the value of that capacitor is normally. Perhaps ~100pF.)

On the REF-1, the three resistors and the capacitor are unpopulated. As far as I could determine, these four missing passives and the missing SMA connector are all that prevent a REF-1 from having the same 10MHz output as the REF-0.

Relevant locations on the REF-1 mainboard for accessing the 10MHz test point signal. Also shown is the output coupling capacitor for the 15MHz output (J4).

To access the 10MHz signal at U206, you will need to completely remove the board from the housing. That's a LOT of screws. Everything on the front panel needs to be undone, including the annoying securing screws for the DB connectors. (They all have blue Loctite by the way) Once you get the top case off, you need to remove the Oncore GPS. That takes four screws, then you can carefully pull it up and off the board. After that, there are seven or eight screws securing the board to the bottom case. Remove those, then carefully wiggle the board backward and out. It will get hung up on things on the underside, so have patience. Don't flex your board too much doing this; you don't want cracked solder joints all over.

Look at the underside of the board near the 15MHz SMA connector. Find U206 as shown above, and the pads for the unpopulated resistors and capacitor. At this point, you can tap into it as you see fit. You could re-create the normal 10 MHz TP signal, or use filtering for a sine wave. Luckily, it seems that it is unnecessary to buffer this signal. U206 is already doing that.

Once you have decided how you want to tap the signal off of U206, you will then need to get that to the outside of the unit. Remember, you can't use the normal spot for an SMA, because it is physically covered by the GPS antenna connector. There are many options, including drilling a hole in the front panel and mounting your own connector.  You could also separate the 15MHz output from the J4 SMA and send your 10MHz there. An easy way to do this is to remove the final output coupling capacitor highlighted above. Then you will just need a small piece of coax to get the signal to the J4 connector. You can easily solder to it on the underside of the board.

Possible Modifications

I first tried re-creating the stock 10MHz test point output to see what it would look like. I populated three 150 ohm resistors and a 100pF capacitor to the pads mentioned above. Then I removed the output coupling capacitor to J4, and routed the signal there through a small piece of coax. The result looks pretty similar to the 10MHz output on my REF-0. Here it is being driven into 50 ohms:

The normal 10MHz TP signal re-created on the REF-1.

For my own unit, I decided to use low pass filtering and some attenuation instead of the standard circuit. I once again sacrificed the 15MHz output and sent the signal to the J4 SMA. The result is a 1Vpp sine wave into 50 ohms. This is just about perfect for my needs.

The 10MHz sine output I added to my own REF-1 unit.

I re-assembled my unit after this modification to test it. I also found a bare DB15 connector and soldered together the necessary pins on it for standalone operation. With that inserted in the J5 Interface connector, there is no special procedure to power it up standalone and get 10MHz out. I just hook up power and the antenna and let it do it's thing. Externally, the end result is quite tidy. After an hour or two of settling, the output was less than 1ppb out.

Conclusion

Being able to add a 10MHz output to the KS-24362 REF-1 is very useful. What I have shown here is how you can re-create the normal 10MHz test point signal that exists on the REF-0. There are certainly other ways you could do it. You might be able to trace back from U206 and find a cleaner source of 10MHz. Then you could filter that to produce a 10MHz output just as nice as the normal 15MHz primary output. When I have time, I plan to explore that approach.

I hope this information was useful to you.

Thanks for reading!

- Dan W.

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.

Standalone Operation of the Lucent KS-24361 REF-0 Unit

Introduction

This post will detail how to make the REF-0 unit of the Lucent KS-24361, aka HP/Symmetricom Z3812A, run standalone.

My REF-0 running standalone with support from a Venus GPS module and an Arduino.

The KS-24361 has been available on the usual auction site for quite a while. It is an old GPSDO, but new-old-stock surplus units can be purchased for a reasonable price. The KS-24361 is designed to run as a pair of boxes. The REF-1 box has the GPS module inside. The REF-0 does not have a GPS, and is controlled by the REF-1 box. However, the REF-0 does have a useful 10MHz output. Both have high quality Milliren OCXOs inside. Steward Cobb on the Time-Nuts mailing list wrote a very detailed review of this GPSDO. I highly recommend you read that if you haven't already.

If you want to run the KS-24361 normally, it is very easy. Hook up a GPS antenna and the interface cable, and power the boxes from +24V as described by Steward. After some time the green "ON" light will appear on the REF-0 and the other lights will extinguish. The REF-1 will flash that it is in standby mode, though of course it is still doing quite a lot. It has to discipline its own OCXO and pass the GPS data to the REF-0 box. Several connectors are available for reading out serial data and accessing the pulse-per-second (PPS).

For various reasons, many more REF-0 boxes are available by themselves than complete systems. At the time of this writing, a single REF-0 costs $25 plus shipping. The problem is that the REF-0 does not have a GPS, so normally it can not run by itself.

Is there a way to add a different GPS and run the REF-0 as a standalone unit? There sure is.

Much of the groundwork for this project was done by members of the Time-Nuts community. Recently, Bob Camp provided a detailed writeup on how the interface connector on the boxes works, and what signaling is needed to make the REF-0 think a REF-1 is attached when it is not. I made the necessary connections as described by Bob and got my own REF-0 to turn its outputs on. The main issue remaining at that point was getting the unit to accept a PPS signal and discipline its oscillator. Bob describes in his writeup several messages that are passed between the REF-1 and REF-0 during normal operation. These would be needed, with correct information in certain fields and sent at the right intervals, to make the REF-0 work. This is where I attempted to help with the project.

Creating a GPS Neverland for the REF-0 to live in

Analyzing the serial output of my REF-1 on the interface connector, I found that the following messages were passed at the listed intervals:

• Every Second (75ms after the PPS edge)
• @@Ea - Position, status, and general data
• @@En - Set alarm limits for T-RAIM
• 6 Second Interval
• @@Bb - Visible satellite status
• 8 Second Interval
• @@Ap - Set user datum
• 30 Second Interval
• @@Aw - Time mode
• 40 Second Interval (for each, but spaced out, not all at once)
• @@Ag - Satellite mask angle
• @@At - Go to position hold mode
• @@Az - Offset the 1PPS for antenna delay
• @@Bj - Leap second pending
• @@Bo - UTC offset status message

These messages are in an older Motorola format used by the Oncore GPS in the REF-1. Other messages may be sent at other times, but this is what's sent during normal operation. Some of them have limited usefulness to the REF-0 and are for setup after a hot swap. Nonetheless, they fill in data fields that need to be filled, so the REF-0 is looking for them. We need to send these messages to the REF-0, make it think the GPS lock is good, and accept the PPS signal as valid.

I modified the messages to create a perfect fake GPS environment for the REF-0. It thinks a full set of eight satellites are being tracked directly overhead, at 0 degrees latitude 0 degrees longitude, on January 1st 1998. That may sound funny, but if you are familiar with these messages, you'll know why that is.

Through significant trial and error, I figured out strings that work, and how to send them. Here are the modified message strings:

@@Ea
0x40, 0x40, 0x45, 0x61, 0x01, 0x01, 0x07, 0xCE, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0A, 0x08,
0x02, 0x08, 0xFF, 0x82, 0x04, 0x08, 0xFF, 0x82, 0x06, 0x08,
0xFF, 0x82, 0x08, 0x08, 0xFF, 0x82, 0x0A, 0x08, 0xFF, 0x82,
0x0C, 0x08, 0xFF, 0x82, 0x0E, 0x08, 0xFF, 0x82, 0x10, 0x08,
0xFF, 0x82, 0x20, 0xDF, 0x0D, 0x0A

Note: The 9th, 10th, and 11th bytes are the hour, minute, and seconds. 

The third to last byte is the check character.

@@En
0x40, 0x40, 0x45, 0x6E, 0x01, 0x01, 0x00, 0xC0, 0x01, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,
0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00,
0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00,
0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x0A, 0x00, 0x00, 0x00,
0x00, 0x0C, 0x00, 0x00, 0x00, 0x00, 0x0E, 0x00, 0x00, 0x00,
0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0xFA, 0x0D, 0x0A

@@Bb
0x40, 0x40, 0x42, 0x62, 0x0A, 0x02, 0x00, 0x00, 0x5A, 0x00,
0x00, 0x00, 0x04, 0x00, 0x00, 0x5A, 0x00, 0x00, 0x00, 0x06,
0x00, 0x00, 0x5A, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x5A,
0x00, 0x00, 0x00, 0x0A, 0x00, 0x00, 0x5A, 0x00, 0x00, 0x00,
0x0C, 0x00, 0x00, 0x5A, 0x00, 0x00, 0x00, 0x0E, 0x00, 0x00,
0x5A, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x5A, 0x00, 0x00,
0x00, 0x12, 0x00, 0x00, 0x5A, 0x00, 0x00, 0x00, 0x14, 0x00,
0x00, 0x5A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3C,
0x0D, 0x0A

@@Ap
0x40, 0x40, 0x41, 0x70, 0x32, 0x61, 0x52, 0x99, 0x00, 0x81,
0x01, 0x2A, 0x0F, 0x54, 0xEB, 0x8B, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x38, 0x0D, 0x0A

@@Aw
0x40, 0x40, 0x41, 0x77, 0x00, 0x36, 0x0D, 0x0A

@@Ag
0x40, 0x40, 0x41, 0x67, 0x0A, 0x2C, 0x0D, 0x0A

@@At
0x40, 0x40, 0x41, 0x74, 0x01, 0x34, 0x0D, 0x0A

@@Az
0x40, 0x40, 0x41, 0x7A, 0x00, 0x00, 0x00, 0x00, 0x3B, 0x0D,
0x0A

@@Bj
0x40, 0x40, 0x42, 0x6A, 0x00, 0x28, 0x0D, 0x0A

@@Bo
0x40, 0x40, 0x42, 0x6F, 0x00, 0x2D, 0x0D, 0x0A

These messages need to be sent to the REF-0 at the intervals listed above, 9600 baud 8N1. 75ms after the PPS edge, send the @@Ea message, immediately followed by @@En, then any other messages due that second.

BUT there is one small wrinkle. The time sent in the @@Ea message actually needs to increment. The REF-0 keeps its own internal clock. If you don't increment the seconds it will never accept the lock. If you don't increment the minutes and hours, it will initially accept the GPS lock, but when it later checks and finds the time incorrect, it will consider GPS lost. The check character in the message also needs to be updated every time you send the message, since you modified the contents. (The check character is an XOR of each byte in the string after the first two bytes but before the check itself. Sorry I know that's a mouthful.)

If you google search for a Motorola Oncore message format guide, you can see for yourself what I have done to these messages. You can also of course modify them as you like. Don't forget to update the check character.

What You Need to Do

If you want a REF-0, search on eBay for "KS-24361" (I have zero connection to the main seller of these units). Other sources of REF-0s may be available. Prices may go up in the future, and units will eventually dry up. If you are reading this two years from now, sorry. The situation is probably very different.

It goes without saying, be safe when working on electronics and double check every connection before applying power.

To get your REF-0 working standalone, you need to:

1. Program a microcontroller to send the above listed strings at the above intervals. You also need to send the PPS signal to the microcontroller so that it knows when to send the messages. They have to be transmitted 75ms after the PPS edge. There are a few ms of wiggle either way, but timing is still important. I recommend an interrupt.
2. Power up a GPS that has a good, stable PPS output. I used a Venus GPS module, but others will work. Also, you need to find out if your PPS signal is normally low and pulses high, or if it is normally high and pulses low.
3. Hook up a schmitt inverter IC. I used a 74LVC14. A 5V supply will work fine if your inverter IC supports that. If not, 3.3V should work too. You need to send the serial output from the microcontroller through an inverter gate to go to the REF-0. If your GPS PPS is normally low, that also needs to go through a separate inverter gate before going to the REF-0.
4. Wire the pins on the interface connector as described by Bob, and as shown below. You probably want to find a bare DB15 connector and solder this together for reliability after you test it.
5. Power the REF-0 from +24V (up to 2 amps) as described by Steward above, and as shown below.

The power connector on the REF-0.

The interface connector on the REF-0.

What will happen next:

1. A test sequence will flash on the LEDs, then the NO GPS and FAULT lights will come on.
2. After some time (the OCXO is warming up) the FAULT light will go off and the ON LED will come on.
3. Now you are waiting for the NO GPS light to go off. If it does, and only the ON light remains lit, you are successful. Monitor the unit for several hours. If the "NO GPS" light comes on again and stays on, the time in the serial string may not be incrementing properly.
4. If you know what SatStat is and how to use it, hook that up and monitor the status screen for more information.

Assuming only the green ON light is lit, then congratulations, you now have a GPSDO. The outputs should stabilize and be very accurate within a few hours to a few weeks, depending on how you define "accurate" and "stable".

Going Forward

This is a brand new procedure and problems will be found. Some GPS modules with different looking PPS signals may not work. There may be code lurking inside the REF-0 which is checking a field we don't know about yet, and it will eventually become unhappy. But for now, this is a good start.

If you know how to do everything above, including programing a microcontroller of your choice, go for it! Enjoy your newly functioning REF-0 unit. If not, I will post a follow up to this in the future with code and more information.

Again, much credit is due to fellow Time-Nuts members. This is just one project, but much work has been done with these units over the past years. In no particular order: Bob Camp, Steward Cobb, Skip Withrow, Gerhard Hoffmann, Arthur Dent, and Ole Petter Ronningen. There are certainly others and I will add their names here when I learn of them.

Thanks for reading!

-Dan W.