Here are my notes on this scope from when I last performed a successful calibration. Hopefully it helps, I don't think I could help any further as it was so long ago. You did replace the battery on the acquisition board as well, correct?
REM CSA8000 and TDS8000 serial reprogramming after battery replacement
REM the serial # can be seen under menu item [utilities] [system properties]
REM Serial # programming:
SYST:PROT OFF
SYST:PROP:MAI:SER "B010243"
SYST:PROT ON
REM A reboot is not needed to see the new #
REM Model # programming:
SYST:PROT OFF
SYST:PROT:MAI:MODE "TDS8000" or
SYST:PROP:MAI:MODE "CSA8000"
SYST:PROT ON
REM CALIBRATION - an experiment.
SYST:PROT OFF
CAL:SAVE:FACT:MAI
CAL:UPDATEINFO:MAI
SYST:PROT ON
It did not solve the error 171 NVRAM data integrity, but no more cal errors are seen in the serial port logs, such as:
0x2ee98a0 (aCalDiagExecutor): CCMgr: Recall ACQ cal constants failed!
0x2ee98a0 (aCalDiagExecutor): --> Initializing to defaults!
0x2ee98a0 (aCalDiagExecutor): CCMgr: Recall user ACQ comp data failed!
0x2ee98a0 (aCalDiagExecutor): --> Initializing to defaults!
0x2ee98a0 (aCalDiagExecutor): [2] M: 1,0:00:29,23.50,## FIRST TEST ##
0x2ee98a0 (aCalDiagExecutor): [3] P: 1,0:00:44,23.50,171,AcqCalInfo(2), AcqCalCo
nst(2), AcqCompFactory(2), AcqCompUser(2)
done
done
done
connectionTask: handshaking with peer...
connectionTask: handshaking with peer - done.
connectionTask: handshaking with peer...
0x2ee98a0 (aCalDiagExecutor): CCMgr: Recall ACQ cal constants failed!
0x2ee98a0 (aCalDiagExecutor): --> Initializing to defaults!
0x2ee98a0 (aCalDiagExecutor): CCMgr: Recall user ACQ comp data failed!
0x2ee98a0 (aCalDiagExecutor): --> Initializing to defaults!
So I followed this procedure and it worked - it got rid of error 171
It did not require setting the write protect switch off either.
Try, :calcomp:double instead of CALCOMP:DOUBLE.
The following may help. Notes and memory joggers for me to remember how to calibrate these. I do recall there was a step(s?) where the capitalization of the gpib commands had to be just right, and not as documented, looks like I changed all of the gpib commands to lower case...
Unprotect the cal memory by toggling the memory write protect switch in the rear of the unit (to the outside hole).
:syst:prot off
:calcomp:double "DcCalOffsetAdj",4.0e-4 ; this is equivalent to a positive 4mA shift.
(querry form, :calcomp:double? "DcCalOffsetAdj")
:calcomp:double "DcCalLsbAdj",0.9967 ; where 0.9966 and -0.9967 dmm values, see notes
:calcomp:double "Internal10MHzRefFreq",9.99008e6
:comp:sav:fact:all
:cal:save:fact:mai
:cal:update:all
:syst:prot on
Notes:
Use capitalization exactly as above.
I am not certain how many digits of precision are allowed. A 6.5 dmm per instructions implies, based on above, 4.00e-4 (or equiv) and 0.996700 as permissible values. Simple experimentation with the latter did not result in obvious influence on calibration. The values used in the top example were adequate to meet cal specs.
DcCalLsbAdj = this is a compromise adjustment and is dependent on offset being correct. You take a dmm measurements of the 1 volt calibrator signal, plus and minus, look at them as absolute values and pick the best value in between. So, 0.9966 and -0.9967 becomes: 0.9966 and 0.9967, now pick an in between value, 0.9966 or 0.9967. So, on this system you are telling it that a 1V signal is actually 0.9967, and it needs to adjust for that... This value is never negative! You could choose to use 0.9966 instead. If you see a greater spread than 2 digits your offset voltage is probably wrong.
The Internal10MHzRefFreq result that I got may have been wrong. This one is probably best left alone, or the 10e6 value. My math skill are not that great.
I replaced my batteries, so all of the above values were zeroed out already.
Menu Soft Key to get to calibrator.
-> lkup "DcC"
calCompSetDcCalibratorAdjConst 0x01000a8c text (rtlLibTarget.o)
calCompGetDcCalibratorAdjConst 0x01000a38 text (rtlLibTarget.o)
calLibGetDcCalibratorCalDefaults 0x01032ef8 text (rtlLibTarget.o)