Viewing the DCS Spread-Spectrum (CDMA) Track Signalling Format

I've been studying DCS design in a bit of detail over the last few weeks and there's a lot of misinformation out there about what's actually going on in the track between the train and TIU so I wanted to make a clean reference available for anyone who is interested or needs the information.

===========

Introduction

===========

First of all DCS is a spread-spectrum technique which is a subset of CDMA (Code-Division Multiple Access). The specific technique used is called Direct-Sequence Spread Spectrum, or abbreviated DS/SS for short. Beyond model trains, DS/SS is employed in most wifi (802.11abgn,ac) and in wideband radar systems. It's large spreading ratio (spreading small data over larger bandwidth) is attractive for communication systems as it makes the link robust to multi-path, fast fade and channel distortions, while in radar the low energy density prevents it from easily being jammed or overrun by local transmitter leakage.

Okay so back to the trains:

The concept of spread-spectrum is that you use a long string of multiple bits (at a faster rate) to represent a single bit (at a slower rate). At the receiver you then correlate (multiply bitwise and add along the length of the packet ) the long string received against the known string of bits. The advantage of this over straight 1's and 0's is that even if a few bits are flipped due to interference and bad contact, the majority are left alone and so the data still makes it through. The number of bits that have to match to be considered a successful code detection is called the "Confidence interval" of the CDMA or DSS receiver system.

========================================================================

How it transmits -by example

========================================================================

Lets look at an example where the DCS TIU sends a command to the train. A command is typically a short packet of several bytes:  3F 2A 44 22     (something like this). It can be longer when downloading sound files, but for most functions (speed, bell, whistle, ...)  it's pretty short, like 20 byte max. Note that for DCS the first byte in every packet is a constant value. Making the first value constant is common in DS/SS systems as it helps with packet detection and frame synchronization.

To make the math simpler lets do a simple 1 byte example...

We want to send byte "34" to the train through the DCS system.

So in base 2:    34 (hex) = 8'b00110100 (bin)   (what we want to send)

As mentioned the spread spectrum replaces each bit with a string of multiple bits. In DCS the string of bits used to replace each bit in the packet is exactly 31 long.  These 31 bit strings are often called PN codes (short for Pseudo-Noise), because they look like a noise signal in the frequency domain. For DCS only 2 PN codes are used (one for 1s and one for 0s) and they are complementary (meaning one code is the negation of the other). While this isn't the general case for DS/SS (any code could be used), I think DCS uses it to simply the correlator in the receiver.

So we will have 2 PN codes for DCS, each 31 bits long:

When I see a 0 in my packet I send: "0101011001001101111001011100110"

When I see a 1 in my packet I send: "1010100110110010000110100011001"

So in order to send 34 (00110100 in binary) the actual sequence of data streamed to the track will be:

(0101011001001101111001011100110)(0101011001001101111001011100110)(1010100110110010000110100011001)(1010100110110010000110100011001)(0101011001001101111001011100110)(1010100110110010000110100011001)(0101011001001101111001011100110(0101011001001101111001011100110)

Often in DS/SS systems we refer to each 1 or 0 actually transmitted as a "spreading-chip" (nothing do do with like microchip, it's just a name). So a "bit" is referring to the 1 or 0 at the packet level and a "chip" is referring to a 1 or 0 inside the PN code.

So since each PN code has 31 chips inside, and our packet is 1 byte (which is 8 bits) our entire sequence on the track should be: 31 X 8 = 248 spreading-chips. DCS has a "chip-rate" of 3.75 MHz meaning that every 1/3.75MHz = 266ns the next 1 or 0 in the transmission sequence appears on the track. Unlike WiFi or LTE, the sequence is not unconverted onto an RF carrier, it's just directly streamed out onto the track.

So in our example this 248 spreading-chip long code goes down the track and into the locomotive where it's picked up by the PS2/3 board in the locomotive.

Note that the above example is not the real PN codes, they are probably proprietary to MTH so I don't want to stick them online. If you really really want them, just follow the next section where I talk about viewing them... and you could always just use the scope to capture them and write them down....

If DS/SS is still confusing you, NI has a great tutorial here:

http://www.ni.com/white-paper/4450/en/

========================================================================

Seeing the track signal

========================================================================

(Frequency Domain Viewing)

Since there is no up-conversion, computing the spectrum even by hand is relatively trivial. As the data is time-limited (not a power signal), you can take the f(t) = rect(t/T) function, scale T to the 266ns period, and then just use the Fourier transform pair:  FT(rect(t/T) = f(w) = Tsinc(Tw) so it will be a sinc function. The PSD (power spectral density) function would then be [Tsinc(Tw)]^2.  Since the DCS pules have a infrequent and have a relatively low duty cycle (like way below 0.1%)... we're talking like a few us of packets every second... this means you probably can't seen them on a spectrum analyzer as the integrated power is too low compared to the noise floor. If you put on a modest resolution bandwidth of maybe 10-100KHz and did some deep averaging over an hour or two, the Tsinc(Tw)^2 should become visible.

(Time Domain Viewing)

Capturing the DCS packet on a digital storage scope is probably the best way to see the signal in detail.

The first and most important step is to not blow up your oscilloscope with the 18-20V track power signal (usually AC 50-60 Hz). What I did for this (feel free to find better design solutions) is to go with a 4th order butterworth high-pass filter centered at 15 KHz. That gives you 80dB/decade roll-off meaning the DCS signal can go right through but the 60 Hz will be pushed down like 200dB (below a scope noise floor). My implementation of the filter was just a series connection of 10nF caps with a 10K resistor to ground at each tee node. 

The TIUs tend to have amplitudes on the order of 2V so you can trigger the scope somewhere around 1.5 to 1.7V and leave a bit of room in the pre-trigger regime so you can see the start of the packet format clearly. The spreading-chip time is 266ns so you probably want to over-sample at least by a factor of 4 or 5 so you can see the boundaries between each chip clearly. This way you can check the PN codes by eye if you wanted too. Also remember that each byte is like 2.13 us... so you need decent digital memory if you want to view the entire packet. I'm a WiFi chip designer so normally I use a fancy agilent DSO scope.... but I found this $150 hobby one (www.bitscope.com) that's a USB oscilloscope that can sample at 20MS/s giving you 5:1 oversampling of the chip rate, and it can store 12000 points which is enough for:

(1/20M X 12000)/266ns = ~2250 spreading chips or (2250/31) = 72 bits (9 bytes) worth of packet data.

Maybe not enough to see the entire soundfile download, but certainly enough for debugging and such. The only downside is you need to write your own C/Python or whatever to drive it. I have code for it specifically to capture DCS packets if anyone wants it, just message me back.

Anyhow, that's everything you need to know to see the DCS packets on the track. Here are some DCS samples I captured with that bitscope part (and the filter in front of course!):

The bitscope code I wrote just spits out a csv so I had to drag it into matlab to make nice plots.

Anyways, I'll write another post later about how to receive and demodulate the codes (called "de-spreading") on an FPGA or fancy micro-controller.

-Adrian J Tang

(www.sadcircuitdesigner.com)