I just bought an Efratom 100318

[edpalmer42]

I am finding the module works from 18 volts and doing so will significantly reduce power consumption without anything negative.  I would think heat generation will be less as well.  (Yes, I know I'm just shifting where the heat will come from, power supply or rubidium module)

What you should see is that as you reduce the voltage, the current stays constant.  Then you reach a point where the current starts to drop.  This is the point where the internal voltage regulator is no longer able to regulate the voltage.  Increase the voltage back to the stable point, and keep increasing to give the circuit at least a few volts of headroom.  If you run too close to the dropout voltage, you may end up with lots of 120 Hz noise on the output.

Ed

[Johnny10]

At 18 volts aren't you going to starve the circuit for power at start-up?

Unit needs minimum 22 v at start-up through regulator.
After lamp ignition unit self-regulates power to 17V.

A couple of volts for regulator consumption thus minimum 24V as stated in specs.

[tkamiya]

A very kind gentleman sent me a case that goes with CTS series and along it, came a PC board with buffers.  Onboard this buffer board is a DC/DC converter and a circuit to make LED status output an open-collector.  This thing is huge....  but quite useful.

One thing I found out is, this case relaxes power source requirement from 1mv P-P noise to 100mv P-P.  As a result, I was able to use a switching power supply I happened to have on-hand.

Added a green LED for locking status. 

I changed my plan quite a bit from inception of my project.  But for this and at this stage, an only thing I have left is calibration.

Thanks an anonymous (well, I know who it is... but I don't have his OK to disclose his name) gentleman!

[texaspyro]

On the lock monitor circuit, a simple one transistor TTL inverter circuit driving a LED will work fine - I think I read somewhere it does need to be a high impedance, like 20K or higher as to not load the lock circuit, and switching transistor will work, 2N2222, 2N3904, etc.

A lot of Rb lock monitor outputs are open-collector transistor outputs.

[tkamiya]

Mine is open-collector when combined with a factory buffer board.  (as implemented)
Without, it's a TTL output.  (reverse logic)

As to my heatsink, it has a lot to do with availability.  Plus, factory manual says about maximum bottom plate temperature but not minimum.  My understanding is, parts that needs to become hot is well insulated.  Cooling is for electronics around these hot components.  I just tweaked frequency using a trim pot accessible though base plate. 

Factory manual says maximum ripple is 100vm p-p.  (with buffer board)
Without, it's 1mv p-p.  I covered this in my earlier post.  I'll see what output looks like tomorrow via Spec Analyzer.  If it is modulated, it should show in 10Hz bandwith view.

[tkamiya]

I guess I'm not done, yet.

Today, I decided stacking approach isn't going to work for me.  So I arranged power supply and Rb with outer case and buffer board horizontally.  It works fine on my bench.  It doesn't work when I put it on shelf.  Take it down to bench and it doesn't work now.  Open it up and jiggle few things and enclose it.  It works on bench but not on shelf.  When it doesn't work, I get output but it never locks.

I took it apart again and opened it up.  Inside case is awfully hot on top side, while heatsink is relatively cool.  Now I am keeping it outside the case, no buffer board, and wire directly to the weird coax in the middle pin outside connector.  Powered from bench supply.

NOW IT WORKS!  I spent all day playing with this.

Good thing is, the real module works but all that nicety the buffer board and outer (military spec) casing does not, or it appears to be.  I'm awfully suspicious of 12 pin header connector that joins the module and the buffer board.  Both are rigidly soldered, and alignment can't possibly be precise and accurate.  In fact, I can see the outer case deform when bolting everything up.

At this point, I don't need any advice.  I'm just documenting this for sake of completing my project and sharing.

[Johnny10]

Another method of checking these units for correct lock signal is to open case and connect oscilloscope to TP1.


This is signal on 7104 scope with Fast Acquisition enabled.

[tkamiya]

Nice Scope!

[testpoint1]

the FRS is quite old clock, it uses dip component, LPRO-101 used SMT, and I tested more than 70 pcs LPRO, please keep the working temperature within 20-50C (manual said it is -25 ~+70) after one hour power on, I made a house for the LPRO by machine, I will release the cheapest and most accurate Rb clock (all calibrated, 1E-11 stability) then.

[Theboel]

Hello everybody,

Is there any one know what optimum temperature for Rb clock and where exactly to measure it ?

[tkamiya]

Which make and model do you have?

I've been researching that very information for Efratom C and Stanford Research PRS-10.  I am not having an easy time.  There are two kinds of data.  1)  What people say on Internet.  2)  What manufacturers say on their manuals.

As far as 1 is concerned, there are three groups of people.
People who think lower is better
People who think higher is better
People who think there is a particular temp or range of temp

As far as 2 is concerned, it really depends on manufacturer.
Efrratom (c) says base temperature needs to be in certain range.  I don't recall the figure but it's clearly stated in user's manual.  They don't seem to care about any other location.  I have 3 commercially made frequency standard by Efratom/Bell.  They all settle warm to touch. 

SRS for PRS-10 is more complicated.  There is a lamp temperature, Xtal oven temperature, case temperature, and base templature.  Case temperature is measured somewhere between the Rb lamp and the base plate.  For many of them, they specify the set point.  (a given value) and some are only decided after the unit goes through calibration at factory.  What this value is, is stored in internal memory which you can read.  Case temperature seems to be what they are mainly concerned with, and manual says it will be somewhere between ambient (room) and case temperature.  It doesn't say what it should be though.  I have a service request sent into SRS to find out the official data. 

My data is all over the place.  Small heatsink, larger heatsink, and small heatsink with fan has been tried.  It tends to settle somewhere between 60 degrees C and 70 something degrees C.  It's quite hot to touch.  Since SRS doesn't say what it should be, I have no idea if this is good or bad.

Oh, one more thing.  One of the manuals say life span of your Rb module depends on temperature.  Higher the shorter, lower the longer.

[Theboel]

Hello tkamiya,
I have "bare" PRS-10, SR-625, LPRO 10, X72, FEI 5680A

[tkamiya]

Very nice collection!  If I find out anything more about PRS-10, I'll post it here.

SR625 is a complete product.  I really don't think you need to worry about that one.  For everything else, did you go through user manuals?  I can say PRS-10 manual is incomplete.  I don't have anything else you have.

[testpoint1]

I think you need a Cesium standard to calibrate your Rubidium clock, since your collection seems is quite old, X72 also need new firmware then can be trained by 1pps signal.

[tkamiya]

I agree....  I NEED a Cesium oscillator.

[testpoint1]

Hello tkamiya,
I have "bare" PRS-10, SR-625, LPRO 10, X72, FEI 5680A

Hi, what about the internal oscillator of SR-625 ?

[ArthurDent]

My main Rb standard is a modified surplus unit and uses a Ball (Efratom) FRK-HLN Rb unit made in 1993 so it’s over a quarter of a century old. The ‘H’ stands for high stability and the ‘LN’ stands for low noise. I added a 10Mhz to 1Ghz multiplier that I found handy for checking the ‘C’ inputs on high frequency counters. I also added a small fan to move some heat out of the box and it is very quiet. The two sides of the case are also heatsinks to help dissipate the generated heat. The built-in distribution amp gives good clean multiple outputs.  The internal supply is a SMPS that I’ve had no problems with.

I have a second 10Mhz standard with 4 well filtered outputs. This was a quartz standard that I grafted a LPRO-101 into. The Rb unit was telco surplus with not much time on it, locks fast, and is quite stable. The adjustment I use on a lot of standards to get high resolution is to use a pot with a resistor in parallel that gives a much smoother and finer adjustment. I also use two stable resistors, one on each end of the pot to get even more resolution. The values aren’t that critical and depend on the oscillator you’re using. I set the 10-turn pot to half way then use the internal adjustment to adjust the warmed up standard to 10Mhz. I generally use 1% resistors I have several of. In the Quartzlock unit I used a 4.64K on each end of a 2K 10-turn pot with a 200 ohm resistor across the pot.  The SMPS is external to this unit. The photos should pretty much illustrate what I have described.

[Johnny B Good]

Hi Arthur,

 I've been pondering whether I should reply to what is now a 29 month old posting over the past two or three months since I revisited this topic thread for the lack of more current threads on the subject of rubidium frequency standards.

 I'd bought my own Efratom LPRO-101 the August before last and have been developing a thermally stabilised and barometrically compensated Rubidium standard ever since. I finally reached the stage where it is now housed in a custom built enclosure since about a month ago and have been fine tuning the base plate fan cooling based thermal control algorithms ever since.

 I've been able to stabilise the base plate to a 36.1*C set point temperature to within +/- 0.1*C but I'm still seeing what seems to be a diurnal effect which I'm beginning to think may be due to infrared heat leakage which seems to be more of an issue than I'd originally thought it might be. I'm now looking to purchasing a roll of IR heat shield tape and a tube of Autosol to polish the aluminium case panels to a bright mirror finish to address this "Gotcha".

 Anyway, all that aside, the thing that's been bugging me about your post is the bit about padding the ten turn adjustment pot using three 0.1% low tempco resistors. In this case, with the useful feature of these Efratom/Ball/Datum LPRO-101's internal trim pot adjustment and external EFC connection, the (only now! ) blindingly obvious solution to getting very tine tuning control from a ten turn pot (+/- 1ppb in my case) is simply to connect the pot directly  across your low tempco 5 v supply and wire the slider terminal to the EFC pin via a 3.3M resistor to take full advantage of that internal 10 turn trimpot to set the external pot midway and trim as close as possible to the 10MHz just as you described.

 You had all the pieces of this "simplification" puzzle to hand so it wouldn't surprise me if you'd already experienced this particular epiphany at some time over the past 29 months.    I'd had mine only about 3 or 4 months ago.

   I've raised this point just in case you hadn't and also for the benefit of anyone interested in achieving such fine tuning control of an LPRO-101 or similar rubidium reference using nothing more than a 5 or 10K ten turn pot (or whatever ten turn pot you have to hand in the 1K to 100K range - exact value isn't critical) and a 3,3M or so resistor (also tolerance not critical).

 The beauty of this circuit being the elimination of expensive resistors and simplifying the desired amount of trimming range by changing the resistance value of only a single inexpensive resistor.

 I'm planning on creating a new topic thread describing my current RFS project once I have completed it (I still have to investigate, and hopefully fix, my suspected IR problem). In the meantime, I'm attaching four images to give a glimpse of the project. I've posted several photos in another rubidium oscillator related thread, linked to below.

https://www.eevblog.com/forum/metrology/gnss-rb-(chinese)/msg3999667/#msg3999667

[Johnny B Good]

Wow! That was a bloody fast response to all your eevblog notification emails! At least four visits (aside from my own) in the space of just 5 minutes.

[Johnny B Good]

 Well, this time it's only been a mere 13 1/2 months since my last post

 I've not been idle during that time although the project did suffer a 5 month hiatus due to a computer hardware and OS upgrade exercise that had been bedeviled by several issues.

 I'd refined the temperature algorithm to the limits of the Arduino nano's 10 bit adc (and then some!), doubling the adc's sampling rate to 19 Ksps, oversampling that by 64 to gain an extra "3 bits" of resolution, increasing the SSD1306 display's I2C speed from 100K to 800K to increase the polling frequency from a lethargic 2.4Hz to a more responsive 12.5Hz before caving in to the need of a better adc almost a fortnight ago.

 Initial tests with the ADS1115 4ch 16 bit I2C module with my bread-boarded "Flight Spare" weren't very encouraging (11.6Hz cycle time and almost as 'noisy' a temperature display). However after closer inspection of its datasheet I realised that I'd chosen too high a sample rate (860sps) in a futile attempt to shorten the cycle time (the bottleneck on speed still being that damned SSD1306). Even 475sps was too noisy an option so I chose the 250sps for minimal acceptable noise without sacrificing too much by way of speed.

 That modification made a significant improvement in stability. Although the result looked noticeably calmer, I felt it could still do with further improvement so I tested the 2.048v FRS option over the 4.096v option I'd initially chosen to be safe with the use of a TL431 to provide a 2.5v Vinput to the thermistor/resistor circuit. This worked as expected, no change in base plate temperature readout yet an even more impressive calming effect on the stability of the readings.

 However, all is not quite as perfect as I'd like over my target ambient temperature range (15 to 30 deg C) and so I feel there is yet still room for further improvement.
One obvious change I made, some 7 or 8 months back now, was to the display. Concerned about oled fade due to the 24/7 operation, I decided to invert it to black characters on a white background with the brightness setting reduced to its minimum usable level where the effect would become less obvious (and, incidentally, help even up the wear already incurred). I've attached a couple of photos, along with an earlier attached photo for comparison for review (and possible comments on the change).

[Johnny B Good]

 I've made yet more progress with my rubidium frequency reference project over the past seven months.  I really need to fabricate a barometric test chamber to fine tune the barometric compensation algorithm. One that can cover a modest +/- 25mBar range and maintain it to within 0.5mBar during settled weather conditions over time periods of a couple of hours or so. Any ideas on how to cheaply fabricate one?

 Anyway, I thought it might be of some interest to demonstrate the improvements reflected by the need to now display temperature readings to three decimal places (one milli Kelvin resolution). The attached images represent a short 25 seconds long sequence.

 You'll notice one other change, namely the renaming of the "Ambient temperature" readout label to "Plenum temperature". It's from the BMP280 sensor as before - I've simply moved its location from the mouth of the intake vent to in front of the fan intake within the induction plenum chamber. This now controls a set of servo driven flap diverter valves to transition between direct exhaust and total internal recirculation over a 1 degree range centered currently on 31 deg C. I may raise this another degree since once the flow diverter valves have "battened down the hatches" so to speak at an ambient around the 17 degrees mark, this gives me a more stable fan intake temperature which then falls at a steady 100mK per 1K drop in ambient temperature below that transition point.

 Trying to maintain temperature control with an 80mm CPU cooling fan being fed directly with raw ambient air below 18 deg is just not possible without resorting to shutting it off and then kick starting when it needs to provide a minimal level of cooling without introducing the Spectre of under and overshooting the target base plate temperature. This "Air Conditioning" of the fan intake plenum worked wonders for temperature control of the base plate over an ambient ranging from 10 to 28 degrees.

 I could go on at length about this project but I think it best to save it for a separate thread on the "completed' project at a later date. In the meantime, you can admire my efforts thus far as demonstrated in the attached pictures.

P.S  I've added 4 screenshots of the Arduino serial plots of base plate temperature (a sequence of 6.4 second windows). The vertical scale is milli Kelvins referenced to a 36.000 degrees base line. There are 500 points per window. The control loop is now running at just over 78Hz. The "spikes" have been introduced every 498 th plot to suppress the counterproductive re-scaling that Arduino had cursed their serial plotter feature with (ver 1.8.19 - the ver 2.x.xx plotter is even more useless!).

 Without these "spikes" the vertical scaling would be dancing an epileptic jig, defeating the whole point of graphing data in the first place One good side effect of adding these pulse pairs (0 and 120) being that it allows a simple way to measure the control loop speed by timing each pass through a chosen X axis reference point with a stopwatch (6.4s per pass for a quick 'n dirty check or 64s for ten passes to obtain a more accurate measure).

PPS added three DSO screenshots to illustrate the whole point of this rather protracted project. The first is from midnight the 2nd at 08:09 and the final taken a few minutes ago at 18:00. The DSO (an SDS1202X-E btw) was set to infinite persistence as it has been for the past few years I've had it running 24/7 to monitor the phase drift between the MK II gpsdo and the rubidium reference. CH1 (yellow trace) is triggered by the gpsdo with the ruby on CH2.

 The majority of the persistence is being painted by the 20ns diurnal wander of an M8T based G3RUH type gpsdo fed from a multi frequency GNSS/RTK antenna mounted with a clear all round view of the sky. This diurnal phase wander rather muddies the waters when it comes to syntonising the ruby to the atomic clocks world time reference/ frequency standard making it rather difficult to test the efficacy of my attempts to stabilise it against variations of both ambient temperature and barometric pressure. However, I do hope to reduce this effect by completing a MK III using a ZED9T gnss receiver module I'd purchased just over a year ago.

 Damn EEVBLOG's 10 file attachment limit !  I've had to drop the first photo of the ruby's oled display.