What's the 'bandwidth' of Dcc?

[Dave777]

Just writing a blog entry about Dcc and I got to thinking about the amount of data you can shove down the track to a loco. Now my knowledge of Dcc is really limited, but if I understand correctly at the moment the controller sends at least some tiny piece of electronic data down the rails to the chip in the loco, right? So just how much data can you put down the tracks to it?

 

Can it be measured in the same way as, say, a modem at 56 kbit/s or something?

 

I may be making a complete idiot of myself in public here

[melmerby]

Just writing a blog entry about Dcc and I got to thinking about the amount of data you can shove down the track to a loco. Now my knowledge of Dcc is really limited, but if I understand correctly at the moment the controller sends at least some tiny piece of electronic data down the rails to the chip in the loco, right? So just how much data can you put down the tracks to it?

 

Can it be measured in the same way as, say, a modem at 56 kbit/s or something?

 

I may be making a complete idiot of myself in public here

 

If you really want to know check out this site:

 

NMRA DCC specs

 

Plenty of teccy talk there.

 

Keith

[Adrian Wintle]

Just writing a blog entry about Dcc and I got to thinking about the amount of data you can shove down the track to a loco. Now my knowledge of Dcc is really limited, but if I understand correctly at the moment the controller sends at least some tiny piece of electronic data down the rails to the chip in the loco, right? So just how much data can you put down the tracks to it?

 

The best place to start is the NMRA standards (S-9.1 and S-9.2) available here http://www.nmra.org/standards/sandrp/consist.html

 

The bandwith will vary somewhat because '0' bits and '1' bits are different lengths. A basic packet comes out to about 30 bits at an average of about 160us per bit*, so about 5ms. This would allow about 200 commands per second, but there are wildcards in the mix in the form of extended packets, so your practical maximum is probably about 100 commands per second (assuming my math makes sense).

 

EDIT: *this means the raw data rate is about 6kbits/sec.

 

Adrian

[Lady_Ava_Hay]

Good question. Obviously, some decoders can take more instructions than others.

 

At a rough guess though perhaps 100CV's needing a value up to 255bits..........each packet then will be 25,500bits.

 

8 bits to a byte?

[Adrian Wintle]

Good question. Obviously, some decoders can take more instructions than others.

 

At a rough guess though perhaps 100CV's needing a value up to 255bits..........each packet then will be 25,500bits.

 

8 bits to a byte?

 

Not quite - each changed CV needs 3-4 bytes plus message wrapper, sent twice. The CV value isn't 255 bits, it is a maximum value of 255, which can be encoded in 8 bits.

 

See RP-9.2.1 for more detail.

 

Adrian

[Dave777]

Okay, useful info, many thanks. Having seen the answers I'm suspecting I may have asked the wrong question - from the info you've give me there it looks like the decoders and/or controller is determining how much data is set (ie, they are the limiting factor), so perhaps the next question is 'How much data could you put down the track?'. Getting a bit Heath Robinson here, but let's say I plug a DSL or cable modem into one end of a length of OO flexi track and a PC at the other, how much data could I put down it?

 

Obviously the technicalities are all wrong there, but hopefully you can see what I'm saying. At the moment there's a little bit of data going down the track from the controller to the decoder, so what's the theoretical maximum? The wiring into my house is the limiting factor for my interweb access, so if I replaced that wiring with OO track (or N or O), how much data could it handle?

 

Does the question even make sense I wonder?!

 

 

[ian]

Taking the question at face value, you would be limited to the maximum speeds available using wires rather than fibre-optics, so you should be able to do a direct replacement for wires with your track.

 

After that you start coming up against real-world nasties, electrical noise from the railway, higher resistance of nickel silver rail as opposed to copper wire, etc..

[Crosland]

Okay, useful info, many thanks. Having seen the answers I'm suspecting I may have asked the wrong question - from the info you've give me there it looks like the decoders and/or controller is determining how much data is set (ie, they are the limiting factor), so perhaps the next question is 'How much data could you put down the track?'. Getting a bit Heath Robinson here, but let's say I plug a DSL or cable modem into one end of a length of OO flexi track and a PC at the other, how much data could I put down it?

 

Obviously the technicalities are all wrong there, but hopefully you can see what I'm saying. At the moment there's a little bit of data going down the track from the controller to the decoder, so what's the theoretical maximum? The wiring into my house is the limiting factor for my interweb access, so if I replaced that wiring with OO track (or N or O), how much data could it handle?

 

Does the question even make sense I wonder?!

The problem is the nature of the channel you are trying to send the data down. Any booster could be connected to any unknown track network with an unknown number of indeterminate loads that have a habit of moving around. That's why you can't simple apply transmission line theory to a general case. In addition the connection is intermittent with wheel/rail and wheel/pickup contacts often being less than ideal. Increasing the data rate bay an order of magnitude, say, would require a very robust error detection/correction scheme.

 

The absolute maximum data rate for DCC, as defined, is a stream of 1 bits (so not very useful) at 8.62kbaud. Useful data rate is somewhat less. A back of the envelope calculation shows that the absolute maximum packet repetition rate (includong preamble and start/stop bits) is around 150 packets per second for a "useful" packet

 

Andrew Crosland

[Ron Ron Ron]

If you are thinking about the maximum amount of data for maximising functionality, with regard to the control of model trains (i.e. a practical purpose), rather than some theoretical maximum capacity, then you have to consider the two-way requirement of Bi-directional communication and the necessary break in Command Station transmissions to allow decoders to transmit data.

[Adrian Wintle]

Okay, useful info, many thanks. Having seen the answers I'm suspecting I may have asked the wrong question - from the info you've give me there it looks like the decoders and/or controller is determining how much data is set (ie, they are the limiting factor), so perhaps the next question is 'How much data could you put down the track?'. Getting a bit Heath Robinson here, but let's say I plug a DSL or cable modem into one end of a length of OO flexi track and a PC at the other, how much data could I put down it?

 

No, the decoders and controllers aren't determining how much data is sent. The DCC specification is the limiting factor. The decoders and command stations are designed to meet that specification.

 

The theoretical maximum is based on the electrical definition in S-9.1, which is a minimum of 110us for a '1' bit and 190us for a '0' bit, averages out to 150us per bit, or 6.7kBits/sec. You cannot get a higher bandwidth and still be DCC since you would be outside the parameters defined in the basic DCC specification. On to that you add the communication protocol in S-9.2 and the RPs which give an indication of the effective data transfer rate.

 

If you want to invent something different from DCC your bandwidth could be significantly higher, but then it isn't DCC, and so isn't the question you originally asked. At some point you would be getting into issues of noise corrupting the signal (rails are unshielded antennae), and likely a limitation on the power transfer possible (DCC also ensures you have the power to run the trains you are commanding).

 

Adrian

[zabdiel]

 

If you want to invent something different from DCC your bandwidth could be significantly higher, but then it isn't DCC, and so isn't the question you originally asked. At some point you would be getting into issues of noise corrupting the signal (rails are unshielded antennae), and likely a limitation on the power transfer possible (DCC also ensures you have the power to run the trains you are commanding).

 

 

If you wanted to design a system with significantly higher bandwidth then using WiFi or Bluetooth would probably be the way to go. You could still have the trains getting power from the track like with DCC, but you could have that part optional, so that trains could be battery powered in larger scales, which would allow them to run over highly weathered sidings with no electrical contact. I'm sure someone has done something like this.

 

I don't think many people have found the bandwidth limitations to be a problem, I think Fremo might be the exception but they run some ridiculously large modular meets.

[peach james]

At 150 data blocks/second, it means that if the command station sends a change of speed every second to every loco, you have 150 locos changing speed every second. I am under the understanding that a latency of ~1/3rd of a second is considered about the maximum that is desirable, which would suggest the practical limit is around 50 running locos at the same time per DCC circuit.

 

I am doubtful that many layouts in the world are capable of running more than 50 locos at a time. Even on layouts like San Diego, I still think it is unlikely that they will ever have 50 running locos at any single time.

 

(I'm not sure how to figure the MU issues- if it would be 50 locos, or 50 trains...I'm just not that interested in figuring that out)

 

James

[Adrian Wintle]

(I'm not sure how to figure the MU issues- if it would be 50 locos, or 50 trains...I'm just not that interested in figuring that out)

 

Using advanced consisting (CV19) the complete MU is effectively one loco (operates on a single address). Other consisting methods take more bandwidth since the control station maintains the relationship and commands the constituent locos individually.

 

Adrian

[Crosland]

If you are thinking about the maximum amount of data for maximising functionality, with regard to the control of model trains (i.e. a practical purpose), rather than some theoretical maximum capacity, then you have to consider the two-way requirement of Bi-directional communication and the necessary break in Command Station transmissions to allow decoders to transmit data.

Railcom transmission from a decoder takes place at a higher data rate during a few bits of the (extended slightly) preamble. It's a few percent overhead at the most.

 

Andrew Crosland

[Lady_Ava_Hay]

I suppose that the comparison between your Internet connection and the DCC is not really valid. In order to get the huge packets of data down your telephone line to watch a video, a great deal of compression has been applied. We know that fibre optic cable can carry vast amounts of data basically as light whereas when the old style copper cable that we all have is still the limiting factor in data speed and bandwidth.

 

Apparently the fitting of a fibre optic cable straight into your house was disbarred as a safety issue. Apparently if you cut a fibre optic cable and put it to your eye, you would be blinded.

 

At the same time it is the sampling rate of the transmitter and the receiver that dictates the speed of data transfer. DCC is still in the steam age ( sorry, pun intended ) when it comes to bit sampling rates.

 

It is entirely possible to change the system and speed it all up immeasurably and it is possible that this has already been done but.........that would increase the costs a great deal and we would lose the ability for any command station to speak to any decoder and in 00 terms would probably fill the loco with electronics with very little visible change in performance.

 

So the bandwidth of the mechanical connection is, effectively, not being utilised because the loco decoder doesn't actually need it.

 

This post is my take on bandwidth and data speeds in pure layman's terms and, if asked to explain it or justify it in scientific terms, I couldn't. So don't ask.

[melmerby]

 

 

Apparently the fitting of a fibre optic cable straight into your house was disbarred as a safety issue. Apparently if you cut a fibre optic cable and put it to your eye, you would be blinded.

 

 

 

And if you cut a live mains cable and put it into your eye you would also be blinded - as well as probably dead (RCD excepting)!

 

Shows how stupid the rules are.

You also get laser light from an optic cable on hi-fis, video etc.

 

Keith

[Pinkmouse]

...Apparently the fitting of a fibre optic cable straight into your house was disbarred as a safety issue. Apparently if you cut a fibre optic cable and put it to your eye, you would be blinded.

 

Urban/interweb myth. BT and Virgin have already done it in test areas, and are just waiting for a favourable economic climate for the massive investment required to make it widely available.

[Dave777]

Thanks for all the replies folks.

[Etched Pixels]

The actual speed possible if you change the signalling system a bit is way more - sound decoders upload samples at a somewhat higher bitrate but don't use the actual DCC protocol for this (hence the need for custom programmers).

 

You probably could do pretty high data rates except that

- Your decoders would be much larger

- You'd draw much more power for them

- You'd probably have serious RF interference problems

- You would be much more vulnerable to strange behaviour from capacitors and freak perfectly non-ideal track lengths

 

So for most things DCC is fine. Technically speaking you can also do DCC routing and only send messages to certain locos into certain power districts. I'm not aware of anyone ever finding a need for this however (although I bet someone somewhere has... Miniatur perhaps 8))

[ian]

(although I bet someone somewhere has... Miniatur perhaps 8))

I think they just use multiple, separate systems.

[Dagworth]

At 150 data blocks/second, it means that if the command station sends a change of speed every second to every loco, you have 150 locos changing speed every second. I am under the understanding that a latency of ~1/3rd of a second is considered about the maximum that is desirable, which would suggest the practical limit is around 50 running locos at the same time per DCC circuit.

 

I am doubtful that many layouts in the world are capable of running more than 50 locos at a time. Even on layouts like San Diego, I still think it is unlikely that they will ever have 50 running locos at any single time.

 

(I'm not sure how to figure the MU issues- if it would be 50 locos, or 50 trains...I'm just not that interested in figuring that out)

 

James

 

Remember though that it is only CHANGES that need urgent broadcast, any loco that is to continue doing what it is currently doing only needs the relatively occasional packet addressed to it to keep it alive. The size of layout then grows vastly before the speed of data transmission becomes a porblem. Every packet on the DCC system is used by every loco as a power supply, locos will continue to obey the last valid instruction they received until the decoder hits a "time-out" that is built into the decoder. If no valid instruction is received and the time limit is reached then the loco will come to a grinding halt.

Example:

you have two locos on the layout

Loco 1 is told to move at speed step 10

Loco 2 is told to move at step 1

subsequent instructions are issued to loco 2 to accelerate to speed step 2, then 3, etc.

If no further instruction is sent to loco 1 it will continue at step 10 until its decoder times out, then it will stop dead.

 

The command station brain ensures that CHANGE* packets are stuck into the top of the queue to be broadcast, CONTINUE* packets are lower priority.

 

*By which I mean instructions to do something different or to do what the loco was already doing.

 

Andi