digital capacitor

Apr 16, 2021 Last reply: 5 years ago 42 Replies

A few people make digital caps. This one is nice:



formatting link
I'm upgrading an oldish product that used a Maxim part that is, of course, discontinued. Maxim won't even acknowledge the old part number. Nobody in the world seems to have any.



The Ixys part has three cap groups, coarse/medium/fine, with 10 bits total. The transfer function code to capacitance is sawtooth shaped, not monotonic, which guarantees that any cap value in the full range has some code that will hit it within one LSB.



I'm coarse tuning an LC oscillator at powerup, to be close to 50 MHz, so that a varicap can take over and swing it to exactly 50.


Unquestionably the worst capacitors on the market: -705pm/VCC, +41.4ppm/C,

+/- 25% tolerance, no data on quality factor, limited frequency range.

Might as well put a strand of spaghetti in a linear actuator and measure the aroma as a function of stretch.

Trimming LC oscillators is a well-established topic with many options to choose from. A digital cap is probably the worst one.

Why not design the oscillator so the varicap has enough range to accommodate all the component tolerances? Then you won't need a digicap and complex power up circutry.

Hi-k ceramics are far, far worse. Electrolytics too. There is a graph on the data sheet of q vs frequency: 50 to 100 at my frequency, and it's just the trimmer. Everything has a limited frequency range.

The oscillator is temperature compensated. The inductor and the FR4 capacitance gang up to give it a negative TC. This digicap hardly matters.

Tolerance doesn't matter: it's a trimmer!

You seem crabby today. That distorts objectivity.

Do I have to give the money back?

Varicaps are terrible. They have huge TCs that are a function of the applied voltage. I want to minimize the pull range of the varicap. That keeps phase noise down too.

I first did this sort of PLL with a piston cap for the coarse tune, but the digital cap is way cheaper and smaller and autotunes every powerup.

Here's the gadget:

formatting link
We're going to do a very minor redesign now, with the new digicap, to hold us over for a year maybe. Then it needs a full redesign; too many parts are going eol, including the 68K uP and an old FPGA. And the Maxim digital cap of course.

The old design has parts on both sides. With modern power supplies and a Zynq, I think it might fit on one side.

formatting link

Pretty sure ONS discontinued a bunch of these before 2010, but could only find one or two other parts in files. Peregrine, Intersil and Xycor(?). Ranges typically below 15pF.

RL

RL

The question is why is there a limit. What is the reason?

[...]

The NXP BB201 dual varicap has a temco of 0.6% at 0.5V, 0.15% at 10V.

The ESR is 0.25 ohm at 100 MHz and 3V bias. This gives 60 pF.

Xc at 50 MHz is 53 ohms so Q = 53 / 0.25 = 212.

So the phase noise would better than the digicap.

How do you accomodate drift between powerups?

Presumably, you use a ramp to interpolate between the 50 MHz clock pulses. This allows you to trigger the output pulse when the ramp crosses the voltage set by a DAC, and the desired number of 50 MHz clocks have passed.

You could use the 50 MHz clock to set the timing instead of an LC oscillator.

You could use another identical ramp to find the time of the input trigger by clocking an ADC.

Combine the two values to determine the settings for the output pulse.

This would give much lower drift and jitter, and eliminate the setup at power on. The changes would probably fit in the same board area.

You could upgrade the 50 MHz clock to a low noise OCXO for even lower drift and jitter. You could also use stable external clocks, such as rubidium or GPSDO for the ultimate in long term stability.

-- The best designs occur in the theta state. - sw

That has way more capacitance than I need for trimming my oscillator.

A varicap needs an analog voltage input, which I guess could come from a DAC, which I don't have. That would have some noise. The digital cap is fixed once it's set at powerup.

It just worked, with a bit of active temperature compensation.

The 50 MHz LC oscillator is started at trigger time, and then phase-locked to the crystal oscillator, which is a different frequency. Time delays are programmable to 10 ps resolution, with under 30 ps RMS jitter from an external trigger.

SRS does something like that, but it adds a lot of insertion delay.

One problem is that fast ADCs have a lot of pipeline delay.

As noted, the 50 MHz oscillator is started at trigger time.

That's what we did at Cambridge Instruments back in 1988-91. The whole story is written up on my website.

formatting link
You'd have to dig through a lot of stuff to find anything relevant. We used an 800MHz local oscillator (phase-locked to a good 50MHz crystal oscillator) so digitising a 125nsec ramp to 5psec only took an 8-bit ADC. The ramp ran for longer than 125nsec but we used frequent auto calibration to make sure that the ramp stopped somewhere exactly within the voltage range the ADC could digitise.

True, but two isn't any more of a problem that one, and fewer bits helps a lot.

Exactly what we did.

There's quite a lot of fast arithmetic involved, which we did in 100k ECL. Programmable logic has come a long way since then.

GPSDO for the ultimate in long term stability. As noted, the 50 MHz oscillator is started at trigger time.

It's a remarkably expensive way of avoiding having two ramps and two ramp digitisers. When I reworked parts of the scheme a few years later for a very different application, I went for a crystal-controlled 500MHz oscillator - it would used a crystal that had been etched down until it was remarkably thin, if we'd ever been able to build the hardware.

John Larkin doesn't like the approach - he won't even dignify it by claiming that it wouldn't work - but it worked for me.

Those weekly reports are more interesting than they have any right to be. :) Thanks for the read, detailed post-mortems of complicated projects are almost always worthwhile.

Having confessed your sins, you can stop beating yourself up for overlooking the column transit time now...

-- john, KE5FX

I didn't see it as beating myself up. I just got it wrong in a situation where I couldn't easily measure what I was estimating. Being rude about the fact that I didn't have easy access to a working system when it would have been useful, wouldn't have gone down well with my superiors (which wouldn't have worried me in the least) but also wouldn't have won me anything that I happened to need at the time. I did have an interest in getting people to tell me about things that weren't working out as expected, so confessing to my own error did make sense as setting an example.

Why spec resolution at 10 ps when the jitter is 30 ps?

RMS is only 1 sigma. Practical jitter should be spec'd at 3 sigma, which means the pulse can be +/- 90 ps from center. If you want to get nasty, you should spec the jitter at 6 sigma to give a more realistic idea of where the pulse could be.

I love their spec: "approximately 80 ns"

I have been studying SRS for some time. They have two models which are different architectures. One model integrates the time between the input trigger and the 100 MHz clock, which is not the same as using a ramp. They have extremely complicated architectures, which is due to the design philosophy in the '60s and '70s. You can tell when they were designed by looking at the parts list.

The Renesas KAD5510P-25Q48 has a latency of 7.5 cycles at 250 MHz. This takes 30 ns, and would increase your insertion delay a bit.

However it would allow you to significantly reduce the 30 ns rms jitter figure, and provide continuous calibration of the interpolation ramp. $47.240 at Newark:

formatting link
formatting link

You can never achieve the low jitter of a crystal, and using DSP to lock to a separate clock will add phase error and jitter.

Most important, you have no way to correct for drift in the interpolation ramp.

With two identical ramps, you could continuously corect for any drift in the ramps by comparing one ramp with 50 MHz clock, leaving the other ramp free for the output pulse. Then swap roles on the next 50 MHz clock.

So by adding an ADC and referring everything to a low noise crystal, you can reduce the clock drift and jitter, and provide continuous calibration of the interpolation ramps.

Because that's what it does.

It's customary to specify jitter as RMS.

If you want to

The DG645 was designed by an engineer that I fired. His name is etched on the PCB. The human interface is ghastly. The packaging is ghastly.

And then the output of the ADC needs to be crunched and probably fed into a DAC to make the final fine delay. Takes more time.

Go for it.

When do you calibrate the output ramp?

How do you correct for drift?

Not exactly. You add exactly the same insertion delay but the input happens at the start of the delay, so that the data is there when you need it.

<snip>

It's a 10 bit device. A faster clock doesn't need to be divided down as far to get to 10osec resolution.

It you crunch the data in parallel in ECinPS it doesn't take much extra time at all. Inside a fast proigrammable device it could be even quicker.

Have a few more, and cycle through cycle through them, so they spend half their time self-calibrating and the other half earning their living.

Going for a 800MHz clock meant that we dividing up a much short clock period, which made the whole self-caibration job a lot less demanding

That's roughly what we did back in 1988. It worked.

And now that we are at it, what is the tolerance of the insertion delay?

What we did - back in 1988-91- was recalibrated it every few minutes.

DAC adjustment of the ramp current, and another to adjust where the ramp started. The board looked a bit busy, but it was surface mount parts on triple extended Eurocard, so there was room for lots of bits.

Pretty much the stability of the 50MHz crystal oscillator to which we locked our 800MHz oscillator - the self-calibration referred everything back to that.

At production test. We poke a polynomial into a cal table for each vernier ramp. A 20 ns linear ramp isn't usually very linear.

It's designed to not drift much. It doesn't.

A delay generator has a lot of tempcos, most of them positive. A temperature sensor measurement can bash them all at once, which helps a lot.

If there's a fan, it can be servoed to sort of keep the PCB temperature constant, which helps a bit too.

It varies per box, but +-400 ps is a typical spec. Unlike Certain Parties, we calibrate and spec insertion delay. Low insertion delay sells boxes, and it's a big and annoying design factor.

Thanks for the reply. Interesting info.

I got a Miller Effect ramp to give a fairly linear 20 ns ramp without the stray inductances that would cause ringing.

Then I realized my idea to ADC the ramp at the input trigger was hopeless.

A 10-bit ADC would give a resolution of 20e-9/2^10 = 1.953125e-11, or 19.5 picoseconds. A resolution of 1.2 picoseconds would require a 14-bit ADC, which is unobtanium at these frequencies. Ramps are a bad idea.

I am now working on another approach that will give resolutions and RMS jitter in the tens of femtoseconds, with an insertion delay of 10 ns or less. The insertion delay has the same specs as the resolution and is locked to the same source. I plan on a LAN or USB interface to load the data, and a fiber optic or SMA input for the trigger. There are no ramps.

Everything is locked to a low jitter, low drift SAW oscillator, which can be locked to a Rubidium or GPSDO.

I will probably make one or two, then make everything open source. At my age and with the loss of one eye and continuing problems from last year's strokes, I am in no condition to start a company, or even try to get a patent and sell the idea. I don't even want the hassle of trying to subcontract the work.

I also have another idea cooking for a fast, cheap sampler that has the unusual property of rejecting noise on the input signal. I have already built it and it works exactly as predicted. I will also make it open source. It will be very useful for testing the delay generator.

Here is the ASC file for the Miller ramp. I am unable to get sabercat or google drive to work, so I have to post the file here. The output ramp is on Q1C. The ramp will be very drifty. If you don't have a BFR92, you can use any 5 GHz or higher npn. MOSFETs like the 2N7002 won't work.

LTspice is valuable for showing when an idea is not even worth trying.

Version 4 SHEET 1 2108 800 WIRE 848 -304 768 -304 WIRE 944 -304 848 -304 WIRE 992 -304 944 -304 WIRE 1008 -304 992 -304 WIRE 1120 -304 1088 -304 WIRE 768 -288 768 -304 WIRE 1120 -288 1120 -304 WIRE 848 -272 848 -304 WIRE 992 -224 992 -304 WIRE 1120 -192 1120 -208 WIRE 640 -176 608 -176 WIRE 672 -176 640 -176 WIRE 768 -176 768 -224 WIRE 768 -176 752 -176 WIRE 848 -176 848 -208 WIRE 848 -176 768 -176 WIRE 912 -176 848 -176 WIRE 928 -176 912 -176 WIRE 608 -160 608 -176 WIRE 992 -112 992 -128 WIRE 608 -64 608 -80 FLAG 912 -176 Q1B FLAG 992 -112 0 FLAG 608 -64 0 FLAG 944 -304 Q1C FLAG 640 -176 Vin FLAG 1120 -192 0 SYMBOL Voltage 608 -176 R0 WINDOW 123 0 0 Left 2 WINDOW 39 0 0 Left 2 SYMATTR InstName V1 SYMATTR Value PULSE(0 3 0 1n 1n 48n 100n 0) SYMBOL npn 928 -224 R0 SYMATTR InstName Q1 SYMATTR Value BFR92 SYMBOL res 768 -192 R90 WINDOW 0 0 56 VBottom 2 WINDOW 3 32 56 VTop 2 SYMATTR InstName R1 SYMATTR Value 50 SYMBOL cap 752 -288 R0 SYMATTR InstName C1 SYMATTR Value 68pf SYMBOL schottky 832 -208 M180 WINDOW 0 24 64 Left 2 WINDOW 3 24 0 Left 2 SYMATTR InstName D2 SYMATTR Value BAT54 SYMBOL voltage 1120 -304 R0 WINDOW 123 0 0 Left 2 WINDOW 39 0 0 Left 2 SYMATTR InstName V2 SYMATTR Value 10v SYMBOL res 1104 -320 R90 WINDOW 0 0 56 VBottom 2 WINDOW 3 32 56 VTop 2 SYMATTR InstName R2 SYMATTR Value 500 TEXT 728 -440 Left 2 ;'BFR92 Miller Effect Ramp TEXT 728 -408 Left 2 !.tran 0 27n 0

I just use an RC and linearize it mathematically. That eliminates a lot of difficulty.

Here's a delay generator making 100 ps steps:

formatting link

If we get a trigger and make that into a ramp (or just lowpass filter it) and digitize that with a clocked ADC, we can calculate the delta-T between the trigger and the local clock. Then we can use that info later, in the delay verniers, to take out the jitter. I've thought about that a lot, but it's not practical... too much processing delay.

One of our products controls a lithography laser. What's wonderful is that we fire the laser so we have no asynchronous trigger. We have time stampers too, also on the same clock.

We build time stampers, time-digital converters, which digitize ramps that are triggered by external events, with the ADC clock local to our board. That works fine. That's how we locate tin droplets. A few clocks of pipeline dealy don't usually matter, and decent design will have under 1 LSB RMS jitter. The theoretical limit is clock period over sqrt(12) for some reason.

We sell a lot more delay generators than time stampers.

That's impressive. Nobody sells a frequency counter with less than about 20 ps RMS jitter. Nothing is much better than a an HP 5370.

We have a test set that we use to calibrate delay generators. It has fs resolution but that's only statistical. It's a 1-bit sampler.

formatting link

Email me and we'll see if we can help.

Nowadays my fast ramps are just an RC, clamped to ground with a schottky diode or a phemt or something.

Open-drain cmos gates have too much personality. Fast current sources are a real pain. Polynomials are cheap in Python.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required