Hi
It’s a good bet that the REF-1 is set up to allow a hot swap of the REF-0 unit. In a cell site, you would not want a working REF-1 to go down when you replaced a blown REF-0. You would *think* that the same logic applies to a REF-1 booting up initially. For what ever reason, it does not apply. No I did *not* write that firmware :) I also have never seen the original spec for these boxes. There may be a perfectly logical reason they boot that way. Why does this matter? Booting a REF-0 cold is likely a bit different than letting the REF-1 bring it up. The control lines likely need poking in a “ready goes low first” followed by the other lines later sort of order. It is indeed the once per 5 seconds stuff that I *suspect* are not needed except to fill in the information in the master display screen. The once a second message is very much needed for the unit to keep doing it’s thing. Actually that’s not exactly correct. The unit cruises along for a bit with no messages before it goes into holdover. I have never tried pushing things to figure out if that’s a useful “feature” or not. Bob > On Aug 8, 2015, at 7:07 AM, D W <watsondani...@gmail.com> wrote: > > Bob, thanks for the detailed notes. > > This morning I fired up a REF0/1 pair and let it lock normally. Then I > disconnected the magic interface cable. Strangely the REF1 doesn't seem to > care in the slightest that the cable is pulled, likely because it is in > standby. The REF0 certainly does care though and gives the expected lights. I > was then able to manually wire the necessary interface pins as described by > Bob, and I got it operating normally again. With that test done I'll now try > it from a cold startup. > > I also captured some serial strings from the REF1, looks like the required > messages go once a second with the full set of messages being transmitted > every five seconds. > > I plan to use an AVR as I have plenty on hand. Should be fairly easy. I think > I'll ignore the sawtooth correction for now and just null out the GPS data > for a true dummy burst. Hopefully the REF0 likes that. After that's working > I'll try to populate sawtooth correction from a ublox to potentially improve > performance. > > Thanks > > Dan > >> On Aug 7, 2015, at 9:48 PM, Bob Camp <kb...@n1k.org> wrote: >> >> Hi >> >> 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 >> 10K range. >> >> In normal operation (Ref 1 in charge) the pairs look like this at the Ref 1 >> end: >> >> Pair A: >> >> 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. >> >> Pair B: >> >> 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. >> >> Pair C: >> >> 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…. >> >> Bob >> >> >> >>> On Aug 7, 2015, at 2:06 PM, paul swed <paulsw...@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. >>> Paul >>> WB8TSL >>> >>>> On Fri, Aug 7, 2015 at 10:13 AM, Bob Camp <kb...@n1k.org> wrote: >>>> >>>> Hi >>>> >>>> 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. >>>> >>>> Bob >>>> >>>>> On Aug 7, 2015, at 5:24 AM, Graham <planoph...@aei.ca> wrote: >>>>> >>>>> Bob, >>>>> >>>>> 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: >>>>>> Hi >>>>>> >>>>>> 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. >>>>>> >>>>>> Bob >>>>>> >>>>>>> On Aug 6, 2015, at 10:02 PM, Edesio Costa e Silva < >>>> time-n...@tardis.net.br> wrote: >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> I have some Motorola Oncore available. >>>>>>> >>>>>>> Can you detail this "fairly simple manipulation of the signal lines"? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Edésio >>>>>>> >>>>>>>> On Thu, Aug 06, 2015 at 09:57:20PM -0400, Bob Camp wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> Bob >>>>>>>> >>>>>>>>> On Aug 6, 2015, at 7:27 PM, Edesio Costa e Silva < >>>> time-n...@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 >>>> 52.30 >>>>>>>>> (shipping to Brazil) and I have to pay the same amount as custom >>>> taxes. >>>>>>>>> >>>>>>>>> Right now the REF-0/REF-1 pair would be too expensive. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Edésio >>>>>>>>> _______________________________________________ >>>>>>>>> time-nuts mailing list -- time-nuts@febo.com >>>>>>>>> To unsubscribe, go to >>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>>>>>>> and follow the instructions there. >>>>>> _______________________________________________ >>>>>> time-nuts mailing list -- time-nuts@febo.com >>>>>> To unsubscribe, go to >>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>>>> and follow the instructions there. >>>>> >>>>> _______________________________________________ >>>>> time-nuts mailing list -- time-nuts@febo.com >>>>> To unsubscribe, go to >>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>>> and follow the instructions there. >>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts@febo.com >>>> To unsubscribe, go to >>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>> and follow the instructions there. >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@febo.com >>> To unsubscribe, go to >>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
