Efratom LPRO repair attempt

[thinkfat]

Thanks for the document collection. I've read most of them already, but the Indian research paper was new to me. Nice stuff, gives some more insight on the physical package. So there's Krypton in the lamp, too. And there's some discussion about the different "burn modes" of the lamp, which affect the output of the relevant spectral lines. Apparently you're supposed to tune both frequency and current of the lamp exciter for optimal results. I somehow overlooked that, I'm sure it's mentioned in some of the other documents.

[thinkfat]

Summing up this thread, here's a few things I learned:

• the lamp voltage is not sufficient for health assessment.
• frequency of the lamp exciter oscillator is critical for stable operation. If the frequency is wrong, it may create noise on the detected signal to the point where locking is impossible.
• a decisive health indicator is the signal amplitude on the servo test pin. It should be in the range of 4V p-p in the LPRO101 and free of spurs and noise.
• If the FLL doesn't lock, you can disconnect the servo from the VCXO and trim it manually until you can see something on the test pin, then trim SRD and Cavity for maximum output.
• the service manual for the Efratom FRK-L is really helpful with a lot of troubleshooting information.

This is a photo of the test setup with free-running VCXO connected to a 30k trimpot between 14V and GND. As usual, black is GND, red is 14V. Green is connected to the VCXO input. The probe of the oscilloscope is on the servo test pin. It's advisable to have a counter connected to the 10MHz output, otherwise it'll be really difficult to trim the VCXO manually.

[testpoint1]

actually SRD is very important for the locking, if the diode is not so good, will cause unstable lock. and, do not do any adjustment in the circuit, if the component in PCB is ok, no need to do it.

[chick0n]

Hi

Could anyone tell me the Marking on Inductor "L607"?

Mine broke off the PCB.

I marked it with red arrow.

[thinkfat]

DALE
6R8
9937

[thinkfat]

Reviving the thread, adding a couple of things I learned about the LPRO-101 recently.

During the repair, I complained about the signal on the servo pin being quite small in amplitude. Around 1 Vpp instead of the 4 Vpp suggested in the repair document. I never got that fixed and basically wrote this LPRO off as being near death, despite the lamp voltage going strong.

Now, I recently bought another Rb clock, not a LPRO-101 but a SLCR-101, which is basically the same but smaller form factor. The PCB is identical, just the physics package, in particular the cavity (and thus the absorption cell) are of smaller diameter, allowing the whole device being about half the height of the LPRO-101.

Anyway, while comparing the SLCR with the "weak" LPRO, I noticed that the SLCR has a jumper installed on J10, connecting the two middle pins, while the LPRO hasn't. Just out of curiosity I installed the missing jumper in the LPRO-101 and whoop-dee-doo the signal on the servo test pin went waaaay up, more than 10Vpp. What I also found is that you can actually tune the servo signal amplitude with the trimmer right next to J10.

The next thing I learned is that even when the XO is locked to the Rb, the stability can be abysmal. An indicator is the stability of the servo test signal. If it fluctuates a lot, appears unsymmetrical or has spurs on it, the output stability will suck. The key to fixing this is the lamp oscillator. You can tune its frequency over a wide range, but on some frequencies it will badly couple into the synthesizer and mess up the spectrum big time. You need to find a frequency where a) the lamp ignites reliably and b) no spurs or even small spikes on the servo test signal. This is best observed with an oscilloscope in auto-roll, timebase set to 1s/div. This gives a couple seconds of signal history on the screen and spikes and spurs will show up visibly. The amplitude envelope should be constant with no modulation.

As far as short-term stability is concerned, you will want to check the servo test signal for amplitude fluctuations. The best method I have found is to set up a Peak-Peak voltage measurement, enable the statistics and check the standard deviation. With a mean Vpp of around 4V, stddev should be 150mV or less. The lower the better. I have not yet found a decisive factor to tuning this, but stability of the XO voltage supply is important, as well as again, tuning of the lamp oscillator.

[Johnny B Good]

@thinkfat

 I finally decided, some 23 months after its purchase from testpoint1, to pop the lid off my precious LPRO-101 just yesterday to check out a couple of one off suspicious wobbles I'd seen on the DSO the night before. I've been tracking its drift against my home brewed GPSDO for several months whilst trying to fine tune the fan cooling algorithm that's meant to keep the baseplate temperature stabilised to within 50mK of the 36.01 deg C setpoint I'd chosen to allow stable temperature control up to a maximum ambient limit of 32 to 33 deg C. These disturbing events were the final motivation to risk my doing more harm than good by following DeVries's Rev 7 October 2011 repair guide.

 Whilst I had it open, I noticed the largely missing foam insulation between the lamp and the vapour cell assemblies.  There had been no sign of foam debris so I assumed testpoint1 had  simply hoovered it out to get the lamp voltage back up to a more workable level. Although the absence of this foam insulation compromises the temperature control of each section a little, it does at least have the merit of providing a quick fix to restoring an LPRO to a working state.

 That was a minor issue, easy to fix with polyamide foam, readily available as "Magic Eraser" cleaning sponges. It's exactly the same stuff that's used to insulate boilers and hot pipework but sold at a high cost per gram to the cleaning obsessed public (luckily, less than a gram's worth is needed in this case - it's very lightweight stuff

 I removed the lamp to check for rubidium splash marks to see whether I needed to give it the hot air treatment but all I could see was the frozen blob of rubidium right where it was supposed to be, at the pinch (considering its normal horizontal orientation, Gawd knows how it defies gravity but I guess capillary forces must normally keep it in place other than for when being dropped on its end whilst still above 40 deg C). The lamp envelope had a brownish tint similar to that of those 15W pygmy oven lamps, only a touch darker.

 Undismayed, I treated the glass with IPA to clean off some 25 years' worth of atmospheric contaminants, and the same for the protective window and the front glass of the vapour cell to test my hypothesis that the cleaning associated with the hot air remelting exercise plays some greater or lesser part in this heat treatment improvement. In my case, no need for the heat treatment, it does at least seem that cleaning the glass alone offers a small but useful improvement.

 I did try tuning the capacitor on the lamp housing but the very narrow slot on the end of the brass tuning slug forced me to resort to the smallest of flat bladed jeweller's screw drivers to stand any chance of turning it (it was very stiff to start with and even if I'd had a plastic trim-tool with metal blade tip that could be filed to fit the slot, I doubt it would have been strong enough - it might be now that I've worked the extreme stiffness out).

 At first I'd assumed the the tuning slug would be grounded but this seemed not to be the case. In hindsight, I realise it was isolated to eliminate sliding contact losses, working on the same principle as butterfly vaned ceramic trimmers where only the stator plates are connected to the circuit. This means I need to buy or fabricate a purpose made trimming tool to tune this particular circuit

=========================================================================================
[EDIT 2022-07-05] When I had another go at tuning the lamp oscillator cap whilst I had the lid off yesterday to fit the missing jumper link and adjust the servo amp gain to drop the amplitude down to 4.5v pk-pk and tune the cavity and the SRD bias pot, I took a closer look at this capacitor tuning slug (both visually and with a DMM continuity test - something I should have done to begin with ). It turns out that my supposition that the slug was a "piggy in the middle" component part had been total and utter bollix. That tuning slug is in galvanic contact with its ground terminal. It would seem that at 60MHz, the lamp oven's ground isn't quite at RF ground potential, hence the disturbance to the servo signal whilst tuning it.

 I'll save my further observations and conclusion on this lamp oscillator adjustment exercise for a later post and just add that a cheap flat bladed jewellers screw driver is safe to use. I found one that was just the right width with a blade thickness that was barely shy of being an interference fit in the slot - it was just a case getting it precisely aligned before it would slip into the slot.
=========================================================================================

 I gave up when I realised I was on the losing side of this particular adjustment battle. I think I left it parked where it had been before starting this doomed enterprise but I'm not certain. I'm guessing this is why DeVries neglected to mention the adjustment procedure in his otherwise excellent repair guide.

 Anyway, whilst I was checking the board over for obviously failed components - the complete absence of any electrolytic capacitors makes finding any obvious failures by visual inspection alone a forlorn task (anything else that shows any signs of failure is likely to have already stopped it dead in its tracks and mine was still functioning ok (ish)), I noticed the jumper headers which reminded me of your findings. Unfortunately, I couldn't recall where these particular nuggets of useful information had been stored (or whether I'd even kept a copy of these notes) so I decided not to experiment since they matched what was in DeVries's repair guide in spite of the pk-pk servo voltage being only 900mV to begin with, maxing out to 1.5v pk-pk after adjustment.

 It was only this afternoon, as a result of yet another "Unicorn Hunt" with DDG, that I came across an image you'd posted that linked back to this topic thread which I'd obviously read back when it was still active otherwise I'd have still been trying to track down the jumpering (and other) info you'd so kindly provided. However, putting that information to use will have to wait for another day or two since I'm seeing a very encouraging improvement  that at least suggests I managed to do more good than harm this time round I'd like to let the test run another day or two before I subject it to yet another cool down cycle (or, as I view it, another nail in its coffin).

 Besides this, taking the lid off involves the ticklish job of releasing it from a fan cooled heat spreader before undoing the add-on mcu board piggybacked onto testpoint1's own add on breakout board attached via the J1 10 pin connector's plug retaining screws so as not to damage the connections to the three regulators bolted onto the heat spreader plate (a 7812 feeding a couple of 7805s, one of which is currently dedicated only to supplying 1mA to a 5K 10 turn tuning pot feeding the EFC pin via a 3.3M resistor - that internal 10 turn trimpot is an extremely useful feature in simplifying the padding circuit to just a single cheap resistor ).

 Hopefully, when I next disassemble it from my fan cooled heat spreader and mcu controller concoction, I'll not have to resolder a broken connection (it had been a poor solder connection direct to the end of the 33k input resistor rather than a vacant adjacent hole I should have used and solder blobbed to the input resistor instead ) This was the BITE wire connection which resulted in an immediate green "Atomic Lock" status indication on power up as opposed to the red "Powered up - awaitng lock" indication on the two wire bi-colour status LED. Initially, I'd hoped, despite being sure I'd connected it the right way round, that I'd simply reversed the non-polarised two pin connection but since it had remained green after the DSO showed that it had locked, I was resigned to having to hammer yet another power cycle nail into its coffin.

 However, that was not until I'd given it another half hour or so to confirm that I'd at least managed to raise the lamp voltage from its previous 4.848 volts reading prior to my attempt to improve it to a more healthy looking 5.2xxx volts after its initial 5.9ish volts excursion from cold followed by the usual slow climb to where it now shows 5.2458 volts some twenty hours later, and possibly still on the rise before ultimately starting a slow decline of about  1mV or less per week as it had always done during the previous 18 months or so of running it 24/7.

 Assuming for simplicity's sake that this trend remained constant, that implied a remaining lamp life of 36 years and that was before I'd "rejuvenated" the lamp! Of course, I doubt such an optimistic estimate and figure there might be another 12 to 15 years left on a lamp that's almost certainly clocked up more than 20 years to date.

 IOW, unless the lamp voltage is already below the 4 volt mark the strategy of intermittent operation to maximise the remaining lamp life seems to my mind more likely to do harm than good by the thermal cycling stresses imposed on the electronics.

 I've attached some 'scope screenshots taken over a sixteen and a half hour period. There were 12 bmp images in all and I was going to drop two of them after converting them into jpgs to fit within EEVBlog's 10 files max and paltry 5MB posting limit until I realised I really needed to show all 12 making the file compression exercise redundant ('d still have to split them into two postings and worse still, the compression loses the original date/time information which is important in this case - I'm assuming the attached files will retain their original date/time stamps despite the renaming to get past EEVBlog's stupid filter... which the server refuses to accept for failed security checks ).

 I've given up trying to preserve the original date/time stamps. Instead I'll list the time stamps here, starting at 3am Saturday morning

1st lot

03:00
06:45
11:13
12:00
12:00
12:10
13:27
14:00
15:30
17:00

2nd lot

19:30
00:13

 The final image shows the result of what seems to be yet another 'event' where it suddenly shifted about 5ns to the right where it has been keeping station within a ns or two for the last 3 hours. I guess I'll be checking out those jumpers tomorrow after all and having another go with the lamp exciter oscillator setting.

[Johnny B Good]

The final two remaining images... plus another two images captured at 02:15 within a few seconds of each other to provide continuity when clearing the infinite persistence for another run.

[EDIT 2022-07-04 08:52]

Three more screen captures (made at 04:04, 08:30 and 08:34 respectively) to make the point that the sudden 5ns excursion to the right (transient drop in frequency) last night had been yet another random one off event similar to what I'd actually witnessed the night before.

 Aside from those one off events, I'd otherwise consider the frequency stability of my RFS to be close to perfection and I'd be one happy bunny. The +/- 3ns phase wobble is entirely the effect of GPS disciplining all of which are due to errors built into the GPS system itself, which with a single frequency GPS timing receiver, an M8T in my case, are mostly imperfectly corrected ToF delays due to variations of the ionosphere.

[Johnny B Good]

 I disassembled my RFS for a second round of adjustments (as mentioned in my edit in my first reply) and fitted the jumper to increase the servo signal, along with adjusting its level to 4.5v pk-pk on the adjacent gain pot (it works even without the jumper but only increases the level to around the 2v pk-pk mark).

 Having done that I had another fiddle with the SRD bias pot and the cavity tuning screw which only provided a marginal improvement over my earlier adjustments before turning my attention to the lamp oscillator tuning cap. This seems more to do with adjusting the lamp heating power (which I understand to be optimal at 2W) than the particular frequency used. Although the standard deviation seemed to be effected, no matter where I tuned it, given more than half a minute or so observation time, it would eventually jump up from an acceptably low 50 to 120mV pk-pk varying up and down to some 200 to 270 mV with little sign of creeping back down towards its former values.

 Of course with that 'grounded' tuning slug still crawling with 60MHz of RF due to its obvious inductive connection to the ground plane, every time I touched the screwdriver tip to the slug, I'd see horrendous spikes on the servo trace which settled down once I had my metal screwdriver fully engaged into the almost interference fit slot of the tuning slug.

 I tried many settings before deciding that getting the standard deviation to remain at or below the 150mV mark whilst the lamp housing remained bereft of the shielding normally provided by the mu-metal cover was a complet waste of time and went for broke to see just how high I could adjust the lamp voltage. This turned out to be a tad over 6.2v. Mindful that this might be a little too much of "A Good Thing", I backed it off to 5,8 volts which in retrospect might still be too much a good thing.

 It zoomed up to just over 6 volts during the warm up after I reassembled it and then, as expected dropped back to 5.880 volts before creeping up to its current high of 5.88830 volts with possibly another mV or two to go before it hits its peak in another day or two's time and start a very slow decline of about a mV per week thereafter.

 In the light of this afternoon's "one off" 6 to 10ns backward step in phase wrt the GPSDO reference, I'm thinking I aught to make a third visit to the dark interior of that LPRO to reduce it to a less ambitious 5.3v. If those mystery backwards jumps aren't the result of counter electronic measures being applied by GPS Central to aid the Ukraine war effort (or possibly Russian interference), then my adjustments to the LPRO seem to have had no effect on this seemingly peculiar behaviour.

 That being so (the problem lies with the LPRO), I think it only prudent to dial the lamp power back and reduce the risk of accelerating the rate of LVD and a sub-optimal lamp power level to boot! A case of being safe rather than sorry.

 That wild thought that the issue may lie with the GPS signals due to electronic countermeasures is more wishful thinking (that my RFS isn't the culprit) but the only solution I could think of to lay that nagging thought to rest is to acquire yet another Rubidium oscillator and, to that end, I've just purchased a "USED Symmetricom 15MHz Rubidium Oscillator atomic clock SA22C-0028C02D0002" from this seller:-

https://www.ebay.co.uk/itm/253709293753?epid=1524016453&hash=item3b124098b9:g:CBsAAOSwsJ1bMSCo

 As you can see, I've gotten the last one in stock and it's a 15MHz square wave output but from what I read in the manuals, they can be programmed to output a 10MHz sine wave and if this proves too risky to attempt, then it's fairly trivial to lock one of my 5 spare 10MHz OCXOs to a 15MHz conveniently TTL level square wave in any case.

 Besides which, I've always got the option to lock my much modified FY6600-60M "toy awg" to the LPRO and tune it to precisely 15.000000000000MHz to compare it against the SA22C and lock the SDG 2042X to the gpsdo (I can manage with the lack of μHz resolution above 100KHz in this case) and switch from the SDS1202X-E to the SDS2104X+ to display all three traces (the 2104 burns up 54W versus the 22W of the little 1202X-E, so it only gets turned on for special usage cases like this)

 It seems all the 'good' rubidiums have been sold off, leaving only grossly over-priced Temex units I wouldn't give tuppence for (they suffer from electrolytic capacitor rot (electrolytics in a rubidium oscillator - really? ). I was quite taken aback that not only were the LPRO-101s totally absent  from ebay sellers's listings but also the slightly less desirable FEI units and all the other Efratom/Datum/Ball LPRO offerings (and Amazon was even worse!).

 The seller provided free postage but I would have had to wait some three to nine weeks for its arrival so I stumped up the extra 35 dollars American (30 quid sterling) for expedited delivery in 1 to 2 weeks time

 It seems like I picked a bad moment in history to start testing my temperature stabilised (and barometrically compensated) RFS project against a timing reference system originally funded by a massive military budget. This wild thought that maybe the GPS system is no longer the reliable trustworthy timing reference it once was has been nagging me ever since. Hopefully, when I get my hands on that SA22C, I'll finally settle that niggling question to my satisfaction once and for all.

 Well! Wouldn't you know it, my RFS has just taken a sudden 12ns backwards step some time in the past half hour or so, literally whilst my back was turned! This once or twice a day event seems unlikely to be due to tantalum or ceramic cap failure (nor, for that matter any other component failure) in that other than for these two or three second long events (assuming they're the same as the one I caught in progress a few nights back), the RFS functions absolutely perfectly with only the GPS disciplining wobbles being in evidence with almost zero drift once it's properly syntonised to that moving target of a GPSDO.

 Ah well, hopefully I'll be able to prove whether my RFS is the culprit or not once I get hold of a working (as advertised) SA22C in a (hopefully) week or two's time

 I won't burden you with a bunch more screenshots. Instead I'll attach a couple of self described pictures for your amusement.

[thinkfat]

I may be stating the obvious, but how do you know it was the LPRO that did the phase jump?

[Johnny B Good]

 Excellent question!    The answer is, as I'm sure you already knew, "I Don't!  " Hence my purchase of that SA22C.

 I took a last screenshot at 04:48 this morning showing a 10ns wide band of persistence and the next one at 12:47 revealed a 30ns wide band leaving the rubidium trace parked right on top of the gps trace.

 Obviously, there must have been at least one 20ns jump backwards (or maybe two 10ns jumps) during that 8 hour interval. I cleared the sweeps (and set the Sootys - silly joke,  I know) and took another screenshot to clear the persistence and then took another 4 screenshots at 2, another 2, then 4 and finally 15 minute intervals where the only hint that the 'scope hadn't frozen lay in close scrutiny of its screen to witness the low level noise in the trace and eventually a half nanosecond or so of drift between them.

 I took another screenshot 50 minutes after that where I could see the expected disciplining effect on a seemingly perfectly syntonised to the GPS RFS trace, a 5ns band of persistence which still remains some 50 minutes later on (it's subsequently advanced a couple more ns in the 5 minutes since - not unexpected when a gpsdo is the reference).

 Incidentally, the lamp voltage has reached an average value of 5.89070 volts. The variations can range between 150 and 30 μV depending on my nano based temperature regulator's mode of operation which can go into 'pogo mode' (+/-100mK) or settle into a more stable mode (+/-10mK).

 Whilst the average temperature remains within 20 or so mK of the stable mode temperature (I've no doubt this Pogo mode opens the door for an ambient temperature related biasing shift) I'm surprised I can detect its effect on the lamp voltage (it's amazing what you can observe with just a 6 1/2 digit DMM, especially one with an almost zero tempco - the main reason why I decided to spend the extra on an SDM3065X rather than its cheaper cousin, the SDM3055X).

 I know the lamp voltage variations are temperature related rather than electrical interference caused by the fan's loading on the 19.5v laptop charging brick's voltage because when it's in pogo mode, I see the lamp voltage follow the temperature changes on the display during the times when the 12v 80mm fan is completely stopped with no hint of any sudden jumps when the fan kicks back in at 100% PWM for anywhere from 80 to 240ms to accelerate it up to speed from a standstill off an 18 volt supply - the effect seems to be purely a temperature mediated one.

 As I mentioned previously, I'm a little concerned that I may have literally 'overcooked' the lamp heating power setting on my last round of adjustments. The warmed up current draw, as observed when the fan isn't running remains unaltered but I know the extra 60MHz power reduces the demand on the lamp housing's heater so all that indicates is that there's no obvious sign of a serious overload condition other than for the lamp itself.

 Do you have any opinions to offer on this? My own thought is that it's best not to go too far in compensating for reduced light output from the lamp by hitting it with more heating power. Not only does this seem likely to accelerate the ageing process, it'll also shift its output spectrum from the optimal design value (doppler shift effect by the presence of the buffer gas (mixture)). However, it seems a more modest boost may offer a net benefit in the trade off between those two effects. It's even possible that I may have reduced the lamp power slightly on my first attempt and that decontaminating the glassware alone may have provided a bigger improvement than I'd observed.

 Two final notes, the lamp voltage is now averaging 5.89100 volts and the RFS trace has settled back to its original start point some 4 1/2 hours after the 12:47 screenshot, having peaked to 8ns ahead of this point (a total sweep of 14ns contributed mostly by the GPSDO's disciplining of a less than perfect GPS timing signal).

[thinkfat]

Are you talking about the RF exciter that pumps the lamp? Or about the heater for the housing? I never adjusted the heater, I think it's not an adjustable on the LPRO, or at least I didn't find out where. The setpoint is given by a fixed voltage divider, that, together with the heating FET, is one of the common faults of this RFS.

I did adjust the RF frequency to reduce the spurs on the servo signal and to improve stability. As far as I know, the actual output power is regulated by the drive current of the RF transistor. The exciter has two modes, one for lamp ignition, with higher current, and a lower current mode that is switched in as soon as the lamp ignites. The lamp voltage is what switches the modes.

The capacitor at the lamp housing forms a tank circuit with the exciter coil inside the housing. Tuning the capacitor mainly changes the exciter frequency, not so much the output power.

You might want to try a tiny drop of silicone oil on the capacitor if it's stuck.

For measuring the frequency of the oscillator, a magnetic field probe will be useful. Or just a coil of mag wire, 10 turns or so, connected to the tip of an oscilloscope probe.

PS: you know what they say about a man who owns two clocks...

[Johnny B Good]

Are you talking about the RF exciter that pumps the lamp? Or about the heater for the housing? I never adjusted the heater, I think it's not an adjustable on the LPRO, or at least I didn't find out where. The setpoint is given by a fixed voltage divider, that, together with the heating FET, is one of the common faults of this RFS.

I did adjust the RF frequency to reduce the spurs on the servo signal and to improve stability. As far as I know, the actual output power is regulated by the drive current of the RF transistor. The exciter has two modes, one for lamp ignition, with higher current, and a lower current mode that is switched in as soon as the lamp ignites. The lamp voltage is what switches the modes.

The capacitor at the lamp housing forms a tank circuit with the exciter coil inside the housing. Tuning the capacitor mainly changes the exciter frequency, not so much the output power.

You might want to try a tiny drop of silicone oil on the capacitor if it's stuck.

For measuring the frequency of the oscillator, a magnetic field probe will be useful. Or just a coil of mag wire, 10 turns or so, connected to the tip of an oscilloscope probe.

PS: you know what they say about a man who owns two clocks...

 It's the RF exciter - the housing heater will react to the variations in excitation power just the same as it would in response to ambient temperature effects. I mentioned it because the increased lamp excitation power will cause the heater current to drop, almost cancelling out the increased current  drawn by the exciter making such a change invisible when monitoring the unit's power supply current.

 Initially, I tried the same exercise to minimise the mean deviation in pk-pk voltage but although I could get this down to less than 100mV for maybe as long as half a minute, it would suddenly jump up to between 200 and 270mV and remain very close to that value thereafter. If it was a rogue glitch, I'd have expected it to slowly settle back close to the 100mV mark before jumping again. I could clear the stats at any point and start off as before, low mean deviation values for the firs 30 seconds or so followed by a sudden jump to the 200 to 270 mV mark.

 BTW, that tuning slug wasn't stuck, just rather stiff to begin with. It's stiffness seems to have eased off somewhat so even if I thought that applying a drop of silicone oil would be a good idea (I don't since it risks creating a high resistance contact in a component that should have a sub milli Ohm ESR), I no longer need to take such a measure.

 It didn't seem to matter how I tuned the tank capacitor other than for the variation in the photocell output voltage. I'd see pretty much the same behaviour hence my tuning it to see how high I could raise the lamp voltage before dialling it back to the 5.880 mark (it's now showing 5.89510 volts - still increasing!).

 I've closely examined the circuit diagram of the lamp exciter and I find it very confusing to say the least. Clearly it's a self oscillating power amp stage (common drain Colpits I think) driving what appears to be a Pi tank circuit turned on its head (the tuning cap is normally on the input side rather than the output as seems the case here.

 Since precise frequency output isn't a requirement in this case other than perhaps to avoid troublesome spot frequencies, the 'tuning' cap is being used to vary the loading and hence trim the lamp power (the 'loading' cap is a fixed 15pF connected to the source with an 82pF dc blocking cap linking it to the tank coil with the 'load' being connected via electromagnetic coupling to the tank coil.

 Prior to the lamp striking, the coil and the tuning cap form a high Q series tuned circuit, once the lamp has ignited, it becomes a very damped low Q circuit where increasing the tuning cap value increases the coil current whilst coincidentally reducing the oscillator frequency.

 Clearly, the designers didn't require an exact 60MHz excitation field in the lamp housing since they could so easily have derived it from the third harmonic of the 20MHz XO. It seems you could tune the tank circuit anywhere from 40 to 90MHz with that 0,6pF to 4.5pf tuning cap and basically simplify the loading adjustment to just a single capacitor trimmer and let the devil take the hindmost over adjusting the other capacitor in a Pi Tank circuit as you would have to do if it were operating at a separately defined fixed frequency locked to the third harmonic of the XO.

 That being the case, I don't need a precise frequency measurement and I can probably get enough voltage into the standard 10:1 probe just by placing its insulated tip against, or even just close to, the lamp housing to satisfy prurient curiosity.

 I finally concluded that I was trying to solve a problem of avoiding certain frequencies that could cause trouble with the servo stability which would likely disappear as soon as the lid was fitted to enclose the physics package (lamp exciter included) within its own screened compartment so I tuned it for an acceptable lamp voltage and an initial sub 100mV pk-pk standard deviation and forget about the sudden leap to 200 odd mV pk-pk deviation that would appear some 20 to 30 seconds later. TBH, I was beginning to think "Bugger it, life's just too short for me to go chasing rainbows like this!"

 The presence of that 6 pin "gain adjust" header strongly suggests that it may be providing a 3 bit wide coarse gain adjustment option with the trimmer doing the fine gain adjustment. I've seen a target value of 4.4v pk-pk mentioned and the amp is fed off a 14v supply with a DC voltage on that pin around the 7.2v mark. 4.4v pk-pk is pretty close to the 10dB headroom level which I assume is a deliberate choice to avoid rogue spike voltages overloading the amp and causing more disturbance than that due to the transient alone. I chose to set it for a 4.5v pk-pk value as measured with the 'scope. I'll experiment with that jumper block when I open it up to dial the lamp power back to a less aggressive lamp voltage level of 5.3v later today.

 Incidentally, I've not seen any more peculiar phase jumps since that last one just over 36 hours ago. The RFS has steadily gained just under 1ns per hour since 9pm last night and, afaicr, I've resisted the temptation to 'twiddle' with the calibration since then. That's the hardest part of syntonising an RFS against a GPSDO, resisting the temptation to 'twiddle'. Since it takes several hours to detect any change not attributable to GPS disciplining, the "Devil makes work for idle hands" factor starts to come into play.

[thinkfat]

The idea of tuning the exciter frequency actually came from the FRK-L service manual, which contains a very detailed repair and adjustment procedure. Sadly, such document is missing for later RFS models, the Efratom FRK series was meant to be field serviceable while the LPRO manual simply says: return to factory for repair.

The exciter oscillator is not meant to be in tune with the synthesizer. On the contrary. The FRK-L manual makes it clear that an exciter frequency should be found that has no harmonics or spurs that would interfere with the synthesizer, to achieve datasheet specs. Since the LPRO has the same basic design as earlier models, just with more modern components, I'm sure the advice is valid for it, too.

[Johnny B Good]

The idea of tuning the exciter frequency actually came from the FRK-L service manual, which contains a very detailed repair and adjustment procedure. Sadly, such document is missing for later RFS models, the Efratom FRK series was meant to be field serviceable while the LPRO manual simply says: return to factory for repair.

The exciter oscillator is not meant to be in tune with the synthesizer. On the contrary. The FRK-L manual makes it clear that an exciter frequency should be found that has no harmonics or spurs that would interfere with the synthesizer, to achieve datasheet specs. Since the LPRO has the same basic design as earlier models, just with more modern components, I'm sure the advice is valid for it, too.

 Well, after last evening's (and early hours of this morning), 'servicing exercise', I have to apologise for having had doubts about your advice regarding the lamp oscillator tuning requirement. I had hoped I could use daylight, flicker free illumination but the sun had set by the time I was able to start 'twiddling' again (primarily on account I wanted to dial back the lamp power to a less aggressive setting).

 I discovered, contrary to my expectations of a 5 foot 24W LED replacement tube rated to operate over universal mains voltage range (85 to 265 volts rms 50 and 60 Hz supplies), that it still suffered enough flicker (100Hz smoothing ripple?) to make tuning for minimum standard deviation an impossible task - indeed, the situation was even worse this time round.

 Once I realised that the room lighting was the cause, I switched it off and used a desk lamp instead, which, despite being blessed (or cursed) with a 1500Lm 100W equivalent LED bulb, seemed to eliminate the problem. However, for the critical adjustments I used a small cheap (simple 3 AAA cell resistor ballasted) LED torch with the desklamp pushed flat to the desk to attenuate its contribution. Thus at last was I able to achieve a standard deviation figure below 100 mV peaking to 140 odd mV every now and again, only this time falling back down to the 100mV mark as one might expect when those peaks are the result of a one off random excursion every now and again.

 The lamp voltage is now showing a reading of 5.37777 varying up to just over the 5.37805 volt mark some ten hours after this morning's restart. I expect it to top the 5.38000 volt mark by this evening if the previous trajectory holds true. It had actually risen above its hour or so post startup minimum by just over 10mV some 40 hours after the previous servicing and looked like it hadn't quite reached its peak even then when I started working on it last night.

 BTW, thanks for mentioning the FRK-L service manual. I DDGd it and downloaded a copy from here:

https://www.eserviceinfo.com/downloadsm/185194/EFRATOM_FRK-LServiceManual.html

 After that I found KO4BB's web site here and downloaded exactly the same manual (a shoot first, ask questions later download operation).

http://www.ko4bb.com/getsimple/

 I was so impressed with his well organised and easy to access collection of manuals and servicing guides, I made a $10 donation (something I rarely do) and decided to add him to Opera's speed dial list only to discover I already had (probably two or three years back) when I scrolled the search page down to access the empty "Add a Site..." speed dial box. No wonder that call sign seemed so familiar!

 Another thing to mention is that I've spent all day on and off due to "Real Life Events"(tm) intruding whilst writing this missive. In this case, sorting out a replacement flexi hose tap connection for our shower room wash basin mixer tap which had burst the evening before last.

 Luckily the XYL had noticed the event thinking the recently replaced toilet cistern valve had gotten stuck only to discover the floor awash with a quarter inch of water. Since she couldn't detect where it was coming from, she screamed for my assistance (my hobby room is a spare first floor bedroom and my hearing isn't what it once was).

 The leak in the rising main supply to the cold port of the tap, was cunningly hidden behind the wash basin pedestal, no wonder she couldn't spot the source straight away - it took a few precious seconds even for me to figure it out before grabbing the 5 pence coin we keep on the window ledge for just such emergencies (sufficient for the outside tap and the WC cistern isolation valves) but this particular valve, through lack of use, was just too stiff to be completely shut off with a 5 pence coin so I had to dash back upstairs to get a "Real Screwdriver"(tm) to shut it well and truly off, yet more precious seconds squandered before we could finally relax and take stock before mopping up the mess.

 The XYL wanted to do the week's shopping today and reminded me of my promise to get off my backside to actually order and collect the parts needed to restore normal service. With the cost of fuel going up so much, she wanted to maximise the benefit of taking the car off the drive for a shopping trip (and,no doubt, make damn sure I actually got hold of the parts to ensure I had no excuse for delaying the job any further on account "I had more important things to do"

 As it happened, I was glad to get that job out of the way so when we got back just after 5pm, I spent the next hour cursing the so called professional plumber for his bodgery whilst I replaced the offending flexi-hose fitting, completing the job just in time to avoid having to suffer a dried out tea.

 If you ever get the impression that It's taken me several hours to write up a reply, It probably has . Half a day in this particular case, thanks largely to real life events intruding a little more than they usually do.

[Johnny B Good]

@thinkfat

 It's been just over two months ago since my last posting and I've made some more progress with my RFS project in the interval which I feel is worth reporting on,

 The inexorable 1mV per day increase in lamp voltage had started to worry me sufficiently to pull it apart to retune the lamp exciter oscillator for a further reduction in the lamp voltage. The second retune exercise had resulted in my setting the lamp voltage to 5.4v which settled to a value of 5.40275 a day or two later which, from then on, kept rising at about a millivolt per day, reaching a value of 5.42720 four weeks later with no sign of it hitting a peak from where it would resume a slow decline of 1mV per week.

 At that point, I felt I needed to reduce the lamp excitation a little further to avoid accelerating lamp ageing so, for a third time, I took it apart and reduced it to a lamp voltage of 5.11065v 12 hours later. By then, I was mindful of the need to avoid troublesome frequencies (but ignorant of the specific target frequencies mentioned in the FRK servicing manual - I hadn't properly scrutinised it 'till today) so aimed for a minimum of standard deviation in the servo amplitude measurement and reassembled it.

 It still showed an increasing voltage with time but much less than the 1mV per day. It reached a peak of 5.11600 just over a week later where it's remained within 50uV ever since (it varies inversely with ambient temperature). Today's 1pm reading was 5.11630v which has increased to 5,11650v +/- 100uV depite the 4 degree rise of room temperature with the afternoon sun. It does look as though it's on the point of resuming its previous LVD curve which makes me feel a little happier since I felt I might pay for this "rejuvenation" effect with an accelerated ageing of the lamp and/or its excitation oscillator components.

I've not seen any more anomalous phase jumps since disabling the SBAS option. The only variations are back to those linked to a not quite perfect control of the baseplate temperature and the chilling effect of lower ambient temperatures on the rate of heat loss "via the backdoor" of the remaining 5 sides supposedly insulated against such thermal leakage.

 I had tried to compensate for this chill factor effect by compensation of the temperature set point but whilst the effect on the set point temperature is as expected over a range of ten or more degrees, there's an unexpected lumpiness in the resulting temperature readout for smaller 1 or 2 degree variations. As a result, I commented out the setpoint adjustment code and decided to use the chillfactor variable to negate its effect on frequency through the EFC pin via a spare PWM pin as per the barometric compensation.

 A 12 hour overnight run from 1 minute past midnight showed a very promising result but the subsequent daytime temperature variation (22 to 26 degrees) still exhibited a response. I rather think the problem is due to the much greater lag between ambient and its effect on the thermal mass of the whole (enclosure and its well insulated contents).

 Theoretically, holding the base plate at a constant temperature doesn't suffer such a lag, provided the base plate temperature controller can hold its own thermal lag close to a vanishingly small level (+/- 20mK in this case). I've been using my garage/workshop as an environmental test chamber to test my thermal management solutions.

 The night before last, I ran a test to determine the effect of ambient on frequency over a 9 degree drop and was able to estimate a 5uHz drop per K drop in ambient temperature to work out how much I needed to attenuate the PWM output to compensate for this chill factor which worked out to a voltage attenuation of 400:1.

 Tonight, I'll be repeating this test to verify or modify this choice of attenuation.The transfer from 1st floor hobby room to the outside garage/workshop (and back again) takes about a minute during which time I plug a 16 cell AA battery pack into whichever of the two DC input jacks is free before unplugging the 19v laptop charger (and vice versa at the destination) so as not to have to interrupt power to effect such transfers.

 I used to keep a laptop charger plugged into the mains supply at each end to effect a speedy transfer between battery and mains power until I realised that the small voltage variations (2 or 300mV) between laptop chargers was more important than I'd thought. The transfer process is a little more fraught now that I also have to include the laptop charger to eliminate this small variation in voltage so I've become a little more reluctant about running these test sessions.

 I'm planning on using a boost converter to supply the RFS with a reasonably stable 22 volts from any 19v laptop charger to eliminate this dependency on any particular laptop charger but that's a modification that's still sitting on the back burner - I need to do a little more testing before committing to such a modification and right now, my main concern is dealing with this ambient driven chill factor effect. I need to verify that I haven't applied too much compensation which will make the problem worse. When it comes to such indirect compensation measures too little is better than too much.

 The attached images show the screenshots I'd taken at 00:01 and 12:35 today.

[Johnny B Good]

 I think I've overlooked one important detail with my chillfactor compensation strategy (a form of feed forward error correction), namely that of the need to match the thermal time constant of this 'backdoor' heat energy transfer mechanism with a similar time constant applied to the forward error correction being fed into the EFC pin.

 At the moment, the indications do suggest that my 5uHz per degree guestimate is just about 'on the money'. It's just a pity that I hadn't given even the slightest thought whatsoever to compensate for this delay.

 At the moment, I'm simply using a 6:1 voltage divider (51 and 10 K) which feeds the 10M resistor link to the EFC pin (150K input impedance) which provides the additional 67:1 voltage division to make up the required 400:1 reduction from a 5 volt swing provided by a PWM pin to cover the designed 25*C range in 100mK steps of the chillfactor variable. With an upper ambient limit effectively set to 32*C, the bottom end of the chillfactor control range is 7*C, safely below 10*C and some 11 degrees below the typical "23 deg +/- 5 deg" ambient temperature range specified for most test gear.

 In this case, my "gut feeling"(tm) is that this thermal time constant is somewhere between a half hour and two hours. Fortunately, due to the use of a 10M resistor, this can be achieved using a 1500 (typically 1800) uF capacitor connected between ground and the junction of the two 5M resistors in series substitute for the single 10M creating an R value of 2.5M in the RC calculation which gives me a TC value somewhere between just over an hour to an hour and 15 minutes which seems as good a starting point as any.

 Swapping out the 10M for two 5M in series with its centre tap connected to a cap seemed the simplest way to get the ball rolling with regard to finding an optimal RC time constant but I've decided that I may as well 'go for broke' by replacing the 51K, 10K and 10M resistors with a single centre tapped string of six 10M resistors instead (400:1 reduction in one go) to maximise the effective R value to 15M in the TC equation which will extend the capacitor values down to a more manageable 120uF for a 30 minute TC, scaling up 470uF for a two hour TC.

 Once I've completed this mod, I'll run a pair of wires via the exhaust vent to a solderless breadboard into which I can conveniently try various values of capacitance before finally soldering the selected cap into the circuit.

 I'd had enough trouble soldering a string four 1206 10M resistors in series for the barometric compensation circuit so I'll be going to the trouble of assembling a centre tapped 60M 'special' onto a narrow strip of perf board in this case and, while I'm at it, replace the existing 40M one in the baro compensation circuit with a similarly constructed (no centre tap) version. It could be some time before I'm ready to report any further progress with this now two year long project.

[Johnny B Good]

I've been meaning to follow up with an update for almost a year now but kept putting it off. To those of you waiting with bated breath, my humble apologies.

 To cut to the chase, that forward error correction of the chilling effect of very low ambient temperature conditions by applying a frequency compensation voltage to the C pin went by the wayside a few months back to be replaced with a servo controlled heatsink cooling air exhaust flow diverter valve to transition from direct exhaust at high ambient temperature to total recirculation back to the intake plenum at extremely low ambient temperature. "How low is extreme?", you may well ask. Well, the answer to that is yet to be determined but hopefully anywhere from 16 degrees down to freezing.

 The issues with adding a CR time constant delay to match the thermal delay were twofold. The first being to choose the optimum value capacitor to connect to the mid point of  a string of half a dozen 10M resistors chosen to provide the required Hi-Z attenuation all in one lump to keep the required capacitor to its lowest possible value.

 This proved rather more tricky to achieve than I'd anticipated because my estimated thermal time constant seemed more likely derived from 3 to 4 time constant's worth of observed delay. Also, aside from the fiddly business of temporarily connecting candidate caps, there was also the protracted delay before the circuit settled down before each test could be run.

 The second issue (and final straw) being that of Dielectric Absorption (DA) at which point I started a hunt for a simple software algorithm alternative completely devoid of the DA issue. It took some time but I did eventually unearth a ridiculously simple "one liner" solution and incorporate it. However, even though trying different time constants had been simplified to editing a single constant in the sketch and initialising the start condition to eliminate the "settling" delay at each restart, I still couldn't determine an optimum to counter the real time thermal delay, so I finally gave up on that doomed strategy, turning instead to the more promising 'air conditioning solution' by exhaust heat flow venting control. A more promising solution since it's always better to compensate the primary cause of an error rather than through its secondary effect.

 As for the 6 x 10 M resistor attenuator mod, that got reverted so no need to fabricate a 60M centre tapped resistor string nor, as it turned out, any need to modify the existing 4 x 10 M directly mounted on the matrix PCB  since they were already nicely secured in place.

 The air recirculation technique has proved to be an effective solution to compensating the chilling effect of very low ambient temperature extremes, getting better with each new improvement of adc precision, first by doubling the nano's 10bit adc sampling rate and oversampling by 64 to get an extra 3 bits of resolution, followed by replacing it with with an ADS1115 external 16 bit I2C module.

 I'm still fine tuning it but hope soon to be able to post a complete description of the finished project which I think would be of interest to anyone looking for a cost effective alternative to a cheap working example of a cesium beam atomic reference (aka Unicorn droppings) that they still can't justify the expense.of.

 BTW, I've just added three photos of the panel display, one "before" and two "afters"

[EDIT 2024-04-16]  I've added my latest picture of the display by way of a "teaser". I'm now displaying temperature to three decimal places because I now need to be able to monitor them in milli-Kelvins since I've, at long last, achieved the 4 to 30 degree ambient range of control of the base plate temperature to within +/- 5 milli-Kelvins of its set point (36.05 deg C).

Unfortunately, I'm now painfully aware of an intermittent 1ns phase wobble in the ruby's output which means I'll have to make up a test connector adapter board to break out the 10MHz output and power input connections in order to do "open heart surgery" on it.

 To save having to wire up a trimming resistor to this adapter, I'll simply make use of my much modified FY6600-60M to act as a μHz tunable proxy of the ruby's frequency output fed to the external reference socket I'd added a couple of years ago shortly after doing the OCXO upgrade.

 I do have an SDG2042X but its (advertised) 1μHz tuning steps are limited to (an unmentioned) less than 100KHz limit making it woefully inadequate for such a task. 

 Since the problem looks like a dry joint or one or both of those pesky 100K 0603 smd resistors (R705 and R729) mounted on the underside of the PCB beneath the physics package, I'll hopefully be able to remedy this issue without too much difficulty.

[EDIT 2024-05-29]  I did check out those 'usual suspects' but they seemed totally innocent of any crime. However, I did notice how touchy the 20MHz crystal oscillator section was to vibration testing in that corner of the main pcb, even unsoldering the TO 5 crystal to reseat it more flush to the board. It made no difference and I noticed that even gently appllied firm pressure on the crystal and the board would induce transient phase shifts which when suddenly applied or suddenly released, could cause a loss of lock. I figured it was just the nature of this setup so gave up doing anything else since these symptoms didn't tally with an intermittent connection of any sort.

 The only other thing I'd tried was repositioning the lamp in its housing to improve the lamp voltage output. However, since I hadn't seen the expected improvement and worried that I may have adjusted it too close to the glass, I opened it up again to make sure I hadn't 'overcooked' my adjustment only to discover that the locknut had either worked loose or (more likely) not been tightened up properly. Taking care to ensure the lamp had sufficient clearance from the front glass, I tightened the locking ring with rather more torque, only too painfully aware that I had to avoid transferring too much stress to its mountings with the board.

 The result of all this fettling didn't seem to have made any improvement initially, but during the following weeks, this weird nanosecond sized wobble seems to have completely faded away, leaving me to concentrate onthe temperature control algorithm and a belated discovery that the classic simple open drain PWM drive circuit, so effective with resistive loads (LEDs) just doesn't cut it when it comes to controlling the speed of a 2 phase BLDC cooling fan motor (PC cooling fan).

 Converting the 10 bit value of 61 that I had determined to be the minimum to prevent the fan stalling when fed off its 18.3v supply into a motor voltage, I was bemused to see that this actually equated to just 1.1v which is about a third of the actual minimum requirement for this 12v fan. Indeed, bench testing with another identical fan showed that the minimum was a little higher at 3.75v. Only then did I realise the "Peak hold" effect the capacitor used on the fan's motor pcb was having in magnifying the PWM to motor voltage conversion.

 The only way to minimise this undesired effect is to replace the power fet with a proper half H bridge circuit. I considered making one up but the additional complexity of incorporating 'dead time' to prevent "shoot through" during switching transitions put paid to that idea. In the end, I simply ordered a DRV8871 H-Bridge module from Ebay and used it as a half H bridge which is all that's required (desired!) when driving a DC motor that can only run in one direction anyway.  I very much doubt there's any reverse polarity protection circuit built into these cooling fans since that's the job of the industry standard polarised connectors used by these fan coolers. In this case using the full H-Bridge connection could so easily end in tears.

 The upshot of this fan drive upgrade being that my new 10 bit PWM minimum is now where it should be, 218 giving me over a threefold improvement in control resolution ( 0.5% versus 1.67% per incremental step of the original open drain FET) at this end of the control range. The stability of the base plate temperature has been much improved, particularly at the low ambient extreme of 12 degC (so far since the upgrade) right up to around the 32 deg C mark.

 I've also made some changes to the displayed readings shown by the oled display panel. I've attached a couple of photos (taken one second apart - oled refresh rate) to compare against the previous ones.