RailCom

ECoS 1.1 and RailCom cut and pasted and mildly edited from my posts in the ECoS 1.1 topic:-

I've been checking out just what RailCom does. First you have to activate it in your decoders and then hope the software in the decoder supports it. My experience is that some do and some don't

Enabling RailCom in a decoder
CV29 bit 3 controls general RailCom support. Set to 1 it's on; set to 0 it's off. Most decoders leave the factory with it OFF.

RailCom also has "channels" which are enabled by different CVs depending on what brand of decoder you have. The default setting appears to work ok in the decoders I have, so this looks like an advanced "need to know" feature.

Decoders which support RailCom

Lenz Gold from at least version 6.1; I bought this decoder in April 2006

Zimo MX63 from version 28. This software was published in February 2007, but depending on stocks already in the supply chain you may need to check carefully. Most Zimo MX63 decoders can be updated using the DECUP device.

ESU Lokpilot / Loksound. New firmware was made available on the ECoS Forum last week. You need a LokProgrammer to flash it.

What ECoS 1.1 does with RailCom
It reads back CV values while the decoder is on the main. This is useful if you are tweaking running settings for a locomotive and it's a pain to use the programming track because it is either too short or remote.

That appears to be it apart from support for the SwitchPilot but I don't have one of those to report on what happens.

David

I understand there are some problems in mixing Railcom with more conventional block detection. This is a summary of my understanding of discussions elsewhere, which users of this forum may find useful in avoiding expensive misconceptions! Basically a lot of people who may be expecting Railcom to do certain things are likely to be disappointed.

The decoder sends its Railcom message at a low voltage and can only source a small current while doing so. This is laid down in standards, and necessary in practice because the track power is off during this period so the decoder has to store the energy needed to send the message.

A conventional block detector such as those made by Lenz or Littfinski puts diodes in series with the track feed, and the voltage drop over these is larger than the voltage of the Railcom message. So the message will not pass through these detectors. A less common type of block detectors uses coils. I do not know whether the Railcom signal passes through these, but most people using block detection will also have resistance axles which will also affect the working of Railcom.

Each resistance axle, lighted coach or locomotive without a decoder will take some of the limited current available for the Railcom message and its voltage will therefore drop too low to be seen at the detector. This can be resolved by putting back-to-back diodes in series with the equipment concerned - OK for lighted coaches but I don't see how it could be done in a resistance axle. Decoder-fitted items are OK, as the rectifier on the decoder inputs blocks the Railcom signal.

Hence, on a layout using any of the equipment mentioned above, Railcom will not work in the sense of allowing a central controller to interrogate a specific decoder wherever it may be on the layout. This is unfortunate, as the type of 'DCC power user' interested in Railcom is highly likely also to be using block detection and resistance axles.

I think Railcom will still be usable for local identification of trains at a specific place, provided the detection section is long enough to include the whole loco to be identified, but short enough not to include more than one or two resistance axles in the train it is hauling.

Since identifying a train also implies detecting it, in theory a Railcom user could remove all resistance axles and fit Railcom detectors on each detection section. However this would be very costly and would not detect unpowered vehicles unless these are also fitted with pickups and Railcom-compatible decoders.

QUOTE (Edwin @ 29 Nov 2007, 09:36) <{POST_SNAPBACK}>The decoder sends its Railcom message at a low voltage and can only source a small current while doing so. This is laid down in standards, and necessary in practice because the track power is off during this period so the decoder has to store the energy needed to send the message.
That is not quite the right way to describe it, but the end result is much the same.
The Railcom signal sent out by a decoder during the DCC power off period should be thought of as a fixed current, not a voltage. The Railcom receiver is able to detect the current using a sensing resistor. The system is arranged such that the voltage that appears across the sensing resistor as a result of the Railcom current is lower than that needed to overcome the forward voltage of each decoder bridge rectifier that remains connected in the locos. In other words, the decoders will not load the Railcom signal because the voltage produced by the current is too low to activate them. This is where the simple axle resistor problem comes in - every resistor that is added across the track WILL add a load to the Railcom current, and it wouldn't take many to drain it away completely. As has been mentioned, the only way round this is to add some diodes to provide a similar amount of voltage 'headroom' for the Railcom signal to live in.
As far as block control is concerned, yes, detectors based on diodes will probably not work for the same reasons as stated above. To get the full benefit of block detection and Railcom, each block detector needs to be able to receive and decode the Railcom signal of its own accord, without destroying the signal in the process, and then pass that information back to the controller some other way, such as via a layout control bus like Xpressnet or Loconet. As has also been pointed out, the complexity and likely expense of this requirement means that such a comprehensive solution is unlikely to be very popular with the masses.

Well as I am using Littfinski's and am quite happy with what they do I guess I will stick with them and forget about the minimal benefits of Railcom.

QUOTE (neil_s_wood @ 29 Nov 2007, 22:25) <{POST_SNAPBACK}>Well as I am using Littfinski's and am quite happy with what they do I guess I will stick with them and forget about the minimal benefits of Railcom.

Hi Neil,

I didn't say that Littfinski's detectors don't work with RailCom, or that RailCom doesn't work with them.
I only said that I haven't tested this setup.

And I would never say that the benefits of RailCom are minimal.

Best regards,

JM

QUOTE (jmcosta @ 29 Nov 2007, 17:20) <{POST_SNAPBACK}>Hi,

Sorry to disagree with you.
I have some RailCom local detectors LRC120 wired so that the RC signal passes through occupancy detectors LB101 and they work reliably (Both the LRC and the LB). I've not tested Littfinski's as they have 4 diodes instead of the more sensible approach made by Lenz of putting two diodes + a transistor.

Also in the block monitored by the LRC120 I've put some wagons with a total of 20 resistor axles (10K each) and everything works as intended.

Best regards,

JM

That is interesting and encouraging. The previous discussion involved several eminent DCC experts I have to say I'm surprised, though I don't think anyone had the necessary hardware to do practical experiments. What decoder(s) are you using and do you have an independent power source (eg Lenz Power 1)?

In my own case I have Littfinski detectors fitted throughout, the track feeds work fine but I'm not ready yet to get the detection and feedback working. I don't personally see any need for global Railcom but I hope that by the time I need it there will be a computer-compatible version of the LRC120 which I can to identify trains to RR&Co as they approach from the branch line and sidings which are under manual control. I will consider using a LB101 rather than a Littfinski on this section, and/or shorten it if the number of resistance axles proves to be a problem.

Hi Edwin,

I'm using Lenz Gold decoders and have tested also the Zimo MX64 with the latest firmware update.

And no, you don't need the Power1 to make it work.

Initially I was also concerned by the RC data having to pass the antiparallel diodes and tried -wrongly- the other way round: First the LB101 and closer to the track the LRC120. This wasn't satisfactory as the identification was OK but the LB showed always occupied as the current of the display was enough to trigger the opto.

So, I put them as it should be: the LB direct to the track and fed through the LRC120. I have both worlds: traditional occupancy by the LB (and RS) and identification displayed in the LRC120.

The only remark: the detector in the LRC120 is actually in the line J - J1, so if for your occupancy you are isolating the K rail, you should feed the LRC120 with the K of the booster into the J of the LRC.

Another problem with the detectors from Littfinski is that they have an input for four sections and for me that means two blocks (I am using RR&Co).

Best regards,

JM

QUOTE (jmcosta @ 30 Nov 2007, 19:08) <{POST_SNAPBACK}>Hi Neil,

I didn't say that Littfinski's detectors don't work with RailCom, or that RailCom doesn't work with them.
I only said that I haven't tested this setup.

And I would never say that the benefits of RailCom are minimal.

Best regards,

JM
Thanks Edwin, I can start paying attention to RailCom again now.

Hi guys.

I try to resist responding for the most part but sometimes (as now) it becomes irresistible.
The big problem with RailCom is that Lenz released the vapourware regarding this many years ago which has inevitably resulted in people airing their opinions or repeating the opinions of others without so much as a shred of actual experience of problems actually seen in the real world.

Like many of you we were very interested in the implications inherent in a RailCom system but grew increasingly frustrated at the lack of progress from the RailCom working group until we finally decided to have a go at building our own. Several prototypes followed while we ironed out certain aspects of what a RailCom detector needed to do resulting in a live demonstration at the SECC in Glasgow during the Model Rail Scotland exhibition a few years back. Have a look at our website (www.dcc4pc.co.uk) for pictures and details of the story from there.

In short, provided the specifications are adhered to, there are ABSOLUTELY NO PROBLEMS with RailCom. So why do we keep hearing about problems? Because, to date there are no fully spec-compliant systems out there. Some manufacturers produce RailCom cut-outs that are non-NMRA compliant while others have made RailCom decoders that send non-compliant messages. (e.g: ESU SwitchPilots send an error packet before each point-state message.) Some, like Hornby have produced an excellent RailCom decoder in their Sapphire range, but are their Command Stations capable of using the technology? Not by any stretch of the imagination. They produce a cut-out only when a CV read command has been sent. Is this spec-compliant? Not to any spec I have ever seen.

Other myths, like light bulbs in coaches or occupancy detectors causing RailCom not to work, are also completely untrue. I know because we have tried and seen no difficulties caused. That said, why would anyone want an occupancy detector in the same track section as a RailCom detector, given that RailCom includes simple occupancy anyway? Sadly Tams in their RailCom protocol forgot to include this even though their detectors will detect resistive wheel-sets etc.

Again it's been a pleasure to see people's thoughts on this. Neil (I live about a mile from the Pictish stone on your icon) hang in there. RailCom is potentially very much more useful than any of the systems around today and as soon as software, capable of utilising these features fully, becomes available we should hear less from the detractors out there. And Jmcosta you should be congratulated for at least experimenting with the LRC120s rather than dreaming up theoretical shortcomings like so many others. And Edwin, thanks for your input. It would for now be best if we didn't confuse DCC experts with RailCom experts as these seem to be far less common, not surprisingly given how little is currently available.

Kind regards,

TartanTrax

QUOTE I try to resist responding for the most part but sometimes (as now) it becomes irresistible.

I think you resisted pretty well since it's four years since the last post in this topic

But seriously, now that I have RailCom on my ECoS, I find that when I enable it, various accessory decoders - not of ESU manufacture - stop responding. In the light of your experience, would you say this is a problem with the ECoS RailCom signal or in the accessory decoders? Which do I give up on?

David

QUOTE (dwb @ 6 Dec 2011, 20:34) <{POST_SNAPBACK}>I think you resisted pretty well since it's four years since the last post in this topic

David, that is the first time in a long time I have actually laughed out loud at something on the forum!

On a serious note, I fear that RailCom offers nothing that can't be achieved with computer control.

Perhaps if all the decoders I own were already Railcom compatible I'd be more interested, but I can't see any real benefits atm or going forward.

Rob