HP E1740a time interval analyzer

[hgl]

I bought an HP E1740a time interval analyzer for about 80€.
There is no free software, what you can find on the internet requires a dongle. I have to do it myself.
My hardware is an old laptop with a PCICIA slot for the Firewire controller to talk to the VXI rack via VISA running on windows XP.


I measure 500,000 times the period of the OCXO on input 1 an save it to internal RAM with a resolution of 50ps. That takes about 1s.
Each measurement is a double value and needs 8 bytes to store, so we have to read 4 Mbytes and save it as ascii to disk. That takes about 14min.
A lot of time to measure and save 20 ms in the life of a 10Mhz oscillator to a 11 Mb file

I imported the data into Timelab and this is what it looks like.

Sample time is 1E-7 - Timelab can only do 1E-6 so the measurement time is 20ms and not 200ms

* measured against the internal reference TCXO

[hgl]

The device dates from the 1990s and has an MC68HC000FN10 controller for math. It is probably better to read the raw timestamps in larger blocks and do the math on the PC. Histograms are excluded from this they are sorted into 2048 bins by hardware on the board.

[KE5FX]

Interesting, not too common to see one of these units up and running.  If you like, try this build:  beta_1ns_t0.exe .  It should allow you to import data with sample intervals down to 1E-9.

[mjs]

That's interestig, how did you find out how to communicate with the device ? I've got 89600-series spectrum analyzer, but the software is node-locked and with limited features. Would be great to be able to use the hardware for SDR.

[hgl]

Interesting, not too common to see one of these units up and running.  If you like, try this build:  beta_1ns_t0.exe .  It should allow you to import data with sample intervals down to 1E-9.

Thanks for the new version, the deviation windows look good, the others are apparently not correct yet.

[hgl]

That's interestig, how did you find out how to communicate with the device ? I've got 89600-series spectrum analyzer, but the software is node-locked and with limited features. Would be great to be able to use the hardware for SDR.

All SCPI commands are described in the E1740a user manual and there are also Basic and C examples. You need a VISA driver from Agilent or NI.

[KE5FX]

Interesting, not too common to see one of these units up and running.  If you like, try this build:  beta_1ns_t0.exe .  It should allow you to import data with sample intervals down to 1E-9.

Thanks for the new version, the deviation windows look good, the others are apparently not correct yet.

No problem.  What are you seeing that looks incorrect?

[hgl]

The labeling of the time axis in picture 3 and 5. Is that correct?

[KE5FX]

The labeling of the time axis in picture 3 and 5. Is that correct?

Looks OK to me, at first glance.  About 5 milliseconds per division, 50 milliseconds total.  For 500K points at 100 ns per sample, that sounds correct.

[hgl]

Sorry I confused the 100ns period with the 50ps resolution 

[hgl]

It is possible to read the measurement results in 3 ways.
-> ascii character (22 bytes)
-> double values ​​(8 bytes)
-> timestamp (2 bytes)

For 500,000 measured values, ascii ist the slowest and takes 14min.
Timestamp is the fastest and takes 70s readed as 32K blocks on my old Laptop.

All binary results are encoded in big endian and for windows you have to swap the bytes to little endian.
Binary results also comes in a frame started with a header (variable length) and a line feed character at the end.

All information is distributed in various documents and the most important original user manual(E1740-90005.pdf) is a scan, you cannot search in it and there is no table of contents to click on.

An C example is attached, extracted from the user manual

[hgl]

Next I tested the histogram function. 10E7 periods sampled in a histogram with 2048 bins. Span of the histogram is 100ns, each with 50ps bins and an offset of 50ns. So we have a histogram from 50 to 150ns. I don't have a graphic in my program yet, so I took a picture of the memory in the debugger.

[hgl]

The histogram data is also big endian and the image of the last post is useless. 
After the conversion it looks more like a histogram 

[hgl]

It looks like everything is working fine. Now it's time to improve my "trial and error code" and build a GUI and also for the other VXI instruments that I have.

My measuring system consists of:
1 HP E8401A VXI rack,
1 Agilent E8491B controller,
1 HP E1740A Time Interval Analyzer,
2 HP E1412A 6 1/2 digit multimeter,
and a slot card from VXI Technology with
2 VM2710A 6 1/2 digit multimeters and
1 VM3608A digital to analog converter 16 channels with 16 bit resolution
as sub modules.

[maxwell3e10]

Thanks for sharing these data. It looks like the RMS noise is about 30 psec? I wonder if its possible to setup time stamp measurements to detect every 10th zero crossing or so. That will allow one to extend the total time interval closer to 1 sec. Then one can look for frequency deviation by fitting the time stamps to a straight line. It would be interesting to see if E1740 is better than HP53310 at frequency measurements.

[hgl]

The maximum measurement time depends on the internal memory size and the frequency. For 1-channel measurements the maximum frequency is 80Mhz and the shortest time between 2 timestamps is 12.5ns. You have 2 options to extend the measuring time, decrease the resolution or use what they call pacing = Timestamps every nth edge. There is also a random pacing feature. Another possibility is to take n measurements and read out the mean value. This increases the resolution but does not save any internal storage space, because the mean value is calculated after the timestamps have been saved. And finally, you can use an external loop to read the mean values ​​for long-term measurements and save them on the PC.

Max timestamps = 524287.
From user manual page 404:
Resolution (LSB): 50 ps  (variable in binary steps up to 400 ns to increase maximum TI)
RMSjitter: <100 ps
Peak-peak jitter (for 1010 measurements): 500 ps

[maxwell3e10]

For frequency estimation its best to spread the maximum number of time stamps over a longer time, but they have to be done continuously. So it would be best to use the pacing feature to measure every 10th edge. That would give 0.5 sec measurement time of 10 MHz oscillator and one could get a pretty good frequency estimate from the slope.

[hgl]

I did and it looks like this 

The OCXO is ref out from my  BG7TBL counter.

[maxwell3e10]

Are you using an external clock for E1740 locked to the same source of 10 MHz? It seems this plot pacing10_timdev.JPG shows too much time deviation at longer times?

Does this plot pacing10_freqdiff.JPG  show the difference between 1 usec and measured time difference of the two edges? It would be interesting to integrate it (add successively each point). This will show the evolution of the cumulative time (phase) difference.

[hgl]

Yes reference ist locked to signal. 

I read the calculated frequencies from TIA. Maybe it would be better to read the interval times or the timestamps.

[maxwell3e10]

I read the calculated frequencies from TIA. Maybe it would be better to read the interval times or the timestamps.

Is the frequency calculated just as a reciprocal of each period? With time stamps usually one gets times between successive zero crossings, so they need to be added together to calculate total time. For some of the plots it's hard for me to tell what are the units on the vertical axis?

[hgl]

I think so, told the TIA to measure intervals and give me frequencies back.

The measurement data are 11Mbytes. I guess that's too much to upload here

Statistics about the measurement:

min	9,956246961595E+06
max	1,004413928396E+07
max-min	8,789232236815E+04
stddev	4,219388119433E+03
mean	1,000004548291E+07

[maxwell3e10]

I'd be interested in analyzing the data. You can share it using zippyshare, for example.

One of the questions is long-term drift of time stamps. With averaging enough edges one can get random noise down to ~1 psec. But if there is a drift of say 1 psec over 1 sec of measurements it puts a limit on frequency stability of 10^(-12).

[hgl]

The maximum measuring time depends on resolution. For 50 ps it is 3.2µs. Therefore I can set pacing to max 32, otherwise there will be an overflow in the internal counter and time aliasing. 500,000 samples with pacing 30 results in a measuring time of 1.5 seconds.
In meantime i have reached 4 minutes for reading out 500,000 timestamps, calculating the frequency and saving in a file. It would be possible to generate a new file every 5 minutes. Histogram measurements can take up to 1E12 samples.

[maxwell3e10]

Yes, just a single 1.5 sec long measurement would be good for looking at the drift. Its best to just save the timestamps themselves, otherwise there can be round-off error in frequency calculation.
It doesn't seem like one could do continuous frequency measurements for longer without loosing resolution.