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: