Command Wire and DZ Command Bus Interference Issue

Here's my thoughts on this.

You have a nice huge layout, tons of tracks in parallel, a country mile of wire running parallel under the table.

Parallel wires is how you get crosstalk between wires- hence a garbled digital serial data signal.

Solution: Break up your command serial bus setup. You are using one SER2 and one data wire driver, and then depending on that serial data signal to command all those switches and given the length of wire and load of switches along with parallel long runs picking up interference.

So- break it up. Get another SER2 and another data wire driver, long PDI cable remote mount the second SER2 and Data wire driver in another area or grouping of switches to divide and separately command the switches.

Interestingly if I remove the LCS devices from the layout and istall the dz driver directly into the base, then the Legacy base accepts and sends  commands and all dz2500 behave normally.  So I guess the SER2 us bad??

@T4TT posted:

Interestingly if I remove the LCS devices from the layout and istall the dz driver directly into the base, then the Legacy base accepts and sends  commands and all dz2500 behave normally.  So I guess the SER2 us bad??

No, again, it's interaction. A SER2 is a buffer/repeater. It takes time from the input signal to the output signal. Again, your base transmits 2 signals, an RF signal to the track, and a digital serial signal out. What appears to be happening is the delay and echo of crosstalk is confusing the DZ2500s. It first gets the radio crosstalk on the wire since that came from the base (the source of the signal and thus first timing) and then a second signal delayed from the wire driver and SER2. The timing is such that the DZ2500 sees an invalid command string of serial data.

Reduce the crosstalk is one method- using shielded twisted pair wiring, less total length of total parallel wiring.

Reduce the (signal) load- using more than one SER2 and wire driver giving stronger signal and less crosstalk to a smaller group of switches.

If you really think SER2 is the problem, fine, get a Y splitter serial cable, drive the wire driver and your LCS with the splitter at the base.

Thank you Vernon. I think I made my second post the same time u initially responded.

I am really at a loss.

I divided the layout in half and created two data buses-completely separate from one another. I had the DZ data driver plugged into the SER2 and once again when the command wire from the Legacy base is removed from the outside rail all of the DZ2500s on that half of the command bus responded to the CAB2. But as soon as I connect the command wire the red led on the data driver glowed constant red, the DZ2500s do not respond and the green light on the motors flicker.

I then removed the SER2 from the equation and used the Y splitter cable shown above. I can't explain why but none of the DZ2500s responded to commands in this configuration.

So I can either command engines or switch motors, I just can not command both. I have no idea why. It is strange because this is a recent phenomenon and it is driving me to drink!

Any additional suggestions would be appreciated.

@gunrunnerjohn  I tagged gunrunnerjohn...he is the resident expert and I hope he will weigh in. Thanks very much.

kevin

The solid red light on the DZ2001 usually results from a problem with one of the switches.  Disconnect the switches one at a time from the data driver until the light doesn't stay on.

Here's a little troubleshooting note that Dennis at Z-Stuff sent me some time back.

DZ-2500 Failure to respond to the CAB remote:

This failure is usually due to at least one switch machine failing or being in the wrong mode. One
indication is the LED on the DZ-2001 data wire driver being ON all the time. The DZ-2001 red LED is
supposed to be normally OFF and flash when data command is sent.

If there is a DZ-2500 with no lights lit, remove its BLU wire from the data wire to see if that fixes the data
wire problem. It may need to be replaced and sent back for repair.

Being constantly ON is caused by a DZ-2500 failure (no LEDs lighted on it) or in the wrong mode (both
LEDs lighted for the first two seconds at power up). Both LEDs lighted means the DZ-2500 is in the two
wire DCS mode and no longer in the TMCC default mode.

WRONG MODE
If the switch machine has both RED and GREEN "ON" together for the first two seconds at power up. If
this is the case, then starting with the RED LED lighted, press and hold the button on top of the DZ-2500
until the RED and GREEN lights flash alternately. As soon as they do, release the push button. Then, turn
off power. When power is turned on again everything should be fine.

@gunrunnerjohn

Well after spending the day removing one dz2500 from the data bus after another, I was nearly on the verge of a nervous breakdown. I have two CSM2s in the LCS daisy chain, one is completely wired and indicates the switch position, the other is in the  PDI chain but only has the serial data wire port wired to the data bus the other 7 ports were not wired yet. When I removed that serial data wire from that CSM2 from the bus...holy s#!t...the red light on the data driver went off! I reconnected some switches to the data bus and they responded to commands!

I happen to have a NIB CSM2 and I swapped it out. ODDLY, the brand new one caused the red light on the data driver to glow solid red too! So for now I removed that serial wire from the bus and for now everything is working. Could it be that the CSM2 needs the other ports wired? Again I have another CSM2 fully wired for switch position (and block power) and it works perfectly.  Strange, but at least for now I can command engines and switches.

thanks John!

FWIW, I found out that the CSM2 has a timing issue if you turn it on the same time as the DZ2500's.  If you turn the CSM2's all on first and power up the DZ2500 after a few seconds, all is well.  I surmise that the initialization of the CSM2 sends random data during initialization and the DZ2500 switches modes.  I discovered that the DZ2500's would be in manual mode when the problem occurred.  I'm currently running all the DZ2500's off the DZ2001 and all is well.  I still use the CSM2 inputs for the LCS display, just not the serial output.

@gunrunnerjohn

John, I read your posts about that very phenomena. I literally have two separate switched circuits in the train room. Both are 15 amp and one is dedicated to 180 bricks and switch motors and the other is for all other accessory transformers. I turn on the accessory circuit first that powers the LCS devices and after about 30 seconds I turn on the switch the powers the bricks and the transformer for the switch motors. I thought that would give the LCS the time it needs. But I wired the serial port in the CSM2s to the data bus. I only plan to use the CSM2s to identify switch position on my iPad.

John are you saying I do not need the serial wire is not needed for my application and that I can get by with just wiring the CSM2 to either the yellow or green wire from the DZ2500s?

Thanks John! I have learned very much from you.

You can get the serial data from any source, the CSM2 just repeats the same data stream.  I'm running all my 25 or so switches using the DZ2001.  You don't have to use the serial data from the CSM2.  The CSM2 has the power common and one data wire from the DZ2500's to monitor position, that's all it needs.