I've recently read http://www.ringengineering.com/RailProToDccComparision.htm.It suggests that its newer technology is better than DCC. The controller certainly has a more sophisticated graphic touchscreen display and it seems that its decoders take full advantage of 2-way communication and measurements of motor performance.I wonder what DCC controller features would be possible if all DCC decoders on a layout support 2-way DCC communication (NMRA RP-931-1) or require additional decoder features: - self discovery of all DCC decoders - would this require that all DCC decoders have unique addresses like Ethernet MAC addresses? - would controller ability to measure decoder current or back-emf allow it - to provide more reliable smoother slow speed control? - to self adjust for consisting - what advantage does wireless locomotive communication provide since electrical contact with the rails is required for power?are there features missing from the DCC standard, possibly in non-standard decoders, that could be easily added to improve DCC performance (i.e. DCC version 2), or would having decoders that support all features of DCC be sufficient?
greg - Philadelphia & Reading / Reading
DCC will continually evolve as new technology becomes available, just as computers are continually changing. The next big step for DCC would be battery technology capable of running our models with on-board power for an extended period of time between recharge, but that is currently available only in the larger scales (G, for example) that have room for Lithium battery packs.
I have an HO scale steam engine equipped with Ring Engineering's RailPro decoder that I run on a DCC powered layout instead of using their DC power pack. The biggest advantage to their system is the two-way radio communications between controller and locomotive which doesn't rely on commands being sent through the rail.
I remember hanging around the pool at my apartment complex, talking with a guy who worked for one of the big battery companies. We both believed that we were due for a big breakthrough in battery technology, as the batteries we'd been using for years simply hadn't gotten much better for decades.
That was in 1970. Yes, we've seen the development of better rechargeables, and alkaline batteries are now standard, but as for that big breakthrough? I'm still waiting.
It takes an iron man to play with a toy iron horse.
gregc I've recently read http://www.ringengineering.com/RailProToDccComparision.htm.It suggests that its newer technology is better than DCC.
I've recently read http://www.ringengineering.com/RailProToDccComparision.htm.It suggests that its newer technology is better than DCC.
Rich
Alton Junction
The next big break through is going to be in the Super Caps used as Batteries!
They recharge in seconds instead of hours!
Have ZERO memory (where like Batteries which slowly die because of subsequent recharingings)!
They can be set up in banks of multiples to get what ever capacity you need (NOT what some MFG thinks you need).
Do a Google search on Super Capacitors!
BOB H - Clarion, PA
cacoleDCC will continually evolve as new technology becomes available, just as computers are continually changing.
I wasn't asking about changes/improvements to the standard, but taking advantage of existing features (2-way) that not all decoders support.
I also assume that DCC can be supported over RF instead of electrically thru the rails if batteries provided power.
New battery tecnoligy is here but it needs to be produced in larger number to bring the price down and of course everything needs goverment approval.
Every once in a while, someone comes up with a "revolutionary new idea". The problem, though, is that they are single-source new ideas, which creates a whole set of issues. Think of all the single-source command control systems that were around before DCC, how much market share they had, and where are they now?
The thing that killed them was the NMRA's DCC standards. Those standards meant you weren't locked into a single source any more. While that was bad news for those single-source command system manufacturers, it was good news for command control users. All those single-source issues were now gone!
I'd be willing to bet the market share for DCC (total of all manufacturers) is much higher than the combined market share of all those pre-DCC, single-source command systems.
The Stanton system and the Tam Valley stsem both are DCC via RF, in that they transmist standard NMRA DCC packets over their radio systems, which is why their radio receivers hook to a standard DCC decoder.
I'm sure we can all think of neat things that could be done with a full 2-way communications system, but I have to ask, does it REALLY matter? A pure RF system would eat up nearly as much power sending RF data back as it did turning the loco's motor. I'd rather have more run time than know how mnuch coal and water my loco has consumed.
As for batteries - no breakthrough since the 70's? In the 70's they didn;t have litium ion and lithium polymer batteries. No way would you have been able to do some of the thiungs we do today - small phones with more computing power than anything in the 70's. Small battery powered RC planes. The small quadcopters. Battery technology has come a long way in terms of energy density since the 70's.
Super caps though, will be the way to go. A couple of the radio control systems allow charging from live track, but only if you use NiMH or NiCad batteries - LiPos need carefully controlled charging to avoid sudden catastrophic failure. For me, this ability to recharge or run off track power is an absolute must, unless the power source will be able to last for several hours. Having powered track makes it much easier to keep the locos charged up. COmplex trackwork like a reverse loop? Just insulate the rails and don;t bother to power it.
The big question is signals. How would you do track circuits when not all the rails need or would have power flowing in them?
Finally, I just do not like this video-game style full color with graphics display screen on the cabs. Seems pretty pointless to me. I have over half a dozen RS-3's. So what do I do, scrtoll through the 6 different pictures to select the loco I want? All of them have 3 digit road numbers, so it's exactly 5 button presses with a stanadrd DCC throttle. Scrolling through the pictures is easier? Hogwash! When I want to play video games, I play video games. When I want to run my trains, I run trains.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
- would controller ability to measure decoder current or back-emf allow it - to provide more reliable smoother slow speed control? - to self adjust for consisting
The decoder (at least in most high-end decoders) already reacts to back-emf and motor current. How it reacts is determined in the decoder programming and configuration values (CVs). In the old days, before DCC, some transistor throttles used motor current and back-emf ("feedback") as signals to be combined with throttle inputs to generate the motor signal. Basically the same signal processing, but being executed at the throttle instead of inside the locomotive.
From a technical perspective local signal processing results in fewer issues from communications link failures (momentary and longer). At-the throttle processing may - depending on throttle design - allow more on-the-fly alteration of the feedback equations and its impact on throttle input. But do you really, really want to be performing the equivalent of CV alteration at the same time as you are trying to control the train.
The smoothness of slow speed control is partially deterimined by the physical running characteristics of the locomotive, and partly by the execution of throttle commands (controlled by CVs in DCC decoders). Again it makes no difference in locomotive performance if the throttle command execution control is performed locally (DCC decoder) or in the throttle.
The difference in systems as to processing location determines what is required for the communications link. The more processing is done by the throttle, the more complex the communications link must be if any feedback is to be used.
I'm not sure what you are looking for in "to self adjust for consisting". I don't believe I would want automatic adjustment of speed tables within a consist - the program would likely have different priorities than me in setting up the new consist speed tables.
- what advantage does wireless locomotive communication provide since electrical contact with the rails is required for power?
If the rails are used for power only, a temporary interruption can easily be handled through an on-board roll-over power source. Interruption of the communications link is a lot more of an issue. Wireless communications comes with its own set of issues and potential interruptions (scenery, antennas, etc). And of course, comms through the rails has to deal with dirt and less than perfect continuity, too. I can't say one is significantly better than the other.
- self discovery of all DCC decoders - would this require that all DCC decoders have unique addresses like Ethernet MAC addresses?
Again, I have to wonder what you really want here. When I power up my PowerCab, I see the DCC address of the last locomotive I controlled (if it's still on the rails). To change locomotives, I input the DCC address of the locomotive I wish to control. Typically, the painted-on locomotive numbers are used for the DCC address to make things easier for the operator - but I can choose any numerical address I want within the specs. Surely you do not want to consult a look-up table of MAC addresses (or other unique address database) to select a locomotive. If you didn't buy a locomotive new with the unique address already in the database, how do you get an entry into the database? How many weeks do I have to wait for my locomotive to be established in this database after I install a decoder?
Transponding (2 way comms) has been a Digitrax feature for a few years now. Yet very, very few layouts are built or structured around what transponding can provide. It's just not seen as that valuable a feature by a large majority.
I'm not saying DCC is perfect - it's not. But most of the initial issues have seen some degree of resolution because the relatively open standard allows refinement by many developers, not just one. And there is enough flexibility to fit a wide variety of user layouts and preferences.
just my thoughts and experiences
Fred W
The owner of my Local Friendly Model RR shop in Minneapolis said most modelers are barely capable of changing the address of a decoder. Notice how many sound equipped locos have a physical control for sound?
99 % of users use 1% of the functionality. Simply consisting diesels and having the headlights of all four units respond correctly is a major achievement.
Disclaimer: This post may contain humor, sarcasm, and/or flatulence.
Michael Mornard
Bringing the North Woods to South Dakota!
richhotrain gregc I've recently read http://www.ringengineering.com/RailProToDccComparision.htm.It suggests that its newer technology is better than DCC. I read the article, but I'm not convinced. DCC seems fine to me. If it ain't broke, don't fix it. Rich
I read the article, but I'm not convinced. DCC seems fine to me. If it ain't broke, don't fix it.
Exactly..That whole article sounded similar a old time DCC sales pitch from years ago-remember those?
Larry
Conductor.
Summerset Ry.
"Stay Alert, Don't get hurt Safety First!"
Bayfield Transfer Railway99 % of users use 1% of the functionality.
I agree that existing DCC capabilities are under-utilized.
Bayfield Transfer RailwaySimply consisting diesels and having the headlights of all four units respond correctly is a major achievement.
rather than programming CVs, could a more sophisticated controller provide a user interface where the user indicates what he wants programmed (e.g. headlights) and the controller figures out what CVs need to be programmed and their values? (is this something JMRI does)?
as for consisting ... multiple locomotives must be consistently configured to actually travel at the same speed when set to the same controller speed setting.
during a speed configuration procedure -- possibly running two disconnected locomotives at various speeds at the same time -- could a more sophisticated interface allow the user to indicate that a target locomotive is running slower/faster than the 2nd locomotive and let the controller adjust Cvs to match the speeds of both locomotives?
My point is that while the controller/decoder use CV to configure/tune operation, the user doesn't need to with a better user interface (e.g. when you select a TV channel, you don't specify frequency or decoding formats).
I also wonder if the controller could request that the decoder report back-emf or current of each locomotives in a consistent in order to make minor adjustments (load balance) of specific locomotives in the consist or even just recognize/indicate that there is a mismatch.
Of course this might require decoders that such a feature (which may nto be a DCC feature).
Bayfield Transfer Railway The owner of my Local Friendly Model RR shop in Minneapolis said most modelers are barely capable of changing the address of a decoder. Notice how many sound equipped locos have a physical control for sound? 99 % of users use 1% of the functionality. Simply consisting diesels and having the headlights of all four units respond correctly is a major achievement.
What the real problem with most people today is that they EXPECT the MFG to do all of the thinking for them.
They just want to turn it on and go (actually most don't want to even have to flip a switch)
Most of the members of our Club are not interested in learning to program DCC.
They have a few that can do it and are satisified in having them fix things when the Decoder forgets its programming.
This does not seem like a good future if no one wants to THINK any more - and that is just what programming a decoder requires!
Keep on dumming down things and we won't have to send the kids to school anymore as we will expect someone else to tell them what to do as their smart phones will answer every question thay could possibly ask - that is if they ever learn to talk!
cmrproductsthat is if they ever learn to talk!
Shoot Bob,all they need to learn is the code for texting.
-----------------------------------------------------------
If all they want to do is go then DC is the thing for them-just turn the knob and go!
My Tech 6 in the DCC mode has taught me the advantages of setting CVs for slow speed switching with momentum and start voltage.
I made some boo-boos and miscalculations and had to reset the decoder to its factory default and that easier then texting a message..
Automatic speed matching is a reality with JMRI today. There are speed match scripts that work with either commercial speedometers or just by feeding in a distance between two block detectors on your layout.
If there's anything I see way too much of - it's an emphasis on speed matching. Somewhere along the line, when people realized what you CAN do with DCC, it got turned into one of those model railroading myths "you MUST" Pre-DCC, there was no speed matching., You could throw some diodes in the motor circuit of the fatser loco, or remoter/regear some to match, or rework every brand of loco shell to all work on the same brand chassis.
Close is good enough, there is zero reason or requirement for all locos to be in perfect lockstep. Close is good enough. This is yet another thing that irritates me about Tsunamis, not supporting the simple 3 step speed adjustment using CV2, 6, and 5. Outside of those factory equipped really horrible Bachmann motor only decoders, a Lenz model from 15+ years ago, any other decoder you buy today has those 3 CVs supported. Stupidly simple to match speeds using those three, instead of trying to mess with 28 entries plus forward and reverse trims. I have yet to ever set a speed table in a decoder - all the ones I use support the 3 CVs, and it is an easy job to set the top speed to something realistic, and adjust CV2 so they can creep at step 1.
gregcI also wonder if the controller could request that the decoder report back-emf or current of each locomotives in a consistent in order to make minor adjustments (load balance) of specific locomotives in the consist or even just recognize/indicate that there is a mismatch.
I use MTH's DCS system for my O-guage equipment. It communicates 2-ways through the track. Lionel TMCC has a functionality where you can one-way communicate to the locomotive through the hand rails along the side of the boiler on certain steam locomotives which are actually antennas(doesnt work when used in conjunction with DCS remote, that goes through the tracks). Pretty slick if you ask me, only problem is not all guests watch where they set the controller with the long antenna.
gregcrather than programming CVs, could a more sophisticated controller provide a user interface where the user indicates what he wants programmed (e.g. headlights) and the controller figures out what CVs need to be programmed and their values? (is this something JMRI does)?
Check out TCS WOW sound steam, and soon to be released diesel sound decoders. You press a button on your DCC remote and the locomotive talks to you. The display at the NTS was amazing. Price tag is the only drawback that I can see.