Conflicting advice on Railcom

[DaveArkley]

I have the need for two Railcom sections in order to identify locos. This will form an important part of the computer automation software I'm writing for my layout.

 

I currently have Digitrax kit:

 

Digitrax DCS100 (Super Chief) 5A Booster/Command station

Digitrax DCS50 (Zephyr) Booster/Command/Throttle (x2)

Digitrax DT402 Dual Throttle

 

All of my locos are fitted with either Lenz Gold Mini, Zimo MX621N or Zimo MX622N decoders so all support Railcom.

 

I have spent four hours talking with various dealers about combinations of controllers, decoders and Railcom detectors, and have been told that there are some compatibility issues relating to the differences between the Lenz and Zimo implementations of Railcom which may lead to unreliability of Railcom communication between my decoders and the options I was exploring. None of the dealers was able to tell me what combination would work together. I received lots of conflicting advise on what wouldn't work! 

 

If I need to settle on one make of decoder I'll standardise on Zimo as I have many more of those and prefer them for their slow running abilities.

 

I'm aware that DCC4PC make both a cut-out device and a 16 section Railcom detector board and that to interface to a PC I'll need their specific CID. While I've read that this has been successfully tested with Digitrax equipment can anyone confirm compatibility/reliability with Zimo decoders.

I'm willing, if necessary to replace my Digitrax equipment. I'm thinking that the Roco Z21 might be a workable alternative. Given this option can anyone tell me a tale of success with Zimo decoders? If so what Railcom detectors were used?

 

Does anyone have experience of reliable Railcom detection with Zimo decoders using any other controller and detector combinations?

 

I'm disappointed to report that non of the dealers I spoke with were prepared to invest the time in putting an experiment together to prove/disprove the utility/reliability of the equipment they sell, despite the potential for a sizeable potential order, hence my request to the community here.

 

Thanks in advance

 

Dave Arkley 

[Nigelcliffe]

This is a very messy area, hence I suspect why nobody will commit to X working with Y.

 

 

RailCom Cutout on Digitrax:    I have the DCC4PC unit working, most of my tests were on a DCS50 (Zephyr), but will be the same on others.    

The Digitrax command station uses a 14bit pre-amble, so only the "short" RailCom cutout is possible (needs 16bit or more pre-amble for a "long" cutout).  Consequently, all that will be read is a single loco address in the RailCom zone, it won't be possible to get speed, or other features.    I've used the Hans De Loof kit built RailCom detector,  I also did some early tests with a Lenz simple RailCom readout.  

 

The HDL reader will deliver LocoNet "Transponding" messages with the loco identity (but not direction of travel) to the output, so software which uses Transponding messages will then work with RailCom.  But, the DCC4PC detection board may be more cost-effective if more than a handful of detection zones are required.

 

The same HDL detector on an Uhlenbrock Daisy-II system has the long cutout, so will read decoder speed, and other aspects from the decoder as well as address.   Again, won't work with more than one loco in a detection zone.   (I'm not clear whether this is a limit in the way RailCom detection works, or whether its a limit of the HDL detector). 

 

I have also done a few tests with Uhlenbrock Marco units.  Note that these don't work with Digitrax systems via the DCC4PC cutout generator.  This is because Uhlenbrock and Digitrax have different "ground" levels for their DCC track signal, and some devices which are critical to ground levels don't play with each other (to the extent that some devices will emit blue smoke, so some care needed when mixing the two brands with devices which do link to track voltages). 

 

 

I've used a mix of Lenz and Zimo decoders for these tests.  Mostly Zimo, but I didn't detect any differences to the Lenz.

 

 

Where things get very messy is RailCom+ (plus).   This is technically a Lenz patent, but is exploited heavily by ESU.   Its been the subject of a techno-legal disagreement between Zimo and ESU (see various items on Zimo website).     With RailCom+ there are far more features available, and it seems much easier to cope with multiple locos within a detection zone.    The ESU ECoS has far more RailCom and RailCom+ features built in and working than other systems I have tried.     I can't comment on the Z21 in relation to RailCom, never tried it. 

 

 

My experiments have all been small scale bench and test-track work, not deployed on a model.    If you have contacts to David Townend of the "McKinley Railway", it may be worth asking him on how far he's got with RailCom on the layout.  He's been looking to add RailCom to it for some time.

 

 

 

-  Nigel

[DaveArkley]

Guys,

 

Thanks fro your advice and guidance.

 

Since I already have the Digitrax controller and the same Zimo decoders as Nigel I like the ability to use the DCC4PC cut-out generator and HDL Railcom detectors.

 

It's a shame that the Digitrax pre-amble limits the returned data to loco address - but since I am planning to detect on tracks with one directional running, and I'm not too fussed about speed I guess this will give me what I need.

 

The requirement for Railcom comes from planning an automated fiddle yard with a manually controlled scenic section. Locos (and their trains) may return to the fiddle yard in a different order than they leave, if for example, I lay up a freight in a siding while a passenger train passes it. Hence I need to detect which loco is arriving. Once I know the address, the software has been loaded with train lengths and so it's simple to track a train under computer control through the various loops of my fiddle yard, and to sequence the trains so that they are ready to leave the fiddle yard according to a computerised schedule. 

 

Many thanks again

Dave

[Phil S]

Alternative strategies exist, which can operate independantly, or in parallel to the Railcom:

RFid tags attached to stock / locos passing a reader can be fed back to the computer system - there is no need for the feedback path to be via the dcc signal; although this may be convenient. MERG members can benefit from an RFid reader kit, and concentrator, or there are RFid > USB readers from china.

Lissy is another method based on bar coder reading

 

If tracking of trains is correctly known from elsewhere (route setting and simple train detection), then simply using optical or magnetic, or even current-consumption-in section can be used - especially where there is no doubt about running direction (no reversing in section !) - all of these can be fed back to the computer indepandantly of the track dcc - although the electrical method does require sectioning, and current consuming devices - locos or resistive axles.

[TartanTrax]

Hi Dave,

 

As one of the directors of DCC4PC  I thought I might add some clarity regarding your question regarding RailCom reliability with various makes of decoders. We tested our hardware extensively before launch and I can report that not a single make of decoder ever performed less than 100% effectively. We tested 4 or 5 different Zimo models at the time and they were all utterly reliable. Making a DCC locomotive decoder that can transmit RailCom is simplicity itself. 

 

Your second issue - only a short cutout possible with Digitrax - has a further possible solution. Instead of using our Cutout Device to produce a cutout, you could buy something such as a Tams booster off a site such as Ebay (potentially for nearly the same money) which will give you a long cutout regardless if placed between the Digitrax command station and the tracks.

 

Good luck with writing your software.

 

Kind regards,

 

Ray

[Crosland]

 

 

Your second issue - only a short cutout possible with Digitrax - has a further possible solution. Instead of using our Cutout Device to produce a cutout, you could buy something such as a Tams booster off a site such as Ebay (potentially for nearly the same money) which will give you a long cutout regardless if placed between the Digitrax command station and the tracks.

 

If the command station is sending only short preambles, how does the TAMS booster increase the preamble length (to allow a long cutout) between packets without buffering and eventually losing a packet?

[Phil S]

I can only observe what I hace seen using the NCE reader monitoring various Roco  and some other controllers - but a std Multimaus system seems to repeat a point/accessory command about 15 times, in a 'burst' .... one of them is likely to get through 8-) ... probably more if you hold the button down.   A std Multimaus also used a cycling stack of 32 locos, whilst a MultimausPro/Centrale system cycled though 64 locos ... perhaps why some  users commenting on a slower response compared to their previous model.

(For comparison, A Massoth Dimax offers the user a choice of locos in the cycle - number versus response.  LGB controllers - aimed at dirty contact garden layouts used an 8 loco cycle.)

[DaveArkley]

Hi Dave,

 

As one of the directors of DCC4PC  I thought I might add some clarity regarding your question regarding RailCom reliability with various makes of decoders. We tested our hardware extensively before launch and I can report that not a single make of decoder ever performed less than 100% effectively. We tested 4 or 5 different Zimo models at the time and they were all utterly reliable. Making a DCC locomotive decoder that can transmit RailCom is simplicity itself. 

 

Your second issue - only a short cutout possible with Digitrax - has a further possible solution. Instead of using our Cutout Device to produce a cutout, you could buy something such as a Tams booster off a site such as Ebay (potentially for nearly the same money) which will give you a long cutout regardless if placed between the Digitrax command station and the tracks.

 

Good luck with writing your software.

 

Kind regards,

 

Ray

 

 

Ray, That's reassuring on the decoder front. 

 

Would a suitable TAMS booster be something like the B4? Have you actually tried that configuration yourself?

 

Can the output from such a booster pass through a power management board like a PM42 without degrading the Railcom feedback?

 

So many questions...

 

Cheers

Dave

 

I must confess I'm still torn which way to go. On the one hand a Digitrax based solution would be great as I don't have to replace my current kit, and while I can only foresee the need to detect loco address, I cautious about locking myself into a solution which won't expand any further.

[TartanTrax]

Hi Dave,

 

We did some experimentation with several boosters but not specifically the Tams B4. What we found (even when using a Lenz booster - given they wrote the RailCom spec) was that boosters seem to generate a long cutout regardless of the number of preamble bits. They shouldn't but they do. In practice we found that this caused no problems with any decoders despite being non-spec compliant. Our cutout device counts the preamble bits and will produce either: no cutout, a short cutout or a long cutout depending on the preamble bits counted. So far we know of no booster that does the same, but it doesn't seem to matter. 

 

I hope this helps.

 

Best wishes,

 

Ray