On Fri, Oct 23, 2020 at 9:14 AM jimlux <jimlux@earthlink.net> wrote: > ... > 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. 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: > On Fri, Oct 23, 2020 at 9:14 AM jimlux <jimlux@earthlink.net> wrote: > >> ... >> 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. > > 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 > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there.

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: > 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: >> 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: >>> 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, >>>> >>>> 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: >>>>> 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, >>>>>> >>>>>> On 2020-10-22 19:13, Attila Kinali wrote: >>>>>>> On Thu, 22 Oct 2020 11:50:08 +0000 >>>>>>> Giorgio Barinetti <giorgio@barinetti.it> wrote: >>>>>>> >>>>>>>> Choices are many, but I'll try to avoid the "older" machines lile >>>>>>>> 5370 or 5335. The 531xx series seems nice ( money apart ) >>>>>>>> But again : which one between the 3 ? 53131, 53132 or 53181 ? >>>>>>> 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) >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> time-nuts mailing list -- time-nuts@lists.febo.com >>>>>> To unsubscribe, go to >>>>>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>>>>> and follow the instructions there. >>>>> _______________________________________________ >>>>> time-nuts mailing list -- time-nuts@lists.febo.com >>>>> To unsubscribe, go to >>>>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>>>> and follow the instructions there. >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts@lists.febo.com >>>> To unsubscribe, go to >>>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>>> and follow the instructions there. >>>> >>>> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there.

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: > 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: >> 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: >>> 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: >>>> 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, >>>>> >>>>> 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: >>>>>> 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, >>>>>>> >>>>>>> On 2020-10-22 19:13, Attila Kinali wrote: >>>>>>>> On Thu, 22 Oct 2020 11:50:08 +0000 >>>>>>>> Giorgio Barinetti <giorgio@barinetti.it> wrote: >>>>>>>> >>>>>>>>> Choices are many, but I'll try to avoid the "older" machines lile >>>>>>>>> 5370 or 5335. The 531xx series seems nice ( money apart ) >>>>>>>>> But again : which one between the 3 ? 53131, 53132 or 53181 ? >>>>>>>> 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) >>>>>>> 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 >>>>>>> >>>>>>>

On Mon, Nov 9, 2020 at 6:18 PM Rex <rexa@sonic.net> wrote: > > 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. > > ... > 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. > 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: > 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: >> 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: >>> 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: >>>> 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: >>>>> 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, >>>>>> >>>>>> 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: >>>>>>> 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, >>>>>>>> >>>>>>>> On 2020-10-22 19:13, Attila Kinali wrote: >>>>>>>>> On Thu, 22 Oct 2020 11:50:08 +0000 >>>>>>>>> Giorgio Barinetti <giorgio@barinetti.it> wrote: >>>>>>>>> >>>>>>>>>> Choices are many, but I'll try to avoid the "older" machines >>>>>>>>>> lile >>>>>>>>>> 5370 or 5335. The 531xx series seems nice ( money apart ) >>>>>>>>>> But again : which one between the 3 ? 53131, 53132 or 53181 ? >>>>>>>>> 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) >>>>>>>> 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 >>>>>>>> >>>>>>>> > > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there.

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: > 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: >> 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: >>> 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: >>>> 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: >>>>> 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: >>>>>> 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, >>>>>>> >>>>>>> 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: >>>>>>>> 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, >>>>>>>>> >>>>>>>>> On 2020-10-22 19:13, Attila Kinali wrote: >>>>>>>>>> On Thu, 22 Oct 2020 11:50:08 +0000 >>>>>>>>>> Giorgio Barinetti <giorgio@barinetti.it> wrote: >>>>>>>>>> >>>>>>>>>>> Choices are many, but I'll try to avoid the "older" machines >>>>>>>>>>> lile >>>>>>>>>>> 5370 or 5335. The 531xx series seems nice ( money apart ) >>>>>>>>>>> But again : which one between the 3 ? 53131, 53132 or 53181 ? >>>>>>>>>> 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) >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there.

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: > 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: >> 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: >>> 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: >>>> 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: >>>>> 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: >>>>>> 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: >>>>>>> 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, >>>>>>>> >>>>>>>> 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: >>>>>>>>> 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, >>>>>>>>>> >>>>>>>>>> On 2020-10-22 19:13, Attila Kinali wrote: >>>>>>>>>>> On Thu, 22 Oct 2020 11:50:08 +0000 >>>>>>>>>>> Giorgio Barinetti <giorgio@barinetti.it> wrote: >>>>>>>>>>> >>>>>>>>>>>> Choices are many, but I'll try to avoid the "older" machines >>>>>>>>>>>> lile >>>>>>>>>>>> 5370 or 5335. The 531xx series seems nice ( money apart ) >>>>>>>>>>>> But again : which one between the 3 ? 53131, 53132 or 53181 ? >>>>>>>>>>> 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) >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@lists.febo.com >>> To unsubscribe, go to >>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>> and follow the instructions there. >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > >

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: > 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: >> 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: >>> 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: >>>> 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: >>>>> 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: >>>>>> 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: >>>>>>> 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: >>>>>>>> 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, >>>>>>>>> >>>>>>>>> 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: >>>>>>>>>> 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, >>>>>>>>>>> >>>>>>>>>>> On 2020-10-22 19:13, Attila Kinali wrote: >>>>>>>>>>>> On Thu, 22 Oct 2020 11:50:08 +0000 >>>>>>>>>>>> Giorgio Barinetti <giorgio@barinetti.it> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Choices are many, but I'll try to avoid the "older" machines >>>>>>>>>>>>> lile >>>>>>>>>>>>> 5370 or 5335. The 531xx series seems nice ( money apart ) >>>>>>>>>>>>> But again : which one between the 3 ? 53131, 53132 or 53181 ? >>>>>>>>>>>> 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) >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts@lists.febo.com >>>> To unsubscribe, go to >>>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>>> and follow the instructions there. >>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@lists.febo.com >>> To unsubscribe, go to >>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>> and follow the instructions there. >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. >> >> > > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there.

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: > 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: 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: 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: 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 [1] > > 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 [2] > > 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: 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 Links: ------ [1] http://www.xertech.net/pm6681/PUD_cmd.pdf [2] http://www.xertech.net/pm6681/interpolate_cal.pdf