Yet another Tonghui TH2822A LCR meter review in pictures

[reagle]

Just posted a boatload of pictures of the Tonghui Th2822A LCR meter I bought after almost a year of contemplating which brand/model to go with.
http://kuzyatech.com/tonghui-th2822a-lcr-meter
Seems very nice for the amount paid ($175 +$35 shipping), though I do question the -2mF reading at one of the test frequencies
On a positive note, I see no signs of the min/max/avg bug Dave found in the BK879B unit

[valentinc]

    Interesting enough, I have a TH2822 (100 Hz - 1 Khz version) that has the problem with the MIN/MAX/AVG, exactly as Dave found on the BK Precision 879B... And this makes me think that both units share the same firmware... Because the hardware is obviously identical, except the input protection board that the BK doesn't have.

   

[reagle]

What firmware version does yours report?
On boot, mine flashes:

2.1.1.1
2822A

[valentinc]

     I'm away for a few days... I will reply when I get back and verify what version mine has.

[valentinc]

2.0.10    (without a dot between 1 and 0)
2822

replies mine ...  yours has a newer firmware, but on the Tonghui website there isn't any firmware update file

[reagle]

No dot here either. I had to take a picture to capture it again- it flies by too fast:)
 Mine says
2.1.11
2822A

Now we need to find somebody with a  BK  meter to compare

[valentinc]

Yes. I bet that the firmware is the same...

Read this about Siglent and LeCroy... it's the same thing

https://www.eevblog.com/forum/testgear/siglent-sdg1000-(aka-lecroy-wavestation)-firmware-updates/

[valentinc]

If you can, please post a high res photo of the board of your Tonghui... I want to compare to see if the max frequency is determined by a couple of 0 ohm resistors... it could be

[reagle]

Any particular corner of it? It's a bit tough to get everything equally sharp

[valentinc]

Most probably, if there are any resistors to do that are at the top, near the CPLD and MSP430 microcontroller ... But it's better if you take 2 or even 3 pictures to compare the entire board (except the input board that has obviously nothing to do with this)

I will be very happy to hack this LCR meter, since the 100 Khz version is very expensive...

[reagle]

Assuming the firmware is the same in all, I'd like to try that too. I need to get some low measurement ranges that even 10Khz is not reaching.
Here are the pictures- let me know if you need more details

[valentinc]

  At a first look the boards look identical (my TH2822 and your TH2822A). The only difference is on the TH2822C, which has additional circuitry for charging the 9V Ni-Mh battery, which ours don't have... I'll investigate further and let you know what I'll find.

  Now the problem is I can't find the firmware update for the BK Precision 879B on their website...

  If you can find the firmware update file for the BK, please let me know...

[valentinc]

Now I see, even the silkscreen with the board name is the same: TH2822-MAIN
                                                                                                        VER 1.1@2010-10

It's clear that the differences between the models are in the EEPROM next to the microcontroller or in the flash of the microcontroller. I'll try to probe with my oscilloscope to see if I can figure out what's in that memory... My guess is the calibration data and some ID's for different models...

[valentinc]

    It seems that only at startup (boot) there is a data transfer between the EEPROM and the microcontroller, in rest, anything you do there isn't any data transfer. I couldn't capture the entire data on my scope (because it hasn't enough memory), but it's clear that at boot time the uC receives some ID of the model number and eventually some calibration data...

    I don't have an EEPROM programmer, that would be the next step, to unsolder the chip and read its contents. And maybe it can be modified and written on another chip (because it has write protect).

    And I also wonder if it can be done via SCPI commands (like the Rigol DS1052E) ...

[reagle]

Let me see if I can sniff I2C traffic on the EEPROM. Between Bus Pirate and Saelae Logic 16, i should be able to figure it out

[valentinc]

If the data in the EEPROM is not encrypted we should be able to figure it out

[ivan747]

I honestly doubt the data is encrypted. Not even Agilent encrypt their model data.

[reagle]

At the moment I am setting up Saelae  Logic to grab I2C traffic. If I don't feel too lazy, I may try reading the eeprom out with bus pirate, but that requires actually actively using my brain

[ivan747]

Can't you setup the Bus Pirate to read the whole chip into an hex file?

[reagle]

That's what I meant by having to actually use my brain
For now here is a grab of the i2C traffic on boot

[ivan747]

That's what I meant by having to actually use my brain
For now here is a grab of the i2C traffic on boot

Change the extension to CSV to open it in a spreadsheet. 

[reagle]

If read as ASCI, it reads out the firmware rev first VER2.1.1103. rest is less obvious

[valentinc]

Can you post the data in ASCII format ?

[reagle]

Try this one

[ivan747]

I converted it into CSV, and added some comments. I already found some sort of pattern.

Look by yourself. Change the extension to .csv

[valentinc]

    I think I figured out most of it ... The 165Z that appears at almost every read is probably some adress... it hasn't have any meaning for our purpose that's for sure

    I attached an xls with the comments

    I'll try to get a USB logic analyzer from a friend of mine to capture the data in my Tonghui and compare ...

    And I'm not sure that the content that transfers at boot is all the content in the EEPROM, it should be, but who knows, until I desolder the chip and put in on an EEPROM programmer and read it I can't be 100% sure. But I'll need a EEPROM programmer to do the hack anyway, so probably I'll get one from ebay.

[ivan747]

That converted to ASCII makes much more sense. The 0's at the end of certain read commands are the null terminators for strings in C.

Good job on the color coding, I was thinking of doing that myself.

[ivan747]

I reckon the model information must be either '165' Z or the configuration bits. One explanation for the continuous reading of the model info might be to have some sort of confirmation every time the software passes though certain point that the LCR model is this or that. Maybe the MCU has the model number on its EEPROM as well to make it secure and they are constantly compared? 

Might be worth it to mess with the configuration bits.

For some reason the MCU writes on the EEPROM a (ascending) numerical value for each packet and a second byte following that which to me appears random but must have some logic behind.

Have you found any evidence of a checksum anywhere? If not, I think a hack might be very easy on this one.

[valentinc]

   There isn't any obvious evidence of a checksum...

   Probably next week I can get a logic analyzer and sniff the packets of my TH2822 and compare them.

 

[reagle]

Almost forgot- here is a Saelea Logic data file. You can use their software standalone without the analyzer to view it. Remove .txt at the end

[ivan747]

Almost forgot- here is a Saelea Logic data file. You can use their software standalone without the analyzer to view it. Remove .txt at the end

Good, good. Checking it out right now. 

[reagle]

And here is my analysis in an excel file. I looked at a combination of binary/HEX/ASCII.
0xA5 0x5A is just asking to be a marker of a packet beginning and end
Everything else is basically a bunch of reads, and I think most are actually returning binary data, and only the first string with version is in ascii.
So we could create a memory map of sorts, based on these addresses. But it would definitely help if we had captures from a few more units.
I do wonder why did they use a 64kb part to store this little data.

[ivan747]

I do wonder why did they use a 64kb part to store this little data.

Reading the actual EEPROM could shine some light into that. Maybe they already used that part on different tools. It's common to do that to reduce stock variety, for example. Is the firmware upgradable? Maybe they are planning ahead. I

Or it could be used for datalogging but that got cancelled or is available in higher end models.

[valentinc]

Is the firmware upgradable?

Yes, the firmware is upgradable, they say that in the user manual. But on the other hand it's Tonghui have not offered any firmware upgrade since they released the product...

Everything else is basically a bunch of reads, and I think most are actually returning binary data, and only the first string with version is in ascii.

I think 030 after VER 2.1.11 may be the model number.

But it would definitely help if we had captures from a few more units.

I'll see what I can do next week about that... As is said, unfortunately, I personally don't have a logic analyzer in my lab...

[reagle]

I have access to Logic 16 one, but what I need to do is just hook up Bus Pirate and do a continuous read. Time's been a bit of a problem, but will try to get to it in the next few days

[reagle]

I tried using Bus Pirate but with  no luck. I can sniff the bus on boot and get the same data as with Logic 16, but I can not talk to the chip. I wonder if somehow the bus is held high- not really an I2C compliant thing if I am not mistaken.
 I've tested it on standalone EEPROMs and the ones on an old VGA monitor boards and was able to read them just fine : Basically switch to I2C mode, do a discovery scan (1), then set address to all 0: [0xA0 0 0], followed by a read [0xA1 r:100]
On the above chips it works fine, on the one inside the meter I just get NACks on everything and bus scan returns nothing. Looking at the bus with a  logic analyzer probes from my scope, I don't see lines wiggle when bus pirate tries to drive them. Weird 

[carloscuev]

I found my probe pcb edge connectors were corroding or something, very bad quality gold pating on them, when measuring I had poor results, rather unstable and not repetitive.


So I decided to install custom 4-wire bananna connectors, note that I inserted spacers between the plates of the connectors to disconnect them from each other:


And convert my 2 probes to this probe system of 4-wire + guard connection:


Now the measurements are much more stable and repetitive than before, I regret not doing tests (and record them!) before and after the modding, but I am sure that the stability is very much improoved

I want to start researching to hack it to 100kHz, but I can't find a datasheet for the eeprom:


Any advise on where to find it?

I think I've read somewhere that this EEPROM is write protected, is it true?

I have a Saleae logic analyzer to read the data flow and a BusPirate to read/write the EEPROM, but how can we get a TH2822C (100kHz) EEPROM readout to try to find if there's a magic bit (or bits) to flip?

Regards!

[carloscuev]

Here's the Saleae sniffing of the I2C comms:
CH0: SCL
CH1: SDA
CH2: Write Protect Pin



I attached the *.logicdata file, download the Saleae application to open it: http://www.saleae.com/downloads

[carloscuev]

Additionally I have found that the MCU reads or writes the EEPROM in this cases:

Switching Frequency from 10k to 100:
Read @0x0164: A5 5A
Read @0x0166: 16 DC 33 4D D2 FF 5B CE
Read @0x0578: A5 5A
Read @0x057A: 8F F3 A0 3D 02 36 AD 3E
Read @0x0964: A5 5A
Read @0x0966: D9 08 80 3F 36 FA C1 3A

Switching Frequency from 100 to 120:
Read @0x0196: A5 5A
Read @0x0198: 94 27 BA 4D 4F CA B2 CE
Read @0x05AA: A5 5A
Read @0x05AC: AB AD 92 3D 60 35 81 3E
Read @0x0996: A5 5A
Read @0x0998: 20 0C 80 3F 49 4D DC 3A

Switching Frequency from 120 to 1k:
Read @0x025E: A5 5A
Read @0x0260: 32 AF AA 49 0C 71 DF CC
Read @0x0672: A5 5A
Read @0x0674: 38 88 34 3D 75 DC E7 3C
Read @0x0A5E: A5 5A
Read @0x0A60: 85 08 80 3F 61 C4 3E 3C

Switching Frequency from 1k to 10k:
Read @0x0326: A5 5A
Read @0x0328: 3A 9D BF 49 9C 23 3A CB
Read @0x073A: A5 5A
Read @0x073C: C8 9A 21 3D 02 39 35 3C
Read @0x0B26: A5 5A
Read @0x0B28: 03 AB 7E 3F 8E 2B 33 3D

Exiting UTIL menu with Power-Up setting as Previous
Write @0x0040: A5
Write @0x0041: 5A
Write @0x0042: 00
Write @0x0043: 00 (Beep, 0: Off, 1: On)
Write @0x0044: 02 (Auto-Off, 0: off,1: 5min, 2: 15min, etc.)
Write @0x0045: 00
Write @0x0046: 00
Write @0x0047: 00

Exiting UTIL menu with Power-Up setting as "Set"
Write @0x0040: A5
Write @0x0041: 5A
Write @0x0042: 00
Write @0x0043: 00 (Beep, 0: Off, 1: On)
Write @0x0044: 02 (Auto-Off, 0: off,1: 5min, 2: 15min, etc.)
Write @0x0045: 00
Write @0x0046: 00
Write @0x0047: 00
(and then)
Write @0x0050: A5
Write @0x0051: 5A
Write @0x0052: 01 (Mode, 00: L, 01: C, 02: R, 03: Z)
Write @0x0053: 0E (Sec. Display, 11: Frequency, 0E: ESR, etc. )
Write @0x0054: 0B (Frecuency, 0B: 10kHz, 07: 1kHz, 03: 120Hz, 02: 100Hz)
Write @0x0055: 00
Write @0x0056: 00
Write @0x0057: 00
Write @0x0058: 00
Write @0x0059: 00
Write @0x005A: 00
Write @0x005B: 00
Write @0x005C: 00 (??, 00: L, 01: CRZ)
Write @0x005D: 00
Write @0x005E: 00
Write @0x005F: 00
Write @0x0060: 00
Write @0x0061: 00
Write @0x0062: 00
Write @0x0063: 00 (01: AUTO, 00: otherwise)

So we can see that the EEPROM address 0x0040 to 0x0047 are used to store settings from the UTIL menu, that 0x0050 to 0x0063 is for the power-on state, and that for each frequency selection a new set of data is read, maybe calibration data?

This also gives more sense to what's happening on power on:

1. Power ON with AUTO (1kHz) power-on state:

[1st Block]
Read @0x0000: A5 5A
Read @0x0030: 56 45 52 32 2E 31 2E 31 31 30 33 00 ("VER2.1.1103\0")
Read @0x0040: A5 5A
Read @0x0040: A5 5A 00 00 02 00 00 00 (Beep, Auto-Off settings and maybe something else)
Read @0x0050: A5 5A
Read @0x0050: A5 5A 02 0D 07 00 00 00 00 00 00 00 01 00 00 00 00 00 00 01 (20 bytes, Power-up state)

[2nd Block]
(5 ms later, no idea what this is yet but depends on the power-up frecuency)
Read @0x0272: A5 5A
Read @0x0274: AA 73 CF 4B 35 BA 1B 4C
Read @0x067C: A5 5A
Read @0x067E: C3 F0 D1 3A A9 E0 87 3A
Read @0x0A7C: A5 5A
Read @0x0A7E: 96 E5 7F 3F 82 8F AF 38

[3rd Block]
(60 ms later, Read the presumably 1kHz cal data)
Read @0x025E: A5 5A
Read @0x0260: 32 AF AA 49 0C 71 DF CC
Read @0x0672: A5 5A
Read @0x0674: 38 88 34 3D 75 DC E7 3C
Read @0x0A5E: A5 5A
Read @0x0A60: 85 08 80 3F 61 C4 3E 3C


2. Power ON with Inductance at 10kHz power-on state:

[1st Block]
Read @0x0000: A5 5A
Read @0x0030: 56 45 52 32 2E 31 2E 31 31 30 33 00 ("VER2.1.1103\0")
Read @0x0040: A5 5A
Read @0x0040: A5 5A 00 00 02 00 00 00 (Beep, Auto-Off settings and maybe something else)
Read @0x0050: A5 5A
Read @0x0050: A5 5A 00 11 0B 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  (20 bytes, Power-up state)

[2nd Block]
(5 ms later, no idea what this is yet but depends on the power-up frecuency)
Read @0x033A: A5 5A
Read @0x033C: 73 B6 27 CA 00 EE 32 CB
Read @0x0744: A5 5A
Read @0x0746: A2 57 CA BA B6 DC 1C BA
Read @0x0B44: A5 5A
Read @0x0B46: 12 D9 7F 3F 03 6B A4 3A

[3rd Block]
(60 ms later, Read the presumably 10kHz cal data)
Read @0x0326: A5 5A
Read @0x0328: 3A 9D BF 49 9C 23 3A CB
Read @0x073A: A5 5A
Read @0x073C: C8 9A 21 3D 02 39 35 3C
Read @0x0B26: A5 5A
Read @0x0B28: 03 AB 7E 3F 8E 2B 33 3D

The 3rd block depends on the power-up frequency and is the same data that is read when changing frequency on the fly. No problem with this.

What's strange is that the 2nd block also depends on the power-up frequency and in fact is near the presumable cal data for that frecuency, but when changing frequency it is not read again, just on power-on. This may be a cal complement, but strangely is not read when changing frequencies.

Other strange thing is that in reagle's case, the 0x0050 read was 0xFF 0xFF and in my case are 20 bytes with the power-up state.

The most interesting part so far is the EEPROM Address 0x0054 which determines the power-up frecuency, so far I know the values for 100Hz, 120Hz, 1kHz and 10kHz (0x0B: 10kHz, 0x07: 1kHz, 0x03: 120Hz, 0x02: 100Hz) and taking into account that from 120Hz it's ascending by 4, 100kHz must be 0x0F

Next Step: Write 0x0F at address 0x0054 on EEPROM, power on, sniff all the way and watch what happens.

[vtl]

Very interesting thread here!

I had attached my EEPROM dump to my review thread but thought it might be good to keep all the hacking data in this thread

You have attached I2C dumps on frequency changes for all the transitions, but have you got the transition between 10KHz and 100Hz?

Asking this because I am wondering if it attempts to read the cal data from 100KHz, detecting it is blank, and them simply cycling back to 100Hz. If this is the case we should see an attempt to read location 0x326+0xC8=0x3EE

Another thing to attempt is to default our power up settings and then compare the binaries between models. It is possible the model differentiation is buried somewhere in the powerup settings

I wonder what happens if we simply change the hardware string? The Rigol hack is based on changing the model number also.

Only downside I can see to hacking the instrument is that we have no idea of the format of the cal values. The best you could do is copy someone elses cal values and hope their production process is consistent enough between boards.

[vtl]

I copied across the sections that were missing from my eeprom (presumably cal data) from the posts above

I can confirm changing the powerup settings does indeed work and my TH2822 (1KHz model) powered up with a 10KHz signal (confirmed on scope)

The only downside is that cycling through the frequencies with the button you cannot select 10KHz after leaving that mode and you must reboot the meter to get 10KHz again.

Would really be handy to have a full memory dump of a 2822A and a 2822C to see all of the differences rather than seeing small snippets of blocks

EDIT: Also works for 100KHz frequency by changing address 0x54 to 0xF, even though I have no cal data present

[carloscuev]

Yes! the semi-hack works. I'm powering-on my 10khz model at 100khz!





Frecuency confirmed in DSO as shown. I'll further investigate. I'm painfully using a bus pirate but I'll dump my whole EEPROM and post it here ASAP (1 or 2 horus) !

VTL, could you post Hi-Res pictures of your PCB? I want to compare if there's some resistor value difference, model selection could be a voltage divider because I haven't figured out yet any magic bit in the accessed EEPROM data at power-up that differenciates your model from mine.

[vtl]

I compared the above pictures of the 2822A and all the resistors connected to the MSP430 are identical to my board.

If there was model identification data it would most certainly be read during the powerup reads. I have copied all of your powerup data blocks and it doesn't appear to have any effect. Most likely the data is stored in the MSP430. If I could be bothered I might try plugging the jtag at work but most likely it will have code read protection on the MCU

[carloscuev]

Here's my meter's eeprom dump, could you try it in yours?

[vtl]

Just tried it, unfortunately doesn't turn it into a 2822A

[carloscuev]

Just tried it, unfortunately doesn't turn it into a 2822A

There's lots of bytes in the 0x0050 block that may be some model-set flags which then get resetted in EEPROM, just trying to think alternatives.

I found that when powerting up, if the meter doesn't find cal data (or whatever it is) it retries:

When Powering On at 100kHz hack mode:

[1st Block]
Read @0x0000: A5 5A
Read @0x0030: 56 45 52 32 2E 31 2E 31 31 30 33 00 ("VER2.1.1103\0")
Read @0x0040: A5 5A
Read @0x0040: A5 5A 00 00 02 00 00 00 (Beep, Auto-Off settings and maybe something else)
Read @0x0050: A5 5A
Read @0x0050: A5 5A 00 11 0F 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  (20 bytes, Power-up state)

[2nd Block]
(0.18 ms later, strangely this second block now appears continuous to the first)
Read @0x03F8 FF FF
Read @0x0802 FF FF
Read @0x0BF8 FF FF

[3rd Block]
(5.22 ms later)
Read @0x0402: FF FF
Read @0x080C: FF FF
Read @0x0C0C: FF FF

[4th Block]
(54.92 ms later retries the 2nd block)
Read @0x03F8 FF FF
Read @0x0802 FF FF
Read @0x0BF8 FF FF

[carloscuev]

There's something different that happens when it powers up and find that the FW version is different, I'm analyzing the sniff data.

[vtl]

http://kb.bkprecision.com/questions.php?questionid=182

This is interesting. Since Tonghui is the OEM of the 879B, the button presses to get it into firmware download mode is here.

[carloscuev]

I've been playing a lot with the meter and the eeprom, so far I can list this findings:

1. Without eeprom, the meter boots fine, and measures "fine" I noticed that without the eeprom, there's more parasitic capacitance, inductance and resistance of the leads, but a simple CLEAR procedure yields the same measurements as having the eeprom, so the data read from eeprom may be just initial CLEAR data, overwritten when making a manual CLEAR procedure. Not entirely sure about that as I don not have any L, C or R references and also let's face it, the meter doesn't give highly repetitive results between reboots measuring a common passive.

2. The FW version and model displayed on boot screen are taken from the MCU, although there's that same info on eeprom. At boot, the meter reads the fw version string from eeprom, but if its not the correct one it writes 0xF0 to 0x0000 and 0x0F to 0x0001 on eeprom (normal value of this addresses is 0xA5 and 0x5A), as a flag so that in next reboot if that data is read it rewrites eeprom fw version and model strings with the correct ones. In fact I've tried different values than 0xF0 and 0x0F and the behaviour is the same, it triggers a rewrite of those strings on eeprom. I was hoping to find some values that trigger a write from eeprom to the mcu's internal memory, but couldn't find one.

3. There's a lot of "orphan data" on the eeprom that is not read in any operation mode, this data is next to the presumable cal data, couldn't find any mode that accesses it.

[carloscuev]

http://kb.bkprecision.com/questions.php?questionid=182

This is interesting. Since Tonghui is the OEM of the 879B, the button presses to get it into firmware download mode is here.

It would also be interesting trying to load the BK firmware into a Tonghui, would you risk bricking yours loading the BK's 878B fw? Tough decision

EDIT: Even if firmware update goes well, the buttons would be messed up.

[valentinc]

    On the picture with the oscilloscope you were connecting the LCR meter directly to the BNC ? Or through a probe ? A 10X or 1X probe ? Because something does not seem right... In 10X the input capacitance should be ~15pF and ~90pF in 1X... Or your meter is indicating 35pF... What does it show when using 1Khz test frequency ? Or 10 Khz ? I mean, the input capacitance of the scope may vary with frequency, but not that much...

     About the buttons I think there are 2 options... Of course, it the FW works... You can either live with it, or cut the rubber on the back as a matrix with all the individual buttons and rearrange them in the case...

[carloscuev]

Sorry valentinc, that was connected through lots of cabling I had attached to the scope, here you have shots with the osc probe directly to the terminals.

1kHz:


10kHz:


100kHz:

[valentinc]

   Then it means that the only possible calibration data in the EEPROM are the parasitic capacitance, resistance and inductance that are stored when press CLEAR... And if so I'll live with it... It's no big deal to press CLEAR at every turn on... Considering the TH2822C price...

   I didn't understand exactly... When you power the meter on with the modified EEPROM, it boots at 100 Khz... And then if you press the FREQ button what happens ? I have the TH2822 (so only 1 Khz)... That means that if I want to switch between 10 Khz and 100 Khz I have to rewrite the EEPROM ? Because that is a real pain...

   Because I want to be able to use both 10 and 100 Khz modes... not just the 100 Khz...

   

[carloscuev]

   Then it means that the only possible calibration data in the EEPROM are the parasitic capacitance, resistance and inductance that are stored when press CLEAR... And if so I'll live with it... It's no big deal to press CLEAR at every turn on... Considering the TH2822C price...

It looks like that, but I have no way to confirm it. I tried several capacitors and inductors (the best ones I could get my hand on) and got very close results in 10kHz and 100kHz (after a CLEAR open and CLEAR short process).

   I didn't understand exactly... When you power the meter on with the modified EEPROM, it boots at 100 Khz... And then if you press the FREQ button what happens ? I have the TH2822 (so only 1 Khz)... That means that if I want to switch between 10 Khz and 100 Khz I have to rewrite the EEPROM ? Because that is a real pain...

In the case of your model ask vtl for details, he got the same one. What I understood, he could only get 10kHz or 100kHz on power up, when pressing FREQ button it would go back to 100Hz in both cases. However a more sophisticated hack using a EEPROM with a "page select" pin (if they exist) could work to select 10kHz power up or 100kHz power up.

I have faith that there's a magic word on the first 2 bytes of the eeprom that will copy the model information from the EEPROM to the MCU, and maybe perform some autocal process to write to EEPROM those data that I think is the default CLEAR open and CLEAR short for each frequency.

I am not very knowledgeable in the measurement process but I think it relies on the theta between voltage and current to determine if it's a cap or an inductor, and it's value. So the real "calibration" would be a timing accuracy issue I think. But again, I'm no one to assume that.

By now I've stopped researching any further hack, couldn't find anything else, but I'm looking forward to get some time to continue searching for a way to do it.

What I did to my meter is write to the eeprom the power up settings I like, solder it and have the WP pin high (write protected) so by accident I could not rewrite it by going to the UTIL menu. It works without problems.

[frankiek3]

I bought a TH2822A on eBay for under $190 shipped (USA)
I plan on writing the following to the EEPROM when I get it

Offset 0x54:
0x0F 100kHz power up setting

Offset 0x3F8:
2-byte header 0xA5 0x5A
8-byte data (leave as empty 0xFF?)
2-byte header
8-byte data (leave as empty 0xFF?)
2-byte header
8-byte data (leave as empty 0xFF?)

Offset 0x802:
2-byte header
8-byte data (leave as empty 0xFF?)
2-byte header
8-byte data (leave as empty 0xFF?)
2-byte header
8-byte data (leave as empty 0xFF?)

Offset 0xBF8:
2-byte header
8-byte data (leave as empty 0xFF?)
2-byte header
8-byte data (leave as empty 0xFF?)
2-byte header
8-byte data (leave as empty 0xFF?)
2-byte header
8-byte data (leave as empty 0xFF?)
2-byte header
8-byte data (leave as empty 0xFF?)

*header 0xA5 0x5A


I eventually plan on reading the firmware and finding what enables the 100kHz frequency from the enumeration. Thanks for all the info guys.

I think the battery charger wouldn't be to hard to add, I would need a photo of the other side of the TH2822C board for the component list.

-Frank

PS First post but I've been watching the videos and reading the forum for awhile.

[kamcm]

  At a first look the boards look identical (my TH2822 and your TH2822A). The only difference is on the TH2822C, which has additional circuitry for charging the 9V Ni-Mh battery, which ours don't have... I'll investigate further and let you know what I'll find.

  Now the problem is I can't find the firmware update for the BK Precision 879B on their website...

  If you can find the firmware update file for the BK, please let me know...

The firmware update files for the BK

http://kb.bkprecision.com/getattachment.php?data=MTgyfHYyXzFfdXBkM18wLnppcA%3D%3D
http://kb.bkprecision.com/getattachment.php?data=MTgyfHYyXzFfdXBkMl8wLnppcA%3D%3D

[kamcm]

I2C> (1)
Searching I2C address space. Found devices at:


I2C> (2)
Sniffer
Any key to exit
[[][][[0xA0+0x00+0x40+0xA5+][0xA0+0x00+0x41+0x5A+][0xA0+0x00+0x42+0x00+][0xA0+0x
00+0x43+0x01+][0xA0+0x00+0x44+0x01+][0xA0+0x00+0x45+0x00+][0xA0+0x00+0x46+0x00+]
[0xA0+0x00+0x47+0x00+][0xA0+0x00+0x50+0xA5+][0xA0+0x00+0x51+0x5A+][0xA0+0x00+0x5
2+0x01+][0xA0+0x00+0x53+0x11+][0xA0+0x00+0x54+0x07+][0xA0+0x00+0x55+0x00+][0xA0+
0x00+0x56+0x00+][0xA0+0x00+0x57+0x00+][0xA0+0x00+0x58+0x00+][0xA0+0x00+0x59+0x00
+][0xA0+0x00+0x5A+0x00+][0xA0+0x00+0x5B+0x00+][0xA0+0x00+0x5C+0x01+][0xA0+0x00+0
x5D+0x00+][0xA0+0x00+0x5E+0x00+][0xA0+0x00+0x5F+0x00+][0xA0+0x00+0x60+0x00+][0xA
0+0x00+0x61+0x00+][0xA0+0x00+0x62+0x00+][0xA0+0x00+0x63+0x00+]


I2C> =0X54
0x54 = 84 = 0b01010100


I2C> [0b01010100 r:1]
I2C START BIT
WRITE: 0x54 NACK
READ: 0xFF
NACK
I2C STOP BIT
I2C>
I2C>

I2C> [0b10100000 0 84 r]
I2C START BIT
WRITE: 0xA0 NACK
WRITE: 0x00 NACK
WRITE: 0x54 NACK
READ: 0xFF
NACK
I2C STOP BIT
I2C>

0X54 should be 0x07, but it returned 0xFF

I want to Write 0x0F at address 0x0054 on EEPROM.
Before doing that, I want to read the current record at address 0x0054,  I don't know why it did not work.

Please advice,

Thanks

[ddavidebor]

Normally lcr meter can't be calibrated

[kamcm]

I tried using Bus Pirate but with  no luck. I can sniff the bus on boot and get the same data as with Logic 16, but I can not talk to the chip. I wonder if somehow the bus is held high- not really an I2C compliant thing if I am not mistaken.
 I've tested it on standalone EEPROMs and the ones on an old VGA monitor boards and was able to read them just fine : Basically switch to I2C mode, do a discovery scan (1), then set address to all 0: [0xA0 0 0], followed by a read [0xA1 r:100]
On the above chips it works fine, on the one inside the meter I just get NACks on everything and bus scan returns nothing. Looking at the bus with a  logic analyzer probes from my scope, I don't see lines wiggle when bus pirate tries to drive them. Weird 

My buspirate unable to talk to the eeprom too..
Have u solved the problem ? please give me some advice

Everything returned 0xFF when I try to read some address.

Method1
I2C> [0b10100000 0 84 r] // Read directly from 0xA0+0x00+0x54
I2C START BIT
WRITE: 0xA0 NACK
WRITE: 0x00 NACK
WRITE: 0x54 NACK
READ: 0xFF
NACK
I2C STOP BIT
I2C>


I2C> [0b10100001 0 84 r] // Read directly from 0xA0+0x00+0x54
I2C START BIT
WRITE: 0xA1 NACK
WRITE: 0x00 NACK
WRITE: 0x54 NACK
READ: 0xFF
NACK
I2C STOP BIT
I2C>


method2
I2C>[0b10100000 0 84 ] //position the read pointer to 0xA0+0x00
I2C> [0b01010100 r:1] //read the values of 0x54 address
I2C START BIT
WRITE: 0x54 NACK
READ: 0xFF
NACK
I2C STOP BIT
I2C>

Method3

I2C> [0xa0 0x00][0x54 r:2]
I2C START BIT
WRITE: 0xA0 NACK
WRITE: 0x00 NACK
I2C STOP BIT
I2C START BIT
WRITE: 0x54 NACK
READ: 0xFF ACK 0xFF
NACK
I2C STOP BIT
I2C>

I2C> [0xa1 0x00][0x54 r:2]
I2C START BIT
WRITE: 0xA1 NACK
WRITE: 0x00 NACK
I2C STOP BIT
I2C START BIT
WRITE: 0x54 NACK
READ: 0xFF ACK 0xFF
NACK
I2C STOP BIT
I2C>

[kamcm]

I tried using Bus Pirate but with  no luck. I can sniff the bus on boot and get the same data as with Logic 16, but I can not talk to the chip. I wonder if somehow the bus is held high- not really an I2C compliant thing if I am not mistaken.
 I've tested it on standalone EEPROMs and the ones on an old VGA monitor boards and was able to read them just fine : Basically switch to I2C mode, do a discovery scan (1), then set address to all 0: [0xA0 0 0], followed by a read [0xA1 r:100]
On the above chips it works fine, on the one inside the meter I just get NACks on everything and bus scan returns nothing. Looking at the bus with a  logic analyzer probes from my scope, I don't see lines wiggle when bus pirate tries to drive them. Weird 

My buspirate unable to talk to the eeprom too..
Have u solved the problem ? please give me some advice

Everything returned 0xFF when I try to read some address.

Method1
I2C> [0b10100000 0 84 r] // Read directly from 0xA0+0x00+0x54
I2C START BIT
WRITE: 0xA0 NACK
WRITE: 0x00 NACK
WRITE: 0x54 NACK
READ: 0xFF
NACK
I2C STOP BIT
I2C>


I2C> [0b10100001 0 84 r] // Read directly from 0xA0+0x00+0x54
I2C START BIT
WRITE: 0xA1 NACK
WRITE: 0x00 NACK
WRITE: 0x54 NACK
READ: 0xFF
NACK
I2C STOP BIT
I2C>


method2
I2C>[0b10100000 0 84 ] //position the read pointer to 0xA0+0x00
I2C> [0b01010100 r:1] //read the values of 0x54 address
I2C START BIT
WRITE: 0x54 NACK
READ: 0xFF
NACK
I2C STOP BIT
I2C>

Method3

I2C> [0xa0 0x00][0x54 r:2]
I2C START BIT
WRITE: 0xA0 NACK
WRITE: 0x00 NACK
I2C STOP BIT
I2C START BIT
WRITE: 0x54 NACK
READ: 0xFF ACK 0xFF
NACK
I2C STOP BIT
I2C>

I2C> [0xa1 0x00][0x54 r:2]
I2C START BIT
WRITE: 0xA1 NACK
WRITE: 0x00 NACK
I2C STOP BIT
I2C START BIT
WRITE: 0x54 NACK
READ: 0xFF ACK 0xFF
NACK
I2C STOP BIT
I2C>

[carloscuev]

The MSP430 is pulling up or down strongly the SCL and SDA lines. You need to desolder it.

[kamcm]

The MSP430 is pulling up or down strongly the SCL and SDA lines. You need to desolder it.

Thanks for helping and answering....

[radioFlash]

Here's another photo of the TH2822A. It was a nice meter--until I killed it with an undischarged cap. After that, it only reported ERR E02. I'm thinking about getting another, but if I happen to do the same thing again, is there any chance of repairing it, and if so, what would most likely have been damaged?

[valentinc]

   Try to check the continuity of F200, right above the spring that connects to the shield on the back of the case... I'm not sure if it's a polyswitch or a simple SMD fuse... But it's worth measuring it...

[kamcm]

I try to use I2CEEPROMWIN.c to dump the eeprom with buspirate.

It works but the file format messed up.

Please advice how to fix it?

Thanks



 

[carloscuev]

I see no problem, how should it be?

[valentinc]

       Try to save it in hex format and open with this software... In demo mode...

       https://www.wetransfer.com/downloads/ce391a503aa83e088d0c58c57cac53a520140209025302/725ef2cbf259ea746b7feb03f57787cc20140209025303/fab982

[all_repair]

Here's another photo of the TH2822A. It was a nice meter--until I killed it with an undischarged cap.

I held back buying a TongHui or other expensive cap meter precisely of this reason.   I went with a cheaper noname LC200A.  But this meter is surprising accurate.  Hurt less if someone forgot the cap is charged in the midst of highly focused work.

[kamcm]

       Try to save it in hex format and open with this software... In demo mode...

       https://www.wetransfer.com/downloads/ce391a503aa83e088d0c58c57cac53a520140209025302/725ef2cbf259ea746b7feb03f57787cc20140209025303/fab982

Thanks for helping,

I write 0x0F at address 0x0054 on the EEPROM, but when I power on the Th2822A, it's still power up with 1kHz.
Anyway, I will try it again!

[kamcm]

EDITED:
The problem has been solved, It suddenly working now, but I don't know why.

[kamcm]

It may possible to change something in the eeprom to enable the 100kHz option
https://www.eevblog.com/forum/Smileys/default/smiley_laughing.gif


Updated: I changed 0x16 from 0x41 to 0x43, but it didn't work...

[dav]

Any news about a final TH2822A to 2822C conversion?

Did anyone dump the EEPROM of a 2822C?

And did anyone try the 100kHz mini-hack on a BK Precision 879b?

[Szybkijanek]

Hi, can anyone share the software FastAccess for Tonghui LCR meter?

Ok, here is link:
http://www.tonghui.com.cn/cn/upload/Download/20200518171724482.rar