Jump to content

Railcom compatible equipment


Recommended Posts

I decided to build this new layout using equipment that is 100% Railcom suitable and I have had many challenges finding euipment that meets my desire and I thought I would let people know what I have finally used to get full automation with full visibilty of what is where at all times - this may help people who want to use the capabilities presented by Railcom.

These items provide me with 100% Railcom coverage and I am very impressed by all of them and would not hesitate to recommend any of these products as they have all worked perfectly out of the box and setting up has been a doddle.

I hope that this helps someone - if only to save them wasting money trying to find a solution that works, or getting sore fingers asking questions on what does/doesn't work with Railcom, and even better all of these items are available in the UK. :)

Iain

Edited by WIMorrison
  • Like 1
  • Informative/Useful 1
Link to post
Share on other sites

Hi,

 

Great info.

 

Did the "power district cutouts" and the "auto reverse module" have to meet certain criteria to work with Railcom?

 

When you were looking at computer software did you research TrainController? If so what things made you choose iTrain?

 

Thanks much.

 

Frederick

Link to post
Share on other sites

The first requirement for both of these items was that they actually work with Railcom. :)

 

I did try other cutouts and auto-reversers and in the case of one cut-out Railcom caused to fail to operate completely, and the others failed to pass Railcom signals consistently and had spurious cutouts. Swiching off Railcom with all these errant devices enabled them to operate as intended therefore I decided they were not Railcom compatible. the EB1 was the only one that worked 100% of the time (and was also the cheapest!) 

 

With the auto-reverser there was an additional requirement which was that I wouldn't have waste a complete detector module for one feedback, which effectively meant that the auto-reverser had to operate after the detector but without constantly triggering occupancy due to the current draw. The only one I have found that operates in this manner is the LS Digital 5410.

 

There may be more equipment that works with Railcom and I would ask that people post it in this thread - might become useful enough to become a 'sticky' ;)

 

Edit - forgot to answer the iTrain question.

 

I did look at the other alternatives and considered that iTrain offered the best 'bang per buck' of the commercial programmes, with TrainController just being far too expensive for my hobby purchase. iTrain standard was well inside my budget and provides all the functionality I need and most importantly is easy to understand. I discounted JMRI and Rocrail after several frustrating attempts to make them work - I had the basic iTrain working in about 2 hours and have found a UK based reseller (www.dcctrainautomation.co.uk) who runs training courses and provides excellent remote support.

 

hope this helps

 

Iain

Edited by WIMorrison
Link to post
Share on other sites

  • RMweb Gold

What about DCC turnout decoders? I use Tortoise motors operated by NCE Switch-8 Accessory decoders. These work very well indeed, but the Switch-8s are not Railcom compatible. If I enable Railcom on my Lenz LZV100 the Switch-8s stop working. 

 

However, I now have the accessory bus with a separate booster (Lenz LV102). Fortunately I am able to have Railcom enabled on the LZV100 but not the LV102, so I could use Railcom if necessary. 

Edited by RFS
Link to post
Share on other sites

hope this helps

 

Iain

 

Regards iTrain - I see there are several - which version did you purchase?

 

Thanks again. Good information to file away.

 

Frederick

Edited by fcwilt
Link to post
Share on other sites

Frederick,

 

I bought the standard version. I did have a trial of the top version for 3 months (free from author) and found that I wasn’t using the additional functions that are available as you move up the offerings.

 

At £172 (~$200) is is much more affordable that the alternative. I also note that the upgrade path is simply the cost difference between existing licence and new product which is good to know. I was also told that as the product has evolved (the author is active on the product forum) he has offered upgrades at very attractive prices - again, not like the main commercial alternative ;)

Link to post
Share on other sites

Frederick,

 

I bought the standard version. I did have a trial of the top version for 3 months (free from author) and found that I wasn’t using the additional functions that are available as you move up the offerings.

 

At £172 (~$200) is is much more affordable that the alternative. I also note that the upgrade path is simply the cost difference between existing licence and new product which is good to know. I was also told that as the product has evolved (the author is active on the product forum) he has offered upgrades at very attractive prices - again, not like the main commercial alternative ;)

 

Thanks very much.

 

Frederick

Link to post
Share on other sites

  • 2 weeks later...

Railcom provides the ability to get the actual loco ID from the decoder when the engine is on the main track which is useful when running using automation software as it shows that the actual loco number on the screen.

 

The great advantage is that you can do proper POM as you can not only write values to the decoder but you can read the values that are stored in the decoder. This allows me to fine tune loco to get best performance as I can alter the motor variables at will and see the effect of changing the motor type, emf, emf rate, frequency and a host of other variables real time.

 

Other manufacturers than Lenz make decoders with Railcom - Zimo and TCS being 2 that I know but I like Lenz chips and as they are all priced around the same I prefer to remain standard as I know the CVs in Lenz :)

 

Hope this helps

Link to post
Share on other sites

In the future RailCom could become more important as it could allow feedback of coupling status in a fully DCC coupling system - something that would be very useful for manual control at a distance and also for automation to be able to report either coupling up or uncoupling failures.

Link to post
Share on other sites

...Other manufacturers than Lenz make decoders with Railcom - Zimo and TCS being 2 that I know.....

 

 

All ESU LokPilot and LokSound DCC decoders have RailCom and RailCom Plus.

Uhlenbrock also produce RailCom and RailCom Plus decoders.

 

 

Edit (12 Apr 2018): 

Manufacturers with RailCom decoders include....

 

Kuehn

Tams Elektronik

ESU

Uhlenbrock

Lenz

Zimo

TCS

 

 

Note: Subject to space being available, any loco fitted with a non-RailCom decoder, can have RailCom capability added by fitting a RailCom sender module (a mini decoder).

.

Edited by Ron Ron Ron
  • Informative/Useful 1
Link to post
Share on other sites

Railcom provides the ability to get the actual loco ID from the decoder when the engine is on the main track which is useful when running using automation software as it shows that the actual loco number on the screen.

The great advantage is that you can do proper POM as you can not only write values to the decoder but you can read the values that are stored in the decoder. This allows me to fine tune loco to get best performance as I can alter the motor variables at will and see the effect of changing the motor type, emf, emf rate, frequency and a host of other variables real time.

Other manufacturers than Lenz make decoders with Railcom - Zimo and TCS being 2 that I know but I like Lenz chips and as they are all priced around the same I prefer to remain standard as I know the CVs in Lenz :)

Hope this helps

That’s great, thanks for the information.

Link to post
Share on other sites

its perhaps the only way to implement proper slow down procedures automatically with total layout automation , you need to know the ID of the DCC loco in the block section that  you wish to control 

 

Plenty of layouts with automation manage just fine without RailCom, its far from necessary.   All the software needs to know is where the locos are at the start of operations, ideally the size of any train load, and then the software can track trains, slowing and stopping correctly, provided there are sufficient block detectors, and if decent speed profiling for the software has been done.     

 

If anything, RailCom is a solution searching for a problem to solve. It looks really nice in principle, but despite being around for ages, there are very few advantages available over alternative approaches.  Which is why the uptake is so slow. 

Link to post
Share on other sites

Plenty of layouts with automation manage just fine without RailCom, its far from necessary.   All the software needs to know is where the locos are at the start of operations, ideally the size of any train load, and then the software can track trains, slowing and stopping correctly, provided there are sufficient block detectors, and if decent speed profiling for the software has been done.     

 

If anything, RailCom is a solution searching for a problem to solve. It looks really nice in principle, but despite being around for ages, there are very few advantages available over alternative approaches.  Which is why the uptake is so slow. 

 

I Would argue the uptake is slow cause NMRA messed up. 

 

the problem is  where you have layouts that are not completely computer controlled , i.e. you may have manual driving of trains , interspersed with  computer control, or you just may want to implement AWS  for example without total layout control , ensuring your operators " drive to signals ", or just have a automated shuttle or platform loop slowdown/stop etc , or even automated rule 39(a) processes , again you really need to know the ID of the loco in the block , rathe then having to maintain " state " over the whole layout 

Link to post
Share on other sites

How good are any full automation systems at dealing with complex shunting anywhere on the layout? I'd argue none, though I'm sure some will disagree. To be able to automate coupling up and uncoupling anywhere on a layout, with any length of train, would require feedback from loco and/or vehicle to the control system. RailCom provides that. The only other way to do it would be via some kind of wireless transceiver on the vehicles, such as bluetooth, but that would require some quite complex and probably bulky decoders. A small function only decoder with RailCom and proximity sensing could be put into every vehicle in theory, allowing any coupling or uncoupling operation anywhere along the train, anywhere on the layout.

Link to post
Share on other sites

How good are any full automation systems at dealing with complex shunting anywhere on the layout? I'd argue none, though I'm sure some will disagree. To be able to automate coupling up and uncoupling anywhere on a layout, with any length of train, would require feedback from loco and/or vehicle to the control system. RailCom provides that. The only other way to do it would be via some kind of wireless transceiver on the vehicles, such as bluetooth, but that would require some quite complex and probably bulky decoders. A small function only decoder with RailCom and proximity sensing could be put into every vehicle in theory, allowing any coupling or uncoupling operation anywhere along the train, anywhere on the layout.

 

I disagree that RailCom is transformative in shunting.  But, to take theoretical discussions beyond a "pub bar chat" requires a prototype shunting setup which can be evaluated. 

 

 

If someone has a layout doing stuff they like with RailCom, that's great.   Equally, I know big layouts with mixed automatic and human control, where RailCom isn't needed (its been considered and rejected as "not useful").  

 

 

- Nigel 

Link to post
Share on other sites

I acceptt that it has limited acceptance within the community, but I think that this is for 2 reasons - one is shown here as we have people asking what it actually is and what it can do. This is down to education and knowledge on DCC systems where most people have knowledge of only one system and do not seek to understand the capabilities outside of their use, which is also often limited by what the 'salesman' demonstrated to them or what they see at the club layout and hear from the 'experts' - this is what I would call human nature.

 

The second reason is rather more damning and it is the lack of innovation ort development by DCC manufacturers who have largely failed to adopt Railcom and simply remained with the systems that they developed many years ago when first creating their DCC offering, fixing issues and offering little further innovation. I have been using DCC for 15 years and see very few new capabilities that haven't been available for many years.

 

It is also probable that the adoption of a different standard by America (also not used) with the Digitrax Transponding has left the European vendors isolated from a large market, but it is gaining traction as the value of the bi-directional communication is understood.

 

All of the discussions on these boards about trains 'running away', poor loco performance, failing to do X or Y etc. can be addressed and resolved easily by using Railcom as the loco can confirm it has received the instruction unlike traditional DCC where the controller send out a message and hopes that the receiver gets it. In computer networking terms this is the difference between UDP and TCP (which will mean a lot to those who know the TLAs and for the majority https://www.diffen.com/difference/TCP_vs_UDP :))

 

edited for spelling errors - hopefully all resolved!

Edited by WIMorrison
Link to post
Share on other sites

  • 3 weeks later...

​I now have enough track with sufficient complexity to test and demonstrate it working and I created this short video to show a friend who lives a long way from me what it all looks like when you get it all hooked up together and working.

 

https://www.youtube.com/watch?v=-KXWtys3ptA

 

I know that the video of the actual track is small, but I wanted to concentrate on the control being provided by iTrain which is running this little layout completely automatically, all I have done is pressed the start button and poured the tea, iTrain is controlling everything else. The numbers you see are the Railcom feedback showing the Loco ID in the block.

 

This is what DCC is about for me, full automation which will also let me insert trains manually onto the track then recognise that and simply slot it into the routine that is running.

 

I hope it is useful - I am certainly pleased I have it working fully now :)

 

Iain

  • Like 1
Link to post
Share on other sites

  • 2 years later...

I’m rewaking this thread as I’ve a similar requirement for a railcom/iTrain/cobalt digital setup.

 

The command station is digikeijs DR5000 and a couple of 5088RC feedback modules.

 

I’m having a crazy issue with the cobalts.  I have 4 double slips set up in a diamond formation, so 8 ipDigital motors.  These are initially set to addresses 60-67, and I have verified they respond to commands from the DR5000.

 

when I setup dr5000 without a railcom cutout, iTrain runs the point formation just fine but of course there’s no railcom feedback in iTrain.

 

when I set up the dr5000 with a railcom cutout, with iTrain in charge, I see the following problems:

 

1) on startup the dr5000 tries to set the turnout motors.  Often, during the set process the dr5000 will cut out.  It is not a short, as I can just press the green button and we are off and running again.
 

2) This is the mad part:  very soon one of the slips will be set wrongly.  When investigated thoroughly, I establish that the one or more cobalt ipDigital has been reassigned a different address!!!!!  eg motor originally on 60 will now respond on 67 or motor on 64 will respond on 61.

 

this does not happen if railcom is off in the dr5000 but that sort of defeats the issue.

 

I have been at this for 48 hours straight and come to the conclusion that ipdigitals are probably not compatible with digikeijs if railcom is enabled.

 

Am I missing something here before I look for a different command station setup?

Link to post
Share on other sites

I had a DR5000 for a period when i considered selling my Z21 as I had been convinced that the DR5000 would meet my needs better due to the number of protocols. During the period of owning the DR5000 I had all sorts of issues like you describe and as I use Railcom turning it off wasn't an option. Initially I was told it was a Cobalt issue and various posts showed that people had cured their Cobalt issues by turning off Railcom but I persevered and place some 'snubbers' on the DCC busses to remove that potential issue and in fairness it did reduce the issue but it did not remove the issue.

 

Luckily I hadn't sold my Z21 and i plugged it in a Lo! all the issues disappeared, plugged in DR5000 and issues returned - The Z21 is now plugged in and the DR5000 was sold.

Link to post
Share on other sites

Thanks Iain.  
 

I’ll try the termination snub of the DCC bus, it’s fair to say that this issue has really multiplied now I’ve gone to a T shaped bus on a doubled size layout but I’ve never heard of cobalts being reassigned an address while in run mode before. It’s crazy.

 

And another reason to not give in and lose railcom - without the cutouts in on the bus, there’s more rms track voltage so trains go faster per speed step. I’d need to speed profile all the

locos yet again for iTrain 

Link to post
Share on other sites

One possible route out would be to put the Cobalts on an accessory bus where the RailCom Cutout is absent.   Unfortunately, to do that requires more hardware adding to provide a bus without the cutout.  

 

I think the DCC4PC cutout device can be configured to remove the cutout, so do precisely this job, but its another bit of electronics to add to the expenses sheet.   
Or a second DCC system (something simple, eg. a Sprog) and configure iTrain to use the turnouts on that second system (assuming iTrain can cope with multiple system connections).  Again, more expense.   

 

- Nigel

Link to post
Share on other sites

Nigel

 

i don’t think that the DCC4PC is sufficiently reliable for mainstream use, very much a development bit of kit for use in an environment where one likes playing and solving issues - that was my experience from about 18 months using one.

 

iTrain could do what you suggest easily  (assuming the correct licence has been purchased), the other way might be to have the second command station sniff the main track bus - can the Sprog sniff the main bus to relay the commands without railcom?

 

 

Edited by WIMorrison
Spelling ...
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...