Hi Magnus, When you did your measurements, did you use 'single' mode or 'normal' mode? When I got my PM6681, I wanted to check the interpolater to make sure that it was healthy. I couldn't generate pulses over the whole range, but over the range of 50ns to 28 ns, my StdDev readings in 'single' mode were in the range of 2.6 - 3.6 e-11, i.e. similar to the example in the manual. In normal mode, my readings were significantly better. So I'm assuming that 'single' mode was the correct mode to use. FYI, my unit was factory calibrated with a 4.05 ns pulse according to the PUD command, so I guess that's what gave the best results. I also see that the example in the manual was for a 4.29 ns pulse. Does that suggest that shorter, harder to generate, pulses are important for this calibration? Ed On 2017-02-01 11:00 AM, Magnus Danielson <magnus@rubidium.dyndns.org> wrote: > Fellow time-nuts, > > With the hints from the former Pendulum service guy, I have started to > write my own code in order to restore calibration on a CNT-81/PM-6681. > This have been a discussion on and off for a couple of years, so I ended > up buying a PM-6681 which had the Loss of Calibration message "CAL LOSS". > > First things is to replace the CMOS battery, which is a trivial thing to > replace the CR2032 battery, had one laying around. > > Then, I've been digging into the NI VISA files, which have snippets of > actual code in it. As I don't have NI VISA and not running with my > Prologix, I was a bit out of luck there. So I had to start from the > ground up, taking a serial interface hack I already have, write some > minimalistic Prologix support for it (TvB hp59309.c provided some needed > clues on how to get it working stable). > > Then more and more bits and pieces have been falling together, like > being able to build and write the *PUD string. Also, triggering the > calibration itself and using an external source. > > Now my counter does not display the error anymore and seems to behave > more coherently. I'm not completely trusting it, as I am not doing the > full sweep over calibration pulse calibration values and measuring their > effect, that will be part of the complete solution, but at least I get > sufficient part of the way. > > Far from bullet-proof, it is however worth celebrating these baby steps > in the right direction. > > Cheers, > Magnus >

It seems that "normal mode" is not a mode: from the operator's manual: SINGLE When on, the result from each measurement is displayed. When off, the counter averages all data captured during the set measurement time. No normal mode but single mode on or off. The measurments look better when averages are on... On Wed, Feb 1, 2017 at 8:46 PM, Ed Palmer <ed_palmer@sasktel.net> wrote: > Hi Magnus, > > When you did your measurements, did you use 'single' mode or 'normal' mode? > > When I got my PM6681, I wanted to check the interpolater to make sure that > it was healthy. I couldn't generate pulses over the whole range, but over > the range of 50ns to 28 ns, my StdDev readings in 'single' mode were in the > range of 2.6 - 3.6 e-11, i.e. similar to the example in the manual. In > normal mode, my readings were significantly better. So I'm assuming that > 'single' mode was the correct mode to use. > > FYI, my unit was factory calibrated with a 4.05 ns pulse according to the > PUD command, so I guess that's what gave the best results. I also see that > the example in the manual was for a 4.29 ns pulse. Does that suggest that > shorter, harder to generate, pulses are important for this calibration? > > Ed > > > > On 2017-02-01 11:00 AM, Magnus Danielson <magnus@rubidium.dyndns.org> wrote: >> >> Fellow time-nuts, >> >> With the hints from the former Pendulum service guy, I have started to >> write my own code in order to restore calibration on a CNT-81/PM-6681. >> This have been a discussion on and off for a couple of years, so I ended >> up buying a PM-6681 which had the Loss of Calibration message "CAL LOSS". >> >> First things is to replace the CMOS battery, which is a trivial thing to >> replace the CR2032 battery, had one laying around. >> >> Then, I've been digging into the NI VISA files, which have snippets of >> actual code in it. As I don't have NI VISA and not running with my >> Prologix, I was a bit out of luck there. So I had to start from the >> ground up, taking a serial interface hack I already have, write some >> minimalistic Prologix support for it (TvB hp59309.c provided some needed >> clues on how to get it working stable). >> >> Then more and more bits and pieces have been falling together, like >> being able to build and write the *PUD string. Also, triggering the >> calibration itself and using an external source. >> >> Now my counter does not display the error anymore and seems to behave >> more coherently. I'm not completely trusting it, as I am not doing the >> full sweep over calibration pulse calibration values and measuring their >> effect, that will be part of the complete solution, but at least I get >> sufficient part of the way. >> >> Far from bullet-proof, it is however worth celebrating these baby steps >> in the right direction. >> >> Cheers, >> Magnus >> > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

Hi Ed, First of all, don't be fooled to think it is "calibrated", not yet. What I've done so far is just starting to make my ways into the GPIB commands to make it do the right things. I've not even attempted to do the right thing in terms of actual calibration, but trying to make sure that I can get it to do the necessary stuff. Anyway, one trick being used is to use a locked offset oscillator, that effectively sweeps all phase relationships over the 10 MHz cycle stable, predictably and evenly. This way it sweeps over all the phase relationships to the locked 100 MHz oscillator and the 10 ns time error window that is then expanded 400 times in the interpolator before being counted in the 100 MHz clock. The scaling of this is done with an internal reference pulse. The internal reference pulse needs to be calibrated with external software, and once established it is put into the PUD command and used in the internal self-calibration routines. So, 4.05 ns or 4.29 ns is really a property of that hardware. I have not attempted to do the routine to establish the calibration pulse length yet, I'm trying to clear the way before I get there. Hence, I have not yet cared about actual precision yet. Cheers, Magnus On 02/01/2017 08:46 PM, Ed Palmer wrote: > Hi Magnus, > > When you did your measurements, did you use 'single' mode or 'normal' mode? > > When I got my PM6681, I wanted to check the interpolater to make sure > that it was healthy. I couldn't generate pulses over the whole range, > but over the range of 50ns to 28 ns, my StdDev readings in 'single' mode > were in the range of 2.6 - 3.6 e-11, i.e. similar to the example in the > manual. In normal mode, my readings were significantly better. So I'm > assuming that 'single' mode was the correct mode to use. > > FYI, my unit was factory calibrated with a 4.05 ns pulse according to > the PUD command, so I guess that's what gave the best results. I also > see that the example in the manual was for a 4.29 ns pulse. Does that > suggest that shorter, harder to generate, pulses are important for this > calibration? > > Ed > > > On 2017-02-01 11:00 AM, Magnus Danielson <magnus@rubidium.dyndns.org> > wrote: >> Fellow time-nuts, >> >> With the hints from the former Pendulum service guy, I have started to >> write my own code in order to restore calibration on a CNT-81/PM-6681. >> This have been a discussion on and off for a couple of years, so I ended >> up buying a PM-6681 which had the Loss of Calibration message "CAL LOSS". >> >> First things is to replace the CMOS battery, which is a trivial thing to >> replace the CR2032 battery, had one laying around. >> >> Then, I've been digging into the NI VISA files, which have snippets of >> actual code in it. As I don't have NI VISA and not running with my >> Prologix, I was a bit out of luck there. So I had to start from the >> ground up, taking a serial interface hack I already have, write some >> minimalistic Prologix support for it (TvB hp59309.c provided some needed >> clues on how to get it working stable). >> >> Then more and more bits and pieces have been falling together, like >> being able to build and write the *PUD string. Also, triggering the >> calibration itself and using an external source. >> >> Now my counter does not display the error anymore and seems to behave >> more coherently. I'm not completely trusting it, as I am not doing the >> full sweep over calibration pulse calibration values and measuring their >> effect, that will be part of the complete solution, but at least I get >> sufficient part of the way. >> >> Far from bullet-proof, it is however worth celebrating these baby steps >> in the right direction. >> >> Cheers, >> Magnus >> > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.