Trains.com

Subscriber & Member Login

Login, or register today to interact in our online community, comment on articles, receive our newsletter, manage your account online and more!

Dcc compatability

1274 views
4 replies
1 rating 2 rating 3 rating 4 rating 5 rating
  • Member since
    September 2002
  • 7,486 posts
Dcc compatability
Posted by ndbprr on Wednesday, March 9, 2016 6:01 AM
If everything downstream of the system is compatible why aren't upstream components like controllers compatible?
  • Member since
    February 2002
  • From: Reading, PA
  • 30,002 posts
Posted by rrinker on Wednesday, March 9, 2016 7:04 AM

 Because no standard was set for that side to allow manufacturer differentiation. If a standard were set for the controllers and controller bus, who would make anything when anyone and their brother could make the same thing and undercut them. And whose would you have used as the 'standard'? A slow serieal polled system, a network based one, something else?

                         --Randy


Modeling the Reading Railroad in the 1950's

 

Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.

  • Member since
    December 2004
  • From: Pa.
  • 3,361 posts
Posted by DigitalGriffin on Wednesday, March 9, 2016 10:00 AM

+1 to what Randy said.

Having programmed C++ and .NET drivers for the big "3" this is what I can tell you from my first hand experience...

Lenz's XPressNet was the first.  And as they have evolved the most, they have some of the most arcane protocols.  It was patched and changed several times to handle updates in DCC capabilities.

Digitrax LocoNet soon followed.  And it's pretty bullet proof, but it's stack is a bit complex to program for.

NCE command bus is very simple.  But I don't believe it to be as bulletproof as the LocoNet implementation.  But that's just a my humble opinion.

As with all things electronic, as methods improve, it's sometimes better to start over with a new standard then to patch existing ones.

Intel kind of has this problem.  Their CPU's will run code written for the 8088 (The predecessor for the (80x86) from 1979).  All this extra compatibility really makes the die complex and is one of the reasons Intel CPU's are so power hungry compared to ARM processors on the same node size.  And this is one of the reasons your phones run ARM based processors instead of intel ones, even though intel is the one of fastest most comprehensive mass produced General Purpose CPUs you can buy.

 

Don - Specializing in layout DC->DCC conversions

Modeling C&O transition era and steel industries There's Nothing Like Big Steam!

  • Member since
    December 2004
  • From: Bedford, MA, USA
  • 21,483 posts
Posted by MisterBeasley on Wednesday, March 9, 2016 10:01 AM

Randy's right, but it's still an interesting "What if?" question.  Most of the innovation in DCC has been "trackside," particularly decoders which have vastly improved since the standards were set.  That's the evidence that the standards have worked to promote innovation and give all manufacturers access to the same market, so all modelers can share in the benefits.

But, what about that other side?  As a long-time Lenz guy, I'm still happy with my original system.  On the other hand, Lenz doesn't make a wireless system, so I'm happy that CVP has filled the gap and made a wireless throttle that's compatable.  You do have to wonder how much better our throttles might have been if there had been a standard for throttle communications as well.

It takes an iron man to play with a toy iron horse. 

  • Member since
    February 2002
  • From: Reading, PA
  • 30,002 posts
Posted by rrinker on Wednesday, March 9, 2016 12:05 PM

 The problem of standardizing on the throttle side bus at the time of the trackside standards would be that people would by now be dumping DCC en mass for direct radio. Or given up long ago. It took so long to develop the trackside standards (and even then, stuff was left out and later filled in - to the detriment of the standard, actually - 4 digit addressing, I'm looking at you. Because this came later, the NMRA standard had to accommodate how each manufacturer handled the initial 2 digit scheme, which is why there is the whole 0-99, 0-127 confusion issue between Lenz, NCE, and Digitrax.) that had they taken even longer to add throttle side standards, something else may have tekn hold. The DCC stndards discussion was highly active on the old COmpuserve Trainboard forum (it's still around of course, ported to a standard web site) and compared to the earliest proposed standards, CVP's Railcommand had way more features. ANyway, at the time of the DCC standards, there weren't too many options for a system bus. Ethernet is what many of the latest systems are turnign to, but back then, a 10MB Ethernet card that uses UTP, instead of the more common at the time coax, was VERY expensive. Plus Ethernet is not a royalty free open speification and so would never have been adopted anyway. By leavign that side of things up to the manufacturers, that allowed them to compete on design, while because of the track standards ensuring that anyoen could take their locos to a friend's house and still run them even if they had a completely different brand of DCC system than you did, which was the real issue with all prior proprietary command control systems up to that time. Pretty much worked, too, look how many times the decision of what system to buy comes down to the throttle. Decoders are purchased based on price and features, because it doesn't matter what DCC system you have, they all work. The universal throttle is upon us now, with JMRI and Rocrail and their smartphone apps, the software pieces forming the bridge to support all the different command bus protocols. I don't knwo if anyone's done it yet, but it is at least theoretically possible to use JMRI or some other program to act as a bridge so that you can use Brand A's throttles on a Brand B system. I do suspect that before long, someone will come out with a commercial version of what I have talked about, a smartphone accessory throttle and app compatible with WiThrottle and/or Rocrail that clips on to the phone (as universally as possible, to support the most variety of phone models) that interfaces via bluetooth (again to work with as many different phones as possible) and gives the missing actual knob throttle and maybe a physical direction switch. This would work with any DCC system supported by JMRI and/or Rocrail (and if they wanted to make it compatible with RR&Co, why not, but sales would suffer if it didn;t support a free package like JMRI or Rocrail) and apart from software development time costs, the hardware should be fairly cheap. It would work with the smartphone you already have, or one of those cheap ANdroid ones you find from time to time if you are the type who has no use for a smartphone for anything else. A fully functional piece of hardware could also work this way, but building all the wifi stuff instead of leveraging the phone would increase the cost of the device signifcantly. Maybe one of the established DCC system manufacturers will offer such a device, but I doubt it. None of them really want to just sell throttles for people to use on a competitor's system. Such a device will come from a new company, or at least one that does not currently make full DCC systems, such as one of the decoder companies.

                      --Randy

 


Modeling the Reading Railroad in the 1950's

 

Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.

Subscriber & Member Login

Login, or register today to interact in our online community, comment on articles, receive our newsletter, manage your account online and more!

Users Online

There are no community member online

Search the Community

ADVERTISEMENT
ADVERTISEMENT
ADVERTISEMENT
Model Railroader Newsletter See all
Sign up for our FREE e-newsletter and get model railroad news in your inbox!