NMRAnet - Issue 3: What is NMRAnet again?

[The_Ghan]

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.

 

Cheers,

 

The_Ghan

[The_Ghan]

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?

 

[The_Ghan]

Cap'n,

 

Of course the Digitrax and Lenz stationary decoders will not operate on each others proprietary bus.  In fact, I don't even think the Lenz LS100 and LS150 even use the Lenz XpressNet bus.  But, if I buy a Digitrax stationary decoder I can still wire it up to the rails and use it with a Lenz command station and vice-versa.  But this thread is not about DCC, it's about NMRAnet and OpenLCB and the question relates standardization, which you heralded as one reason for the development of OpenLCB nd the standard.  I submit that we already have that standard with the NMRA DCC standard.  Any turnout controller can be wired up to work with any brand of command station.  So I don't see how your comments answer the question.  Can I do that with OpenLCB?  Can I just buy a Lenz LS150 and the very flexible Team DCC SIC24AD, hook them both up to OpenLCB, set a couple of addresses and have them just work, like they do if you add them to a Digitrax system?

 

So far, the two proprietary DCC features that have come to light are these:

1. Bi-directional communications: Digitrax Transponding and Lenz Railcom/RailcomPlus;

2. Independent bus: Lenz XpressNet and Digitrax LocoNet;

 

Both of these brands are market leaders.  Both have great IP.  Both have the IP available for licensing.  Both have licensees of each product.  The world seems to be functioning happily.  The two brand names keep cropping up like Coke and Pepsi, or iPhone and Galaxy.  Yet, I don't see a standard for cola.  I don't see a standard for smart phones.  If either were to exist, my guess is that it would embrace both competitors equally.  Why is the NMRAnet standard not doing the same?

 

...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...

 

I thought Railcom and Transponding were bi-directional.  They both appear to be able to report "who" they are back to the command station, even if this does rely on a proprietary bus.  OpenLCB is yet another bus.  RailcomPlus extends what that bus can do.  Someone running live steam can have a RailcomPlus equipped decoder report back how much oil, water, or steam the loco has left.  Apparently such a decoder can store the loco's "home" location so that it can automatically return to be refueled.  I've not trolled through the entire documentation, but I think it is also capable of reporting boiler pressure and the like if the loco is equipped with the necessary sensors.

 

Accepting the proposition that OpenLCB is superior and richer in vocabulary, I'm still not seeing what this is going to do for us end users (I was going to say "consumer" but would only confuse the issue ...  ).

 

I agree that CV values are arcane.  I'm surprised that manufacturers haven't enhanced their throttles to get around this.  I'm stunned that after 20 years we have to calculate the values of two separate CVs in order to set a single 4 digit address.  I dare say this would be one of the biggest stumbling blocks in getting people to move across from DC to DCC.  In fact, we can even add this "carrot" to Issue 4.

 

With regard to other LocoNet licensees, Team DCC, Tam Valley Depot and TrainController are three more that come to mind.  Perhaps if you list a few things that can't be automated with DCC.  I just don't see what I'm missing out on here.  Perhaps it's a bit like chocolate, which looks like poo until you taste it ...  ... I've seen your demo video posted recently, for example, and just didn't get what it was you were trying to demonstrate beyond what DCC can do. 

 

Contrary to your proposition, I think the market is overall satisfied with what is on offer in the DCC world.  There are hundreds of DCC themed blogs and pages out there on the net.  I got some of my early support from a US HO gauge site.  There's plenty of space for small companies like NGDCC and Railstars, and there's quite a few players of your size out there already. 

 

Cheers

 

The_Ghan

[CaptOblivious]

1) You can't do any kind of turnout position feedback—one of the key features of my demo—over DCC, even with Transponding or RailCom.

 

2) You can't use DCC accessory decoders on any non-DCC (DC, Selectrix) layout.

 

Forget DCC. That's a red herring in this discussion.

[The_Ghan]

Cap'n,

 

This topic is about the aims outlined in your quote at the start of this thread, which I'm still hoping you can make clearer to me.

 

The point of your latest comment is unclear to me, but I look forward to seeing a LocoLCB turnout running on a DC layout and offer the following comments:

 

1.  I thought the Digitrax DS64 does turnout feedback when combined with occupancy detection (BD4, for instance) and power routing turnouts.  I believe both the Kato and Tomix turnouts are power routing.

 

2.  Actually, as the Digitrax DS64 has switch inputs, it should technically work on a DC layout anyway.  For what it's worth, the CTI Train Brain stuff has been doing it for years.  If that isn't what you meant then please let me know.

 

Cheers

 

The_Ghan

[Martijn Meerts]

Actually, you can do turnout position feedback using a DCC system, but the same system would work for any protocol.

 

What does one consider turnout position feedback though? Just a decoder telling the command station which position a turnout is in? Because in that case, it's not reliable. To get real turnout position feedback, you'll need either some microswitches hooked up the the blades of the turnout, or some sort of visual detection that makes sure the blades of a turnout are in a certain position.

[The_Ghan]

Actually, you can do turnout position feedback using a DCC system, but the same system would work for any protocol.

 

What does one consider turnout position feedback though? Just a decoder telling the command station which position a turnout is in? Because in that case, it's not reliable. To get real turnout position feedback, you'll need either some microswitches hooked up the the blades of the turnout, or some sort of visual detection that makes sure the blades of a turnout are in a certain position.

 

 

Martijn,

 

You are correct.  That is what I was trying to describe in point 1 above.  I believe you use Lenz and I'm sure there is a way to do this with their shelf components. 

 

In plain english with Digitrax components, because that's all I really know:  You need three things:

 

1. The DS64, a stationary decoder that handles 4 turnouts, routing and has inputs for panel switches or block detection.  It is also LocoNet equipped;

 

2. The BD4, an occupancy detection module with 4 sections which can report back to the DS64;

 

3. A power routing turnout, such as the Tomix or Kato turnouts.

 

Use an insulating connector so that the short piece of rail on one side of the turnout, that is, the same rail as divided into blocks around the layout, is isolated from the adjoining piece of track.  With the power routing turnouts, when the turnout is set in the other position, that piece of rail will be dead.  Note, you only need to do this for one branch of a Y, L, or R turnout because we presume the turnout is in the other state when we don't get feedback, because the piece of rail will be dead, without power. 

 

Next, wire the BD4 so that one of the sections is actually the stub that we've isolated, which is dead when there is no power at all.  Connect the 10-wire ribbon between the BD4 and DS64 as shown in the DS64 manual. 

 

Then, enable the sensing capability of the DS64 by setting Option Switch 13 to "closed".

 

Now, whenever the the switch is thrown (in either direction) the power will be routed to and from the isolated rail.  The BD4 will sense this and report "High" or "Low" back to the DS64.  The DS64 then knows that the mechanical action of throwing the turnout was completed and send a signal through LocoNet.

 

The DS64 and BD4 will combination will provide feedback for 4 turnouts.  In this way, they do not appear as normal blocks on a section of track.  In a yard, where you have Slow Motion turnouts it is more cost effective to use the SE8C and 2 x BD4 to handle up to 8 turnouts in this manner.

 

Hope that kind of makes sense.

 

Cheers

 

The_Ghan

[Martijn Meerts]

I use a couple of systems, and the same technique is usable for pretty much any system.

 

I don't know anything about Digitrax, but what you describe sounds plausible :)

 

There are VERY few people who actually do the true turnout position feedback though, even the big layouts like Miniatur Wunderland in Hamburg and Railz Miniworld in Rotterdam don't do it :)

[CaptOblivious]

Let me try that again. You can't do turnout feedback using only DCC. You have to have a feedback bus. Like LocoNet. DCC is itself incapable of providing the feedback mechanism. (Side note: I am simply talking about the accessory reporting the turnout position, regardless of whether this information is reliable). The DS64 can report position—using LocoNet, not DCC.

 

So, let me address your points individually.

 

Of course the Digitrax and Lenz stationary decoders will not operate on each others proprietary bus.

 

Which means no turnout position feedback from a DS64 on a Lenz system. Which means the two aren't fully compatible. And where they are compatible is along the DCC interface to the decoder—the open, non-proprietary portion of the system, I note. Wouldn't it be better if you could use the full feature set of the DS64 on a Lenz system?

 

But this thread is not about DCC, it's about NMRAnet and OpenLCB and the question relates standardization, which you heralded as one reason for the development of OpenLCB nd the standard.  I submit that we already have that standard with the NMRA DCC standard.  Any turnout controller can be wired up to work with any brand of command station.

 

And you can control the accessory decoder with any command station, yes. But here's what the DCC standard—and this is what I'm trying to drive home here—cannot do: it cannot facilitate any kind of feedback from the turnout. Here's something else you cannot do: Use those accessories on a pure DC layout. (Yes, you can use fancier ones like the DS64 with LocoNet, but not all accessory decoders work that way; more to the point, that claim misses the very important point I'm trying to make here.) Accessory decoders take the commands from the rails, and are therefore limited to DCC systems. You need a separate bus for that. Which is why the NMRA desired a new standard in addition to DCC: A bus that would transcend these two limitations.

 

Can I do that with OpenLCB?  Can I just buy a Lenz LS150 and the very flexible Team DCC SIC24AD, hook them both up to OpenLCB, set a couple of addresses and have them just work, like they do if you add them to a Digitrax system?

Yes. If they used NMRAnet. Or offered a whateverBus-to-NMRAnet bridge.

 

 

A side note: the BD4 requires a DCC or other AC signal to work. It cannot detect occupancy on a DC layout. Which means this entire discussion is moot unless you are running DCC. So it's not very useful to the fellow running a DC layout, which is part of the point here.

 

1.  I thought the Digitrax DS64 does turnout feedback when combined with occupancy detection (BD4, for instance) and power routing turnouts.  I believe both the Kato and Tomix turnouts are power routing.

It does. Over LocoNet. Which is great. I'm working on a turnout controller that does the same over NMRAnet. What is the advantage? Because of the structure of NMRAnet, configuration is going to be far easier: You will be able to use a GUI in JMRI (or any number of other configuration tools being developed just now, JMRI was just the first to add one) to configure routes of unlimited size, to configure arbitrary signal behavior in a reasonably intuitive way, to set up multiple control panels on your layout (fascia, CTC), all of which work together in unison, or (and the code and hardware here is also under development) to set it up for control from a DCC throttle if that's your druthers. And again, I emphasize, most of this flexibility and ease of use comes not from JMRI, but from the design of NMRAnet: from the massively powerful producer-consumer model, and from the human-centered configuration protocols that are part of NMRAnet.

 

2.  Actually, as the Digitrax DS64 has switch inputs, it should technically work on a DC layout anyway.  For what it's worth, the CTI Train Brain stuff has been doing it for years.  If that isn't what you meant then please let me know.

That is true. I didn't know that. But by relying on the switch inputs instead of the DCC inputs, you lose a large number of the features. In this case, you are confined to a single control panel for controlling the switch. In contrast, on a DC layout wired with NMRAnet, you could have multiple control panels, full control and feedback with a JMRI panel, integration with your signaling system, and so forth. Some of this is possible with LocoNet on a DC layout, although you'd have to source a LocoNet DC block occupancy detector which are rare if not totally unavailable, to get every last feature. But you still wouldn't get the ease of set up that NMRAnet offers, or the level of flexibility in setting up unusual configurations. (Is there a LocoNet product that allows you to build a control panel to control DCC or LocoNet turnouts over the LocoNet itself? Rather than having to connect it directly to the turnout?)

 

---

 

Here's one way to take all of this. The DS64 is quite a capable machine, but it requires three different interfaces—and hence three different sets of wires—to achieve full functionality—DCC for sending commands remotely, an ad-hoc logic-level interface for local panels, and LocoNet for feedback. NMRAnet gives you all of this functionality in a single interface, a single set of wires. And, NMRAnet gives you easy configuration of arbitrary layout topologies on top of that. The resultant devices works equally well on DCC, DC, whatever, without changing anything about the way it is set up, and without loss of functionality.