[time-nuts] Re: Efratom FRK with "inoperative lamp"
On 5/2/22 2:58 am, paul swed wrote: Julien I don't think I would read a lot into the failed R just replace it. They are in a nasty hot environment and simply can age and die. Get at leat 2 resistors just incase there really is a shorted transistor or something else going on. Regards Paul Oh absolutely, my rough guess is the thermal insulation foam degraded corroding the leads /eventually/. This unit is over 30 years old, and who knows how it was used, although being in a road case makes me suspect it was not the sort of life we might like. I swapped in two 10-ohm 1-watt carbon film resistors today (being what I could get my hands on). Sadly I couldn't just solder to the lead stubs still poking through the board, they were just too corroded. A significant disassembly and reassembly later the unit appears to be improved, but still not locking. Should anyone run into this later, a clear bench, lots of lighting, and a way to ensure any screw you drop doesn't disappear never to be seen again are strongly recommended. Sadly my own bench is rather more of the Jim Williams[1] variety. A good soldering setup is also needed, but there I was rather luckier, even if my new desoldering iron did end up lifting a few pads. I /think/ it's using more power than it did before (right around 20W at total cold, dipping to 10W after a while), although silly me didn't make a note of it, but even after 30 minutes it's not locking. Given that the resistor I replaced is in a key point for the lamp excitation oscillator I won't be surprised if it's totally off and needs a recalibration, but that's a task for another day. When I stick a scope probe in the lamp cavity as the manual suggests I do see a a signal, so there's certainly hope, although I don't see the expected glow. I did confirm the heater is working, and was getting above 90c when I poked a thermocouple at it just after power-off. 1: https://www.edn.com/honoring-jim-williams/ On Fri, Feb 4, 2022 at 3:50 AM Julien Goodwin wrote: Well that was unexpectedly easy (to diagnose). Thanks all for the replies, much appreciated, you have once again confirmed my appreciation for this group. I sat down this evening to work through your various suggestions, and, by chance, picked up the unit without my lab power supply (and more importantly, its noisy fans) being on, where I heard a little rattle I must have missed before. Removed the bottom panel, which I hadn't done yet, and out dropped the remnants of a Vishay RW80U 20-ohm resistor. Based on the circuit this pretty much has to be R2 on the lamp board (following the December 73 circuit I have, which has that at 10 ohms), which is directly in-circuit for the lamp, so would explain exactly what I've seen. The lamp board in general seems to have a few holes missing components, so I'm going to have to get it out which looks like a project in itself. If anyone has any pointers to decent guides on optimum process on further disassembly, otherwise I guess it's copious photos, notes, and hoping I don't stuff up anything too much. I'd also appreciate suggestions for replacement foam to use in the lamp cavity as the original stuff has long since degraded. Paul, Peter Robert, Thanks for reinforcing what I'd suspected with the lamp. Matthias, I hadn't bothered with an actual temperature meter, luckily on the FRT it's actually easy to confirm lamp temperature in use, and it certainly wasn't anywhere near 100c. I think what heat there was likely leaked through from the crystal oven, which was getting pretty hot. Bob, Fortunately the onboard crystal does seem likely to still be close enough, based on what I was seeing on a counter, so I feel like I have a hope of recovering the unit if I do manage to get the lamp going again. On 1/2/22 8:17 pm, Julien Goodwin wrote: I picked up an Efratom FRT a while ago, and it finally arrived the other day, sadly it doesn't lock. The oscillator inside is an older Efratom FRK, and it's also clear someone had been inside already, although it does appear to be complete. The FRK manual does include a key description I wish I'd noticed a few days ago before full disassembly: "Terminal pin 7 provides an indication of proper operation of the rubidium lamp. For nominal operation the signal is 6 to 12V. An inoperative lamp is indicated by an signal of approximately 3V. The internal resistance of this circuit is approximately 6K." ... indeed I'm seeing 3v on that pin. Based on the circuit this appears to simply be the output of the first stage op-amp from the photo-cell, so is this effectively an indication that the (electrical part of the) lamp is dead? Certainly it wasn't anywhere near the temperature it should have been when I removed the bulb after running for over an hour. Just for completeness, the unit does draw up to ~0.8A when started up cold with 24V, dropping down to about ~0.5A after a while. The sealed sub-section of board A4 seems be where all the hea
[time-nuts] Re: Efratom FRK with "inoperative lamp"
On Samstag, 5. Februar 2022 10:48:57 CET Julien Goodwin wrote: > I /think/ it's using more power than it did before (right around 20W at > total cold, dipping to 10W after a while), although silly me didn't make > a note of it, but even after 30 minutes it's not locking. The power starting high and dipping eventually means there's some regulation for the temperature. That's a good sign. > Given that the resistor I replaced is in a key point for the lamp > excitation oscillator I won't be surprised if it's totally off and needs > a recalibration, but that's a task for another day. When I stick a scope > probe in the lamp cavity as the manual suggests I do see a a signal, so > there's certainly hope, although I don't see the expected glow. First goal is to get the lamp to light up, once that's working, "calibration" of the lamp exciter is only fine tuning. To see if the exciter oscillator is starting at all you could use a makeshift RF probe with an oscilloscope and a coil of wire connected to the probe and the get that close to the lamp. You should see something between 70 and 90 MHz if the oscillator is working. If it isn't, hopefully Q2 isn't damaged. Voltage across R14 should tell. There should be a voltage drop across it, maybe 1V or so? Lower if the oscillator is not working, but certainly not 0. If the voltage is 0V, Q2 has either failed open or the connection to the exciter coil is broken. If the voltage is much higher, Q2 has probably failed shorted and then R14 should also get very, very hot. > I did confirm the heater is working, and was getting above 90c when I > poked a thermocouple at it just after power-off. That's quite low. Nominally, the lamp temperature should be 113°C. The good thing about the FRK is the very detailed service manual that tells you exact troubleshooting steps for each of the component. I guess you've already found it? BR, Matthias ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: HP Z3801A project update
Depending on who’s GPS chipset is being used, a fix might be possible. I’ve poked around inside the firmware of a number of Trimble receivers (so far three generations of the 4000 series, and the Placer series). Because the first week rollover occurred in 1999, any receiver made close to that date already has logic to handle a week number rollover. Finding this in the disassembled code is usually easy because they simply add 1024 to the week number, which usually appears as an add instruction with a 0x400 immediate operand. changing a 0x400 to 0x800 will extend the receiver’s lifetime another 20 years. The most difficult part of this is figuring out the processor used on the receiver, and figuring out how to get the patched firmware back into the receiver. - Keelan > On Feb 3, 2022, at 8:50 PM, Bill Beam via time-nuts > wrote: > > The date issue is a 1024 week rollover failure in the GPS receiver. > A fix is to replace the GPS receiver with one that does not have this problem. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: HP Z3801A project update
> > You can also fix your software to add 1024 weeks until the date is past a > magic constant. If your tools support it, you can get that date as the > build > date from when you compiled your software. > Then there's US patent 5,923,618: "Leap-second cure for 1999 GPS rollover problem" The author of the 1999 patent identified that the frequency of leap seconds was quite consistent, and that the current "week number epoch" could be calculated from the number of UTC leap seconds: GPS Weeks = 84.55874 + 70.53509 * GPS Leap Seconds Of course what he couldn't predict was the 7 years without leap seconds that occurred between 1999 and 2006, and our current 4+ year leap second "dry spell", which puts the formula 12 years behind schedule. A great example of "it seemed like a good idea at the time!" Historically interesting, nevertheless. - Keelan ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: HP Z3801A project update
I think the problem with the Z3801 is that it expects to see specific handshake things at startup, in Motorola binary protocol. Dropping in a random GPS will result in a "No GPS" error. John On 2/5/22 12:44 PM, Keelan Lightfoot wrote: Depending on who’s GPS chipset is being used, a fix might be possible. I’ve poked around inside the firmware of a number of Trimble receivers (so far three generations of the 4000 series, and the Placer series). Because the first week rollover occurred in 1999, any receiver made close to that date already has logic to handle a week number rollover. Finding this in the disassembled code is usually easy because they simply add 1024 to the week number, which usually appears as an add instruction with a 0x400 immediate operand. changing a 0x400 to 0x800 will extend the receiver’s lifetime another 20 years. The most difficult part of this is figuring out the processor used on the receiver, and figuring out how to get the patched firmware back into the receiver. - Keelan On Feb 3, 2022, at 8:50 PM, Bill Beam via time-nuts wrote: The date issue is a 1024 week rollover failure in the GPS receiver. A fix is to replace the GPS receiver with one that does not have this problem. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: HP Z3801A project update
I do not know what Z3801 uses for GPS. I have several Motorola UT+ GPS modules running. Older ones with V2 firmware suffer 1024 week rollover failure. My units with V3.2 and V3.1 do 1024 week rollover correctly. If you are able to communicate with your device using Lady Heather she will correct any rollover error and display correct date. On Sat, 5 Feb 2022 16:36:15 -0500, John Ackermann N8UR wrote: >I think the problem with the Z3801 is that it expects to see specific >handshake things at startup, in Motorola binary protocol. Dropping in a >random GPS will result in a "No GPS" error. >John > >On 2/5/22 12:44 PM, Keelan Lightfoot wrote: >> Depending on whoGs GPS chipset is being used, a fix might be possible. >> IGve poked around inside the firmware of a number of Trimble receivers (so far three generations of the 4000 series, and the Placer series). Because the first week rollover occurred in 1999, any receiver made close to that date already has logic to handle a week number rollover. Finding this in the disassembled code is usually easy because they simply add 1024 to the week number, which usually appears as an add instruction with a 0x400 immediate operand. changing a 0x400 to 0x800 will extend the receiverGs lifetime another 20 years. The most difficult part of this is figuring out the processor used on the receiver, and figuring out how to get the patched firmware back into the receiver. >> >> - Keelan >> >>> On Feb 3, 2022, at 8:50 PM, Bill Beam via time-nuts >>> wrote: >>> >>> The date issue is a 1024 week rollover failure in the GPS receiver. >>> A fix is to replace the GPS receiver with one that does not have this >>> problem. >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an >> email to time-nuts-le...@lists.febo.com >> To unsubscribe, go to and follow the instructions there. >> >___ >time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an >email to time-nuts-le...@lists.febo.com >To unsubscribe, go to and follow the instructions there. Bill Beam NL7F ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: HP Z3801A project update
The Z3801As that I have seen have the Motorola Oncore VP 6-channel receiver which I think predates the UT+, and all have had the rollover issue. The problem with swapping in another unit is that unless it sufficiently imitates the VP at startup, the Z3801A will throw an error and never get to locked state. Of course, many of the old units still work fine except for the rollover providing a bogus date, and external software can easily correct that. John On 2/5/22 6:19 PM, Bill Beam wrote: I do not know what Z3801 uses for GPS. I have several Motorola UT+ GPS modules running. Older ones with V2 firmware suffer 1024 week rollover failure. My units with V3.2 and V3.1 do 1024 week rollover correctly. If you are able to communicate with your device using Lady Heather she will correct any rollover error and display correct date. On Sat, 5 Feb 2022 16:36:15 -0500, John Ackermann N8UR wrote: I think the problem with the Z3801 is that it expects to see specific handshake things at startup, in Motorola binary protocol. Dropping in a random GPS will result in a "No GPS" error. John On 2/5/22 12:44 PM, Keelan Lightfoot wrote: Depending on whoG€™s GPS chipset is being used, a fix might be possible. IG€™ve poked around inside the firmware of a number of Trimble receivers (so far three generations of the 4000 series, and the Placer series). Because the first week rollover occurred in 1999, any receiver made close to that date already has logic to handle a week number rollover. Finding this in the disassembled code is usually easy because they simply add 1024 to the week number, which usually appears as an add instruction with a 0x400 immediate operand. changing a 0x400 to 0x800 will extend the receiverG€™s lifetime another 20 years. The most difficult part of this is figuring out the processor used on the receiver, and figuring out how to get the patched firmware back into the receiver. - Keelan On Feb 3, 2022, at 8:50 PM, Bill Beam via time-nuts wrote: The date issue is a 1024 week rollover failure in the GPS receiver. A fix is to replace the GPS receiver with one that does not have this problem. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. Bill Beam NL7F ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: HP Z3801A project update
j...@febo.com said: > Of course, many of the old units still work fine except for the rollover > providing a bogus date, and external software can easily correct that. If you tell it the date, it will do the right thing. T220220205235450339 >From the status page: GPS 23:55:19 05 Feb 2022 - >From page 42 of Chapter 3 of the UT manual. ROLLOVERS IN TIME In August of 1999, the GPS week number will rollover from 1023 to 0 due to the limited length of the GPS week field in the navigation data stream. Motorola Oncore receivers (GT, UT, VP, XT, and Basic) have been designed and tested to properly distinguish the correct 20 year window (1024 weeks is just shy of 20 years). They will not need reprogramming or replacement come 1999. In fact, the transition will be completely transparent to users of Motorola Oncore GPS receivers. Motorola Oncore GPS receivers are also year 2000 compliant. Multichannel GPS satellite simulators have been used to test each rollover condition in GPS. For example, each week there is a rollover in the GPS seconds on midnight Saturday. The August 1999, year 2000, leap day, and leap second rollovers have all been successfully tested using simulators. In order to handle the 1999 rollover, Motorola GT and UT Oncore GPS receivers use a date stored in flash memory. For example, if the firmware date is 1996, a defaulted receiver that does not have back-up power (or battery) will start with an internal time of 12:00 on 1/1/96 and begin acquiring satellites. Once the first satellite is acquired, the time and week number will be downloaded from the navigation data message. The receiver determines the current date by starting from the week number of 1/1/96 (week 834) and searching for the first occurrence of the current week number (week 860 for 7/1/96). -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: Timestamping counter techniques : dead zone quantification
Erik, You also also test the issue by vary the slew-rate of the input signal. The trigger circuit will convert voltage noise into time noise, and any such leakage will become larger time for slower slew-rate. You can look up Collins paper amongst others for zero-cross-detectors. Combining that with the knowledge of leakage can be fruitful to understand the analog side of it. The cross-talk comes in two flavours, one is just straight signal-leakage, typically capacitive coupling, the other is indirect through common ground-bounce which is really inductive. High resolution counters have been used to analyze signal integrity issues like these. An alternative approach is TDR/TDT, which I tend to fancy. A good way to characterize an input is to measure the RMS for a sweep over all phase relationships of the incomming phase and that of the coarse clock. One need to make sure one covers those phase relationships equally enough. Cheers, Magnus On 2022-02-04 11:49, Erik Kaashoek wrote: Magnus, Thanks, good input. To check if there is "pulling" between the two counter inputs I used two signals generated by two PLL's from the same OCXO. First measurement is both at 10MHz. The ratio of these two signals was measured in the two counters using a shared 10MHz reference with a 0.1 s gate time. The ADEV behaves well and starts below 1e-9. When one of the signals is shifted with 0.1 Hz (ratio change 1e-8) or 0.2 Hz (ratio change 2e-8) the ADEV starts to show oscillations and the frequency difference shows a pulling pattern that repeats every 10 s for 0.1 Hz difference and 5 s for 0.2 Hz difference. Both ADEV and frequency difference plots are attached The difference between the 10MHz from the signal generator and the 10MHz reference in the counters was large enough to not create any visible pulling using a 0.1 s gate time but when I brought the 10MHz from the signal generator close (within 0.2 Hz) to the 10MHz reference in the counter the interaction became very visible and the repetition rate nicely varied with the measured frequency difference. This clearly demonstrates the cross-talk you mentioned, both between the two counter inputs and between the inputs and the counter reference OCXO As my goal is to create a dual input timestamping counter that can reliably measure with 1e-9 accuracy (both short and long term) there is clearly some work to do. Erik. On 3-2-2022 17:14, Magnus Danielson via time-nuts wrote: Erik, You should be aware that cross-talk of transitions is a factor here. It "pulls" the transition to the time-base clock. It can be worth evaluating this by delaying the time-base clock in controlled manor and measure non-linearity of the time-stamps. A similar test is done between two inputs, as the trigger inputs can cause cross-talk from one another. This is known to be the issue of several vendors counters. As you push the limit for the resolution, these effects tends to increase in relative size, but for other work they can be fairly ignored. For some reason I have built a collection of pulse-generators and delay mechanisms to increase the ability to test this. :) Cheers, Magnus ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: Is this bad OCXO behavior?
Hi, As you run the OCXO without the lock to the maser, what does it do then? Can you probe the input before the loop? The EFC Voltage is a consequence of the loop action, so sorting out what is a oscillator thing and what is sourced by other things becomes much easier by opening up the loop and measure things separately. Cheers, Magnus On 2022-02-06 03:28, Skip Withrow wrote: Hello Time-Nuts, Well, hopefully many of you have read the saga of the Sigma Tau MHM-A1 restoration by now. Seems like the next chapter has already begun. Attached are two graphs, one of the VCO EFC voltage, and one of the VCO supply voltage. They cover about a six day period (logged once per hour). As you can see the EFC plot has several blips in it. After two of the three episodes there is an offset in the EFC voltage. The second plot is the VCO supply voltage. There does not appear to be any spikes there that correlate to the EFC events. You can see the daily diurnal variations in the supply voltage as there is 2 ohms in series with the supply before this point (and the bus supply has a slight diurnal variation as well). I know that OCXO's can have these types of jumps. But I have to believe that this is not a desired thing for a maser. The two big questions I have are: 1. Should I consider replacing the oscillator? It is an Austron 1120L which is probably unobtainium. However, there are probably lots of SC-cut low phase noise units out there today that would beat the pants off this unit. 2. Could it be a component other than the crystal? Not that I want to go tearing into the oscillator again, but if it was the varactor diode or a capacitor I might be up to the challenge. The problem is trying to identify the faulty component. Just wondering what the hive mind thinks. Thanks, Skip Withrow ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Dimensioned Drawing LUCENT-SYMMETRICOM Z3810AS KS24361
Since my homemade version did not turn out as well as I had hoped, I was planning to have my local fab shop laser cut a rack panel for our "new" LUCENT-SYMMETRICOM Z3810AS (KS24361) Before break out the ruler, anyone have a dimensioned drawing of the mounting and panel holes? Martin A Flynn / W2RWJ Computer Deconstruction Laboratory 2201 Marconi Road Wall Township, NJ 07719 Tel: +01 732-456-5001 Email: martin.fl...@compdecon.org Online: www.compdecon.org Facebook: https://www.facebook.com/compdecon/ ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
