DCC Bus

Frank Gallagher

Frank Gallagher

Well matured physically if not mentally
I've been reading about DCC Buses, basically a ring main under the layout to provide multi track feeds. It recommends that the bus is not continuous (so its not really a ring main its a spur) and also if your track is continuous there should be a break in both rails at some point, never heard of this before does anyone out there do this? And why?

Quote from website

Adding a break or gap in your DCC bus wiring also means that you should also do the same in your track. What this means is that a continuous circle of track must have plastic or insulated joiners in both rails at some point in the circle to break the loop. We recommend that this is put in a similar place to the break in the bus wires, which should be equidistant to the controller feeds.
 
Depends on your viewpoint, the NMRA standard and recommendation was to always ensure the track and wiring for the DCC signal was never continuous.

This in part is because the DCC signal is made up of voltage and data packets, and stray and corrupt packets can disappear out into the ether, and not continually clog up the network with redundant data packets colliding with instructions being sent between sender and receiver.

Is it necessary in G Scale, again depends on how well you view your own operation, on Die Eichel Bahn the NMRA Standard was followed, and it's day to day operation is faultless, little or no voltage loss, and instructions sent from the Massoth 1210Z Central Station are acted upon instantaneous, no time lag, no lost commands.

Which in this case was, all the cabling is copper stranded wire, cables were twisted together every few feet, this reduces inductance, laid on the surface, and a DCC Terminator was fitted, made from a 104 capacitor and a 2 W 150 ohm resistor.


For further information refer to the various NMRA Standards for the implementation of DCC.
 
Last edited by a moderator:
But 'Arthur' having said all that..
Not many people do it that way..

DCC differs from Ethernet, in that there is no acknowledgement back to the Central Station.. The CS sends a command a number of times (eg. 'loco address 6 got to speed-step 6), and hopes it gets there and is acted on.
Anything which makes it more likely the data packets will get there in one piece, and be acted on, has to be a good idea.
 
Yeah I read the recommendations that the bus shouldn't be a ring. To be honest though, for me it's more important that the voltage drops are minimised by feeding both ways round my main loop as a ring. On the other hand my trackwork had a few section breaks in it as it was built to accommodate analogue DC running if I so desired. In DCC mode all sections were left on. Either way I've never noticed any problems.
 
Never had to do it with LGB (MTS2).

With nice chunky code 332 rails you don't really need a separate bus either, although some folks like to do the belts and braces thing....
 
One thing about multiple feeds and "gaps" is that it can make it easier to diagnose problems. If your whole 200-foot track is one "circuit" then you've got to check the whole thing if there's a short. If you've broken it into four sections, you can disconnect them one by one and narrow it down to one particular 50 foot section and just look there for the source of your problem.

That said, I have a single "bus" that parallels the track over the entire layout, with multiple feeds along the way. There are no gaps, and everything has screw-clamp joiners. My focus is on ensuring that there aren't any unfed sections and that the whole track (even parts far from the command station) has a sufficient connectivity to throw the breaker if there is a short.
 
Does anyone know if the 'self-resetting' fuses we recommend for battery loco's (the blue rectangular things) will pass DCC signals OK?
 
Not making it continuous help avoid problems with a command taking 2 different routes and getting to a location at 2 slightly different times.

It has nothing to do with bidirectional communication, although that would ADD more issues.

Anyone old enough to have used an off-air TV knows what ghosts are, and this was the result of receiving the same signal twice, at slightly different times.

Another example, getting multiple echos from shouting in a canyon or hall.

So don't make it continuous, best practice. If you do, will you have problems? Maybe, maybe not.

Greg
 
PhilP said:
But 'Arthur' having said all that..
Not many people do it that way..

DCC differs from Ethernet, in that there is no acknowledgement back to the Central Station.. The CS sends a command a number of times (eg. 'loco address 6 got to speed-step 6), and hopes it gets there and is acted on.
Anything which makes it more likely the data packets will get there in one piece, and be acted on, has to be a good idea.
Click to expand...
That's not strictly true Phil. Most of the current generation of DCC systems have some sort of decoder feed back, be it Railcom (+) or Marklins MFX protocol etc.
 
Greg Elmassian said:
Not making it continuous help avoid problems with a command taking 2 different routes and getting to a location at 2 slightly different times.
Click to expand...

Yes that is true. When packets arrive at slightly different but overlapping times both are likely to be corrupted and both thrown away by the receiver in the decoder.

Not sure it makes much difference in practice though as it is normal for some DCC packets to be corrupted and ignored. Another exactly the same will arrive soon after.

I ensure that I don't have any continuous loops.

Shropie is correct, MFX and Railcom both support through the track feedback and so DCC is a bit like Ethernet in these cases. Probably the rule not to have continuous loops would have more benefit when through the track feedback is used as there has to be a short period when there is no outbound DCC traffic but inbound feedback.
 
You beat me to it Greg!
.. Railcom, and MFX, are not DCC..
;):giggle::giggle:

So, DCC does not send an 'acknowledgement' back to the CS..
<pedant mode off>
 
Drifting slightly off topic here. so apologies in advance - but while we're talking about the various DCC systems....
Today I had a promotional email from Kieskemper, a German supplier I've used in the past - anyway, one of the things in the email newsletter was the new Marklin CS3 - in the description, I happened to notice that the supported protocols were listed as DCC, Motorola, MFX and MFX+ ........ so does anyone know what MFX+ is? First time I've heard of it....

Jon.
 
It 'appeared' in the literature with the CS3..

I think it is MFX .. '+' it works!
;):rolleyes::giggle::giggle:
 
Zerogee said:
Drifting slightly off topic here. so apologies in advance - but while we're talking about the various DCC systems....
Today I had a promotional email from Kieskemper, a German supplier I've used in the past - anyway, one of the things in the email newsletter was the new Marklin CS3 - in the description, I happened to notice that the supported protocols were listed as DCC, Motorola, MFX and MFX+ ........ so does anyone know what MFX+ is? First time I've heard of it....

Jon.
Click to expand...
Hi Jon
MFX+ decoder allows the CS2 to operate in simulator mode and incorporates cab control, simulated resource consumption etc.

Regards

Martin
 
PhilP said:
You beat me to it Greg!
.. Railcom, and MFX, are not DCC..
;):giggle::giggle:

So, DCC does not send an 'acknowledgement' back to the CS..
<pedant mode off>
Click to expand...
I actually said that most DCC systems have some form of feed back. I was using the accepted generic usage of DCC to mean digital.
If you want to be exact DCC as defined by the NMRA DOES contain a bi directional communication protocol. It is identical to Railcom as it was developed by Lenz and offered as a standard. Railcom + is a licensed add on available to any DCC manufacturer who can come to an agreement with the rights holder.
You are certainly correct that not all systems have feedback capabilities but the standard is there should manufacturers want to use it therefore is easily possible to have feedback from decoders and still be a 'pure' DCC system.
 
Last edited:
you are exactly right, I had not checked the site lately, I did know the original standard was unpopular and there was a move afoot to adopt an existing system, rather than have the NMRA invent their own... looks like Railcom, but they are still revising the standard.

But "most" systems do not have feedback, if you mean by the number of manufacturers or by the number of systems in existance. I do hope that changes.
 
Thanks all, phew what did I start there?

Gregs explanation that a continuous looped feed could result in the signal arriving twice at slightly different time seems the answer (IMHO). Neve did it on my last layout though.

Anyway thanks again for all your input
 
You must log in or register to reply here.
Back
Top Bottom