Large DCC packets support

[HFF-Git]

Hello all,

I was directed to this GIT from a comment made on the old Site DCC++. There is a dialog that explains a bit more.

There are DCC packets of up to ten bytes of data. For example the CV XPOM command which you can find in the RCN214 spec of the RailCommunity. The original code does not handle such large packets. I have adapted the "loadDccPacket" routine to generate the bit stream. If there is interest to include it, just let me know.

DCC++ is just great for starting digital model railroading!!!!

[FrightRisk]

Thanks for coming over to help. Will comment more tomorrow, but wanted to say hello. How many people use these large packets would you say? Have you visited our Discord?

[atanisoft]

@HFF-Git are there any commercially available decoders that support and require usage of XPOM? That packet format appears to use the "future expansion" format and appears to use more data bytes than the NMRA DCC spec declares.

[HFF-Git]

@atanisoft: I did send an Email to the RailCommunity folks. The answer came today. They are always in close discussions with the NMRA on such matters. So far, I have not seen an official end of these discussions documented in the NJRA specs.

Unfortunately they are not at liberty to give commercial statements about who is using it already. So, when I have my railroad running I can test the commands ( LGB decoders ). Anyway, the changes in software on the local version I use work for all lengths up to ten bytes and I am done with this subject.

What really is a good command is to send speed, direction and the functions F0 .. F12 in one command ( hex 3C instruction ). This way the functions get refreshed as NMRA recommends. This command can also be up to 8 bytes when functions up to F28 are refreshed. But even using the command only for F0 .. F12 requires 6 bytes ( assume long loco address, instruction, speed/dir byte, two function bytes ). This is how I found the problem in the first place.

Best
HFF-Git

[atanisoft]

They are always in close discussions with the NMRA on such matters. So far, I have not seen an official end of these discussions documented in the NJRA specs.

I'll reach out to a few of my contacts who are working on the NMRA specs as well and see if I can get any clarity on it as well.

Unfortunately they are not at liberty to give commercial statements about who is using it already.

Most likely there are none since it is not part of the NMRA standard which is required to be adhered to for compliance purposes. But that doesn't mean that there aren't any, they just may not know of any.

direction and the functions F0 .. F12 in one command ( hex 3C instruction ).

That does sound like a great optimization but I don't know of any decoders which support this explicitly. This optimization would need to be done on a per-dcc address basis likely (same for other extensions).

[habazut]

There are several manufacturers with representation in the RCN. We could of course ask them for a table of compliance of their products with the RCN standards, for example stating which firmware versions they claim are compliant with which standards. As they themselves have been part of the RCN they can hardly say "we do not know".

[habazut]

The original code does not handle such large packets.

Then you might have noticed that it is very wasteful with RAM when you extend the number of packets in the original code as ist costs approx 9/8 * slots * 2 bytes for each new byte. Depending how many bits are already used the 9/8 might be rounded up to 16/8 = 2. That is another reason not to implement this, especially not in the classic where hurts much more than newer code base.

I have adapted the "loadDccPacket" routine to generate the bit stream.
If there is interest to include it, just let me know.

Have you found any decoders that react on it?

[HFF-Git]

I just learned, ESU Decoder 5th Genration and Lenz Decoder ( both are part of the RailCommunity ) are good candidates to test. Of course we could ask them... the ESU data sheet does not really tell the RCN standards supported. But the decoder data sheet states that it supports up to F31.

All I wanted is to be helpful in making the DCC packet generation to support longer packets. :-) Once I have such a decoder I will test it for sure.

[HFF-Git]

@habazut. I already said that I have no decoder yet. But once I have one, I can look into it. Until then just forget I even asked.

[habazut]

@HFF-Git Sorry, I did overread that. If I would start looking then I would start looking at Zimo because they have been active in the RCN and make firmware updates available (for which you need their equipment or a black Z21 to get into the decoder). I have neither.