Update: This page was originally about the OpenLCB group's efforts to work with the NMRA on a set of NMRAnet documents. OpenLCB members put significant work into that, as shown by the discussions in the 2nd part of this page, below the line. Unfortunately, at their February 2011 meeting the NMRA Board adopted an unauthorized modification of some work done by an NMRAnet working group as NMRA Standard S9.5.1. This unacceptable situation was documented in detail on other pages. OpenLCB withdrew from the NMRA effort. During Spring 2011, we put a huge amount of effort into getting that decision revisited and the systematic problems in the NMRA corrected.
At the NMRA Board meeting and Convention in July 2011, we were told that the Board had voted to de-adopt the S9.5 Standard, and that the causes of the original incorrect action have been removed. Although as of this writing (August 1, 2011) we have not yet seen the promised written minutes of the meetings, we are cautiously optimistic that with new people involved the NMRA's standards effort for NMRAnet will be back on track. Certain elements of the NMRA have terrible record of living up to commitments, however, so we're leaving this entire page up in case the troubles continue and people need to understand the history.
In hope of progress, we have submitted current versions of our draft Standard [pdf][with changes marked][odt] and Technical Note [pdf][with changes marked][odt].
We are also in the process of developing a node to be included in a DevKit. The NMRA has agree to purchase some of these for NMRAnet development and demonstration.
We'll provide updates here as they occur. We hope to see demonstrated progress by Spring 2012.
The NMRA is interested in defining a “NMRAnet®” as a standard, and OpenLCB™ wanted to take part in that. Several people put significant efforts into created strong NMRA documentation, and this page contains documents for our effort in that direction. Our own Specifications and Explanations are available in a separate directory. The separate “documents” directory contains our development documentation.
Unfortunately, the NMRA has allowed Di Voss to entirely hijack this effort in favor of the specific activities of his brother Don. This resulted in the NMRA adopting a very modified version of the common physical layer standard that had been developed with OpenLCB help. More details on these unacceptable actions and their poor decision can be found on a separate page. The net result is that we don't currently anticipate taking part in the NMRAnet process again.
After the summer 2010 NMRA meeting in Milwaukee, the NMRA wanted to start with a “Physical Layer” standard for NMRAnet implementations that use CAN. Various discussion ensued. The following documents were submitted for NMRA approval on September 17, 2010. The NMRA decided they needed to reformat them, which took three weeks, but after that they were proposed for a vote on October 7, 2010:
S-9-x-1 NMRANet® Physical Layer draft standard (ODT original) (PDF)
TN-9-x-1 NMRANet® Physical Layer draft technical note (ODT original) (PDF)
The NMRA effort defined some “Goals and Measures” and “Goals and Mandates” for the NMRAnet effort in 2008 and requested information from people working on NMRAnet proposals. In 2008, 2009 and 2010 the OpenLCB group wrote replies to those, along with introductory information, which are linked from this section. We've also provided some use case information.
TN-9-6-NMRANET Overview (Draft) – a draft overview of OpenLCB/S9.6 for NMRAnet (ODT working copy) (PDF of latest draft)
TN-9-6-NMRANET-Goals and Mandates (Draft) – a draft reply to the NMRA “Goals and Mandates” document (ODT working copy) (PDF of latest draft)
TN-9-6-NMRANET Goals and Measures (Draft) – a draft reply to the NMRA “Goals and Measures” document (ODT working copy) (PDF of latest draft)
TN-9-6-NMRANET Use Cases (Draft) – a description of how OpenLCB meets various use case requirements (ODT working copy) (PDF of latest draft)
Standards are required of all implementations. They therefore are the baseline, mandatory functionality.
From the DCC Working Group:
"An NMRA Standard is a public document that specifies the minimum requirements for interchange of equipment. To be granted a conformance seal, a manufacturer must meet all relevant requirements specified in all standards. "
Recommended Practices describe optional features and capabilities. Those need not be present, but if they are present they must function as described in the RP.
From the NMRA DCC Working Group:
"An NMRA Recommended Practice is a public document that specifies the maximum requirements for interchange of equipment. For any DCC product to be granted a conformance seal, the product must not violate any recommended practice. "
Although the terms of both Standards and Recommended Practices use the “must” construction, note the difference between “must meet” and “must not violate”. In practice, it's not at all clear what “the maximum requirements for interchange” means. Perhaps that was intended to be “the requirements for maximum interchange”?
Technical Notes are non-normative documents which convey information useful to the model railroading community.
From the DCC Working Group:
"An NMRA Technical Note is Technical Department document used to convey information useful to the model railroading community. Technical Notes are only available to NMRA members."
This last sentence seems ominous – the OpenLCB group will want information to be available to all NMRAnet users. Maybe the NMRA has some other type of doc we can use for technical information. Or we can write a “For Dummies” book outside the auspices of the NMRA...
There doesn't seem to be a single system of numbering for Technical Notes. Some are based on dates (TN-2004-1), some are linked to standards (TN-9.2.1), and some have multipart numbers TN-3-05.
The NMRA has assigned the 9.6.* numbers to the OpenLCB proposal for NMRAnet.
We want to keep the various components of OpenLCB in separate standards documents, including the wire protocols and higher level protocols, so we propose using a several-part number where the 3rd group (1st after S 9.6) is the type, and if need be a 4th group adds a wire-protocol identifier:
|
General Document |
CAN Document |
TCP/IP Document |
---|---|---|---|
Physical Layer |
S 9.6.1 (basically empty) |
S 9.6.1.1 (a common one is being developed as S9.x.1/TN9.x.1, and may even be adopted under that number) |
S 9.6.1.2 (basically empty) |
Data Link |
S 9.6.2 (basically empty) |
S 9.6.2.1 (a common one is being developed as S 9.x.2, and may be adopted under that number) |
S 9.6.2.2 (basically empty) |
Network |
S 9.6.3 |
S 9.6.3.1 |
S 9.6.3.2 |
Transport – Event Exchange |
S 9.6.4 |
S 9.6.4.1 |
S 9.6.4.2 |
Transport – Datagrams |
S 9.6.5 |
S 9.6.5.1 |
S 9.6.5.2 |
Transport – Streams |
S 9.6.6 |
S 9.6.6.1 |
S 9.6.6.2 |
Higher level protocols are then described in a transport-independent document:
Protocol |
Document Number |
---|---|
Producer/Consumer Layout Control |
S 9.6.7 |
Memory Configuration |
S 9.6.8 |
Configuration Description Information |
S 9.6.9 |
Display |
S 9.6.10 |
etc |
|
This results in a lot of small documents, but because we're working with an evolving specification, it lets us advance and adopt each part independently.
This is SVN $Revision: 1598 $