Frequency counter resolution

[grumpydoc]

So, just putting the finishing touches to the latest repair project - a Racal Dana 1998 1300Mhz frequency counter. No photos of this one I'm afraid - partly because I forgot to take any "pre" photos and partly because there's already been a detailed teardown of a 1992 universal counter timer on the forum. The 1998 is very similar apart from the front panel and firmware.

I think this one is ex MOD, probably Navy because it looks as though it has been used on board ship, or at any rate a damp and possibly salty environment  - heavily corroded around the transformer and back of the PCB but fairly easily rescued with a good clean and resoldering a few joints.

Anyway, I was testing it and all seemed well. It has the 04E high stability oscillator which is nice and without touching the calibration it's accurate to about 5 parts in 10⁸ - sadly my GPS disciplined oscillator has died so full calibration will have to wait. I'll check it against my FE-5680A when I get chance.

However - and the real reason behind the post, at 1kHz there was a lot of difference between successive readings - initially I thought it was a fault but tried two signal generators and also a 1991 counter-timer that I picked up at the same time. All four combinations yielded the same result - the last three or four digits were effectively random.

But then I started thinking about it. How do frequency counters produce 8, 9 or 10 digit resolution at frequencies of 1kHz or so? Or any frequency for that matter?

I know there are two basic techniques . First the traditional count the input signal for a fixed period. Well, count 1kHz for 1 second and you've got a resolution of 1Hz or 1 in 10³, to get 9 digit resolution would require a gate time of 1x10⁶ seconds - personally I'd rather not wait 11 and a half days for the frequency counter to produce a result.

Alternatively count timebase pulses - the 1998 has a 10MHz reference. That's 1x10⁴ pulses per period of the input signal. Great, we've gone from three to four digits :-/

I can see that counting multiple input signal periods can be used, so you could get 7 digit resolution by counting 1000 cycles of the input signal with a 1 second gate time - but the 1998 will display 9 digits at a 1s gate time - I don't understand where the extra resolution comes from.

Maybe a modern FPGA based design could multiply the reference clock up to a GHz to get that sort of resolution but this is a late 1980's design ( the 1991 I have was built in...... 1991 and the 1998 was built in 1994) so I doubt it's taking that approach.

How does it come up with 8 or 9 digit resolution for a 1kHz input?

[pickle9000]

Does it have a 1 / 0.1 gate speed switch?

...mike

[tekfan]

This should explain how high resolution at low frequency is achieved: http://www.best-microcontroller-projects.com/article-frequency-counter.html

[grumpydoc]

Does it have a 1 / 0.1 gate speed switch?

It has several gate times/resolutions but the resolution always seems higher than it should be for the gate time.

This should explain how high resolution at low frequency is achieved

Yes, I described that but I don't see how you'd achieve the resolution that the counter is displaying.

I suppose that if you just calculate the reciprocal to 9 digits and display it +/- 1 or two counts of the timebase pulses would cause the least significant three or four digits to change quite a bit - that could be what's happening. In which case you might as well not have a 10 digit display.....

[alm]

Reciprocal counting with a 10 MHz reference frequency gives you 7 digits of resolution per second of gate time. If the input frequency is not an integer multiple of the reference frequency, then there will be a small time lag between the last trigger from the reference signal and the last trigger from the input signal. Racal has a Timing Error Circuit (TEC) that measures this time lag and uses it to gain two extra digits of resolution. You may be able to find more details on this if you can find a patent for this technique.

[w2aew]

Some counters use a reciprocal counting method.  They'll count the number of internal clock cycles inside a period of the input signal.  In many cases, the 'partial' bits at either end are measured by starting controlled current source into a fixed capacitor at the trigger points (start of signal, start of each clock pulse), and then stop the charge current at the next trigger point (start of next cycle, start of next clock).  The voltage across the capacitor is directly proportional to the amount of time between the trigger points.  The two partial clock periods (one at the beginning and one at the end) are added to the clock period counter.  The voltage achieved during a full clock cycle is used as a calibration to measure the partial periods at the edges of the input signal.

[grumpydoc]

Racal has a Timing Error Circuit...

In many cases, the 'partial' bits ... are measured...

OK, thanks - that sounds interesting. The very brief mention of this technique in the service manual (no real detail) makes a bit of sense now.

The first 6 or 7 digits are stable, it's the last three which change significantly from reading to reading - does that suggest there could be a fault in this measurement?

That said I presume this is all handled in the Racal custom chip or in the firmware so I'm not sure how it could fail if the counters otherwise work and for two to fail in the same way also seems a bit of a stretch.

I'll review the schematic & have a look if there are any discreet components involved in the measurement.

[alm]

I believe the TEC is in a dedicated ASIC, no idea what the failure rate of this part is. Does it do the same when you feed it a signal from its own 10MHz reference output? Are you sure it's not jitter in your signal generator? I wouldn't expect the frequency from a basic RC oscillator (as found in many analog function/pulse/sinewave generators) to be stable down to the 1 ppm.

[Rufus]

However - and the real reason behind the post, at 1kHz there was a lot of difference between successive readings - initially I thought it was a fault but tried two signal generators and also a 1991 counter-timer that I picked up at the same time. All four combinations yielded the same result - the last three or four digits were effectively random.

Measuring what at 1kHz?

Consider a 1kHz sine wave of some amplitude and the voltage slew rate as it passes through the counter trigger level. A tiny amount of noise or uncertainty in trigger threshold detection results in a lot of digits of jitter when you have an effective 1GHz clock from the interpolation thing the Racals have.

Try measuring a square wave and see how/if the jitter changes.

That said I have a 1992 and it does seem to have this problem worse than other counters, perhaps the trigger circuit is a bit noisy. Also other counters tend to have gate time controls accumulating over a varying number of input cycles which divides the threshold uncertainty by the number of cycles. The 1992 seems to use the minimum gate time required to achieve the set resolution.

[grumpydoc]

Does it do the same when you feed it a signal from its own 10MHz reference output?

No, that reads 10MHz exactly to whatever precision is selected. External signals in the 10-100MHz range produce stable readings as well.

Are you sure it's not jitter in your signal generator?

I've considered this, neither source is a simple RC oscillator though. I have an OR-X 660 50MHz AWG - that has a 10MHz TXCO reference and the 2nd sig gen is a Marconi 2022 which has an ovened reference. In the case of the Marconi the measurements were done at 10KHz as that is the lowest frequency it will generate. Output from either gives stable readings at 10MHz (and 100MHz for the Marconi) but it's certainly possible that at 1 or 10kHz there could be timing jitter.

Measuring what at 1kHz

Trigger jitter is certainly also possible. I've measured sine from the Marconi, sine and square from the OR-X - perhaps a slight improvement with square but it doesn't make the problem just vanish. Rise time from the OR-X is 4-5ns when producing square wave output.

One thing it isn't is the oscillator in the 1998 warming up - it takes about 20-30 minutes for it to settle down and I've allowed for this before taking measurements. It's obvious when the warm-up is taking place as the readings change continuously but always in the same direction. Then there's a bit of overshoot and the readings change in the opposite direction before settling down.

That said I have a 1992 and it does seem to have this problem worse than other counters

Ah, that's interesting - almost certainly not a fault if a totally unrelated 1992 shows the same behaviour. Perhaps just something to be aware of with these counters.

[Rufus]

That said I have a 1992 and it does seem to have this problem worse than other counters

Ah, that's interesting - almost certainly not a fault if a totally unrelated 1992 shows the same behaviour. Perhaps just something to be aware of with these counters.

Actually I just checked and it is a 1991. With it set to show 5 decimal places of Hz at 1kHz I feed a 1v pk-pk sine ware and it shows around 500 digits of jitter. 1v pk-pk square wave from the same generator shows about 50 digits of jitter (it is an arb so the square wave will have some jitter, not sure on the rise time). 1v pk-pk pulse from the same generator shows 1 digit of jitter. Pulse from the generator isn't arb-derived so it doesn't have much jitter and it has controlled rise/fall times of about 5ns.

When I set the pulse rise/fall time to 20us the counter shows about 40 digits of jitter.

[grumpydoc]

I was thinking how to check this - one idea I hit upon was to hook the 1991 and 1998 to the same signal (1kHz square from the OR-X) and observe the correlation (or not) between the changes in the two readings. The idea being that if the jitter were in the input signal both counters would show similar reading to reading deltas, even if slight differences in the timebase oscillators made the absolute readings differ a little.

 I videoed half a minute or so to play back in slow motion so I could actually jot down the readings.

Here is the result. Both counters were set to 10 digit resolution (ie 1kHz would display as 1000.000000Hz) and just the last four digits are shown

1991    Delta   1998    Delta
9899            9843
9887    -12     0038    +95     
9890    +3      9861    -177
9801    -89     9953    +92
9889    +88     0043    +90
9893    +4      0032    -11
9800    -93     9948    -84
9901    +101    0071    +123
0005    +104    0035    -36
9989    -16     0052    +17
9999    +10     0065    +13
9910    -89     0054    -11
9916    +6      9958    -96
9796    -120    9859    -99
9913    +117    0053    +194
9921    +8      9968    -85
0019    +98     9863    -105
9984    -35     9966    +103
9917    -67     9976    +10
9916    -1      9966    -10
0019    +103    9965    -1
9925    -94     0098    +133
9910    -15     0069    -29
9931    +21     9976    -93

Ideally the display updates would be simultaneous - I'd got them about the same by eye but the video showed that the 1998 was updating about 100ms after the 1991.

I don't really see a close correlation between the deltas which makes me doubt that the jitter is in the input signal. Having said that we're talking about an 0.2ppm change reading to reading which isn't large.  Sine vs square wave showed more variation in the sine wave - perhaps up to 500 counts between successive readings. Like Rufus using the pulse output on the generator I could get the variation down to single figures. Slowing the input signal to 10Hz gives very large deltas between readings.

I'm not quite sure if I've proved it but it looks like trigger jitter is the culprit. I might connect both counters to a single 10MHz reference and repeat the exercise.

Thoughts?