Fluke PM6690 12 digit/s frequency counter

[DaJMasta]

I snagged a used (and somewhat beat up) one of these counters and looked around a bit - doesn't seem to be a lot of info outside of the official docs (which do include a schematic!)  I figured I wanted to clean it up and check things out for myself anyways, so why not post pics.  I've also heard it suggested that the PM6690 is a rebadged Spectracom CNT-90, and given the look of the front panel and the specs, it did seem likely.  Well I can say for certain that is the case 

It's evident that my counter has been punched, scraped, and stuck to quite a bit in its lifetime, but best I can tell it's still in great shape.

And it's one of those long form factor units, next to it is a Siglent SDG2082X function gen


The unit powers up when plugged in and the fan starts whirring.... sort of annoying.  Over the next few minutes it cranks up at least 3 times to be rather loud for such an instrument.... but at least it's off in standby (though I'm sure the OCXO is still going)

The model number is a PM6690/AN, which isn't listed as an official spec in Fluke's datasheet... it's supposed to have a three digit code not a two letter one.  Also fluke never mentions a 2.7GHz channel C option, they start at 3GHz.  So I navigate to the information menu...


...and the installed option codes aren't listed on Fluke's datasheets..... but they are listed as valid options for the CNT-90.  The option 30 timebase is their mid tier OCXO (a notch under the best and two up from the base) and option 10 is the 3GHz input C - not the 2.7GHz specified on the front, but in the datasheet it breaks down the input voltage range for different bands and 2.7-3GHz is the lowest - maybe that wasn't to Fluke's desired spec so they said only 2.7GHz?  Also the firmware is from 2006, as is the boards, I found after I opened it up.

Of course, I knew the screen had some damage, but I didn't expect the backlight to die in the first hour - was making odd waving patterns in the beginning, then went to half brightness for a bit, then just went out.


It was time to dig into the thing.


Pretty clean inside, pretty solid construction, no loose bits and no obvious damage or mods (the cal sticker had been broken by someone before me!)  Also another confirmation that it basically is a CNT-90:


Thanks Bjorn!

The bottom of the board is just some decoupling:


The input C board:


The timebase, a quick google doesn't give me much, but given where the performance is and the option code, I have a good idea.


And hiding under the PSU there's actually a few chips... including this Sharp ARM SoC running the thing.



So I took off the front board with 2 screws (it's been all torx so far) and took a look.  The schematic made it easy to find the backlight power, and it's just 5V to some LEDs built into the screen.  I follow the trace and.... the solder joint is dry and looks cracked, one more on the other side of the screen too.  So a little flux and solder later, and the backlight is back on.  Still have some wavies in the screen (I scope probed it when it was dead and the power line was stable, but may be worth probing again), but the light has been going for hours and seems fine to me.

The noisy fan is actually a decent fan (NMB) that is pretty quiet uninstalled.  there's no vibration damping and because it's right up against the chassis, the fan grille actually blocks a lot of the airflow and makes most of the noise.  I have a quieter one I want to install instead and will use some rubber washers and a little extra distance as well, but I'm surprised the thing needs a fan.... the highest temps I could find on the board were high 40s Celsius with the noncontact thermometer.  Maybe they just have it to make sure things don't heat up too much for the OCXO when in a bad environment.  And these high 40s, low 40s on the FPGA, were enough to kick the fan up a couple of notches even with the top off.

I've got it measuring my GPSDO output and it seems to be pretty spot on for the specs (I though the GPSDO is not characterized or Cal'd, so it's unofficial), even with the top off the drift doesn't seem to be too much.  I'm quite happy with it so far, will have to hook it up to USB and see if there's some new firmware and whatnot, then see how it triggers off other waves with the function gen - maybe see how much the function gen jitters by piping the GPSDO into both of them.

[DimitriP]

...it also looks like your power supply caps woll need some attention ...sooner or later

[TiN]

I was looking for CNT90 some time ago, but decided to skip. Ain't it 14 digit resolution though?
Nice clean construction and fun to see impedance matching cutouts on ground plane on the bottom

[DaJMasta]

The CNT90 and 91 are both 12 digit/s counters, but both have 14 digits worth when the gate time is long enough or when you're averaging a bunch of samples (the pic with no backlight is 14 digits, but it had been going for a bit).


That front cap does look a little suspect in the pic, but it seems less in person - maybe the camera angle?  Anyways they're Nippon Chemi Cons and it's only 10, I at least hope those caps still have some life left in them!


Looking for the part number on the input C board, apparently this is an option for an earlier fluke (Phillips?) counter that actually did top out at 2.7 GHz.  My guess is they had some left over from the previous generation and wanted to use them, but didn't have so many as to make it an official SKU in the more recent documentation.  Since it probably performs nearly like the Pendulum equivalent 3GHz option board, it probably just identifies as one of those in the firmware.  So this particular unit may actually be slightly different than just a rebrand.

[bitseeker]

Aren't models with /AF or /AN suffixes often an indication that it's for the military? Ah, yes, this counter has an NSN: http://www.parttarget.com/6625-01-530-9444_6625015309444_PM6690-AN.html/-4ED76C21-2112-4800-AF96-895C96EA4505

Perhaps that would account for the variations you see from normal SKU.

Nice job with the fixes and lots of pictures.

[BloodyCactus]

I just picked one of these up, mine has a firmware of 1.21s dec 2007, and timebase 030 from october 2008, same options 10 C input too.

Its a nice step up from my racal dana 1992.

[DaJMasta]

I imagine it is!  I wonder if there's a way to get firmware online from fluke, a basic search hasn't shown anything, but I haven't actually tried contacting them.

Haven't had particular problems with my firmware, so there hasn't been a big reason to look.

I've done a bit of programming since the first post and the VISA drivers seem to work pretty well.  The examples they provide in the programming manual use directional quotes which don't compile properly if just pasted into a code document, but it seems to respond fine to all the commands I've tried so far.  I suppose it's to be expected, but it's nice to know it all works.

[TiN]

I just picked one of these up...

Oh, that was you for 300$ one lately. I wanted it , but forgot to bid....  GAS outbreak prevented... 
Let's see some pics!

[raileon]

I imagine it is!  I wonder if there's a way to get firmware online from fluke, a basic search hasn't shown anything, but I haven't actually tried contacting them.

The Spectracom CNT-9X v1.28 update worked just fine on my PM6690.

https://spectracom.com/get-help/product-software

Check the doc file in the zip. The Fluke PM6690 is listed as a supported product.

[BloodyCactus]

I imagine it is!  I wonder if there's a way to get firmware online from fluke, a basic search hasn't shown anything, but I haven't actually tried contacting them.

The Spectracom CNT-9X v1.28 update worked just fine on my PM6690.

https://spectracom.com/get-help/product-software

Check the doc file in the zip. The Fluke PM6690 is listed as a supported product.

cool!

@TiN
not much difference inside from the above pics

I think, more pins on the prescaler connector


different OCXO. MV197. I believe the upgrade is MV209

[DaJMasta]

Well after a hair-raising 15 minutes, my 6690 is also running the 1.28 firmware.


Went through the normal update procedure, found the instrument and firmware just fine, clicked the button.  Loaded onto the unit, updated the unit.... at about 85% of the progress bar it hung and the screen went from the normal updating screen to the center saying "firmware updating" but the animated icon stopped and the outside of the screen looked like the normal UI....

Gave it like 15 minutes and no progress, the updater had also hung.  Powering down the unit from the front wasn't responsive, removing the USB cable didn't make it responsive... had to pull the plug.  Plugged it back in and it auto-ons, plugged the USB back in.... normal UI loads, and when the USB reconnects, the updater says it finished properly.

Well the about screen confirms the new firmware and it's back to working as I expect.... so i guess it was actually successful 

[BloodyCactus]

does the model retain its identification in the about as a FLUKE PM6690 or is it now a CNT-90?

[DaJMasta]

Still IDs as a PM6690 in the menu and over USB.

[BloodyCactus]

yeah I ran it, device rebooted and it shows updated to 1.28s. I am currently running the Calibrate Internals command it suggested.

[DaJMasta]

Finally got myself an RF generator with a good bit of bandwidth so I decided to check out the performance of my 2.7GHz input C.  At 0dBm it will go up to 3.067GHz, but at +10dBm, I get a cool 3.089GHz.  Not bad for a 2.7GHz input.


Also from browsing around and looking at counters that are available, I think I can match the Tektronix MCA series counters to the CNT-90 (same as this one), and their FCA series is the CNT-91 based version with a 50ps timestamp resolution.  In terms of commercial availability, it seems like this and Keysight's 50ps timestamp are second only to the Keysight 53230a counter - same 12 digits a second, but a 20ps timestamp resolution.  I think I've gone far enough over the timenut threshold to drool over it, but at at least $3000 used, it's not really on my radar 

[coromonadalix]

lucky you   

[volvo_nut_v70]

Having just bought one of these guys I noticed that there is a calibration utility called for in the manual referenced as PM6690.zip. The kind folks at Fluke searched their basement and lo and behold they found it! This should also work on the Pendulum CNT-90, CNT-91, Tektronix FCA3000, FCA3001, FCA3020 and MCA 3000.

Unfortunately it's too big for adding as an attachment, so it's on KO4BB site:

http://www.ko4bb.com/getsimple/index.php?id=manuals&dir=07_Recent_Uploads

As a side note, it had no option C so I added a PM9624 clone off Ebay, seems to work fine! Still have to update the firmware.....

Anyone ever replace the STD timebase with an OCXO, if so which one did you use?

[DaJMasta]

I know there's a PM66XX compatible OXCO upgrade available on ebay, I believe Dave's got a video of putting one in a PM6685 or something similar, and I think the header in the space next to the power supply would be it, though in my counter it was directly populated on the board.  It's supposed to work on PM6690s.

Since that's the case, though, You may be able to just drop in an OXCO with a compatible pinout directly into the board, it looks like the upgrade modules don't have much else on the board besides the oscillator, but it would be work at least looking over the board to make sure yours has the parts around it still populated.

[BloodyCactus]

mine is soldered directly to the board, I worked out what replacement would be. Im not sure if there is a header there or not (I didnt see one when I looked, from memory...). I think a MV209 would work to upgrade to OCXO. I just plug my rubidium source into it.

[Jörg]

Hi, I have tried the fluke PM 6690 Utiliiy with my TEK FCA 3000 .  Basically, the software that works.
After I was asked my serial number and the confirmed to enter, the FCA 3000 rebooted. So far so good, the PM6690 utility has been renamed my TEK FCA 3000 .
On the display and via the USB port, the TEK logs now with fluke PM 6690. I found there is no way to undo that. The programmer manual shows no command to write the IDN. But somehow it should work. The utility has done it without prior notice.

[picitup]

Hi All

I've just bought a Pendulum CNT-90 but I can't seem to get it to work as expected.  I'm inputting a 10MHz square wave @280mv pp from CH1 on my Siglent SDG1025 which is clocked by my BG7TBL gpsdo into the 10Mhz Ext Ref input.  The display shows EXT ref to show it has accepted the signal.

The I connected CH2 of my sig Gen to Input A on the CNT-90 and supplied a 10MHz sine wave at 5v.

The issue is that whatever gate speed/resolution I choose, the last couple of digits on the CNT-90 dance around by about 20 counts.  I had assumed that if the extref is essentially the same clock, the display should be crack on and the display would be. for example, 10.000 000 000 000 but even on faster gate times like 100mS, the last couple if digits dance around, effectively showing more error for faster gate times.

I've played around with different voltage levels for ext ref and sine/square and while these do make a small difference, the display doesn't zero.

Am I missing something here?

Thanks

Steve

[picitup]

Oh, I forgot to say, performing the same test on my TF930 with 100 second gate/10 digits, the display is zeroed as expected, eg:

10.00000000

And is rock solid.

[jpb]

Hi All

I've just bought a Pendulum CNT-90 but I can't seem to get it to work as expected.  I'm inputting a 10MHz square wave @280mv pp from CH1 on my Siglent SDG1025 which is clocked by my BG7TBL gpsdo into the 10Mhz Ext Ref input.  The display shows EXT ref to show it has accepted the signal.

The I connected CH2 of my sig Gen to Input A on the CNT-90 and supplied a 10MHz sine wave at 5v.

The issue is that whatever gate speed/resolution I choose, the last couple of digits on the CNT-90 dance around by about 20 counts.  I had assumed that if the extref is essentially the same clock, the display should be crack on and the display would be. for example, 10.000 000 000 000 but even on faster gate times like 100mS, the last couple if digits dance around, effectively showing more error for faster gate times.

I've played around with different voltage levels for ext ref and sine/square and while these do make a small difference, the display doesn't zero.

Am I missing something here?

Thanks

Steve

I quickly did the experiment on my FCA3100 with a 10 second gate (to get enough digits) and it flips between 9.999999999etc and 10.00000etc:

See the attached picture.

I did set the sine to only 500mV, perhaps 5V is a little high.

[jpb]

When I extend the gate time to 100 secs to get 13 figures then on the first reading it is 9.999 999 999 995.

Your Siglent generator may not be as stable as my Agilent one - if you have a splitter you could use that instead (so it is exactly the same signal).

Also remember the TTi just does whole counts while the CNT-90 is interpolating - the TTi will ignore the noise until it gets as big as a whole count.

But even so, I'd expect your results to be a bit better than you describe.

[DaJMasta]

I think what you're probably seeing is actual noise in the measurement.  Even when clocked from the same reference, that reference is used to control the PLL of an internal oscillator, so if it's averaging that at all or if the reaction time of the PLL isn't instant (and it isn't), there can be some noise that appears if the reference is changing at all (and even the OCXO in the BG7TBL does slightly - you can actually see shifts in the frequency with the DAC steps when measuring with this counter against a more stable reference).  There's also potential for noise in the triggering mechanism, and then there's the fact that you simply can't see the detail you see as fluctuating on the TTI counter - 20 counts on 12 digits is well under the noise you'd be able to see on a 10 digit display, so while there is some inherent noise in the counter (and the data sheet specifies it at length), I think the noise you're seeing is actually a product of the test system.

Just took my PM6690, 1 second gate time, auto trigger, frequency measurement of one of the distribution amplifier outputs of my PRS10 rubidium reference which is disciplined to a GPS PPS signal, which another of the distribution amplifier outputs feeds the external reference, let the counter warm up for a bit, and took some measurements.  In almost 1000 measurements, I'm seeing a peak to peak variation of less than 4 least significant digits at 12 digits per second, and an Allan deviation of 0.6 digits per second.  That's 2 and 3 digits below the displayed least significant digit of the TTI counter, so of course you're not going to see them.

Then, to get your 12 digits on the TTI, it's averaging the counts over the whole time, so the displayed mean in the images I took is actually the same sort of measurement, again showing a smaller noise figure to the point of not being able to be measured by the TTI, 2 uHz out at a 10MHz frequency is 2x10^-13... 0.2 parts per trillion

[Jörg]

Hello everyone.

I made a similar observation with my TEK FCA3000.

There are differences in the measurement of smart frequency (Continius time stamping) and without this technique as a conventional start stop counter.

I did these tests with my HP Z3805A GPSDO. A 10 MHz output for external reference, the other as the DUT to the input A or B of the FCA3000 counter.  I'll show a few images with sample time 1 sec, 2 sec, 5 sec and 100 seconds.
Averaged over the number of samples, a Sample time 5 seconds or more, show exactly 10 MHz at maximum resolution.

[Jörg]

Hello jpb.
I post a picture from my counter with the three LEDs. There you can see the "trigger a " LED. I don't know if the LCD backlight shines through from behind. This is independent of what I set on the device.
The behavior of the LCD is bad to describe. Everything looks right from the front. From the lateral angle it looks restless. A little as if horizontal, from bottom to top, strips of light go through.

Jörg

[jpb]

Hello jpb.
I post a picture from my counter with the three LEDs. There you can see the "trigger a " LED. I don't know if the LCD backlight shines through from behind. This is independent of what I set on the device.
The behavior of the LCD is bad to describe. Everything looks right from the front. From the lateral angle it looks restless. A little as if horizontal, from bottom to top, strips of light go through.

Jörg

I've not noticed this before, and it doesn't worry me but when I disconnect so the trigger is off then there is a little light bleed so that the trigger looks faintly green as in the attached photo (similar to yours).
I'm not sure why your gate light is on with no connection - we must have different settings - I've set mine to measure frequency back-to-back.

[coromonadalix]

backlight way to powerful  maybe you could dim it a little mod the circuit ??

[jpb]

backlight way to powerful  maybe you could dim it a little mod the circuit ??

Yes, it is rather bright - I poked around the menus to see if it was adjustable and couldn't find any options.
I'm a bit reluctant to poke around inside. The brightness doesn't bother me - it is not dazzling - the only concern would be the light burning out prematurely but presumably if there was such a problem with the design it would have emerged by now, it is not a particularly new counter and even in the Tek form it has been around for quite a few years.

[Jörg]

Hello jpb.
I post a picture from my counter with the three LEDs. There you can see the "trigger a " LED. I don't know if the LCD backlight shines through from behind. This is independent of what I set on the device.
The behavior of the LCD is bad to describe. Everything looks right from the front. From the lateral angle it looks restless. A little as if horizontal, from bottom to top, strips of light go through.

Jörg

I've not noticed this before, and it doesn't worry me but when I disconnect so the trigger is off then there is a little light bleed so that the trigger looks faintly green as in the attached photo (similar to yours).
I'm not sure why your gate light is on with no connection - we must have different settings - I've set mine to measure frequency back-to-back.

Hello jpb and thank you for your help.
I see on your picture the easy rest light of "Trigger A" LED is obviously normal.
To the time lights up the trigger LED, without a signal at the input. Depends on if I activate the channel A or B from the menu.
It was on my last photo not so. I don't know why.
Unfortunately, "Back to back" is a mode that is available only at the FCA3100 but not at the FCA3000.
The "Gate" LED lights on without a signal, if  "Smart Frequency" is active to "ON" or "AUTO" mode. If I press the "HOLD" button, the "GATE" LED goes out.
If you "Smart Frequency" switches "AUTO" and is under 200 ms measuring time, the device work as a conventional start-stop counter.
If "Smart Frequency" is set to "AUTO" and measuring time is 200 ms or more, the device works as continuous timestampng counter with linear regression.
When measuring times above 2 seconds, the device can operate only in the continuous timestamping mode.
The measurement results with and without "smart frequency" will differ slightly. To show I two statistical evaluations of the FCA3000 at 2 seconds measuring time per sample.

I'm sorry if my English reads slightly strangely. I gotta help me with a translation software.

Jörg

[jpb]

Thanks for highlighting smart frequency - you did so in an earlier post and I then checked my counter and found that it was on by default so I turned it off.

I can see that linear interpolation/regression will give a better average frequency value as you are reducing the dependence on the accuracy of the last measured point but on the other hand it makes it harder to determine what is being measured.

[Jörg]

Hello jpb. If you are not an engineer you must read first much on continuous time stamping with linear regression.
For optimal working with this counter, you must acquire much background knowledge. I am not an expert in this field and i wonder about different measurements,  depending on equipment setup.
We're talking about very high resolution frequency measurements, which can be adversely affected by many sources of error.
Depending on the type of error, the one or the other measuring methods can deliver better results.
I am still on the search for information, to better understanding this technique.
That between start-stop counting or continuous timestamping counting with linear regression, different results of the StdDev and AllanDev are, I understand quite well.
But that the MEAN result is always different averaged over the set of samples, I still do not understand.

[jpb]

Hello jpb. If you are not an engineer you must read first much on continuous time stamping with linear regression.
For optimal working with this counter, you must acquire much background knowledge. I am not an expert in this field and i wonder about different measurements,  depending on equipment setup.
We're talking about very high resolution frequency measurements, which can be adversely affected by many sources of error.
Depending on the type of error, the one or the other measuring methods can deliver better results.
I am still on the search for information, to better understanding this technique.
That between start-stop counting or continuous timestamping counting with linear regression, different results of the StdDev and AllanDev are, I understand quite well.
But that the MEAN result is always different averaged over the set of samples, I still do not understand.

I am an engineer by background, though I now work in software, and have done quite a lot of work in the past on curve fitting to measured data.

I think the difference is nothing to do with the source of noise but simply in the way the data is handled. If you have n points going from t1 to tn say, then the standard counter mode will treat this as (n-1) cycles in (tn-t1) seconds or a frequency of (n-1)/(tn-t1). In the linear regression mode the counter fits a least-squares (I'd guess) straight line to the data which may not exactly go through any of the points. The frequency is then the slope of the fitted line.

If you're looking for the best average frequency and assume that the points are all equally noisy then the slope is probably better - the variance in the slope is less than that of the difference in end points. For analysing the data further with ADEV I would guess that you probably want the actual phase measurements since different time periods are used when working on the same data - also some points may be glitches (outliers) and it is probably better to simply remove them rather than allow them to affect the measurements.

I think it is similar to the arguments that photographers have about jpeg and RAW camera data. The jpegs look good straight out of the camera but serious photographers want to work on the RAW data rather than lose information.

I would recommend Bob Riley's web site and in particular his book (available as a free pdf report) and his software Stable 32 which is now also free.

http://www.wriley.com/

http://www.stable32.com/Handbook.pdf

[jpb]

backlight way to powerful  maybe you could dim it a little mod the circuit ??

Yes, it is rather bright - I poked around the menus to see if it was adjustable and couldn't find any options.
I'm a bit reluctant to poke around inside. The brightness doesn't bother me - it is not dazzling - the only concern would be the light burning out prematurely but presumably if there was such a problem with the design it would have emerged by now, it is not a particularly new counter and even in the Tek form it has been around for quite a few years.

I've now done the unthinkable and actually looked at the manual!
The LCD screen contrast can be adjusted using the up and down arrows when there is no input expected. It is not the same as brightness but it does allow some adjustment.
Interestingly the screen inverts at one extreme and then I noticed that the screen inverts anyway (white on black) when viewed from an angle (polarisation I suppose).

[Jörg]

backlight way to powerful  maybe you could dim it a little mod the circuit ??

Yes, it is rather bright - I poked around the menus to see if it was adjustable and couldn't find any options.
I'm a bit reluctant to poke around inside. The brightness doesn't bother me - it is not dazzling - the only concern would be the light burning out prematurely but presumably if there was such a problem with the design it would have emerged by now, it is not a particularly new counter and even in the Tek form it has been around for quite a few years.

I've now done the unthinkable and actually looked at the manual!
The LCD screen contrast can be adjusted using the up and down arrows when there is no input expected. It is not the same as brightness but it does allow some adjustment.
Interestingly the screen inverts at one extreme and then I noticed that the screen inverts anyway (white on black) when viewed from an angle (polarisation I suppose).

Thank you for the information with the arrow keys. However as you already written, results in hardly any practical benefit. When the darker adjust the LCD is very cloudy. Not nice.  I have a guess that the backlight of the LCD's is regulated with PWM or so . The technique seems to be somewhat unstable in my FCA3000.
It's good that you're an engineer. I think I may need your help to the understanding of the FCA.
Many greetings. Jörg

[Jörg]

Hi All

I've just bought a Pendulum CNT-90 but I can't seem to get it to work as expected.  I'm inputting a 10MHz square wave @280mv pp from CH1 on my Siglent SDG1025 which is clocked by my BG7TBL gpsdo into the 10Mhz Ext Ref input.  The display shows EXT ref to show it has accepted the signal.

The I connected CH2 of my sig Gen to Input A on the CNT-90 and supplied a 10MHz sine wave at 5v.

The issue is that whatever gate speed/resolution I choose, the last couple of digits on the CNT-90 dance around by about 20 counts.  I had assumed that if the extref is essentially the same clock, the display should be crack on and the display would be. for example, 10.000 000 000 000 but even on faster gate times like 100mS, the last couple if digits dance around, effectively showing more error for faster gate times.

I've played around with different voltage levels for ext ref and sine/square and while these do make a small difference, the display doesn't zero.

Am I missing something here?

Thanks

Steve

This question also concerns me.
I use an external 10 MHz source and divide the signal, once on the external reference input and once on the measuring input of the Tek FCA 3000 (aka Fluke PM 6690/Spectracom CNT 90)
If I collect measured values over a longer period of time (in this example, 1 second gate time, n = 1500 samples, Trigger "MANUAL) and the mean value I expect exactly 10 MHz, possibly also +/-2 on the LSD.
In my guess I assume that sources of error such as jitter of the 10 HHz source, trigger errors of the counter or other noise have random properties.
This should exclude the fact, that the same deviation is always measured.
But no matter what 10 MHz source I'm trying to do, the FCA 3000 always measures something too high in this configuration.
I'm not sure if I have a mental error or if the counter has a systematic measurement error. I can't find a good explanation for that.
The question is also, which measurement is correct?

The pictures in the Appendix show the statistics with smart frequency activated and below without smart frequency.
With smart frequency, as a continious time stamping counter and linear regression, the error is of course further shifted into the area of some uHz.
But the reading is always slightly higher than 10 MHz. I have repeated this process often. I have never seen a mean value below 10 MHz.
However, this should be the case for random errors. Or??

Perhaps the experts here in the forum can explain this well.

Jörg   

[Jörg]

Hello jpb. If you are not an engineer you must read first much on continuous time stamping with linear regression.
For optimal working with this counter, you must acquire much background knowledge. I am not an expert in this field and i wonder about different measurements,  depending on equipment setup.
We're talking about very high resolution frequency measurements, which can be adversely affected by many sources of error.
Depending on the type of error, the one or the other measuring methods can deliver better results.
I am still on the search for information, to better understanding this technique.
That between start-stop counting or continuous timestamping counting with linear regression, different results of the StdDev and AllanDev are, I understand quite well.
But that the MEAN result is always different averaged over the set of samples, I still do not understand.

I am an engineer by background, though I now work in software, and have done quite a lot of work in the past on curve fitting to measured data.

I think the difference is nothing to do with the source of noise but simply in the way the data is handled. If you have n points going from t1 to tn say, then the standard counter mode will treat this as (n-1) cycles in (tn-t1) seconds or a frequency of (n-1)/(tn-t1). In the linear regression mode the counter fits a least-squares (I'd guess) straight line to the data which may not exactly go through any of the points. The frequency is then the slope of the fitted line.

If you're looking for the best average frequency and assume that the points are all equally noisy then the slope is probably better - the variance in the slope is less than that of the difference in end points. For analysing the data further with ADEV I would guess that you probably want the actual phase measurements since different time periods are used when working on the same data - also some points may be glitches (outliers) and it is probably better to simply remove them rather than allow them to affect the measurements.

I think it is similar to the arguments that photographers have about jpeg and RAW camera data. The jpegs look good straight out of the camera but serious photographers want to work on the RAW data rather than lose information.

I would recommend Bob Riley's web site and in particular his book (available as a free pdf report) and his software Stable 32 which is now also free.

http://www.wriley.com/

http://www.stable32.com/Handbook.pdf

Hello jpb.

How did you import the data from your TEK FCA 3100 in the Stable32 software.

Thanks Jörg

[jpb]

Hello jpb.

How did you import the data from your TEK FCA 3100 in the Stable32 software.

Thanks Jörg

I've only recently downloaded the Stable32 software - I've not had time to do anything with it yet but my understanding is that the format is just text files. (I looked at the software a few years back but at the time it was around $300 and I couldn't justify spending that for hobby use, it has only been free since last December.)
Getting data out of the counter requires the use of remote control I think, e.g. via the USB or GPIB but again I've read how to do it but have not yet had a chance to do it myself (it is easier just to let the counter do the work).

I'll try to set up my counter to measure its own reference and see what I get to compare with your results.

[Jörg]

Hello jpb. Thank you for your help. Please note, BtB is not possible with the FCA3000.
Please disable this function when your FCA 3100 for the comparison of the measured values.


I was also able to determine the influence of the trigger mode.
With the trigger mode  "Auto " the count error is slightly lower, but the short-term stability is slightly worse.
If you then set the trigger to "manual" mode, the count error is slightly higher and the short-term stability at ADev is slightly better.


Thanks Jörg.

[jpb]

Hello jpb. Thank you for your help. Please note, BtB is not possible with the FCA3000.
Please disable this function when your FCA 3100 for the comparison of the measured values.


I was also able to determine the influence of the trigger mode.
With the trigger mode  "Auto " the count error is slightly lower, but the short-term stability is slightly worse.
If you then set the trigger to "manual" mode, the count error is slightly higher and the short-term stability at ADev is slightly better.


Thanks Jörg.

I have done two measurements. First is back-to-back to show that this goes nicely to zero. The second (which I've not kept running very long) is normal frequency which shows the effect that you've noted - it is too large.

My best guess is that this is a resolution rounding error. The gate time I set was 1 second with clever frequency stuff turned off. The resolution of the counter I think is around 30 psecs (the resolution it stores data to) - the one off accuracy on my counter is 50 psecs and yours is 100 psecs but I think both only store digits down to 30 psecs. (I may be wrong on this but I remember reading it somewhere in the documentation.)
For a 1 second gate with 1 least-significant-digit being out at the start and end then this would amount to the period being 60 x 10^-12 low with the frequency being roughly 60x10-12 or 6x10-11 too high (for such very small delta (1 - delta)^-1 = 1 + delta). This seems to be consistent with the error shown and if it was rounding  it would always go the same way on repeated measurements so shows up in the mean.

With back-to-back the error or rounding only occurs at the start and end of the whole measurement so becomes say 60 psecs in several hours which is insignificant.

Back to back measurements are certainly a good thing to do and even my cheap TTi 930 counter does them though it doesn't interpolate at all.

[Jörg]

Hello JPB. Thank you for your nice post. Maybe I have something interesting for you.
It is also interesting to note the influence of the trigger mode on the last digits of the measurement result.
With trigger mode ' auto ', the measurement result and the Allan Deviation is slightly higher than in the manual mode.
This is also a factor to consider when measuring at maximum resolution. For relatively stable signals from good OCXO, the "manual" mode is probably better.
I think your good explanation, describes ' continuous timestamping ' with regression, in the menu as ' smart frequency '. 
BtB (back to back), in your FCA 3100 and also in the CNT91, indicates "zero dead-time ". Probably implemented according to a single-shot principle.
If I have seen this correctly in the user manual for the FCA3100, you can select BtB when pressing the ' Meas ' button. Independent of  "smart frequency" Function, if you like. .
Although in the literature, continuous timestamping and zero-dead time are always described in combination, but the manufacturer has separated these functions at FCA3000 and FCA3100 (CNT90 and CNT91).
With the less expensive models of Tektronix, Pendulum and Fluke, you can only switch to continuous timestamping with regression.

I have found some publications about continuous timestamping and I give them in the appendix. Maybe you don't know them and can use them.

Jörg

[jpb]

Hi Jörg,
Thanks for the post and links. I've come across a couple of them before (there is also a Tektronix one around) but not the middle one.

I did an experiment to see if the offset was entirely quantization error or not by deliberately introducing some random noise. It does reduce the frequency error but not as much as I'd hope so I think that there is some intrinsic issue with the way the counter rounds or interpolates but it is not large.

Attached are photos showing frequency measurement from my generator locked to the counter reference output (which in turn is locked to my GPSDO). Adding random noise frequency modulation reduces the error in the mean frequency by about 1/3rd.

[Jörg]

Hi jpb.

As you can see again, high resolution does not always mean highest accuracy. The meter always remains a device with real 12 digit/second.

Based on your assumption of rounding errors, I have played around with different gate times.

I think there is a mathematical correlation between the TimeBase and the GateTime.

With the "Smart frequency" function on, trigger  "Manual", 10 MHz GPSDO as ext ref and at the same time on input B of the counter, i have observed the following:

Measuring times 200 mS, 400 mS, 2 sec, 4 sec, 20 sec, 40 sec, 200 sec... show the 10 MHz on the level of LSD with the slightest deviation.

The error in measurements without "Smart Frequency", could thus not eliminated. "

The more you experiment with it, the more questions arise.

It is interesting how the Agilent 53200/53210 counter behave in this situation.

Greeting. Jörg

[klaus11]

Hi guys, I have a PM6690 unfortunately with the screen broken. Do you know any information on where to get the screen?

[coromonadalix]

Its an TM32097AGFG 

320x97 dots lcd  stated in the service manual  page 169, with 2 fpc 20 pins headers, and many voltages to make it work with led backlight.

Not sure it is easily replaceable, unless finding a donor

I think the Tektronix FCA3000, FCA3100, MCA3000  may have used the same lcd's,   not totally sure ?

[klaus11]

I'm getting closer, I found a 320X64 is missing little.

[DaJMasta]

I can confirm, at least, that it's the same as the Tek FCA series screens and the same as the CNT-90/91 screens, since they're all effectively rebadges of the same hardware (seeing the FCA in person just corroborated that).  It wouldn't be all that cheap, but there's a chance Tek or Pendulum has a stock of replacements in a warehouse.

If not an official replacement, you may be able to match the input configuration, at least, since the service manual gives you the pinout for the connector.  It's worth mentioning that the LCD module seems to use 8 data lines, but the schematic shows four of them grounded and only 4 used.

[klaus11]

Yes, but I do not know where to buy Tektronix parts in Europe. Unlike Keysight, it's as easy as picking up the phone. 

I'll have to keep looking.

[glarsson]

In Europe you should probably contact Pendulum, the designer and manufacturer of these devices. Originally a company located in Sweden (split from Philips test instruments) it now resides in Poland. The website is still http://www.pendulum.se

[Jörg]

Now I have finished changing the standard time base of my Tek FCA 3000.
The free space on the board is now equipped with a compatible OCXO. I only desoldered the connections of the standard crystal and left the crystal in the device.
For the correct function, the Fluke PM 6690 utility is required. With the software, the CPU is given the instruction to switch from the standard TCXO to the OCXO.
The selected Timebase option 30 or 40 is then shown in the information display.
Next, with a suitable 10 MHz source you can make a factory calibration. The date is also shown in the information display.
However, the following must be considered for the owners of the Pendulum CNT or Tektronix FCA equivalent.  The Fluke utility renames each device as Fluke PM 6690!!
This name is displayed on the information display and also on a PC when connected to a USB cable.
Next, i exchange the cheap case fan and implement the prescaler PM 9624 clones from China.

Jörg

[jpb]

Now I have finished changing the standard time base of my Tek FCA 3000.
The free space on the board is now equipped with a compatible OCXO. I only desoldered the connections of the standard crystal and left the crystal in the device.
For the correct function, the Fluke PM 6690 utility is required. With the software, the CPU is given the instruction to switch from the standard TCXO to the OCXO.
The selected Timebase option 30 or 40 is then shown in the information display.
Next, with a suitable 10 MHz source you can make a factory calibration. The date is also shown in the information display.
However, the following must be considered for the owners of the Pendulum CNT or Tektronix FCA equivalent.  The Fluke utility renames each device as Fluke PM 6690!!
This name is displayed on the information display and also on a PC when connected to a USB cable.
Next, i exchange the cheap case fan and implement the prescaler PM 9624 clones from China.

Jörg

Interesting. My counter is out-of-warranty now so I may think about doing some improvements. I intend using an external reference (GPSDO or possibly Rubidium) so I'm not sure how much I'd gain from an OCXO except that the crystals in OCXOs tend to be higher quality.
The prescaler may be useful, at present I use my TTi counter for anything over 300MHz and below 3GHz.

[Jörg]

Hi jpb. Of course, if you always use your counter with a good GPSDO as an external reference,
you don't need to worry about the internal timebase.
I can also use a GPSDO. But I also need to be able to use the counter in other places.
For this purpose, I consider the default TCXO to be inappropriate in a device with this resolution.
In a more serious scenario, this can only be appreciated.
The OCXO has the short-term stability at least a factor of 100 better than the TCXO.
Also provides a more predictable temperature stability. I like that.
Everyone needs to assess the benefits of this upgrade. 
Homemade is the upgrade in any case cheaper than the original options from the manufacturer.


Meanwhile, the 2.7 GHz Prescaler has arrived from China. I tested it quickly. The Prescaler works in FCA 3000, but is shown as option 13 in the display.

[Jörg]

I quickly built an em-shield for the prescaler.
In the background you can also see the replacement for the simple fan.

[Jörg]

I have noticed a weakness of the China prescaler.
The circuit in the area of the FET 1-4 behind the signal input, is sensitive when metal comes close.
My EMF Shield unfortunately has no benefit. The right side of the counter housing is also slightly too close to the circuit. Without input signal, the display for input c shows alternating, random readings.
Without housing near the Prescaler, the frequency display is blank.
However, this behavior has no negative effect on the accuracy of the measurement.
At the moment, I can test the measurement only up to 78 MHz.

[DaJMasta]

I wonder if that's an interference thing or if that's a nearfield coupling thing.  If you have any RF absorber material, it could be worth testing with it next to the location in question.


Actually, it may be worth checking the grounding of the chassis.  It could be that the chassis ground isn't great, and it's picking up some ambient RF field that's influencing the gain stages early on in the circuit.  Could be tricky to troubleshoot, though.

[Jörg]

That's a good question.
> The behavior is also shown when the SMB to N connector cable is not plugged into the prescaler.
> The data on the display is similar if you connect an unshielded cable to input A or B.
> If you are very close to the area with your finger or metal (1-2 mm), data up to 230 MHz will be displayed.
   If you are farther away (10-15 mm), the display shows about 30-80 Hz.
> The shield I built is made of copper-coated PCB material with good contact to the equipment ground.
   I just didn't have a better material.

It could be that the original prescaler has a slightly different design.

[little.tesla]

Hello,

regarding the Fluke Utility which renames the counter to FLUKE / PM6690, there is an easy way to rename it back.
Use this commands with a generic GPIB Utility or even using the FLUKE Utility (Manual Command) did work for me:

SYST:INST:TYPE:HEMLIGKO 'CNT-90'
SYST:INST:MAN:HEMLIGKO 'PENDULUM'
(was already correct on my device): SYST:MOD:HEMLIGKO CNT90

Bonus commands (not tested):

Change SN to 123456: SYST:SNUM:HEMLIGKO 123456
Change Timebase to Standard: :SYST:INST:TBAS:HEMLIGKO STANDARD
Change Timebase to OPT30: :SYST:INST:TBAS:HEMLIGKO OCXO30
Change Timebase to OPT30: :SYST:INST:TBAS:HEMLIGKO OCXO40

Regards,
 Dimce

PS. The 8GHz option from https://cojotech.com/ works very well with the CNT-90.

[Micke]

I wonder, can it be a coincidence, or a software engineer had some fun...
Since the counter is made in Sweden and HEMLIGKO (if you divide it to HEMLIG KO) means "Secret Cow" in Swedish  

[DaJMasta]

Has got to be, the secret cow level unlock code! 

[Jörg]

Hi little.tesla. Thank you for your help.
I did this with my FCA 3000 today and it worked fine.
Best regards.

[MegaVolt]

The Spectracom CNT-9X v1.28 update worked just fine on my PM6690.

Please post a firmware update file. It is no longer available on the website.

I found an update on the tektronics website: https://uk.tek.com/frequency-counter-supplies/mca3027-software/firmware-update-loader-and-fca3000-fca3100-and-mca3000-0

But the description does not mention the Fluke 6690

The model number is a PM6690/AN, which isn't listed as an official spec in Fluke's datasheet... it's supposed to have a three digit code not a two letter one.

The three numbers you need are hidden at the end of the code:

[MegaVolt]

Please post a firmware update file. It is no longer available on the website.

I found it myself )) The firmware files are identical. Loaders are different. Just in case, I post it here.

[rockwell]

I'm trying to update the firmware from my Pendulum PM6690.
Installed on the counter is firmware v1.08 and I would like to update to v1.28
I have the NI-Visa drivers installed on a windows 10 computer and connected the counter to it via USB.

Now when I start the CNT9xLoader program I get the error message:

"can't open the counter with the following Visa symbolic address:
 USB::0x14EB::0x0090::88884::INSTR"

Has someone a idea what I'm doing wrong?