GPS in Ref-1: Motorola UT+ Oncore GPS Timing Receiver p/n R5122U1152
Images from AECI South.
Z3810AS Z3811AS (REF 1) Z3812AS (REF 0)
Front panel indicators (when illuminated).
NO GPS -- No valid GPS (solid) or Antenna Issue (blinking) FAULT -- System Fault STBY -- Module is in Standby ON -- Module is Ready
After 24 hours 5335A reports mean frequency: 14,999,999.9966 Hz
Serial comms to the diag port are unreliable using RS-232. Some working SCPI commands:
*CLS *IDN? :DIAG:GPS:UTC 0|1 (0 GPS, changing time scale happens after reboot e.g. :syst:pon) :DIAG:GPS:UTC? (Reports new value immediately on change) :DIAG:IDEN:GPS? :DIAG:LIFEtime:COUNt? :DIAG:LOG:READ:ALL? :DIAG:ROSC:EFC? :DIAG:ROSC:EFC:ABS? :DIAG:ROSC:EFC:REL? :GPSystem:POSition:SURVey:STATe:POWerup 0|1 (survey on reset 1=yes) :GPSystem:POSition:SURVey:STATe:POWerup? :PTIMe:GPSystem:ADELay NN (REF 1 only) :PTIMe:GPSystem:EMANgle NN (REF 1 only) :PTIMe:GPSystem:INITial:POSition N,nn,nn,nn.nn,W,nn,nn,nn.nn,nn.nn :PTIMe:GPSystem:POSition N,nn,nn,nn.nn,W,nn,nn,nn.nn,nn.nn :PTIMe:GPSystem:POSition:HOLD:LAST? :PTIMe:GPSystem:POSition:SURVey:PROGress? (REF 1 only) :PTIMe:GPSystem:POSition:SURVey:STATe ONCE (REF 1 only) :PTIMe:GPSystem:SATellite:TRACKing:COUNt? :PTIMe:GPSystem:SATellite:TRACKing? :PTIMe:LEAP:ACC? :PTIMe:LEAP:DATE? :PTIMe:LEAP:DUR? :PTIMe:LEAP:STATe? :PTIMe:TINTerval? :PTIMe:TCODe:CONTinuous 0|1 :PTIMe:TCODe:FORMat F1|F2 :PTIMe:TCODe:FORMat? :PTIMe:TCODe? :ROSCillator:HOLDover:DURation? :ROSCillator:STATe? :SYSTem:COMMunicate:SERial1? :SYSTem:COMMunicate:SERIAL1:BAUD 9600 | 19200 :SYSTem:COMMunicate:SERial1:BITS 7 | 8 :SYSTem:COMMunicate:SERIAL1:PACE XON | NONE :SYSTem:COMMunicate:SERIAL1:PARarity EVEN | ODD | NONE :SYSTem:COMMunicate:SERIAL1:SBIT 1 | 2 :SYSTem:LANGuage "PFORTH" (halt to exit pForth) :SYSTem:PON (reset the unit as opposed to the normal use of this command) :SYSTem:STATus?some pForth words (via words)
halt abr_stat duart_debug gps_query_all pr_pll adc_read efc_rep gps_time pr_time_raim avg efc_wr init_gps print_bc clear_nv efc_write leapsec print_clk_list clk_synch eman lock print_ext_msg clr_avg es_ascii log_send print_l1 clr_gps_debug ext_msg_rate loop_time print_stat crash force_15_fail master_reset print_vis debug_psos force_15_pass pll_debug pstat disable_gps_cmds force_1pps_fail pll_rep q_eman dmes_all force_ext_1pps pll_restart q_gps_cable_dly dmes_curv force_gps_1pps pr_1pps q_gps_php dmes_gpsm fp_u pr_adc_avg quiet_status dmes_hmon get_time pr_avg s_rep dmes_klok gps_cable_dly pr_efc set_time dmes_pllp gps_change pr_gps_cmds stat_rate dmes_root gps_date pr_gps_debug sync_imm dmes_scpi gps_ph pr_gps_id vis_stat_rate dmes_spoo gps_php pr_gps_istate wr_eeprom dmessage gps_query pr_hold_cause xdop_stat_rate
Example log:
Log 001:19990521.00:00:00: Log cleared Log 002:19990521.00:00:00: System preset Log 003:19990521.00:00:07: Power settings ok, Int: 17 dBm, Ext: 17 dBm Log 004:19990521.00:00:00: Power on Log 005:19990521.00:00:00: Power on Log 006:19990521.00:00:39: Power settings ok, Int: 17 dBm, Ext: 17 dBm Log 007:19990521.00:00:00: Power on Log 008:19990521.00:00:27: Power settings ok, Int: 17 dBm, Ext: 17 dBm Log 009:19990521.00:19:58: GPS reference valid at 20141126.04:20:32 Log 010:20141126.04:22:36: Locked mode entered Log 011:20141126.18:22:35: Ready for 4 hour flywheel Log 012:20141127.00:22:35: Ready for 8 hour flywheel Log 013:20141127.00:00:00: Power on Log 014:20141127.00:00:26: Power settings ok, Int: 17 dBm, Ext: 17 dBm Log 015:20141127.00:04:08: GPS reference valid at 20141127.16:12:04 Log 016:20141127.16:13:10: Locked mode entered Log 017:20141128.06:13:09: Ready for 4 hour flywheel Log 018:20141128.12:13:09: Ready for 8 hour flywheel Log 019:20141128.00:00:00: Power on Log 020:20141128.00:00:26: Power settings ok, Int: 17 dBm, Ext: 17 dBm Log 021:20141128.00:52:21: Position hold mode started Log 022:20141128.01:28:32: GPS reference valid at 20141128.20:34:00 Log 023:20141128.20:35:04: Locked mode entered Log 024:20141129.10:35:03: Ready for 4 hour flywheel Log 025:20141129.16:35:03: Ready for 8 hour flywheel
Example status (GPS timescale):
--------------------------- Primary Receiver Status ---------------------------
SYNCHRONIZATION ............................................. [ Outputs Valid ]
SmartClock Mode ___________________________ Reference Outputs _______________
>> Locked to GPS TFOM 3 FFOM 0
Recovery 1PPS TI -10.0 ns relative to GPS
Holdover HOLD THR 1.000 us
Power-up Holdover Uncertainty ____________
Predict 3.0 us/initial 24 hrs
ACQUISITION ................................................ [ GPS 1PPS Valid ]
Tracking: 7 ____ Not Tracking: 3 ________ Time ____________________________
PRN El Az C/N PRN El Az GPS 16:44:00 29 Nov 2014
2 59 79 36 9 11 36 GPS 1PPS Synchronized to GPS Time
5 86 243 35 12 13 216 ANT DLY 60 ns
6 18 94 35 *26 Acq .. Position ________________________
10 33 53 39 MODE Hold
13 41 111 41
25 23 255 32 LAT N 43:41:06.950
29 41 308 41 LON W 78:29:23.789
HGT +103.01 m (GPS)
ELEV MASK 10 deg *attempting to track
HEALTH MONITOR ......................................................... [ OK ]
Self Test: OK Int Pwr: OK Oven Pwr: OK OCXO: OK EFC: OK GPS Rcv: OK
UTC timescale (REF 0):
--------------------------- Primary Receiver Status ---------------------------
SYNCHRONIZATION ............................................. [ Outputs Valid ]
SmartClock Mode ___________________________ Reference Outputs _______________
>> Locked to GPS TFOM 3 FFOM 0
Recovery 1PPS TI +0 ps relative to GPS
Holdover HOLD THR 1.000 us
Power-up Holdover Uncertainty ____________
Predict 2.1 us/initial 24 hrs
ACQUISITION ................................................ [ GPS 1PPS Valid ]
Tracking: 7 ____ Not Tracking: 2 ________ Time ____________________________
PRN El Az C/N PRN El Az UTC 21:46:34 21 Dec 2014
4 23 307 40 11 10 313 GPS 1PPS Synchronized to UTC
12 26 92 43 *31 Acq .. ANT DLY 50 ns
14 62 290 42 Position ________________________
18 52 135 33 MODE Hold
22 84 260 39
24 34 50 40 LAT N 43:41:06.950
25 21 133 36 LON W 78:29:23.789
HGT +103.01 m (GPS)
ELEV MASK 10 deg *attempting to track
HEALTH MONITOR ......................................................... [ OK ]
Self Test: OK Int Pwr: OK Oven Pwr: OK OCXO: OK EFC: OK GPS Rcv: OK
Slightly edited text orginally from person credited.
One of the GPSDOs I've had running for some time is an HP Z3811 with a a 1998 date code and a MTI 260 OXCO. Before you say I'm crazy, Z3811 is what the labels on the chips say. The name on the outside of the unit is Lucent RFTG-u REF1. Another similar Lucent unit had a clone of the 260, same size and pin out, but I have no idea if the specs are close, and that OXCO was an OFC MC895X4-015W with a 1999 date code. Both these OXCOs are 5.000000Mhz.
Like most Lucent units the RFTG-u REF1 was made to run with another back-up unit for redundancy, needed an interconnect cable, and has no information available. I managed to figure out a way to make it work as a standalone unit and ran the 5Mhz from the OXCO thru a QBits amplifer to give me 5Mhz output instead of the Lucent standard of 15Mhz. I haven't carefully checked it against the other GPSDOs I have running but with the modifications I made to allow it to work solo, it seems to be a pretty good plug-and-play unit.
This (long) post is a review of the HP/Symmetricom Z3810A (or Z3810AS) GPSDO system built for Lucent circa 2000. I wrote it because I looked for more information before I bought one, and couldn't find much. It's relevant because (as of this writing), you can buy a full system on the usual auction site for about $150 plus shipping. For those of you lamenting the dearth of cheap Thunderbolts, this looks like one of the best deals going. The description of these objects does not include "GPSDO", so time-nuts may have missed it. Search for one of the part numbers in the subject line and you should find it.
So what is it? It's a dual GPSDO built by HP as a reference (Redundant Frequency and Time Generator, or RFTG) for a Lucent cell-phone base station, built to Lucent's spec KS-24361. Internally, it's a close cousin of a later-model Z3805A. Externally, it looks to be almost a drop-in replacement for the earlier RFTG system built to Lucent's spec KS-24019. That was a redundant system containing one rubidium (LPRO, in the one I have) and one OCXO in two almost-identical boxes. That spec went through several revisions with slightly different nameplates and presumably slightly different internals. You can generally find one or two examples on the auction site (search for RFTG or KS-24019).
This system is similar, but the two boxes each contain a Milliren (MTI) 260-0624-C 5.000MHz DOCXO, and neither contains a rubidium. The Milliren DOXCO is the same one used in the later models of the HP Z3805A / 58503A. It's a very high-performance DOCXO, in the same class as the legendary HP 10811, and better than the one in most surplus Thunderbolts. The 5 MHz output is multiplied up to 10 MHz in at least one unit, and 15 MHz in both units. I don't have the ability to measure phase noise on these outputs, but I'd be interested to see the results if someone could.
Nomenclature: The Z3810AS (there always seems to be an "S" at the end) is a system consisting of the Z3811A (the unit containing a GPS receiver), the Z3812A (the unit with no GPS receiver), and the Z3809A (a stupid little interconnect cable). The GPS receiver inside the Z3811A is a Motorola device, presumably some version of an OnCore. Where the Z3811A has a TNC GPS antenna input, the Z3812A has an SMA connector labeled "10MHz TP". That is indeed a 10 MHz output. It comes active as soon as power is applied to the unit, and its frequency follows the warmup curve of the OCXO. The two units have identical PCBs (stuffed slightly differently), and I have no doubt that someone can figure out how to add a 10 MHz output to the Z3811A as well.
Operation: From the outside, these units are broadly similar to earlier units in the Lucent RFTG series. The (extremely valuable) website run by Didier, KO4BB, has a lot of information on those earlier units, much of which still applies here. The purpose of these units was to provide a reliable source of frequency and timing information to the cell-site electronics. The 15 MHz outputs from both units were connected to a power combiner/splitter and directed to various parts of the transmitter. The units negotiate with each other so that only one 15 MHz output is active at a time. The outputs labeled "RS422/1PPS" contained a 4800 baud (?) serial time code as well as the PPS signal, which were sent to the control computer.
Power is applied to the connector labeled "+24VDC" and "P1", in exactly the same way as the earlier RFTG units. Apply +24V to pin 1 and the other side of the power supply (GND or RTN) to pin 2. In these units, that power supply goes directly to an isolated Lucent DC/DC converter brick labeled "IN: DC 18-36, 1.9A". Presumably you can run both units with a 4-amp supply.
Once you have applied power, connect the Z3809A cable between the jacks labeled "INTERFACE J5" on each unit. The earlier RFTG units used a special cable between two DE-9 connectors, and it mattered which end of the cable connected to which unit. The interconnect for these units is a high-density DE-15 connector (like a VGA plug). The Z3809A cable is so short that the two units need to be stacked one above the other, or the cable won't reach. It doesn't seem to matter which end of the cable goes to which unit. I don't know whether it's a straight-through cable, or whether you could use a VGA cable as a substitute.
When you apply power, all the LEDs on the front panel will flash. The "NO GPS" light will continue flashing until you connect a GPS antenna. Once it sees a satellite, the light will stop flashing and remain on. The unit will conduct a self-survey for several hours. Eventually, if all is well, the Z3812A ("REF 0" on its front panel) will show one green "ON" light and the Z3811A ("REF 1") will show one yellow "STBY" light. This means that the Z3812A is actually transmitting its 15MHz output, and the other one is silently waiting to take over if it fails.
Most time-nuts want to see more than a pretty green light. The old RFTG series allowed you to hook up a PC to the "RS422/PPS" port and peek under the hood with a diagnostic program. The program is available on the KO4BB website. It is written for an old version of Windows, and I had no luck getting it to run under Windows 7. It does run under WINE (the Windows emulator for Linux) on Ubuntu 12.04 LTS. To use it, you need to make an adapter cable to connect the oddball RS-422 pinout to a conventional PC RS-232 pinout. The adapter cable looks like this:
RFTG PC DE-9P DE-9S 7 <----------> 5 8 <----------> 3 9 <----------> 2
(According to the official specs, this is cheating, because you're connecting the negative side of the differential RS-422 signals to the RS-232, and ignoring the positive side of the differential signals. However, it's a standard hack, and it's worked every time I've tried it.)
With that adapter, you can see the periodic timetag reports from the unit. The RFTG program will interpret these timetags when it starts up in "normal mode". However, when I try to use any of the diagnostic features built into the program, it crashes WINE. The timetag output was required for compatibility, but I suspect that HP didn't bother to implement the Lucent diagnostics.
Instead, they added a connector which is not on the previous RFTG series. That connector is labeled, logically enough, "J8-DIAGNOSTIC". It too is wired with RS-422, so you need to use the same adapter cable as before. Once you do, you'll find that this connector speaks the usual HP SCPI command set (Hooray!). I used the official SATSTAT program (again under WINE on 12.04 LTS), but I'm sure that other programs written for this command set will work as well. The default SATSTAT serial port settings of 9600-8-N-1 worked for me.
After about 24 hours, with a poorly-sited indoor GPS antenna, my system has converged to TFOM=3, FFOM=0 (the best possible numbers), and a "predicted 24-hour holdover uncertainty" of 5.2 microseconds, which is not too shabby. It found the correct day and year without any assistance, so if it has a "GPS week number rollover" problem, it's still in the future. I don't currently have the ability to compare the 10 MHz output to anything else. Again, if someone else can, I'd be interested to see the results.
Additional Notes: The parts on the boards all have date codes of 1998 or 1999. The Motorola GPS receiver has a firmware label that reads "02/04/00". The SCPI error logs inside the HP units were virgin when I first got them. They had 84 and 94 power cycles, respectively. Before the GPS receiver acquired time, the error log timestamps read "2000-05-09 00:00:00", which I interpret as a firmware release date.
The PCB has an interesting feature. Next to each soldered-in pin of the Milliren OCXO is a single-pin socket soldered into the board. I'm guessing this was used in manufacturing, to temporarily install a Milliren and confirm that the system worked before permanently soldering it in. (At production prices, the Milliren would have cost far more than the rest of the PCB.) You might be able to use this in reverse, if you have a set of Millirens to test from another source.
The Z3809A interconnect cable has three of the 15 pins on each end clipped a bit shorter than the rest. Not so short that they won't eventually make contact, but short enough to make contact later than the rest. Don't know why, but it's clearly deliberate. A lot of hot-plug connectors are built that way, including USB connectors. I have no idea what the pinout of the interconnect is.
The redundant system slaves both DOCXOs to the same GPS reference. Inside the GPS loop bandwidth, the two oscillators will have almost the same frequency and will differ only by phase noise and short-term stability. This is almost a perfect setup for experimenting with certain kinds of time-nut measurements, assuming someone can figure out how to get 10MHz out of the Z3811A unit. If you then command both units into holdover, you could measure longer-term stability as well.
The units are described as "new in factory sealed box". After an archeological investigation of the various strata of labels and tape on the boxes, I would say that's probably accurate. My set seems to have been shipped from the Agilent factory in Korea to Symmetricom in Sunnyvale, CA sometime in August, 2000, shortly after it was built, and remained untouched until I opened it. I'm guessing it was built and saved as part of a spares program for Lucent, and kept until Lucent decided they didn't need spares any more.
I have no connection with the current seller of these units (or any other sellers, for that matter) except as a satisfied customer. I think I'll order another set as a spare, before the feeding frenzy hits.
Standard numbering on all connectors. The P connector is numbered "backwards" from the J connectors as viewed from the front of the unit. If that does not make sense, check a DB-9-M and DB-9-F diagram. The numbers are on the parts in *really* small print if you really want to go crazy.
P1 - Power 1 2 3 4 5 6 7 8 9 pin 1 + supply into the unit pin 2 supply return out of the unit all other pins - no connect
Supply is 18 to 36V. After warmup the pair of units pull about 1A at 28V. At turn on they pull more than 2A. The supply inputs are fully floating at DC relative to the chassis.
J5 - Interface 5 4 3 2 1 A 9 8 7 6 F E D C B
J8 - Diagnostics 5 4 3 2 1 9 8 7 6 Pins 3 and 7 ground Pin 4 RX+ Pin 8 RX- Pin 5 TX+ Pin 9 TX- all others no connect [Editorial note interpolated] So using an icusb422: Lucent ICUSB 8 1 4 2 5 3 9 4 3 5 [End note]
J6 - PPS Pins 3 and 7 ground Pin 4 RX+ Pin 8 RX- Pin 5 TX+ Pin 9 TX- Pin 1 PPS+ Pin 6 PPS - all others no connect
J3 - Alarm(on 29-Dec-2014)
All signals for RX and TX are RS-422. Data on J8 is at 9600 baud 8N1. RX is into the box, TX is out of the box.
[F1] Data format on the PPS connector looks like the older RFTG's:
byte use values 1 talker 0 = ref 0, 1 = ref 1 2 status 0 = active, 1 = inactive 4 mode 0 = warmup, 1 = gps, 2 = holdover, 3 = fault 9,10 time hours in this mode 11 to 18 GPS time seconds since GPS start in 1980 19 to 22 Firmware Rom version 23,23 checksum [e.g. : 0 0 x 1 xxxx 1A 41A38192 A301 B6]The string starts with a : All the bytes not listed above read as zero
I have now tested 3 pairs of these units (full Z3810AS system), always in pairs. One Z3811 box was DOA. It drew power at the appropriate level, but the lights did not light up and there was no response on the SatStat port. AECI quickly swapped it for a working unit, and even paid return shipping for the dud. Can't complain about the service. One pair was built in the US in approximately March 1999; it has serial numbers in the old HP style: 3844A41xxx. The others were built later, in Korea, and have new-style serial numbers like KR92840xxx. They all seem to have the same software.
My lab uses a dual USB-to-serial converter to talk to both boxes at once. This does not use FTDI chips. One side seems to talk perfectly both ways through the RS-422 hack wiring; the other side seems to receive perfectly but the GPSDO complains about erroneous commands about once or twice an hour. If anyone wants to duplicate my setup, the converter comes from "Microconnectors" and can be found here:
MicroConnectors Serial Adapter
(Link provided for information only; I have no connection with any of these people.)
It is NOT TRUE that only the box with the green light on will talk over its diagnostic port. Both boxes can be interrogated simultaneously with SatStat, starting immediately after power-up. The J8 diagnostic ports on both units "speak only when spoken to". If you're using a scope to look for activity on the diagnostic port, you won't see any unless a PC is connected. If you're switching one serial cable back and forth between two boxes, be sure to close the port (menu CommPort/PortOpen unchecked) before removing the cable from the first box, and open the port again (menu CommPort/PortOpen checked) after connecting the cable to the second box. The PortOpen command seems to do more than merely opening the serial port; it seems to be necessary to get communications going with the box. If you watch the window title, you can see that it's sending a *IDN? command and interpreting the results, but it may be doing other things as well.
On the Z3812A, the front panel "10 MHz test point" J1 connects to a group of three 100-ohm SMT (0805?) resistors and one SMT (0805 again?) ceramic capacitor. These are next to U206, a 74ACT14 in a SO-14 package, on the bottom of the board behind J6. On the Z3811A, these three resistors and one capacitor are missing. It is quite probable that adding them would send a 10 MHz signal to the SMA jack footprint buried under the GPS antenna input TNC jack. One could presumably solder a small coax cable to that footprint and route it around to a convenient location on the front panel. (The capacitor is not marked with a value, but it's probably small. It connects from the 10 MHz output to ground, and its purpose is probably just to slow down the edge rates of the 10 MHz output to reduce EMI.)
The 10 MHz output seems to have a duty cycle of about 55% high / 45% low. This may be related to the synthesis technique, or it may simply be due to asymmetrical thresholds in the 74ACT14 schmitt-trigger driver.
The firmware in the Z3811 and Z3812 boxes appears to be exactly the same. The PCBs are stuffed slightly differently, and of course the Z3812 has no GPS receiver. It is possible that one could add a GPS receiver speaking the correct protocol to a Z3812, and turn it into a GPSDO. It would be necessary to find out how the firmware detects what sort of box it is. Perhaps it simply looks for a GPS receiver, or perhaps there is a pullup resistor somewhere on the board that is only stuffed on one version of the box.
The GPS receivers in these boxes use fairly old technology. In particular, they can only track 8 channels at a time, and they cannot make use of the WAAS signals. WAAS transmits corrections for satellite ephemeris errors and for the changing ionosphere. These are two of the most prominent error sources for GPS timing. (The others are antenna position error and multipath, both of which are potentially under the control of the user, and troposphere delay, which is small but can't easily be measured or removed.) It is theoretically possible to build a plug-compatible board carrying a modern GPS timing receiver and a small microcontroller to translate its communications into Motorola Oncore language. With a well-sited antenna, such a system might display noticeably improved performance.
The current GPS receivers in these boxes take a remarkably long time to settle down after power-up. The GPS satellites transmit their full almanac every 12.5 minutes, which is normally all the time required for a GPS receiver to become completely happy. These receivers seem to require over an hour to become happy enough to START their self-survey, and several more hours to complete it. The old rubidium RFTG units could take 24 hours or more to become fully operational; these units seem to take 4 to 12 hours, depending on GPS antenna quality and siting.
The [interface] cable is actually wired pin 1 to pin 15, pin 2 to pin 14, etc. Another way to describe it is that for each wire in the cable, the pin numbers on each end of the cable add up to 16.
A mated pair of these units is running in my lab with a scratch-built interconnect cable following the above rules. This scratch-built cable allowed access to the interconnect signals while the system was operating happily. No lights were lit except the green ON light on the Ref-0 unit (Z3812A, no GPS) and the yellow STBY light on the Ref-1 unit (Z3911A with GPS receiver). The following signals were observed on the interconnect (pin numbers given for the J5 interconnect socket on the Ref-1 unit):
Pin 1: 9600 baud serial data (described below) Pin 2: logic low (0.11V) Pin 3: Ground (0.00V) Presence detect? (see below) Pin 4: logic high (4.79V) Pin 5: inverted Motorola PPS, high (5V) for 800ms, low for 200ms Pin 6: "17 / 23 dBm" signal from Ref-0 unit (see below) Pin 7: logic high (4.48V) Pin 8: Ground (0.00V) Pin 9: logic low (0.11V) Pin A: "17 / 23 dBm" signal from Ref-1 unit (see below) Pin B: inverted PPS, low 400us, high (5V) otherwise Pin C: logic low (0.12V) Pin D: Ground (0.00V) Pin E: logic low (0.08V) Pin F: logic high (4.78V) 5 4 3 2 1 A 9 8 7 6 F E D C B
Pins 3, 8, and [D] appear to be firmly connected to Ground. (Note that these are the three pins which are clipped short on the HP interconnect cable.) On an unpowered, disconnected box (either Ref-0 or Ref-1), pins 8 and [D] are connected to Ground (low resistance) and pin 3 is high impedance. Presumably pin 3 on each box (connected to the grounded pin [D] on the other box) is used to sense the presence of the other box and/or the interconnect cable.
The timing of the PPS signal on pin [B] matches precisely the timing of the PPS signal available on pins 1 and 6 of J6 (RS422/PPS) on the active Ref-0 unit. Presumably this signal is coming across the cable from the Ref-0 unit.
Note: when the system is coming up from a cold start, SatStat on the unit with the GPS receiver (Ref-1) will show "[Ext 1PPS valid]" in the space where it shows "[GPS 1PPS valid]" after the survey is complete. It appears that the Ref-1 unit timing system is locking its oscillator to the PPS coming from the Ref-0 unit during this time.
The timing of the PPS signal on pin 5 matches the timing of the PPS output described in the Motorola OnCore manual. Presumably this signal is sourced by the Ref-1 unit to allow the Ref-0 unit to lock to GPS. The edges of this PPS signal look very dirty compared to the signal on pin [B]. This may be an artifact of the homemade cable used for this experiment. The HP cable clearly has an overall shield (visible through the cable sheath) and may have internal coax or twisted pair for these PPS signals.
When pin 5 and pin [B] are observed together, the usual GPS sawtooth pattern is evident.
Someone discovered earlier that ... both units will blink their green ON lights if the front-panel switch on either unit is set to 23 dBm [versus] the normal 17. Obviously each unit can communicate its switch status to the other unit. They use pins 6 and [A] to do that. Pin [A] (on the Ref-1 unit) is high (~5V) if the switch on the Ref-1 unit is in the 17 dBm position, and low in the 23 dBm position. Pin 6 (on the Ref-1 unit) gives the same indications for the switch on the Ref-0 unit.
The serial data on pin 1 is transmitted at 9600 baud, with a burst of data every second. The signal idles at logic low (near 0V) and rises to logic high (near 5V) during the burst. This may be the standard for TTL (not RS-232) transmission of serial data, or it may be inverted. The first few characters of one burst were hand-decoded from a scope trace as 0x40, 0x40, 0x45, 0x61, 0x0B, or ASCII "@@Ea". This appears to be the Motorola Oncore binary data format, although "Ea" does not appear to be a valid Motorola command or response. Perhaps the hand-decoding was in error.
One can use SatStat, talking to the Ref-0 (non-GPS) box, to issue queries and commands to the GPS receiver. The results are inconsistent, but it seems that at least some of the queries get through and trigger responses. If the Ref-0 box is actually talking to the GPS receiver, it must be doing so through the interconnect cable. The specific wire in the cable used for this (if any) has not yet been identified.
The serial com coming out of the GPS has several standard Motorola headers in it:
@@Ea normal position message @@En TRAIM / sawtooth status timing status message @@Bb Visible satellites message @@Bo UTC offset message
The first two make sense for a GPSDO. The third is probably for the :SYSTEM:STATUS? display. The last one makes very little sense for a CDMA basestation GPSDO.
Pin 1 is an open drain output. The pull up is supplied by pin 15.
Pin 2 is part of the negotiation process. It goes high and low as the boxes sort out who is who. It appears to be some sort of open drain with pull up arrangement. Pulling pin 2 low briefly will take the GPS unit out of standby status in a single box configuration if pin 3 is grounded.
Pin 4 is also part of the chat process. It is not an open drain with pull up. It appears to be a legit CMOS output, possibly with a series resistor.
Pin 5 is an open drain output. The pull up is supplied on pin 11.
[Pin 11] is driven by pin 5 on the other end of the cable. It looks like a CMOS input with a pull up.
Pin 12 is part of a wired OR / open drain / pull up combination. It gets used to work out which box is doing what.
Pin 14 may also be part of the who is doing what back and forth between the boxes.
read this on: http://www.realhamradio.com/gps-satstat-software.htm
When you first turn on the Z3816A GPS receiver, it is always continuously sending time. There are two commands you need to use: one to put it into the SCPI> command mode, the other to switch it back to sending time. The two commands are:
To go to the SCPI mode: ptim:tcod:cont 0
To go to the continuous time mode: ptim:tcod:cont 1
this holds true also on the J6 (RS422/1PPS) connector of the Lucent KS-24361 Z3811 and maybe Z3812 ( watchout there is no !! echo if you are using a terminal software but Z3811.exe works fine).
Yes, one of the great unanswered questions about the KS boxes is how to quickly and easily switch them from a nice clean (useless) 15 MHz output to a nice clean (useful) 10 MHz. The circuit appears to be all discrete analog. That suggests that a jumper this, swap that approach might work.
I had Planned to eventually convert the 5 Mhz output I added from J8 on the Lucent RFTG-u REF1 (that I described previously) to 10 Mhz. Since I made that 5Mhz modification 4 years ago I have been using the 5 Mhz sinewave output for some of the equipment I have around the bench that can use it directly plus I have a modified Spectracom 8140 distribution amp that take a 5Mhz input and will output a clean 10Mhz sine wave.
The 5-10Mhz doubler circuit described by John Roos seems like a good way to accomplish what I wanted to do. I started looking around for parts I might already have that I could use to construct the circuit and I found a lot of what I needed. Having dismantled about 200 of the wireless locator units that held the Thunderbolts that I sold on Ebay, I had a large pile of the machined R.F. subassemblies left over and they had a large number of MCL (Micro-Circuits) and other really neat R.F. stuff. I found a MCL RMS-2 (5-1000 Mhz) mixer that would work well for the mixer and then found a 10Mhz 2-stage amp with filters on one of the circuit boards that should give me the clean 10Mhz sine wave that I want. I have tried the amp and it seems to work well. When fed with either a sine or a square wave the output is a clean sinewave that can drive 50 ohms. The power required is +/-7VDC at low current and that voltage goes to 2 on-board regulators to provide +/-5VDC that supply the 2 amps. Feeding the +/-15VDC from the REF 1 power supply through two 200 ohm resistors provides the +_7VDC for the amps' on-board regulators.
The inductors I need for John Roos's 90 degree phase shifter circuit should be here in a couple of days and then I can permanently mount the amp board right behind the front panel connectors near the middle of the REF 1. On the outside chance that the unit actually needs the 15MHZ signal for some purpose this added board will not affect that signal in any way. At least for me this is a good solution. Here is a link to a photo of 2 different revisions of the board, one with a discrete lowpass filter and one with the MCL SCLF-10.7 package. After stripping off the other stuff I don't need there is plenty of room for the rest of the parts from John Roos's circuit.
-Arthur
here is my example spectrum taken with a Rigol 815, due to inpatience only up to 100 MHz. This shows what is meant by "clean 15, dirty 10 MHz."
Have successfully tapped into the clean 10 MHz of the the Lucent and using a EL2020 50 Mhz current opamp have a very nice 10 Mhz sine wave out. Any spurs are down at least 43 db. Close in at 4Khz total span or 500 Hz/div I don't see anything down to at least 65 db. Thats the best detail the HP 8568B will allow.
To get the signal out of the Lucent I sliced the 15 Mhz trace and injected the 10 Mhz into the SMA output connector.
A signal with harmonics 20 db down and sub-harmonics 30 db down will make a fine reference input for a counter / signal generator / spectrum analyzer. A signal with a 1 second ADEV of 5x10^-10 will look absolutely perfect on any spectrum analyzer ever made. It will not be a good a reference for an instrument as a source at 5x10^-12. Close in phase noise / ADEV is what you need to set up to check. A relative test is fine ( divide 10 by 2 and compare to 5), but that's what you need to check
It might be of interest to some that it appears that the KS-boxes has an adjustable PLL time constant:
:SYST:LANG "PFORTH" >pll_rep start ptr = 0 stop_ptr = 0 max loop time = 700 ffom = 1 tfom = 1.0e-06 secs >1000 loop_time >pll_rep start ptr = 0 stop_ptr = 0 max loop time = 1000 ffom = 1 tfom = 1.0e-06 secsLooks like a teakable PLL parameter, but I don't have the measurements to back it up. Yet.
Also, there is a command to report on the L1-status, which might make life easier for those who try to get the boxes going separately by manipulating the J5-port:
On REF-0
>print_l1 mode: locked, duration: 1152 locked duration: 1153, learning exceeded: 0 ready: 1, critical failure: 0 shutdown failure: 0 GPS locked once: 1 GPS found once: 1 Flywheel capable state: 0, time: 3600 sec Other flywheel capable state: 2, time: 28800 sec flywheel ready mode: idle Other GPS locked once: 1 other on: 1, delayed other on: 1 Monitor enable active: 1, ready: 1, hold actref: 1 ext_1pps_dead: 1 ext 1pps valid: 0 gps_1pps_dead: 0 gps 1pps valid: 1 HW lines cable 1, active in: 0, ready in: 1 Ext locked in: 0, GPS Locked once in 1 ACTREF out: 1, PRI_ACT out: 1 Int power: 0, Ext power: 0on REF-1:
mode: locked, duration: 76342 locked duration: 76343, learning exceeded: 0 ready: 1, critical failure: 0 ...
Regarding: KS24361 Ulrich Z83XX software mod works
the latest version will do it for the Z3811 and Z3812 as well. Download here: http://www.romahn.info/lucent/z3811.exe
> over the Christmas season, I have designed and built a frequency > doubler from 5 to 10 MHz and a distribution amplifier for the Lucent > KS-24361. A preliminary writeup is under > > < http://www.hoffmann-hochfrequenz.de/downloads/DoubDist.pdf >I have updated the text with a phase noise measurement and some clarifications.
regards, Gerhard
Based on the phase noise on the 15 MHz output, I would *guess* that the 5 MHz OCXO has a floor in the vicinity of -160 dbc / Hz. That would be correct per the MTI spec sheet. It also would make sense based on your phase noise plots. Close in ( around 200 Hz) your multiplier and amp are doing a better job than the stock 15 MHz tripler and buffer.
Lucent KS-24361 mystery LED resolved
There are two LED's on the circuit board next to the power supply module.
One is green blinking. I'd never seen the other one on.
I needed to get them off of my bench power supply and onto a permanent
supply. I tried a 24V 3A supply. They must have been cheating a little on
the ratings. The voltage dropped down to about 16V when the oven heaters
fired up. I noticed that the mystery LED was lit. It's red. A good guess is
that it's a power fault indicator. The LED's are next to the black power
supply module. A picture is attached.
...
This is just a brief report, not a how-to.
I got a KS_24361 with a bad Lucent power module. Having nothing to lose I thought I'd see if it came apart. After unsoldering it from the motherboard, I found the usual potting compound. Fortunately, the compound was only loosely attached to the board in the brick and was easy to pick off. After that, I used a pair of needle-nose pliers to work the board out of the casing. In spite of the pic below, I first gently pried up on the corners, in succession, until the corners released. Then I worked my way toward the middle, until the board came out. Be aware that there are two small inductors on the top side of the board that have metal covers that will probably stay in the potting compound. Just leave them there. When you push it all back together the covers will go back on the inductors.
...
Here's a quick and dirty approach to getting a Z3812A, KS-24361 L101, RFTG-u, Ref-0 box
In August 2015, Dan Watson posted articles about running a stand-alone REF-0.
Standalone Operation of the Lucent KS-24361 REF-0 Unit
Example code Lucent KS-24361 REF-0 Standalone Operation
