TCXO (shopping for replacement)

Got it. Doesn't this tie up a nice sampling scope, though?

-- john, KE5FX

If I understood right it should only tie up a garden variety average reading DC voltmeter.

piglet

It will actually go into one of the ADC inputs of an ARM uP, and LPC1768. It's a crummy ADC, but it's fast.

In a brainstorming session some years ago, James Arthur and I came up with basically that same scheme to make a time-interval counter. One downside is that there is not a big market for fs-resolution time interval counters. Lots of people have gone into and out of that business.

There are chips now, like THS788. Self-driving-car LIDAR uses picosecond-resolution time-interval measurement, although it could use other ideas, like pseudo-random correlation or something. I'm not sure how those cheap optical tape measuring things work.

Ah, never mind, I see you're measuring probabilities by integrating the Q output, not gathering samples at full bandwidth.

-- john, KE5FX

Right, the Q/Qbar diff output of the CML flop is lowpass filtered and scaled to 0-3 volts, into the ADC. At low shot rates, many milliseconds or seconds, the filter will settle and then we will see single shots. We will probably do crude go/nogo testing at that point, to save test stand time.

A sampling scope would get ugly measuring jitter at 1 shot per second, too.

Why not just get a TI THS788. 4 channels, 8 ps Single-Shot, 0 s to 7 s, 0.1

You can do the same time interval averaging as the 5370. At 100ks/s, that would take 1 second and get you down to 8e-12/sqrt(1e5) = 25fs, plus give the rms jitter. Subtract the clock jitter using difference of squares and you have fully qualified your delay generator.

The LSB seems to be 13 ps.

The TI thing is impressive, but we want to measure jitter to better than 1 ps RMS. The difference-of-squares thing can't be pushed enough to get from 8ps to 1.

It's interesting that the TI chip has, basically, a multiplexer ahead of a single time stamper. It ignores an event that happens any sooner than 5 ns from a previous event. Channel-to-channel time skew looks bad.

One cool thing about the data sheet is that is has transistor-level schematics for the LVDS inputs and outputs. Too bad that's bipolar.

Why not? You are probably not going to get 1ps rms jitter in your dut. You have a free-running 500MHz oscillator with low loaded Q. 1 ps rms is doubtful.

Correct me if I'm wrong, but I think there may be a major problem in your d-flop concept. You can only measure at the zero crossings of the reference oscillator. For 10MHz, that is 50 ns.

You probably want to claim 1ps resolution. This means delay increments from

You max time delay may be 1,000 seconds. That is 1e3/1e-12 = 1e15. You need log(1e15)/log(2) = 49.82 bits. Round up to 50 bits.

So 16/50 = 0.32. This means approximately one-third of your delay range is untestable.

At the other end of the range, from 1 second to 1,000 seconds, it could take 1+2+4+8+16+32+64+128+256+512+1024 = 2,047 seconds to test every bit.

That is around 34 minutes. A go-no go test at each of those data points is not going to tell you much. The THS788 would at least tell you the actual delay at each point. So what if it's 13ps. Your oscillator will probably drift more during the test.

Your test combines the jitter from the delay generator with the jitter from the reference clock. You don't know how much each one contributes, so there is no way to assign the jitter measurement to the dut. You need to measure the jitter of the reference oscillator.

How do you do that?

Wrong.

You

Should get close, and we have other products to test.

That's not a problem. The DUT has picosecond delay resolution. We can tune the DUT to find successive OCXO edges, every 50 ns, and measure the jitter around any selected edge. Then we graph jitter vs delay. It works.

Counter bits are cheap. But for long delays, we'll have enough DUT timebase phase noise that we can cut over to using an Agilent 53230 counter, which will take measurements faster. We probably won't test out to 1000 seconds in production. 1 second should be good enough.

The Agilent is pretty good, and already boxed and interfaced and everything.

Buy a very good one.

How do you test between the 50ns edges?

That was my problem. About one third of your delay range is untestable.

Do you ship like that?

You wanted to retire the 5370. What good does it do you to buy another HP tester to take its place?

It won't have 0 ps jitter.

There is a trivial way to do it, but it seems you are not interested. So I give up.

Don't need to. All the hardware inside the DUT will be exhaustively tested. You wouldn't try to test a DVM at every possible input voltage.

The old and new HP counters can do average delay measurements with sub-ps accuracy, so we can make sure the DDGs fundamentally work at any delay setting. But they can't measure jitter to single ps.

Yes. Thousands of them.

The 5370's are decades old and getting impossible to maintain or replace. Besides, they have about 30 ps of RMS jitter. We now use

Our LeCroy digital scope has about 1 ps RMS jitter, and has an "enhanced" mode that claims 100 fs. But it's a $50K monster. And it does this now and then:

If the 53230s get unavailable in 15 or 20 years, we'll have to find something else.

If the DUT has a jitter spec, and it passes, we know that the test set time base is good enough. That's different from testing something like a DVM, where a defective standard results in defective calibration.

Not interested? Tell us and maybe we are.

Don't need to. Just exercise each bit: 1,2,4,8,16,32...

How do you exhaustively test all the hardware inside the DUT. How do you test between the 50 ns zero crossings. How do you check the delay above 1 second.

If the testing is so comprehensive, why bother doing a final test. Just plug it in and turn it on. If the green light shows, ship it.

Isn't the 53230 the one you complained abbout so bitterly since it couldn't do anything without hooking up a pc and programming it?

Here are some comments on the 53230 from the time-nuts archives, including your own in the google groups:

I just received a Keysight 53230A counter/timer, the current recommended replacement for the HP 5370B. The 53230A is nominally 12 digit but will display up to 15 digits and has 20 ps time resolution. In my case, it is desirable because it is a lot smaller than the 5370B and it has USB, GPIB and (best for me) Ethernet connectivity. The TimeLab software has drivers built in for the 53230A. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Robert Leiby (5990-9189EN) paper was a real find. Agilent sent it to me after I ran tests of their new 53230A counter. I had two of them on loan (TCXO and OCXO) and the closer I looked the less I was impressed. The one feature that was a show-stopper for me was that the TCXO version would not outperform the OCXO version even if you gave it a BVA or maser as external reference to the counter. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [time-nuts] Counters for ADEV measurements Tom Van Baak tvb at LeapSecond.com Tue Oct 2 14:03:09 UTC 2012

Previous message: [time-nuts] Counters for ADEV measurements Next message: [time-nuts] Counters for ADEV measurements

To be fair, HP/Agilent did not hide this fact, but I agree it is buried rather deep in the 53131A/53132A manual. The new series (eg, 53230A) has a similar issue. There's a wonderful paper by Robert Leiby about this design artifact:

"Frequency Error near the Reference Frequency Harmonics"

This is no reason not to use a frequency counter in the lab. It simply explains why this class of counter works amazingly well at arbitrary frequencies and not quite as well right around magic numbers like 5 or 10 MHz.

/tvb ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ counters 39 posts by 18 authors

John Lark >> >>>> Not many people make benchtop counter/timers these days.

It's a pleasure to use manually. All the buttons on the front panel make sense and make satisfying clicks. If you want to show the mean or standard deviation of groups of 1000 time interval or period measurements, just a few jabs do it.

The 53230A can't even do that. Statistics keep piling up over all the measurements taken since it was last reset, which is useless for seeing trends or making adjustments. You have to talk to it from a PC, and write code, to do basic stuff.

I suspect that lots of people who write the code for instruments don't actually use those instruments. Lots of people who write the code for cars probably don't know how to drive.

Grrrr.

All these time and frequency measurements bring back good old memories sinc e the 70's for brief moments in my career designing VLF Doppler systems bef ore GPS and using the HP5370P to automatically measure the phase modulation on our UHF Tx which sent the VLF and weather data to GOES #1.

For Black Brandt sounding rocket Doppler, I used Vectron OCXO's with a PLL to create an FM subcarrier in the telemetry signal to track range and azimu th. getting them to pass in 3 axis of 100g shock 50g acceleration and 15g vibration was always a challenge with only 1cm allowance for isolation, so even though ruggedized, usually only 2 axis met the 1e-10 critieria so they had to be mounted in a preferred axis.

Another fave experience was helping design a 1ppm TCXO for $1 in volume usi ng a process we developed for automated binning varactors for C ratio. Th e innovation was my test process using a small jig to measure ppm shift fro m +40'C to +70'C in 15 seconds ( mini regulated thermal socket) then match match use that linear shift offset to compute the 3rd order AT curve to -40 'C from just 2 points.

I then created a polynomial to generate all the AT cut curves so the binned Xtals in the Rx Synth hybrid at 928MHz were within 1ppm for PLL sync from

-40 +70'C with a data 8kHz channel for wireless meter reading.

cheers, Tony

Or buy two, and use closure. Apart from the average frequency of the constellation, that'll give you the jitter statistics of the three devices separately.

Cheers

Phil Hobbs

One interesting gotcha is that very precise oscillators really like to lock to one another, sometimes by being in the same box and sometimes by just being in the same room. That removes apparent close-in phase noise. Our fix is to use different frequency oscillators in the DUT and in the test set. The goofier the ratio, the better.

Your determination to be snarky is removing your ability to think. There's a lot of that going around.

Same applies with (analogue) clocks. One of the deep mysteries of the universe... ;)

-- This message may be freely reproduced without limit or charge only via the Usenet protocol. Reproduction in whole or part through other protocols, whether for profit or not, is conditional upon a charge of GBP10.00 per reproduction. Publication in this manner via non-Usenet protocols constitutes acceptance of this condition.

There was nothing wrong with your post. It was an honest evaluation of the