Additions to Solar DGNs, plus an additional FMI
Submitted by Kyle Cameron, GoPower/Valterra
- A new FMI - "Polarity Reversed"
- New DGNs: SOLAR_CONTROLLER_STATUS_2, _3, _4, _5, _6, SOLAR_CONTROLLER_BATTERY_STATUS, SOLAR_CONTROLLER_ARRAY_STATUS, SOLAR_CONTROLLER_COMMAND, SOLAR_CONTROLLER_CONFIGURATION_STATUS_2, _3, _4, SOLAR_CONTROLLER_CONFIGURATION_COMMAND_2, _3, SOLAR_EQUALIZATION_STATUS, SOLAR_EQUALIZATION_COMMAND.
- New SPNs for Solar Charge Controller.
Justification: This adds a considerable number of features which are missing from the existing Solar DGNs. The new FMI provides a specific way to address a fairly common and broadly applicable failure mode.
Administrators note: There are several places in the submission where a reference should be made to the standard physical units table. These will be added when the approved submission is incorporated into the main document. If added now, the hyperlinks would be broken anyway.
| Attachment | Size |
|---|---|
| RV-C Solar Charge Controller Proposal 2019-07-29.pdf | 331.38 KB |
My apologies for not noticing
My apologies for not noticing this earlier, but the DGN numbers for several of these is incorrect. The correct values are
SOLAR_CONTROLLER_SOLAR_ARRAY_STATUS 1FDFFh
SOLAR_CONTROLLER_CONFIGURATION_STATUS_2 1FDFEh
SOLAR_CONTROLLER_CONFIGURATION_COMMAND_2 1FDFDh
SOLAR_CONTROLLER_CONFIGURATION_STATUS_3 1FDFCh
SOLAR_CONTROLLER_CONFIGURATION_COMMAND_3 1FDFBh
SOLAR_CONTROLLER_CONFIGURATION_STATUS_4 1FDFAh
SOLAR_CONTROLLER_CONFIGURATION_COMMAND_5 1FDF9h
In general, RV-C avoids the use of DGNs with lower-order bytes less than 0x80. This is intended to limit confusion between RV-C and NMEA 2000, which mostly uses identifies with lower-order bytes with low values.
>Is there a reason not to
>Is there a reason not to support DC Source Instance and priority? We are presently using those to allow for coordination and prioritization of charging sources associated with a given battery, a key example: Allow the Solar chargers (with a higher priority) to work to their maximum capability by scaling back the output from our alternator controller. Knowing which chargers are assigned to the same battery, and their relative priority, is key to allowing this to work.
>> The only reason I can think of is that they are not in all the other Solar Charge Controller DGNs currently and this would require a complete revamp of all of them, which I'm not sure would be a good idea because it might break existing implementations.
I am thinking there is no
I am thinking there is no reason to revamp the rest of the DGNs, (Though it would have been helpful from the beginning - but history has already been established on those). Just use in the same way the Charger entry is used, a local table is kept linking a device to its claimed battery.
I think I see what you mean.
I think I see what you mean. Even if all of the DGNs don't have these parameters, if one DGN has them it will still allow the the device instance to be associated with a DC source and it's priority will be known when that one DGN is transmitted. If that is a useful thing then I will update the proposal to include linked DC source and priority.
I believe that the answer is
I believe that the answer is a DGN (maybe more than one) that allows these sorts of devices to identify the DC Source that they are attached to in a consistent way. A device that desires to know the "topology" of the charging/discharging of each DC Source (e.g. house, chassis) would request this DGN. I see three types of devices responding: Storage, Loads, and Sources. Storage would mean batteries, but perhaps super-caps someday. Loads would include at least the Inverter and Generic DC Loads. Sources would include Solar, Charger, and DC Generator. Obviously we should include the ability to extend the concept to other DC devices.
This "generic" scheme would eliminate the need to include this data in the device-specific DGNs, although products should still support the existing fields for the sake of backwards compatibility.
A standardized assignment DGN would also be useful, I think.
I agree, a standardize way
I agree, a standardize way has value. How quickly can it be developed is one question.... From my standpoint there must be A way. Replicate the approach already used for Chargers today in Solar today - OR - let this proceed forward w/o an ID method, and push for the standard way ASAP.
My personal option is: Add the DC_ID to this solar additions, as I fear a standard approach will take some time to craft and flush out. This way we can move forward using the same approach as Chargers, and when the standard approach does become available - accommodate the existing approach in both chargers and solar the same way.
In the end, I am not sure it matters which is taken, and if the standard approach can be created quickly that is good. But I do believe we need to have something to truly deliver the value that RV-C is able to. But truth is, if we do not add the DC_ID to this submission, it will be in the same situation we are with the new batteries submission, as they too are lacking any IDing linkage back to a DC_Source ID.
Lets just add DC Source
Lets just add DC Source Instance and Charger Priority for now if it will be used, then a more standardized way can be developed in a future submission. I feel like the standardized approach needs to be considered carefully and should be it's own thing. If you guys are in agreement let me know and I will make the final changes.
You have my support for this
You have my support for this direction.
-al-
kcameron, Hello. Thanks for
kcameron,
Hello. Thanks for the replies.
On 6.45.8 Solar Charger Controller Battery Output Status
o Yes you are correct that it is very similar, just missing the DC source instance and charger priority. I can change this to match and just make the first two bytes "reserved" as well as temperature uint8 instead of uint16.
Is there a reason not to support DC Source Instance and priority? We are presently using those to allow for coordination and prioritization of charging sources associated with a given battery, a key example: Allow the Solar chargers (with a higher priority) to work to their maximum capability by scaling back the output from our alternator controller. Knowing which chargers are assigned to the same battery, and their relative priority, is key to allowing this to work.
Hi Al, Thanks for the
Hi Al,
Thanks for the comments! I will update the proposal accordingly. Please see my replies below.
• 6.45.8 Solar Charger Controller Battery Output Status
o Yes you are correct that it is very similar, just missing the DC source instance and charger priority. I can change this to match and just make the first two bytes "reserved" as well as temperature uint8 instead of uint16.
o Byte 5/6: This is intended for solar controllers that have an external temperature sensor for measuring battery temperature. I will clarify this.
• 6.45.13 Solar Charger Configuration Status 2
o Byte 5/6: I guess it depends on the controller and load. Ours re-enter float unless there is a large enough load in which case it goes to bulk. I will update this to make it more generic by just saying "restart a new charge cycle" as you suggest.
• 6.45.17 Solar Charger Configuration Status 4
o Byte 7: Good idea! Will do.
It is wonderful to see Solar
It is wonderful to see Solar additions to RV-C. I do have a few comments and questions on the latest submissions:
Comment / Questions:
• 6.45.8 Solar Charger Controller Battery Output Status
o This seems VERY CLOSE in structure and purpose to the existing CHARGER_STATUS_2 (1FEA3h). Could this one be adjusted to replicate the CHARGER STATUS 2 structure – to allow reuse of parsing code : - )
o Byte 5/6: Is this temperature to temperature of the controller, or something else?
• 6.45.13 Solar Charger Configuration Status 2
o Byte 5/6: Does the controller enter float, or restart a new charge cycle?
• 6.45.17 Solar Charger Configuration Status 4
o Byte 7: I would suggest striking the last sentence "Only valid for lead acid batteries". Going forward we do not really know what other chemistries which might come out that could use temp comp. If temp comp is not used by a given battery (e.g., LiFeP04), this value could be set to 0 to indicate such.