The NMRA Standards Effort and its Relation to OpenLCB
2013.01.26 Update: The NMRA BOD passed more Standards and TN documents at their winter meeting in Grand Rapids, at the 2012 NMRA National Convention. Minutes are available here: NMRA Board Minutes.
63) CAND moved MBOD12072818 to approve adoption of NMRA Net Standard 9.7.1 as presented by the NMRA Net Working Group, and presented by Working Group members Brian Barnt, David Harris and Karl Kobel. The revision removes the calculation of recommended network physical length from the Standard and moves it to the technical notes. Motion seconded by ADD, and passed on voice vote. This motion replaces the previously approved Provisional Standard 9.7 passed at the 2012 Mid Year in Las Vegas.
A OpenLCB/NMRAnet Development Kit was developed and distributed to approximately 20 modelers around the world. These included three Io nodes from Railstars, and a CANUSB adapter from TCH Technology. It was funded through private donations and the NMRA.
The group's progress can be followed on our Dashboard, and we have made good progress on the documentation, and a near complete set of the basic protocols, including Event, Datagrams, Streams will be ready for review and presentation to the Board Meeting at this years National Convention in Atlanta.
2011.12.30 Update: The NMRA BOD Minutes have not yet been published. However an extract of these was published in the NMRA Magazine, in the October 2011 issue, pp 50-52:
NMRANET standard adopted
The board heard updated presentations for two versions of the definition
of the physical layer of the layout control bus called NMRANET.
In a change from its position at the winter BOD meeting, the Board selected
S-9.6.1, but the final approval must await Board review of the final wording
of the new Standard.
The Board thanked the developers of both versions, which were led by Don
Voss and Bob Jacobsen. They and their teams contributed countless hours of
development work toward NMRANET, and Digital Command Control users as well
as the model railroad industry as a whole will greatly benefit from their
efforts. Several manufacturers have been waiting for this new Standard so
they can adopt it for their product lines.
In addition, Stephen Priest commented in Observation Car, in the November 2011 issue:
Train Hibernation Time
....
Changing gears a little, I want to thank the members of the NMRANet team that
I am privileged to be working with. The BOD had enough faith in me to make me
co-chair with Karl Kobel of the NMRANet working group. We are tasked with
taking the working groups drafts, concerns and progress to the board. For those
wondering what in the world I am talking about, NMRANet is a communications
protocol (system) that can be used to control most non-train devices on your
model railroad. The idea is to split off turnout control, signal operations,
and the like onto a separate bus to free up train control and onboard sound.
Currently identified as Standard 9.7, this is an ongoing open effort to pool
resources, minds, and ideas. The working group creates documents that are then
approved by the BOD as Standards and Recommended Practices. This cooperation is
occuring between NMRA and the OpenLCB group. The effort is being driven by
people who have been involved academically and professionally in designing
networks that are intended to scale and intended to be flexible enough to serve
for many years to come.
The NMRA has agreed to support the purchase of some development /
demonstration nodes, and this is in progress. In addition, some
articles are planned to be submitted to the NMRA magazine around this
topic.
Update: This page was originally about NMRA's S9.5.1 Standard, which was an unauthorized modification of some work done by an NMRAnet working group based on the OpenLCB physical layer documentation. We wrote the 2nd part of this page, below the line, shortly after the NMRA Board adopted S9.5.1 in February 2011.
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. We hope to see demonstrated progress by Fall 2011.
In February 2011, the NMRA adopted Standard S9.5.1 for the CAN physical layer of their “NMRAnet” effort. This was based on the OpenLCB physical layer specification and technical note, but the NMRA made significant modifications to the CAN part of the specification. Four of us (JD, DH, BJ and AS) worked on those OpenLCB documents. We think that the NMRA's decision was a serious error. We want people to know about this situation so that when things eventually go seriously wrong, the rest of the communities developing CAN-based layout control buses won't be discredited by the inevitable results of the NMRA's poorly-considered decision.
Briefly, the NMRA has adopted an S9.5.1 Standard that cannot perform as promised. The NMRA's new NMRAnet S9.5.1 Physical Layer Standard is based on specific modifications to the international CAN standard to get “extended performance”. Layouts built using this NMRAnet specification will be unable to live up to those promises for “extended performance”.
Di Voss, in his role as NMRA Standards and Conformance Department Manager, has decided on an approach to NMRAnet protocols that does not have strong capabilities for handling more than one CAN segment. This motivates him to find ways to put as many nodes as possible on a single CAN segment, so that only one segment is needed. (The Voss NMRAnet effort has not discussed a solution for connecting smart phones and other devices that do not have native CAN interfaces) There are multiple technical issues that effect how big a CAN segment can be, and the international CAN standard has addressed these in a balanced way. Di's brother Don Voss has used information from two vendor notes (out of the huge number available for CAN; see e.g the list of 18 in the OpenLCB Technical Note on this topic) to devise changes to the CAN standard that address just one of these limitations. From this, the Voss brothers conclude that a much larger number of nodes can be supported on a segment, as shown in the formula and Figure 1 in the NMRA's S9.5.1 Standard.
OpenLCB developers with years of CAN experience disagree with the Voss brothers' simplistic analysis. The Voss changes to the CAN specification make promises that cannot be kept, because these “extensions” to CAN have only addressed one of the many issues involved in supporting longer CAN segments with a larger number of nodes. This has been explained repeatedly to them in significant detail, [1] [2] and those interested in the technical issues can get more information from those notes.
By imposing “extensions” to the international CAN standard, the NMRA Standard makes existing commercial CAN hardware non-conforming, which model railroaders will understand to mean that they can't use them. This restricts hobbyist choices, and channels their purchases to vendors selected by the Voss brothers.
NMRAnet-conforming hardware will work reasonably well on short CAN segments with a few nodes. Longer segments may work better or worse, depending on whether NMRAnets specified power and termination methods work better or worse than the CAN standards. Where the results are most problematic is where the CAN segment is longer and has more nodes than the OpenLCB recommendations, but still within the NMRAnet recommendations. Those segments will sometimes work reliably, but since they have greatly reduced margins, there will be other circumstances where the segment does not work reliably. When this happens, the blame should be placed firmly at the feet of the Voss brothers and the NMRA for blindly backing them.
How did we get to this undesirable situation?
At the 2007 Detroit NMRA convention, several groups working on a new approaches to a "Layout Control Bus" got together for discussion. Don Voss was working on an RS-485 approach, a few other people were working on another RS-485 approach, and several people were developing CAN-based solutions. Di Voss enlisted John Socha-Leialoha to develop some measures of success was eventually generally accepted by everybody except Don Voss. Don felt that the criteria were too far-reaching, and covered items that he felt were not important.
An NMRAnet discussion and working group was established under the leadership of Edward Richards. That discussion went well, with some significant technical progress, until Di Voss decided to fire Edward Richards so that he could install his brother in charge of the effort. Di Voss's post doing this can be found here; note that his description of Don's qualifications is substantially at variance with the subsequent facts, including failing to mention that Don had not even read the CAN specification at that point, let alone had any experience designing CAN systems. Under Don Voss, the effort collapsed completely. Over a couple months, a vibrant group that had been making progress, had made decisions and created prototypes, lost members and enthusiasm. The effort decayed away, as can be seen in its message totals. Don's behavior as group manager grew abusive and threatened to split the group into two. Di Voss put Alex Shepherd in charge of the group in August, and asked for two separate proposals, with Don's called S9.5 and the OpenLCB effort renamed to S9.6 for the NMRA. Di said both proposals would get an even-handed evaluation by a neutral panel, but Di never convened the panel. It became clear that Di was only listening to Don, and Don's behavior was becoming increasingly arbitrary. After repeated requests for an open comparison, Di did call for demonstrations at the 2009 NMRA convention, and the S9.6/OpenLCB group made arrangements for several people to travel there, but Di cancelled that event two days before it was to happen.
In the Spring of 2010, Di arranged for Don's S9.5 specification to be listed on the NMRA web site as the choice for NMRAnet, with no consideration of the other efforts. Di also wrote an article in the June 2010 Scale Rails that described only Don's proposal for NMRAnet, and included false statements about the work & contributions of other people. David Harris wrote an article for Scale Rails that covered the S9.6/OpenLCB effort, but Di refused to allow it to be published.
All of this was far from treating the efforts on an even-handed basis, and showed clear preference for the work of Di's brother, even though it was much less complete than other efforts. A number of people protested this bias on Di's part, and he agreed to host an event at the Summer 2010 NMRA Convention in Milwaukee where all proposals would be "fairly considered". There were displays and presentations by OpenLCB, MERG CBUS, AT Bus, and Don's S9.5 effort (though Don threatened one OpenLCB organizer that he would "have my brother throw you out of the convention" when asked questions). Unfortunately, Di never even visited the S9.6/OpenLCB, MERG CBUS or AT Bus demos, though he did manage to spend an hour at the S9.5 demo. He made no effort to make a fair comparison, nor did he enlist anybody else to make one.
Naively, and despite all this evidence, several of us thought there was value in a consensus NMRAnet specification, at least to the extent possible. In particular, John Day thought that he could work with Don Voss and others to craft a common physical layer specification that would let manufacturers provide circuit boards that could be used for many different functions with suitable software. Karl Kobel agreed to chair a group to do that, and the group was established by Di Voss with the goal of sending him a proposal in Fall 2010. There were active discussions in August and September, including detailed negotiations over what should be in the final document. Don Voss took part, as did others. Many people, including Don and the authors of this note, made suggestions that were accepted, and other suggestions that were not accepted. The final documents (draft standard and technical note) were written by the four of us based on the discussions, edited and revised through multiple rounds of additional discussions, voted on and forwarded by Karl Kobel to Di Voss.
Imagine our surprise when, with literally no notice from Di, the drafts that were published on the NMRA web site were not the ones that had been voted on. Several features that Don had championed, but that had been unanimously rejected by the rest of the group, had been inserted by his brother Di before Di published it.
We've covered technical reasons for objecting to those in the section above; we also believe that there are significant process and fair play problems with this outcome. We documented those in a letter to the NMRA Board but it was to no avail: The Board accepted a deeply flawed recommendation by Di Voss in his role as Standards and Conformance Department Manager, choosing to overlook a conflict of interest that was clearly unfair and explicitly forbidden by the NMRA's own manual of procedures (see section C 4.1).
And the NMRA wonders why it's hard to find qualified volunteers...
From this experience, we conclude that there is little point in trying to align the OpenLCB efforts with the NMRA's process for developing NMRAnet Standards. We may revisit this decision later on, but for now, we wish the NMRA luck in its efforts, and we remind the model railroading community that OpenLCB actually works.
There are some specific points in conclusion:
The OpenLCB group will continue to do good work, developing useful capabilities in a professional manner. OpenLCB nodes will meet their performance specifications.
NMRAnet will be what it is, developed as the NMRA wants.
Hardware that conforms to the NMRA S9.5.1 Standard will be able to operate with OpenLCB nodes if OpenLCB software is available for it, and the hardware isn't limited in other ways. When operating like this, the NMRA-conforming hardware will fulfill OpenLCB performance expectations.
Hardware that conforms to the OpenLCB physical layer specification may or may not conform to the NMRA S9.5.1 Standard depending on choices by the designer. We expect that most custom-designed model railroad boards will. We expect that many commercial products that are usable as OpenLCB nodes will not conform to the NMRA S9.5.1 Standard due to driver and termination choices.
This is SVN $Revision: 4143 $