Following up... To connect JMRI running on a laptop/computer to the TCS LT50, you need the RR-CirKits "LCC Starter Kit". If you are using the TCS CS-105 DCC system (not exactly an entry-level system), you can connect your JMRI laptop to it via WiFi.
Personally I'd go with either the PowerCab or the LT50 over the Zephyr (tethered throttles). Once you use a hand throttle I think you will be hooked and not want to use the stationary one even on a small layout. I love my hand throttles which are also wireless. For a smaller layout being non-wireless isn't probably as important as if you have to walk around so a concession one can make. I knew from the beginning I wanted the freedom of a wireless throttle so chose a system that allowed me to go that way for less than either of these systems but also isn't open the box and run. Getting close to that but still a little ways away although people are starting to sell DCC-EX Command Stations I see. I know for sure with the PowerCab and this is probably true of the LT50 you can run a much larger layout with one by adding boosters down the road. The throttle now only sends the DCC signal to the boosters so isn't needed to power the layout. It becomes the master command station. Duncan, owner of Tam Valley, runs a very large layout with a PowerCab that is connected to his boosters in this manner. You could do the same with other manufacturers products. If I wouldn't of found DCC++ which morphed into DCC-EX I probably would of gone in that direction with a PowerCab (available at that time). Now I'd probably compare other products before making a final decision. Sumner
Excellent points, Sumner! The LT50 supports RailCom, the NMRA standard system for transponding, where locomotives on the layout can communicate back to the command station, to confirm identity, commands received, and commands executed.* Railcom also allows reading the currently programmed contents of decoders on the mainline. So Railcom allows the entire mainline to be a reliable programming track for each individual locomotive on the layout. But you would need a RailCom compatible booster to keep that capability on a larger layout. TCS offers such a booster, but it is more expensive than other non-Railcom boosters. Railcom allows programming on the mainline, with full-readback from the decoder as to what was programmed (both before and after your programming). This really removes the need for a traditional programming track to be able to read back decoder contents. And RailCom reads back data much faster than on a conventional programming track, plus the locomotive does not have to move while programming like it does on a conventional programming track. But not every decoder brand provides the Railcom feedback capability. TCS, Zimo and ESU decoders support Railcom. *On very large layouts with potentially lots of locomotives, this decreases latency for transmitting DCC commands from the command station to the locomotive, since once a RailCom locomotive has replied back that it has received and executed a command, the command station need not keep repeating the last command to that loco. This frees up the DCC bandwidth to allow the command station to send new commands to all locomotives much quicker.
I opted for the NCE PowerCab system. It interfaces to a PC with JMRI if desired. I run 6 trains at a time with a mix of decoder brands (NCE, TCS ESU and Digitrax), with an additional 4-5 engines idling and only use about 700-800mA. I have talked to the NCE guys about a power booster. They said 2Amps is possible from the PowerCab (so about 12-14 engines). I did not get the booster. I do have multiple power feeds around the layout, and only see about 0.1V drop worst case, and no slowing of engines away from the cab. I found some nice 3D brackets on the internet, so I can holster the PowerCab on the edge of the layout when not using it.
My laptop is my only computer and gets used for way too much 'stuff'... BUT.... when It gets replaced with a newer one, I will keep the current one and then your suggestions will come in very handy! Thanks
I don't know if this was said, but with dccex, you can have two engines on the same throttle. I use my mobile as my throttle, and the screen is split in two, so I can have the two engines. It's convenient to be able to move two engines at the same time without having to switch which loco appears on screen. If you use a tablet with a larger screen, I think you can have up to three or four engines on screen at a time.
JMRI will run on about any windows computer, I belive back to windows 8. I'd think it wouldn't be that hard to find a used one for well under $50 or free in some cases on-line, yard sales, thrift shops, etc.. I wouldn't shy away from a tower or desktop if it came with a monitor, keyboard and mouse. Computer under the layout and separate monitor/keypad give you more freedom where to put things vs. a laptop. Sumner
Older versions of JMRI will run on old versions of Windows, but I think the latest versions of JMRI are more restrictive than that (need Win10 or later?) Go to JMRI.org to find out about system compatibility; JMRI is written in Java, so it's all about what the required version of Java will run on. Sometimes it is better to replace a really old version of Windows with a newer version of Linux (free) on the same computer, that can run the latest versions of JMRI. Also, a Raspberry PI model 4b or 400 (built-into keyboard, with safe shut-down function key) will run the latest version of JMRI just fine. A good USB thumb drive will suffice, but you can use USB SSDs too, but both require shutting down the OS prior to removing power. Laptops, with their battery, can shut themselves down (eventually) when AC power is removed.
Thanks, I just looked and it looks like 8.0 or later will work on most versions and 8.1 on almost everything if I'm understanding this correctly... ========================================================================================== Using JMRI requires a combination of hardware (in this case running Windows), Java software and a JMRI download for a specific version. The table below shows configurations that have been reported working - there may be other combinations that are also possible, but they have not been reported by the user community. JMRI® Release Windows Rel. Java Rel. Test release 4.x.y through 4.25.9 7, 8, 10, 11, Vista Java 1.8 ("Java 8") Production rel 4.26 7, 8, 10, 11 Java 8 or Java 11 (Recommended) Production rel 4.26 Vista Java 8 Test rel 4.27.1 7, 8, 10, 11, Vista Java 8 or Java 11 (Recommended) Test rel 4.99.x 8.1, 10, 11 Java 11 Production rel 5.0 8.1, 10, 11 Java 11 Test rel 5.x 8.1, 10, 11 Java 11 ========================================================================================== Looks like it is still easy to download earlier versions if someone wanted to do that. I'm not even sure what version I'm using. I used Steve Todd's Raspberry Pi image file that had it on. Really simple to use. Buy the Pi...put the SD card with the image file on it into the Pi's card slot....turn it on and JMRI comes up on the screen and start using it. I only use it for decoder programming and my roster for the wireless throttle so might never go to a newer version. Works well for all of that. I use the throttle and it sees the roster without me doing anything and I select a loco or multiple locos and run them. Pretty darn simple. I never thought to look before but looks like there are Pi3's and 4's on eBay for $25 and up. Sumner
The dual-throttle capability of Wi Throttle or Engine Driver is built into the throttle app, and is not dependent upon the DCC system. Any DCC system that has a WiFi interface*, or is connected to a computer running JMRI, can do it. *Until lately, with the advent of TCS' CS-105 DCC, WiThrottle was the only throttle protocol available for WiFi. The CS-105 uses Layout Command Control (LCC) which is a new NMRA standard protocol for throttles/apps and much more over WiFi or other media. LCC provides better handling when multiple throttles are involved (e.g. all throttles are aware of what locos are going what speed at all times, regardless of which throttle commanded it.) TCS command stations, even with WiFi interfaces, do not support the WiThrottle protocol, but can talk (via LCC over WiFi) to a computer running JMRI that can talk to WiThrottle compatible throttles/apps. At least one LCC throttle app is available for iphones, and others are still in development for Android.
Actually, I was mistaken. The CS-105's built in NCE Cab Bus interface supports the WifiTrax WFD-30/31 WiThrottle Protocol Bridge. With that, it can communicate with WiThrottle-compatible throttles/apps (though not as many at once as a WiFi router.)
I opted to got with the CS-105 combo with the UWT-100 throttle from TCS which arrived in June. I hope to have it hooked up later this summer and start playing with it.
Well done! If I decide to do that, I'll likely go with the smaller throttle (less $), and the 12V supply (N scale). I've been researching the system, RailCom, and LCC; and I'm very impressed.
The UWT-100 works with the DCC-EX CommandStation also. The throttle costs 10 times more than the Command Station! You might want to check out the EX-CS and see what the EX RAIL automation and animation capability can do for you. You don't need JMRI at all unless you like it for certain features. You create rosters, can run routes, have macro like commands to handles turnouts and signals all running from the CS directly. Built in support for different kinds of turnouts (servo, snap, DCC, virtual), signals with aspect control, sensors, outputs, CS status and layout station displays, I2C device support, etc., etc. The <DCC-EX> protocol is taking off too since it is simple to implement. Engine Driver, for example, lets you switch to that protocol seamlessly from the WiThrottle protocol which opens up a lot of features that are exclusive to DCC-EX.
I wonder what the market is for Railcom, especially in the United States? By the time RC and LCC could take off (Railcom has a following in Europe, but LCC has never taken off) I would think another wireless technology would take over. After all, all these technologies are ways to get around the design of DCC, which was a product of technology at the time and never accounted for where the hobby would grow, how electronics would shrink, and what radio spectrum would be available. Railcom solves the need for communication back from the loco while it is running on main. There are other ways, some perhaps better, to do this. Don't get me wrong, I like the idea of technology trying to solve a problem, but what percentage of the model train market has that problem? Just like with DCC-EX offerings, there are Tinkerers who would love to build their CS and those who would not. How many users out of all of traindom need more than 5A or need boosters? I'm not sure how to find out those answers, but I would love a chart that shows where people are in the hobby and what they need. I've found some data, like from polls magazines have conducted, but not enough. I think it is easy (for us especially being in technology) to see the people we interact with as being the market, but seeing the number of people that come to us asking questions and the kinds of questions they ask, a vast majority of the market seems to be non-technical and have small to medium sized layouts. As a matter of fact, that's why a lot of folks still haven't converted to DCC, they are fine running things with a transformer! Just to be clear, I am not arguing the point, I just really wish I could know real numbers. How many Zephyrs were sold each year for the last 5 years, for example? How many people have more than 10 turnouts, engines, 20 engines, once CS with no booster? How are they controlling accessories? What kind and how many? Maybe we could conduct more polls. The technology needs an update and I'm not sure when that is going to happen. I'm not knocking Railcom, I liken it a bit to how TV had to figure out a way to add color information to an already existing monochrome signal. The "colorburst" idea was pure genius, but gone now when digital TV replaced analog. In a similar way, Railcom tries to solve the problem of riding another signal on a continuous wave of power and data coming from the track. It's a hack, and one fraught with issues. A CS has to be aware of RC and actually short the track for long enough to use the resulting current loop to pass data back and forth, restore it, and try not to affect everything else going on. Maybe it's like not knowing how the sausage is made, stuff can still taste good (or solve a need), even if the hidden parts are a bit messy. And as a manufacturer ourselves now, seeing the fairly lax adherence to standards and poor build quality for a significant part of decoders and accessory items, I can imagine the problems, support issues, etc. as someone grows a layout with increasingly complex systems. Just look at the issues caused by auto-reversers. My mission is to solve issues of cost and complexity. I think there is another "c" word in there I can find to make my mantra roll off the tongue, but I think we need to do more for the non-tinkerers.
For most of us with medium to small layouts I wonder the same thing. Sounds cool but are you really going to use it on a smaller layout or maybe even a larger one. It is going to limit your choices on decoders. I see it for most of us being another 'bell or whistle' that might get us to look for a command station with it and maybe buy it but then never use it. I don't think you need more in the way of features for the command station (maybe your aren't suggesting that) for the 'non-tinkers' out there (a huge group). As DCC-EX stands right now it has as many or more features that actually get used by what I'm guessing is the great majority of us as any commercial product out there at way less cost. I've mentioned this before, going to the website ( https://dcc-ex.com/ ) for 'non-tinkerers' is too overwhelming in my opinion. I still think there needs to be a 'BIG' link' on the first page that takes someone directly to a page/pages where there aren't dozens of options but simple instructions to buy this.....connect this and this together...hit the 'auto-installer' and you have a DCC Command Station in an hour. All for about $70 or whatever a mega, motor shield, wifi shield currently cost. Have a link there to options if they want to go explore them. One doesn't need to save the last $10 by shopping for options that might or might not be a problem. Get the items on the list, assemble them and you have a proven, bullet proof command station. I know this is a 'hard sell' to some of the guys in the project. By the way if someone does need more than 2-5 amps they can add additional boosters for less than $60 that are dead simple to use commercial boosters. Sumner
Fred, LCC is quite young; so it is just getting started. But the concept of a bidirectional data link for track accessories has existed (Loconet) for a long time. But unlike Loconet, LCC is an open standard. The throttles on LCC (wired or WiFi) are automatically updated with each other's changes (like loco speed). So if one user needs to hand over a loco to another user, the recipient's throttle is aware of the original throttle's settings, lights, sounds, etc. for that loco. And rather than having to have your JMRI computer system handling signals and turnouts for you, the LCC bus nodes handle it cooperatively. You can turn off your JMRI computer, and everything still works (assuming you aren't still running any throttles or panels via JMRI.) LCC can handle the panels, throttles, switches, and signals, autonomously. Note: JMRI is still invaluable for configuring LCC nodes, as well as DCC decoders. RailCom, on the other hand, has been around awhile. It is ubiquitous on European DCC systems. The NMRA standard for it came from Europe (just like DCC did.) European DCC systems and decoders have RailCom built in. TCS systems and decoders have RailCom built in. But the two old guards (NCE and Digitrax) in North America either ignore it, or have their own proprietary, non-standard substitute, respectively (e.g. Digitrax transponding.) Another feature TCS command stations use RailCom for, is to confirm that speed command updates have been received and implemented by the locomotive, so the command station can drastically lower the frequency of static updates for that loco, which in turn allows more locos to get speed change commands more quickly. This only has real benefits for very large (club or show) layouts, but it improves responsiveness on them dramatically. But are RailCom and LCC the do-all, end-all for model railroad status and control? At least in N and Z scale, currently, yes. In larger scales, WiFi is or will begin to be used to wirelessly control locomotives, rather than via the rails. And eventually, that technology will shrink enough to support N and Z scale. And when it becomes a standard that different brands adhere to, it will eliminate the need for DCC and RailCom altogether. (WiFi is already used for LCC for some use-cases: e.g. throttles and command stations' links to computers running JMRI, etc.) Note that, as long as two rails are used to deliver power to the locomotive, auto-reverse polarity controllers will still be necessary. And when N scale WiFi mobile decoders become standardized and commonly available, I'll switch! I'm not gonna hold my breath, though. As for DCC system market size, it is apparently large enough for TCS to invest in. Hey, the "American way" is to build a better mousetrap!
