[time-nuts] KS-24361 REF-0 standalone
kb8tq at n1k.org
Fri Aug 7 21:48:51 EDT 2015
Here’s a quick and dirty approach to getting a Z3812A, KS-24361 L101, RFTG-u, Ref-0 box
up and running on it’s own.
First P1 the +24VDC input. It’s a male 9 pin connector. The pins are all labeled on the connector.
The numbers are small, but they are there. They are also labeled on every example of the mating
connector I have ever seen.
Pin 1 gets the positive lead from the supply
Pin 2 gets the negative (return) lead from the supply.
The rated supply range is 18 to 36V. I would not go below 19V based on previous experience
with these bricks. Current at 28V will start out around 1.3A.
Next up is the RS-422/1PPS port J6. Again this is a 9 pin connector with all of the pins labeled
on the connector. Since it’s a female connector, the pin order is not the same as on a male
connector when you are looking at the face of the connector. The pin *locations* are the same,
they mate face to face.
Pins 1 and 6 form the PPS output pair. Pin 1 is +.
Pins 4 and 8 form the RX data (data going into the box and out of the computer) pair. Pin 4 is +.
Pins 5 and 9 form the TX data pair. Pin 5 is plus.
Pin 3 is ground
The J8-diagnostic port is identical to J6 except it does not have the 1 pps output.
All data on these two ports is at RS-422 signaling levels. They are not the same as RS-232. You
should use a converter with these levels. When connecting up things remember that with a
serial connection the wire has a transmitter on one end and a receiver on the other end.
Data format is 9600 baud, 8 data bits, no parity, one stop bit. This is often called 8N1. If you power
up the box and type *IDN? It should come back and tell you what sort of box it is. This same approach
works for checking serial connections to a lot of HP gear. It’s standard SCPI stuff. The other handy
command is :SYST:STAT?. It will show you a nice screen full of information about what the device is doing.
If you power the box up at this point, you can talk to it via serial. The LED’s on the right side will come
on and tell you that there are various things wrong:
NO GPS = the box has not seen a data string from a Motorola Oncore GPS in a a while
FAULT = the magic 15 pin cable is not plugged in
STBY = the box is not the master unit for the cell site
ON = we have power.
The goal obviously is to get the yellow and red LED’s to turn off while keeping the green LED glowing.
The only connections required to do this are on J5 the Interface connector. J5 is a 15 pin connector. Like
the rest, the pins are all labeled. While 15 pins sounds like a lot, it is a fairly simple interface. We will
start out slow with this connector. We will get it all taken care of.
J5 pins connections and uses ( AKA .. the good stuff)
Pins 8 and 13 are tied to ground inside the unit. Either one of these gets tied to directly to pin 3. This
wire signals to the Ref-0 that a Ref-1 is plugged to wired to the connector. The standard cable takes
pin 3 to pin 13 (which is also grounded on the Ref-1). No active signaling is done on pin 3 It’s just a solid ground
in the normal setup.
Pins 6 and 10 let the boxes tell each other what the setting on SW1, the output level switch is set to.
If you set it to 23 ( = 23 dbm) you get an error flag. Just leave the switch at 17 dbm. Jumper pin
6 to pin 10 to keep things happy signal wise.
So far, nothing we have done is any different on the REF-1 and getting it running stand alone. In fact, much
of the process of getting a REF-0 going stand alone is the same as the REF-1.
Pin 1 is the serial output (5V CMOS levels) from the box. Since there is no serial out of this box, the pin is open.
Just ignore it. Pin 15 is the serial input to the box (also 5V levels). It will need the GPS data on it.
Pin 1 of the Ref-1 box does have serial data on it. That data is a duplicate of the serial output of the Motorola
Oncore in that box. The Oncore is set up and operated entirely by the CPU and firmware in the Ref-1. The data
stream has the @@ Ea (position), @@En (time), @@Bb (visible satellites) and @@Bo (UTC offset) information in it.
If the objective is to fill all of the entries in the data screen on the Ref-0 with accurate data, all of these strings
would need to be present and 100% correct to the firmware used in the HP / Symmetricom version of
the Oncore. If the objective is to simply have the Ref-0 run as a GPSDO, fake strings can be used.
Pin 15 is the serial data input to the Ref-0. It is the magic pin that the Oncore serial (or fake strings) need to show up on.
If you are running an Oncore, then simply setting it up to run a survey, then locking it in position are needed to
get the GPS module going. After that it needs to be set up to put out the Three strings listed above on a regular
basis. The string with the TRAIM and sawtooth data needs to come in once a second. You might get away with
fairly slow rates on the other strings.
Next up is the PPS input to the Ref-0. It’s on pin 11. Like the other signals, it is 5V CMOS. The PPS should be aligned
with the serial strings in the normal Motorola fashion. Not a big deal with an Oncore. It’s something to watch out
for if you are simply putting in faked strings with dummy “I live at the north pole” data.
The complement of pin 11 is pin 5. That has the pps out of the REF-0 on it.
This leaves a few pin pairs (2 pairs of each type):
2 and 14 Pair A
4 and 12 Pair B
7 and 9 Pair C
In each case above the pins on the Ref-0 map to the pins on the Ref 1. Pin 2 on the Ref-0 goes to Pin 14 on the Ref-1.
Pin 2 on the Ref-1 goes to pin 14 on the Ref-0. The internal firmware refers to these pairs (pair A) as “Ready”.
Pairs B and C are not mentioned in the firmware as far as I know. As with all of the lines above, some of this stuff
is done with open drain driving a pull up on the other end. The typical pull up resistances are in the 1K to
In normal operation (Ref 1 in charge) the pairs look like this at the Ref 1 end:
Pin 2 low
Pin 14 low
(both are ready to operate, low = ready)
Pin 2 appears to be an input with a pull up. Pin 14 appears to be a driver.
Pin 4 high
Pin 12 low
(one is in charge, the other one is not)
Pin 4 appears to be an input with pull up. Pin 12 appears to be a driver. Again active
low signaling. Pin 12 is the Ref-1 saying it’s in charge.
Pin 7 high
Pin 9 low
(again one is in charge, the other is not)
Pin 7 appears to be the driver. Pin 9 appears to be the receiver.
PLEASE note the qualifier above => all those pin numbers are the REF-1 end of the pair NOT the REF-0 end.
Tracking back to the REF-0 requires you reverse the pin numbers (It’s just a piece of wire …).
So what do we need?
Since there is no Ref-1 in this system, the signaling that is only for it’s use is not needed. All we really
need to do is convince the Ref-0 that:
1) The cable is hooked up (did this with pin 3)
2) The world is fine (low on both pair A's)
3) The Ref-1 wants the Ref-0 to be in charge. Pair C (or possibly Pair B)
Once you have the right set of signals on those pairs, the Ref-0 is happy that it is doing the right thing by
turning it’s outputs on. It’s been running as a GPSDO the whole time, so that part does not require any intervention at all.
That makes it sound like a pretty simple ground this open that sort of thing. There may be a solid way
to do it that simply. The question is – does it keep running ok with a simple connection? In normal operation,
the control lines go through a little dance. Ready comes on from the REF-1 first and then comes on (remember
on = low in this case) a bit later. The rest of the control lines seem to go through a test sequence (along with
the LED’s) at boot. If failing this test has an impact, it’s not obvious.
This is all “that goes low then next this goes low” sort of signaling. There are no complex data transfers between
the two boxes. You probably can do the whole process with LED’s, toggle switches and a good sense of timing. When
they are running as a set, NONE of the data entered into the REF-0 shows up in any way on the REF-1. The only
data from the REF-1 that makes it to the REF-0 is contained in the GPS strings.
So what to do:
Ground both pair A's, that seems to be pretty obvious.
Reverse signals on each Pair B and C. That also seems like a good bet.
Is there more that you need to do to keep it stable long term? Maybe, only time will tell.
So what to do hardware wise:
You need an MCU. It’s got pins. They can drive 5V lines. Rather than hard wiring the state of these pairs, drive
them each with a tri-state buffer. Two pins per pair, six pairs, twelve i/o’s off of your MCU. If you run into the
need for a bit of a dance on the lines – you have the hardware to make it happen. Just tweak the firmware.
All of this likely is also contingent on your GPS approach and what your PPS looks like.
So what to do system wise:
1) Pick any one of a couple hundred MCU’s. Please don’t try to tell me that there is “obviously only one that makes sense”.
That simply is not true. Most of the parts that people seem to think are the “one and only” have been obsolete for
a decade or two. Modern parts and tools make things much easier.
2) Decide on a GPS to use. I see at least a dozen good candidates out there. A 1997 vintage
Oncore would pretty far down on my list. The auction sites are awash in candidates at dirt cheap prices.
3) Find a power supply. There are lots to pick between. I use 28 V supplies.
4) Start wiring stuff up. Check things out each step of the way.
5) Decide how fancy you want the result to get (How many status fields are correct). Do log files (dates) matter?
6) Write some code that is specific to your decisions on 1,2, and 5 above. The choices I make and the code
I write likely will be of zero use to you unless your objective is a WWVB receiver ….
Now, that’s not the only way to do it. There is code in the EPROM’s on the board. You could extract that code. Then
reverse it back to a fully commented and documented listing. After that you could re-write it as a stand alone system.
Next shoot it back in the device and debug the result. Since that is by definition the “zero cost” option, use it as a test case in terms
of what time is worth…..Before you suggest that it’s a fine use of somebody else’s time - try doing it yourself.
Don’t have the skills? Time to grab a book. None of us do this without the hard work of learning how to do it.
It’s not a matter of “you’re closer to the pot, grab it for me”. Anybody can learn how do to this if they try.
So - what’s time worth? You can say that for a hobby it’s free. If it’s a hobby, it does not involve somebody else deciding
you get to spend the next 4 years in programming school in order to do the next fun step. Only the fun stuff counts as hobby
time. The rest of it is work, just like cooking burgers at the local MacDonalds.
Lots and lots of choices. Each of us will have a different opinion on what the single correct choice is at each and
every turn. Most will be un-interested in the other choices at those turns. For every person who actually wires
this stuff up. There will be at least three dozen who extol far better choices that should have been made. The only
decisions that count are the ones made by the people doing the wiring. They are the only ones with skin in the game.
I’m quite sure that we could spend at least two months debating the exact gauge and type of wire that is uniquely
and solely capable of being used as a jumper between pin 13 and pin 3. Another few months could be spent
contrasting this optimum jumper wire with the proper wire for pin 6. The ultimate result of that debate will be
this all heading back off to a dark corner off list again. That debate holds no value (though it is fun). It can quickly
get this turned into a “should be off list” topic again.
So here’s what I’d like to suggest – keep the “my wire is the only one to use” stuff to a minimum. Keep the questions
that are easily answered by Mr. Google (what does a 9 pin connector look like) off the list. Investigate basic
troubleshooting techniques for things like serial communications via the same trustworthy Mr. Google before
dumping that all on the list.
Why? Because I’d like to save the bandwidth for useful stuff like “here’s a sequence that works on the control pairs”
or “guess what, you don’t need all those GPS strings all the time” or “the third jumper from the left next to the
big IC makes it run stand alone with no goofy stuff”. That’s the sort of thing that is useful and that is exactly the
sort of thing that the wire debate and repeat questions pushes off the list.
Getting the useful stuff out in the open is much easier if we can all post what we have found. Some of it will be
wrong (that’s a given, we all make mistakes). Some of it will be dead ends. Some of it will be good stuff. What you
run into as a dead end may be the answer to what I have half done. Your mistake may be so close to one I just
made that it saves me a week of hassle. Technical information exchange has value. It does not just have value now.
It also has value a decade from now when somebody looks in the archives and sees how it was done before. You
never know what you might pick up from a random decade old conversation between two guys named Tom and John….
> On Aug 7, 2015, at 2:06 PM, paul swed <paulswedb at gmail.com> wrote:
> Looking forward to the notes.
> Yes it could be fairly simple if what ref 0 wants is a string that
> essentially says the system is fixed with 3 d accuracy. Perhaps after that
> the ref 0 makes no checks other then the string keeps coming with the
> correct quality. Not to push a particular proc but any of the low end ones
> will do that stunt very easily.
> That would be pretty sweet.
> On Fri, Aug 7, 2015 at 10:13 AM, Bob Camp <kb8tq at n1k.org> wrote:
>> Ok, I will write something up and post it here. It will probably take a
>> few days
>> to get it all into a form that answers most of the questions.
>> What you will need:
>> 1) A working REF-0
>> 2) A PIC or other micro to get things going
>> 3) A GPS with a PPS output (any will do)
>> 4) Code specific to your GPS and the needs of the REF-0
>> Since the Oncore needs to be set up each time it’s booted, there is no real
>> advantage to using one. You still need an MCU in the mix.
>> More to follow.
>>> On Aug 7, 2015, at 5:24 AM, Graham <planophore at aei.ca> wrote:
>>> I would like that information too please and thank you.
>>> I have a pair that is working quite well and I also have a second REF-0
>> that I want to start testing but just haven't got round to it yet to figure
>> out what is needed.
>>> cheers, Graham ve3gtc
>>> On 2015-08-07 02:39, Bob Camp wrote:
>>>> You need to get the Oncore running with the correct position locked in
>> and spitting out the right strings.
>>>> That’s all done by the CPU in the REF-1 unit. The REF-0 simply grabs
>> the data off of the string
>>>> as it comes by.
>>>> I’ll see if I can dig out the information and send it to you off list.
>> It’s buried around here somewhere.
>>>>> On Aug 6, 2015, at 10:02 PM, Edesio Costa e Silva <
>> time-nuts at tardis.net.br> wrote:
>>>>> I have some Motorola Oncore available.
>>>>> Can you detail this "fairly simple manipulation of the signal lines"?
>>>>> On Thu, Aug 06, 2015 at 09:57:20PM -0400, Bob Camp wrote:
>>>>>> People got a bit ???excited??? about the level of KS box discussions.
>> All of the work decoding
>>>>>> the 15 pin connector and how to drive the REF-0 was taken off list.
>>>>>> Simple answer:
>>>>>> Yes you can run a REF-0 by it???s self. It needs a dummy string that
>> looks like the output
>>>>>> of a Motorola Oncore to feed it and some fairly simple manipulation
>> of the signal lines.
>>>>>> It will then quite happily discipline to the pps you feed it.
>>>>>>> On Aug 6, 2015, at 7:27 PM, Edesio Costa e Silva <
>> time-nuts at tardis.net.br> wrote:
>>>>>>> Hello Fellows!
>>>>>>> Had anyone managed to run the KS-24361 REF-0, the one without GPS,
>> as a
>>>>>>> standalone unit? If so, can you provide some links on how to
>> configure it?
>>>>>>> The reason to try this is cost. The REF-0 unit costs USD 25 + USD
>>>>>>> (shipping to Brazil) and I have to pay the same amount as custom
>>>>>>> Right now the REF-0/REF-1 pair would be too expensive.
>>>>>>> time-nuts mailing list -- time-nuts at febo.com
>>>>>>> To unsubscribe, go to
>>>>>>> and follow the instructions there.
>>>> time-nuts mailing list -- time-nuts at febo.com
>>>> To unsubscribe, go to
>>>> and follow the instructions there.
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to
>>> and follow the instructions there.
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> and follow the instructions there.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts