TartanTrax

Hi Neil, Sorry to hear your ECoS died. If you fancy a colour screen, why not try a Roco Z21 with a large screen tablet? The Roco Z21 also does RailCom and even if you buy the tablet (assuming you don't have one) it should still be cheaper than a new ECoS. Nothing wrong with the ECoS other than its price (that raises my Scottish bloodpressure). ;-) Loved this article and the pictures. Cheers, Ray

As a manufacturer of some DCC kit, I will just add my 5p's worth here and say that not only is it unnecessary for you to worry but pointless as this man's opinions are just that and not hard evidence. We had some results of tests done by the NMRA (when issuing Warrants of Conformance to manufacturers of command stations and boosters) that showed that it is pretty much the norm for the quality of the DCC square-waves produced by numerous products on the market to be poor to very poor on average. On average, the expensive models were just as guilty as the budget models and putting these systems under significant load seems to harm them very slightly to not at all. In terms of the DCC specs, locomotive decoders are required to be very tolerant of a poor DCC signal and they usually are. The problem arises with accessory decoders, turntable controlers etc. where there isn't the same requirement for coping with poor DCC and relatively poor performance can result and sometimes no performance at all. This isn't because you asked too much of it, - the hardware was just not built to a high enough standard. (Of the NMRA tests we were given, about 70 to 80% should have been improved before putting them up for sale to the trusting public.) When we designed our DCC4PC Standalone Railcom Cutout Device we wanted to make sure that we wouldn't be blamed for anything not working because guys came up with an opinion that we were to blame. That is why our product, when connected to a command station or booster, will take in the DCC signal and repair it so that no decoders should fail to respond to DCC commands, either when the RailCom cutout is active or even when it is not. If you want to look at our website under the manuals for the Cutout Device, we have published oscilloscope traces of the DCC signals from two very popular mid to top of the range Command stations both before and after fixing. Both these manufacturers were successful at getting an NMRA Warrant of Conformance (WoC) so they are clearly not very strict. You have to wonder how bad some of the DCC signals are from manufacturers that failed to get a WoC after the NMRA tests. One of those that failed, is mentioned quite often on this forum but it would be unethical for me to mention any names, as in practice their stuff seems to work pretty well regardless. However if you do try to run both systems via DCC and find you have a problem as the MERG bloke described there are a couple of ways to fix the problem. One we are looking at presently is adding a hardware & software bridge to a Raspberry Pi. This has the potential to be a very high quality solution at a budget price. It is such an obvious idea, I'm sure we aren't the only ones looking at this either. Kind regards, Ray.

Hi again Rich, Thanks for your reply. You may be right that RFID is the way to go as it may work out cheaper depending on how it is implemented. We have recently been contacted by some modelers in the USA regarding some very ambitious projects, not to mention absolutely huge and very complex layouts with predicted build times ranging from 15 years to over 20 years and from the problems they have identified as needing solving you may find some common ground with your own future plans. I have a sneaky feeling that the software you use may play a significant role too. Another option which might give you the best of both worlds might be to use a combination of two systems, such as RFID & RailCom with software that then propagates these values around your layout via a prediction algorithm. If you want to contact me directly regarding any of this, my email address is: dcc4pc@gmail.com Merry Christmas & a prosperous New Year, Regards, Ray

Getting excited by a Hornby announcement? I stopped doing that when I was about 14 years old. Since then they seem to have produced a long line of disappointments. They produced the Elite capable of generating a RailCom cutout and their Sapphire decoders which are pretty good to excellent. Then, despite the "RailCom compatible" claims on the Elite boxes, they cripple this feature to the point that the Elite firmware only produces a cutout when reading CVs. CV reading is something the programming track can also do. Is it really RailCom compatible? Then they decide they want to do Locomotive Detection - something a change to their Elite firmware could already achieve, as could their Sapphire decoders. Adding local detectors would have given them a very viable solution especially if linked to their software. Instead they decide it would be better business to dream up something new in order to sell more hardware to the punters out there. The description of this system sounds somewhat reminiscent of the Uhlenbrock Lissy system where barcodes stuck under locomotives are read by the scanning LEDs on the tracks. It may be worth remembering that Lissy was so flawed that they then brought out their Marco RailCom system. Maybe that's Hornby's plan too?

Hi Rich, I'm slightly puzzled trying to work out what you are trying to achieve by identifying wagon ID's. Based on your layout sketch, I can see why you thought (probably correctly) that RailCom could help you run several trains at the same time by adding a bit of automation to your system. For what purpose would you need to know the identity of the wagons as well? Regards, Ray

Hi Dutch, You can disagree with me if you want but you are still wrong. When Bernd Lenz wrote the RailCom spec he did a very decent job of it. (Likewise when he wrote the DCC spec.) One of the things he needed to cater for was the possibility that a train could pass from a section with a cutout to one without a cutout and this should not cause any problems. Moreover, what if a train were to park accross such an area with lit coaches? That would mean an area with a cutout would be connected to one without for potentially very long periods of time. It was for this reason that the spec stipulates that any device generating a cutout, should it detect DCC during the cutout, it must instantly cease to generate the cutout until this condition no longer exists. In fact if you reread your posting up to the place where you said "acts accordingly" and then inserted "stops generating the cutout to prevent a short circuit" you would have been 100% correct. If the Z21 doesn't do this I would be very surprised indeed as it isn't technically difficult and it is quite clear in the spec for RailCom that this must be done. A device that fails to do this should be regarded as broken. As regards boosters, I am fairly sure that none of the Roco boosters are RailCom compatible. If we assume that the Z21 may indeed be broken as described above, this still leaves one with a few options: 1) If not wanting to use RailCom, simply switch it off on the Z21 and make do without it, 2) Use a RailCom enabled booster connected to the Z21. (I have seen some very reasonably priced boosters from Tams on Ebay.) or 3) attach a RailCom Cutout Generator to the track feed from the Roco booster. I would suggest doing the first one for now as it's the cheapest and the other options will always be available at a later date should he want to use RailCom after all. If he still gets short circuits despite switching RailCom off, then RailCom is not involved at all but something may be preventing the voltages from his two transformers from floating. From his description this is what I suspect is the case but without knowing more regarding his wiring it's hard to guess where things may have gone pear shaped.

Hi again Despatcher, I'm sorry but the kindest word for the reply Roco sent you is Balony. I will explain: RailCom is a term for bi-directional communication between the DCC decoder and the command station (or the computer if you use a PC to control your trains). In order to allow the decoder a chance to have its say, the command station will produce a very brief short circuit (less than half a millisecond long) at the start of a packet transmission (called a preamble) where the left rail is effectively connected to the right rail. This period is called a cutout and is too short to be recognised by the command station as a short circuit. Decoders are required in terms of the DCC spec to cope with short power interruptions (in case your locomotive drives over a spec of dust or an insulated track joiner etc.) RailCom (patented by Lenz) seems to get the blame for a lot of things (the forums are full of examples) but it is a fact that, provided RailCom is implemented in compliance with the spec it will never be the cause of any problem you may be experiencing. Problems will occur due to decoders being outside of their specifications or if the Z21 is implementing RailCom outwith of the spec. It is a fact that driving a locomotive from an area with a cutout to an area without a cutout causes absolutely no problems at all. (I know because I've done it often.) Furthermore Roco claims on their website that the booster you are using is compatible with the Z21. I must assume they tested this rather than just printing something based on optimism. RailCom when switched on on the Z21 can be used for automation because the RailCom data will tell the Z21 where the locomotive is, which way it's travelling and at what speed so not a bad option to have. It is also possible to add a cutout to your booster should you wish. Anyway, the short answer is whatever the problem is, it probably isn't RailCom. I notice you live in Kent which is not too far from where we are at the moment so if you want to have a chat or possibly meet to see if we can solve the mystery, feel free to contact me on the forum messenger application and I'm sure we can make a plan.

Hi Despatcher, Just in case I have missed something, are your Z21 and your booster connected to the SAME transformer? Command stations & boosters require floating voltages to avoid short circuits when a locomotive crosses from one power district to another so each device must have its own transformer or shorts are going to be a problem. Sorry if I'm asking the bleeding obvious but on skimming through this thread I saw nothing saying there were two transformers. Apologies if I missed it. Cheers, Ray