Martin Perlot of SilverLeaf Electronics and Dimitri Butvinik of Lithionics submit the attached additions.
BATTERY_STATUS_1, . . . BATTERY_STATUS_11, and BATTERY_COMMAND.
Included is explanatory text indicating when these DGNs are to be used and when DC_SOURCE DGNs are appropriate.
Justification:
The DC_SOURCE DGNs clearly indicate that batteries are to be maintained in "banks", and it specifically calls out the "House" and "Chassis" banks. At the time there were no "smart" batteries such as the modern Li-ion packs and no thought was given to the concept. Today most devices look to the DC_SOURCE_STATUS messages for an aggregate value of the entire house (or chassis) battery system. This set of messages allows each individual battery to be monitored while maintaining the DC_SOURCE status as well.
Attachment | Size |
---|---|
Battery Status Submission.doc | 126 KB |
After consultation, the
After consultation, the following modifications have been proposed to address the amount of traffic generated by reports at the cell level:
In all status DGNs, make Byte 1 definition, "0 = Entire battery. 1-250 = Cell Index"
In preface add: "A device responding to a request for any of these DGNs shall respond with values for the whole-battery, not for individual cells. Cell data is not broadcast in normal operation, and if a device or service tool desires data for individual cells, it shall trigger a report using the BATTERY_COMMAND message."
To BATTERY_COMMAND, add Byte 2: Command. uint8. "1 = Report a snapshot of the cell status."
I'm placing a temporary hold
I'm placing a temporary hold on this submission as Dimitri and Al Thomason are in private discussions that might lead to some amendments. - Martin