Remove 6.18.20 & .21


Table 6.18.20b, doesn't make much sense. Byte 2 may be “Priority', in which case it duplicates data in GENERATOR_DC_STATUS_2, or it may be “Absorption Time”, in which case it duplicates GENERATOR_DC_CONFIGURATION_STATUS_4 – but with absurd scaling.

Please see attached for proposed deprecation/removal.

Section 6.18.20_.21 Removal 070821.docx19.9 KB

DISCUSSION: There is a


There is a collating error in these PGNs, the original submission was:

Byte Bit Name Data type Unit Value description
0 - Instance uint8 -
1 - DC Source Instance uint8 - DC Source generator is associated with.
2 - DC Generator priority uint8 - Priority of DC Generator. See b

With the primary purpose to allow association of the DC Generator with its attached DC SOURCE INSTANCE. (Byte 1 & 2 are repeated to meet the goal of all messages begin fully self-sufficient). However, it does appear this is a direct replication of DC_GENERATOR_STATUS_2. More so, in late discussion to the spec, DC Source association was generalized using : DC_SOURCE_CONNECTION_STATUS message.

Is it possible to retire / remove a DNG once the spec is published? As opposed to Depreciate it?

This is really up to Von.

This is really up to Von.

Personally, I would mark section 6.18.20 with the text "GENERATOR_DC_CONFIGURATION_STATUS_5 has been removed from the protocol and DGN 1FDD5h deprecated." Same with 6.18.21, and I'd mark those rows in Table 7.7 as deprecated. I always erred on the side of deleting as little as possible, but in this case the DGN is so incoherent that I'd pull the table out completely and just leave a message for future generations so that no one comes along and defines a new DGN called GENERATOR_DC_CONFIGURATION_STATUS_5 or using 1FDD5h.

I would not disagree with you

I would not disagree with you on this point, given the miss-edits in the PGN and how it clearly is not correct, nor published as intended -- one would either remove the whole thing, or correct it and then deprecate it...