Hacking the Agilent 4263B LCR Meter!

[TERRA Operative]

Alrighty, I've written my first real Python script. 

Install Python and PyVISA, then your choice of Keysight IO Libraries Suite (if using a HPAK USP-GPIB adapter) or National Instruments NI-488.2 software if using an NI GPIB-USB-HS, or whatever respective drivers you need for your GPIB adapter.

It will automatically find and communicate with your 4263B to read the serial number, firmware number, and check if the options are already enabled. (for good measure it'll also tell you if your firmware is out of date).
If you don't have both options enabled, it'll reset the unit and then run self tests to make sure it is all ok (and tell you what errors it finds, if any).
Then it'll generate the option codes, write them into the instrument and finally it will verify the written data.

Once you reboot your instrument, it's all good to go. It's as easy as it could possibly be. It's literally as simple as running the script and letting it do all the work.

I have tested it under Windows 10 using an Agilent 83257B USB-GPIB adapter with the Keysight IO Libraries Suite installed, and also a National Instruments GPIB-USB-HS adapter with the NI libraries installed and it works perfectly on both. It should work on any GPIB interfaces that PyVISA supports, let me know how you go with your setup.
(I found the Keysight software 'just works' a bit better with it's auto discovery of connected devices, but once the NI software can see the instrument, it's smooth sailing).


Special thanks to Miek for reverse engineering the checksum magic, and nfmax for providing the commands to read and write to memory! 


Let me know what you think and suggestions for improvements and bugfixes etc. 


Latest version here: https://github.com/JaredCabot/HP-Agilent-4263A-4263B-Option-Unlocker

[Giallograle]

Just wondering whether this hack is applicable to the 4263A?

[TERRA Operative]

The options 001 and 002 are applicable to the 4263A, so it will probably work.

Do you have the ability to extract your firmware and post it here so I can take a look?
If you open the instrument, you'll see the big DIP memory chips right there on top, you can simply pull it and read/write with a standard chip programmer.

If you have the capability to read and write the firmware, we can play around and see if it works with no real risk.
If it doesn't work, you can just flash the original firmware back.

I can then make a change to my script to allow the A model if it works.

[drhex]

Just used  @Terra Operative's script to update my new to me 4263B. Trying to do an short measurement afterwards promptly killed the Xicor X28HC64P-12 - Error 14 and 15 with unit stuck, I was still able to read it luckily. I then tried replacing with a CAT28C64P-12 with mixed result, box did start again but only open measurement worked, closed did still throw error 14. Bought some Xicors which returned the unit to working order. Thanks for the script!

[TERRA Operative]

Has anyone tried unlocking option 002 on a 4263A?

I have one on my bench and my script worked, but when actually trying to use the 20kHz setting, I get no frequency output from the Hcur terminal.

Is anyone able to confirm if their 4263A works with option 002, and maybe even provide a ROM dump too?

[picburner]

I tried now: same thing, at 20KHz there is no output signal.
My firmware is 1.06 and opt. 002 made like all of you.

Actually, after selecting 20KHz and confirming, the sine wave appears for a couple of seconds and then disappears.

[TERRA Operative]

Yours is a 4263A model right? My 4263A is on firmware 2.00 (My 4263B is on firmware 1.06).

I wonder if there is a different checksum algorithm or something?

[picburner]

I forgot to specify: Mine is a 4263B but it does the same thing, the 20KHz are present only for a couple of seconds.
I fear that calibration is necessary (with the program that is not found ....) otherwise the opt. 002 does not work.

[picburner]

I understood where the problem is. As I feared it depends on the lack of calibration data in the U1 eeprom (28C64).
I tried to put an eeprom from another instrument with an genuine opt. 002 and I have the sinusoidal output at 20KHz.
Of course all the levels are wrong since the calibration constants are those of another instrument but it is the verification that the problem is in the eeprom.
Among other things I used for the test an Atmel AT28C64 eeprom instead of the original Xicor X28C64 and I tried to change a data but the instrument refuses to write it and
reports "eeprom r/w failed": It also check the eeprom ID!
So we are screwed: To use the opt. 002 we need the calibration program!
But did anyone on this forum who made this change then check that it actually works?
I confess that I hadn't done it either! I had only tried the opt. 001 and that fortunately works.

[TERRA Operative]

Well, that sucks, but also makes sense...

I guess the next step is to either locate a copy of the HP adjustment software (I've been looking for ages so far), or reverse engineer the process from the firmware and write our own Python script etc, as these instruments require a software controlled calibration via the GPIB port.

[TERRA Operative]

I updated my unlocker script to recognise both the A and B models, and to add a note about the requirement for calibration.

https://github.com/JaredCabot/HP-Agilent-4263A-4263B-Option-Unlocker

[picburner]

If anyone ever needs it, I'm attaching the jed file of one of the two PALCE16V8s found in older mainboards for this instrument.
I only dumped this because someone had already messed around with it and made a mess.
I cleaned it up, put in a socket and make the dump while I was there.
The IC was not protected so I didn't even have to use my Runfei rf-3148.
The newer instruments have three of these PALCE16V8 and I don't think the file I attached will work for these mainboards.