home about telemetry projects gallery log

High Speed time interval measurements with the Keysight 53230A

One of the nice features of the Keysight 53230A Universal Frequency Counter/Timer is the Timestamping mode, capable of timestamping events at up to 1 MSPS. Somewhat frustratingly, the counter "only" has a 1 million internal sample memory, and there is no way to continously read out and free up the sample memory as the measurement is on going - in short, we can not get more than 1 million samples in this mode, no matter what we do. Which limits us to a total measurement time of 1 second at the highest resolution.

So, the second best option will be to get Time Intervals measurements, and get them fast. The 53230A will capture TI measurements at up to 90ksps, according to the datasheet. That is all well, but the limited sample memory remains - and 1 million samples fills up pretty quickly at 90ksps - in about 11 seconds, in fact. 11 seconds is not a lot when measuring the (in)stability of precision oscillators, so to really get the most out of this high speed sampling, a way to continously get the readings out of the counter as quickly as possible is needed in order to let the measurement run for more than 11 seconds![1]

This is surprisingly cumbersome to do, at least if we want the measurements to be gap free. There are two limits in the instrument that complicate matters; the number of samples the instrument will take per trigger, maximum 1e6, and the number of triggers the instrument will process, again maximum 1e6.

The perhaps obvious solution of simply setting :SAMPle:COUNt to i.e. 100k and software triggering the instrument kinda works, but it will collect the TI measurements as fast as it can - the rate at which the samples are taken is not controllable. Basically, it will take a burst of measurements, then wait for the next trigger. Not what we want.

This could be fixed by dividing down the reference to the desired sample rate, i.e. 10KHz, but then we are measuring the combined instability and noise of the REF and whatever circuitry we use to divide the clock, so this is also less than ideal. To avoid this, the divided signal could be used as an external trigger, but the maximum number of triggers the instrument will process would again limit the length of the measurement.

So in order to extend the measurement duration to more than one million samples, we need to process many triggers - and many samples will need to be collected for every trigger. And it is necessary to control the rate at which the samples are taken within the duration of a single trigger. In essence, the we need to open and close the gate of the measurement many times per trigger - which is precisely what the EXTERNAL GATE input allows for. It is worth noting that the instrument will finish a TI measurement that has been started after the gate signal has been asserted - even if the gate is unasserted before the finishing edge of the measured signal. The pulse width of the external gate signal needs to be less than the period of the reference, to avoid multiple TI measurements being taken back-to-back.

The stability of the external gate signal need not be particularly good, as it only controls the sample rate. The actual time interval measured is between the rising edge of the reference and the following rising edge of the DUT. (Or falling edges, as the case may be.)

Illustrated on the left is a shaky setup using an ancillary pulse generator connected to the EXTERNAL GATE input of the counter to reliably fetch time interval measurements at up to 50KHz, for as long as is needed. It may be possible to get readings even faster, I have not nailed down the upper bounds precisely.

I clock both instruments from the house standard.

The counter is configured for Time Interval measurements between channel 1 and 2, with sane settings of triggerpoints etc. The trigger source is set to software using TRIGger:SOURce BUS, while GATE:STARt:SOURce EXTernal and GATE:EXT:SOUR BNC configures the instrument to use external gating on the rear BNC. The number of triggers to process is set to 1e6, and number of samples per trigger set to some convenient number, 10000 in this example. The counter will now return up to 1e10 samples, which should be enough.. Increase number of samples per trigger to get more data.

Then, in software

  1. Issue *TRG
  2. Issue *TRG (sic)
  3. Fetch readings using :DATA:REM? 10000,WAIT
  4. Goto 2

This relies on the fact that the instrument will buffer up to one software trigger, so while the software is busy downloading the previous block of measurements, the instrument is already collecting the next block. Gap free.

[1]: An earlier writeup with a little more details can be found here: http://www.efos3.com/downloads/High Speed Phase Measurement with Keysight 53230A.pdf
olepr01 at gmail dot com