Author Topic: Fixed vs Adjustable frequency Rubidium oscillator.  (Read 6401 times)

0 Members and 1 Guest are viewing this topic.

Offline Johnny B Good

  • Frequent Contributor
  • **
  • Posts: 870
  • Country: gb
Re: Fixed vs Adjustable frequency Rubidium oscillator.
« Reply #25 on: January 16, 2021, 12:57:30 pm »
Like already reported, the FA-5650A is a noisy devices; first reports about its uselessness for microwave applications date back to about 2010 from KA7OEI, to my memory he also shows a way how to clean up the signal with a rubidium locked oscillator

 Interesting, initially I'd thought the  "FA-5650A" was a typo for the "FE-5680A" but when I googled " FA-5650A" to check, the only results led to a few hits for the FE-5680A and this topic thread. However, googling for FE-5680A led me to results for both model numbers with one of the results being this informative page :- https://prc68.com/I/FEIFS.shtml.

 Both models use the same DDS method so need the use a 'clean up' VCXO solution to allow them to be used as 10MHz reference frequency sources for GHz rated transverters (the Efratom LPRO-101 and its variants can be used directly without the need for a 'clean up' add on VCXO).

 Personally speaking, the Efratom LPROs are a safer purchasing choice imo since you can never be certain which of the '57 varieties' of the FEI models you might actually land up getting lumbered with (the issue of remaining lamp life and whether you get a working unit applies to all of these used RFS models regardless of make and model).

 The bonus features of 1PPS and, where enabled, programmable frequency setting via a serial interface, are rather overrated imho since the 1PPS has no fixed relationship to the GPS PPS time reference pulse anyway and it makes very little sense to use the RFS directly as a variable (and limited range) frequency source when it's far better to simply employ it as a fixed 10MHz reference for test and measurement kit and use a separate RF generator or AWG to generate a much less limited range of frequencies locked to your 'Atomic reference'.

 The Efratom LPRO models are more or less a "Straight out of the box" 10MHz secondary atomic reference solution whereas the FEI models might involve some modification or reprogramming to achieve this happy state. If you're prepared to add a clean up oscillator, you can phase lock this to whatever oddball frequency your unit happens to produce if it turns out not be a 10MHz unit, thus neatly avoiding having to open it up to modify it internally for 10MHz.

 Adding a clean up oscillator to an FA-5650A  or FE-5680A is a relatively trivial task in the grand scheme of things so, as long as any of these can produce a stable frequency, locked to the Rubidium physics package whatever oddball frequency they happen to output (8.333333MHz or 15 or 20 MHz for example), phase locking the cleanup oscillator will provide an effective solution without any need to delve into its innards to effect a possibly risky modification.

 If you're prepared to do the extra work of adding a clean up oscillator (a decent quality VCXO will suffice - no need to go to the expense of a VCOCXO in this case), you can turn this to your advantage to build a cost effective RFS using one of the cheaper less desirable frequency variants of the FE-5680A or else just pay the premium for an Efratom LPRO-101 for an 'easy life' and have done with it. :)

 Having said that ("and have done with it"), if you're serious about the ultimate stability, there's a little more work involved than just shoehorning it into a barely large enough plastic or metal case (whether sealed or ventilated) as demonstrated in some of those idiotic youtube videos I've had the displeasure of watching. >:(

 When you're chasing down stabilities of the order of 10ppt or less (as I am in my quest to quantify the ionospheric errors that plague the single frequency timing GPS based GPSDO models with phase shifts on the order of 5 to 6ns pk-pk that I've observed so far with my modern re-spin of the famously high performance James Miller design using a uBlox M8T in place of the ancient Jupiter-T GPS receiver module used in the original design), you need to hold the base-plate temperature to a very tight tolerance against room temperature variation to achieve the required stability.

 In my case, that means installing it into a roomy steel instrument case, mounting it onto a quarter inch thick aluminium heat spreader with a large (80mm square by 25mm deep fan cooled) CPU heatsink bolted onto it to control heat transfer rate to the walls via recirculation inside of this unvented case using PWM fan speed control mediated by a bead thermistor literally embedded into the centre of said heat spreader.

 Initial testing of the effectiveness of this recirculating fan cooling system in an unvented steel enclosure of 1800 sq cm total panel area indicates this is a viable way to control the base-plate temperature with the absolute minimum of openings for a bi-colour front panel led with two on the rear panel for a 5.5mm DC jack and an SMA-F output socket.

 Although the 'recommended' DC supply voltage is quoted as "24 volts", the full voltage range is given as from 19 to 32 volts (with power consumption test figures curiously covering the slightly wider range of 18 to 36 volts). After initially testing with a 24v supply (just under 2 minutes to lock), I elected to use a 19v laptop charging brick (I have at least three suitable laptop chargers to hand) which extended the time to lock to a pretty consistent 192 seconds from a room temperature in the range 20 to 25 deg C. The reduction in energy consumption after lock up is only a modest 1W in this case but 'Every little helps' :) as does keeping the PSU outside of the case (improved charging brick reliability due to lower temperature operation and faster swap out of any failed units being two other obvious benefits as well as simplifying some form of battery backup I might wish to add at a later date).

 My initial idea for fan speed control had been simply to turn it on and off to control the base-plate temperature since there is a rather massive thermal inertia involved. However, my solderless breadboard lash up had introduced an accidental PWM effect around the switching point (as such solderless breadboard lashups are wont to do) and the 12mV hysteresis on the temperature sensor signal disappeared, leaving it being held to a steady reading once the temperature had stabilised which inspired me to use PWM 'on purpose' as opposed to 'by accident'. I'm now at the stage of testing my PWM circuit ideas, having finally extracted those hens' teeth from out of the jaws of all those Unicorns googling efforts.

 I'm aiming for a base-plate temperature of 35 deg C which should be good for a maximum room temperature of 27 to 28 degrees or so (here, in this part of the UK, it's very rare to see summertime room temperatures go above 25 to 27 degrees). I'd prefer to avoid going to a higher base-plate temperature but, if needs must, I still have the option to drill some discreet ventilation holes to enable some external cooling airflow to avoid raising the set temperature above my 35 deg target.

 Unfortunately, I won't be able to verify the actual cooling requirements until I have everything mounted inside and the enclosure sealed up ready for final testing but I do at least have a contingency plan in place should a more effective cooling solution ultimately prove to be required.

 If anyone is curious about why I am going to so much trouble in using a recirculation cooling solution in a sealed case rather than 'take the easy way out' with a ventilated cooling setup, it's because this, if it works as well as my initial tests indicate, is actually the most pragmatic approach in that, as well as minimising EMI leakage paths with additional routes for ingress and egress of electrical interference, I'm also avoiding unnecessary work on modifying the case as well as maximising the possibility of repurposing it should I later decide to rehouse my RFS in a better enclosure.

 I hate unnecessary work and needless mutilation of an otherwise serviceable enclosure that could be used in a later project should it ever become redundant to the current project - I like to keep my options as wide open as much as I possibly can. :)

 John
« Last Edit: August 25, 2021, 02:57:45 pm by Johnny B Good »
John
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: Fixed vs Adjustable frequency Rubidium oscillator.
« Reply #26 on: January 16, 2021, 02:08:36 pm »
Indeed I meant the FE-5680A, since it's the one I own, so investigated about that one in the pre-GPSDO times
Certainly the Efratom LPRO are a much better choice, but from that what I see both types are rather expensive now; I got my one for about 50$ in 2011
 

Offline Johnny B Good

  • Frequent Contributor
  • **
  • Posts: 870
  • Country: gb
Re: Fixed vs Adjustable frequency Rubidium oscillator.
« Reply #27 on: January 16, 2021, 08:41:03 pm »
 I bought mine from a US based Ebay seller (EEVBlog member testpoint1) for $179 plus another 70 dollars for postage and import duty charges in August last year. As per usual, it's a case of "Market Forces" at work, "Supply and Demand", and those halcyon days of the 50 dollar rubidium oscillator are now long since gone.  :(

 John
John
 

Offline martinr33

  • Frequent Contributor
  • **
  • Posts: 363
  • Country: us
Re: Fixed vs Adjustable frequency Rubidium oscillator.
« Reply #28 on: January 17, 2021, 03:08:24 am »
I'm only working with cheap stuff, seems that I like to fix the cheap rubidium oscisllators on eBay... and 53132as... and...

However, I have put together:
    - A couple of 53132as with high-grade crystal oscillator boards (units can source or use a 10MHz reference signal)
    - A GPS frequency generator based on a Trimble module (eBay)
    - An HP 33120A waveform generator with the external lock for an external oscillator

What I see is:
   - The two 53132As running on their internal enhanced clocks track each other precisely over short periods.
   - The GPS oscillator output varies by maybe 100 counts on the 12 digit scale
   - The rubidium oscillators hold close to frequency over long periods, once they have locked in
        - it takes a little while after they lock in to reach final frequency

GPS is my only trustworthy reference, but the deviation around 10MHz makes it tricky as a calibration source.

So.. is there  a GPS-based oscillator that does not deliver a wandering 10MHz? (we're talking parts per trillion here).






 
 

Offline Wim13

  • Frequent Contributor
  • **
  • Posts: 252
  • Country: nl
Re: Fixed vs Adjustable frequency Rubidium oscillator.
« Reply #29 on: January 17, 2021, 03:07:54 pm »
So.. is there  a GPS-based oscillator that does not deliver a wandering 10MHz? (we're talking parts per trillion here).??

Yes there are, GPS standaards see attachment , 1xE-12

But i use two rubidium clocks and two GPSDO, and a HP5370, and most important excel spreadsheet,
then i can get close to 1xE-11
« Last Edit: January 17, 2021, 03:10:26 pm by Wim13 »
 

Offline martinr33

  • Frequent Contributor
  • **
  • Posts: 363
  • Country: us
Re: Fixed vs Adjustable frequency Rubidium oscillator.
« Reply #30 on: January 17, 2021, 06:08:55 pm »
You can see in the spec that the short term variation in the GPS signal shows up in the output.

I'm assuming that the best crystals can deliver 1e-12 stability in the short term (I see this on Oscilloquartz, Morion and Trimble double oven devices when I run two counters on the same input).

So why don't the standards use the GPS to discipline a local oscillator in the short term?

Maybe because the specified performance on the oscillator is not good enough?



 

Offline Wim13

  • Frequent Contributor
  • **
  • Posts: 252
  • Country: nl
Re: Fixed vs Adjustable frequency Rubidium oscillator.
« Reply #31 on: January 17, 2021, 07:15:20 pm »
The problem with GPS signals on short term, you have to deal with radio paths that are not stable,
so your GPS reference is always moving.

a path difference of 1 meter is already 3 nSec away.

The sats are moving, the ionsfeer is moving, reflections, and so on, the software must be able to
correct this all on the short term, is not easy.

I have also an old Jupiter GPS, that is still working, (telling me it is 2001, wrong week number),
but works for positioning and time pulse oke, on a scoop you can see on these early models that on the short it is moving 50 to 100 nSec per sec.
The manual specs of these old model is even worse, 1 uSec per sec .
 

Offline 5065AGuru

  • Frequent Contributor
  • **
  • Posts: 374
  • Country: us
Re: Fixed vs Adjustable frequency Rubidium oscillator.
« Reply #32 on: January 18, 2021, 01:08:28 am »
martinr33,

Pick one of your Rubidium units, run it 24/7, and track the long term phase against your GPS.
Over a few days of trimming the Rubidium you will have a "trustworthy reference".
Then you can calibrate to reasonable levels in a much shorted period of time.
Of course picking up a Cesium unit with some life in the tube would be ideal!

Cheers,

Corby
 

Offline martinr33

  • Frequent Contributor
  • **
  • Posts: 363
  • Country: us
Re: Fixed vs Adjustable frequency Rubidium oscillator.
« Reply #33 on: January 18, 2021, 04:33:31 am »
Thanks, Corby -

 - I use the precision double oven oscillators in my two counters as my references.
 - I tune them with a GPSDO. When they are measuring the GPSDO at 10MHz over a longer period, I figure that they are set. That takes a few tries, as I can't control the calibration timing in the 53132as. I have ot hit the GPSDO just right.
 - Then I use that to set the rubidiums. I have FEI units, which have a remakably diverse number of ways to set the frequency across the range of units, and in some cases a very annoying connector.



 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf