NMRAnet

[The_Ghan]

Gentlemen,

 

I'd like to apologise for my recent outburst in this thread.  In particular, I'm referring to this post: http://www.jnsforum.com/index.php/topic,6972.msg72780.html#msg72780

 

This post was especially unfair to Don, with whom I'd had agreed via PM not to make further comment until he had a chance to respond to my earlier post here: http://www.jnsforum.com/index.php/topic,6972.msg72752.html#msg72752.  In posting a further reply, I broke our gentleman's agreement and Don's trust.  For that I'm truly sorry. 

 

I have implied that Don might be involved to benefit his own business and that covert negotiations were taking place.  Neither of these statements are correct.  I regret the hurt that I have caused Don and any damage I might have caused to his reputation.  While I have already apologised to Don in private, I make that apology again, in forum, without qualification.

 

I have also implied that there may be sinister or alterior motives behind the development of OpenLCB and NMRAnet. I have suggested that NMRA members might have reason for concern.   This is simply not the case and I apologise to all of you for misleading the forum.

 

David Harris dropped into the forum on the back of my earlier post with his own reply.  While it is fair to say that his post triggered mine, my tone and comments were still out of line and inappropriate and I apologise for that.

 

If there is any good to come out of all of this I'd like to say that Don and I are communicating freely and in a friendly manner.  I doubt either of us is getting much work done, but for me work can wait until this matter is set right.  I sincerely hope a better friendship arises out of this mess.  I think my mega post here: http://www.jnsforum.com/index.php/topic,6972.msg72817.html#msg72817 went part way towards explaining my position, but it should have come after my apology, and after Don's reply.  I'll submit that I was casting on the defensive here and so my tone remained terse.

 

One thing that I have raised with Don is the need for a forum Charter, Guidelines and House Rules.  I don't want to turn this into Watergate and we don't need volumes of rules.  But a couple of paragraphs and a handful of rules can go a long way towards reducing the chance of this kind of thing repeating.  Yesterday I learned that Don is the custodian of this forum.  In two years as a member, I never knew that.  This came about following a suggestion to identify Admin, Mods, Developers, Retailers, and Experts.  Unfortunately, the current forum doesn't permit us to put much by way of identity here, but I'm sure that will be remidied in the future.

 

Finally, to Don's credit, he hasn't deleted the thread, my posts, or even a single line of this thread.  I'm sure I have tested his resolve in this regard but it is the mark of a good Admin and a good man.  Thanks Don.  You have been a good sport about this, truly.  I note that Don has posted a reply to clarify his position in all of this.  Thanks for that.  I also see he wasted no time in getting back on topic and I look forward to continuing the NMRAnet and OpenLCB debate in this thread.  I might have a bit to say about LocoNet too.  I'll also kick off a topic or two in the appropriate section about forum Guidelines etc.

 

Don, I apologise again for frothing at the mouth and my inappropriate remarks earlier.

 

Best wishes and kind regards,

 

Nige'

[Guest Closed Account 1]

Ok so is it correct to refer to this open sorce tech as NmraNet?

 

I don't get it. No One has yet to make a node for N Gauge? How then are DC train controlled?

 

Why the hype and hysteria over something we are not being informed enough to understand?

[The_Ghan]

Skip,

 

My hysteria aside, I am beginning to understand what this is all about. 

 

A simple analogy: think of LocoNet and NMRAnet as cables behind your PC or Mac.  LocoNet is like the old grey printer cable ... it connects your PC to your printer and does a great job at that.  It will connect to any printer with the same plug and your PC will print to it.  If you have two or three printers and cables your PC can print to all.  But the limitation is it can only print to printers.  It can't talk to your smart phone, a mouse, a keyboard, etc.  Now, think of NMRAnet as a USB cable.  You can plug in lots of different devices, as well as printers.  Your PC will talk to them all.  They can store their own drivers on firmware and even the location for future updated drivers.  While the functionality is not the same, the leap in technology is similar.

 

I hope that helps a little.  I'll be asking plenty of questions about this technology over coming days myself.

 

Cheers

 

The_Ghan

[cteno4]

Web,

 

I don't look at this as something that is competing with dcc right now, but as a stab at creating a standard for a more universal mr device communication system where you can have all sort sof things talking with each other with a more robust buss and also providing much more low level support to this communication so at the user wont have to dink with the low level stuff to make all sots of future stuff to talk to each other. I dont think it's been under wraps as much as, like capt said, they haspd their head down trying to get the basics going. If you were into automation or an nmranet member this would be more on the radar I'm sure, but this kind of thing can't really be marketed big time until you have a good bit of work done on standards and some proof of concept or no one will pay attention (even with that you are not that wowed now with nmranet so you see the conundrum!)

 

While I'm not big into my model rr automation that much right now, I do see this as being a great new world when you can get all sorts of things easily talking to each other. I've done a lot of this sort of stuff over the last 25 years with exhibit stuff (av gear, interactive elements, set display stuff) and its always been tough. Either you did the hard work of figuring out a system yourself to talk to and control all the devices, or you drank the flavor aide and went with one brand's system (even many company's own brands would not interop) and hoped you did not find a whole that you could not fill/fix. This is why I'm now more excited by what the nmranet group is attempting here and my past exhibit experience is most likely why I have bee so gun shy of of getting into mr automation myself.

 

In theory you could have a nmranet box that could put out dcc communications via traditional dcc and at the same time use the nmranet buss to communicate with other nmranet boxes controlling points, relays, detection, displays, computers, mobile devices, etc to coordinate your overall layout. The ability to bridge the nmranet to other protocols like Ethernet and wireless opens up more options in the future!

 

Cheers,

 

Jeff

[kiwi64ajs]

Hi Guys,

 

New member - first Introduction post. Don told me there was a flurry of interest in NMRAnet on this forum so, I've come over to have a look and maybe contribute some thoughts.

 

First a bit about me, I live in New Zealand and have been interested in MRR since I was a kid and built a simple layout on two 8x4 sheets joined with a narrow section in between. I got back into MRR about 10 years ago after a friend told be all about what DCC was and I soon found out about LocoNet and the AVR micro-controllers and what all these things could do and I was soon hooked. I also found out about the JMRI project and got involved in writing the client/server networking support for LocoNet in JMRI. I've also done a lot of the development of the EmbeddedLocoNet, a bit for OpenDCC, both of which I've merged into Model Railroading for Arduino see http://mrrwa.org

 

I've been doing software development for over 20 years. Earlier on it was in Industrial Automation and control systems using mostly Allen-Bradley PLCs (now Rockwell) and Modicon PLCs (now Schneider) and a bunch of other weird devices, developing custom communications drivers for most of their interfaces and networks to talk to various Unix, VAX and Windows Systems - quite a mixed bag. Later on it we go involved in business ownership and became an Internet Service provider. In later years I'm involved more Web Development and business level software and managing larger Web Applications etc for our customers. Our company now employs about 40 people.

 

Over the years a number of people have been involved in on-going discussions about what a new Layout Control Bus (LCB) might do and various DIY projects started and achieved some things. However none of them really seemed like they were going to become or achieve a quantum leap over what is commonly available in the hobby now. LocoNet can actually do quite a bit, but the Digitrax product line seems to have grown in uneven directions as I suspect the bulk of their sales is still dominated by DCC decoders and related gear and the really interesting stuff is probably so much less by comparison that it just doesn't get the development it would need to take it to the next level. We've see the development of products from RR-Circuits and CML Electronics and others that is filling that niche anyway.

 

I quite like LocoNet and could easily live within it's capabilities but having a fatal attraction to cool technology and MRR, what has become OpenLCB seemed like an interesting project and I've gotten to know a bunch of cleaver guys who are all involved. I've been involved in OpenLCB since the beginning (and the previous lives and Yahoo groups etc) and am also a MERG member.

 

I've also been involved in the various NMRAnet Working Group attempts within the NMRA to produce NMRAnet. That is a whole other story (some of which is best forgotten) but I'm pretty confident with the latest arrangement whereby we have the OpenLCB group doing all the design, development and testing in a completely open way that anyone can join in and help with, and the NMRA is able to consider the designs and OpenLCB standard and adopt the ones it likes or work with the OpenLCB guys to tweak it a bit to get it right. We've recently managed to get the first set of documents through the process and be adopted which is actually a huge achievement if you've even been exposed to such a process.

 

The community of people involved in not that big and we've known each other for some time and have generally figured out how to work well together - but we do have our moments from time to time... However to pull-off such a lofty goal of producing a new LCB standard for the MRR Hobby is also a pretty big undertaking and still needs heaps of support and resources to really make it fly. So I'm always in the lookout for keen technical people who can help with such things and there's heaps they can be involved in. Having a technical writer and communications people would be a huge help right now. Also have people doing testing and proving using the DevKits would also help.

 

Anyway this has got pretty long so I'll quit now, but for those who care or are interested: I have no financial interest in anything OpenLCB or NMRAnet related or in any of the business entities interested in OpenLCB or NMRAnet. I'm a member of the NMRAnet working group and host & manage the http://nmranet.org website on their behalf for free.

 

Regards

 

Alex Shepherd

[CaptOblivious]

For my own part, I would like to apologize for being defensive, and taking offense so easily as I did. The_Ghan and I have been conversing quite a bit behind the scenes, and I think that we simply got our wires crossed somewhere. It's hard to recognize that situation when you're too busy being defensive: I am sorry for my part in this mess.

[CaptOblivious]

I've added this video to the post above with the clinic videos, but I think it is timely given the discussion here. This is my NMRAnet demo layout, which, among other things, demonstrates how NMRAnet and DCC can work together to drive a train. Bonus: The video features my beloved EF65-1034 and a string of コキ container cars.

 

Let me add that this video was originally meant as a bit of an advertisement for Railstars's products. I post it here in the hopes that it is informative.

 

[Martijn Meerts]

The cooling block on the booster looks like some strange modern/scifi building =)

[Guest Closed Account 1]

Yes DCC and NmraNet can coexist.

 

 

Untill my Ntrak club adopts NmraNet or other I will continue to use DCC.

[CaptOblivious]

Yes DCC and NmraNet can coexist.

 

 

Untill my Ntrak club adopts NmraNet or other I will continue to use DCC.

 

I've seen this video before, but I have no idea who made it, or what system they are using. I suspect it was one of the earlier competitors (NMRAnet originally had three candidate systems in competition, of which OpenLCB was one). I'd be interested in learning more about this system, as they seem to have made great strides with it. But whatever it is, I can assure you it is not based on OpenLCB / S-9.7.

[kiwi64ajs]

Hi Guys,

 

I've seen this video before, but I have no idea who made it, or what system they are using. I suspect it was one of the earlier competitors (NMRAnet originally had three candidate systems in competition, of which OpenLCB was one). I'd be interested in learning more about this system, as they seem to have made great strides with it. But whatever it is, I can assure you it is not based on OpenLCB / S-9.7.

 

I believe it is a French University - Student Engineering Project. If you follow the links in the video you'll find it ends up on a French person's channel - probably one of the students.

 

They had a certain amount of time to put together an implementation of a published protocol spec and they chose MRR and used Don Voss's S-9.5.x docs as they were several years ago that existed on the NMRA website for a while. We had exchanged some emails with them about their implementation, but they took some artistic license to fill in the gaps, but it served the purpose of their course - which they passed and moved on to other things...

 

It's certainly not S-9.7.x or the NMRAnet/OpenLCB that we are involved with now.

 

That's all I know.

 

Regards

 

Alex Shepherd

[disturbman]

Definitely French rolling-stock and speaking in another video of the same layout.

[The_Ghan]

Cap'n,

 

I'm going to ask a series of questions over the coming weeks of an inquiring and probing nature.  They are meant to draw out further explanation, in plain English, the new features that OpenLCB has over the currently available products so that all of us here can better understand what is in the pipeline. 

 

Here's a few for starters:

 

Issue 1:  Backward compatibility, cross-layout compatibility, and cross-platform:  

 

Background: If I take my train over to keitaro's place or Webskipper's club layout, I put it on the track, pick up a controller, and go.  At worst, I might have to set a new address.  This takes a minute or two.  Likewise, as we all use Digitrax we all enjoy the benefits of Transponding if the BDL168 and RX4 components are installed.  If I go to Martijn's place, my only limitation is that my Digitrax decoders don't have Railcom.  If Martijn brings a train to my place he doesn't have Transponding equipped decoders, but he is otherwise fully compatible with Digitrax. 

 

Questions: Can you describe the process if Skip or I bring our Digitrax trains to "John Doe's" (JD) imaginary OpenLCB layout in 5 years time.  What modules, components, etc, does JD need?  What setup is required on our arrival?  What would JD need to do to have our trains Transponding over Open LCB?  If Martijn joined us for a Shinkansen day, what else would need to happen? 

 

Reasons: Interoperability, cost, the fact that most of us with established investments just aren't going to chop and change.  But some might want to upgrade their network without having to change their trains.

 

 

Issue 2: Backward compatibility, using OpenLCB trains on a DCC layout.

 

Background: Now it is my turn to host the Shinkansen party.  Skip turns up, his trains just run ... we spend a few minutes changing addresses on his sexy new Dr Yellow and a couple of other bullets that Skip just can't leave home without.  Martijn turns up a few minutes later (his plane was late into Sydney) and we configure his trains too.  Ten minutes later his three shinkansen are all running, although the don't Transpond because he uses Lenz decoders, but at least my BDL168's are still registering his trains for occupancy detection.  Then JD arrives with a suite of gorgeous MA shinkansen equipped with the super-duper new OpenLCB decoders.  Instead of a dumb DCC address, these things actually report the whole train description, eg: 200-1500 Shinkansen and 300-3000 Shinkansen.  I let JD know that he can use the address range between 9200 and 9299

 

Questions: What does JD need to do to get his trains to work on my Digitrax layout?  What reprogramming needs to be done by JD? Did JD need to set anything up using his OpenLCB layout and controller before leaving home?  Can JD use my Digitrax throttle to program his OpenLCB decoder?

 

Reasons: Compatibility, ease of use.

 

 

Issue 3: What is NMRAnet again?

 

Background:

1.

NMRAnet is a set of emerging standards governing the communications channels between layout control devices. In other words, it is an effort to standardize the ways in which things like turnout controllers, block occupancy detectors, and so forth, talk to each other. The aim is to create an open-access freely-available set of standards that any manufacturer can use, to ensure the greatest degree of interoperability.

2.

Despite using LocoNet, every Digitrax product, with the exception of the RX Transponding products will work with any other popular manufacturer's DCC system.  Digitrax documentation even explains how to hook the products up.  Likewise, TCS, ESU and other products can be hooked up to a Digitrax system through the bus.  They don't get the benefits of of the LocoNet bus and Railcom components won't work.  This is because  Loconet, Transponding and Railcom are proprietary to their respective companies and licensees.

3.

Despite LocoNet being a proprietary Digitrax product, it is licensed to a number of other manufacturers.  My favourite is CML, who make great turnout controllers, signal controllers and panel animators for those of us who still prefer a LED panel over computer software to display the position of our trains on the layour.  Another is RR-Cirkits, who have a great signal decoder to handle all the signalling required for a passing siding.  But I especially like their little $13 board to control 4 signal head masts.  That's awesome.  All of these are compatible with all Digitrax products and LocoNet.  These other companies license LocoNet from Digitrax, yet their pricing is very competitive.

 

Questions: In paragraph 1 above you claim  that NMRAnet is an effort to standardise the industry.  Isn't there already a DCC standard?  Don't the examples from paragraphs 2 and 3 demonstrate the interoperability between different manufacturers products?  Isn't there already cooperation between manufacturers and healthy competition.  What exactly is NMRAnet trying to achieve beyond this in terms of standardization?  When the world happily lives with proprietary standards, like Dolby in the entertainment industry, why can't we accept similar proprietary standards in DCC?

 

Reasons: The lay-men among us don't quite get what it is all about at this level.

 

 

Issue 4: Migration and upgrading.  Knowing your competition.  The big "must have" carrot:

 

Background:  I don't accept that OpenLCB doesn't directly compete with DCC.  It certainly does if you can run trains using OpenLCB without DCC.  The good old DC transformer competed with DCC and with OpenLCB too.  They are all in the same market of controlling model trains.  30 years ago, only 10% of model railroaders were using a command control system and nearly 25% were using the Hornby Zero 1, many to control other brands of trains.  Today, most model railway enthusiasts around the world are still using DC controllers.  Many of those, such as the advanced Tomix controllers, are quite sophisticated with separate throttle and brake control, sound effects, turnout control and interior lighting control.  After 30 years more than 50% are still using DC throttles.  This is because it is cheap, easy, and simple to set up.  There are people still using the Zero 1, particularly in the UK and Australia.  In Japan, the DCC take-up has been incredibly slow.  Few manufacturers are interested.  Kato seems to be the exception and that may be because of their presence in the US and Europe.

 

Questions:  Can/will we use OpenLCB without DCC to control trains in the future?  Who are the major DCC players?  What percentage of the DCC market does each have (if you don't know, how can we find out)?  What is the "must have", irresistable carrot that will entice contemporary DCC users, legacy command control users, and DC throttle users to migrate across to OpenLCB?  In the year 2020 worldwide, what percentage of enthusiasts will use DC throttles, DCC, and NMRAnet standard products?

 

Reason: Technology is driven by fulfilling a need, or even better, creating a need, and filling it.  The evolution of BoomBox to WalkMan to Diskman to MP3 player is a case in point.  I've not seen a BoomBox on someone's shoulder for around 30 years.  I haven't seen someone using a WalkMan for 20 or a Diskman for 10-12.  We are yet to see how OpenLCB might fit into the landscape.  To answer the last of the questions: 1983 was 90% DC and 10% Command Control, 2011 was 53% (I think) DC to 47% DCC and I'm predicting that in 2020 worldwide it will be about 48% DC, 50% DCC and 2% OpenLCB/NMRAnet.  I'm not saying that to discredit the efforts of the people involved or the product itself.  I just think that you can't go wrong with the good old DC throttle and those of us who have chosen already to go DCC have invested a substantial amount of money.  That carrot has got to be pretty big, remember some people still use the Zero 1.  There are Zero 1 decoders for sale in the UK - new and unused.

 

I'll give you a bit of time to get through these and look forward to understanding things better.

 

Cheers

 

The_Ghan

 

Reasons:

[CaptOblivious]

Ghan, some excellent questions. You've really nailed some of the difficult questions that make the DCC bridge tricky. So my answers here are very preliminary, and reflect the way that I and the others thinking about traction control are currently conceiving of things. I'm going to re-order your questions to suit my dialectical needs, however.

 

Questions:  Can/will we use OpenLCB without DCC to control trains in the future?  Who are the major DCC players?  What percentage of the DCC market does each have (if you don't know, how can we find out)?  What is the "must have", irresistable carrot that will entice contemporary DCC users, legacy command control users, and DC throttle users to migrate across to OpenLCB?  In the year 2020 worldwide, what percentage of enthusiasts will use DC throttles, DCC, and NMRAnet standard products?

 

The answer depends on scale. I know of a few folks who are working on making direct OpenLCB control of HO and larger models a possibility in the very near future. But for smaller scales like N and Z, it is my belief that DCC is going to be around for a long time yet. The primary reason is that any form of direct OpenLCB control is pretty much going to require wireless technology: DCC has demonstrated that using the rails for both power and signal is very limiting in what you can achieve. But, a 2.4GHz antenna requires more room than can be had in most N scale trains, and far more room than will ever be available in Z. Processors capable of handling the OpenLCB stack are only just now becoming available in sufficiently small packages to fit in smaller decoders. I predict that for these reasons, it will be at least 10 years until we have the technology to fit a powerful, wireless equipped processor into the tiny spaces inside most N scale locos, if ever.

 

For HO and larger, however, direct control of trains is already here in some forms, albeit proprietary and expensive. We have the technology today to install OpenLCB wireless decoders into HO and larger trains. What remains is for a manufacturer with the resources and willingness to give it a shot. The carrot for end users should be obvious: throw a LiPo battery in, and you can eliminate every last bit of track wiring for ever and ever, amen. That's, to me, a pretty darn big carrot. Even without a battery, you only need to be able to throw 12V across the rails, without having to block anything out except reversing loops. That's considerably simplified wiring. That's still a nice sized carrot, I think. Nevermind that you gain very fine-grained control over various train FX (lights, sounds, animations, etc) vs. what DCC currently offers (analog whistles, for example, are a very bad hack laid over what is a system of binary functions; a hack most throttles cannot manage).

 

But I don't have any good idea about the relative percentages. I'm not going to speculate. I personally favor a broad spectrum approach: I'd rather see NMRAnet being made to work with all three technologies as best as each can manage. Obviously, each technology has its limits: DC is limited to one train per block, and no independent control of FX, but is dead simple as far as the trains go; DCC is what it is; direct NMRAnet requires beefier technology that doesn't seem likely to fit in smaller scales any time soon. But NMRAnet can accomodate all three.

 

Questions: In paragraph 1 above you claim  that NMRAnet is an effort to standardise the industry.  Isn't there already a DCC standard?  Don't the examples from paragraphs 2 and 3 demonstrate the interoperability between different manufacturers products?  Isn't there already cooperation between manufacturers and healthy competition.  What exactly is NMRAnet trying to achieve beyond this in terms of standardization?  When the world happily lives with proprietary standards, like Dolby in the entertainment industry, why can't we accept similar proprietary standards in DCC?

 

The examples you give of compatibility are very narrow in scope, and do not apply broadly. Can you find a LocoNet-based turnout controller that can also report turnout position over the Lenz feedback bus (forget what it's called, not XPressNet); How about an XpressNet throttle that works with NCE (despite the fact that NCE uses a sort of variant on XpressNet). I gaurantee that you can't use an RR-Cirkits LNCP with an EasyDCC system. You'll never find a RailCom detector for LocoNet, and forget using Transponding with something other than LocoNet. And little of this stuff works very well with straight DC. So, the instances of compatibility you offer are, I think, little more than red herrings. NMRAnet aims for something much, much broader.

 

That said, DCC is a standard, but it was designed for train control, and never really meant for accessory control. Accessory control was tacked on as a badly-conceived after thought which has been hacked to death by various manufacturers. It's a broken system that is extremely constrained in what it can do, and what kinds of future uses it can be put to. Nor does it offer any method of feedback, because DCC is a one-way stream. NMRAnet provides a far superior system for communicating with layout accessories that is bi-directional, and very rich in its vocabulary. It is also much easier to set up, as it does not demand that the user understand CVs and Switch Options, which in my opinion are extraordinarily arcane.

 

Finally, who says the hobby is happy with the proprietary standards we have? When what we have is a) comparatively limited in capability, b) doesn't offer real compatibility and c) provides tremendous barriers to entry for DIYers and small businesses? You do mention that LocoNet is technically available to license. When was the last license issued, do you know? There is Uhlenbrock in Europe, and CML and RR-Cirkits in the US. Who else? (I'm sure there are one or two more.) More importantly, how many small businesses do you see picking up licenses lately. Not many. This does not sound like a hobby happy with what it's been handed. Moreover, is it really genuine competition when it is one business that acts as the gatekeeper to the standard? Is that not why we have the NMRA in the first place, to hold these standards in trust for and in the interests of all hobbyists and manufacturers?

 

Questions: Can you describe the process if Skip or I bring our Digitrax trains to "John Doe's" (JD) imaginary OpenLCB layout in 5 years time.  What modules, components, etc, does JD need?  What setup is required on our arrival?  What would JD need to do to have our trains Transponding over Open LCB?  If Martijn joined us for a Shinkansen day, what else would need to happen?

 

Questions: What does JD need to do to get his trains to work on my Digitrax layout?  What reprogramming needs to be done by JD? Did JD need to set anything up using his OpenLCB layout and controller before leaving home?  Can JD use my Digitrax throttle to program his OpenLCB decoder?

 

These, to my mind, are the really interesting questions. And indeed, this is one area where we would love some immediate help in figuring out the best way forward.

 

What makes them complicated is this: Decoders can, obvious, store certain configuration withing them, in the CVs. But NMRAnet permits the storage of much more, such as a description (encoded in UTF-8, so Japanese characters are allowed), a full road number (so now I can use "EF65-1034" to refer to my beloved Kato loco, rather than the truncated and hardly unique "1034" that DCC allows in a 4-digit address), speed matching info, pictures, a unique NodeID, etc. Some of this information must be stored somewhere else—if you want to use it. If you don't, the problem is simpler.

 

Let's ignore the issue of the additional configuration stuff that NMRAnet permits. We have already set aside a range of NodeIDs for use specifically for DCC decoders, and we are working out a set of conventions for automatically accessing CV and Function settings from legacy DCC decoders without the need for additional configuration. So the idea is that, when your Good Old DCC train (GODCC) to JD's house, presuming that he has an NMRAnet-capable DCC command station (similar to the one in my video above), the process is quite simple. You would grab a throttle, enter the DCC address, if necessary indicate which command station it's running on (NMRAnet permits the use of multiple command stations; a necessity for groups like FREMO), and go. Easy-peasy. JD needs only the aforementioned command station. And of course his tracks must be wired to it. If he's running the aforementioned 100% wireless system (with no wires to the track), you're out of luck.

 

Now, let's suppose you do want all the fancy-schmancy stuff NMRAnet can give you. Our current idea is that you could purchase an inexpensive "DCC Roster" node that would store this information for a set number of trains. When you bring your GODCC trains to JDs, you can also plug in the module to his NMRAnet. Stick the train on the programming track, let it read the CVs, set up the other configuration options using the throttle, and assign it a permanent unique NodeID. Now you can take your trains to any DCC-compatible NMRAnet layout, along with your roster node, and your old-fashioned trains appear to the system just like any brand new NMRAnet-compatible trains. This is part of the picture we're still working on. A lot.

 

So, let's go the other way, then. JD brings his trains over. If his trains are DCC trains, he need only plop them on your layout. He might not know the DCC addresss (having possibly been automatically assigned by his fancy NMRAnet command station), but that's an easy problem to solve. He then drives it with your Digitrax throttle. If his trains are of the super-fancy wireless kind, he'd need to bring along his NMRAnet throttle to control them, but ostensibly the trains would either ignore the DCC voltage on the rails, or rectify it and simply use it for power, ignoring just the signal. In either case, JD need do nothing in advance to prepare for the visit, except remember to pack his throttle. Could he use your Digitrax throttle in this case? Technically yes. If Digitrax were to ever grant someone a license to build a LocoNet to NMRAnet bridge. This is technically possible, but legally nearly impossible, because you would have to convince Digitrax to license a technology that opens a giant doorway out of their gated garden. (Remember what I said before about allowing a commercial interest to control the standard? Suddenly certain kinds of technology—those contrary to the interests of the business—become illegal).

 

What do you think? Could any of this be streamlined, perhaps? Care to offer some opinion on the blending of DCC and NMRAnet technologies? As I've said above, I think that DCC is going to be with us for a very, very long time yet, and one of my priorities is ensuring that NMRAnet plays well with DCC without compromising future compatibility with more advanced control technologies.

[The_Ghan]

Cap'n,

 

Good, healthy start to the debate.  I'm currently at a loss as to the best way to process all this info in forum, so I'm splitting the issues into separate threads, appending to my previous post, but re-issuing it.  I know it's not a best-forum practice, but this is a very complex subject.  Look out for a separate topic on each issue, with new topics posted as issues arise.

 

Cheers

 

The_Ghan

[Hobby Dreamer]

Don / David / Alex

 

Thanks for your time and effort to make the modelling world better for users; and for taking the time to explain the new technology/standards here.

 

We are in a "Golden Age" when users can have their say towards the development of standards that will enhance our enjoyment and ensure compatibility with various vendors as well as backward compatibility. I know that each of you have devoted considerable time, effort, stress and expense for others in this hobby and I, for one, am grateful.

 

But the development of these new standards is not just a destination. Its about the journey as well. For the first time there is a hobby "Glasnost " where anyone can participate to ensure the end result is not skewed or biased towards specific interests. So its not just an open standard  but one developed with complete openness. Anyone who is motivated enough can contribute at almost any level.

 

Hobbies are first and foremost about fun, about meeting similarly-minded friends, about sharing ideas and the joy of being a kid again... 

 

But I am disappointed with the tone this thread has taken. Its the wrong medium and does appear to be an inquisition. If people are concerned about the standards, their direction or possible hidden agendas, or even about the credibility of those involved then perhaps it would be best to become actively involved themselves.

 

Don, its mid-Sunday but I hope you had a great weekend! IIRC you are a new father. Enjoy the fall with your child and don't worry about defending your work here. Its just a hobby forum.... 

 

Rick

[CaptOblivious]

If anyone is interested, the Model Railway Show interviewed me recently about NMRAnet. Probably nothing new in the podcast, but you might find it a different angle, anyway:

 

http://themodelrailwayshow.com/ShowNotes/?p=908

[Hobby Dreamer]

Thanks Don...  Good interview!

 

I think you explained the cascading effect of having a train enter a block and then affect signals etc very well, which helped me appreciate more having this new standard.

 

I also like your ideas for your own layout with the use of light and sound.

 

Cheers

Rick

[CaptOblivious]

And, NMRA members will notice page 38 of the November 2012 NMRA Magazine also has an article on NMRAnet…

[KenS]

Good article Don (and for those who don't get the magazine, the article is credited to Don; he's being a bit too humble here). You do a good job of converting programmer's standards-speak (producers/consumers) into terms railroaders should understand (sensors/actuators). And it's well placed to raise visibility among the membership. My only concern is that's it's still probably opaque to the average non-technical model railroader.  I don't think you could have done better in the space available, but what's missing is the "why should I care, can't I just do this with toggle switches?" part.  Plus, I expect many will have the "does this replace DCC?" confusion we saw here a couple of months ago.

 

For those who don't get the NMRA's magazine, the article is two pages, but more than half the space is taken up by photos from the demo at the convention (nice hat, Don!).  It doesn't say anything that hasn't already been said here, but it provides a semi-technical overview of how NMRAnet devices can sense control states (control panel button presses, etc) and signal remote devices to do things (throw a turnout). It also talks a bit about why "open" is good and how the system has potential for extensibility defined-in.

 

I'm a big fan of open licensing (my entire website's contents are Creative Commons licensed and I make a lot of use of Wikipedia and Flickr material that is similarly licensed). Particularly for small-volume products like model railroad control systems, getting license costs out of the equation is key to widespread implementation and adoption.

 

NMRAnet at heart is a very simple and powerful concept: an open-licensed control bus any manufacturer can implement.  As someone who likes Digitrax in large part due to their multivendor (but closed) control bus, LocoNet, I really see the value in that.  It's a pity I'm so deeply invested in Loconet at this point, or I'd definitely be playing with this. And I'm hopeful that in a few years we'll have a mature marketplace and I'll finally be able to invest in a "21st century" standards-based control system (I so really despise programming my command station by setting boolean flags with a turnout controller; JMRI is a step up, but hopefully this will lead to someone selling a nice GUI).

 

But to the average modeller, the fact that it does or will eventually do for things like turnouts, handheld throttles, signals, occupancy detectors, and even synchronized fast-clocks what the core DCC specs did for train control: eliminate the loom of wiring under the layout and enable new capabilities, may not be at all clear.

 

Hmm, I think I have the topic for my next blog post...

[CaptOblivious]

Thanks Ken for the summary and commentary. It was pretty tough to write an article that did everything it needed to in the space allotted. I know the NMRA Magazine intends to run more articles on NMRAnet; we definitely need to work on our entry-level-why-should-you-care pitch.

[KenS]

Having just gotten around to reading the new standard and tech note, what I'm wondering now is where the rest is. There's clearly an implication in your article about there being some organized way for devices to notify each other of events, and maybe that's in OpenLCB (I haven't dug that far). But who defines what event is a "turnout is thrown" event?  Is there an RP in the works, or another standard, or is that all being left to each manufacturer today?

 

I can see that some of this could be covered using the DCC protocols (using CVs and the Railcom protocols perhaps). And maybe OpenLCB alone is enough to signal "device X change state to state 1", although that leaves undefined if "1" should mean thrown or straight to a turnout. What you seem to be missing is what I'd call the "application" layer protocols (like what Digitrax defines in their LocoNet specification, which includes things such as sending time updates to a fast clock display). Something that says "this is how you throw a turnout" or "this is how you send speed and direction info from a handheld throttle to a command station" or "this is how you set a signal to aspect X".

 

And I don't see anything on the NMRAnet site about that; it's all focused on OpenLCB. Which is important (vital even), but to me it seems like a foundation that's missing its house, and there's no blueprints in sight.  What's the plan?

[CaptOblivious]

Having just gotten around to reading the new standard and tech note, what I'm wondering now is where the rest is. There's clearly an implication in your article about there being some organized way for devices to notify each other of events, and maybe that's in OpenLCB (I haven't dug that far). But who defines what event is a "turnout is thrown" event?  Is there an RP in the works, or another standard, or is that all being left to each manufacturer today?

 

We are taking it slow introducing the OpenLCB docs as NMRAnet standards. All the event protocol stuff is documented in OpenLCB documents. As to who defines what event is a turnout-thrown event—you the user do. Events are defined as an abstract number, and nothing more. That number has no further meaning until a device on the layout is programmed to use it, and then the number is given its meaning in virtue of what it is connecting up. So, to give an example, ex manufacturer a turnout motor might be pre-set to produce event reports X and Y on turnout-thrown and turnout-whatever-the-opposite-of-thrown events. In and of themselves, X and Y mean nothing. Indeed, you are free to overwrite X and Y with your own A and B if you like. X and Y get their meaning when you configure your fascia panel controller to consume event reports X and Y to trigger LED1 and LED2 to come on or off. Therein resides the meaning.

 

I can see that some of this could be covered using the DCC protocols (using CVs and the Railcom protocols perhaps).

 

Avoiding that whereever possible, as doing so would prevent NMRAnet from working with straight DC, or fancy-pants control schemes of the future.

 

And maybe OpenLCB alone is enough to signal "device X change state to state 1", although that leaves undefined if "1" should mean thrown or straight to a turnout. What you seem to be missing is what I'd call the "application" layer protocols (like what Digitrax defines in their LocoNet specification, which includes things such as sending time updates to a fast clock display). Something that says "this is how you throw a turnout" or "this is how you send speed and direction info from a handheld throttle to a command station" or "this is how you set a signal to aspect X".

 

That is what is really cool about NMRAnet—almost everything is handled by the Producer/Consumer Application Layer! See comments above. Also note that more complex activity such as train control, memory configuration, etc, does require their own protocols within the application layer, but let's hold off on discussing that now. Even fast clocks don't need anything beyond producer/consumer: The fast clock simply emits a pre-defined event report (there are a very small range of pre-defined events, and those definitions can only come from the OpenLCB group) every tick (I forget how fast a tick is here). Other items on the NMRAnet network can consume those event reports as any other—so you could trigger, for example, lighting changes at dusk and dawn, set an alarm, or simply display the fast clock.

 

And I don't see anything on the NMRAnet site about that; it's all focused on OpenLCB. Which is important (vital even), but to me it seems like a foundation that's missing its house, and there's no blueprints in sight.  What's the plan?

 

Very little has been formally adopted yet. For a complete listing and status of the various OpenLCB standards, see here:

http://www.openlcb.org/trunk/documents/OpenLCBDashboard.html

 

Those standards marked as complete, in particular the Glossary, General Information, CAN Data Link Layer docs, and CAN Message / Network Layer docs will be submitted to the NMRAnet working group for formal adoption very soon, to be followed as quickly as possible by the Event Transport and Datagram Transport, and the items listed in the Application Layer, all of which are necessary for proper operation of the NMRAnet.

 

Aside from the docs, we now have two solid implementations, which we use as a testbed for the documentation, (one of which is my own OpenLCB library) both of which implement everything listed except the Stream Transport—for which we haven't yet found a need, reservation—which we haven't hashed out yet, and remote button—for which we aren't sure if there is a need.

 

So, don't be disheartened by the lack of documents on the NMRAnet website. The ball has only been officially rolling for a few months now, and the head of steam behind it is much larger than it appears. Indeed, the main reason for the articles and interviews and whatnot has been to make that head of steam manifest, by talking about what's going on beyond S/TN-9.7.1 and what's in the pipeline!