Brain dump relating to data captured from Makita XGT battery tester - example capture here: Example Capture
Example program using this information available here:
https://github.com/twaymouth/XGT-Tester
The data within this capture represents this screenshot: Tester Screenshot
Bulk of the commands and responses are comprised of 8 bytes each, 16 bytes total for a command and response pair.
Before each command the testers microcontroller appears to send an unusual byte as shown below, a start bit is sent, 8 x 0 bits are sent and the line is then asserted low for 15ms before the command is issued resulting in an intentional parity error (all other communication is 8E1).
Attempting to reproduce this behaviour by sending byte 0x0 resulted in the battery ignoring further messages for a period of around 100ms? (sending 0x0 with even parity results in a parity bit of 1 which differs from the example below).
Not sure how this is being implemented or why (possibly it is to ensure the battery is awake?) but it doesn't seem to be necessary as long as prior to the first command being sent byte 0x0 is sent, a 100ms delay is allowed and then further commands issued.
The 1st byte of each group of 8 is always 0xCC and the 8th byte is always 0x33. The 2nd byte is a CRC byte which is calculated by summing all bytes in the group except the CRC byte and then taking modulo 256.
e.g. CRC of CC BF C0 00 00 00 00 33 is BF calculated as follows CC + C0 + 00 + 00 + 00 + 00 + 33 = 1BF (447 Decimal) 1BF % 0x100 = 0xBF
Bytes 3 and 4 appear to represent the command, whatever these bytes are set to in the command group is echoed in the response group. Bytes 5 and 6 are data, in the command group these appear to contain the parameter of the command specified in bytes 3 / 4 and in the response group these contain the response data.
Byte 7 appears to always be 0x00 and byte 8 is 0x33 as above.
During the testing process 35 total messages are sent to the battery however as below not all appear to be used.
The first 2 messages are in the format described here. github.com/Malvineous/makita-xgt-serial
1st message is the battery model. - A5 A5 00 1A 50 2B 4D 4C 00 CB 13 07 00 06 00 03 00 01 13 0B 02 3B FF FF FF FF FF FF FF FF FF FF / A5 A5 0 12 90 1F 4D 4C 0 CB 33 7 0 0E 0 1 0 0 13 0B 20 46 30 35 30 34 4C 42 4 49 FF FF = BL4050F when decoded as described in github page above.
2nd message in longer format and empty during my testing.
3rd message in shorter format described above and empty.
4th message again in longer format and empty.
Suspect the messages with empty responses above are related to battery / tool lock / timer / custom ownership messages and tool fault data, following this are 31 messages in shorter format.
The batteries MCU operates in big endian mode and individual bytes are MSB first so bit order and message endianness need to be reordered as appropriate in order to make sense of the data. When sending data it needs to be sent in correct bit order and endianness for battery to respond.
Example commands (in blue) and responses below beginning at message 5. The bytes that make up these messages have been re ordered so they correctly represent what was sent in MSB first bit order however endianness has not been changed, in example calculations below I convert endianness of specific 16 bit / 2 byte words as required to get correct values otherwise just leave it as is. Confused? so am I.
This data was validated by programming a microcontroller to emulate a battery, I could then change individual bytes at will and observe how they impacted what was displayed on the tester and confirm the changes matched my perceived understanding of the testers operation.
CC 13 C0 00 54 00 00 33 / CC E9 C0 00 2A 00 00 33 – Byte 5 & 6 are charge count 002A = 42 charge cycles.
CC E4 DD 08 00 00 00 33 / CC 21 DD 08 24 19 00 33 - Byte 6 is pack construction i.e. what capacity cells pack is made of 19 in decimal = 2.5ah cells this is important for degradation calculation. Byte 5 does not change between batteries, potentially this refers to nominal cell or pack voltage (i.e.0x24 = 36v or 3.6v in decimal depending how you interpret it?)
CC E6 DD 0A 00 00 00 33 / CC F2 DD 0A 02 0A 00 33 Byte 5 appears to be number of strings in parallel i.e. in this example pack is a 5Ah pack i.e. 2 strings of 10 * 2.5ah cells (cell size from command above). This is important for the degradation calculation, byte 6 does not appear to change, possibly it represents the number of cells per string (i.e. 0x0A = 10 in decimal)
CC 23 C0 00 64 00 00 33 / CC 54 C0 00 85 10 00 33 - Byte 5 & 6 are believed to be calculated pack capacity, i.e. 1085 = 4.2Ah capacity available. This is used in conjunction with 2 above messages to calculate degradation score i.e. 4200 / 5000 = 84 % battery health.
CC 29 C0 00 6A 00 00 33 / CC C8 C0 00 FD 0C 00 33 // unknown – changes between batteries but does not appear to impact anything?
CC E0 DD 04 00 00 00 33 / CC E4 DD 04 02 02 00 33 // unknown – changes between batteries but does not appear to impact anything?
CC C1 C0 02 00 00 00 33 / CC C1 C0 02 00 00 00 33 // unknown – does not change between batteries / appears to be empty?
CC C8 C0 01 08 00 00 33 / CC 80 C0 01 5E 62 00 33 // Byte 5 & 6 represent battery charge percent when divided by 255 i.e. 625E / FF = 0x62 or 98% in decimal
CC DC C0 03 1A 00 00 33 / CC 4B C0 03 7E 0B 00 33 Byte 5 & 6 represent temperature sensor 1 reading. Temperature calculated as follows. The lowest temperature the tester can display is -30 degrees C, this occurs when bytes 5/6 are set to 97F or 2431 in decimal. To calculate temperature take value from battery response i.e. 0B7E / 2942 and subtract 2431 from this value and divide by 10 giving a 51 degree offset from -30 adding 51 to -30 gives the current temperature which in this example is 21 degrees C
CC DE C0 03 1C 00 00 33 CC 49 C0 03 7C 0B 00 33 Byte 5 & 6 represent temperature sensor 2 reading. - 20 degrees C as per calc above.
CC C2 C0 03 00 00 00 33 / CC C6 C0 03 64 A0 00 33 Byte 5 & 6 represent pack voltage in mV A064 = 41060 in mV in decimal = 41V pack voltage.
CC C4 C0 03 02 00 00 33 / CC DC C0 03 0A 10 00 33 - Byte 5 & 6 represent cell voltage in mV 100A = 4106mV in decimal. For each subsequent cell command byte 5 (0x02) increases by 2 i.e. cell 2 below is 0x04 through to cell 10 0x14
CC C6 C0 03 04 00 00 33 / CC DC C0 03 0A 10 00 33 - cell voltage.
CC DA C0 03 08 10 00 33 - cell voltage.
CC DD C0 03 0B 10 00 33 - cell voltage.
CC DC C0 03 0A 10 00 33 - cell voltage.
CC DC C0 03 0A 10 00 33 - cell voltage.
CC DA C0 03 08 10 00 33 - cell voltage.
CC DC C0 03 0A 10 00 33 - cell voltage.
CC DD C0 03 0B 10 00 33 - cell voltage.
CC D6 C0 03 14 00 00 33 CC / DF C0 03 0D 10 00 33 - cell voltage.
CC E6 C0 00 24 03 00 33 - temperature histogram – chart contains 6 bars byte 5 is left most bar, byte 6 is bar 2 – byte value determines bar height – seems to be non linear in nature, needs more investigation.
CC C1 C0 00 02 00 00 33 - temperature histogram - chart contains 6 bars byte 5 is bar 3, byte 6 is bar 4.
CC BF C0 00 00 00 00 33 - temperature histogram - chart contains 6 bars byte 5 is bar 5, byte 6 is right most bar - bar 6.
CC DA C0 00 00 1B 00 33 - current histogram – same as temperature.
CC CD C0 00 0E 00 00 33 - current histogram.
CC BF C0 00 00 00 00 33 - current histogram.
CC BF C0 00 00 00 00 33 – failure messages / unused? - need example of faulty batteries to examine.
CC BF C0 00 00 00 00 33 – failure messages / unused?
CC BF C0 00 00 00 00 33 – failure messages / unused ?
CC BF C0 00 00 00 00 33 – failure messages / unused?