add 2 separate percent readings for batteries in a battery grip esp on t3i

Started by scrapjack, March 15, 2017, 02:35:05 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

scrapjack

Any device from mp3 players to cameras that uses a lithium ion batteries has to poll the battery to keep from running the voltage too low and preventing it from ever being able to take a charge. I can't understand why so few items actually allow a percent reading even if it'd be in a sub menu. I was annoyed to find my $600 camera and $30 mp3 player lack this function but my  $4  power banks, and some dudes $10 gas-station vape don't. Why are some manufactures so lazy?

It seems it shouldn't be too hard to add this feature, the device knows the total possible voltage for a full battery and the current status. It would be nice to see 2 readings to compare two batteries in a battery grip to see how much they differ in quality as the mAh isn't always truthful. To see if one discharges faster than the other would be especially useful to compare aftermarket to oem batteries, is the $5 battery really better than the $40 like the add claims. Also if one battery is dying it would make it easier to see which one with just one session. If hardware doesn't allow seeing each battery separately, at least a percentage reading for the whole grip, and single battery if no grip is used.

I'd especially like to see this for my camera model the t3i, almost every photographer I see in my town has this model, some have three.

a1ex

Quote from: scrapjack on March 15, 2017, 02:35:05 AM
It seems it shouldn't be too hard to add this feature

In this case, feel free to reverse engineer it.

On most models, the battery reading comes from the MPU (a secondary processor we know very little about).

Example for 60D:

919CB>    CtrlSrv:ff214980:83:03: PROP_Request PROP_BATTERY_REPORT
92B68>    PropMgr:00ca82b4:00:00: *** mpu_send(06 05 03 1d 1f 00), from ff05e224 (last 9041a)
931EB> **INT-36h*:00ca830c:00:00: *** mpu_recv(1c 1b 03 1d 55 00 00 00 00 18 00 4c 50 2d 45 36 00 00 00 00 00 01 00 ea 8f c4 2f 00), from ff1bf420
9343B>    PropMgr:ff0a5ec4:83:02: changeCBR PropID(0x8003001d)Parameter(1)Size(96)
9368D>    CtrlSrv:ff205860:83:03: PROP_BATTERY_REPORT copysize (96)<-(96)


Contents of PROP_BATTERY_REPORT from 60D, with battery level at 69% (see battery.c for decoding):

00000000: 0100 0000 4500 0000 003b 004c 502d 4536  ....E....;.LP-E6
00000010: 0000 0000 0001 00ea 8fc4 2f00 1f00 0380  ........../.....
00000020: 0000 0000 0300 0000 2b00 0000 2600 0380  ........+...&...
00000030: 0000 0000 0300 0000 2f00 0000 2800 0380  ......../...(...
00000040: 0000 0000 0300 0000 2e00 0000 2900 0380  ............)...
00000050: 0000 0000 0300 0000 3000 0000 2a00 0380  ........0...*...


Contents of PROP_BATTERY_REPORT from 500D, with full battery (3 bars):

00000000: 0000 0000 0300 0000 1c00 0000 1b00 0380  ................
00000010: 0000 0000 0300 0000 2100 0000 1f00 0380  ........!.......
00000020: 0000 0000 0300 0000 2b00 0000 2600 0380  ........+...&...
00000030: 0000 0000 0300 0000 2f00 0000 2800 0380  ......../...(...
00000040: 0000 0000 0300 0000 2e00 0000 2900 0380  ............)...
00000050: 0000 0000 0300 0000 3000 0000 2a00 0380  ........0...*...


I've tried checking the ADC channels on 550D and 60D (ShowAllAdChValue in Canon code), without much success, but I don't think this sensor is directly accessible from the ARM processor.

So, the task is a very hard one: the first step is understanding how the MPU reads this sensor and how it talks to the main CPU. The MPU uses the TX19A instruction set (MIPS with extensions), and documentation is available. It will probably take some hundreds of hours just to start making sense of it.