HP E1740a time interval analyzer

[hgl]

Timestamps come from a 16 bit counter that counts resolution steps (min real resolution step = 4.8828125000000011e-011). This counter always counts from the beginning, never stops and overflows every 65536 counts. There can be one overflow between two timestamps which can be corrected by adding 65536. You can increase the measurement time by increasing the resolution steps up to 400ns.

Code: [Select]

// set output format
*outfile << std::scientific << std::setprecision(16)<< std::setfill( '0' );

// all bytes read and stored in timestampBuffer
uint16_t * pbuf = (uint16_t *) timestampBuffer;
unsigned num_tintv = meas_bytes /2 -1; // time intervals

int  actStamp; // actual timestamp
int  nextStamp; // next rimestamp
int  tintv; // time interval   
double realTintv;

for (unsigned long i =0 ; i< num_tintv; i++)
{
      // swap bytes from big to low endian
     actStamp =  _byteswap_ushort(*pbuf);  // actual timestamp
     pbuf++;                               // adjust pointer
     nextStamp =  _byteswap_ushort(*pbuf); // next timestamp
       
     if (nextStamp > actStamp)
tintv =  nextStamp - actStamp; // timestamp interval
     else
tintv =  nextStamp - actStamp + 65536; // correct overflow

     realTintv = (double) tintv * realresolution; //  calc real interval time
           
     double freq = 1.0 / realTintv; // calc frequency   

     // save to file
     *outfile << freq << std::endl;
}

What do you need ?
raw 16bit data?
big / little endian?
corrected timestamps?
time interval?
frequency ?

[maxwell3e10]

It's best to manipulate tintv, since these integer numbers can be added together to get total time without any rounding error. Also make smaller files. But it would be easiest if you save it as ASCII.

[hgl]

Here are 3 runs with an HP10811-6111 as reference and signal.
pacing =30, timinterval as ascii int
 

[maxwell3e10]

Are you sure these numbers are with pace=30? The average spacing between points is 2048, which corresponds to 10^(-7) seconds.
Also, I am not sure if you need to take difference of successive time stamps. I think each timestamp is already the difference of successive zero crossings.

[hgl]

I was also surprised that I didn't need the parameter in my calculation. There is no error message and when I read the parameter back it is 30. But I'm not sure whether one of the many other parameters stops to use it.

Trigger level is 0V and slope is positive.

[maxwell3e10]

What are the numbers in actStamp? You would expect numbers around 61440

[hgl]

Timestamps come from a 16 bit counter that counts resolution steps (min real resolution step = 4.8828125000000011e-011). This counter always counts from the beginning, never stops and overflows every 65536 counts. There can be one overflow between two timestamps which can be corrected by adding 65536.

[maxwell3e10]

OK, so it just reports the time bin (in 48 psec increments) when a zero crossing occurs. But still the spacing between successive points is about 2048, so its not using the pacing number somehow. Can you tell how long the measurement actually takes?

[hgl]

There is an unclear point or a bug in the user manual, you need an extra parameter to activate the pacing, which must not be left out.

[maxwell3e10]

So here is the analysis of the timestamps and frequency resolution.  For frequency measurements I do many line fits to segments of specific length and estimate frequency uncertainty from scatter of the linear slopes. These plots can be compared to the ones in review of Keysight 53230A: https://www.eevblog.com/forum/testgear/keysight-53230-frequency-counter-review-and-bug-identification/

In general, the performance  of E1740 is pretty good, but can't quite beat 53310A or 53230A. The rms of single edge detection is 70 psec, slightly worse than HP53310. The time stamp measurements are pretty stable over time, with Allan deviation comparable to 53230A. When measuring every edge the Allan deviation has some oscillations, which may indicate non-linearity of the time interpolators. There maybe a calibration option to compensate their non-linearity.

[maxwell3e10]

I checked the manual and it does have a interpolator calibration function. Have you tried it already?

[hgl]

Time intervals after calibration of the timebase and interpolator.

There is a small difference to the old measurement, input impedance is now 1MOhm. I don't think it matters.

[maxwell3e10]

Interpolator calibration helps in reducing the time stamp rms from 70 to 30 psec. Time stamp measurements for 1.5 seconds all land in 4 (49 psec wide) bins. When averaging 1000 measurements one can get even better resolution, but there is substantial 1/f noise in the timestamps.  So for short time intervals E1740 works quite well. It would probably be even better without pacing when looking at short intervals.

[hgl]

Sorry there was still a bug in my program. Calibration did not end properly and ran in timout.
Here are 3 new runs, maybe it looks better now

[maxwell3e10]

These look similar to me. It maybe interesting to get data without pacing.

[hgl]

I switched to frequency output again and see a difference between a T-adapter and a powersplitter. Green and red lines with a powerspliter and the others with a simple T-adapter to split the signal to input and reference.

[maxwell3e10]

You don't need a power splitter if input impedance is set to 1 MOhm. Probably simple T gives larger signals. In general to reduce random time jitter one wants  signals with as fast slew rate as possible. One could use a function generator to make larger sine wave  or generate a square wave. The frequency stability of the generator is not so important if the same signal is used for input and for reference.

[hgl]

There is a command: Save Calibration Values ​​to Non-Volatile Storage. Maybe that has to be done. But first I want to save the current settings in a file.
But now it's time to go to bed for an old man. 

[hgl]

It maybe interesting to get data without pacing.

[maxwell3e10]

It seems like calibration of the interpolators helps a little, but there are still some oscillations in the timestamp. Or it could be the external clock reference PLL has some oscillations. One could dive even further into it and measure the time difference A-B between two channels (with identical signals). That removes the clock uncertainty. Further, if the input frequency is a little off from 10 MHz one can see periodic oscillations associated with interpolator non-linearity since the input edges land in different part of the interpolator DAC range.

[hgl]

Next, I wanted to try whether you can read out 3 times after a measurement as timstamp, time interval and frequency and then compare it with my calculations. Then a diff measurement with a 10m BNC cable between the inputs.