# NMRA selects new layout control bus



## Chip (Feb 11, 2008)

" 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. 
" NMRA Mag October 2011 pp 50-52

openlcb.org has more info.
Chip


----------



## Chip (Feb 11, 2008)

Correspondence from August 3rd 2011 with OpenLCB team member:

Hi Chip --

Yes, RF is certainly contemplated, although we have a ways to go there. Note that the RJ45 stuff is referring to CAN (ie a wired bus). We also define a more generic protocol (of which the CAN is an adaptation) which matches Ethernet quite well. We expect that XBee and other off-the-shelf RF should be integrated into OpenLCB using similar adaptations to the protocols. 


We would love to hear what you would like in that regard. 


David


On Wed, Aug 3, 2011 at 6:34 PM, Chip wrote:
David:
New to your forum. Garden RRer. Long time JRMI/sprog user for programming. Massoth system, 8 amps,

track powered; wireless controller to central station. DCC controlled turnouts, loco-uncouplers, 

animations, etc.

In the OpenLCB-CAN Physical Layer Jul 24, 2011 documentation, it states:
CAN connections between nodes shall be made using UTP cable. There shall be a RJ45 plug on the cable and RJ45 jack on the node unless the cable is permanently attached to the node. 

Is OpenLCB allowing for a wireless bus (not just controllers to bus as in the Ian H 7/12/2011 doc) for battery-powered locos? 

Thanks! 


Chip


----------



## openlcb2 (Nov 9, 2011)

@import url(http://www.mylargescale.com/Provide...ad.ashx?type=style&file=SyntaxHighlighter.css);@import url(/providers/htmleditorproviders/cehtmleditorprovider/dnngeneral.css); Hi- 

The Physical Layer document applies to CAN. OpenLCB is meant to run on multiple transports, including CAN and Ethernet, so yes, it allows for a wireless connection and batteries. This is likely to be via XBee type devices and 802.15.4 . 

David


----------



## VictorSpear (Oct 19, 2011)

I'm wondering whether the working group considered the I2C protocol inclusion/exclusion merits for supporting closer proximity static device control (switches, signals) thoroughly prior or during the winter BOD meeting. The I2C protocol has been license free since 2006 and several manufacturers are incorporating the CAN/I2C support on their multi-function controller boards. There are more MCUs available with I2C built-in than CAN and supporting 3-4 Mbit baud rates. If the I2C was excluded, it would be good to know the exact reasons why and not so much about the merits/demerits of CAN vs I2C..

In the aging DCC model with 'Fire and Forget' methods of communicating using the track as the data bus-and-the power bus (with its intrinsic problems on old, soldered/clamped, constantly oxidizing track) the feedback (or lack thereof) problems were patiently borne by the community. If feedback and error correction (CRC generation, error retries, resending due to loss of arbitration) are being addressed through CAN (like OpenLCB or other) , we may remember that CAN was introduced in 1983 (Bosch) as a means of allowing microcontrollers and other devices to communicate with feedback without a host computer. That was 28 years ago. 

It's good to know that one of the Goals and Measures declared was:
*No Central Control *¶

Goal: Products can interact with other products without the need for a central processor.

Measure: Once a layout is set up, it should run perfectly and completely *without a central processing system* for basic and advanced functionality.

It also declares: 


"Maximum utilization of* existing globally standardized communication technologies *
should be used to develop this bus. Multiple forms of communication transport shall 
co-exist. Generic implementations to enable all forms of communication shall not be 
required if it greatly impacts the size/cost/complexity of the solution. Defining 
communication technologies is beyond the scope of this WG...."


So it would be good to know what was all considered and then rejected in the first place.

For example : I2C ESCs are gaining traction and popularity in robotic applications. Ignoring the protocol will be more than expensive. 

(And I think in the earlier post OpenLCB really meant "Zigbee" - the standard - as opposed to "Xbee" - the implementation)

Cheers
Victor


----------



## openlcb2 (Nov 9, 2011)

@import url(http://www.mylargescale.com/Provide...ad.ashx?type=style&file=SyntaxHighlighter.css);@import url(/providers/htmleditorproviders/cehtmleditorprovider/dnngeneral.css); 
Victor, see below ... 

Posted By VictorSpear on 09 Nov 2011 09:42 AM I'm wondering whether the working group considered the I2C protocol inclusion/exclusion merits for supporting closer proximity static device control (switches, signals) thoroughly prior or during the winter BOD meeting. The I2C protocol has been license free since 2006 and several manufacturers are incorporating the CAN/I2C support on their multi-function controller boards. There are more MCUs available with I2C built-in than CAN and supporting 3-4 Mbit baud rates. If the I2C was excluded, it would be good to know the exact reasons why and not so much about the merits/demerits of CAN vs I2C..>> Hi Victor --My understanding is that I2C is really designed for local application, specifically as an interconnects on circuits boards, while CAN is designed for noisy environments, with built-in error correction etc. While this is true, I do not see any reason why I2C cannot be adapted to run the protocols. The specific way to do this hasn't been specified. In the aging DCC model with 'Fire and Forget' methods of communicating using the track as the data bus-and-the power bus (with its intrinsic problems on old, soldered/clamped, constantly oxidizing track) the feedback (or lack thereof) problems were patiently borne by the community. If feedback and error correction (CRC generation, error retries, resending due to loss of arbitration) are being addressed through CAN (like OpenLCB or other) , we may remember that CAN was introduced in 1983 (Bosch) as a means of allowing microcontrollers and other devices to communicate with feedback without a host computer. That was 28 years ago.>> Right on here. It's good to know that one of the Goals and Measures declared was:











*No Central Control *¶

Goal: Products can interact with other products without the need for a central processor.

Measure: Once a layout is set up, it should run perfectly and completely *without a central processing system* for basic and advanced functionality.

>> Yes, the goals do not force you to use a central processor, but they also do not prevent you from using one. If you look at the use cases, which span from very small layouts to huge, conglomerate layouts, you will see that at the smallest sizes central processors may never be used, middle size layouts might use them for set-up and debugging, while large layout might also use them for operations. 

It also declares: 


"Maximum utilization of* existing globally standardized communication technologies *
should be used to develop this bus. Multiple forms of communication transport shall 
co-exist. Generic implementations to enable all forms of communication shall not be 
required if it greatly impacts the size/cost/complexity of the solution. Defining 
communication technologies is beyond the scope of this WG...."


So it would be good to know what was all considered and then rejected in the first place.

>> Nothing was rejected -- if you can get it to run on two tim cans and a piece of string, more power to you ;-) . 

For example : I2C ESCs are gaining traction and popularity in robotic applications. Ignoring the protocol will be more than expensive.

>> Perfectly viable transport  

(And I think in the earlier post OpenLCB really meant "Zigbee" - the standard - as opposed to "Xbee" - the implementation)

Cheers
Victor 


>> Yes, well, I wrote off the top of my head. Essentially, it will be easier and less work to use an existing commercial effort, than to design from scratch. 

David


----------



## VictorSpear (Oct 19, 2011)

Yes, the 400pF capacitance threshold was overcome a while ago. Distances around 500m to 1000m are not uncommon 
(Use an I²C-bus extender to add high drive to any
I²C-bus. Guidelines (80 pF per meter) for 400 kHz 
are at least 20m and for 30 kHz are at least 1000m)

Rather than deviate to the I2C, RF sidings... if we stay on the mainline for the thread, what are the boundary constraints of the 'new' bus layout ? The NMRA offers no Search on their site for anything (coming within 10 years ?)... 
*Bus Length according to ISO-11898*
The usable physical distance in a CAN network depends, first of all, on the applied baud rate as shown in the table below.
*Baud Rate [kbits/sec]* *Distance
[m]* *Distance
[ft]* 1000 30 150 500 100 300 250 250 750 125 500 1500 62.5 1000 3000 



Is something like 3000 feet sufficient for the NMRAs adoption ? This implies the use of CAN repeaters or CAN-to-XXX gateways would need to be used to extend the footprint? With repeaters the dilution of bit monitoring is known. 
Then the question is do you see the bus allowing us to get something like this : http://www.youtube.com/watch?v=X9IlPDOar7E&feature=related ... where intermodal communication is visible (Air..road...rail...).
Do they have track - yes - you just don't see it
Do they have sidings and turnouts - yes
Do they have collision control - yes
Do they have device to device communication - yes
Do they have process to process feedback - yes
....
.... 


Cheers
Victor


----------



## openlcb2 (Nov 9, 2011)

Victor -- 

Great questions - you have obviously some experience around the issues and put thought into it. 

There are other things limiting length of a bus, and the tables are a little misleading as they state maximum lengths based on specific items. OVerall bus length is limited by many factors at once, including bus drive, bus loading, refections, bus topology etc. So the 300 m at 125 kb for CAN is only achievable with very few nodes, and the achievable bus length decreases with each added node. However, this is not limiting, since one can use other methods to extend the bus, as you suggested. The 125 kb for CAN was chosen as it gives a healthy single bus size that should be adequate for very many home layouts. 

There is also support for larger layouts, for example museum layouts such as you mention, but more specifically large aggregate layouts such as modular group. Fremo AmericaN is such a group, see: http://sourceforge.net/apps/trac/nmranet/attachment/wiki/GaM/Expandable/Freemo.jpg. See the Use Cases document for examples of the range that is to be covered. As such, larger layouts will need to have more than one bus segment. The overall plan is to have a fast 'backbone' bus, employing ethernet, with bridges to more local bus segments built with CAN, or even I2C. This allows simple one segment layouts that can grow as necessary to very large layouts. The protocols are designed with this in mind, with automatic filtering between segments. 

As Standards are adopted by the NMRA, they will appear on their website. More information is available in the OpenLCB website: www.openlcb.org. OpenLCB is a family of inter-digitated protocols. The Consumer-Producer model is used in which 'events' are used to send information between one or more producer nodes to one or more consumer nodes. Very large IDs are used for both nodes and events. IDs are assigned to each node at manufacture in a manner that ensures that they are thus globally unique. The upshot is that the user does not need to assign, store, remember or even know ID numbers. In addition, the large event space means that each node can produce unique events, events can contain legacy bus messages, clubs and groups can define specific protocol events, and users do not need to worry about conflicting IDs. There are other protocols defined such as Datagrams for larger sized node-to-node communication, Streams for continuous node-to-node communication, Configuration, etc. 

Finally, openlcb is a volunteer open development .... as such there is not the funding level that has obviously been spent on the professional example that you give - it would be nice to see more details of their implementation, do you have a link? However, that sized layout is certainly contemplated by the development group, and the protocols are designed with this in mind, as evidenced by the large IDs, multiple transports, and protocol design. 

Openlcb is looking for individuals to help with this development, and invites you to help out with this exciting development. It has been implemented on several platforms, including Arduinos, and hardware and code is available. 

David


----------



## VictorSpear (Oct 19, 2011)

I've started browsing for the referenced S-9.6.X assets. Search Results on the NMRA.org site for S-9.6.1 turned in zero results. I cannot even find the public comment open/closed period dates for this initiative series on the NMRA site. The TRAC at http://sourceforge.net/apps/trac/nmranet/wiki/S96Main indicates "Currently, much of the documentation is on a separate SVN repository, but it will be moving to this SourceForge project shortly."
There is one (1) active ticket opened in Aug 09 - so I'm probably in the wrong location. After some digging I did find the old S-9.5 here
http://www.nmra.org/standards/sandrp/pdf/S-9.5.1_2010.05.17_DRAFT.pdf. 

I'll spend more time on the OpenLcb.Org site instead which does have a lot more of the desired transparency and with associated Y-groups.


Knuffingen's project took a two year planning period and a four year implementation period, costing over 3 million euros. Some more info here: http://www.youtube.com/watch?v=Wti4ySW3TGs&feature=related where you can see the full Command-and-control operation in the basement. A good example would be Wheels Up to Wheels Down operations matched to the precise arrival times: http://www.youtube.com/watch?v=9l4l0Jq6LUY&feature=related ._ "It would be of no use if the Meals Truck arrived at the feeding ramp and the plane or train has already departed with hungry passengers (Process to Process communications)". 
_ 

Cheers
Victor


----------



## openlcb2 (Nov 9, 2011)

Itsallgood. Are you really worried? We embrace your old wiring. Just use the new stuff on new additions, keep the old... unless you don't like it! Totally up to you -- your the boss, CEO, chief bottle-washer ---- who better to decide? 

 David


----------

