Submitted By: Doru Botex 

Justification:

Up to now a Charger (Converter) was considered to be a device that converts AC power to DC power. Due to the electrification of recreational vehicles, a converter device can also be a DC-to-DC converter/charger which converts DC power taken from the starter/chassis battery to DC power that can be used to charge the main/house battery.

A DC-to-DC Converter can be unidirectional, or bidirectional.

The changes from this submission are meant to add few DGN fields that indicate the converter type as AC-to-DC or DC-to-DC as well as to indicate if the device is unidirectional or bidirectional and allow for charging direction control.

Wednesday, September 2, 2026 | 09:10am
Attachment Size
6.20 Charger_Converter_proposed_changes.docx 116.69 KB
You must be logged in to comment. Log in
1 comment

Martin Perlot Member for 1 year

Nice submission.

OBJECTION

CHARGER_COMMAND - Direction 
   The 10b value is reserved for error conditions, and although this is a command (and "error" wouldn't make any sense), we should avoid using this value.  I suggest expanding the field to 3 bits, which would allow 10b to be used unambiguously as "Auto".   

Introduction

There is some ambiguity in the description.   This scheme requires a DC-DC Charger to report using two different instances.  This opens up a number of questions regarding how data is reported and commands accepted.

  1. In CHARGER_STATUS, what values are reported for each instance in each state.  (Do the directions match, or is each the opposite of the other?  At any given time is the state of one "Not Charging"?)
  2. Is the normal/reversed value in CHARGER_COMMAND absolute, or relative to which instance is used?
  3.  When using the DC_SOURCE_CONNECTION_STATUS/COMMAND DGNs, are both instances reported and are the primary/secondary values the same for both or reversed?

Some of the answers are contained in the tests (and kudos to you for writing good tests!), but these should be clarified up front.  

SUGGESTION

According to CHARGER_COMMAND, the directionality may be temporary or permanent.  A status field to indicate which is the case seems appropriate, as well as a command (or additional values in the Direction command).  Another flag to indicate "auto" mode seems appropriate.  CHARGER_PROPERTIES is full, so I suggest created "DC-DC_CHARGER_PROPERTIES" and put all the new fields there.  (I have the feeling that this DGN is going to expand pretty quickly anyway.)

QUESTION

Is there any overlap between this and DC_DISCONNECT?  Do these products do double-duty as a bridge (e.g. for starting the engine when the chassis battery is dead?)