Denuo GPS Hits Rev B + Dongles...

This is a quick update on the REF-0 projects I have going.

REF-0s running my Denuo GPS board. All lights green.

The Denuo GPS has hit Revision B. There were very minor changes to the original board, mainly to tweak the BOM. I have also hit firmware version 0.6, which I feel is very stable and reliable. There is always room for improvement, but I am close to calling the firmware "done".

I have also been thinking on what a Denuo GPS retrofit kit for the REF-0 would look like. One of the important steps in prepping a REF-0 for standalone operation is eliminating the need for the interface cable. I have covered multiple techniques for doing this in my previous posts. However, a kit would have to be as simple as possible to install. Looking for unlabeled pins on the bottom of a PCB and soldering fine bodge wires is not a good installation method. Neither is jamming wires into a DB15 socket. For that reason, I made this:

A dongle to replace the interface cable on the KS-24361 units.

It is effectively a "magic dongle" for the KS-24361. It jumpers the necessary pins to eliminate the other box and the interface cable. Plug it into a REF-1 and the unit turns on the outputs and operates standalone. Plug it into a REF-0, install a replacement GPS internally such as the Denuo board, and it hums away all by itself.

There will still be soldering involved in any REF-0 retrofit. But this dongle should greatly simplify things.

As for the Tria GPS board, that project is coming along slowly but surely. Attempting to implement Oncore UT+ compatibility is a big undertaking, but I've made good progress. I have a solid plan to get to the finish line.

That's all for now. I should have something interesting to post about in a week or two. It's a brand new project involving...FPGAs.

Thanks for reading!

- Dan W.

Distractions

If I don't stop getting distracted, I'll never finish the Tria GPS firmware. Hmm...

- Dan W.

Simulating GPS Week Rollover with the Tria GPS

GPS week rollover is an interesting "bug" in the way GPS keeps track of the date. Rollovers are not frequent, but when they do occur, it is possible for equipment reliant on a GPS lock to malfunction. At the very least, equipment made on one side of a rollover may not correctly display the date after the rollover. There are many articles online that cover the issue in-depth, so I won't attempt to explain it here. These are some links:

http://tycho.usno.navy.mil/gps_week.html

http://www.leapsecond.com/notes/gpswnro.htm

http://www.navcen.uscg.gov/?pageName=gpsweek

GPS week rollover can be a problem on older surplus timing gear that is still in operation. The user may have to reset the unit after a rollover, or deal with an incorrect date display. As the Tria GPS module I am designing is meant for use in just such a unit, the Lucent KS-24361, I decided to do some experimentation on the rollover issue with this box. The Tria GPS has a simple text-based user interface over a serial UART, so I added a GPS week rollover simulation to the available options. After this is selected and the unit is power cycled, the GPS module fast-forwards the date and time to 30 minutes before midnight, April 6th, 2019 to simulate the next rollover.

I used a REF-0 for these tests.

Tria GPS warning the user that the simulation is in progress.

Here's the view in SatStat.

Synchronized to GPS time all right... 4 years in the future.

Simulating this on my board is actually very easy to do. I have complete control over the Oncore serial strings and what I send the GPSDO, so changing the date is just a slight modification to the initialization routine.

As the time approached "midnight", I connected to the U-blox LEA-6T module in u-center and ended the automatic survey early. This way, we could hit midnight in normally operating conditions. Being able to modify GPS settings in u-center is a really nice feature of the Tria GPS.

Changing GPS configuration settings in u-center, and seeing the results in SatStat.

For this simulation, I programmed the module to roll the date back to August 1999 at midnight. That, of course, was when the last rollover occurred. Here I am simulating a GPS module that was built between the rollovers and can't display dates beyond April 6th, 2019.

The simulated rollover just occurred. Will the REF-0 handle it ok?

Well, as you may have expected, nothing dramatic happened. I have found the KS-24361 units to be very tolerant of date/time "mishaps". They simply reset their internal clocks after a minute or so when a significant change occurs on the date/time presented in the serial strings. After the rollover, the unit displayed the wrong date, but never threw an alarm or lost lock.

The REF-0 continues to operate normally after the rollover. However, it now shows

the incorrect date that is being sent to it.

If I can inject a problem with the Tria GPS, I can also fix the problem. U-blox modules handle GPS week rollover pretty well, and of course the RTC in the Tria GPS understands more than 1024 weeks. So it's very possible to "fix" the rollover problem and just send the GPSDO the correct date after April 6th, 2019. I modified my simulation routine to do this with good results.

Here the Tria GPS and REF-0 have rolled over to April 7th 2019 with no ill effects.

This sent me on a quest to determine the actual date range supported by the KS-24361 firmware. Is it effectively unlimited, and the only limitation is the GPS module? Or is there some other date rollover we will eventually hit on these units? I simulated dates further in the future and went all the way up to 2038 with no issues. That's when I ran into the 2038 bug in the C time library I am using. Sigh...

We really broke the date on the Tria GPS and REF-0 trying to go past 19 January 2038.

But this is due to a very different rollover bug.

2038 is a long way off, so I'm not going to worry about that one right now.

By this point, dealing with leaps into the future, two different date rollover bugs, and the outer limits of the C time library had given me a headache. I was quite happy to reset the clock to the correct time and wrap things up.

Summary

Playing around with GPS week rollover simulation was an interesting experiment. In the end though, the Tria GPS makes the whole thing a non-issue. One of the many benefits of upgrading to a modern GPS receiver from the Oncore UT+ receivers is that we can better handle things like GPS week limits and leap seconds. This should keep old GPSDOs operating well past the next "rollover".

Thanks for reading!

- Dan W. 

Tria GPS Success in the REF-0

I made some good progress yesterday on the Tria GPS firmware. I have been finding and fixing little bugs over the past few days, and finally got to the point where I could test my Oncore message formatting routine. This is an entirely new chunk of code that creates Oncore message strings in real-time using data sent from the U-blox GPS. That is a very different approach from my previous REF-0 standalone techniques, which used canned strings to make a REF-0 lock up. I am now sending real data in all of the messages, including SV info, position, date/time, and configuration settings.

I dropped the Tria GPS into a REF-0 and launched SatStat to view the status screen. To my slight surprise, nearly everything was populated correctly. I had to make some minor adjustments, but the new Oncore message formatting routine is a success. Here's a screen capture of SatStat for the REF-0 with the Tria GPS:

Status Screen for a REF-0 with the Tria GPS

The SV info is little wonky. Partly that is because I have to adapt satellite info for a 16 channel receiver to 8- and 12-channel messages. I plan to do some more sorting to ensure that the top 12 SVs that the U-blox has acquired appear in the status screen of the GPSDO.

With my message formatting routine working, I am closer to the end goal of full Oncore compatibility. I now need to write some code to allow the GPSDO to send commands to the Tria GPS and configure it. Once that is done, I will be able to make a REF-1 lock up using the new GPS. That will be exciting.

Thanks for reading!

- Dan W.

PCB Progress on the Tria GPS

Lots of progress today on the Tria GPS board. I got the PCBs back and assembled the first one. So far it tests out good.

SMT is so clean. My least favorite part of assembly is

soldering on the through-hole bits.

Now begins the long process of completing, testing, and verifying the firmware...

- Dan W.

Measuring Time Takes Time

Here's a little bit of data on the Denuo GPS in a REF-0 during the warm-up period.

Classic "lots of zeros" picture of the REF-0 10MHz output.
Does this shot have much meaning? Not really.

I've been collecting phase data on the REF-0 and Denuo GPS as the pair warms up. My equipment is quite limited, and it's difficult for me to collect useful frequency data in the E-13 range. So I thought I'd just measure the phase difference between the REF-0 PPS and a stock REF-1 with the Oncore GPS. Perhaps measuring the two relative to each other will provide some insight on how a REF-0 performs with a non-timing GPS.

No data was collected for the first two days. I did monitor it casually on the counter, and it was exactly as you'd expect. Lots of big swings and settling.

Below are traces showing T + 48 to 72 hours, and T + 72 to 96 hours.

Notice the "pop" of noise during day three of the warmup.

Make sure to notice the scale when comparing this plot to the first one.

It's difficult to know what's causing what in these plots. The REF-1 has a 15 year old GPS receiver. The REF-0 has a non-timing GPS with no position hold, but great sensitivity. Better references and lots more time will be required to know more.

Though, something interesting happens when you overlay the two plots.

Plots from two consecutive 24 hour periods shown together.

The consistency between them in many spots is easy to see, even though the traces are separated by exactly 24 hours from each other. Especially during the middle of the plot, which would have been the overnight hours, the two follow each other closely. I'm not sure if there's actually anything useful to glean from that.

That's all for now. There's not much data yet, but any comments are welcome. We'll see how the unit does after a week of being on, then a month, then.... 

Thanks for reading!

- Dan W.

Denuo GPS Retrofit Board

Here is another quick post about some progress I've made toward developing a retrofit board for the Lucent KS-24361 REF-0.

Denuo GPS Retrofit Board for the KS-24361 REF-0

The Denuo GPS is a drop-in retrofit board for the REF-0. It uses the u-blox NEO-6M GPS module. There is a microcontroller on the board that translates the UBX serial messages from the u-blox to the Oncore format for the REF-0. The microcontroller also replicates control functionality of the REF-1, in that it automatically sends the appropriate messages with the correct timing for the GPSDO to operate. This enables standalone operation. While the NEO-6M is not a timing GPS, the board is still able to send sawtooth correction and other timing-related information.

The board is a significant step up from my previous prototyping efforts. It installs just like an Oncore GPS would in a REF-1. Power and signaling are handled through the 10-pin header used by a real Oncore. There are a small number of modifications that need to be made to the REF-0 to enable this, such as mounting standoffs and removing two SMD jumpers. The normal antenna mounting location is not present on a REF-0, so I opted for a u.FL connector and a pigtail to the outside. I think the finished install looks pretty nice. What do you think?

The Denuo GPS board mounted inside of a REF-0.

The board also has some neat features that are enabled by the modern GPS receiver. Sensitivity is hugely improved compared to the Oncore. Time to first fix is several seconds instead of several minutes. Also, the board breaks out the USB connector of the u-blox GPS. I can now monitor GPS status and tweak settings using the free u-center application.

So you might be thinking, "Where's the beef?" Or rather, where's the timing GPS module? The REF-0 is a GPSDO after all, and the original Oncore GPS was of course made for timing. Don't worry, that version of the board is in the works too.

A sneak peek at the Tria GPS Timing Module.

So that's it! I have a REF-0 with the Denuo GPS humming away in a quiet corner. Over the next few weeks, I'll be collecting data on the performance of the GPSDO with this retrofit board.

More to come.

Thanks for reading!

- Dan W.

Sneak Peek

My REF-0 project is about to take a big step forward.

 

- Dan W.

A Nearly Perfect U-blox GPS Breakout

Here's a quick post about a breakout board I made for the U-blox NEO-6M GPS. U-blox makes many excellent GNSS modules. The NEO-6 series is not their latest and greatest. However, the NEO-6M in particular strikes a great compromise between price and performance. It is an excellent GPS-only receiver that can be had in the $10 range online. Small breakout boards can be found for as little as $12.

My issue with the commonly available NEO-6 boards is that most do not break out all of the features of the module. The cheapest ones bring out the serial pins, but do not utilize the USB functionality. Also, few (if any) provide a buffered PPS signal through an SMA connector. These two features in particular are why I decided to design my own.

My u-blox NEO-6M breakout board.

The board has USB for monitoring and configuration via u-center. It also has a buffered PPS output, a backup battery holder, and it works with active antennas. GPS reception on this board is just as good as with any other breakout or Eval kit I've tried.

I'm very happy with how this board turned out. I will be re-using much of this layout in my development of a retrofit GPS board for the Lucent KS-24361 REF-0.

Thanks for reading!

- Dan W.

Custom PCB for KS-24361 REF-0 Standalone Operation

In this post I will describe a custom PCB I designed to enable standalone operation of the Lucent KS-24361 REF-0.

My custom board to enable REF-0 standalone operation.

Introduction

In my last post on the KS-24361, I described a prototype of a GPS retrofit board I made for the REF-0. I will eventually turn that into a proper PCB with a u-blox GPS onboard. However, I decided to make an intermediate board that does not have the GPS module. It merely contains a microcontroller and some miscellaneous circuitry. This board has allowed me to test dimensions, footprints, and a host of other things that will aid development of future boards.

The Design

Even though this will not be the final board design, I still wanted it to be useful. It has an ATTINY85 microcontroller for sending the serial strings to the REF-0 and synchronizing to the PPS signal. It also contains inverters and buffers. The serial transmissions to the REF-0 have to be inverted, so that is taken care of automatically. Also, the board will accept either polarity of PPS signal, at 3.3-5V. Selecting if the PPS to the REF-0 is inverted or just buffered is handled with solder jumpers that can be easily changed. The setting for the PPS polarity to the microcontroller can also be independently set. Finally, I put a 3.3V regulator on the board to accommodate lower voltage GPS modules. The board has a 5V hookup on the header as well.

The board mounts neatly using two mounting holes that would normally support an Oncore GPS in a REF-1. I described in my previous post how to solder some jumpers to the REF-0 mainboard so that nothing needs to be connected externally (accept for the antenna if you are using GPS). The PPS signal can be connected via a 0.1" header pin or the SMA connector. There is a spot for a termination resistor (R2) on the incoming PPS line if needed. Overall, the board is very flexible.

Potential Uses

There are several ways this board could be used. As it takes care of the serial strings, the only thing that needs to be provided to make the REF-0 hum is the PPS signal. The most likely source is GPS, and a module could be installed inside or outside of the case. But GPS is not the only option. The REF-0 could potentially be used as a clean-up oscillator for a Rubidium standard. This board would handle that quite easily.

I decided to go with GPS in one of my REF-0s and mounted a u-blox NEO-6M module inside the case. This little GPS board can be had for $12 to $15 USD online; it's a real bargain. I arranged the two boards in a stacked configuration as shown, and kept the wires as neat as possible.

My custom board and a u-blox NEO-6M make the REF-0 operate quite happily. The messy jumper wires will be completely eliminated in the next board design.

The only connection that needed to be made externally was for the GPS antenna. I used a uFL to SMA pigtail to accomplish this. The SMA bulkhead connector mounted nicely in one of the slots in the cover. It required a tiny amount of filing to fit it through, but by opening up the slot just enough it locked into place quite securely. I think I will use this approach in the future.

Here you can see the SMA bulkhead connector mounted nicely at the rear of the REF-0, and the pigtail connecting to the u-blox GPS module inside.

Wrap Up

I'm very happy with how this little board turned out. As I have time over the next few weeks (engineering students have nothing but free time of course...) I will merge this design with a u-blox GPS layout I have already completed and take this project to the next step. Gradually this is moving toward a single-board solution that will have a very professional appearance when installed, and a high degree of performance and reliability.

I don't know if this will ever turn into a kit. Currently my goal is to document what I am doing so that others can take it as a starting point and go even further. If I eventually get to a board design that I am happy with, I may consider figuring out a way to make it available to others.

Thanks for reading!

- Dan W.

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.