AP_BattMonitor: SMBus Ehancements

[WickedShell]

Issue details

This is meant to be a tracking issue for planned SMBus specific features, and the required support in AP_BattMonitor. I've had the same conversation 4 times over the last week covering the same topics with different people, so I thought it would make more sense to document everything in one place. (I'm aware of #5900, but that is solo specific).

Features:

• Fetch and report temperature (Underway, see AP_BattMonitor: Cell voltages and Temperature #6020)
• Fetch cell voltages and report them (Underway, see AP_BattMonitor: Cell voltages and Temperature #6020)
• Fetch battery serial number and report it (probably via a parameter, that way it is easily logged/viewed on the GCS without adding overhead to every DF message/telem message) AP_BattMonitor: SMBus: Fetch serial numbers and pack capacity #6106
• Fetch the manufacturer name and date of the battery (log it to DF?) Decided that this didn't present a value at this time
• Fetch and utilize the BATTERY_STATUS ( 0x16) fields for throwing alarms/low battery levels
• Use the CHARGE_STATUS ( 0x0d ) in the Maxell driver rather then having the autopilot integrate current consumption. (Also fetch capacity values, rather then utilizing a parameter).
• Support cell based failsafes on the autopilot (spread or low values)
• Unify redundant code (Not all of the Maxell vs Solo stuff can easily be unified, however there are a number of things that can be, which would reduce flash consumption, lower maintenance overhead and reduce the chances of erroneous behavior.)
  • get_PEC() is entirely the same, and specified by the SMBus protocol, and should be moved into the common SMBus code. AP_BattMonitor: Use a common PEC helper #6089
  • read_word() can be unified (just requires an API to check if the PEC is supported or required) BattMonitor: Unify common functions #6091
  • read_block() might be possible to unify, solo vs maxell treats this a bit different as far as interfacing with the battery is concerned.
  • Create a common SMBus helper that reads common SMBus fields (voltage, current, status, temperature) and use this in the backends rather then duplicating it.

Those are just the ideas off the top of my head, I welcome other comments and requests. (This is primarily intended to be a list of common SMBus features however). I'm not promising to address all of these items immediately, but this is whats on my radar, and some of them will be addressed by myself at least soon.

Platform

[ x ] All
[ ] AntennaTracker
[ ] Copter
[ ] Plane
[ ] Rover

[adrianbostan]

Hi,

I'm designing a SMBus battery monitor with high accuracy energy accumulation measurement ~ 0.1%.

• import and export energy.
• cycle counting
• power,current,individual cell voltage,etc.

I've noticed a limitation in the SMBus protocol:

Range: 0 to 32,767 mA for charge or
0 to -32,768 mA for discharge

The issue is that 32Amps it's a big limitation and we need to add an option to select the scaling of the current like : 32,768 ---> 327A.

Also i've noticed a bug the arduplane 4.0.5, BATT_CRM_MAH and BATT_LOW_MAH failsafe are not working with SMBus.
Also tested with copter 4.0.5 and it's working.

Regards,
Adrian

[be-ska]

I've noticed a limitation in the SMBus protocol:

Range: 0 to 32,767 mA for charge or
0 to -32,768 mA for discharge

The issue is that 32Amps it's a big limitation and we need to add an option to select the scaling of the current like : 32,768 ---> 327A.

The PR #23786 I've just submitted should fix this issue, using the SpecificationInfo() SMBus function.

[bhavilrevo]

@be-ska Did you get any update for your PR? I am trying to do the same at my end, but I have multiple BMS's which need the scaling function. However, some of those has the scaling factor under the SpecificationInfo() block, while some don't.