For some time I've felt the need to have a piece of equipment allowing me to measure inductance, impedance and a broader range of capacitance values. For the rest of the relevant types of measurements I've already had a digital multimeter and an oscilloscope, which have proven sufficient so far.
The device in question is named LCR after the symbols that represent the quantities that is capable of measuring. L represents Inductance (the letter conventionally used in the mathematical equations involving this quantity), C stands for Capacitance and R is Resistance.
In a more advanced LCR meter or in this model in particular, other quantities such as the Q factor, Equivalent Series Resistance (ESR), Impedance (Z) and Reactance (X) can also be measured.
One aspect that characterizes the versatility of an LCR meter is the range of frequencies that it is capable of synthesizing in order to produce measurements. An LCR meter with a broader range of frequencies will be capable of measuring the inductance of a component closer to the conditions in which it will be operated.
In this particular LCR meter, the user can select frequencies between 100 Hz and 40 KHz. There is a "twin" version of this meter - the 1833C, which is capable of outputting 50, 75 or 100KHz sine waves as well, and two different voltage output levels can be selected - 300 mV rms or 600 mV rms. The 1832C only outputs a fixed 600 mV.
While I don't have a confirmation that the hardware on the 1833C is the same, some users were able to find that after installing the firmware provided in the vendor page in their 1832C devices (there is only one firmware image for all the 183x models), to their surprise the device was now reporting as 1833C, and they could then select frequencies up to 100 KHz.
While this is a relatively simple way of "converting" the device, I found that my (recently purchased) meter had a firmware version which appeared more recent than the one found in the website, judging by the date code/version number of each. Mine has version 20201120PM, whereas the one in the Hantek site is 2020101001AM according to the filename and the photo provided by one user in the blog where this topic first appeared: https://www.eevblog.com/forum/testgear/hantel-lcr-1832c-unlock/
As I didn't want to let go this eventually improved firmware version, I decided to try to find if there was an alternative way of achieving the same effect, i.e. unlock the frequencies and the 300 mV level.
By reading the manual I found that this instrument supports SCPI (Standard Commands for Programmable Instruments) commands. This is basically a spec that describes a standard way for devices to communicate with a given test equipment. The physical interface in this case is USB, but the specification is agnostic to the physical layer. Another popular physical interface from the days when this standard first appeared is the GPIB bus (IEEE-488.1), but is less common in more modern devices.
So my focus was on trying to figure out if there would be some undocumented SCPI command to change factory data. I knew that many devices support changing lower level calibration data and even model data (as is the case of the Rigol DS1052E oscilloscope) via SCPI, so chances were they would use such approach to calibrate and set the model in the factory, while keeping the rest of the process the same for the two models.
By playing a bit with the SCPI commands, I found that I could set the frequency to 100 KHz using the FREQuency <freq> command:
In order to find other commands, my first approach was to analyse the binary image of the firmware and look for relevant strings. This allowed me to figure out the existence of a "fact:model ?" command that when called would return the current model string:
-> fact:model ?
<- model = Hantek1832C
Upon trying to use it for writing, i.e.:
-> fact:model Hantek1833C
<- model = Hantek1832C
it would just behave as the query command. Seemed too easy but I had to try anyway :)
So I decided to go deeper in the analysis and begin with a tool called Ghidra.
This is basically a open source tool first created by the NSA (not too surprising why this organization needed to develop such tool :) ), that is capable of decompiling code from multiple architectures. In this case, the LCR meter has an STM32 microcontroller:
So I needed to be able to decompile Arm Cortex Little Endian 32 bit code.
The tool is quite compreehensive and can even generate flow graphs such as this one:
Not very helpful but cool.
Not too long into the analysis, I realized that there was a global variable that was a pointer to an address in RAM containing a byte used as a boolean. When this byte was set to 0x01, certain commands were allowed to run.
In the STM32, any address in the 0x20000000-0x2000FFFF range corresponds to the SRAM:
So by looking up this address (0x200031E6) in other parts of the code, I found where it was being read, and also asserted. I was able to conclude that this was the variable that would tell if the device was in debug mode or not. Among the various commands that dependend on this variable being set to 0x01, was the fact:mode write command.
So I only had to figure out how to enter debug mode. I found another function that grouped various calibration related strings, and among these were the strings "hantek_enter_debug_cmd" and "hantek_exit_debug_cmd". And precisely in this section of the code is where the debug global variable was being set. By digging a little bit further, I could see that these two commands belonged to the CALIB subsystem, and essentially this function was responsible for handling all the commands of this subsystem.
So with this information, I decided to experiment in runtime, and yes the device appeared to enter debug mode:
Intuitively, my next step was to try the fact:mode for writing. I entered the command:
and verified that no response was produced. This is normal for write commands. So I exited debug mode:
and tried the same command for reading, i.e.
as expected, the command returned Hantek1833C
but as I executed another SCPI command *IDN? (this is a command that most devices support, and it provides information about the software and hardware in the device), I obtained the same model nr:
Hantek Handheld LCR Meter,Hantek1832C,CN************,20201120PM
By executing it after changing the model string, this time yes, the change was persisted:
I was then able to confirm that everything was as expected: I could now change to any of the new frequencies, and set the 300 mV level as well:
- Enter debug mode:
- Change the model string (this command will not return data, so use the "Send Command" button in this case):
- Save the change:
- Exit debug mode:
- Confirm that the change was successful:
After the change is committed, I was able to compare the contents of the flash before and after the change, and confirm that for example no calibration data is lost. As can be seen only the model string, and what appears to be a flag have changed.
But as of yet it is not clear how to use these. Some commands appear to provide a readout of the calibration data, but the exact syntax is still to be figured out.