Open FrightRisk opened 3 years ago
@FrightRisk It is our intent to harmonize the NMRA DCC standards with the RCN standards as much as practically possible. This of course will take time and many DCC WG votes. For anyone wanting to have influence over the process, they should participate in the DCC WG.
I don't know what you mean by "bit duration limits", I don't see anything like this in RCN-212. Can you provide a specific document reference?
If by "extended button functions" you mean adding support for F29 through F68, can you explain how this "breaks the NMRA spec"? I see this as a simple addition of new commands, something the DCC WG has done many times over many years. It is no different than when the available functions was expanded to include F13 through F28 about 10 years ago. There are several manufacturers already using these extended functions and particularly with newer advanced sound decoders, a legitimate need for them. If you have meant something else, please explain.
@bakerstu My mistake as there is RCN-210 for signal and 212 for packets. Thank you. Perhaps we are misreading the spec or lost something in the German to English translation. Dec 1, 2019 RCN-210, sec 2.2 states:
So it is a bit confusing to say the bit duration is between 95 and 12000µs, and then say any number in between that could be the limit. And if it is saying that if you have no DC locos, the maximum duration for a 0 is 116µs, then any system that uses 2x a 1 pulse to generate a 0 pulse and comes up with 116µs will certainly fail if their signal is off by just 1µs too long.
As for the extended functions, Our concern is our reading of a possibility of a discrepancy in the use of binary state commands. The NMRA spec, and the RCN spec specifies that binary states and functions are similar in purpose but are not the same. Therefore, system manufacturers may use them freely. NMRA says Function 65 may perform a different operation to binary state 65. Conversely, the RCN spec states that function 65 and binary state 65 must perform the same operation. Our reading of the specs sees this as a breaking change.
RCN-212 Dec 6, 2020 Sec. 2.3.4: "Decoders that support functions 29 to 68 must also be able to control these functions via binary states 29 to 68"
Thank you for helping to clarify these points.
P.S. Adding this later. This document has a table that may make it more clear. It seems to indicate all you 0 bits could be longer than 116. I would just worry that some decoders might cheat and throw out anything over 116, especially if they didn't support zero stretching. https://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.1_electrical_standards_for_digital_command_control_2021.pdf
@FrightRisk Regarding the additional zero bit constraints in the RCN standard, these look like they are intended to allow for multi-protocol decoders and command stations to not get confused. The RCN standards are primarily maintained by mainland European manufacturers. They have a lot more experience with multi-protocol systems, as they are quite common there.
The NMRA DCC WG may choose to adopt these restrictions as well, at some point. However, I think it is more likely that we would add this commentary to a non-binding technical note as a recommendation to manufacturers.
If you want to use a "doubling" of the one bit time technique to create zero bits, then just choose to use a smaller duration 1 bit. You are allowed to go down to 55usec. BTW, if your system cannot produce DCC bits with better than 1 usec determinism, you are probably doing something wrong with your design. Beyond wasting bandwidth, this technique doesn't leave a lot of flexibility for handling some of the important NMRA Bi-Directional (RailCom) corner cases. I strongly recommend decoupling the zero and one bit timing from one another.
Hi Stuart. The DCC-EX team is a bit concerned with the RCN-212 spec merging into the NRMA spec and wanted to know the proper method/forum to discuss what will be adopted. In particular, there are 2 places (the bit duration limits and the extended button functions) that would appear to break the NMRA spec. I know the bit length change would break DCC++ EX if that were approved. Thanks!