Local RailCom Detectors

[GoingUnderground]

Out of interest, what decoders are you using to test your system?

 

I ask as I have seen a comment on another forum which suggests that Zimo decoders "sometimes sends much to early outside the allotted feedback frame", and this can cause problems with some other makes of Railcom detection kit.

[Ticket man]

Good afternoon

 

I use Lenz Mini Gold or Silver only, and have no experience with other de-coders.

[TartanTrax]

Hi all,

 

GoingUnderground raises an interesting point as we had heard this said regarding Zimo decoders too, so set about testing several models to see if there was any truth to the story.

 

Essentially what was being proposed was that Zimo decoders transmit their RailCom data either before the start of the cutout or after it has ended. Well, none of the decoder models we tested (including Zimo sound decoders) were anything other than 100% spec compliant. Their RailCom transmissions were perfect in every way when tested so I am surprised that anyone felt they were somehow non-compliant. I suspect it may just be another myth like the one suggesting that light bulbs in your coaches will break RailCom.

 

Essentially we have tested numerous decoders from ESU, Lenz, Zimo & Tams and found that, contrary to what often happens when new protocols/techniques are adopted, they were all completely spec. compliant from every angle we could test. So in this regard, at least, you should choose your RailCom-enabled mobile decoders to suit your other needs, they all do RailCom perfectly well.

 

In terms of other RailCom kit, spec compliance is occasionally a bit hit and miss and some manufacturers' claims on their packaging are simply bogus. I don't want to name & shame anyone here but just to reassure people that quality RailCom transmissions in the mobile decoder field is an area where your money is quite safe.

 

Ray

[TartanTrax]

Hi Dutch Master,

 

As a manufacturer myself I have great difficulty in running down other competitor's products from an ethical standpoint, so you have put me on the spot a little I'm afraid. That said I also believe consumers should be protected against buying inferior merchandise. So I will try to tread a fine line here and make a few statements instead, which I hope will be helpful.

 

Specifications, if published, can be checked against product performance so, with this in mind, it is somewhat surprising that of all the products claiming to be able to read RailCom, there are only two which comply with the full published specification - the DCC4PC RailCom readers (ours) and the BiDiBi readers made by BiDiBi.org in Germany which I believe is a sub-group of the Open DCC Group. Most of the other products available offer a reasonable subset of the features supported by this technology and, if that is all you require then no harm done but, if for example you want to be able to read more than one decoder in a zone and your hardware can't do it, then maybe not so fine. Sadly software support for the Omnibus protocol as well as the BiDiBi protocol has been very limited - in fact only the (free) JMRI and Rocrail packages have any direct support and using other software has to be done via emulation layers which introduce spec limitations as a result. This is probably less of a problem as software support is likely to grow over time.

 

Finally some simple advice (not necessarily limited to RailCom) could include:

Don't presume that a hefty price tag on any specific equipment will guarantee or even imply quality. We spent nearly three years taking our RailCom readers from fairly adequate to performing much better and costing 75% less.

The fact that a product is the brand-leader in a particular field or country is no reason to buy that product. Manufacturers' reputations, both good and bad, may be undeserved.

Manufacturers that publish their product specifications online so as to enable & encourage other manufacturers to produce compatible equipment should be encouraged and those that try to lock you in to their products by having them only work with decoders or software or whatever also made by them may be best avoided.

 

While I've not mentioned any names, I'm sure you will have recognised at least a few of these principles from your own experiences. Finally, you also asked about the methods we use to test equipment. It varies, but a lot of the time we have used a high-speed digital recording oscilloscope to read DCC packets and RailCom responses. That was how we tested the Zimo decoders mentioned in my previous post. It's actually not very difficult if you have the right equipment.

 

Best wishes,

 

Ray

[GoingUnderground]

Ray,

 

Many thanks for your informative reply. Your tact and diplomacy about other manufacturers' products is appreciated..

[RailCom_Fan]

@TartanTrax is really adamant above that DCC4PC products comply with RailCom specifications.  It's just a pity they have disappeared from their own website.

 

A little over 4 months after the post above, the DCC4PC website stopped being updated (12/Dec/2012).  Their "RailCommander" software hasn't been updated past Beta version 0.2.1, so any issues it has haven't been resolved 4 years later.  And, customers who purchased their products are still waiting for any features they said (Promised?) would be developed.  Have a look at the documentation.  It refers to features that just don't exist.

 

Obviously, DCC4PC were only worried about Specification Compliance.  Compliance with their own documentation, and their Customer Support appears to have come a very distant last, unless they have gone out of business.  If they have, then maybe them ignoring their existing and potential customers for 4 years was the cause.

 

If you do a search of this forum, you find that @TartanTrax pops up every now and again (It seems to be during Scotland's Summer).  One time, he said that they were developing something that included or used a Raspberry Pi.  Why they would abandon their existing unfinished products to work on new things is a little confusing.

 

Check this page out:  http://dcc4pc.co.uk/in_development.html

DCC4PC describe 5 products (9 if you count the 3 shown on their Progress To Date page, and whatever will use a Raspberry Pi) that they have "in development", but none of them are for sale on the Coastal DCC website 4 years later (http://www.coastaldcc.co.uk/products/dcc4pc/).

 

While @TartanTrax is piously suggesting that some other DCC Manufacturers should lift their game, it appears that DCC4PC haven't looked in the mirror for a few years.  Maybe @TartanTrax has a beard, so has no occasion to look in a mirror.

 

Just to be clear here, I have not said there are any flaws in the DCC4PC Hardware (Well, I know there is at least one, plus a usability issue).  But you just can't rely of what they say they will do at some time in the future.  And, Lenz do the same thing, so what's the big deal?  The deal is that @TartanTrax says that DCC4PC are above the standards of the other Manufacturers.  Maybe they are just the same.

 

On the DCC4PC website, @TartanTrax says they are building a fancy new Command Station that "will also come with Wi-Fi as standard".  Well, I'm sorry, but in the 4 years that DCC4PC have been hibernating, 'digikeijs' in the Netherlands have actually released one!  Have a look here at their DR5000:

-     http://www.digikeijs.com/dr5000-adj-dcc-multi-bus-central.html

 

On the 'In Development' page of the digikeijs website, they say they are building a DR5088RC 16 channel feedback detector with RailCom.  Then, look closely at the description, and you find that it will report only 1 address per Input channel.  My goodness, who is going to actually build us something that works the way it could or should?