Dispo Adventures, Episode 1: Reverse-engineering and “running Windows 95” on a disposable vape with a colour LCD screen

As seen on Hackaday!

TL;DR: Disposable vapes can have LCD screens…?! At least they’re moddable now – check out my GitHub for docs, tools, and links to similar projects if you want to try this on a Kraze HD7K or Raz TN9000 (maybe some others too).

Disposable vaping devices have become distressingly common in recent years, and an increasing ecological burden given how many (perfectly reusable!) lithium-ion batteries are discarded into landfills and roadsides alike. Even worse, some of them include flashy colour LCD screens! I’ve been collecting and harvesting disposable vapes from my friends for a few years now, but only recently have I had a chance to take some of these LCD-equipped models apart; while doing so, I figured I could pioneer some reverse-engineering efforts while adding custom theme/skin support along the way. (For the record, I don’t vape or smoke but plenty of my friends do. I’m just in it for the batteries and electronics.)

A modified Kraze HD7K disposable vape, with my custom Windows 95 theme applied.

A modified Kraze HD7K disposable vape, with my custom Windows 95 theme applied.

The vape in question is found in my area of Canada as the Kraze HD7K, but it seems to go by other names like the Raz TN9000. Internally, they are the same minus some firmware and logo differences.

Disclaimer & Safety Information

Harvesting disposable vapes is not without its own risks, and I will not accept any responsibility if something goes wrong if you try it yourself. This should only be attempted if you are familiar with handling lithium-ion batteries and the safety implications that they pose.

Nicotine can enter your bloodstream simply by getting vape juice on your skin (so wear gloves!), and can be messy if it gets on your clothes and workspace.  The enclosed lithium-ion battery can also cause burns or property damage if short-circuited, and are usually not equipped with protection circuits; the fact that these cells can push several amps in such a small package is the precise reason they’re (wastefully) used in this application. Rechargeable disposable vapes pose a slightly higher risk if the cell is near or at full charge when disassembled, whereas pure disposables are almost always fully discharged. Discharged cells inherently hold less energy and this reduces the fire risk should a catastrophic failure occur during disassembly, but they still need to be treated with respect. Overdischarged cells below 2 volts may not necessarily recover, but if you decide to attempt a recovery, you must bring them back up to 3 volts at a very low current (on the order of tens of milliamps), after which it is possible to charge them normally.

Vapes harvested from the roadside should only be picked up when it is safe to do so, and should be inspected for damage as soon as possible. These “street lithium” vapes could be water-damaged and also physically damaged from getting run over by vehicles. Any cells with a punctured or torn pouch/casing are unsalvageable and must be recycled. My own experimental data finds that the majority of run-over cells survive, but I would not recommend using them without being absolutely sure that there is no further internal damage (after charging the cell with supervision, it should have at least 90% of its rated capacity and no appreciable self-discharge after a few weeks of rest. Otherwise, put it in the recycle bin where it belongs). Even then, only use them in applications where their failure will not cause collateral damage, like in an outdoor solar-powered lamp that is kept away from anything flammable. If you’re not comfortable with these conditions, just recycle the vape at an appropriate facility in accordance with local regulations (some vape shops will have recycling bins, and hardware stores often will accept rechargeable batteries for recycling too).

Teardown

Without any screw holes, I needed to find another way to (non-destructively) open the vape. I noticed a seam in the bottom end cap, and found that sliding a slotted screwdriver into that seam and some gentle prying action was able to dislodge the internal clips. Once that cap was free, a sliding airflow “switch” fell out as well. Removing the core of the vape was pretty straightforward, but it did require some pliers to pull it out due to its friction-fit construction.

With the core exposed, I could see that the vape uses a 13450-size lithium-ion pouch cell (13mm diameter, 45mm length) and a generously-sized vape juice reservoir, with a sponge to absorb the juice and prevent it from leaking. I also noticed a small 9-pin right angle header that connected a black “logic board” that held a microcontroller and LCD screen, and a green “power board” that had the inhalation sensor, heating coil connector, USB-C connector and solder pads for the battery.

Reverse-Engineering

The three main components of the vape’s logic board are the microcontroller, an SPI NOR Flash chip, and the LCD screen.

The microcontroller is a Nations Tech N32G031K8Q7-1, containing a 48MHz Arm Cortex-M0 CPU, 64k of internal Flash and 8k of SRAM; the SPI Flash is a 1MB Giantech GT25Q80A-UZLI; and the LCD is of an unknown maker but has a part number of FXD096QQ08B-F, with a resolution of 80×160 pixels.

Given that the LCD is what makes this vape particularly special, I decided to look into what controller and pinout it uses. I had a hunch that it would use a common interface and controller (to keep costs low), and searched for a 0.96″ LCD with 13-pin FPC (flexible printed circuit) connector. This led me to the Smart Prototyping #102106, which used a 13-pin connector and seemed to have a compatible pinout. The aforementioned LCD uses a common ST7735S controller, and is controlled through a 4-wire SPI interface (clock, data, command/data select, chip select). (Additionally, I looked on Alibaba for a similar LCD, and found one source that sells them for about $1.25 each in large quantities; this suggests that the displays themselves add significant cost to the vape, but are still cheap enough to be utilized in a throwaway device.)

I searched other websites for LCDs with the same dimensions and connector, and they all used this pinout:

Pin Name Function
1 TP0/NC Unused (may be used for some touch sensor?)
2 TP1/NC Unused (may be used for some touch sensor?)
3 SDIN SPI data to LCD
4 SCLK SPI clock
5 RS Logic low = command, high = data
6 /RST Reset (active-low)
7 /CS Chip select (active-low)
8 GND Power supply/signal ground
9 NC Not connected
10 VDD Power supply (3.3V)
11 LEDK LED backlight cathode
12 LEDA LED backlight anode
13 GND Power supply/signal ground

To ensure that the pinout I was looking at really matched up with what was in the vape, I connected the data, clock and other control lines to my DSLogic Plus logic analyzer and sniffed the traffic as the vape initializes the display. A glance at the logic analyzer data confirmed the pinout.

To further confirm that I had an ST7735S-based display, I resoldered the LCD onto a TSSOP-to-DIP breakout board (which was annoying, as the pin pitch was slightly different and alignment needed much precision), and used the Adafruit Graphics Library and ST7735S driver on a Teensy 3.0 microcontroller, and it worked! Well, mostly. While black-and-white text worked perfectly, the red and blue channels seem to be swapped around when using the tft.initR(INITR_MINI160x80) routine, and it seems that I wasn’t the only one with this issue.

I decided I was finished with the idea of reusing the display alone, and began looking into how the vape itself works, and how it displays images. The first step was to look into the memory contents of the 1MB SPI Flash, as that is a pretty large amount of memory for such a simple device. I desoldered the chip and mounted it on a SSOP-to-DIP adapter, and dumped its contents to a file using my MiniPro TL866CS universal programmer.

My suspicions were confirmed when I analyzed the image data being sent to the LCD matching what was in the beginning of the SPI Flash. The data also looked like it was in a raw “RGB565” format, which is a method of packing a 16-bit pixel into two bytes of data; the term “565” refers to 5, 6, and 5 bit values belonging to the red, blue and green channels respectively. Since the image on the screen used blue in the top-left of the image, this supported my findings since the data similarly had only set bits belonging to the blue channel, and also further describes the data as being “big-endian” assuming that the red bits are read out before the green and blue.

The data seemed to be transferred in 4096-byte blocks, which I speculated to be performed using DMA (direct memory access); the data transfers seemed too fast and regular to be done in software alone. This later proved to be true when I had a chance to analyze the RAM of a working vape.

(Flash) Map-Making

With the 1MB SPI Flash chip dumped, it was time to take that apart too… but digitally! Armed with a spreadsheet, a hex editor, ImageMagick and an online RGB565 renderer by Rinky-Dink Electronics, it was time to begin the (grueling) process of unpacking the entire SPI Flash’s contents.

My first step was to try extracting the first image frame, which I calculated to be 25,600 bytes in size (80 x 160 x 2 bytes per pixel). The next step was to use ImageMagick to convert the raw RGB565 data into a PNG for viewing on a computer:

magick convert -size 80x160 rgb565:<file>.bin <file>.png

The result looked like an image, but the colours were all incorrect! I then tried the Rinky-Dink online RGB565 renderer, which didn’t have this issue. Most of my attempts were performed with ImageMagick since it was easy for me to carve and test different image sizes. (Later on, I decided to pipe in an RGB test image and it seems that ImageMagick interprets what should be RGB data as BRG…)

Attempting to convert the rest of the images felt like I was staring into The Matrix, trying to make sense of scrambled image data that looked like an autostereogram (the ones where you need to cross your eyes to form an image). Since the data on the Flash was raw and undocumented, I had no idea where each image began and ended, and what their resolutions were. It took a lot, and I mean a LOT, of trial and error to figure out the mappings.

This slideshow requires JavaScript.

One by one, I catalogued each image and added it to my spreadsheet, documenting its address, length, resolution, what category it belonged to, and if it was in a sequence of images (an animation, essentially).

This slideshow requires JavaScript.

This continued up until I was over 95% through the entire 1MB address space, and I even found unused animations (or at least unused for the version customized for my area). There was a bit of blank space, which I ignored for a while… but as it turned out, there was some other hidden data stored further down (it was the counter that the vape used to determine how many “bars” of juice to display). I won’t show the whole table since it’s over 100 rows long, but here’s an excerpt (you can find the whole table on my GitHub if you’re interested):

Index (#)

Offset (Hex)

Length (Hex)

Frame H (px)

Frame V (px)

Category

Seq (#)

0 0 6400 80 160 Background 0
1 6400 2880 72 72 Battery Icon 0
2 8C80 2880 72 72 Battery Icon 1
19 33D00 6400 80 160 Vaping Animation 0
20 3A100 6400 80 160 Vaping Animation 1
72 D53E2 6400 80 160 Plugin Background 3 0
73 DB7E2 E9A 21 89 Charger Logo Wipe 0
74 DC67C E9A 21 89 Charger Logo Wipe 1
104 F8000 4 N/A N/A Total Vape Time x0.01s (LSB->MSB) N/A
105 F8004 1 N/A N/A Vape In Use Flag (0xBB) N/A

Toolcrafting

With the whole SPI Flash mapped out, I was able to, with much help from ChatGPT, make a couple custom tools: a Flash image splitter and repacker. I also used the Rinky-Dink UTFT library‘s conversion tools to enable replacement of the image data (i.e. custom theme support). Imagine that – custom theme/skin support on a vape, now a reality! With no help from the manufacturer!

Rationale

You might be asking: why anyone would do this? Honestly… I’m not sure; I just was fascinated by a colourful disposable vape and just had to thoroughly take it apart and learn everything I could about how it worked. Maybe this could give a reason for people to attempt to refill (and therefore reuse) their disposable vapes, and a reused vape is a vape that doesn’t end up in the landfill or roadside – and frankly, that’s good enough reason for me.

With the tooling set up, it was time for me to prove that these vapes can be rethemed, and I thought of a great retro aesthetic that is completely different from the original theme, yet easy for me to make with simple image editing tools: Windows 95.

It runs Windows 95?!

Okay, not really… but I wanted a cohesive but entirely different theme to apply to the user interface, and I’m not nearly artistic enough to go about making a Doom theme (I tried, but couldn’t think of much that would work within the limitations of the original firmware). Using little more than a copy of Windows NT 4.0 (essentially the enterprise/professional version of Windows 95), some virtual machines, screenshot and recorder tools, and Microsoft Paint, I was able to create a UI that faithfully recreates the nostalgic Windows 95 user interface in a tiny 80×160 space.

Tip: if you need to frequently reprogram a device that uses an external (serial) memory chip, consider adding or making a socket for it. Additionally, vapes that use a 2-pin microphone element for inhalation sensing can be activated by shorting the pins to ground with a pushbutton, or even capacitively with your finger. If the vape requires a load to be present, a small halogen bulb will do the trick.

Main Screen

The main screen features the classic teal background, with two “windows” to represent the battery charge and vape juice levels. In keeping with Windows UI mechanics, the juice level is rendered as if it were an inactive window.

Battery Level

The battery icon, while looking trivial to implement, required a lot of manual work to create the icons. From Windows 95 through XP, the default Windows UI’s battery icons were very limited in granularity: full, half, near empty, and empty. I had to employ “tweening” techniques by copying rows of pixels and aligning them to the desired levels, then manually painting in pixels where required. I also used a slightly more-detailed icon set from Windows XP which added a bit more of a highlight on the left side of the icon, rather than a flat blue colour. While it does somewhat detract from the “purity” of the icon set, the improved appearance was worth the tradeoff.

Vape Juice Level

The juice level representation was a lot more challenging to conceive. I thought of using the Recycle Bin icon, but figured that making icons between empty and full wouldn’t produce a very unambiguous representation. I also thought about the magenta/blue pie chart used to represent disk usage, but that option was ruled out for similar ambiguity issues (I know that magenta is free space, and blue is used space, but this might not be intuitive enough without some sort of legend).

I finally figured that I had just enough room to make the world’s tiniest Explorer window, with just enough space for six 16×16 small icons. I picked a selection of icons that one would see in the C:\ root directory: folder, batch file, system file, application, .ini settings file, and unknown file (the one with a small Windows logo on it). As the vape juice is depleted, an icon is removed from the window. Once the juice is deemed by the microcontroller to be completely depleted, the blinking folder icon almost becomes homage to a similar phenomenon on Mac computers if it cannot find an operating system to boot.

Charging Animation

This one was another challenge, mainly due to the limited animation size of thirty 21×89 frames in an off-centre position atop a static background; not only that, the firmware dwells on the last animation for about a second, so any animation loop will need to stop cleanly at the last frame. The lack of animatable screen space meant that a file copy dialog was a non-starter, and the Windows 95 boot screen was also infeasible. I eventually settled on a small “Charging…” dialog box, with the animated hourglass cursor in the middle. One concession that I had to make was doubling each cursor animation frame, as well as losing one corner and edge of the hourglass during the initial animation sequence, as the hourglass is 22 pixels wide for the first few frames. Thankfully, this happens quickly enough that it isn’t particularly noticeable. I had pondered overlaying this dialog box atop the main UI’s “windows” but found the result to be too crowded in appearance, so a single dialog on the teal background was chosen instead.

Vaping Animation

This one was arguably the most fun yet the most frustrating to actually implement. I knew I wanted to use a screensaver for the vaping animation, but which one? I needed a screensaver that was both iconic, but also looped cleanly. Flying Windows was a contender, but proved to scale down poorly and, due to its random nature, looped poorly as well. 3D Flower Box was skipped for the same reason (and wouldn’t have looked good looping once per second anyway). 3D Maze, 3D Text, and the simple graphic screensavers like Marquee, Mystify and Beziers were out too… so what’s left? Only one screensaver was left in the pipeline… a 3D pipeline – heh, get it? 😉 (sorry. I’ll see myself out for that joke.)

3D Pipes is one of the most famous Windows 95-era screensavers, and despite its randomly-generated nature, had relatively clean transitions which make looping animations easier. It also scaled well both in terms of resolution and in time, but was an absolute pain to record. I eventually settled by running the Windows 95 version in a Windows XP virtual machine, with a custom screen size as close to a 1:2 aspect ratio as possible. After taking a screen recording, I had to then choose the sequence that looked the best, extract 16 frames from the video, scale those down to 80×160, and only then did I get my looped screensaver animation, but the result was well worth the effort. The particular run that I captured even had a flame-like shape to it!

Other Discoveries

With my main goal of extracting and replacing images on the vape accomplished, I decided to look further into its inner workings and learned a few things along the way.

A Secret Port

During my initial teardown, I noticed that the microcontroller’s SWD (Serial Wire Debug) programming lines were brought out to the USB-C port, but in an unusual way. The CC1/CC2 lines were not only used as regular 5.1k pulldowns to enable USB-C chargers to recognize the vape, but also as a programming connector. I had to build a custom cable to interface with it, but was able to use my Segger J-Link to communicate with the microcontroller in situ. As a bonus, the firmware is fully readable, without any encryption or readout prevention enabled!

It’s Not About The Puffs

For a device marketed with a capacity of several thousands “puffs”, one would think that this would be tracked as a means to provide a vape juice gauge to the user. However, this turned out to not be the case, in more than one way.

Vape Usage Counter

The vape usage/time counter at exactly 10 seconds of usage. 0x3E8 = 1000, or 10.00 seconds.

Unlike many other disposable vape implementations, the juice meter’s data was stored in a non-volatile memory location, since neither a reset nor power cycle would reset the meter back to full. I was initially unsure where the microcontroller was holding this variable, and scanning the internal Flash memory and the extra few “option bytes” available above the usual firmware region showed no changes. It wasn’t until I decided to run a difference on the external SPI Flash between “puffs”, where I noticed bytes changing near location 0xF8000, in a sea of empty/0xFF bytes. Erasing the bytes from locations 0xF8000-0xF8004 resulted in the vape juice meter resetting back to full! Since vape inhalation sensors typically include a 10 second timeout, I decided to trigger a 10-second “puff” and noticed the memory location had updated to 0x3E8, which corresponds to 1000 in decimal. It was then easy to determine that the microcontroller was counting vape time with 0.01-second granularity.

A Beeline to the Buffer

Since I had access to the microcontroller’s memories in near-real time, I decided to experimentally determine where the data from the SPI Flash was getting copied into RAM. Since I already knew the microcontroller was using DMA to stream image data from the SPI Flash, I figured that I could fill its entire contents with human-readable text (in my case, I chose consecutive copies of the “Bee Movie” script) and observe the RAM’s contents changing in Segger J-Mem. This technique worked immediately, and it was obvious where the DMA buffer was held in RAM!

Blinking Power, Hidden Version (Screen)

Out of boredom and wanting to repeatedly test the charging animation during development, I was rapidly connecting and disconnecting power to the charging port. After several consecutive fast insertions and removals, I saw a black screen with red text pop up. It read “GV-K23 0904V1” and trying to capture it was difficult until I had the idea to use J-Link Commander to halt the CPU as soon as I triggered it. Given that the version screen had text, yet I saw no text strings in the firmware dump, I figured it had to be a bitmap image, and it was! It was stored near the very end of the firmware. While identifying where it was inside the dump was simple, trying to reconstruct it from the dump was not. The extra padding of 0x00 bytes (basically black when interpreted as RGB565) that didn’t align with 60 pixel/120-byte rows, it took a lot of experimentation with image sizes and offsets until I got a legible picture. Even now I’m still not entirely sure if I’ve captured the entire bitmap.

Further Efforts

In the time between me starting this reverse-engineering/modding project and my publication of this blog post, I released my documentation and rudimentary tools on my GitHub profile in the hopes of drumming up more support from the community. Within days, another GitHub user by the name of “xbenkozx” was able to apply and extend my research into the external Flash memory mapping and debugging facilities. He created his own Flash dumping and modding tools, and even built custom reflashing firmware that only needed access to a SWD debugging/programming dongle and a custom cable – no surface-mount soldering required (i.e. programming that is beyond my current skillset 🙂 ). He also made more detailed analyses of various board revisions, and some important incompatibilities that could have resulted in damage due to overheating of the vape’s heating coil. Check it out!

Hopefully this reverse-engineering and reuse campaign can branch even further. Perhaps development environments (maybe an Arduino board profile?) or alternative firmwares can be developed to allow these boards to be reused in other applications, given that these vapes already provide easy access to a bright LCD screen, a decently powerful Arm microcontroller, Li-ion battery charging, and a megabyte of SPI Flash storage plus some extra LED indicators. Some board versions even have Rx/Tx pads for a UART serial port, which could make communication between different devices a possibility.

In terms of just theme creation, I made an editable template on my GitHub repository, with example bar graphs and animation frames denoting positioning and frame count. Maybe someone out there with more graphics/artistic/programming talent than me could figure out a way to “run Doom” on these vapes! 😀

Conclusion

Disposable vapes are almost everywhere, and their wastefulness goes beyond just some rechargeable batteries and circuit boards – some have bright LCD screens… and yet somehow these are considered throwaway devices!

If you have some of these LCD-equipped disposable vapes like the Kraze HD7K or RAZ TN9000, perhaps try playing around with them a bit. I’ve spearheaded a community campaign on GitHub to reverse-engineer these vapes, which allows them to be reused or repurposed more easily. If you want to take the path of reuse, I and some others have made customization and reflashing tools available. There is also potential in reusing just the microcontroller board since the vape features a pretty powerful microcontroller and a lot of storage space for images.

Review of XTAR Li-ion 4150mWh AA / 1200mWh AAA batteries and L8 USB-C 8-bay charger

TL;DR: XTAR’s new lithium-ion AA and AAA batteries offer a decent alternative to Ni-MH rechargeables if weight and/or output voltage is a concern, but only for low- and medium-drain applications. You can charge them directly with 5V if you don’t have a dedicated charger on hand. Their new L8 charger works for their Li-ion 1.5V batteries and third-party Ni-MH cells alike.

XTAR's 4150mWh AA, and 1200mWh AAA Li-ion batteries in an XTAR L8 USB-C charger.

XTAR’s 4150mWh AA, and 1200mWh AAA Li-ion batteries in an XTAR L8 USB-C charger.

Lithium-ion AA and AAA batteries have been around for several years (see this review of the Kentli PH5 I made several years ago), but that doesn’t mean they haven’t made progress in energy density. Last summer, XTAR offered me a bundle of their latest and highest-capacity AA and AAA Li-ion batteries to try out, alongside their latest L8 multi-chemistry 8-bay charger. After several months of testing, I have collected enough data on which to base my review upon.

FULL DISCLOSURE: XTAR provided these batteries and corresponding charger to me at no charge for an independent review. They had no editorial control over this review, I have not been compensated monetarily, and all opinions expressed in this review are my own.

Introduction

XTAR is no stranger to the world of lithium-ion rechargeable batteries, and their new Li-ion 1.5V AA and AAA batteries offer an incremental improvement to their previous offerings, increasing their AA batteries from 3.3 watt-hours to 4.15 watt-hours of energy, and their 1.2 watt-hour AAA batteries enjoy a small performance boost from 1.5 amps to 1.6 amps of maximum continuous discharge current.

Like all Li-ion 1.5V batteries that use a DC-DC converter internally to regulate the nominal 3.7 volts from the internal cell down to 1.5 volts, XTAR’s AA/AAA batteries feature a flat discharge profile irrespective of load current and state of charge; their better offerings will even reduce their output voltage from 1.5 to 1.1 volts when the batteries near empty, helping to signal to the device they’re installed in that a recharge will soon be necessary; without this feature, a powered device will “think” it’s perpetually at 100% charge until it suddenly turns off.

Some Li-ion 1.5V batteries include charge regulation circuitry internally, which makes charging them easier since you can provide 5 volts from USB power to directly charge them. Some have a (micro-)USB or USB-C port to do this, but at the expense of battery capacity due to the physical space they take up. XTAR gets around this by including a linear charge controller in the positive end cap of the battery, but allows charging by feeding 5 volts into the same terminals used to discharge them. This makes DIY charging of their batteries easy, if one doesn’t want to spend extra for a dedicated charger. That said, the XTAR L8 charger offers multi-chemistry support, charging their Li-ion AA/AAAs as well as your existing Ni-MH cells. You don’t even need to group them by chemistry, as each charge bay is controlled independently – mix your cells to your heart’s content (just not in your device!). If you’ve already converted most of your USB charging gear to USB-C, you’re in luck – the L8 not only supports USB-C adapters with the correct 5.1k pulldown resistors, it supports requesting higher voltages (specifically, 9 volts) using Quick Charge 2.0 over the data pins for faster charge times (something I was unable to quantify since I don’t have enough test equipment on hand).

Battery Tests

For my discharge tests, I used my SkyRC MC3000 multi-chemistry battery analyzer, which was calibrated against my Keysight U1253B multimeter for both voltage and current measurements. Charging the batteries was performed using the L8 charger that XTAR provided me, as the MC3000 doesn’t support charging batteries with integrated charge regulation circuitry. Thermal performance was measured using an Inifiray P2 Pro thermal camera. The results of four cells were averaged together to get the data shown below.

I included tests of Ikea Ladda 2450mAh Ni-MH AA batteries as a means of comparing the performance of XTAR’s Li-ion technology against existing Ni-MH batteries, with the Ladda effectively being a rebrand of Panasonic’s Eneloop low-self-discharge Ni-MH battery.

AA Capacity vs. Load

Testing the battery capacities with varying load currents revealed a “humped” curve reminiscent of my PH5 review; that is, there is a “sweet spot” where the extracted capacity is highest, rather than a simple downward slope for batteries that don’t use an internal DC-DC converter.

Chart showing the XTAR 4150mWh Li-ion AA's capacity at different load currents.

Chart showing the XTAR 4150mWh Li-ion AA’s capacity at different load currents.

The AA battery showed a peak of 2353mAh at 500mA, which might sound like it’s just under the Ladda’s capacity, but things change once we compare the amount of energy that each battery delivers.

XTAR 4150mWh Li-ion AA vs. Ikea Ladda 2450mAh Ni-MH AA

Chart comparing extracted energy from XTAR 4150mWh Li-ion AA vs. Ikea Ladda 2450mAh Ni-MH AA.

Chart comparing extracted energy from XTAR 4150mWh Li-ion AA vs. Ikea Ladda 2450mAh Ni-MH AA.

For these low to moderate loads, the XTAR AA comes out on top, mainly helped by its higher output voltage. This trend only holds true for the load range that the XTAR battery supports, though. Once you need a battery that can support heavier loads, then a high-drain capable Ni-MH battery is your only real option (but given its capacity-vs-load characteristic, it should provide more consistent performance irrespective of load current).

Now, in terms of the above data… I did have to smooth some numbers due to missing energy values, thanks to a bad data collection setup for some earlier data runs; to be more precise, I multiplied the capacity values with a nominal voltage to get the outputted energy values. However, the data trend itself remains the same.

AAA Capacity vs. Load

The AAA batteries have a similar curve to the AAs, but peak at a lower discharge rate relative to its rated maximum discharge current. I didn’t have an equivalent AAA Ni-MH to test against.

Chart showing the XTAR 1200mWh AAA Li-ion battery's capacity versus load current.

Chart showing the XTAR 1200mWh AAA Li-ion battery’s capacity versus load current.

XTAR 1200mWh AAA Energy vs Load

Chart showing the XTAR 1200mWh AAA Li-ion battery’s energy versus load current.

The equivalent nominal voltage is different for the AAA as it decreases to its 1.1V low-battery threshold much later than the AA does. However, its peak energy percentage is also slightly higher than the AA’s but both are in the mid-80% range.

Thermal Performance

Thermal capture of the XTAR 4150mWh AA Li-ion battery at maximum load.

Thermal capture of the XTAR 4150mWh AA Li-ion battery at maximum load.

One potential concern I have with the batteries is just how hot the regulator circuitry at the positive end gets when under heavy loads. While the AA battery is rated for 2 amps of continuous discharge current, the positive end of the battery reached upwards of 80 or 90 degrees Celsius, hot enough to distort the plastic label from the sustained heat. This ultimately isn’t unique to XTAR’s offerings (the Kentli PH5 I previously tested ran into the same issues at high loads), but is still something to be aware of when using these batteries in high-drain devices, especially ones that place a constant load on the battery. The AAAs aren’t quite as affected but still reached temperatures of almost 60 degrees Celsius at maximum rated load.

Thermal capture of XTAR L8 while charging four Ikea Ladda 2450mAh Ni-MH AAs, and four XTAR 4.15Wh Li-ion AAs.

Thermal capture of XTAR L8 while charging four Ikea Ladda 2450mAh Ni-MH AAs, and four XTAR 4.15Wh Li-ion AAs. Note the heat generated at the positive terminal.

In terms of charging, the thermal issue remains but is much smaller. Heating of the positive end circuitry is largely unavoidable due to the use of a linear charge controller (but can you really expect to fit a switched-mode charger in the end cap of an AA/AAA battery?), with peak temperatures just under 50 degrees Celsius. This isn’t terribly hot compared to the peak temperature of a Ni-MH battery near the end of its charge cycle, which in the above image was about 40 degrees Celsius at the time of capture.

Charger Test (Ni-MH Charging)

I was curious as to how the L8 handles Ni-MH charging, so I captured the voltage and currents going into an Ikea Ladda 2450mAh cell with some jerry-rigged AA battery adapters and an AVHzY CT-3 USB meter.

Chart showing the voltage/current of the XTAR L8 while charging an AA Ni-MH cell.

Chart showing the voltage/current of the XTAR L8 while charging an AA Ni-MH cell.

The L8 charges at about 480mA but takes a small pause every 2 seconds to sample the cell’s voltage. Although I can’t say for certain, a zoomed-out look at the test data suggests that the L8 is uses the -dV/dt (voltage sag over time) method to determine when the cell is fully charged.

Conclusion

Overall, I’m quite satisfied with the batteries and charger. While the idea of sticking DC-DC converters inside a small battery case comes with limitations, it can still offer performance benefits for many applications.

Battery Pros

  • Higher output voltage than Ni-MH
  • Higher energy density than Ni-MH (within specified current range)
  • Low-voltage feature drops the output from 1.5 to 1.1 volts when battery runs low
  • Integrated charge circuitry allows batteries to charge directly from 5 volt power (DIY charging is easy)
  • Lack of USB charge port means no space lost to a USB port (therefore, more battery capacity)

Battery Cons

  • Integrated DC-DC converter limits efficiency
  • Heat generation at high loads due to DC-DC converter when discharging, and linear charge regulator when charging
  • Lower maximum discharge current compared to Ni-MH

PPS For All: Directly charging lithium-ion batteries with a USB-C PD tester

TL;DR – USB-C with PPS (Programmable Power Supply) technology is here, it’s cool, and now it’s usable on more than just the newest smartphones – it works on almost any Li-ion battery with the right USB-C tester. Check out the GitHub repo – it’s open-source!

As seen on Hackaday!

DISCLAIMER: Lithium-ion batteries can be dangerous if mishandled or abused! While much testing and development has resulted in a fairly stable implementation, this application is still an “off-label” use of a USB PD charger and USB-C tester, and therefore there is a risk of property damage, personal injury, or other unforeseen consequences if something goes wrong (and I will NOT be held responsible for that!).

Introduction

The USB PD (Power Delivery) standard has revolutionized how we charge our everyday electronic devices. While many new devices (such as smartphones) emphasize “fast charge” capability, it has required changes to both the device itself, as well as the adapters that power them.

Because power losses in the charging cable (or any other resistance) is directly related to the amount of current flowing through it, one can get more power for the same amount of current by increasing the voltage (this is how the AC power transmission lines that you see on the street and countryside work as well). The USB PD standard allows a device to request the adapter to increase its output voltage from 5 volts to a higher level, such as 9, 15, or 20 (and sometimes 12) volts.

An addition in the third version of the USB PD standard added optional PPS (Programmable Power Supply) support for the power adapter, which allows an adapter to output a wide range of voltages, rather than a fixed “menu” of 5, 9, 15, 20 (and sometimes 12) volts.

What is USB-C PPS charging?

PPS charging is a relatively new variation to the existing PD charging scheme. It allows the device being charged to actively communicate with the adapter and request a precise voltage (and current) level, increasing efficiency since DC-DC conversion efficiency drops when the difference in voltage between the input (the adapter) and output (the battery) is larger. With this bidirectional communication, it allows the adapter to share some of the regulation workload, and therefore move some of the heat-generating power conversion to the adapter, allowing the device’s battery to charge at a cooler temperature which improves its lifespan.

Direct Battery Charging

One step past normal PPS charging is direct charging, which completely offloads the power management to the adapter; the host device controls the charge process purely via software commands to the adapter. This is analogous to the DC fast charging method used in electric vehicles (EVs), which also perform all power regulation outside of the vehicle and its internal charge circuitry. Because the device no longer needs to perform its own DC-DC conversion, this skips a step in the power conversion “chain”, increasing efficiency and reducing the amount of heat dissipated in the host device (you can’t lose power on a conversion step if you never perform that step in the first place!). With this reduction in internally-generated heat, the battery can be charged at even faster rates than it could with previous charging schemes.

One barrier to the widespread adoption of direct charging is that it requires the device to explicitly support it, as it requires significant changes to how the “power path” is designed internally. It also requires the adapter to support the voltage and current levels required by the host.

Diagrams comparing normal versus direct charging schemes.

Diagrams comparing normal versus direct charging schemes. (click here for full-size image)

Thankfully, on the adapter side, PPS support is becoming more and more common, even though most devices on the market (at least at the time of writing) don’t support it. However, because that potential is already present, perhaps there’s a way for the electronics hobbyist to take advantage of direct charging for their own batteries…

Shizuku Platform and its Lua API

The Shizuku USB multimeter by YK-Lab, which is available in a few rebadged forms under names like YK-Lab YK001, AVHzY CT-3, Power-Z KT002, or ATORCH UT18, is a very useful USB charger testing device. It features USB-A and USB-C ports; can measure voltage, current, power; can calculate passed charge (mAh) and energy (mWh) in real time; but unlike most USB testers on the market, it is user-programmable in Lua, a lightweight programming/scripting language.

The Lua API on the tester provides a large amount of extensibility beyond the original tester’s design, and in my case I’m using its ability to “trigger” non-standard voltages from fast-charge capable power adapters as well as its colour LCD screen to act as a highly flexible direct charger – an intermediate between a USB-C PD PPS adapter and an arbitrary (Li-ion) rechargeable battery.

Introducing: DingoCharge!

The idea behind making a battery charging script came about when I looked at using bench-top adjustable power supplies to charge batteries. Since the Shizuku tester (in my case, it was the AVHzy CT-3 variant) allows me to use the PPS protocol to finely adjust the adapter’s output voltage, I tried manually varying the voltage to increase or decrease the current flowing into a battery – and it worked!

That said, constantly checking the battery’s current and voltage levels just to charge a battery gets pretty tiring, and since the Shizuku is Lua-programmable… why not make a script that automates all of this for me? Thus began a programming journey that’s been ongoing for over a year, and I’ve still got ideas to add even more functionality (as long as I don’t crash the tester by running out of memory… don’t ask me how I know).

Charge Regulation Algorithm

All lithium-ion batteries (including less-common ones like lithium-iron phosphate (LiFePO4) and lithium titanate) use what’s known as CC-CV charging; this stands for constant-voltage/constant-current. A fixed amount of current is fed into the battery until its voltage reaches a certain threshold, then the voltage is held at a fixed value until the current going into the battery drops below another, lower, threshold. Once this is reached, the current is turned off entirely and the charge process is complete.

Although the PPS specification allows a device to set a maximum current level, my own testing revealed that there was too much variation amongst all my different adapters that I could not rely on the hardware to perform the constant-current regulation with enough precision for my liking, and the voltage drop across the USB-C cable resulted in the battery’s charge current tapering off too early as the voltage at the adapter reached its programmed constant-voltage level before the battery’s own voltage had a chance to do so as well. Instead, my charge algorithm increases the requested USB PD charge voltage above the battery’s own voltage until the desired current level is within a certain deadband range.

Once the target constant-voltage level is reached, the charge algorithm switches to constant-voltage regulation, maintaining a preset voltage until the current being drawn by the battery falls below the termination threshold.

If a battery was previously overdischarged, it requires a slower “precharge” current to bring the battery’s voltage up to a level that is safe for its regular charge current.

Charge Safety Tests

Over time, I added more safety checks to ensure that the battery’s state was maintained within a safe margin for voltage, current, temperature, and also time. If a safety violation was detected during charging, the charging algorithm would automatically set its charge current to zero, effectively terminating the charge process. Additionally, if the charge process was finished but a small current flowing into the battery resulted in the battery’s voltage getting too high, the PD request voltage gets adjusted downwards to prevent an overvoltage condition from occurring.

Downstream Resistance Compensation

I also added the ability to compensate for high-resistance connections to the battery. This works by using Ohm’s Law (voltage = current * resistance) to boost the voltage thresholds in proportion to the amount of current flowing into the battery, as determined by a configured downstream (tester-to-battery) resistance. This is usually considered an advanced feature for a charging system, but since all of the charging is handled in software, it is relatively trivial to allow for compensating for lossy cabling and connectors.

Charging Test

As a real-world demonstration of the DingoCharge software, I created a test setup that charged a 600mAh/7.4V nominal battery pack (a rechargeable 9V alternative that’s built from disposable vape batteries – stay tuned for that blog post!) at a 1C (600mA) rate at 8.4V (4.2V per cell) until the current tapered off to C/10 (30mA); note that the pack I was charging was built with high-drain cells that can handle higher currents than normal, and most commercial cells are best charged at a C/5 to C/2 rate. I used a Samsung EP-TA800 USB-C adapter, capable of a maximum of 25W at full power (11V at 2.25A).

Demonstration of DingoCharge charging a 9V Li-ion replacement, using a Samsung 25W USB-C PD adapter.

Demonstration of DingoCharge charging a 9V Li-ion replacement, using a Samsung 25W USB-C PD adapter. (click here for full-size image)

Block diagram describing the DingoCharge hardware setup.

Block diagram describing the DingoCharge hardware setup. All power conversion (and associated power conversion losses) occur only in the power source, with the tester simply issuing commands to control the power going into the battery. (click here for full-size image)

Voltage/current plot of DingoCharge charging a battery at 600mA and 8.4 volts, using a Samsung EP-TA800 USB-C PD adapter.

Voltage/current plot of DingoCharge charging a battery at 600mA and 8.4 volts, using a Samsung EP-TA800 USB-C PD adapter. (click here for full-size image)

The classic CC-CV charge profile is visible when the charging current and voltage is graphed over time. The stepped nature of the current is a consequence of the PPS voltage being limited to 20mV granularity, causing jumps in current draw as each step occurs. The voltage is increased or decreased when the current or voltage being sent to the battery falls out of a certain range (in this case, 600mA and a +/-25mA deadband during constant-current charging, and 8.4V +/- 10mV during constant-voltage charging).

One contribution to the relative flatness of the constant-voltage phase is that the charging algorithm is essentially performing four-wire (also known as Kelvin) sensing from the adapter to the tester, inherently compensating for voltage drop across the USB-C cable. This is also why the current flutters a bit as it tapers off, as the voltage at the battery begins to rise above the deadband, resulting in a small amount of oscillation as the algorithm tries to maintain 4.2 +/- 0.01 volts.

Limitations

Nothing in this world is perfect, and neither is my charger implementation. In fact, trying to shoehorn a battery charger into what’s effectively a multimeter and a “wall wart” required a lot of compromises to be made.

No Power Switching

Charge termination is a bit tricky, as most implementations will just electrically disconnect the battery. However, with the tester, there is no power switching available that can be controlled through software. This is mitigated by setting the constant-current algorithm to 0 amps +/- 10 milliamps, resulting in minimal charge/discharge current as the battery voltage drops while it relaxes from a fully-charged state.

One Name, Many Variations

Another limitation is that the PPS protocol allows adapters to not necessarily support the full voltage range of 3.3 to 21 volts. Instead, there are options to support up to 5.9, 11, 16, and/or 21 volts, and at current level up to 5 amps. The large disparity of supported voltages and currents means that the DingoCharge script needs to check the programmed charge parameters against what the adapter supports; many PPS adapters only support up to 11 volts, so 3S (3 cells in series) and higher cell configurations will not work (and an error message will be displayed if that is the case).

My (Electro)chemical Romance Recharge

I designed DingoCharge only for use with lithium-ion type battery chemistries, but have been experimenting with charging other rechargeable batteries, such as lead-acid and nickel-metal hydride/Ni-MH. There has been promising results with both chemistries, but each one is not fully supported as I have not implemented proper 3-stage charging for lead-acid batteries; Ni-MH charging only works by using a low current (C/10 typical) for a fixed period of time via DingoCharge’s time limit feature, or an external temperature sensor alongside the overtemperature protection feature to stop the charge process (a very crude delta-T/change-in-temperature algorithm). Thankfully, the software-based approach of DingoCharge means I can add this functionality in an official capacity with further research and development work… as long as I get around to it 😛 .

Lua Lunacy?

Additionally, this was my first real foray into Lua programming, so I’m pretty certain I’ve made some poor stylistic and other programming choices along the way. For all I know, it could have inherited some significant syntactic defects from my other programming (language) attempts that make it an “awful” program – but hey, it’s an open-source project so if you have some pointers, feel free to help contribute on GitHub (link is in the Downloads section below)!

Conclusion

The USB PD protocol, and its adjustable PPS functionality that was introduced in the PD 3.0 specification, provides a lot of potential use for directly charging batteries since it skips the usual conversion step in a device. However, this type of charging technology was largely untapped by many devices, with only a few smartphones (as of the time of writing) supporting it.

The scriptability of some USB-C testers like the AVHzY CT-3 or Power-Z KT002 allows for a script to handle all of the intricacies of battery charging, while providing an easy-to-use yet highly flexible interface. Thanks to the DingoCharge script, any USB PD PPS adapter and supported USB tester can be used as a universal battery charger.

Downloads

The DingoCharge script can be found on my GitHub profile (https://github.com/ginbot86/DingoCharge-Shizuku), and is open-source under the MIT License. If you have a suitable USB PD PPS adapter and USB-C tester, I’d love to hear if/how well DingoCharge works for your batteries!

Review and analysis of XTAR 3600 mAh 18650 Li-Ion protected battery

TL;DR – Yes, the XTAR 3600 mAh protected 18650 battery meets its rated capacity! Just make sure your device can drain down to 2.5 volts.

The 18650 lithium-ion battery, named after its size (1.8 cm diameter and 6.50 cm length), has seen continuous improvements in capacity over the years. Nowadays it’s easy to get capacities in excess of 3000 mAh, with the highest capacity cells reaching and even exceeding 3500 mAh.

The XTAR 3600mAh protected 18650 lithium-ion battery, pictured with its original box.

The XTAR 3600 mAh protected 18650 lithium-ion battery, pictured with its original box.

Earlier this year, XTAR, a Chinese company specializing in batteries and battery accessories, announced the newest and highest-capacity addition to their protected 18650 lineup, boasting an impressive 3600 mAh capacity and aimed towards medium-drain applications like power banks and LED flashlights (sorry vapers, this one’s not for you!). After submitting my name for consideration, I was one of a few people selected to receive some samples for review; considering how much I’ve blogged about lithium-ion batteries on here, it only makes sense to talk even more about them!

FULL DISCLOSURE: XTAR provided these batteries to me at no charge for an independent review. They had no editorial control over this review, I have not been compensated monetarily, and all opinions expressed in this review are my own.

Introduction

XTAR’s new 3600 mAh protected 18650 comes in a discreet box, holding nothing more than the battery itself. Like all protected 18650s, the protection comes in the form of a small PCB (printed circuit board) that is stacked on the negative end of the bare 18650 cell, with a metal strap running up the cell’s body to the positive terminal, where a small “button top” is attached to improve electrical connectivity for spring-loaded battery holders.

Positive and negative terminals of the XTAR 3600mAh protected 18650 battery.

Positive and negative terminals of the XTAR 3600 mAh protected 18650 battery. Note the added length due to the button top on the left, and the protection circuit and protective plate on the right.

I was able to request an official datasheet for the battery, which I have included at the end of my blog post. My main goal with this review is to test the batteries from an objective perspective, using dedicated test equipment rather than in-application testing in devices like flashlights. If I do decide to perform such tests, I’ll add a second part to my review (stay tuned!).

Datasheet specifications

Parameter Value
Cell manufacturer (Unspecified)
Nominal voltage 3.6 V
Nominal capacity 3600 mAh
Minimum capacity 3500 mAh
Discharge cutoff voltage 2.5 V
Cycle life @ 80% capacity At least 300 times
(0.5C charge to 4.2 V, 0.03C taper; 0.5C discharge to 2.5 V)
Size 18.1~18.7 mm diameter
68.3~69.3 mm length
Weight ≤50 g
Internal AC resistance ≤45 mΩ
Standard charge CC 720 mA
CV 4.2 V
Taper 50 mA
Fast charge CC 2500 mA (0.7C)
CV 4.2 V
Taper 36 mA (0.01C)
Standard charge voltage 4.2 V
Standard discharge 720 mA CC to 2.5 V
Continuous discharge current >8.5 A
Overvoltage protection Trip 4.25~4.35 V
Recover 4.0~4.2 V
Undervoltage protection Trip 2.4~2.5 V
Recover 2.8~3.0 V
Overcurrent protection Trip 11~13 A
Working temperature Charging: 0~45 °C
Discharging -20~60 °C

Test 1: EBL TC-X Pro battery analyzer

Initial testing of the batteries was tested using my EBL TC-X Pro 4-bay battery analyzer. The test procedure for the batteries was performed as follows:

  1. Record out-of-box/initial voltage before charging
  2. Run automatic capacity test with programmed 1500 mA charge current to 4.2 V, and fixed 500 mA discharge to 2.75 V (charge -> discharge -> charge); record discharge capacity and reported internal resistance
  3. Run manual discharge test with fixed 500 mA current to 2.75 V; record discharge capacity and reported internal resistance
  4. Run manual charge with 1500 mA charge current to 3.65V/LiFePO4 mode (moderate voltage is best for long-term storage); record charge capacity
Parameter (charge current = 1.5A) Cell 1 (bay 1) Cell 2 (bay 2)
Initial voltage (V) 3.65 3.55
Capacity run 1 (mAh @ 2.75 V end of discharge) 3349 3369
Capacity run 2 (mAh @ 2.75 V end of discharge) 3334 3386
Internal resistance run 1 (mΩ) 54.9 46.9
Internal resistance run 2 (mΩ) 53.4 45.1
Storage capacity (mAh charged to 3.65 V) 1402 1494

The capacity numbers seemed a bit low to me, even for an incomplete discharge to 2.75 volts instead of 2.5 volts. I decided to continue testing with a more accurate (and calibratable) battery fuel gauge board, revealing the true capacity of this battery… and it’s as good as the manufacturer promised!

Test 2: Texas Instruments bq78z100 fuel gauge

After realizing that my dedicated battery analyzer wasn’t quite as accurate as I wanted, I decided to use a battery fuel gauge board that I had more confidence in. I had previously built a board based on the Texas Instruments bq78z100, a dedicated battery management system (BMS) on a chip, aimed at 1S and 2S battery packs. This allowed me to calibrate the voltage and current measurements against my Agilent/Keysight U1253B multimeter and therefore get the most accurate results, as I can also program the bq78z100’s autonomous protection features to provide precise control over the discharge cutoff voltage during testing.

Example of the bq78z100-based fuel gauge board being connected to the XTAR 3600mAh protected 18650 battery. (note: actual setup is different than as pictured)

XTAR 3600 mAh protected 18650 battery connected to the bq78z100-based fuel gauge board. (note: actual setup is different than as pictured)

Using this circuit, I was able to get multiple measurements of the battery’s capacity with the help of a Texas Instruments GDK (Gauge Development Kit) as a charger and adjustable load for some of the capacity tests; and an Arachnid Labs re:load 2 adjustable constant-current load, with some additional forced-air cooling for the higher discharge rates.

I suspect that if I had a more, erm, “professional” setup, I could extract even more capacity from the battery, as additional resistance between the battery and the fuel gauge board will cause a voltage drop and subsequent loss in measured capacity.

Available capacity vs. end-of-discharge voltage

This is one of the most interesting test results, in my opinion. Many 1S/”single-cell” devices can’t take full advantage of modern NMC (nickel-manganese-cobalt) cells whose end-of-discharge voltage is below 3 volts, and the following chart helps quantify how much capacity can be extracted if one stops earlier than that. One advantage of reducing the depth of discharge, however, is that it can extend the battery’s cycle life and reduce the amount of capacity loss it experiences with age. As long as you discharge all the way to 2.5 volts and at a modest rate, the XTAR 3600 mAh battery achieves its rated capacity, and then some!

Chart plotting the XTAR 3600mAh protected 18650's voltage, compared to discharge capacity and discharge rate.

XTAR 3600 mAh protected 18650’s voltage/capacity curves at various discharge rates. (click here for full-size chart)

Discharge Rate Capacity/DoD@ 3.3V
(Rel/Abs)
Capacity/DoD @ 3.0V
(Rel/Abs)
Capacity/DoD @ 2.75V
(Rel/Abs)
Capacity/DoD @ 2.5V
(Rel/Abs)
C/10
(350 mA)
2616 mAh
72.4%/72.4%
3357 mAh
92.9%/92.9%
3539 mAh
97.8%/97.8%
3613 mAh
100%/100%
C/5
(720 mA)
2555 mAh
(N/A)/70.7%
3250 mAh
(N/A)/90.0%
(No Data) (No Data)
C/2
(1800 mA)
2310 mAh
67.2%/64.0%
3076 mAh
89.4%/85.1%
3338 mAh
97.1%/92.3%
3438 mAh
100%/95.2%
1C
(3600 mA)
1995 mAh
57.2%/55.2%
2874 mAh
82.4%/79.5%
3330 mAh
95.5%/92.2%
3486 mAh
100%/96.5%

Note that “relative” and “absolute” percentages correspond to the 2.5 volt discharge values for each row and the C/10 rate, respectively. The curve for the C/5 discharge rate ends early, as that data was collected with my Texas Instruments GDK (Gauge Development Kit), which has a hardcoded discharge cutoff at 2.9 volts. One oddity of the 1C curve is how it actually gets slightly more capacity than the C/2 rate; I suspect this is because the internal resistance of the battery was decreasing due to cell heating, allowing the lithium ions to travel across the cell’s separator more easily. Additionally, the capacity under-reporting issue I was having with the EBL tester is more visible in this chart, since a rough extrapolation would bring the discharge curve at 500 mA around 3550 mAh, which is a fair amount higher than the measured ~3340 mAh. If I have the time to recollect some data, I’ll add it to the chart.

Thermal performance

I don’t have the equipment to test beyond a 1C discharge rate, but even at a C/2 discharge rate I noticed significant heating of the battery; nothing disconcerting but still noteworthy. At 1C, the temperature rose to just over 40 degrees Celsius (104 degrees Fahrenheit) by the end of the discharge cycle – definitely warm to the touch but not burning hot. However, I imagine that a discharge rate at 2C or even higher will result in battery temperatures exceeding 50 degrees Celsius (122 degrees Fahrenheit), hot enough to be uncomfortable to hold. Note that lithium-ion batteries should not be charged if they are warmer than 45 degrees Celsius (113 degrees Fahrenheit).

Chart plotting the XTAR 3600mAh protected 18650's temperature, compared to discharge capacity and discharge rate.

XTAR 3600 mAh protected 18650’s temperature curves at various discharge rates. (click here for full-size chart)

Chemistry analysis

After running the data taken at a C/10 discharge rate through TI’s online tool, GPCCHEM, I was able to get two chemistry IDs that would allow me to get an accurate model of the cells for use in their Impedance Track line of fuel gauges.

Chemistry ID (hex) Chemistry Description Cell match Max DoD error (%) Max Ra deviation ratio
5267 LiMn2O4 (Co,Ni)/carbon, 4.2 V Bak: N18650CP (3350 mAh) 2.3 0.27
5634 LiMn2O4 (Co,Ni)/carbon, 4.2 V NanoGraf: INR-18650-M38A (3800 mAh) 2.72 0.61

Don’t pay too much attention to the details; they are provided for informational purposes only and mainly of use for those that want to use these batteries with TI’s fuel gauge chips. The specific models listed are not a guarantee that these batteries actually are that cell model, but it does confirm that our data is otherwise trustworthy; both listed models are high-capacity cells and use a chemistry system containing nickel, manganese, and cobalt (NMC for short), and such chemistries tend to have a relatively high capacity at the expense of lower terminal voltage (3.6 V nominal, 2.5 V at end of discharge; versus the typical 3.7 V nominal and 3.0 V end of discharge).

Conclusion

After my testing, I can confidently say that XTAR’s 3600 mAh 18650 really does achieve its rated capacity. As long as your target device is capable of discharging to 2.5 volts and at a modest rate, it will be able to get the most out of this battery.

If you want to purchase this battery, you can do so from their online store: https://xtardirect.com/products/18650-3600mah-battery?VariantsId=10393

At the time of writing, XTAR is selling this battery at $11.90 USD for a single battery, or $23.80 USD for a two-pack with carrying case.

Downloads

The datasheet for the battery can be found here: https://www.dropbox.com/s/wibdm2ty6zfa7xo/XTAR%2018650%203600mAh%20Specification.pdf?dl=1

Skin-Deep Authenticity: Tearing down a “genuine fake” Samsung Galaxy S II battery

When you have the same smartphone for almost 3 years, it’s likely that your original battery’s not going to last as long as the service contract. And as long as you’re not an iPhone user you will probably look into a replacement or spare battery.

coverMy first replacement cell was a 2-pack of “1800 mAh” batteries for $5. These had 66% of the stated capacity and TI’s Impedance Track gauge said that the DC internal resistance was about 250 milliOhms. That’s… pretty terrible. Those two cells quickly led their end in a battery recycling bin. My next two were “genuine” cells from eBay. They cost about $12 each and had rather authentic-looking labels on them too. Their performance was pretty good, but one of them became all bloated so I decided I’d take a look at the cell that’s inside. I peeled off the label, and the truth comes out…

2014-01-01 04.53.39This battery was an outright lie in terms of capacity! 1350 mAh is about 80% of the 1650 mAh capacity that was written on the outer label. The cell’s manufacturer is unknown, but the battery markings read “BMW-524655AR 1350mAh 2012.09.03.1110”. Wait, look at that manufacturer date. Something’s fishy…

2014-01-01 04.53.54The outer label states a manufacture date of July 20, 2012. The internal cell states one of September 3, 2012. Unless this battery was manufactured in a time-bending factory, then these batteries certainly aren’t genuine.

Next up was the protection circuit. The “genuine fake” battery uses a DW01 protection IC and uses a generic 8205A dual NFET for swiching. And there wasn’t even a thermistor; the PCB uses a 1.5k ohm resistor to simulate one. A genuine board uses a single SMD package that integrates the FETs and the protection IC.

Below is a comparison of the protection board of a fake battery and a “genuine fake” one. At least the “genuine fake” uses the same black appearance of the original.

The “genuine fake” battery, after only 2 months of usage (not even 20 charge cycles’ worth), became so swollen that I can’t keep the back cover on. Running this battery through a bq27425-G2A battery gas gauge determined that the real capacity of the battery is a paltry 944 mAh, with an average internal resistance of 187 milliOhms. Absolutely pathetic.

samsung galaxy s ii replacement battery old ra graphGoes to show you get what you pay for. But some things may be more deceiving than others…

Mini-Ramble: I’m such an icon artist!

After working so much with these battery chips, I thought I should spice up the Windows file icon for the .gg files that clutter my documents folder.

I’m not a person for glossy icons, but I’m also not a fan of the super-flat colour scheme that the Windows Metro UI uses. I prefer the good old style of Windows 9x-esque icons (hey, it’s what I grew up on! 🙂 ), albeit with a more… contemporary colour scheme. Keep it simple!

Windows .ico file download: https://www.dropbox.com/s/u7kjb3og7ecvpsj/gas%20gauge%20file.ico

You can use Nirsoft’s FileTypesMan to add an icon in Windows. Personally, I configured it so that .gg files open up in Notepad++ for manual editing.