Hi all I'm actually a DIGITRAX user. But this EcoS station makes me curious. How are your experiences? It's very expensive, that's for sure. Would you recommend it anyway?
Well all I can say is that I was a Digitrax user until I ran up against its flaws. Those were mostly limitations in growth, not really operationally. I opted for the Cab Control from ESU which is the younger brother to the EcoS system, and I have not been happier. There is no issues with running out of slots like with Digitrax and there is no stop limit for the Locomotive numbers, but the Max Address number is 16386, which is also the max number of locomotives running at the same time, as if that would be a hindrance. Both Cab Control and EcoS are both RailCom+ which is true command and control. That is something Digitrax is not. By true Command and Control there needs to be two way communications, sort of adjust the speed of locomotive say increase to 65 MPH, and the locomotive will acknowledge the command as accepted and also notify the controller when it gets to 65 MPH. Again something Digitrax does not do. So under the covers the Cab Control is the same as the EcoS, they operate the same way, just the throttles are external on the Cab Control, but the EcoS system can also use the same walk around throttles as the Cab Control. I am very happy I made the switch. I am still finding out cool things that Cab Control can do.......
Those are my reasons too. I am of the opinion that DIGITRAX is no longer up-to-date. Since I'm building a new and large N scale layout, it's time to rethink. I have been very satisfied with the ESU sound boards for years. So why not use the system to do the same. The EcoS already has enough power, 6A, which should be enough for larger N scale layouts. Are there weaknesses in the system?
I've got an old Digtrax Cheif system and am thinking about a new system. In my case I've already bought the TCS UWT throttles so plan on getting the CS-105 TCS Command station.
I've never used a Digitrax system, but I was really surprised & puzzled when they came out with their latest wireless throttle, that was still beholden to their proprietary radio system, rather than WiFi, when they already have a WiFi throttle interface! Open Standards, and systems that support them, matter!!! The downside is that JMRI is yet struggling to integrate all the features the CS-105 system provides. I like both ESU and TCS DCC systems, with a slight nod to the TCS CS-105 system for integrating LCC. I like my Pi SPROG 3 system, and have planned on a new, dual track bus Pi SPROG 3 Plus, eventually with LCC added on via RR-Circuits' LCC system*. But TCS' new CS-105 is really giving me a lot to think about... *The Pi SPROG 3 Plus actually has an external CAN bus physical interface (like LCC uses) for accessories, but it runs the older, European, CBUS protocol, rather than the (newer) NMRA-standard LCC protocol. And CBUS is embedded into that product so much that LCC is not likely anytime soon. There are no fully assembled CBUS peripherals available that I know of. There are kits (that don't include, but use some ancient through-hole tech components.) Makes them easier for hobbyists to assemble, IF they can find the parts.
If you are going that far, look at keeping the track separate from everything else, and use LCC to control the routes, turnouts and lights etc. It will be much simpler to get trains running and to have all the detection, lighting and route control isolated and it's automation not affecting the running trains at all from a command standpoint. Essentially what you have are two isolated systems in full cooperation with each other embracing each other and making the joy of running the trains without the worries of throwing switches, detection sections etc of the LCC do all the work for you if you set it up right.
Happy New Year and stay safe Only ESU actually has these requirements. Almost all N scale manufacturers aim for ESU sound. I am currently building a two level layout. With a staging yard in the lower level and a large main line in the upper level. About 20 turnouts are switched. About 2/3 of all turnouts are in the lower level. I was looking for one or more screens.I'm looking for a system that can do MU, has a screen. The EcoS offers that. I'm not a friend of PC control. So I need a hand controller with a rotary knob and a modern controller with a display. ESU is far more expensive than comparable systems. OK, Zimo would be up to par too. So you would also recommend the EcoS?
I am very happy with my ESU Cab Control system. It does everything I want it to do, and I am very demanding. So, you can Go EcoS if that is the system you like. I am happier with the walk around throttle so I can watch my trains in action. And for about the same amount of cash you can get the Cab Control and an extra walk-around throttle for a guest. The throttles still show the image and all the functions that the EcoS system does and they are portable.
I have the ECOS stationary throttle and the ESU Cab Control with 2 wireless throttles. The ECOS has so much power and capability it is IMHO beyond the need of the average modeler. Don't get me wrong, I like it a lot but the Cab Control with WIFI throttles is more useful for me. I love the WIFI throttles.
The Digitrax Wi-Fi interface only supports four throttles (a limitation of the chosen Wi-Fi module, likely chosen for it's low cost and easy software development) - you can add more interfaces, but for a large system I would hate to have to add an interface for every fifth throttle. It wasn't really intended as an interface for a physical throttle, but more for smartphone apps.
The limitation of number of throttles on Digitrax's WiFi interface is a problem for large layouts, but is not common to all WiFi interfaces/throttles. Large DCC layouts (where users would need lots of throttles) are often running JMRI on a computer, and that computer can connect to a WiFi router that can handle LOTs of Wi-Throttle compatible WiFi throttles, for less cost that Digitrax WiFi interface. Then you can run ECOS' throttle, or TCS' throttles, or smartphone throttle apps, with whatever JMRI-supported DCC system you want. I'm not really sure why you believe the WiFi interface wasn't intended for physical throttles. Sure the phone apps came out first (it's a lot easier to get a phone app to market quickly than a dedicated wireless throttle.) The same protocol supports both apps and hardware throttles with no differentiation. Proprietary radio interfaces for throttles are doomed to the fate of the dinosaurs. But not all WiFi interfaces are created equal. A WiFi interface dedicated to train throttles is more expensive than a much higher capacity WiFi router, simply due to the efficiencies of scale held by the latter. There is no such market scale for proprietary model railroad throttles.
Because, if I'm not mistaken, there were no commercial hardware wiThrottles available a the time it was developed. The TCS throttles were not available yet. I believe the ESU Mobile Control was available and although it has an Android operating system which allows you to download wiThrottle to it, it's not a hardware wiThrottle at it's core. That's certainly not to imply that you can't use hardware throttles with it, it's just that that was not the intention of the designers.
WiFi was/not intended for any/specific application. It's a radio network. The first steam engine was invented for pumping water. Sure glad somebody figured out they were good for a lot more than that.
While what you say is true, the Digitrax WiFi interface was designed for a specific application, and that is to connect wiThrottle to Loconet, so I'm not sure what your point is, unless it's to say they could have designed it to interface to their throttles. That's certainly true, but that would entail a complete re-write of the communication side of the throttle software as well as a different, more involved and more complicated design of the WiFi interface. They would have had much higher development costs and the end result would be a throttle that legacy wireless users would not be able to use wirelessly without buying a new interface, likely resulting in fewer sales, and for what gain? Just so they could say they use WiFi?
Granted, Digitrax was in a pickle here. They had to support existing customers, while also attracting new customers, with an improved product. But it is not a problem without better, cost-effective solutions. I don't see larger, established Digitrax users/clubs would have the costs you assume for them to adopt WiFi throttles in the form of additional, new Digitrax-made ones. They very likely already have and use JMRI on the layout, which will also serve the WiThrottle interface for them at no cost. An inexpensive WiFi router will support far more Wi-throttle connections than the JMRI computer's (or especially Digitrax') WiFi interface can. Existing Digitrax radio throttles can be replaced with new WiFi ones only as needed when they die. So that takes care of their medium-large customers, while also attracting new users with better, cheaper solutions. The LNWI interface is actually cheaper than the Duplex Radio interface for smaller layouts with fewer users and, in a pinch, they can use a free app on their smart phone instead of a dedicated throttle. And, of course, users can (should!) also use JMRI, and avoid the the LNWI cost too. But you're also forgetting that a new Digitrax WiFi throttle could also be sold to non-Digitrax DCC users, a whole new market! TCS has shown that the market for WiFi throttles is good, even when they didn't (yet) supply a DCC system.
I don't know that TCS has shown there is a market for WiFi throttles, they have shown that they think there is a market. For their sake, I hope they are right. I personally don't see the appeal unless you do plan to get their command station. I believe the TCS command station is the only one that currently supports LCC, and if so you would have to use wiThrottle mode with any other one. The wiThrottle protocol is quite limited, for example, it currently doesn't support decoder programming (even if they add decoder programming, I certainly don't see them adding system specific functions, such as command station consists and setting command station options). To develop a WiFi throttle that could be used on other systems and would be a full function throttle on Digitrax systems, they would have to develop either another WiFi interface or an ethernet connection to be able to connect to a router (they couldn't rely on JMRI because of the limitations of wiThrottle) and on the throttle they would have to develop two modes of WiFi communication - a full function WiFi protocol and wiThrtottle. It just seems like a lot of extra work for very little, if any, gain. Regardless of whether or not they should transition to WiFi or how difficult it would be, the whole point of my first post was in regard to you being surprised they didn't even though they already have a WiFi interface. Their current WiFi interface would not support transitioning their throttles to WiFi, so the existence of that interface would likely have very little bearing on such a decision.
Well this has drifted away from the subject of the ESU system. So let me bring it back to the main topic. After a few weeks of dealing with the CabControl unit and its idiosyncrasies, I can say there was a little frustration and an little, boy was I stupid. I will deal with the stupid first - I have two throttles, and I was in the process of testing all of my DCC locomotives. The only real complaint I have is that the throttles do not hold a charge for very long. Where I was stupid, was that I picked up the other throttle and was frustrated that I could not find the train that was running. Well there is a little dropdown that gives the full inventory of all the stored locomotives. It is just not where you think it might be, or at least where I thought it should be. So I pulled out the manual and found out that the inventory list is on the other side of the throttle, not there with the screens to load the locomotives in memory. So 1 - Stupid for not really looking at the instruction manual all that closely, and 2 for making an assumption that the ESU engineers think like I do. With that out of the way, I have tested all my different locomotives with Digitrax, TCS, ESU and ZIMO, and whatever was in the Athearn Challengers. They all work flawlessly! It recognizes the RailCom in the TCS decoders and of course the RailComPlus of the ESU and Zimo decoders. That enabled me to pull out the Digitrax stuff and convert to ESU fairly quickly. I am currently replacing the power district boosters with the ESU equivalents on my layout. It was essentially built in a LCC way before LCC was established. So the track was isolated from all the electronics controlling turnouts and routes etc. I have gotten the CabControl unit to interface to JRMI and use the existing PanelPro panels. I can also use DecoderPro too. So I am all in on ESU with no regrets and in the process of loading all my current decodered locomotives into the inventory. Not sure how close it will be to the limit of 16384. That is the next milestone to accomplish.
