Yeah, sorry about hijacking your thread, David. So, I've been looking into RailCom, and it seems pretty useful. Do you (plan to) use it for programming on the main, or will you have a conventional programming track? Have you tried using JMRI with your ESU system? I'm tentatively looking for a new DCC system, and ESU is a candidate, along with TCS. Both have RailCom support, but I'm not sure about RailComPlus and TCS, or exactly what it adds. So I keep lookin' and learnin'!
RailCom allows for bidirectional communications between the Locomotive and the Controller. For example you could ask Engine 123 what it's current speed step is, and the decoder would respond with its current speed step. Railcom Plus is different in that it allows for automatic recognition, for example in my ESU decoder in a Kato SD40, as soon as it was placed on the track, it was auto-loaded into my CabControl unit and available to start using, the throttle is automatically updated with all the sound and lighting functions that are enabled. At this time TCS is only RailCom, not RailComPlus. To my knowledge, only ESU and ZIMO are RailComPlus here in the US. I do know the Soundtraxx decoders are not RailCom and neither are Paragon sound decoders in the Broadway Limited locomotives. But that does not mean they can not run, just like Digitrax. Lenz also supports RailComPlus, but they do not sell product in the US anymore. The one thing I will tell you Andy, is to make sure that whatever system you decide on, that is has support of other products like Occupancy Detection and turnout control devices or can interface with what you have if you want to have any sort of automation.
Thanks David, that is very helpful! So if I understand it correctly, Railcom decoders only communicate back to the CS when the they have received a command, whereas RC+ can communicate anytime, (or just within some time after the decoder is powered up?) It sounds like RC+ is nice to have, but maybe not a deal maker/breaker for me. Whereas either RC or RC+ means I can do full decoder programming and readback on the main without having to clear off all the other locos, or move the programmed loco to a programming track. Does ESU have a separate (non-track-bus) interface for accessories like turnout control? I'd like to be able to remotely throw a switch even if a loco has shorted the track bus by running against a switch. I guess I could use a DCC booster, but that would get expensive for Railcom compatible one. I use Kato Unitrack (and switches), so I'll need (eventually) bipolar solenoid adapters for ESU SwitchPilots, which I've seen in the past, but cannot find them now. But then, so do the only LCC switch solenoid control solutions too. I'd use Adafruit DRV8871 bipolar motor drive boards to drive the bipolar solenoids directly from a RR Circuits Tower16. I like the NMRA standard status of LCC (and that my switch controls would be not controlled from the track bus). But I could add RR-Circuits' LCC to the ESU system with JMRI, and do the same thing... Sorry, just thinking out loud... (maybe someone can glean something from my ramblings.)
Looks to me like you have to user their 15v to 21v 7 amp power supply ( HERE ) and ( HERE ). Looks like the CabControl uses a similar voltage power supply. You can run boosters with the system but more money and they also might not have the option for 12 volts? Sumner
That's what it looked like to me too, especially since the supply is variable, and apparently the DCC system controls the supply voltage within that range. At least some of my Kato N scale DC locomotives specify 12V max. I know they appear to run reasonably cool after DCC conversion on my existing 15V DCC system (which is ~13.5V at most by the time it gets to the motor) but it is technically out of spec. I suspect the voltage limit is based on heat/speed, rather than winding insulation breakdown voltage, etc. So running a PWM waveform that peaks at 13-15V, but averages much less (at the speeds I run) shouldn't be a problem. Nevertheless, if I have the option on a DCC system for N scale, I'll purchase it with a (supported) 12V supply rather than 15V. Your Mileage May Vary; Closed Course, Professional Driver; Objects in Mirror are Closer than they Appear; yada, yada, yada...
The downfall of the ESU CabControl. Well there are some serious issues, that may point out had made me decide to look at other systems. First and foremost is the ridiculous throttles that last less and less time as you use them. Started out at about 4 hours until recharge. After a few weeks it is down to 2 hours on full charge. That makes the throttles essentially useless. Add to the the storage of Road Numbers is not very good. Have more of the same Road Number that you want to use, well forget it. I have a 172 duplicate road numbers in my fleet. One of them is a Kato Amtrak P42 Genesis locomotive, my conflicting number is a Montana Rail Link GP 35. Now while I may not run both at the same time, there is no reason in the world that a GP 30 should have the same speed profile of a P42 . The GP's do not run at the speeds of a P42 passenger locomotive. This becomes a sticking point for me. I should not have to create a crazy scheme to enter my locomotives. This was not a problem with Digitrax, though the slots were a big issue. I also had several ESU Loksound decoders installed into many of my locomotives that did not self register, enabled with RailCom + that failed to auto-register like they were supposed to. I did have fun while the throttles worked, just not for very long. And I am at the point where it takes longer to recharge the throttles than it takes to run them out of power. Two hours of use and then four hours to recharge. This turns out to be a dismal failure. If I did not run run against the limits on the throttles, I could find a way to deal duplicate numbers. Easier to change the numbers on 172 locomotives, than buy a dozen or more throttles so I could run for hours. Time to investigate Zimo and other systems. See what they can do.
