Well we are at a point where DCC has improved a great deal over the last several years. Sound has made some great inroads and decoders have improved features. Controllers have gotten better and the changes in applications have opened things like throttles in smartphones etc... So what do you think is missing? What improvements or enhancements would you like to see? I will start with my wishlist: I think it is time to add operational realism to the decoders/command stations etc. What do I mean by that? I means that things like fuel, sand, water all have decrementing counters that will cause the engines to run out of gas and stop. Or running out of water will cause a steamer to stop. There could also be a random failure as well. There could even be a timer that tells you it is time to change crews. From a technical standpoint, I would like to see better Command and Control. True command and control requires constant feedback. This is not really happening at this time. Perhaps a better communication protocol can be the outcome. Right now, a better command and control signal would send the instruction to the decoder, the decoder then would process the command, and once executed, would send an acknowledgement back to the controller. Once received, no more commands would need to be sent to that engine until there is a change of commands. In this manner, there would be a full feedback capability and also reduced traffic on the communication protocol. Right now all instructions are constantly broadcast to all the engines currently running. This is a great waste of the communication protocol. This would allow for a great deal more command capability on the protocol. This is where the things like consumables could be handled. Anyway, those are my ideas, what are yours?
Alpha numeric locomotive numbers. I have many ABBA consists that are the same number but have A,B,C,D suffix's. I hate the idea of having a legend to cross reference my engines. Randy
The user interface. C'mon, folks. Using a DCC system is like going back to the days of DOS in computing. JMRI certainly helps, but even it isn't terribly user-friendly on some things (try figuring out the Fuction Key assignment screen, with all the boxes, checkmarks, etc., etc.). Some of the European manufacturers (ESU; Zimo) have made strides, but their systems are more like Windows 98 in a Win10/OSX El Capitan world. Better, certainly, but still creaky. What things would I like? First, you should be able to hook up a scale speedometer to the Command Station and tell it to program the loco with a top speed of 70 and have it do it for you, at least with a linear curve. No more CV2, 5, 6, speed table, etc. You should also be able to have the command station run the loco through the speedometer at each speed step and store the speed curve. Then you should be able to put a different loco on the track, select a command from a drop-down menu that says "Match speed to Loco YYYY" and it does it. Automatically. Same thing for function reassignments. Drop-down boxes: Pick F1, use a drop-down to assign the action to F1 (ESU already does this). Same with lighting effects. Everything should be a simple point and click. And you should be able to load a template to reassign function keys for any decoder to a common scheme. No more "Hmmm, is F5 the Mars light here? Or F7? What key turns on the dynamics" etc. Again, JMRI does SOME of this, but even it is too complicated. ESU does some of it, too, but you have to be conversant with "sound slots" and what's in them. Sorry, that's not good enough. I should be able to click on "Horn" and click on "50% of full volume" and it happens. Next, all command stations should have built-in WiFi and Ethernet to connect to a network and a computer. We're getting there on this one - again, the Europeans were there first, but finally we see Digitrax going this route with the DCS240. But it's not enough to have it at your highest end. Everything should have it; if you can buy a fully functional computer (the Raspberry Pi) for $35, every entry-level DCC system should have this capability. All walk-around throttles should be wi-fi capable. No more wacky proprietary radio-control systems. WiFi is ubiquitous, common, cheap, and standardized. The ESU Mobile Control II is a great throttle, but it is too expensive. You can buy a fully-functional 7" Android tablet for a third or half the cost of the MCII. All decoders (not just sound decoders) should come with an easy and standardized way to attach keep-alive. A two-pin micro plug would be nice. I could go on, but this list would be a good start. John C.
A lot of what you are asking for is all ready here. Railcom is a NMRA ratified feature that is already present in a lot of European systems now where the actual speed of the train is shown on the hand throttle (Zimo) and decoders keep track of the amount of 'fuel' on board (Hornby Sapphire decoder). Roco should have the Wi-Fi handset in the shops soon. Ethernet is slow in coming, but it is likely to be eclipsed by Wi-Fi built in to the command stations now that Wi-Fi is becoming the dominant radio throttle protocol that people actually use. Looking to the future it would be nice to see some standardisation on decoder sockets. The PluX system works for pretty much everything smaller than Gauge 1 and has the biggest number of function outputs so it would be nice to see that flourish and the myriad of legacy sockets disappear - especially Next18, MTC21, and anything without a speaker connector! Every time one of the legacy sockets is used we have to buy a more expensive version of the decoder. Suzie x
Lenz were first to market with stay alive with their 3-jst connector which was quite convenient at the time - but they were ignored and subsequent manufacturers all did their own thing. At least with Next18 (cough, cough) and PluX the stay alive gets wired to the loco just like the speaker because the stay alive interface is part of the standard decoder connector. Suzie x
Hi Suzie, None of what you provided us, thank you by the way, is currently available with US manufacturers. Zimo and ESU are miles ahead of Digitrax and NCE, but they are still not all the way into what they need to be. I would love to see either ESU or Zimo do N Scale board replacement decoders.......
I would like to see the decoders speed match automatically. Set a base loco and the rest in the consist would constantly adjust to match up the speed and braking.
Continue to advance in more user friendly and system reliability . The other things mentioned were also nice but these two for the less savy these two would go a long way
Guess I'm still in the stone ages. I operate DC only and being that I'm a lone operator and my layout is built mainly for switching, I have no plans at all to change to DCC.
I would like to see a lower cost on decoders. The basic decoders are down to about $14 which is great. If we could get sound decoders down to $20 or $30 the younger crowd would be able to purchase more. Sent from my SM-G920P using Tapatalk
I agree. I should not have to become an expert in a sub hobby in order to program a decoder. Give me the ability to tell the decoder what features are utilized in simple terms and how I want them to operate. Maybe even with a suggestion on how the prototype would run. JMRI helps but still requires some tinkering and knowledge. I don't care what CV#'s are.
While I'm a big fan of DCC, your situation (a single operator with a switching layout) really is one in which it doesn't make a whole lot of sense. Once you get multiple operators with multiple trains running at the same time; or need to speed-match engines from different manufacturers (or even from the same manufacturer) for a multi-unit lashup for a train; or want to have power sitting in a yard on ready tracks while a couple of switchers do their thing from opposite ends, then DCC becomes almost indispensable, IMHO. John C.
Zimo decoders and ESU decoders have almost this in place. Zimo decoders have the ability to self program for speed. It just needs a length of track related to scale to do this. All that needs to be done is to turn the front headlight on at the beginning of the calibration track and then turn it off at the end of the track. You enter in what the speed you want is and the decoder recalculates the speed table to give you that speed. No CVs needed.
Here are some additional changes that would make DCC more performant and be "under the covers" so the users would not have to worry about it. One of the biggest problems with DCC is the overloaded signal package. In the signal pulse all throttle commands, accessory commands and motion decoder commands are stuffed into one data pulse. I have seen issues with this in the form of delays in command execution. How we can change it is to adopt an additional protocols for throttles and accessory devices. The beauty of electronic communications is that any number of signals can be sent down the wire and be completely isolated from each other. The current protocol can stay for the Motion Decoder and Sound Decoders. A new Throttle protocol using 27 KHz PSK (Phase Shift Keying) that could run on the same wires, out of the same controller. Advantage - less of a limit in throttle counts in the command station, could be thousands instead of hundreds. A new Stationary Device protocol using 23 KHz FSK (Frequency Shift Keying) that also can run on the same wires, out of the same controller. Advantage - less of a limit in throttle addresses and command station addresses for Stationary Devices None of the wiring needs to change, and there could be allowances for legacy equipment so previous equipment can be handled without major upheaval. It would be a simple task for the system to poll its resources and identify all of the devices. It would the determine which of the devices can use the new protocols and subtract those addresses from the current protocol and broadcast the other protocols as needed. If there are no devices fitting the new protocol structure, the system can the default back to the current protocol where everything is sent in every pulse. The current protocol has limits to the amount of information it can package into each and every pulse. By extracting the throttle and stationary devices into their own signal protocols, more of the space in the decoder protocol can allow for active addresses. The 120 slots for the Super Chief would not be an issue any more. Even the new Digitrax controller, DCS 240 with its 400 active slots and throttles is just moving the additional slots to stay resident in the throttles, not in the command station. So it is just a shell game. If you don't have the correct throttle, you get none of the extra slots for your locomotives. While I am not using this device yet, the question arises in my head, if the extended slots are in the throttle and I have the throttle running a train and the battery dies, what happens to my train as I change the batteries? I am not knocking the approach, I think it is a step in the right direction, and I do like the three Loconet ports, they only issue there is the the same signal is coming out of all three ports at the same time. There is no true isolation of the different types of command traffic. Perhaps none of this is needed for most folks, but as an engineer, I like to see things built correctly. Because you never know when you may need the functionality, like the new LCC (Layout Command and Control) specification for non-motion devices. But this is just a protocol handshake, it is not a truly separate protocol. It is funny, we have seen this type of signal isolation daily in a very common device known as a television (Pre HD, I have not investigated the HD signal it may do something similar). The video and the audio were sent isolated from each other in frequency space. So this is not any sort of radical idea. It has been done over and over again in all sorts of electronic devices, so this is not new or ground breaking. It is just engineering a better overall system.
I am very interested in the up and coming "LCC" protocol. (Layout Command Control), that takes the load off of DCC for supplemental loads/accessories. I am seriously considering on my current layout having 2 separate networks for pure train control versus accessories items like turnouts, signals, lights, etc. I really like the concept of separating DCC for train control and LCC for accessories.
We have to remember, DCC is only one way to control model trains with digital technology. That is the NMRA version. While DCC is only one of several alternative systems for digital model train control, it is often misinterpreted to be a generic term for such systems. Below are some. https://en.wikipedia.org/wiki/Digital_model_railway_control_systems Rich
JRMI is evolving and getting better, but it has some fundamental design issues. Personally, too many applications like JMRI, iTunes and others try to mimic database operations using XML files. The end result is fine until you reach the tripping point of the approach. This happens with volume. But there are more high end train control applications but they come at a significant cost. Your idea about suggesting that the application/decoder suggest settings for you is a good one. But the problem is, how would it know what locomotive it is or what road name it is without a good database engine? Still one of the suggestions I would have for you is what I did to make life a little easier. I create locomotive templates in JMRI. These have names like Kato_SD40_DN163K1B or Atlas_TCS_AMF4. That way, when I need to program locomotives, I can just clone the proper template and apply a consistent set of CV's so that they they should run together a little easier. The work is setting up the templates, but since the number of decoders is rather small, and the number of models for a decoder can be pretty large, so it can boil down to a few templates. Using an approach like this is adaptable to however you want to run the locomotives. The speed tables are what can make all the difference, and TRIM is the icing on the cake. In this manner I can set all of the speed tables to move the locomotive the way I want, and then I can adjust them to the top speed I want with the trim. As an example, the speed table for an F7 freight and an F7 passenger can use the same base speed table, but the top speeds can differ based on trim. In this manner, if a passenger locomotive gets reassigned to freight duty, all you have to do is change the trim to slow it down. So by looking at different ways of using JMRI, you can make it a lot easier to use. And hey, you can always ask me, and I will email you a couple of templates to get you started.
Why can't the decoder plugs between the steam engine and tender be black plastic instead of orange !!
Just one thought. If we go and make it to ... complicated, it will eventually be to expensive. DCC pushed it's way out of my marketability a few years back and as such I will continue to operate with Analog DC. Perfectly happy with the performance I get. Now my older, ancient MRC DCC unit will remain hooked up but I don't have a locomotive one or a diesel two that I can operate with DCC. So, it's pretty much a forgone conclusion that it is useless on my layout. Fun while it lasted but when both decoders gave up the ghost I let them find the bottom side of a trash can. Done, finished. You guys and gals keep making it better and more realistic and yes you will satisfy this hobbyist's desire for better. I just hope it will be appreciated. David E.. not only has templates but PDF's he can send you and you can keep them in your personal files. Oh, and this is not a plea for help. Perfectly happy with what I have. Have fun!
