[time-nuts] PM6681 and Timelab

[Magnus Danielson]

Bob,

To illustrate your point.

The original PM6681 calibration setup includes a PC, an ancient Philips 
ISA-bus GPIB interface and an ancient Philips driver and a DOS program.
Collecting these and put them together to work will be an interesting 
challenge.

A more modern variant of the calibration routines run can run on more 
modern HW and LabView software. Philips PM5781 and Agilent 81112A pulse 
generators is supported by those routines.

By now the production of the counter has stopped, as the counter core 
ASIC ran out of stock.

The folks who designed and maintained them does not work there anymore.

Turns out the core setup requires a generator that creates a skewed 
frequency such that you sweep over the interpolation phases. You tweak 
the calibration value (3.86-4.50 ns in 0.02 ns steps) that you set over 
GPIB using the *PUD command. You can check it yourself using *PUD?.
It sweeps over this range and checks for the value giving lowest RMS 
value (SDEV result) and then sets this as the final value.

You can set the value using the command :SYST:UNPR;*PUD %s where %s is 
the string, looking somewhat like this:

FACTORY CALIBRATED: %s%s, CALPLS 3.98 ns

The two %s in there is for some string and date, I just don't bother to 
dig up a correct example.

Anyway, you can actually read-out the data and write it back without the 
software. It should be possible to do something with the existing pieces 
and it might be possible to actually get the calibration software 
operational again.

I just don't have a CNT81 anymore to try this out on.

Cheers,
Magnus

On 11/18/2015 01:35 PM, Bob Camp wrote:
> Hi
>
> The coin cell / backup battery swap out is something we probably will become more familiar
> with on a *lot* of gear. The battery backed up RAM idea is now old enough that there is a large
> population of test gear / radios / telecom gear out there with this “feature”. In some cases the
> loss of the battery is a temporary issue. In a lot of others it’s a significant problem.
>
> If you are buying a piece of gear that has important stuff in RAM, the big question is — has the
> data been lost already? I have bought gear that had a good battery in it, but bad data. If the gear
> comes up with “data lost” on the screen, that’s easy to spot. In most cases …not so easy at all.
>
> Some gear might be configurable by normal means. Almost everything I’ve seen needs a “factory
> only” shoot from a test set that probably no longer exists. Yes, there’s nothing magic in that test
> set. The RAM just has bits in it. Figuring out what all the bits need to be without any documentation
> is not easy.
>
> One might hope that as the gear becomes obsolete, the information about what’s what would be
> released to the public. Based on … errr …. on the job experience - not so likely. The data rarely
> is documented in a “public compatible” fashion. One guy’s notes tell you what the test setup looks like.
> Another set of notes go into the code. Both are buried in log books from who knows when. Beyond
> this, someone actively has to agree to release “corporate IP”. The complex part of that is the fact
> that the calibration techniques probably live on in a modern piece of gear. Not at all easy ….
>
> Bob
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>