Skip to main content

Reply to "Weak DCS signals, Failed TIU Output Drivers, and Design Solutions devloped under collaboration between AGHR and MTH"

cnwdon posted:

Real is always better, thanks, Adrian.  I have to consider things like 10 gauge leads to the track buss for a few blocks to serve some important old trains, so capacitance appears to be my middle name.  If I need to invest in more TIU channels it would be a small cost in the big picture.  Or, what else do I not understand yet?  Would appreciate the “real” answer!

Don

Right so how it "really" works is DCS communicates with CDMA codes. This is a spread code of lots of 0s and 1s that are compared to represent a real "0" or "1"

0:  1001001010111100...

1:  011011010100011...

The real codes are like 32 bit long and transmitted at a rate of 3.25MHz. In order for DCS to have successful detection 29/32 of the bits need to be right so you can tolorate some error, but not all errors. They are square waves not sine waves so when you look at their fourier representation they have harmonic content at  9.75 MHz, and 16.25 MHz (square waves only have odd harmonics!). The ACT244 driver that drives your track with this waveform is a CMOS gate inside so it basically looks like a current source (when it's pulling up or down, but not statically sitting at value). Capacitors are I=CdV/dt.  I is fixed by the ACT244 so dt (the time of the slope from 0 to 1 and 1 to 0 is merely dt=Cdv/I. The bit time of a 3.25MHz square wave is 307ns and once the slope starts getting close to 20% of this time (like 30 ns) your square starts to look more like atriangle.  So in the engine decoder it compares a perfect code to a code with slopes caused by the added cap combined with limited drive current. It then all comes down to the deocder's correlation result.

The two codes are compared by multiplying and integrating them timewise... so if we look at an oversampled representation of one bit of the code

 

000011110000 compared with 000011110000

First multiply each bit and add up the result 0(0) + 0(0) + 0(0) +0(0) +1(1) +1(1) +1(1) +1(1) +0(0) +0(0) +0(0) +0(0) = 4 so the detection level is "4" in this example

Now consider if you have slow ramping from the drive/cap pair:

000011110000 compared with 0000(0.25)(1)(1)(0.25)0000

 0(0) + 0(0) + 0(0) +0(0) +1(0.25) +1(1) +1(1) +1(0.25) +0(0) +0(0) +0(0) +0(0) = 2.5 so the detection level is "2.5" in this example

At some point when the wave gets too sloppy the detection level gets too low and the decoder becomes unsure if the code it's seeing is the 1 or 0 code, and then you loose reliable communication. A similar thing happens if the amplitude of the signal is lower than it's supposed to be. Lets say the waveform has 30% of the designed 10V amplitude.

000011110000 compared with 0000(0.3)(0.3)(0.3)(0.3)0000

 0(0) + 0(0) + 0(0) +0(0) +1(0.3) +1(0.3) +1(0.3) +1(0.3) +0(0) +0(0) +0(0) +0(0) = 4 so the detection level is "1.2" in this example

So in practice it's important to both make sure that the amplitude of the DCS waveform is good and that the edges are sharp and do not eat more than 0-5% into each bit time. In our club we look at the waveforms in each section to make sure they are crisp and set the lengths from that. Remember that cap per length of track is *ALOT lower* than cap per length of wire. Loosly capacitance is C=eoer A/D where A is the "effective area" of the two signal conductors and D is the distance between them. A twisted pair of wire is a lot closer together than the center rail and running rails of an o-gauge track so generally the pF per foot is of wire is 10-50X higher than the track itself. Setting the length requires balancing these two contributions. Another way we looked at is stacking ACT244s in parallel to make Idrive bigger. This also works but the actual assembly is a headache.

 

This is only the half story though. If you pull your twisted pair apart you create inductance (which is proportional to the area between + and -). Too much inductance causes ringing which also has a similar effect on the decoders.

Last edited by Adrian!

OGR Publishing, Inc., 1310 Eastside Centre Ct, Suite 6, Mountain Home, AR 72653
800-980-OGRR (6477)
www.ogaugerr.com

×
×
×
×
×