Lenz RailCom

[Martijn Meerts]

I just noticed Lenz is starting to push bidirectional DCC now. Announced for this year are upgraded versions of their decoders, all of which now feature "RailCom".

 

They've also developed a component which guards a track section which can send back data about which decoder (and therefor which train) in in that track section. Along with decoder number, it also transmits speed and even all the CV values.

 

Lastly, they have a box that the RailCom feedback components connect to, and that box is hooked up to a computer using USB. That way, computer control programs that support it will be able to know exactly where on the layout each train is.

 

Combining the RailCom with a regular block system will give you a lot of extra security, since as soon as a train transmits from a section that the program isn't expecting, the program could hit the emergency break and stop the entire layout.

[CaptOblivious]

Something I've wondered about:

Does this system work with a Digitrax setup? Because if it does, I might well be interested in adopting it.

 

Digitrax has been opposed to the adoption of Lenz's RailCom system as an NMRA standard, because it requires modifications to existing boosters (or the addition of a "cut-out generator" inline with boosters). Of course, it's all political jockeying, since they'd like their less-sophisticated-but-works-with-everything Transponding standard to have been adopted instead.

[Martijn Meerts]

Doubt it works with Digitrax directly to be honest. And well, considering NMRA DCC is basically the Lenz system, it makes sense NMRA went for Lenz RailCom as bidirectional standard as well.

 

I think it might actually be possible to automate an entire layout with RailCom alone, skipping occupancy detectors and the like. Although, I'm guessing the RailCom modules/detectors won't be cheap =)

[CaptOblivious]

http://www.google.com/products?q=lrc120

 

Only about 55USD for each section of track…yerg. And all this device does is display the address of a decoder in that section of track, no computer connection or anything of that ilk.

 

I think that Digitrax Transponding, although less sophisticated than RailCom, and not an NMRA standard, would work well for automation. The only problem is that wiring your layout for Transponding is very complex, and the Digitrax manuals are notoriously confusing. This Lenz device just attaches like a feeder to a semi-isolated section of track, which is dead simple.

[Martijn Meerts]

The LRC120 was a proof of concept and is already an old device (and not very useful ;))

 

What you want to look at is the LRC130 (RailCom detector) and the LRC135 (USB gateway.)

[railzilla]

 

I think that Digitrax Transponding, although less sophisticated than RailCom, and not an NMRA standard, would work well for automation. The only problem is that wiring your layout for Transponding is very complex, and the Digitrax manuals are notoriously confusing. This Lenz device just attaches like a feeder to a semi-isolated section of track, which is dead simple.

 

A Digitrax BDL 168 provides block detection for 16 Blocks which of course needs more wiring as just one block. What adds complexity is that fo rtransponding a BDL168 Block detector hat to be used together with one or two RX4 Transponding Receivers. It would be simpler if the Transponding receiver where just built into the Block detector. Digitrax Loconet is very simple and the Loconet is used for everything. Lenz uses Xpressnet fo rthe controllers, the RS Bus for Block detectors and the like and now they use another Bus for Railcomm. Wiring a Loconet Systems will be a lot simpler than use a Lenz system. What i dont like with railcomm is that its not bachward compatible, so boosters and cammand stations have to be replaced as well as lighted coaches without decoders. Also the way they use for transmitting the data needs a onboard energy storage which is a big capacitor and can be problematic for our N-gauge. Another Problem that if you use Railcomm or Digitrax Transponding you have a vendor lock in. For Japanese layout i would prefer Tranponding just because the Kato Decoders are made by Digitrax and support transponding, use Lenz wired decoders will need more effort.

I dont think Digitrax manuals are confusing. Actually i think they better than most other handbooks for Model RR electronics. But i am an electrician engineer so i used with this kinds of handbooks. Maybe a less detailed quick reference without to many technical terms which covers the basics would be a good addition for the general public.

[Martijn Meerts]

While Digitrax might be easier to wire, you should get all the facts about the Lenz system ;)

 

Railcom doesn't require a large energy supply, ALL Lenz Gold decoders have had transponding built-in ever since their release. They newly announced decoders for 2009 ALL have transponding built-in. Old decoders can be retrofitted with a small transponding chip, which easily fits in even Z-scale loco's.

 

I believe the large capacitor energy storage you're talking about is actually an additional component which you can hook up to a decoder. The energy storage provides decoder and motor with several seconds worth or running power, which means dirty track is no longer an issue. This energy storage is *NOT* required for transponding.

 

Also, with Railcom you don't have vendor lock-in considering Railcom will be NMRA standard for transponding, and quite a few decoder manufacturers are likely to follow that standard.

 

 

I've been looking at the Kato decoders as well, but for me their functionality is just too limited, plus I have mainly Tomix and MicroAce, so the Kato decoders would be useless for those =)

 

 

All that said, I do have my issues with the Lenz system, but so far I've found it to be one of the better systems for a modular layout.

[CaptOblivious]

A Digitrax BDL 168 provides block detection for 16 Blocks which of course needs more wiring as just one block. What adds complexity is that fo rtransponding a BDL168 Block detector hat to be used together with one or two RX4 Transponding Receivers. It would be simpler if the Transponding receiver where just built into the Block detector.

 

It's just a little more complex than that, considering how the RX4's work. And while I do appreciate that Digitrax designed the system so that transponding detection didn't require any additional current from the rails, the whole system is a bugaboo if you (like me!) want to experiment with what you can do with the system using a temporary floor layout. That said, I've been giving this some thought lately, and it might not be all that bad.

 

Digitrax Loconet is very simple and the Loconet is used for everything.

 

Truth. And the nice thing about it is that I can, as I've been considering since Martijn first posted, about  just building my own Railcom/BiDi detector -> Loconet devices.

 

Problem that if you use Railcomm or Digitrax Transponding you have a vendor lock in.

 

Only true of Digitrax. Lenz is very open that, although they patented their Railcom system, they then donated the patents to the NMRA such that no license will ever be required to develop Railcom/BiDi compatible DCC equipment. Which, in my book, was the right thing to do.

 

For Japanese layout i would prefer Tranponding just because the Kato Decoders are made by Digitrax and support transponding, use Lenz wired decoders will need more effort.

 

I know! That's why I too headed down the Transponding/Digitrax pathway. Like Martijn, I dislike the Kato decoders for their lack of features (only 2-digit addressing? come on…). But I've been thinking about this too; I'll say more below.

 

I dont think Digitrax manuals are confusing. Actually i think they better than most other handbooks for Model RR electronics. But i am an electrician engineer so i used with this kinds of handbooks. Maybe a less detailed quick reference without to many technical terms which covers the basics would be a good addition for the general public.

 

While I agree, they are better than almost every technical manual in model RR electronics, they're still pretty bad. Although I've since moved on, in my last life I was a software engineer, and part of that life was spent programming embedded devices. But it took me two days of pulling my hair out to figure out how exactly to program the half-dozen CVs necessary to do some very simple lighting on my KIHA110. (All I wanted to do was to turn off the lights controlled by F1 and F2 when the thing was part of a consist.) The Digitrax Decoder Manual's description of the FX3 functions is just terrible. And I dare you to read the DS64 manual and tell me it's well-written with everything fully explained :D

 

Anyway.

 

I wonder if there's a sufficient market in the English-speaking world for us to convince some non-Digitrax manufacturer of decoders that the Kato decoders need competition (Kato is starting to use them in the NA models, too). And maybe, while we're at it, to make some decoders specifically for MUs (i.e., a wired decoder with only motor outputs; a very very tiny 2-function only decoder). All with RailCom.

[CaptOblivious]

The LRC120 was a proof of concept and is already an old device (and not very useful ;))

 

What you want to look at is the LRC130 (RailCom detector) and the LRC135 (USB gateway.)

 

Their US website must be incredibly out of date then, because that site talks as if the LRC120 is the latest and greatest, with no mention of these other products…

[Martijn Meerts]

The LRC120 was a proof of concept and is already an old device (and not very useful ;))

 

What you want to look at is the LRC130 (RailCom detector) and the LRC135 (USB gateway.)

 

Their US website must be incredibly out of date then, because that site talks as if the LRC120 is the latest and greatest, with no mention of these other products…

 

 

Their US website has always been about a year behind ;) I usually only visit their German website (www.digital-plus.de), but while there is an English version, it's not very up-to-date either... Guess there are some advantages to being able to read German =)

[railzilla]

While Digitrax might be easier to wire, you should get all the facts about the Lenz system ;)

 

Railcom doesn't require a large energy supply, ALL Lenz Gold decoders have had transponding built-in ever since their release. They newly announced decoders for 2009 ALL have transponding built-in. Old decoders can be retrofitted with a small transponding chip, which easily fits in even Z-scale loco's.

 

In Railcom the decoder sends the information durring a cut out in the DCC Signal. This means the command station and all boosters need to provide the cut out, which will force ppl to buy new equipment. The information sent out by the decoder is a voltage signal. That means the decoder needs to store energy to generate ans send out the signal. Also the signal will be affected by any loads on the tracks like DC locos and lighted coaches without decoders. On teh other side teh detection circuit can be quite simple, i even saw a DIY project for it. Digitrax modulates the current by adding more load to the decoder e.g. a blinking light. This works with existing equipment but needs a more sophisticated detection circuit.

 

 

Also, with Railcom you don't have vendor lock-in considering Railcom will be NMRA standard for transponding, and quite a few decoder manufacturers are likely to follow that standard.

 

IMHO: Digitrax should have opened Transponding to other manufacturers too. If so we would have block detectors with built in transponding already plus transponding in some other decoders at least from American manufacturers. Normally the more open standard wins.

 

All that said, I do have my issues with the Lenz system, but so far I've found it to be one of the better systems for a modular layout.

 

I chose Digitrax and Loconet because most NTRAK and FREMO layouts use them. Loconet is quite clever designed and allows very long networks with simple cables. Again i think opening loconet for more companies would have been the better choice. Altough there ar many 3rd party for loconet and i guess its the most spread DCC bus now.

 

 

The Digitrax Decoder Manual's description of the FX3 functions is just terrible. And I dare you to read the DS64 manual and tell me it's well-written with everything fully explained Cheesy

 

I strongly recommend using DecoderPro by JMRI for setting the CVs. Its a lot easier and faster than with the command station. I wonder if anybody ever used the command station to speed match two locos with 28 Step Speed Tables. 

[CaptOblivious]

I strongly recommend using DecoderPro by JMRI for setting the CVs. Its a lot easier and faster than with the command station. I wonder if anybody ever used the command station to speed match two locos with 28 Step Speed Tables. 

 

As I haven't yet shelled out for a LocoBuffer USB or the new PR3 thingy, I have indeed done this using only my Zephyr. It's not so hard as it sounds, actually---just tedious. You have to know exactly how fast each loco will travel at a given throttle setting (0-255), and make a table for each loco. You then decide how fast you want the locos to travel for each of the 28 steps, and do a reverse lookup on those tables to know what throttle setting will get you that speed.

 

I've got a rather sophisticated spreadsheet done up to help me automate much of this process.

 

Then you spend an hour tediously typing in CV values :D

[Martijn Meerts]

While Digitrax might be easier to wire, you should get all the facts about the Lenz system ;)

 

Railcom doesn't require a large energy supply, ALL Lenz Gold decoders have had transponding built-in ever since their release. They newly announced decoders for 2009 ALL have transponding built-in. Old decoders can be retrofitted with a small transponding chip, which easily fits in even Z-scale loco's.

 

In Railcom the decoder sends the information durring a cut out in the DCC Signal. This means the command station and all boosters need to provide the cut out, which will force ppl to buy new equipment. The information sent out by the decoder is a voltage signal. That means the decoder needs to store energy to generate ans send out the signal. Also the signal will be affected by any loads on the tracks like DC locos and lighted coaches without decoders. On teh other side teh detection circuit can be quite simple, i even saw a DIY project for it. Digitrax modulates the current by adding more load to the decoder e.g. a blinking light. This works with existing equipment but needs a more sophisticated detection circuit.

 

The requirement of energy to send out the signal is the same for all transponders. No component can send out a signal without having energy. What I was saying is that everything required for RailCom is build in to the decoders, and doesn't require a large external energy storage as you claimed.

 

 

As for the whole Digitrax vs. Lenz thing, it's personal preference, and in my case, the fact that it's near impossible to get Digitrax items without having to import them, which makes them about twice as expensive as Lenz, which is readily available ;) I also never liked the design on their controllers, small detail perhaps, but important to me nonetheless ..

[Bernard]

I agree, it is a personal preference and a lot of time it's the type of system you start out with. I have the Lenz 100 and love it. I find it easy to use and not complicated at all. The one downfall for me is that since I live in the USA, it's harder getting parts as compared to Digitrax or other USA based DCC systems.

[CaptOblivious]

I had been told to keep this under my hat, but as the cat seems to be out of the bag (mixed metaphors!) I thought I would say something here:

 

The recent N-scale decoders released by TCS support RailCom, as will their future decoders including the recently announced K0D8—a drop-in replacement for Kato E8A/B, F3A/B, F7A/B, F40PH, P42…and just about every Japanese outline electric locomotive. Yay!

 

For such a major advance in American DCC products, they are not trumpeting this at all. You won't find mention on their website, but if you ask their tech support they will confirm it. Here's the first rumblings in the UK:

http://www.rmweb.co.uk/forum/viewtopic.php?f=10&t=35228

 

Currently, they are not announcing whether RailCom will be back-ported to their older line of decoders. In the past TCS has tried very hard to maintain a consistent feature set across all of their decoders, so I think we can expect many will get the RailCom treatment, but some, like the new Z2, are likely too small for them to feasibly include RailCom. I do not know if, but I sincerely hope that, their function-only decoders will soon incorporate RailCom.

[KenS]

Since we have an existing thread on the topic, even if it is three and a half years old, I'll add this note here:

 

I'd been thinking about playing with RailComm after the NMRA updated their draft last summer, indicating that efforts on standardizing it were moving ahead. I eventually decided I had other things I wanted to play with first.  And the lack of much in the way of RailComm-compatible devices is a problem (the Lenz LRC130 detector discussed on this thread three years ago doesn't appear to be shipping at present, although a number of stores have it listed with a TBD price and "not yet available" status, so perhaps it's due soon). If it ever was shipping, perhaps this means they're redesigning it.  Or perhaps it was always vaporware.

 

But the really big hitch for me is, or was, that both of my command stations are incompatible.  And unless you have one from Lenz or ECoS, that's probably true of yours too.  The reason is that not only do you need RailComm-compatible decoders and one or more detectors (and a way to connect said detectors to something, like a computer), you also need the command station to briefly pause periodically (called the "cut out") to allow the decoders time to transmit.

 

It's possible to create a device that blocks part of the command station's output without interfering with the operation of trains, but when I looked, there was no such "cut out device" available.  A few weeks ago I noted that on one of the pages on my site, and moved on to other things.

 

Last week I got a note in the mail from one of the companies I'd mentioned, saying that their cut-out device was now shipping. The company is DCC4PC (see this page for info on their equipment). I'll caution that I know absolutely nothing about this company or their products (and I don't have any relationship with them; I just stumbled across their product page when searching).

 

But if you want to do RailComm on a layout with an older command station, it looks like it's possible now. I'm probably not going to get to this any time soon myself, simply because I have too many other projects halfway done to start a new one, but I thought it would be good to pass the info along in case anyone else is interested.