RailPro vs conv DC

Pete, I understand why you did not want to hijack the RailPro thread however the question posed there is specific to RailPro because of the continuous full voltage DC on the rails. Conventional DC with its varying track voltage likely has more issues than a DC system that maintains full voltage on the track.

With that said I don't know if the Ring DC vs DCC track cleanliness comments belong here or there although I am very interested in the subject. The pure DC on the rails is a feature of Ring that I believe has true merit.

I'm Sure I can Post This

This is what Tim from Ring sent me some time ago, and I think it is posted on their site somewhere, too:

So, again, its only theories as to why, but their experience certainly shows a significant difference.

Thanks Dave.

  The paragraph by Ring starts out with the testing of the end of train device and not necessarily the railpro system. The blinking light is attached to a truck with pickups mounted to a car that could possibly weigh 5 or 6 ounces. I can see how any accumulation of any substance can cause failure. Even a small diesel switcher will weigh more and have more pickups for better reliability. Our club switched to DCC seven years ago and with three or more ops sessions a week plus people just running trains here and there we still have not needed nothing more than a wipe with and alcohol dampened cloth. The DC powered N scale layout needs constant cleaning. 

  Again you have to consider the source. Ring is in competition with its nearest competitor and that is DCC. It is obvious that he has no worries with the other proprietary MTH DCS system.

    My thoughts.

        Pete

I run DCC on a small layout.

I run DCC on a small layout. Many days I will run continuesly for 2 or 3 hours at a time. My current layout has ben up for about 5 months, and I think I cleaned the track (except for a couple spots ) once. I run mostly metal wheelsets, and just don't see any black gunk. Previous layout was running for 3 years with DCC and stock plastic wheelsets. That layout I did clean a few times a year. .....Mike

...

You really have to back up and consider what you are calling DC and what you are calling DCC.

The biggest reason for this issue is because as hobbyists we like to think that the Power and Control are the same thing.  They're not!

Power is just the voltage we use to run what we want to run.  Commands are what we use to control the trains.

In the old days, we controlled the trains by varying the system power - so when we dropped the power on segment A to 30%, all units in segment operated at 30%.

DCC uses frequency variation to supply a digital square wave [square or rectangular is a moot point, seeing as how I was taught that it is a square wave similar to how that big L shaped thing is also called a Square; the corner of a perfect wave would be 90 degrees to the normal vector is all 'square wave' means."] on top of the voltage. We can vary the length of this square wave as one means of communication, and we can also establish a set length as a "standard character" and then compose langauges out of that character.

Either way, this allows us to place a unique controller within the heart of each locomotive between the power source and our preferred loads.  This means we can now vary how much power goes to the load without varying the power level on the overall system.

There is a minor issue here whereas the more dirt in your transmission line, the more deteriorated your square wave becomes.  If the decoder cannot read the message, it reverts back to the null value.  What is the null value?  Set any locomotive [DC or DCC] on your DCC system and watch: it will just sit there [at least, on Digitrax, a straight DC locomotive will sit there and wait for commands from address 00].  If there is a sound system, the Idle sound will play.  This is the Null Value.

So this being said, if the decoder cannot read the DCC message, this is very bad.  DCC tries to rectify this by sending a series of three pulses [it repeats the message three times] within a couple microseconds. The problem is, the "Dirt" in the system may be enough to cause a millisecond disruption - enough to make your locomotive stall for a second before the decoder re-establishes contact with the command station.  This can be particularly bad is you have a sound decoder, hence the sound sequence resets every time you stall/null out.

There are two place where we have issue: the Wheels to rail interface, and then the Wheels to pickup interface.

In the old DC days, we DID have dirty Track problems - but then, there were a lot of people still running Plastic wheelsets!!  Doing so, I still remember removing a crude of black something from my locomotive wheels, it was bad... Most of the dirty track problems vanished once those wheel sets were banished from layouts.

But let us consider this one: we used to have no issues with only half of the wheels on a locomotive being live; now you see people rushing to put pickup on all wheels, both tender and locomotive...

So now we have rails so clean that the only way you can tell they're dirty is by wiping the railheads with your fingers.  And the solution now is to polish the railheads as one would any other electrical circuit, to re-nickle plate the wheels, to add as many pickups as one can cram underneath the locomotive.  0-4-0s are the least forgiving locomotive you could have...

DC Power is GREAT!

And DCC Control is GREAT!

But sending DCC control through the rail interface...perhaps not so great...although the interference issue may come around to nip the air in the bud.

And so we embark on the Wireless adventures, as now presented to us by both Ring, Tam Valley, and a couple others.  Tam Valley provides us with a rather useful decoder that adapts any DCC decoder to a wireless system.  And Ring reinvented the wheel with a whole new decoder that only works on their control/receiver system.  There are considerable technological upgrades within a RING decoder not found any/many other places, so it does represent a leap and a bound in the right direction.  At the same time, Tam Valley's device is a breakthrough in and of itself that would eventually allow DCC to take full advantage of the technological advances within a RING decoder, providing a road that would eventually lead to a decoder with a tam-valley adapter built right in [in an ideal world]. 

If Ring wishes to exercise arguments that they somehow own the technology to two-way decoders that talk to each other and the parent system, they'll have to talk to Zimo who accomplished the feat of two-way decoders first...

Interesting to note

It's interesting to note that the Tam Valley device is a breakthrough in that of miniaturization.  Radio send/recv has been in our hobby for years, just not really small enough for some scales.  All the Tam Valley device does is take the 1's and 0's on the track and broadcasts/receives them via radio.  That's it.  As simple as that is, it will allow for retro fitting existing DCC systems to radio control at a very reasonable cost.

DCC is open but RailPro is closed, so if Tam Valley's device ever is able to 'take advantage' of a RailPro decoder, then the RailPro decoder would have had to have been upgraded to 'speak' DCC, which only Ring can/could do... not Tam Valley.

THIS is why Ring needs to make a RailPro/DCC bridge.

[/thread-derail]

I would be very interested if a club performed some sort of study to bring some less nebulous facts into the DCC vs DC clean track discussion.  Even if it's as simple as one of those Bounty paper towel commercials showing how much they clean versus the competitor.

"We see here on the DC track cloth that it is noticeably cleaner than the DCC track cloth".  Perhaps even with the Double Mint Twins presenting the results.

Double Mint Twins

I too like the idea of hard data. Easy enough to imagine a test. Two loops of new track, two new identical locos, DCC horn/light commands being sent, run in circles until failure occurs, wipe with Bounty.

However, it may be a moot point. No one makes the claim that DCC makes track cleaner than DC. Only that DCC may make track dirtier than DC. For Ring Eng type applications the test is of no value regardless of the outcome. Furthermore, even if the data were to show DCC does in fact make track dirtier, is anyone really going to go back to DC giving up all the DCC features just so they clean track less? Doubt it.

While I love hard data derived from a controlled experiment I question the need to do it within the context of this subject since its outcome is not likely to influence behavior. Maybe all that is needed is a quicker picker upper!

Flywheel Inertia

So far I do not see anyone challenging the original premise that DC somehow carries more inertia in the flywheels and thus in the drive train than DCC. 

Uhh . . . unless the laws of physics have changed, the inertia in the flywheels is directly proportional to the rotating velocity of the flywheels.  And, it just so happens that the speed of the locomotive is directly proportional to the rotating velocity of the flywheels, since the gear ratio is fixed.  Thus, a locomotive moving at 30 MPH under DC has the exact amount of inertia in its flywheels as the same locomotive moving at 30 MPH under DCC.

So, sorry, I don't buy this part of the DC is better argument.

However, it may be a moot

The track isn't cleaner with DC running in the rails versus DCC running in the rails.  The difference is the amount of disruption that you can have in the rails [dirt] before the system can no longer communicate.  You'll have Electrical Continuity a LONG time after you lose Digital continuity, which is why you get stalling on DCC.  As soon as the locomotive loses contact with the command station, the decoder reverts back to the Null position - and stops.

What more, Nickel Silver "Dirt" is supposedly Conductive of Electricity.  It is not Conductive of Digital Command Signal.

The TAM Valley Decoder will never be in a position to take advantage of the Railpro decoder, and that's fine.  If you look at the Railpro decoder, you have a DCC module [but it perhaps doesn't even speak native DCC] tied to a microprocessor and a Send/Recieve device.  the TAM Valley route is a perfect manner by which all DCC manufacturers could implement the concepts behind a Ring decoder without running up against Ring.

The Breakthrough that is the TAM vallue device is the fact that accepts any DCC decoder.  This means you can now upgrade the TAM Valley component to include a processor and all those other wonderful 2-way gizmos found in a Ring or Zimo decoder - AND still make use of any and all DCC decoders on the market.  We have to keep in mind that the DCC decoders on the market are just motor/output control devices, while decoders like Ring and Post TAM valley are closer to being full blown modern computer devices.

From what I've heard, the DCC decoder supplies an electrical voltage to stop the motor in place.  The flywheel only works if it is allowed to come to rest on it's own.  if an electrical break is applied, you're going to get No Coast.  A mass in motion stays in motion unless a force acts upon it, and in this case, that force is a counter-electromotive force opposite to the direction of motion.