Additions to DC Source, Battery DGNs
Mon, 2019-08-05 17:42 — Martin Perlot
Kyle Cameron of GoPower/Valterra has submitted the following:
Additions to DC_SOURCE_STATUS_6, BATTERY_STATUS_6.
New DGNs: DC_SOURCE_STATUS_12, _13, DC_SOURCE_CONFIGURATION_STATUS_1, _2, , DC_SOURCE_CONFIGURATION_COMMAND_1, _2, BATTERY_STATUS_12, _13, BATTERY_CONFIGURATION_STATUS_1, _2, , BATTERY_CONFIGURATION_COMMAND_1, _2.
Justification: These DGNs implement a number of features that are common to battery management systems.
| Attachment | Size |
|---|---|
| RV-C DC Source Proposal 2019-07-31.pdf | 278.45 KB |
| RV-C Battery Proposal 2019-07-31.pdf | 272.38 KB |
Thanks for your comments. I
Thanks for your comments. I am fairly new to RV-C so I am learning on the fly and it's very nice to have someone to prevent me from doing something silly.
Please see my replies below beside the ">>".
DC Source Proposal:
>6.5.6 DC Source Status 6
>>You are absolutely correct. I didn't notice this. I will propose that this be fixed.
>Byte 3, bits 0/1 & 2/3:
>>They might be a little redundant, but I think they are still very useful. The reason is, depending on the type of battery, a different lower state of charge might be necessary to extend cycle life. For example, we recommend that customers only discharge lead acid batteries to 50% SOC because they can get 1100 cycles out of it instead of 250 if they discharge to 100%. A lithium battery, in comparison, can be discharged much deeper without as significant of a cycle life hit. This could probably be accomplished using voltages and probably will be for DC sources that don't coulomb count, but I think it would be nice to for a more accurate option. One issue I can think of with voltages compared to SOC is if a microwave is on for 10 minutes this might cause a voltage dip that is long enough to cause the battery to be disconnected, but if the SOC is not below the limit there could be some logic to prevent that from happening.
>(noting the Bits ID are missing for byte 3 & 4 submissions)
>>I'm not really sure what this means?
>Byte 4, Bits 0/1 & 2/3:
>>Yes this makes sense. I will update to include disconnect charge bus.
>6.5.15.18: In reading these additions, they seem to be talking more to a the configuration of an SOC meter / display device as opposed to the DC source. Would it be clearer to place these under a new SOC or Battery Meter device instead?
>>I mostly agree. If the DC source was a smart battery then some of these things like shunt voltage/current and coefficients would be built into the battery and changing them would not be necessary. I will admit that I added this things with an external battery monitor in mind. However, there are some additions I have suggested that I think should be in the DC source and Battery, such as historical information and SOC/temperature limits. I had originally brought this up with Martin when I was deciding how to make these changes and his advice was to put it in the DC source. If Martin agrees with you, though, I am happy to move some of this stuff and some duplicate stuff into a new "battery monitor" section.
>6.5.15 Byte 5/6: Full Capacity: this is a repeat of the existing capacity in DC_SOURCE_11
>>This was a silly mistake. I can remove it.
>6.5.15 Byte 7: tail Current.
>>I suppose the rest of the parameters are not included because they are included in the charger and solar charge controllers DGNs. However, maybe they would be useful here so a charger can read these parameters from the DC source and automatically configure itself rather than a human having to do it? This might be a reason to add these things. By things, I am referring to charge voltages and currents, time since last equalization etc. What do you think?
Some questions and comments on the Battery Submissions Proposal:
>Same comments as with DC Source 6 below, section 6.5.6 with regards to low voltage and low SOC portions (6.49.6)
>>Same answers.
>SOH: I am noting there is no SOH value contained in the proposed battery submissions. Perhaps it can be tacked onto the end of 6.49.11 BATTERY STATUS 11 --- Byte 7, SOH Value of 0..120% Indicated the State of Health of the battery, often defined as the present % of capable battery capacity vs. the as-designed battery capacity.
>>6.49.3 Byte 2 has state of health.
>6.49.15 -- .18, same question as with DC_SOURCE below about an SOC meter.
>>Same answers.
>And an overall comment: There is nothing in this submission allowing the association of the given battery instances to the ‘DC-SOURCE message .. of the bank as a whole” as noted in 6.49 preamble. I understand there is a work effort underway to address this, and perhaps do so at a global level, but without this defined linkage there is a significant gap with this submission.
>>I'm thinking this might be better addressed in another proposal as I don't really feel confident taking this on myself. I am willing to help though if you want to work together on it?
Hello! Am glad there is an
Hello! Am glad there is an opportunity to pass these around, makes RV-C better in the end!
Some continued comments:
6.5.6, Byte 3: Bits 0/1, 2/3: Good point, Voltage is not always a good SOC proxy!
6.5.15 -- 18: Myself, I would say create a new SOC meter if indeed one wants to look to have a device which is stand alone and configurable. But I see you point, some things would make sense to add to a batteries past history. I guess the single item that tripped me up was: Tail Current. IF we are looking from a battery viewpoint, this is odd to have a charge profile parameter added here (See comment below). However, IF we are looking at this from how to configure a stand-alone SOC meter, it makes sense -- in the stand alone meter section.
But yes, I see you point: A number of these items do seem appropriate to associate with a battery/DC_Source, even if it is the SOC meter that ends up supplying the information for some simpler technologies (ala, FLA vs. a BMS enabled Li) But Tail current:
6.5.15 Byte 7 (Tail current): It seems to me that in many ways RV-C has grown at times related to what a given product is able to do, vs. maybe a more organic look at the overall picture. Charge Profile information to me is a key example, there is a lot of it contained in the Chargers section, and some of it was expanded a couple of years ago IIRC (Hence the delta between Solar and charger). It does seem it would have been a better approach to place it int he DC_SOURCE for all to use - but that is not how things got started. So - really kind of look to folks like Martin to give a voice here: How to handle. Is it best to keep all the charge related parameters (ala, Tail current) with the rest of the existing configuration details - spread out across the different devices, or is it perhaps appropriate to draw a line and say any new ones get added to the DC-SOURCE (and Battery). OR... Add them all here to DC-SOURCE and BATTERY, and guide existing devices to use this way overriding the existing methods...
I think this is the one that is troubling me the most, just from constituency standpoint.
Martin, can you help us here with some thoughts?
Overall comment on linkage: I know Martin had started working on something, perhaps after these latest additions get worked though he will take it back up.
Thanks, Al! Regarding the
Thanks, Al!
Regarding the charge profile information, I agree that it would be better placed in DC Source / Battery only and not on the Charger / Solar Charge Controller. However, that only works if every battery is a "smart" battery and it is able to store and communicate that information. Having charge profile information stored on both the Charger / Solar Charge Controller and the DC Source / Battery I think better covers all cases. This would allow a charger to read charge profile information directly from a "smart" battery, but it also allows charge profile information to be manually entered and stored on the charger when a "dumb" battery is used. It seems like a waist to have duplicate information, but functionally it makes sense in the same way it makes sense to have two types of chargers.
There are a number of other
There are a number of other places where we duplicate data like this. There are three different ways that we can handle this sort of situation, and there are examples of all three in the protocol.
Method 1: Duplicate the data explicitly. For example, several devices - including the inverter and the charger - have a DC voltage field, and each is meant explicitly as "the voltage measured at this device". Of course, often the inverter IS the charger, but we can't assume that. Nor can we assume that the voltage at these devices is going to match the voltage at the battery . . . in fact, there is great value is being able to measure the difference in voltage between the inverter and the battery itself.
Method 2: Abstract the device type. With this strategy, the potentially duplicated data is assigned to an abstract device type. The DC Source and Clock are the two good examples. This works best for data where there is "one true value" that multiple nodes may have the ability to report, but one may be "closer to the truth" than others.
Method 3: Use multiple devices to characterize the node. It is common for a node to incorporate more than one device type - the inverter/charger is the most obvious example. A more subtle example is, for example, the Air Conditioner that also reports as a Generic AC Load for purposes of load management (shedding). This technique is handy for allowing any device to report power consumption (as a Generic AC or DC Load) or provide a method of manual control (e.g. for load management). This technique is best for values that are common across many kinds of devices, but which are clearly connected to the specific node.
In this particular case, I believe that there is a distinction between how the Smart Battery is configured and how the Solar is configured - a discrepancy between the values may be meaningful in the same way that the voltage drop between the battery and the inverter may be meaningful. And I'm not an expert in these specific devices, but I imagine that it may be that some discrepancies may be forced - the solar may not have the capacity to match the battery settings, for example. If that's true, then clearly we aren't really duplicating *data*, we're merely using common terms to describe similar data.
Sorry about not replying
Sorry about not replying sooner, I had been expecting to get notice from RSS feed on comments added....
In any case, am wondering about what to do from here. Are you and Martin suggesting we also add full charging info to DC_Source at this time, for chargers to pick up if they wish? It can seem a bit complex, but does go along the way we deploy our regulator today: When we can get guidance over the CAN for charging guidance we follow it, but if not we fall back to internal configuration. A kind of get-home offering. Most times the internal config is simpler in this case, and that would support kcameron's idea of having both.
So today, what is perhaps the steps needed to move forward?
I am thinking we add full
I am thinking we add full charging info to DC source and Battery for chargers to pick up. This will take some more work on my part so I'd like to get agreement before putting the effort into it. Are you guys (and anyone else watching this thread) in support of this?
Not seeing any other replies.
Not seeing any other replies. Overall I think this is a better direction - but I also think that much has already been in place for a very long time, most notable the Chargers...
My guess is this specific idea / topic might be best worked out in a working session of the RV-C group. Martin, given that there seems to be an effort underway to re-energize RV-C, what would your guidance be on this topic.
Well, the RV-C meeting is set
Well, the RV-C meeting is set for next Wednesday, 10-23, in Elkhart. That would be the time to get a "Ad Hoc Technical Subcommittee" together. I'll send an e-mail to the RVIA staff and Mark Howlett, asking for an agenda item.
Some questions and comments
Some questions and comments on the Battery Submissions Proposal:
Same comments as with DC Source 6 below, section 6.5.6 with regards to low voltage and low SOC portions (6.49.6)
SOH: I am noting there is no SOH value contained in the proposed battery submissions. Perhaps it can be tacked onto the end of 6.49.11 BATTERY STATUS 11 --- Byte 7, SOH Value of 0..120% Indicated the State of Health of the battery, often defined as the present % of capable battery capacity vs. the as-designed battery capacity.
6.49.15 -- .18, same question as with DC_SORUCE below about an SOC meter.
And an overall comment: There is nothing in this submission allowing the association of the given battery instances to the ‘DC-SOURCE message .. of the bank as a whole” as noted in 6.49 preamble. I understand there is a work effort underway to address this, and perhaps do so at a global level, but without this defined linkage there is a significant gap with this submission.
Some questions on the DC
Some questions on the DC Source Proposal:
6.5.6 DC Source Status 6
(Original) Byte 2: Bits 4/5 and 6/7: It seems this may have a typo in it, where the description refers to the disconnect of the charge bus and that charging should stop – am thinking at low-voltage limits, discharging should terminate and the discharge bus should be disconnected instead.
Byte 3, bits 0/1 & 2/3: With the above correction are these Low SOC messages needed? Seems they are largely redundant. If not, then would ask if it would also be appropriate to add High SOC disconnects of the charge bus.
(noting the Bits ID are missing for byte 3 & 4 submissions)
Byte 4, Bits 0/1 & 2/3: It is my understanding that a High Temp Limit will also trigger the need to stop charging.
6.5.15..18: In reading these additions, they seem to be talking more to a the configuration of an SOC meter / display device as opposed to the DC source. Would it be clearer to place these under a new SOC or Battery Meter device instead? Some examples,
6.5.15 Byte 5/6: Full Capacity: this is a repeat of the existing capacity in DC_SOURCE_11
6.5.15 Byte 7: tail Current. Tail current is also at times used as a parameter in charge profiles. Reading this as a SOC meter, this value makes sense – as a way for the meter to determine if the battery is fully charged. But as part of the rest of the DC_SOURCE_xx, I am wondering why only the Tail Current would be defined here and not the rest of the parameters typically found in a charge profile.