I need to figure out how the DB9 power connection locks in. I read somewhere that the little pins (instead of screws) are called "slidelock". Have to see if I can get a connector with those.
Why not just replace those with regular hardware ?
I'm assuming most of these posts are referring to the
LUCENT/SYMMETRICOM/HP Z3810AS, KS24361 L101 REF0 / L102 REF1, GPSDO TIMING SYSTEM
as shown. Maybe the thread name can reflect that?
Great stuff by the way...
(h) Run one unit only? There was discussion on that, but since I got these as spares, I haven't investigated. You should be able to find the info on time-nuts.
(i) Reaction to moving a unit? Anytime you move the antenna, you introduce some error into the system. The error can show up as more jitter in the output or as jumps when a satellite joins or leaves the list of tracked birds. Whether the error is significant will depend on your application. In general, when you move the antenna, you should rerun the position survey. I think there's a command for that, but I'm not sure.
(h) Run one unit only? There was discussion on that, but since I got these as spares, I haven't investigated. You should be able to find the info on time-nuts.
I found one person on time-nuts that described how this was done. It involved building a small circuit to toggle the values on inputs on J5 in response to certain outputs. His approach involved wiring into the signal on the Fault LED, so it wasn't an external-only solution.
Run one unit only? There was discussion on that, but since I got these as spares, I haven't investigated. You should be able to find the info on time-nuts.I found one person on time-nuts that described how this was done. It involved building a small circuit to toggle the values on inputs on J5 in response to certain outputs. His approach involved wiring into the signal on the Fault LED, so it wasn't an external-only solution.
As for a PCB for the 5MHz processing doubler and distribution amp, I could make some gerber files that would be compatible with OSHPark, Seeedstudio, elecrow, dirtypcbs, et. al. publically available in the near future if there is continued interest and I can get the CAD data on the particular parts involved in the publication.
(h) Run one unit only? There was discussion on that, but since I got these as spares, I haven't investigated. You should be able to find the info on time-nuts.
I found one person on time-nuts that described how this was done. It involved building a small circuit to toggle the values on inputs on J5 in response to certain outputs. His approach involved wiring into the signal on the Fault LED, so it wasn't an external-only solution.
I had vague memories that there was a 'version 2' of this mod so I did some digging. Take a look at:
http://www.febo.com/pipermail/time-nuts/2014-November/087793.html plus a half dozen or so messages after that.
Apparently you can just set up a jumper plug.
Somebody should set up a wiki for all the information on these boxes.
Ed
Run one unit only? There was discussion on that, but since I got these as spares, I haven't investigated. You should be able to find the info on time-nuts.I found one person on time-nuts that described how this was done. It involved building a small circuit to toggle the values on inputs on J5 in response to certain outputs. His approach involved wiring into the signal on the Fault LED, so it wasn't an external-only solution.
Or even better than that, read what is discussed here:
http://www.febo.com/pipermail/time-nuts/2014-November/087972.html
Which indicates that the GPS unit J5 Pin 2 requires a 470ohm pull down resistor to ground (pin 8 or pin 13) and pin 3 requires wiring directly to ground. As far as I'm aware the numbering is right to left looking at the unit front on. Please double check this yourself.
...all that's needed to enable a Ref-1 unit stand alone is to link together J5 pins 2, 10, 12, and 15, and to ground pin 3 to pin 8, and then just hang around for hours and hours on end with yer fingers crossed:-)
As for a PCB for the 5MHz processing doubler and distribution amp, I could make some gerber files that would be compatible with OSHPark, Seeedstudio, elecrow, dirtypcbs, et. al. publically available in the near future if there is continued interest and I can get the CAD data on the particular parts involved in the publication.
I would like to see a 10Mhz out for the Z3811A or a cleaner 10MHz signal for the Z3812A, I have 16 port distribution amp already so I'm a little against the need for adding a large distribution modification to the Z3811A.
As there is so far a rear power supply mod, standalone Z3811A mod, Z3811A GPS backup battery mod, I think a single 10Mhz output (with 1pps if required) on the rear of the Z3811A seems the best idea.
Drilling multiple holes in the face seems to be over engineering it and butchering what could otherwise be a very discrete modification.
If someone comes out with a minimalist approach I'm interested in adding the PCB and modding mine.
I would like to see a 10Mhz out for the Z3811A or a cleaner 10MHz signal for the Z3812A, I have 16 port distribution amp already so I'm a little against the need for adding a large distribution modification to the Z3811A.
As there is so far a rear power supply mod, standalone Z3811A mod, Z3811A GPS backup battery mod, I think a single 10Mhz output (with 1pps if required) on the rear of the Z3811A seems the best idea.
Drilling multiple holes in the face seems to be over engineering it and butchering what could otherwise be a very discrete modification.
If someone comes out with a minimalist approach I'm interested in adding the PCB and modding mine.
I think you make a good point. How about just modding it so the 15 MHz SMA connector becomes a 10 MHz output?
I would like to see a 10Mhz out for the Z3811A or a cleaner 10MHz signal for the Z3812A, I have 16 port distribution amp already so I'm a little against the need for adding a large distribution modification to the Z3811A.
As there is so far a rear power supply mod, standalone Z3811A mod, Z3811A GPS backup battery mod, I think a single 10Mhz output (with 1pps if required) on the rear of the Z3811A seems the best idea.
Drilling multiple holes in the face seems to be over engineering it and butchering what could otherwise be a very discrete modification.
If someone comes out with a minimalist approach I'm interested in adding the PCB and modding mine.
I think you make a good point. How about just modding it so the 15 MHz SMA connector becomes a 10 MHz output?
All depends how much modification it requires, am still reading through the time-nut posts.
I prefer everything out the back and mount just the GPS unit in an enclosure rather than a rack.
I wanted to see how close the Lucent RFTG unit is compared to Nortel Trimble NTBW50AA Thunderbird unit. Both units using the same antenna over a 3 hour time period. Triggering on Ch 1 (Lucent) yellow trace and Ch 2 is the 10 Mhz TP output from the RFTG unit with the scopes persistence set to infinity.
Forgive the crappy pic, am tiered and cant see straight lol
I haven't looked at the details fully but that photograph looks like there was quite a lot of phase variation relative to the entire 10MHz cycle, which surprised me. I would have expected the jitter to be visible only on one zoomed in edge of the waveforms and to account for a small fraction of a cycle's phase over a relatively short (hour) interval with there being a bit of phase noise with an underlying phase drift progression due to the frequency discord.
I also wonder about whether the clock outputs wouldn't get cleaner wrt. jitter during GPS LOS periods since there is no further input for the corrections. Of course I suspect the devices create a mathematical model of a given OCXO's 'inherent' frequency error and temperature sensitivity and may try to keep correcting for the predicted error according to the trained model data (and perhaps also temperature measurement though probably not if it is assumed to simply be stable in the oven's feedback). But eventually I suppose the 'remembered' feedback due to the frequency error modem might 'age out' and then one would be left with basically the OCXO's intrinsic output given the temperature / power supply / noise related fluctuations.
Or I suppose if you cold started a unit and could get it to output the 15MHz or 10MHz or whatever without having the GPS related corrections enabled due to insufficient data to model the OCXO error at which point you'd be left with less control system jitter, though it may simply not output the high frequency at such a time. I recall seeing something about a fault described in the RFTG's SW report descriptions as 'flywheel failed, duration > 8 hr' so I wasn't sure what it'd do wrt. HF output after 8hr or 24hr in flywheel.
I suppose it might also be possible to trick the non-GPS RFTG unit into giving 'pure' OCXO output by doing something like feeding its own 15MHz output divided by 15M back into its PPS reference input as if that was coming from the GPS disciplining unit, I suppose one might need to do some phase adjustment to get it to accept that there was a 0 static phase error in that process.
Interesting. That is quite a lot of jitter for some of the units (40-90ns). Particularly out of a 100ns period 10MHz cycle anything more than 1ns of jitter is relatively speaking a lot (3.6 degrees / ns @ 10MHz).
BTW I looked at the data from KO4BB's site but I still haven't seen anything like an output specification for the 15MHz or PPS signals, is there a published value for what the frequency accuracy and jitter and such are supposed to be when the unit is operating normally?
As I understand it the PPS signals for timing oriented equipment are actually supposed to be synchronous with the transition of the GPS referenced second's transition time, generally down to nanoseconds levels of precision. I'm not sure that the RFTG units are oriented toward "timekeeping" so much as an accurate long term stable frequency reference at 1Hz and 15MHz though I suppose they probably also keep the clock edge of the PPS relatively aligned to the actual transition of the second though it sounds like that is only to the level of ~40ns to ~90ns which really sounds like it is about a half cycle of the 5MHz crystal clock.
Though it is odd if it can flywheel for 24hrs with microseconds of drift accuracy and still get large fractions (90ns) of that as short term corrections.
I have uncovered a couple of interesting data points on my Lucent unit.
1) I noticed that the PPS fluctuations seemed to increase every time the A/C turned on here. So I put a small 12V fan behind the unit blowing air through at a very low CFM rate. Notably, this seemed to cause the fluctuations to get worse. I observed this over many hours, and as soon as I removed the fan, it returned to the previous pattern.
2) After removing the fan, I put a piece of cardboard around the A/C vent so that the air would not circulate past the Lucent unit as much. This settled things way down, and the PPS value seems to mostly be +/- 10ns with occasional excursions to +/- 20ns and a much rarer spike to +/-30 ns.
During #2, the HUD value started to go down for awhile, but then started increasing again. It appears strongly correlated with the rate of change of the EFC value, which was fairly steady for a short time (while HUD was decreasing), but then started to rise again.
So in conclusion, the unit is sensitive to the environmental air temperature and possibly the EMI generated by that fan. The HUD value seems to be strongly correlated with the rate of change of EFC. The more constant EFC is when the unit is locked to GPS, the lower the HUD value, regardless of how much "jitter" there is of PPS.
I noticed that mine reacted strongly when a stray sunbeam fell on it for a few minutes. I'm surprised that a double-oven OCXO would be that sensitive to external thermal influences. The high number of holes in the case suggests that when these units were in service there was a fan tray or something similar that flooded the entire bay with a continuous stream of air to maintain a constant temperature. Closing off those holes would have to be done cautiously to make sure that nothing was going to overheat, but reducing drafts on the oscillator would likely improve performance.
By the way, don't add extra insulation around the OCXO! The internal heat must be allowed to escape. If you prevent that, the oven controller won't be able to control the temperature properly. Worst case, the internal temperature starts to rise and the unit cooks itself.
Yes, my theory on this is that we're talking about such minute changes in frequency, that even a tiny outside temperature change can have an effect. I wish I had some other unit to compare against - not sure if this is normal. Do you think the stray sunbeam was impacting the outside temperature of the oven, or is there perhaps some chip-scale IC inside these units?