PackProbe (alpha) for dumping data from laptop packs

Batteries and Chargers Rechargeable Batteries
1

I’d like to announce the first public release of PackProbe.

PackProbe is a tool for quickly gathering diagnostic information to use in assessing the health and age of most laptop battery packs. For example, here is data from one of the $12 Acer NOS pulls that people have had such good luck with:

PackProbe is for budget-minded flashaholics, and anyone else, interested in recovering inexpensive, high quality, rechargeable lithium ion cells from used and surplus laptop battery packs.

PackProbe gives you a quick (1 minute/pack), inexpensive ($20 in parts) way to get at the data stored in almost all laptop battery packs. That data includes manufacture date, count of charge/discharge cycles, pack voltage, and, in some cases, voltages for the individual cells.

The typical approach people use for assessing the quality of laptop pulls is to tear the pack apart, separate the cells and check voltages for each cell. Cells below a threshold (often 2.5 to 3v) are recycled. The rest are charged, and checked for excessive discharge overnight. Finally, the remaining cells are put through a cycle on an analyzing charger. This approach can lead to good cells being pitched, and requires the investment in time and effort in cells that end up failing.

The additional information offered by PackProbe can help you decide whether a pack is worth tearing apart in the first place, and whether low cell-voltages are likely due to excessive self-discharge due to old-age, or just spending time on a shelf.

To use PackProbe in its initial release, you’ll need an Arduino-compatible board, familiarity with running and modifying arduino sketches, and some basic electronic prototyping supplies. The documentation includes more details. I’ve also included information on pinouts for packs I’ve worked with, and advice on discovering pinouts for unknown packs.

The next version of PackProbe will be refactored to make it easier to run on a variety of Arduino boards without editing the source code, and after that, I plan to make it easy to input pack data into a web-based database to make it easier to track your cells, and to try and find patterns in pack “aging.”

I think this will probably be of interest to people beyond the BLF community, so I plan on setting up a forum for people to share tips and feedback. For now though, there are comment forms on the site, and this thread.

Another example, this one from one of the Lenovo packs that Hagg911 is selling (unfortunately, I haven’t figured out how to get cell real voltages from Lenovo packs yet):

I hope people find it useful. Feedback is appreciated, as is help debugging communications with HP TD06 packs (and similar), and figuring out how to get voltage for individual banks of cells from Lenovo and Dell pack.

Thanks!

2

(reserved for updates)

3

Very interesting, great work! How did you set about deciphering the data bus? And finding out the I2C address of the pack?

4

I... Holy smokes man! That is some serious packpull extravaganza hardware you developed! TY. I'll have to look into it a lot more to really understand it though.

What a great idea!

5

Most are common type setups

Very interesting OP…excellent, thanks for posting this!!!

Did you write the coding for the alpha release sketch?

Ultimately it will come down to tearing the cells down to retrieve the batteries in the end unfortunately, then a quick hit with a multimeter probe will determine cell voltage, but your application definitely will give a quick overview/snapshot of what is possibly there

6

I’m guessing a Bus Pirate, or Salae (sp?) Logic analyzer would do the trick for data decipering. To answer my own question, the continued repetition of the I2C writes would give up the I2C address, not that it really matters if you are just listening in.

7

It may be that some packs are just not designed for individual cell voltage readout, as it would require more wires and sensors. I know the Asus packs I tore apart didn’t have any extra wires to the table between cells, just a temperature sensor. I have some old Dell, Lenovo and possibly HP packs that can be tested if I can find where I stashed them.

KuoH

8

Thanks for the responses! Glad to see that this is indeed of interest to someone besides me.

Not much to the hardware, at this point, just an arduino, some wires, and a couple of pull-up resistors. I’ve got some ideas on making it a little more turnkey and foolproof (I let some of the magic smoke out of one of my boards due to a dumb but easy to make mistake.

I’ll do a demo video soon, if someone doesn’t beat me to it…

Up to this point I’ve done very little reverse engineering. Its mostly been about finding and reading specs, and existing code. I’ve started doing some reverse engineering to try and figure out stuff that doesn’t work as expected (no cell voltage from Lenovo Thinkpad and Dell packs; SMBus “handshake,” but no data from some HP packs). That would be infinitely easier if I actually had a compatible laptop and could use a logic analyzer to “sniff” the communication and figure out the bits I’m missing. Definitely something I could use help with.

The code I’ve released is copy-paste from some other projects (credited in the source code, if not the documentation at this point), and my own. My impulse was to clean it up more before releasing it, but I figured it was good enough to put out there as a “minimum viable product.”

A multimeter check of cells from packs you’ve torn open is a no-brainer, but I’m happy to report that for packs where the cell-voltages is available, the reported values lines up very well with what I get when I test with a multimeter. The packs also estimate full charge capacity, accounting for aging. Unfortunately, the accuracy of this information isn’t very good if the pack hasn’t been through a charge/discharge cycle recently. For example, if you look at the Lenovo pack data I posted, you’ll see that it estimates that the estimated “Full Charge Capacity” is less than less than 1/2 the design capacity after just 112 cycles. I haven’t torn apart that specific pack yet, but cells from a pack of similar age and cycle count still retain ~80% of nominal capacity.

I think the utility of this will depend on your own goals and proclivities. If you are just doing a pack here and there that you dug out of a recycle bin, then pitching perfectly good cells based on their voltage, and/or running the cells through a cycle on an analyzing charger may not actually be issues worth working around.

On the other hand, if you are paying for what you think are NOS packs, then verifying that fact and keeping low-voltage cells that you’d otherwise pitch has a clear $ value attached to it.

Similarly if your goal is sifting through used packs to get a bunch of cells to build into a new pack for some sort of EV or off-grid project, then this can both save a lot of time, and get you important history on cells that you can’t get otherwise so you don’t combine old cells with young cells based only on basic metrics.

I’m actually planning to look very closely at a lot of cells from packs with diverse histories to try and improve the predictive model. If other people want to pull packs apart and do tests on every cell, well, the more the merrier.

9

Interesting. All the packs I’ve opened from HP, Dell, Lenovo, Acer, Asus, Sony, Gateway, and a Toshiba that isn’t SBS compliant, have leads to allow voltage reading and probably top-balancing of all the banks. I have a Lenovo pack with damage to the circuit board near the main connection to the positive terminal of the pack. It normally reports an 8V pack voltage, but if I fiddle and bend the board, it goes up to 12V. Doesn’t seem like that would happen if it were taking one voltage reading for the whole pack, rather than individual readings for each bank and then summing them in software.

The smart battery standard doesn’t actually specify commands for getting the individual cell voltages, but I found that the documentation for Atmel and TI’s smart battery dev kits both reference the same SMBus commands for this data, and those commands work to get cell voltages on packs from Apple, Gateway, Asus, Acer, and the HP packs I’ve been able to get data from. I’ve also found that cell voltages are available through a proprietary API on Windows and Linux. I haven’t found similar evidence for Dell.

My assumption is that at least the Thinkpad packs are making the info I want available over SMBus in undocumented ways. I’ve tried walking through all the command codes on Lenovo and Dell packs to see if any of them generate values that look like individual cell voltages, and I haven’t found anything. I’m guessing that the values for multiple cells may be packed together in the result returned for a single command code, perhaps packed with other manufacturer-specific data. Next step, short of scrounging up a compatible system, is dumping as much data as I can get from a number of packs and looking at similarities and differences.

I look forward to anything you can figure out from looking at your stash.

10

One difference between IIC and SMBUS can the inclusion of a CRC check byte (aka PEC) byte on the SMBUS transfers. If you are not properly implementing the PEC they pack may not respond, particularly to register writes. I’ve also seen SMBUS devices (like the Melexis IR thermometer chip) lock up and stop working if the PEC was not included in the transfer.

11

Thanks. That sounds like the first thing to look at for the HP packs I’m having a problem with, because to this point, I’ve ignored the PEC and any other error checking/correction.

12

Thank you for releasing this. :beer: :beer:

13

Wow, this is incredible, thanks a lot eas!

I’ll try the setup out sometime this week and let you guys know how it goes.

Thanks again for the work. Any constraints with running it on an Arduino Uno?

14

Uno should be fine, but right now you’ll have to hand edit the sketch to switch from output to the Arduino Yun’s network console to the standard Serial console. Its in the docs, and there are comments in the code. One of the goals of refactoring the code is making that switch easy, or even automatic.

15

Great, I think I’ll be fine then. Thanks!

16

Interesting post and cool looking product, thanks. Hmm my dad just gave me an Arduino Yun a couple weeks ago and I’ve been meaning to play with it.

17

I decided to focus on the Yun because the wireless connection meant that an accidental overvoltage wouldn’t make it to my computer. Of course, the Yun is expensive enough that I don’t exactly feel relieved that I dodged a bullet when I let some of the magic smoke out.

18

I’ve just written up a post on what I’ve learned by using PackProbe to dump data from 34 used lenovo packs I got from Hagg911.

The main take away is that the initial cell voltage from a used pack doesn’t tell you much about the wear and tear the pack has been subject to, at least not at the cycle counts I saw (<300).

19

Excellent project and idea; there definitely isn’t enough attention out there in terms of being able to read out the diagnostic information in smart battery packs!

In terms of your last post, the cell/pack voltage isn’t a good determining factor for estimating the capacity/state of health of a Li-ion battery pack (with exception to very low cell voltages), but is instead related to cell state of charge.

Now, in regards to the code, the Time-to-Full/Empty (the Minutes remaining readout in the PackProbe software) commands are actually _un_signed shorts (16-bit integers), with 0xFFFF (shown as –1 in your code) meaning ‘N/A’. Also, note that the State of Health command is non-standard as the official SBS specs don’t have it in the list.

(edit: Removed “as the” from 3rd paragraph)

20

Welcome to BLF, ginbot86. That’s a heck of a first post!