Lars DIY GPSDO with Arduino and 1ns resolution TIC

[thinkfat]

  The FE-5680A type ones come in many different variants, and usually have a coarse temperature compensation that causes frequency jumps.
   I once checked with Temex about their FRS series and was told that the analogue C-field adjustment was truly analogue and step-less, but neither of the two old Temex ones that I tried worked brilliantly.
   Most rubidiums are so noisy that for RF applications you're often going to need to add an OCXO and lock that to the rubidium anyway.

The FE-5680 breed of Rb standards is a very different design to the LPRO. They opted for an LO frequency of an even multiple of the Rb hyperfine resonance. That simplifies the design as you don't need a complex synthesizer to generate the 6.8GHz interrogation signal. Of course they then need a DDS to generate 10MHz from the LO output and that comes at a cost, too: the 10MHz output is not very "pure". But all in all, if requirements are met, this design is cheaper to make. Some FE5680 don't even have a 10MHz output, probably for a good reason.

   The TI TDC7200 is probably easier to use, but I've not seen any cheap boards for them.

It would be simple enough to make a breakout board for the TDC7200. It is not a very complex device to operate. It's just cumbersome to solder, being TSSOP package and all...

[Dbldutch]

@0xFF0

The changing DAC value ruins your measurement in Timelab, but not the accuracy of the 10MHz-OCXO.

Very true, but if you don't have a Rubidium or other standard to compare with, nor a counter that can measure down to 10^-12, TimeLab is your only friend that can help you to qualify your DIY GPSDO, right?

[0xFFF0]

@0xFF0

The changing DAC value ruins your measurement in Timelab, but not the accuracy of the 10MHz-OCXO.

Very true, but if you don't have a Rubidium or other standard to compare with, nor a counter that can measure down to 10^-12, TimeLab is your only friend that can help you to qualify your DIY GPSDO, right?

yep!

[thinkfat]

@0xFF0

The changing DAC value ruins your measurement in Timelab, but not the accuracy of the 10MHz-OCXO.

Very true, but if you don't have a Rubidium or other standard to compare with, nor a counter that can measure down to 10^-12, TimeLab is your only friend that can help you to qualify your DIY GPSDO, right?

Well, but if you don't have any instruments that can appreciate such precision... What for? If you cannot 'see' your GPSDO, it is by definition good enough.

[billy_gr]

Hi,

Long time reader of eevblog, first post

I have build in the past this GPS DO https://www.instructables.com/id/GPSDO-YT-10-Mhz-Lcd-2x16-With-LED and yesterday i have finished also the LARS version on a breadboard, tried the both on a 53131A (using them as external reference and measuring the other) and both are at 10.000.000 +-001-2mHZ when locked. ISOTEMP on the first, an old CORNING on the LARS GPSDO

I had the issues with the missing PPS and had to use a small coaxial cable to connect the C1 to ADC0 now it looks solid.
Any ideas why it is so sensitive ? I am using an Arduino Pro Mini (not Nano)

Since i am not an expert... i used the timelab on lars version for 3 hours and tried to interpretat the results.
Looks good i think (although there is an LM317 boiling hot because no 7805 on stock during the weekend...)
Comments are more than welcome !!! Feedback needed

[W3AXL]

Thanks for the advice and suggestions everyone, especially Dbldutch who I know has been doing amazing things with this design. Thankfully most of your suggestions are easy to implement with almost no increase to BOM cost. That's been the biggest driver here: right now my total BOM cost all-in is right at 100USD and I'd love to keep it right around there if possible.

I'll certainly look into adding individual regulators for every IC. I think I'll adjust the main reg to be a 12V-5V buck and have individual 3.3V linears powering everything directly. That way I don't have to worry too much about power dissipation with a 12V->3.3V linear conversion but I can still get relatively low-ripple 3.3V.

Filtering for the 1PPS, 5MHz, and 10MHz lines is easy. I'll also probably do a new revision of the board with the traces a lot further separated, and add some inline resistors and maybe even LPFs to the 5 and 10 meg lines. I'll definitely look into the PWM cleanup as well; I didn't thumb through all 25 pages before getting to work so there's definitely some useful tidbits here and there that I missed.

Likewise, temperature probes for the case and oven temps are also fairly easy to add in. A good idea for sure, I didn't even realize the code had provisions for temperature monitoring.

As some of you probably guessed, the OCXO I was going with originally was the McCoy OSC92-100B (also known as the Isotemp 134-12), but it seems as if this is less common on eBay than I thought (I bought the last one). I had originally intended to distribute out boards to some friends for them to build their own, but that requires them to be able to get ahold of oscillators for cheap. I'm now looking at the RALTRON OX4114A-D3-1-10.000-3.3. It seems to have similar specs to the OSC92, is much smaller, and is available from Digikey for cheaper than I got the McCoy on eBay. whoops, that one has no electronic frequency adjustment. Also linked the wrong datasheet. Looks like the hunt continues!

At the end of the day, my goals for this project are two-fold: 1) a fun DIY project that will result in a useful piece of lab gear when everything's done, and 2) something to help my various used bits of test gear stay relatively in-spec. I'm definitely no "time nut" but I do a lot of RF projects and knowing I'm close enough to an accurate frequency is all I really need. My service monitor was last cal'd in 2002 so I'd imagine a good external reference will help things out.

Oh, and by popular demand the extraneous power switch has been removed in revision B:

[Dbldutch]

Just wanted to show the first results of my attempts to regulate the temperature inside the GPSDO enclosure, in an attempt to isolate the OCXO temperatures from the room temperature changes. All this to get a "pure" DAC result, devoid of temperature effects.

The data is taken from my Trimble based GPSDO, where the OCXO itself is insulated from all 6 sides in a 10-15mm thick hard-foam box. Inside the box is one of the LM35 temperature sensors.

I'm using the other LM35 that measures the ambient temperature right on top of D1/R1/C1 inside the enclosure to drive a 30mm 5V DC fan with a PWM signal, coming from a simple PID controller. Both LM35's are now low-pass filtered to get rid of the noise. I've drilled a few holes in the front-panel to let the air in, but tried to keep the air-flow away from the OCXO. The fan with the electronics is located on the back-panel.

I've modified the Lars program to add the required functionality.

UPDATE: I have posted the code on my Github site. https://github.com/paulvee/Lars-GPSDO

This small and simple addition is very promising I think.

[thinkfat]

I'll certainly look into adding individual regulators for every IC. I think I'll adjust the main reg to be a 12V-5V buck and have individual 3.3V linears powering everything directly. That way I don't have to worry too much about power dissipation with a 12V->3.3V linear conversion but I can still get relatively low-ripple 3.3V.

Unfortunately, LDOs are not very good at removing input supply ripple. You might want to look into adding a "capacitance multiplier" after the buck regulator to have a clean input to the LDOs:

[Mike99]

Curse this addiction 

A few months ago I'd never heard of a GPSDO and now I have built two of them ...

[ Specified attachment is not available ]

The first is to Lars' original design using breadboard construction with an NDK OCXO.

The second is Dbldutch's modified design on a PCB with a Vectron OCXO.

Both use a Neo-7 GPS and I have an active puck antenna on the outside wall of the house.

Time to do a comparison. See you in a few weeks 

Mike

[Bryan]

Attempting to compile v 3.51 on the Arduino and receiving a compilation error. error: 'loop_delay' was not declared in this scope
float derivative = (temp_error - prev_error)/ loop_delay;

Is there a missing library or is it just a missing forward slash and loop_delay is supposed to be a comment??

// *** paulv The fan controller
void control_fan() {
  // Use the low-pass filtered ambient temperature sensor value.
  // Do not mess with the original code so convert the value to Celsius here again.
  ambient_t = temperature_to_C(tempADC1_IIR,temperature_Sensor_Type/10);
  // PID calculation
  float temp_error = ambient_t - cool_baseline;
  integral = integral + temp_error;
  float derivative = (temp_error - prev_error) / loop_delay;
  duty_cycle = pwm_baseline + (Kp * temp_error) + (Ki * integral) + (Kd * derivative);
  prev_error = temp_error;

  if (duty_cycle > max_pwm) { duty_cycle = max_pwm; } // max = 100% = 255
  if (duty_cycle < pwm_baseline) { duty_cycle = pwm_baseline;} // set minimum

/* for debugging:
  Serial.print("Kp = ");
  Serial.print(Kp * temp_error);
  Serial.print("\tKi = ");
  Serial.print(Ki * integral);
  Serial.print("\tKd = ");
  Serial.print(Kd * derivative); 
  Serial.print("\tambient temp = ");
  Serial.print(ambient_t);
  Serial.print("\tduty cycle = ");
  Serial.println(duty_cycle);
*/           
  analogWrite(fan_pin, duty_cycle);
}

[fourfathom]

Attempting to compile v 3.51 on the Arduino and receiving a compilation error. error: 'loop_delay' was not declared in this scope
float derivative = (temp_error - prev_error)/ loop_delay;

Is there a missing library or is it just a missing forward slash and loop_delay is supposed to be a comment??

  float derivative = (temp_error - prev_error) / loop_delay;
 

Looking at the code, and the position of the semicolon, I'm pretty sure you are missing a declaration for loop_delay.  It's probably a variable (based on the lack of capitalization), but could possibly be a constant or a #declare.  "loop_delay" might be in a header file.  If you search through the code, do you see any other references to it?

[Bryan]

There is no other reference to loop_delay in the sketch so has me scratching my head a bit. Unless it's in a missing header somewhere.

https://github.com/paulvee/Lars-GPSDO

[thinkfat]

loop_delay is the time constant for the "I" part of the PID. It must be defined somewhere. Maybe on the compiler commandline (like, adding a "-Dloop_delay=10" for a 10 second time constant) if it's not in the code.

[Dbldutch]

Hi guys,

Very sorry for the introduction of the error in the source code. 

I had initially defined loop_delay but that was taken out, unfortunately not completely.
This constant

Code: [Select]

int loop_delay = 1;       // 1 second loop timewas initially used to indicate the loop time for the PID controller, but since it is always 1 second, I took it out of the definitions, but not from the PID function.
You can remove the loop_delay division from the PID controller.

[Bryan]

Thanks for clarifying, appreciated. I was able to compile it after removing the division, as a matter of fact it compiled using the NANO as the board.

[W3AXL]

Alright, did some major rework to the schematic and board this week.

I think I'm going for something in between Lars's "minimum viable" design and dbldutch's "pursuit of perfection" design. Like I said before, I'll be more than satisfied with a GPSDO that gets me reasonable performance, especially for the price. Current BOM cost all-in is around $85.

New schematic:


New board:


Changes made:

• Now using Bliley NV47xx oscillator package since it's cheap and easy to get online
• Added LM35 temperature sensor next to oven package for some half-assed temperature compensation
• Buck regulator for 12V -> 6V and separate 5V LDOs for "digital" and "analog" power
• Switched to a vertical USB-C connection (because it's the only connector I could find with a vertical right-angle orientation)
• Added a ton of vias all over the analog signals to make sure I can minimize crosstalk and interference as much as possible
• Using double-stack BNC jacks for 10MHz output
• Much smaller board size due to smaller oscillator. Designed to fit in a Hammond 1455K1201

Things I'm still considering:

• Resistor dividers on EFC line to oscillator, for more precise voltage control
• Moving the logic gates a bit further from the oven (probably not super necessary)
• Standoffs for the GPS module so it's not just hanging on by the headers

Opinions, comments, and anything else are always appreciated! This has been one of the most in-depth designs I've done in a while so I'm really enjoying the process.

[bingo600]

Looks nice 

But once you get into time nuttery, you would want a buffered 1PPS output too.

How about reverse polarity protection ?
I killed a FEI 5080A Rubidium , by being lazy and not testing that some IDI.. PSU designer made the "screen +" and the "inner core -"

/Bingo

[iMo]

Are those R17-R20 10k resistors "placeholders" or do you want really go with 10k? That is too much for that kind of circuit, isn't it? I would expect a few hundreds of ohms there..
Also I would add a 3.3uH-10uH choke followed by 1u||10n to ground as a filter after the switcher.
PS: the L1=33u seems to me too large too, it will just pickup a noise, moreover it could create an instability of the loop.
Mind the USB is a great source of noise coming from your PC..

[W3AXL]

RE: Reverse Polarity Protection, that's a great point. I'll stuff a small diode/fet combo somewhere to take care of that.

RE: 1PPS, I'd love to, and a friend who's interesting in buying one of these from me asked about it as well. I've got an internal PPS test point but I don't really have any room left in the case for PPS, unless I added another BNC above the GPS/power connectors.

RE: OpAmp Gain Resistors, thanks for bringing that up. I ripped that buffer circuit straight from Brian Dorey's 10MHz project. The Bliley OCXO I'm going with is a square wave output, and as far as I can tell it's not expecting a low impedance of any kind on its output. Are you concerned about loading of the OCXO?

[bingo600]

RE: 1PPS, I'd love to, and a friend who's interesting in buying one of these from me asked about it as well. I've got an internal PPS test point but I don't really have any room left in the case for PPS, unless I added another BNC above the GPS/power connectors.

Use sma  .... sma->BNC adapters are cheap

/Bingo

[Dbldutch]

@ Axel
Good job with the circuit.

Be aware that the Bliley has sine-wave out and square-wave out versions. You could add the "miti" squarer parts as placeholders.

Two small and easy things that will help to reduce side-effects. Use high-efficiency LED's, as a minimum for the Lock signal, so you can increase the resistor size and reduce current. I've shown the effects on the loop in one of my earlier posts.

If you don't want to give the NEO it's own regulator, add a small value series resistor and a larger reservoir cap in the supply line to the NEO. It has it's own 3V3 voltage regulator, so a bit less than 5V in is no problem.  As an alternative, you could also feed it with your 6V supply. This will help to reduce the 1PPS bounce effects.

As an option, put a 68 Ohm resistor in series with the LM35 dataline and use a 10uF T cap from the data to GND. Alternatively, you could also add my low-pass filter in the firmware.

Add placeholders for the parts that can drive a fan, you'll be happy you did afterwards.

Good luck!

[Mike99]

I've just run my new GPSDO with the Vectron OCXO for a couple of days and would appreciate the experts' opinion on the results.

I have a gain of 590, TC of 200s and TempCoeff of 0. The OCXO temperature varied by less than two degrees.

I'm curious about the slope on the DAC value.

Thanks,

Mike

[cdev]

vref use on GPSDO?


I have an OCXO that has both the EFC and a vref connection. Its my understanding that this is the point that represents the highest tip of the control voltage range. Is it used?

[0xFFF0]

The OCXO either loses heat or it heats up more and more. In any case, the temperature control does not seem to be working.

[Johnny B Good]

Curse this addiction 

A few months ago I'd never heard of a GPSDO and now I have built two of them ...

(Attachment Link)

The first is to Lars' original design using breadboard construction with an NDK OCXO.

The second is Dbldutch's modified design on a PCB with a Vectron OCXO.

Both use a Neo-7 GPS and I have an active puck antenna on the outside wall of the house.

Time to do a comparison. See you in a few weeks 

Mike

 Blimey, Mike!

 That was bloody fast work! I started working my way from using a NEO-M8N module as a cheap 10MHz/30MHz reference to check the calibration of an HF Transceiver I hadn't re-calibrated in over twenty years for lack of a suitable antenna and propagation conditions to receive the 10MHz WWV broadcast I'd last used, gulp! back in the early nineties!

 Happily, the HF rig was still within 0.5Hz at 30MHz (after a half hour warmup). My next calibration exercise on the 50MHz TCXO upgrade oscillator board I'd used to replace the crappy 50ppm smd XO in an FY6600-60M is what started me down the road to DIYing a 'proper GPSDO' a whole 18 months ago now,

 It took me 12 months just to complete a MK I version and then another 4 months to respin it into a MK II version which I'd unwittingly morphed into a modern day version of the James Miller design.  I've got three nano3s waiting to be utilised but DIYing a GPSDO is a lot simpler without such encumbrance.

 I'm taking a keen interest here because the only sensible way to go take filtering time constants much beyond 5000 seconds is to use a microcontroller and Kalman filtering to discipline a Rb oscillator from 24 hours or more's worth of GPS timing data. I'm going to start disciplining a much easier beast to tame than an unruly double ovened OCXO when I get round to trying my hand at a microcontroller based GPSDO. 

 However, my first non-trivial use of a nano3 looks like it will be to control the RFS's baseplate temperature and compensate for barometric pressure variations to simplify the disciplining to just compensating the more predictable ageing characteristic of a RFS. I'll save the thankless task of disciplining an OCXO till when I feel more comfortable in using a microcontroller to keep such an unpredictable beast as an OCXO on track.

 As you gain more experience and strive for ever better stability out of your GPSDO projects, you'll become a lot more aware of the GPS system's weakness as a frequency and timing reference source soon enough, assuming you're not already well acquainted with its deficiencies to begin with.

 My plan to discipline a RFS is just my way to bypass all the hassle of an OCXO based GPSDO and cheat my way towards the goal of a reference operating at the 1.0E-14 limit of the GPS master clock itself. What I'll do after that, Deity only knows - probably dabble in the voltnut domain (either that or just vegetate into a senile old age).

John