Enhanced resolution mode for universal counters - Page 1
Forum section: electronics / testgear

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: August 10, 2017, 10:06:42 pm
content: I've been looking for a high resolution counter that can measure frequency with "Enhanced resolution" for short gate times. In enhanced resolution the counter uses the time not only of the first and the last signal trigger inside the gate time, but the time of intermediate triggers as well. As a result, the resolution goes as 1/Gate Time 1/Sqrt(Frequency/Gate time). These counting modes also go by the name Lambda or Omega. For example in Lambda mode, the counter calculates the average frequency for all overlapping pairs of triggers separated by one half of the gate time. In Omega mode one does a linear regression on the array of timestamps of triggers. In these modes both the number of displayed digits and the rms noise is generally smaller than for usual reciprocal counting, which only goes as 1/Gate time.As I started to look for this specification, I realized that newer fancy counters, such as Keysight 53230A and Tek FCA3100 (Pendulum CNT91) are relatively slow. It appears Keysight only applies enhanced resolution for gate time of greater than 10 msec and Pendulum only uses it for gate time of greater than 200 msec. Do I understand the datasheets correctly? Or perhaps someone can experimentally test it?On the other hand, older counters Keysight 53132A and Picotest U6200 use enhanced resolution down to 1 msec. I currently use Picotest and it generally works well, there is only one little problem.I need to make measurements that are externally armed (I am measuring frequency of a short burst). In Picotest, there is no enhanced resolution in externally armed mode. I can understand the reason when both start and stop are externally armed, but it should work if only start is triggered and stop is given by fixed time. For Keysight 53132A the spec sheet is not entirely clear on this issue, but it may have the same problem, it would be good to test.Does anyone know of other counter models available that use enhanced resolution?

author: DaJMasta
author_rank: Super Contributor
timestamp: August 10, 2017, 10:44:02 pm
content: What kind of resolution are you looking for? The FCA series goes down to 50ps timestamps and the 53230 has a 20ps timestamp resolution... and that's pretty quick.If you need short, very quick bursts you could just be running into to the data handling speed of the instrument - the 53230 can store a million timestamps a second, which is a far cry from every waveform in frequent short bursts. If the base resolution is reasonable, one approach could be to just catch and time the first pulse of the burst with single shot timing, then you could take those and average them to increase the resolution. There's also the burst functionality for the microwave side of the 53230 (option 150 on the Keysight, maybe the CNT9X based ones too?), there's some documentation for how it works in the datasheet, perhaps it could be something like what you're looking for? If you can afford to ignore several bursts for the sake of fully timing out one of them, maybe that could be an alternate approach - measuring a burst and then ignoring the rest until the system can rearm the trigger to capture the next.If you've got to get all of them... you may just need a really, really high bandwidth acquisition system, which I think may be better suited to a fast scope that can be locked to an external reference and then a little software to analyze the trigger points for each pulse. So long as they can be captured and stored fully, you can effectively process that data to as much precision as you want, then it just comes down to how low noise your input is to keep the triggering consistent. And with such timestamps being available in the counters, you're already fairly close to the jitter on the inputs even when timing a square pulse.To my (limited) knowledge, there isn't a commercially available counter that will do faster than 20ps single shot resolution, but there's a chance that there's one that can capture more data points to be better suited to timing differing bursts. Not that I have a use for such a beast, but I'd be interested if you came across something that did the job properly - would be a pretty impressive timing device.

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: August 11, 2017, 01:57:45 am
content: The counter timing resolution is not really a limiting factor because the signal itself is noisy, so the trigger error is about 1 nsec. The goal is to extract the best possible frequency from a short burst of a few msec that repeats quickly. So if I start saving timestamps and then analyze them offline, it will turn into a mess.The Picotest U6200 can almost do what I need except for triggering, that is why I find it frustrating that newer counters can't do it. Maybe they use more fancy Omega weighting instead of Delta, but its surprising that they are slower than older generation of counters.I am leaning toward a kludge I used in the past, which is to take out one of the GPIB lines (I have to remind myself which one) and use it as a kind of trigger to issue a well-timed GPIB command that initiates the counting.

author: DaJMasta
author_rank: Super Contributor
timestamp: August 11, 2017, 02:23:14 am
content: Hmmm, then could you use an external arming signal as a more proper looking kludge? I've got a PM6690 (CNT90 rebadge, same as the FCA3000 series but the 3100 is a CNT91) and the basic arming settings you can trigger off an external signal and the minimum measurement duration is 20ns. You still may run into memory amount/speed problems if you want to catch every pulse, but if you can have a trigger pulse at the start of your burst (and you can configure offset if you need to retime it).A quick test hooking up my sig gen to the counter, with an 80MHz sine wave on input A, a measurement time of 20ns, and using channel B, a 100kHz square wave from the same sig gen as the arm signal, it can capture around a thousand measurements per second. Of course, that only gives you like a 3 digit base resolution... but it is doing it pretty fast - though that gate light doesn't look happy all the timeI'm sure it's not sampling bursts at a totally even rate.

author: Kleinstein
author_rank: Super Contributor
timestamp: August 11, 2017, 11:02:24 am
content: It depends on the type of noise in the signal, whether the resolution enhancement really gives lower noise than just using high resolution time stamping for the first and last trigger event. If the noise is frequency noise (e.g. probing a good signal from a not so stable oscillator) time stamping just at start and end is best. If the noise is more like phase noise or trigger noise (e.g. probing a disturbed signal from an otherwise very good oscillator - e.g. mains frequency), the omega type (linear regression of trigger times) mode is best. In intermediate cases intermediate types (e.g. different weights) should work better.If triggering is the problem, one might be even be better of digitizing the waveform and do the frequency calculation from the full waveform and not just the zero crossings. Good filtering of the signal before triggering might be nearly as good, but can be tricky due to settling times.Recoding all the time stamps and doing the math on the data offline might produce a lot of data. However storage it not that expensive any more. One could also do a kind of real time calculation: the calculation of the period time is just a linear function, just a weighted sum and thus very well doable even for a µC in real time. It might get slightly tricky as it might need high data widths (like 96 Bit integers), that are not well supported by some compilers.Besides the time resolution the hardware of the counters might also have a limit on how fast they can do high resolution time stamps.I have a self build counter to measurement in a kind of Lambda mode - using a small 8 bit µC, with just 2 kBytes of code.

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: August 11, 2017, 01:19:35 pm
content: Quote from: DaJMasta on August 11, 2017, 02:23:14 amThat is exactly the problem. The enhanced resolution mode gets disabled when I use external arming. I can understand the reason when both start and stop are timed externally (because one needs to know the length of the gate ahead of the time to do the calculation quickly), but if only start is triggered externally, it should work in principle.

author: DaJMasta
author_rank: Super Contributor
timestamp: August 11, 2017, 08:54:45 pm
content: Maybe I'm not understanding it fully then... but I think the capability may already be in there.Instead of using the external arming signal, I switched the same counter to burst mode, 1uS burst length, and it's now giving me 5 digits of resolution with about 8 LSB of fluctuations. I don't have a burst signal in the sig gen that seems to be what you're describing, but a continuous 80MHz is telling me 82 cycles per sample and a pulse repetition frequency of 975.6kHz, which means it is actually catching everything - even if it's not doing the full calculation for every "burst".Though in the same way as it worked with the external arm, if instead of reading the "Value" button setting, and I go to the stat/plot button, it does build up more detailed resolution from many samples. At the above settings, I'm getting maybe 600 samples per second, but as the sample count increases, the counter adds digits of resolution for the mean (unless it's really noisy, in which case it can actually take them away) - it only took a few seconds to get to 7 digits of resolution, though the samples seem noisy enough that it may take some time to get to 8 digits (4kHz Allan deviation reported after 150k samples).So I guess it comes down to the burst signal that you've got. If each burst is at a potentially different frequency, the only way to get a really, really detailed read on its frequency would be to capture the full burst with a fast acquisition system and run some analysis on it - this single point trigger doesn't give you the same resolution as what you can calculate given the full analog waveform. However, if your bursts are at the same frequency, this counter (CNT90) seems to be perfectly happy to capture and average them together for increased resolution, then the longer the capture window is, the more detail you'll see. I was seeing 3 digits of resolution with a 20ns window because it wasn't even triggering off two complete periods with an 80MHz signal, but using the statistics, it takes about 2 seconds of capturing to get to 5 digits and I've gotten up to 6.If the signal was at a fixed frequency but you were trying to measure gradual drift in it, you'd be able to see it in the graphed points, but you could set the statistics to just reset after 10k samples or something, so you would get a mean of the current frequency rather than the complete duration you've been capturing for.

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: August 11, 2017, 09:57:24 pm
content: Thanks for running the tests. Looks like CNT90 is rather fancy with the statistics.The simplest test to see if its using enhanced resolution is to look at RMS or LSB as a function of gate time.Say you set the gate time to 0.1 msec and look at number of digits or calculate the standard deviation of a bunch of points. Then increase the gate time to 10 msec. Does the number of digits increase by 2 or by 3? Does the scatter of frequencies go down by 2 or by 3 orders of magnitude? With enhanced resolution the improvement should go as (gate time)^(3/2).I looked into the noise of the Picotest U6200 using Keysight 33522 generator. Set one channel to make a sine wave, the other channel to generate gaussian noise and use dual channel add function. I set the gaussian noise to 10mVrms, so its higher than internal counter noise and bandwidth to 10 MHz, higher than the sine frequency of around 1 MHz. Then one can calculate all the terms in the equation for rms noise they give in the counter manual. My measurements are pretty much in agreement with the formula, maybe 10-20% higher. And the frequency resolution improves as (gate time)^(3/2), if I use timed gating.In the mean time I think I almost figured out how to "trigger" things with GPIB by pulling the NRFD (not ready for data) line low.

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: August 14, 2017, 07:55:30 pm
content: Well, I setup the Picotest counter using GPIB "trigger" on NRFD line. It works OK, the time jitter is on the order 200-300 microsec. So I can measure a 2.5 msec long burst using a 2 msec gate time with occasional errors. The actual processing time is on other order of 30 msec, so measure only some pulses.This will work for now, but would be nice to find a counter that can use external trigger and enhanced resolution at the same time.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: August 14, 2017, 08:06:18 pm
content: Why use counter at all for this kind of task? Seems more like scope job to me.

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: August 14, 2017, 08:31:14 pm
content: Need to measure the frequency of the burst to 8 digits.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: August 14, 2017, 08:45:45 pm
content: Quote from: maxwell3e10 on August 14, 2017, 08:31:14 pm...but not quite there yet, reading how its going so far?What is actual freq?

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: August 14, 2017, 09:49:27 pm
content: Picotest counter works fine, gives me 9 digits (1 mHz resolution) for frequency around 200 kHz and gate time of 1 msec. The whole problem is to trigger it so the 1 msec measurement happens at the right instant.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: August 14, 2017, 10:03:01 pm
content: In such low freq range ~8 digits quite realistic with simple scope if freq inside burst is stable and can apply stats. Degrades to ~5 digits on 100MHz. Possibly digit better on less simple scope. Naturally triggering no prob. I did little experimentation once, if scope can be used as counter:https://www.eevblog.com/forum/testgear/picoscope-2000/msg1156850/#msg1156850This is on constant signal, and lowest tried was ~500kHz. But no difference might be as well bursts.

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: August 15, 2017, 04:57:39 am
content: Some Keysight scopes have an 8-digit counter mode, but I think most scopes display much fewer digits. While its possible in principle to implement an algorithm using scope data to find the frequency with high accuracy, a straight forward calculation using time of trigger crossings would be poor. A 5GS/sec scope has only 200 psec resolution, while 12-digit counters have 10-50 psec resolution. So one would need to use interpolation of vertical data to find trigger crossing times more accurately. Would be a nice feature to have.

author: DaJMasta
author_rank: Super Contributor
timestamp: August 15, 2017, 05:08:13 am
content: And if you know the shape of your source, that sort of interpolation is really the only way to get really, really high resolution in short bursts, there's a real limitation without repetition with counters that just trigger off a single point.Anyways, I gave a quick test on the CNT90 for reference, 200kHz signal and then adding a 1kHz arming signal.First, in burst mode with a 1ms measurement window:8 digits base resolution, but since it wasn't synchronous - only getting 300-350 acquisitions per second - it had a 1.35Hz peak to peak variation in about 100 seconds of measurement, though the Allan deviation was only 0.163HzThen using the 1kHz signal on channel B as the arming signal, the measurements per second decreased to maybe 150/sec, but the performance was nearly the same, 1.31Hz PP variation and 0.162Hz Adev in closer to 200s.Again, not exactly apples-to-apples with your application since I can't really generate those pulses, but the second test with the arming signal did manage to get to 11 digits of resolution on the mean in those close to 200s of sampling and the base single capture resolution was 8 digits.

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: August 15, 2017, 07:11:22 am
content: Thanks for making the measurements. From what I've seen in CNT90 manual, it starts using enhanced resolution (using more than two trigger points) if the gate time is longer than 200 msec. The number of digits should jump suddenly when the gate time exceeds that length.If the signal is a sine wave with a certain level of voltage noise (assuming the frequency and phase are stable) one can compare Cramer-Rao limit for fitting a sine wave to frequency counting using one of the enhanced resolution methods. They turn out to be similar to each other, within a factor of sqrt(2). The key parameter is Sqrt(BW/frequency), so if the signal is filtered to a bandwidth just a little above the frequency, then counting is almost as good as non-linear fitting of the digitized waveform.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: August 15, 2017, 08:12:26 am
content: Quote from: maxwell3e10 on August 15, 2017, 04:57:39 amI can measure down to sample jitter no prob on my scope (3ps RMS spec):On low freq its trivial. On higher decider will be if ETS could be enabled or not.Im on the run no access to proper gear but tried just to measure internal gen bursts set to 200kHz and got 200000.1236Hz which is probably gen error, not scope error.Also can measure any other horziontal stuff to high accuracy (duty etc).When get time will hook it up to MatLab to investigate further.

author: TurboTom
author_rank: Super Contributor
timestamp: August 15, 2017, 11:51:12 am
content: @Maxwell3e10:Did you consider the obsolete HP / Agilent 53310A Modulation Domain Analyzer? These instruments are quite affordable at times, should provide the requested accuracy (if I understood your requirements correctly) and also offer a lot of mathematics that you could do on the results. Even though the 53310A has been discontinued by Agilent more than fifteen years ago, there's no direct replacement for it. Unformtunately, there's only little information to be found on this instrument on-line except user manual and basic maintenance manuals. Might be worth a look, though.Cheers,Thomas

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: August 15, 2017, 05:54:32 pm
content: That's a good idea, ordered one!It does claim to make enhanced frequency measurements even for short gate times. The spec rms frequency noise for 1 msec gate time and 1 Vrms input sine wave is 100 mHz. That is worse than I can do with Picotest, which is about 20mHz. I am hoping it is somewhat pessimistic or related to larger input noise spec (600 uV rms vs 200uV rms). But it seems fast and can time trigger crossings at 1 MHz, as fast as the new53230 at a tenth of the price.

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: August 17, 2017, 06:48:50 pm
content: I got the HP53310A Modulation analyzer and it works really well!It basically matches the performance of Picotest in rms frequency noise, but also gives continuous frequency measurements. It uses enhanced resolution down to very short gate times (a 2 orders of magnitude change in gate time gives 3 orders of magnitude change in rms frequency noise).The only slightly confusing feature (which someone has mentioned on the forum before) is that the measurements have a low-pass filter. So, a 1 msec gate time corresponds to a bandwidth of roughly 250 Hz, not 500 Hz. If I set the gate time to 500usec, then the rms noise is about 30 mHz (vs. 20 mHz for Picotest at 1 msec gate time.) Another small problem is that the low pass filtering is not synchronous. Even if the measurements are triggered, there is flickering where the waveform switches between a triangle and square for frequency modulation 4 times slower than gate time.But these are just minor problems. Overall, its a very cool instrument, it responds very fast and has nice soft-key menus. If someone replaced the CRT with an LCD, you would never guess its a 25 year old device. Thanks, TurboTom for a great suggestion.