Eevblog #235 - Rubidium Frequency Standard

[Rerouter]

amspire, because you are higher up, time actually would move slower for you , but thats only from the point of referance of someone looking at you from the ground,

i wonder what a gps corrected rubidium reference would be like... near atomic clock.. or just another magnitude,

[king.oslo]

Rerouter, you are too clever for us man

Yet Richard has a big problem. He will still arrive late to meetings. And whenever he phones somebody, it will be late. I think he needs an altitude- and space-based-interferometer-corrected-clock. I hear NASA is building one. Perhaps he can get a subscription?

"Pick one up"

[amspire]

amspire, because you are higher up, time actually would move slower for you , but thats only from the point of referance of someone looking at you from the ground,

I got the sign wrong? Are you telling me that when I thought I wave been arriving at meetings early, I have actually been turning up late by at least a few picoseconds?

I am devastated.

[TerminalJack505]

I hope that those of you who planned on getting one (or more) of these already have.  The ebay sellers have doubled their prices since Dave's video first came out.  I remember seeing several sellers charging just 35 or 40 bucks.  Those same sellers are now charging $80.  You can look at the sell history to confirm this.

[grumpydoc]

Yes, it's pretty annoying as I was going to pick one up. Think I'll wait and see if they drop back down again.

[wkb]

I hope that those of you who planned on getting one (or more) of these already have.  The ebay sellers have doubled their prices since Dave's video first came out.  I remember seeing several sellers charging just 35 or 40 bucks.  Those same sellers are now charging $80.  You can look at the sell history to confirm this.

Holy cow... Just checked that, I bought my 2nd Rb from the seller now offering one http://www.ebay.com/itm/250967728839?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649#ht_2555wt_1210.

Small difference: I paid $ 35,88 and $ 9,99 shipping to NL.

Other than the price increase, I do recommend this seller, very friendly contact etc.

[McMonster]

Hopefully by the time I really decide it's worth (read as "it'll make a significant difference for some application I'll be working on") the prices will greatly drop so I could get one.

It's interesting how much influence EEVblog has on the hobby market. Parts' and devices' price, availability on online auctions and hobby-oriented buisnesses, interest in EEVblog's products like uCurrent and uSupply etc.

[Bored@Work]

Just wait until all the kids who now bought one "because Dave said so" will resell them, because they have no use for it.

[TerminalJack505]

Just wait until all the kids who now bought one "because Dave said so" will resell them, because they have no use for it.

LOL.  I was nearly one of those 'kids.'  I could almost justify (in my own mind) buying one when they were $35.  Now...not so much.

I hope Dave is getting some kind of kickback from these guys.

[McMonster]

Just wait until all the kids who now bought one "because Dave said so" will resell them, because they have no use for it.

I just hope they'll ship to Poland.

[scopeman]

I offered a seller 38.00 each if he would sell me 10 units. He agreed then reneged on the deal only promising to sell me 5 units at that price, claiming that he had "less stock" than he said that he had. I got my 5 but I'll bet that he still has tons of them.

Mine has the standard pin out (+15 Pin 1, Gnd Pin2, Lock Pin 3, +5V Pin4, Gnd Pin 5, 1pps Pin 6,
Pin 7 10MHz, Pin 8 RX IN, Pin 9 TX Out ) and the RS-232 that I can trace the input RX data signal with a scope  all the way to the control micro but I can not get the unit to respond to serial commands.

Anyone who has any ideas please pipe up!

Thanks,

Sam

[wkb]

I offered a seller 38.00 each if he would sell me 10 units. He agreed then reneged on the deal only promising to sell me 5 units at that price, claiming that he had "less stock" than he said that he had. I got my 5 but I'll bet that he still has tons of them.

Mine has the standard pin out (+15 Pin 1, Gnd Pin2, Lock Pin 3, +5V Pin4, Gnd Pin 5, 1pps Pin 6,
Pin 7 10MHz, Pin 8 RX IN, Pin 9 TX Out ) and the RS-232 that I can trace the input RX data signal with a scope  all the way to the control micro but I can not get the unit to respond to serial commands.

Anyone who has any ideas please pipe up!

Thanks,

Sam

Serial commands as in setting the output frequency to something radically different from 10MHz, like 5MHz for example? 

Sounds like you have the non-settable variant (like I do) which only allows you to adjust the 10.0000000 <whatever>MHz in the mHz range.  The Rb units look the same but have different electronics.  The el-cheapo like you seem to have and I definitely have do not have the wide-range DDS with serial interface control.  The el-cheapo's do not respond to the commands the wide-range DDS units do.

Go and Google and you will find tons of sites explaining this.

[wkb]

While looking into GPS NTP reference appliances for a data center I just stumbled on this one:

http://www.symmetricom.com/media/files/downloads/product-datasheets/PB_SA_32m.pdf

Really neat if you ask me...

[@rt]

Hi Guys,
I know it’s an old topic, but I was watching this video on Rb standard, and the accuracy of a range of crystal oscillators.
Also another video about a program Dave wrote to test drift of crystal oscillators for some underwater project.

I find this difficult to relate to practical terms because how would you know if a crystal would drift one way or another?
I know there are watch crystals made so you can count till the overflow of a 16 bit timer, and that’s a second,
and those are probably cut more accurate.

Say you had a typical even MHz frequency crystal say 4 - 20 MHz, that was TTL buffered and divided down so you
could flash an LED at 1 Hz, and you also had a Rb frequency standard or GPS PPS output connected to an LED right next
to the 1 Hz crystal LED, and they were aligned perfectly to the clock cycle.
How long would it take before you could notice any drift between the two LEDs just from a Human looking at them?

[Dave]

I find this difficult to relate to practical terms because how would you know if a crystal would drift one way or another?

You find a much more stable and accurate frequency source and use it as a reference for your frequency counter. You connect the observed oscillator to the input and log the measured values.
That would be one way to do it.

I know there are watch crystals made so you can count till the overflow of a 16 bit timer, and that’s a second,
and those are probably cut more accurate.

Nope. Watch crystals are usually 32.768kHz, so 2^15 Hz.

Say you had a typical even MHz frequency crystal say 4 - 20 MHz, that was TTL buffered and divided down so you
could flash an LED at 1 Hz, and you also had a Rb frequency standard or GPS PPS output connected to an LED right next
to the 1 Hz crystal LED, and they were aligned perfectly to the clock cycle.
How long would it take before you could notice any drift between the two LEDs just from a Human looking at them?

Good crystals usually have about 20 ppm accuracy. Assuming you would be able to notice when LEDs are at least 1/20 of a second apart and assuming the worst case scenario (crystal being off by 20ppm), it would take 2500 seconds for you to notice it (roughly 42 minutes). Of course, varying temperature, vibration, shock and shitty crystals might give significantly worse results.

[max666]

While looking into GPS NTP reference appliances for a data center I just stumbled on this one:

http://www.symmetricom.com/media/files/downloads/product-datasheets/PB_SA_32m.pdf

Really neat if you ask me...

Link doesn't work, and man does that site annoy me.

[Vgkid]

Google symmetricom sa.32

[max666]

Google symmetricom sa.32

Thanks, that helped.

I was looking if an enthusiast could buy them, but the only thing I found was this (I'm probably doing it wrong):
http://www.ebay.com/itm/Symmetricom-SA-31m-Miniature-Rubidium-Oscillator-090-44310-01-W-Interface-Cables-/231560038309?pt=LH_DefaultDomain_0&hash=item35ea0dc7a5
I wonder how much they cost new.

[Johnny B Good]

 I'm only six years late to this party but I thought I'd add my two cent's worth to give a new perspective on these Efratom/Symmetricom/Datum LPRO and derivative ROs 

 I've looked at the Symmetricom SA22C datasheet and, afaics, it's basically a stretched low phase noise LPRO101 with a few extra 'bells and whistles'. Unless the low phase noise feature is a must have, the good old LPRO101 can serve as a decent lab standard that can stay within 30ns of a decent GPSDO over a 24 hour period if properly thermally stabilised and barometrically compensated.

 I've been testing the frequency stability of an Efratom LPRO101 when thermally managed to keep the baseplate at a fixed 36 deg C +/- 0.2 deg or better over the past month and would typically see less than 50ns drift in 24 hour test runs using a breadboarded analogue temperature controller lash up as per the attached photos,

 Since I started experimenting with an Arduino based alternative to the rather fragile analogue breadboard lash up just a fortnight ago, I'm now typically seeing 24 hour phase drift rates down to 30ns and lower (after fixing a fan load current interaction with the common zero volt rail that was reducing the Vcc rail by some 10 to 20mV every time it fired up).

 As you can observe in the photos, the Arduino lash up is also suffering a modicum of "Solderless Breadboarditus". Considering this impediment, the improvement in frequency stability in both setups over the "Let's attach it to a BFO heatsink and just hope for the best" school of DIY engineering configurations that I had initially used and still see being employed by other electronics enthusiasts who've published their efforts in blogs or YT videos, is quite remarkable.

 What's even more remarkable is that I still have a few more refinements to add (like a properly vented customised enclosure with room for yet more polystyrene foam insulation for one ) which should provide even more stability, easing the task of a GPS add on to just compensating the ageing drift with daily (if required) recalibration adjustments. It's not so much a matter of 'disciplining' as 'gently teasing' my embryonic GPSDRO to stay within 10ns or so of phase with the GPS atomic time reference.

 That's my ultimate goal and the results so far, all things considered, have been very encouraging. So much so, that when I came across this topic thread which doesn't seem to have totally expired, I thought I'd post my results with a few images, which I think will be of some interest here and maybe breathe new life into this topic. 

  BTW, the final photo is to satisfy the curiosity of anyone observant enough to have spotted the anomalous mBar readout just visible in the SSD1306 display in the bench set up photo. I only noticed this while I was taking the photographs. I think it may have hung over 24 hours earlier. Fortunately, I'm only displaying the barometer readings from the BMP280 and discarding its temperature data.

 The temperature correctly being displayed comes from the 56K@20^C thermistor that's embedded in the quarter inch thick aluminium heat spreader attached to the LPRO's baseplate onto which the fan cooled heatsink is attached (the 'meat in the sandwich so to speak). I'd concocted a Frankensketch combining a thermistor temperature sketch and a BMP280 with SSD1306 display sketch.

 I'm a newbie as far as the Arduino IDE is concerned but it's not my first experience in writing real time control algorithms, an experience which harks back to the days of Z80 assembler some forty years ago.

 The fact that the BMP280 seems to have locked up is a little worrying since I plan on eventually using the pressure data to provide barometric compensation and utilise the temperature data to control the power setting of the fan against variations in ambient temperature to refine the on/off control algorithm to minimise the upward drift of the average temperature around the set point that arises from increasingly higher ambient temperatures.

 I did consider a PID controlling algorithm to minimise the under and overshoot effect of the simple on/off control of the fan I'm currently using but it struck me that all I really needed was some means to tune the fan speed to match the ambient temperature conditions - minimum speed at the lowest ambient limit and full speed close to the maximum rated ambient temperature limit.

 I figured this would likely be superior to using a complex PID algorithm in view of the very long thermal time constant involved where a 30 to 40 seconds cycling of temperature by +/-0.2^C around a targeted average would be more than sufficient in this case, provided the ambient temperature didn't significantly shift the average temperature too far from the set point. However, I have yet to add this embellishment to my Frankensketch so it remains untested for the time being until I've figured out how best to incorporate it into the existing code.

 As well as being an Arduino newbie, it seems I'm also on my own in pursuing precision control over a Rubidium oscillator's baseplate temperature since I've not been able to find any published results by others of similar experiments with Rb oscillators on the interweb.

 Anyway, that's my 2 cent's worth (for what it's worth!) 

[Johnny B Good]

 I've noted the interest in those photos and screenshots I'd attached to my previous post, so to satisfy everyone's curiosity, here's some more of the same (at the end of this post).

 My GPSDRO project is still a work in progress but I have made some (progress, that is!). I've modified that frankensketch into more a work of my own. I've added ambient temperature cooling compensation to reduce overshoot (and the consequential undershoot), modified the temperature control algorithm so it now detects when the temperature starts responding to the fan's cooling effect and shuts it off without having to wait for the temperature to drop below the set threshold as it did in the original sketch which mitigates the undershoot effect considerably.

 The temperature now varies over a much smaller range, circa 0.15 *C typically, versus the 0.35 *C of the original frankensketch, still a little dependent on the ambient temperature (ambient compensation isn't perfectly tuned right now) and it still spends a little more time below than above the set point. There's little point in fine tuning everything anyway at this stage until it's finally boxed up in a properly ducted and insulated enclosure.

 I replaced that bi-colour oled with a single colour version (I'd purchased two white oleds from banggood). Unfortunately, I blew the rice grain sized 3.3v LDO on the first one I'd tried due to ASS-U-ME effect (I'd made the mistake of assuming it was a direct drop in replacement without verifying that the Vcc and GND connection placements matched ).

 Luckily, said LDO had 'thrown itself upon this particular hand grenade' that I'd thrown at it and I was able to (snugly) fit a slightly larger one (extracted from yet another piece of my collection of salvaged parts) in its place. This now displays both ambient and baseplate temperatures as well as absolute barometric pressure.

 Despite the improved temperature control, I was still seeing an increasing need to calibrate its frequency with the heli-pot. The problem proving to be down to the internal pot having been 'maladjusted' close to its (normally unused) upper frequency end of its range to allow me to shift the external tuning voltage from circa 2.5v down to circa 250mV to attenuate the temperature drift of the AMS1117-5.0 used in the YRobot breadboard psu module by a factor of 10 to 1. It's a neat trick, but only if the internal pot doesn't get upset by this adjustment to 'parts exotic' of its resistance track. I'd had to 'exercise it' around this new setting to polish that bit of the track clean before I could set the external tuning voltage to 270mV (middle of the new zero to 515mV range that I'd padded the heli-pot out to) and re-syntonise the LPRO.

 The high drift rate problem now appears to been eliminated but it's early days. When you're chasing this level of stability, it needs more than just 24 hours for everything to settle down after even a brief power interruption. I'd been powering the 12v CPU cooling fan from my bench supply to test it at 18.8v to extend the lower usable PWM control range downwards from 22% on 12v to just 14% at a 17v test minimum to verify it would still start reliably using a one diode volt drop less than the 19v powering the LPRO. The psu count is now back down to just two (19v laptop charger and a 12v wallwart powering the breadboard in the absence of a usb connection to the PC).

 Ultimately, the whole GPSDRO will be powered from a couple of redundant 19 volt laptop charging bricks powering a 7808 powering a 7805, both thermally bonded to the baseplate for temperature stability to minimise the effect of the 7805's voltage tempco on the Vcc rail.

 Having an extra DC input socket for a second 19v PSU will come in handy for testing in low ambient temperature conditions (basement or outside on a dry winter's day) since I can plug the redundant laptop charger into a very long mains extension lead plugged into a downstairs socket, allowing me to physically move it from my 1st floor hobby lab without interrupting power.

 However, from previous experience, a simple swap over from a lab mains socket to a very long mains extension is unlikely to disturb its hard won stability if done in just a few seconds long time frame. The LPRO can recover lock after a few seconds of power loss within just a few seconds of restoration of power. My GPSDO (a modern day version of the G3RUH design), otoh, can take minutes to stabilise even after the briefest of interruptions. Notably though, once it has stabilised, the phase relationship it had beforehand with the LPRO is always resumed, seemingly exactly from where it had left off.

 Considering that the PPS has been programmed to output 100KPPS to phase lock at 100th the OCXO's frequency, My instinctive expectation had been to see a random phase displacement after such a disruptive event. I mean, any one out of the individual 100KPPS is as good as any other for the PLL to phase lock at any one of the 100 cycles of the 10MHz it takes to make a single full cycle at 100KHz. Perhaps I'm simply failing to see the wood for the trees to figure out this conundrum.

 Looking at that sequence of screenshots over a 10 hour period, it seems to be in need of more settling time and some more tweaking of the heli-pot to syntonise it to the GPSDO.

PS I've just realised that the time labels on the screenshots could be mistaken for run time. They're just the time of day they were grabbed via the web control panel I've only just reacquainted myself with - no dynamically updated screen image feature, just a Refresh Screen button - probably why I left this interface option to lie unused these past couple of years. That first screengrab was made about half an hour after I'd lined up the traces for a casual test run (honestly? I'd simply forgot to take a screengrab )

[wergor]

I'm thinking about buying a LPRO-101 and have seen 2 versions: one with a 10-pin connector and one with a d-sub 9-pin and SMA connectors. The latter looks as if it was a 10-pin LRPO mated with an (removable?) adapter. Is this the case?

[Johnny B Good]

I'm thinking about buying a LPRO-101 and have seen 2 versions: one with a 10-pin connector and one with a d-sub 9-pin and SMA connectors. The latter looks as if it was a 10-pin LRPO mated with an (removable?) adapter. Is this the case?

 As far as I can recall, I believe that's correct. Try checking out YT review videos. I think that must have been where I saw these 'adapted' LPRO 101's.

 Looking at this one on ebay

https://www.ebay.co.uk/itm/154378085514?hash=item23f1a6a48a:g:0K0AAOSwpsdgU1fx

 that certainly seems to be the case.

[wergor]

my unit came in the mail today, I can confirm that the LPRO-101 is removable.