Avoid the 53181A; too limited. Both the 53131A / 53132A are "universal"
counters so they do frequency, period, time interval, and lots more.

They are very useful counters. The rs232 talk-only mode makes it very
easy to collect data on a PC. No programming required. The 53132A has a
bit higher resolution than a 53131A so that's a plus. But if you plan to
use the external reference the 53131A accepts 5/10 MHz while the 53132A,
last I checked, will only accept 10 MHz.

A lower cost alternative is the TAPR/TICC. If you already have a
commercial counter I would recommend looking at the TICC as your next
counter. As this is your first counter I would recommend a 53131/53132
over the TICC. The TICC is "headless" and has only hard-coded CMOS
digital inputs. The hp units have all the physical front panel buttons,
status LED's and live display. Plus the comprehensive input conditioning
features. And useful frequency gate time or digits modes, etc. Lots of
cool features. Built-in statistics too.

The 5371A is a beast. But it you can get it working it has 10x better
performance than a 53132A.

/tvb

On 10/22/2020 4:50 AM, Giorgio Barinetti wrote:

Hi

53181 = single channel 400 ps counter
53131 = dual channel 400 ps counter
53132 = dual channel 100 ps counter

5370 (when working) = dual channel 20 ps counter

The gotcha is that none of them are good enough to properly measure 1
second ADEV on a good ( but still could be cheap ) OCXO. A mixer based
setup is a cheap way to get things done, even with a 5335.

The 531xx counters all share a couple of issues:

1. The power supply was made by who knows who and their quality is not
   the best. Good news is that the power supply out of a (cheap) 53181 will
   swap over to revive an expensive 53132.

2. They have a fan, it plugs with dust. When that happens it gets hot inside
   the cabinet. Things (like the power supply) die as a result.

3. They have a VFD display. It’s a nice one, but they do wear out. Replacing
   them is problematic.

4. They have a fancy setup to add digits to a frequency measurement. It
   can lead you astray. It also tends to go deaf right at 10 MHz. There are app
   notes out there that explain the details.

5. With any counter, a good external reference is the way to go for “Time Nut”
   grade measurements.

None of that is to say they are a bad counter, far from it. I have a number
of them and have been using them here and at work for decades. The 532xx
counters are the latest and greatest. They are on eBay, but not cheap.

Bob

I am just curious how viable would it be to use a 531xx series counter with Timelab if the counter display has failed ?

Thanks in advance

Mark Spencer
mark@alignedsolutions.com
604 762 4099

Hi,

Small correction, 5371A and 5370A are different beasts. The 5370A has 20
ps resolution and the 5371A has 200 ps resolution. So, the 5371A is
about the same performance as the 53132A at 150 ps resolution. I work
with 5372A which is essentially a 5371A with hardware histogram and a
few other things.

I have both 5370A and 5371A.

The 5371A and 5372A actually can do linear regression processing for
frequency estimation, a historic note that predates this capability of
the Philips/Fluke/Pendulum counters to the best of my knowledge.

PS. I also have a 5370C, which is a flat-bed scanner from HP.

Cheers,
Magnus

On 2020-10-22 15:33, Tom Van Baak wrote:

Hi

Provided you can get a few key parameters set up (= enable the serial
port / set baud rates), it should run just fine without the display. You would
need to do some GPIB fiddling to set various modes.

Bob

Mark,

Yes, the VFD on those counters do seem to have a limited lifetime. I
have some 20 years old that are getting hard to read in bright light.

If the VFD dies, yes, the counter will continue to measure just fine,
not only all the serial talk-only data output, but the full capability
of SCPI over GPIB. TimeLab won't know the difference. The downside is
that the custom little annunciation icons inside the VFD won't be
visible and those are sometimes quite useful, for example, to know the
status of "ext ref", or even the M/Hz/u/s units.

Here are some other ideas:

1. Just replace the dead / dying VFD. You can find NOS on eBay. Taka has
   done this.

2. Use an Arduino or similar to capture the digital signals to the
   display board containing the failed VFD to create a mirror of the
   display. A multi-digit LCD module should work. Or try one of those nice
   looking programmable OLED pixel displays.

Or, for a bit of nostalgia, not to mention a top spot on Hackaday, use
Nixie tubes for the readout and NE-2 bulbs for the status icons. Or get
modern and output the display over BLE and write a phone app as the display.

3. Instead of replacing the front panel readout, instead do all your
   comms over SCPI, to the point where you have created a virtual
   instrument, not unlike some of the logic analyzer or 'scope PC apps.
   This solution would be very welcome by lots time-nuts. It means we could
   fully operate our 53131/53132 counters with the VFD disabled. The
   downsize is that it requires a GPIB (Prologix) adapter.

/tvb

On 10/22/2020 7:22 AM, Mark Spencer wrote:

As a newbie to nuttery I would like to throw my brief experiences into the
mix.
When I started down this slippery slope I was using a HP5386A frequency
counter because I had one.
It was entertaining for a short period of time.
I then acquired a HP5372A which for hooking up to Timelabs and running Adev
plots did not yield the results I was hoping for as the resolution is
rather coarse. I think it does some neat things standalone but not really
the solution to run Timelabs and make Adev plots and have fun.
So then I found a 5370B on fleabay.
I managed to get one that seems to work well. It is measuring frequency
differences of 30-40 ps as far as I can tell.
So I am happy.
Eventually I will figure all this stuff out.
Good luck and have fun.

Dave

On Thu, Oct 22, 2020 at 8:25 AM Magnus Danielson magnus@rubidium.se wrote:

--
72 de Dave
VE7HR

On 10/22/20 8:29 AM, Tom Van Baak wrote:

While I love my Prologix adapters, I wonder if one could implement the
protocol using GPIO pins on something like a Beagleboard or Arduino clone?

(yes, as a product, with the right connector and line driver/receivers,
etc. - it would cost the same as a Prologix... but as a hack...)

After all GPIB is a very old standard, and was developed back in the day
of 1 MHz logic. I think you could do the handshaking in software - punch
the bits one by one, assert DAV, etc.
Listener reads bits one by one, then asserts the ACK or NAK

(Aieee.. Wikipedia says it was supported by the Commodore PET... there's
a challenge for you)

In days of yore + DOS, I implemented a GPIB control by bit-banging a
parallel printer port.
Those were the days

Andy
www.g4jnt.com

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Virus-free.
www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, 22 Oct 2020 at 17:59, jimlux jimlux@earthlink.net wrote:

On Thu, 22 Oct 2020 11:50:08 +0000
Giorgio Barinetti giorgio@barinetti.it wrote:

Maybe try to get hold of one of the Philips (later licensed to
Fluke) PM6680 or PM6681? These are more common in Europe than
in the US, so the big US dominated websites/forums/.. don't
mention them that often. Solid devices that can be had as low
as 300€ if you are willing to wait, 500-800€ is the usual going
price. The SR620 is the workhorse that drives a lot of the
time and frequency metrology worldwide and can be had new and
used (new on http://thinksrs.com goes for 800-2000€ used).

If you go for a new one, I would consider looking at the
Pendulum CNT-90 and CNT-91. (Pendulum is the company that
took over Philips frequency counter business and the CNT-90
is the continuation of the PM668x line, also sold as PM6690
by Fluke)

		Attila Kinali

--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

On 10/22/2020 11:52 AM, jimlux wrote:

Actually it's bytes.  It's byte-serial not bit serial.

Most modern micros can pretty easily keep up with the bus - especially
if you use GPIOs that can generate interrupts. The only real challenges
are finding a reliable source of the appropriate connector - and driving
the 5V lines at the current levels required for a loaded bus.  Most
modern micros do not have 5V tolerant I/O but that's pretty easily dealt
with. Connectors can be had, NORCOMP's 112 series should be ideal.
https://www.norcomp.net/series/112-series and are available through
DigiKey, Mouser, Farnell, etc. TI's SN75160/SN75161 bus transceivers
still seem to be in production as SOICs as well.

I've noodled about building a board that was intended to connect to a
single instrument, but not really gotten serious about it.  I wanted
everything in the shop on Ethernet.

Oz (in DFW)

On 10/22/20 12:08 PM, Oz-in-DFW wrote:

Yes, but sometimes you don't have a way to write all the bits of an 8
bit interface at once, and you have to do them one at a time (if you're
going through some abstracted interface that only allows individual pins
to be set - for instance, Arduinos work that way:

digitalWrite(pin#, HIGH)

I think GPIB would still work if you had to do 8 digitalWrite() calls,
then a final digitalWrite() call to assert DAV.

I suspect that for a number of Arduino type processors, there is a way
to write or read all 8 at once, assuming you were clever enough to pick
the right pins to use.

I think that since the bus is fully handshaked (handshook?) an
arbitrarily slow processor can do it, no interrupts required.

The only real challenges

Buy a Prologix - $200 from sparkfun, for instance.

Unless your time is free and you don't have any more interesting
projects to work on.

I wonder if Prologix makes one that is PoE?  Now that you can get cheap
switches with PoE injection, that would be attractive.  Getting rid of
all those wall warts would be nice.

Hi,

On 2020-10-22 19:13, Attila Kinali wrote:

Let me correct on the history and geniology there.

Philips had a instrument making side called Philips Industrier Järfälla
that did a range of measurement instruments. Later they joined forces
with Fluke. Later Philips felt that the business unit was a bad fit to
stay in Philips, so they sold it off to become a separate company which
became Pendelum. Pendelum was really the business unit with people etc
through that process, and the Fluke relation and rebranding continued.
Naturally Pendelum moved out of the Philips Industrier Järfälla office
over to Bälstabro (both locations in north of Stockholm) as it was sold
off. Pendelum also managed to rebrand their counters to Tektronix, which
mainly consisted of cosmetic changes to get the look and feel. Pendelum
was operated for many years like this, some of their production in
Pajala, where as other where done in Bälstabro. Later they reshaped the
production so that it moved to Poland where it remains. Pendulum was
sold to Spectracom and was operated as a subsidary for a while, until
they shut operation down.

The CNT-80/81 (PM 6680 and PM6681) production went on as long as they
had the timing ASIC. The CNT-90 (100 ps) was developed to the CNT-91 (50
ps), where the later replaced the CNT-81 (50 ps). They aimed to do the
CNT-92, but could not at that time do it with the same technical setup.
They also had the Wander Meter WM-10 which aided in testing telecom
sync. After some testing, I suggested they would broaden the product to
handle more signals and that is when they mostly firmware upgraded it to
the WM-11, and first time I tested the WM-11 the second '1' was cut out
from another '10' print and put over the '0'. Also, it was still under
development. Several years later they where still going back to my list
of feedback. They later did a revamped this into a new instrument with
even improved capabilities such as interfaces boards. This was later
sold off to Calnex which sells it as Sentinel, which is a great product
for telecom operators.

I still have contact with some of the Philips/Fluke/Pendelum staff and
owner.

Cheers,
Magnus

For those who have the PM6681 (aka CNT81): check the 3V memory backup
cell and replace it before the dreaded calibration lost (CAL LOST)
will appear on the LCD. Replace the coin cell with great care (with
the counter powered up), see the service manual for the procedure.
https://archive.org/details/FLUKE_PM6681_Service_Manual

On Fri, Oct 23, 2020 at 6:17 PM Magnus Danielson magnus@rubidium.se wrote:

Hi,

I second this. You can read the calibration data out of the counter and
save. I've done some experiments with that, but nothing conclusive, but
I blame my lack of patience and not a proper setup.

Do replace the battery, it is cheap and relatively easy to do.

Would you loose this calibration, through a little GPIB commands one can
write a fake value in. This will however not produce the best resu. The
calibration routine actually runs an off beat frequency and then test
different values, and look for least RMS value, because it is the
calibration point. I've not had time to replicate all that, but I did
manage to write the fake value in and at one time get rid of the CAL
LOST warning.

Cheers,
Magnus

On 2020-10-29 14:17, Azelio Boriani wrote:

Just for reference, I have an HP5334 that is missing the entire display
assembly and it works just fine over GPIB. Try it, it would most likely
work.

Didier KO4BB

On Thu, Oct 22, 2020, 9:46 AM Mark Spencer mark@alignedsolutions.com
wrote:

Hi Magnus,

Just catching up on list messages and saw this one from you.

I have a Fluke PM 6881 counter. I don't think I've ever seen a
description of a method for reading/restoring these battery backed up
calibration constants. I looked for a way, as losing them is something
I've worried about. Not that it has happened and I did replace the
battery once.

Is doing this described in one of the manuals? Sounds like it is through
GPIB?  I'd greatly appreciate any pointers to info or other details you
might provide.

I did see, in the service manual, a short description of a method for
Interpolator calibration that seems to be for making these calibrations.
Seems if the saved cal values get lost, the counter will display
"CaL.LOSt". The cal procedure is driven by an old DOS program (that I've
never found) and requires a: PM5768 Pulse gen, PM5193 LF Sig Gen, good
10 MHz, all GPIB controlled from the program. Never saw more details but
sounds messy. If there is description of GPIB commands for
reading/setting cal values, I missed them.

thanks for mentioning this and anything more you can provide
-Rex

On 10/29/2020 5:37 PM, Magnus Danielson wrote:

Hi Rex,

I need to dig in the archive to refresh my memory. I don't recall
precisely, but I think I recalled that the manual indirectly describes
the calibration data string.

I have learned a few things from Pendulum, but I did not have the right
tools at hand to set things up.

There was a more recent setup that could use more modern generators, but
the trick was still the same. You lock the generator and counter to the
same frequency, then you set the generator to a small offset frequency
from 10 MHz, which is 9.999 MHz as I recall it. This slowly sweeps
through all the phase-relationships between the reference oscillator and
the counter input, thus sweeps the interpolator phase. It then chooses
the calibration constant giving the lowest RMS error, as this is the
best compensation for the hardware min-point. All this is free from
memory. Then that value with calibration date is written into memory. If
I recall correctly 2.21 ns is a typical value.

I have PM6681 in need of calibration, and as I recall it I was able to
program it enough for the calibration error warning did not show up.
This not to say it was actually calibrated.

At some point I will return to that project. The generator I used did
not support that offset frequency, but I have others that do. Also, my
crapiola GPIB programming needs attention. My intention is to share the
fruits of this project when it comes to that. The lab has been in
shambles for too long, but shaping up slowly and nicely.

Cheers,
Magnus

On 2020-11-05 09:30, Rex wrote:

Old story about the PM6681 (18 Nov 2015, thread: "PM6681 and Timelab")
where a sort of calibration procedure is described: the PUD command is
NOT a calibration command.
PM6681 programming manual, page 9-127: PUD Protected User Data...This
is a data area where the user may write ANY data up to 64
characters...
If the user can write any data, how can it be a calibration command or
calibration data area?
Better watch out those 3V coin cells, we will never get the real
calibration commands/procedure. I have tried with the disassembled
firmware, no way. The visible strings of GPIB commands are all
described in the programming manual, so nothing useful.

On Sat, Nov 7, 2020 at 3:31 AM Magnus Danielson magnus@rubidium.se wrote:

On Fri, Oct 23, 2020 at 9:14 AM jimlux jimlux@earthlink.net wrote:

It's easy once you figure out which I/O ports you're using. I traced
the AVR pinout and Arduino Mega 2560 schematic to translate between
AVR ports and Arduino I/O pin numbers and to find the port I wanted to
use. Googling found the port names that you can directly read from and
write to in Arduino C/C++ code, as opposed to using the digitalwrite
function for each bit. Here I used DDRC and PORTC:
http://blog.freesideatlanta.org/2017/02/a-capacitive-touch-janko-keyboard-what.html

Several USB--GPIB designs may be found on the web, for example,

https://github.com/fenrir-naru/gpib-usbcdc/

I chose this one because it uses the bus driver chips, rather than
driving the bus directly with the microporcessor.

It uses a
http://www.silabs.com/products/mcu/8-bit/c8051f38x/Pages/c8051f38x.aspx
microprocessor, and

SN74ALS160, and SN74ALS162 bus driver chips.  It includes source code
and a (quite small) PC design, in Eagle.

I've built this, with PC design modified to use a 32LQFP package.

It works, at least for the simple use cases I've tried.

David

On 2020-11-08 15:51, Ben Bradley wrote:

Thanks for the memory refresh.

You can read the string using PUD?

Do that and keep the result. PUD and PUD? is the magic in the counter,
the rest is software and hardware outside of the counter for calibration.

In order to write, you need to move the calibration jumper inside.

Cheers,
Magnus

On 2020-11-08 23:01, Azelio Boriani wrote:

Magnus and Azelio,

(About Pendulum or Fluke or Philips PM6681 Counter or equivalent CNT-81)

Here's a link to the thread where Magnus shared info in 2015.
https://time-nuts.febo.narkive.com/6WTFfsyN/pm6680-or-53131a-for-timepod

Your post is about half way down -- 2015-11-18 22:18:04 UTC

Yesterday I dug out my GPIB-capable PC and sent a couple commands to my
Fluke PM6681.

First I tried a basic one:
*IDN?
and got
PHILIPS, PM6681, 0, MAIN V1.09  26 JAN 2001 / GPIB V1.13  26 JAN 2001

So connection is good. Interestingly the *IDN command description says
the PM6681 will return its SN but the SN field here is 0. Oh well, not
important.

Then I sent *PUD?
and got
#261 CALIBRATED: 2006-11-07, CALPLS: 4.25 ns, TMP: +22 °C[LF]
where the [LF] at the end is not literal, it represents the line feed
char 0x0a.

So in addition to the CALPLS value, it looks like they also save the TMP
in centigrade when the test was run. I wonder if the counter uses that?

So I hope if my counter ever lost this cal value, I could send it this
command:
:SYST:UNPR; *PUD #261 CALIBRATED: 2006-11-07, CALPLS: 4.25 ns, TMP: +22 °C

I don't plan to try that now. If it ain't broke don't fix it.

There is one odd thing I see though. The last two of #261 is supposed to
say the string length is 61. But it isn't. I count it as 53 chars. I
don't know if this matters but the counter gave that number to me. In
the Programming Manual description page for *PUD, it gives a couple
examples and the #2nn values shown do have lengths that match their
string lengths.

If it is useful to anyone, I made a version of just the *PUD command
description from the Programming Manual and put it here:
www.xertech.net/pm6681/PUD_cmd.pdf

I also made a version of the Interpolater calibration process page from
the Service Manual. It can't really be used since it is obsolete and the
old DOS program seems unobtanium. It may give a few hints what they were
up to.
I put it here:
www.xertech.net/pm6681/interpolate_cal.pdf

So thanks for pointing out that the *PUD command saved string is what
you lose if the memory backup battery dies. Reading and saving the value
is what I hoped for and now I've done it.

If anyone has a PM6681 counter or equivalent with the "Cal.Lost"
message, sending my string above might be good enough to get it working,
though maybe not optimum.

On 11/9/2020 1:58 AM, Magnus Danielson wrote:

On Mon, Nov 9, 2020 at 6:18 PM Rex rexa@sonic.net wrote:

Could it be that the counter has returned 61 chars but the last few were
binary and the first of those a LF?
But the PC has accepted a string and assumed the LF is it's terminating
character and stopped printing or storing at that point ?

Hi All,

I am one of the lucky persons with a PM6681 that has lost it's
calibration parameters.

Unfortunatly it seems not as simple as sending: :SYST:UNPR; *PUD #261
CALIBRATED: 2006-11-07, CALPLS: 4.25 ns, TMP: +22 °C
This produces an error.
If I sent: :SYST:UNPR; *PUD #253 CALIBRATED: 2006-11-07, CALPLS: 4.25
ns, TMP: +22 °C
Then the counter accepts the string and stores it.

BUT, I still get the Calibration Lost message.

btw. the LF at the end of the string you receive from the counter is
added by the counter itself, so it does not count for the charactercount.

I do have a different firmware version: PHILIPS, PM6681, 0, MAIN V1.05 
27 Jan 1997 / GPIB V1.13  27 Jan 1997

Stijn

Op 09-11-2020 om 17:47 schreef Rex:

Stijn,

Have you tried to power-cycle your counter?

May seem like a silly question, but just to make sure we are on the same
page.

I have had similar problems, but did not debug them all. I do remember
that after writing the string successfully I had to power-cycle the
counter thought, before it got accepted and past Calibration Lost message.

When I did this I could not rule out that my programming to control the
USB-GPIB infterface was correct, as I bone-headidly wrote my own from
ground up. At the time all the stuff with GPIB was flimsy so that's why
I just did not use what was available.

Cheers,
Magnus

On 2020-11-11 11:46, Stijn wrote:

Stijn,

Sorry to hear writing the string I read out hasn't worked so far.

Magnus,

Earlier in this thread (date 11/9) you said, "In order to write, you
need to move the calibration jumper inside."

Do you recall, is there any truth to that? I only saw it mentioned in
that one message and I thought maybe you were thinking of the Unprotect
command (:SYST:UNPR;) that must precede the PUD write.

I'm not sure I really understand all the concepts of the process that
the PC program drives to find the CALPLS parameter. If it actually
iterates through many values of this parameter to make the tests, then
there must be a GPIB way to set it without a power cycle. I'm just
speculating.

-Rex

On 11/11/2020 6:23 AM, Magnus Danielson wrote:

Hi Rex,

Putting my memory to the test, by opening up the 6681 I conclude my
memory failed me. On the other hand, I also discovered that my 6681 have
failed me, since the power supply fails to boot up. I consider a shorted
tantal to be potential cause, but I felt that smell of burnt electronics
which isn't a good indicator. No obvious electrolyt blown. Will
investigate later. Anyway, I obviously remember wrong, sorry.

Cheers,
Magnus

On 2020-11-12 02:05, Rex wrote:

Gents,

In the manual there is no mention of a calibration jumper and I can't
find any inside the counter.

New battery, power cycle, reset etc. no joy.

Maybe some secret sauce to get to the 61 characters?

Stijn

Rex schreef op 2020-11-12 02:05:

Links:

[1] http://www.xertech.net/pm6681/PUD_cmd.pdf
[2] http://www.xertech.net/pm6681/interpolate_cal.pdf