|Product Performed to Expectations:||10|
|Specifications were sufficient to design with:||10|
|Demo Software was of good quality:||10|
|Product was easy to use:||9|
|Support materials were available:||9|
|The price to performance ratio was good:||8|
|TotalScore:||56 / 60|
I applied for this roadtest as i have done a few projects with LiPoly batteries in the past and trying to get good data on their state of charge and overall health is usually a pain. I have used the MAX17043 before in a small 2/3 scale F1 steering wheel for one of my children before and it worked, but i'm always on the lookout for something better.
In this review i want to be able to:
1. Have a look at what the device can do
2. Compare its readings against a known working device
3. See what features might save time or enable it to be used in ways beyond the standard fuel gauge
4. Integrate it communications-wise with a micro controller
The MAX17260GEVKIT was supplied in three individual parts. There was a USB communications dongle, the actual development board itself and the cable to link the two.
When i first opened the packaging, i was perplexed why they would supply it this way. Why not just the dev board and a good set of register maps? Clearly the Maxim product people are much smarter than i am. Once you start using the board i can 150% see why they do it this way. The two boards were supplied in the usual anti static bags (which were themselves surrounded by cardboard boxes for shipping) which were promptly ripped open and probably left somewhere. The packaging was nothing to get excited about, but it doesn't need to be. Its a battery fuel gauge test board, not a luxury watch.
I started by connecting the two boards with the RJ11 cable supplied and plugging the communications adaptor board into the USB port of my computer. Then i remembered i would need software. A quick google search returned the link i needed but i did have to go and register on the Maxim portal to be able to download it. Thanks to the wonders of the interweb i had the link in about 5 minutes or so. Upon installing the software and running it with the boards connected i was greeted with a nice GUI that said i had no board connected. This was odd as i definitely had it connected and it looked like it knew there was a Maxim comms adapter board there. Then i remembered that this device is supposed to sit in the chain of power for a small battery powered device, so it would be ultimately powered by said battery. Finding a suitable lithium polymer cell and connecting it to the pads on the board was pretty straight forward. The pads themselves have no pins soldered to them which could potentially have made life easier. Ideally the board would have had the relatively universal JST connector on it for the battery as an option but no big deal.
The lithium polymer cell i ended up using was the one supplied with a Particle Electron and having this board around for the testing was invaluable as it provided a reference for battery readings. The Electron has a MAX17043 battery fuel gauge IC which is works quite well, but this provides the ideal comparison for the more feature rich laden cousin, the MAX17260. The MAX17260 is designed to go in between the battery and the powered equipment. On some pre-built devices this may prove to be more difficult than others to integrate for a hack job. Luckily the Electron has an exposed pin to be able to wire into where the battery connector is pinned without getting out the side cutters creatively. With the MAX17260 dev board wired into the chain it was time to try that software again......
As i should have expected, the software is great. When i mentioned earlier that the Maxim people are definitely smarter than i am, the software really shows why the boards are built the way they are. When the software is first opened it goes to a configuration section where you can select the battery chemistry, the capacity, cutoff voltage level etc. This chip can obviously be used in a large number of configurations and explains why the user manual is so big for 'just a fuel gauge'.
Once this configuration has been loaded into the chip, the software goes to what i would call the 'Main Page' which shows a whole bunch of the most important information as shown below:
This screen alone is a great example of why this board is so great. All the important information laid out in an easy to read format, perfect for when its 3AM and you are on your 3rd <insert favourite energy drink> trying to debug some code or optimise the power consumption of your portable device. Not only does the MAX17260 measure the voltage of the battery and estimate its remaining capacity, it reads the instantaneous and average current consumption of the battery powered device and the health in general of the battery. The current reading alone is such a useful feature, normally to really get a good idea of the current requires a bunch of wiring and inaccuracies with shunts etc. The MAX17260 board has a small 0.1 ohm shunt on board but the board does all the processing and all you have to do is read the text on screen.
This may seem really useful to people who have ever really tried to do battery powered devices, but it still has another trick up its sleeve: data logging.
If you leave the device connected to the board and the board plugged into your computer you can record and graph a whole bunch of different parameters. I found the current and average current the most useful personally. The data is also stored to a csv file that can be configured for later analysis. From this graph above you can see when the Electron is sitting idle, and the spikes of current consumption when it sends its periodic heartbeat back to the cloud servers on 3G. I played around with this for a while, comparing the reported State Of Charge (SOC) of the battery from the built-in MAX17043 and that from the MAX17260. While most of the readings were within 1-2% across the range from 100% down to 20%, below 20% it looks like the MAX17260 is more accurate thanks to its more detailed battery modelling and coulomb counting ability. For the types of applications i use batteries with, absolute accuracy is not really that important. The ability to report battery health and current draw IS incredibly useful as it now allows the system to limit certain activities based on the amount of current they might draw.
One important thing that the MAX17260 is claimed to be able to do is report back accurate capacity data even under load. Typical fuel gauges use the measured voltage across the cell to determine its SOC. The problem with this method is that under load, the cell voltage drops and therefore inaccuracies arise, reporting a lower SOC than actually is present. The MAX17260 combats this by using the measured current from/to the battery along with its 'Modelgauge m5' battery modelling to predict the Open Circuit Voltage (OCV) of the battery regardless of the load applied. This OCV is then used in the SOC calculation.
I ran the battery through some varying loads while connected and logging to check that even if the measured cell voltage varies a lot, the OCV only changes slowly as it should while the battery drains. A plot showing the percentage change of the Current, OCV and Cell voltage is shown below:
Here we can see that while the current is drawn from the battery (peak current was around 592mA), the measured cell voltage drops accordingly. This is where a normal fuel gauge starts to be problematic. On the OCV line though we see minimal change in the OCV which is good. It does have a slight downward overall trend which we would expect, but it does not vary anywhere near as much as the measured cell voltage.
A better illustration of this OCV adjustment is shown with only the OCV and the measured cell voltage over the same time period:
This constant recalculation of the OCV and then inputting this to the battery model means the device maintains the accuracy even under load. I tested this a number of times by loading up the battery for a while, then disconnecting the load to see if the OCV was close to the resultant measured cell voltage and it was withing 0.03V typically.
Using a more representative current draw from the battery, this time with the Electron running, we get an OCV vs Measured Cell voltage looking like this:
Again, a nice flat OCV showing the gradual flattening of the battery compared to the spurious measured cell voltage which is constantly affected by current draw.
Now that we have played computer fun and GUI's, the real test is can i get the thing to talk to a microcontroller properly. Normally this step involves lots of printing of data sheet pages and trying to make sure they stay in the correct order while estimating what a register might have in it for a sanity check. The GUI steps back in for the win........
The software has a whole section dedicated to the involved registers, showing you their address, the data in them (even in HEX) and their 'real' value. Again, i can't stress how incredibly useful this is when trying to get all the comms working. The screenshot above is only one of 6 different categories, another screenshot is attached showing almost all the available registers. To get the Electron to use its inbuilt I2C to talk to the MAX17260 really only required me to put pull up resistors on the SDA and SCL lines and use the Wire library to read the values out. One thing that was slightly annoying here was finding the device I2C address, its buried down in the user manual. ****SPOILER ALERT***** Its 0x6C for 8 bit addressing and 0x36 for 7 bit addressing (Wire library uses 7 bit addressing). To read the SOC from the MAX17260 with an Arduino or other device that uses the Wire library, the following code will bring it back in an integer percentage:
Wire.beginTransmission(0x36); // transmit to device
Wire.write(0x06); // sends starting byte address byte
Wire.endTransmission(); // stop transmitting
Wire.requestFrom(0x36, 2); // request 2 bytes from slave device
if (Wire.available() == 2)
x = Wire.read();
y = Wire.read();
MAX_SOC = y;
The first byte is actually the decimal places percentage (in units of 1/256th of a %), which in most portable devices isn't really required, simple integer is fine for accuracy. But its nice to know the inherent accuracy is there. From this point the rest of the readings were easy to do, just a matter of checking how the register is formatted (like the 1/256th of a % trick for the LSB) and applying it. Being able to just read the data in HEX and compare it to the GUI is such a time saver to ensure you have the first part going though.
I love this product, its easy to use, it does exactly what it claims to do and does it extremely well and will save me truckload of time in the future with some other battery powered projects i have in mind. It also promises to be quite a good analysis tool with the current readings enabling me to benchmark certain functions and their current consumption as well as optimise how these are deployed. I have a friend who works on CUBEsats which all have lithium batteries and try to minimise power consumption wherever possible, this could actually be really useful for something like that. The sheer amount of information the device generates about the battery means that i imagine this thing will be a real hit for connected device manufacturers. They will be able to easily analyse how their customers use their products and do predictive maintenance on devices in the field if required. The possibilities there are almost to big to fully comprehend from a customer service point of view.
One thing i would like to see is a small breakout board for the chip with the sense resistor on it. Ideally one that is around 10mmx10mm that can be easily integrated into DIY build projects etc. The device itself is so easy to use and compact that im sure many people will find it a great solution.
The kit is somewhat expensive (~$120 AUD) so if you aren't doing battery powered devices a lot it may be expensive. That said, the amount of time this thing will save even doing one battery powered device will more than pay for itself.
Easy to use
Incredibly feature rich
Useful as a dev tool and also as a measurement tool
No small parts to lose
Board well labelled
Could possibly do with a JST on board
A bit expensive if its not something you will use often
I'd like to thank element14 for the opportunity to do this roadtest as it has been really interesting. Now i just need to source a bare MAX17260 and whip up a breakout board....