TCS decoder puzzle

[GaryHinshaw]

I have been adding decoder-equipped motive power to my roster and running existing power more frequently.  In the course of doing so, I have had 3 Kato SD70ACe's with TCS K1D4-NC decoders start acting strangely.  The first symptom is that these locos would start moving for a few seconds when I powered the track on, then stop on their own.  This happened even when all mobile decoder slots were cleared from my command station (Digitrax DCS 100), so it was not a case of throttle competition.

I was able to fix the problem by resetting the decoders and re-programming them.  In the course of doing so, I discovered that each decoder had been set to a long address of 16383 (2^14 - 1).   Oddly, they were still responding to their originally-programmed 4-digit addresses at the same time. Has anyone here seen this behaviour and/or understand what might cause it?  I have a few other locos with K1D4-NC decoders that have not shown this (yet...), and I have many units with K1D4 decoders, none of which have shown this.

Thanks in advance,
Gary

[peteski]

That is indeed odd. You are unclear whether the oddball address was present before or after the reset (I assume before).  Did you try to run them using address 16383? Was the spurious running when powered up repeatable?

The first thing I would have done to troubleshoot this would have been to disable DC mode (in CV 29) then check whether the power-up behavior changed.

Judging by the strange address value and behavior, I would say that those decoders had their internal registers "zapped" and that caused the erratic behavior.

[bobthebear]

Ive come across this too. At a show 2 weeks ago, we had an annoying short. After it was sorted, some locos, mainly with TCS decoders, behaved erratically. Upon inspection at home, they also had new long addresses. I have now disabled DC mode on all my locos.
Bob.

[GaryHinshaw]

Thanks for the responses guys.  It sounds like there might be one cause and multiple effects: something like a short* zaps several registers in the decoder and:

1) sets the address register to 16383=(2^14)-1,
2) enables analog mode
3) changes the manufacturer ID,
4)....

(These are the changes that I noticed in reading back CVs in Decoder Pro.  There may have been other changes.)

It sounds like the transient issue is solely associated with the CV 29 (DC mode).  I'll pay more attention to that if I see this again.  Note that the transient symptom was present regardless of the slot state in the command station.  For example, I cleared all mobile decode info from the DCS100 and still saw the transients after cycling track power.  I assume that a decoder with DC mode enabled will respond to any DC voltage present in the track, regardless of address, correct?  Is it normal for there to be a DC transient on track power-up?

That is indeed odd. You are unclear whether the oddball address was present before or after the reset (I assume before).  Did you try to run them using address 16383? Was the spurious running when powered up repeatable?

The address was present before the reset, but not afterwards.  I did not try to run them under 16383, and I'm still puzzled how they would respond to their original 4-digit address in that state.

*One last puzzle: during our session last weekend, there were a few instances where one of my auto-reversers was failing to switch polarity when a loco crossed its reverser boundary, causing the DCS100 to shut down the whole layout.  Would enabling analog mode interfere with the operation of the AR board?  It's possible this problem only occurred when one of these rogue locos was involved...

[BN1970]

Gary, you may have had two issues around short circuits.

1) By turning Disabling DC operation in your decoders you force them to keep listening for valid control packets - Turning off DC is a good thing.  As others have already mentioned.

2)  Your DCS100 and or PSX (I assuming your using PSX) can at times trip faster than a PSX-AR can revers polarity.  Depending on the individual circuit boards this can be every time or sometimes.  Electronic components very in their timing and as such each circuit board will be slightly different.

   a) How the PSX-AR responds  can also depend on if its Rail A or Rail B thats crossed by a locomotives wheels as the (non AR) PSX circuit breakers only open one rail.  Worst case the PSX trips before the PSX-AR reverses the polarity.

   b) At times a DCS100 can see the short and down goes everything.

There’s two things you can do.

First, you can change the react time of the DCS100 from 125 milli seconds to 500 milli seconds by setting OpSw18 to Closed.

Second, the PSX breaker has the ability to adjust the trip time to take care of these situations where its tripping before the PSX-AR.

• Set CV55=1 to enable the delay and then adjust the duration by changing CV65.

• CV65 adjusts the delay in 1/8ms increments and has a default value of 24 (3ms). 

This is often enough to solve this issue. If not, just keep incrementing CV65 by 8 until you have reliable operation. Using the non-switched side of the PSX will work for those situations where you always hit the gap on this side first. For situations where the train can hit the gaps from either direction, you can adjust the trip delay of the PSX breaker.  The above PSX information is not in the manuals.  I found some boards it was sufficient just to enable CV55, but one my PSX’s needed CV65 to be set to 32.

Two other minor points, if you do an OpSw 39 on your DCS100 that will Reset all the DCS100’s Option Switches to their factory defaults which means the short circuit trip time will go back to 125 ms.  I’m sure you know this, use OpSw 36 to clear your mobile decoder data in the DCS100 as it will not effect how your DCS100 is set up.

The last point, the easiest way to program the CV’s in a PSX breaker is to just use your DT402D throttle, that way you can see the PSX boards LED flash as it gets the commands.  You do this under PO (Operations Mode), which means you can re-program any locomotive on the layout if you have the wrong address - I know as I did it!

I hope some of that is helpful.  I should also mention, I use an DCS100 on my N-Scale layout and all my decoders are TCS. —Brian

[peteski]

By turning Disabling DC operation in your decoders you force them to keep listening for valid control packets - Turning off DC is a good thing.

I'm not sure what you mean - decoders always listen for packets whether they are running in DC or DCC.  That is what they are designed for and that is how they "know" what mode they are running in.

Personally I like to leave the DC mode (actually it is "power source conversion" mode selected by CV12 which is by default DC mode) enabled - that gives me the ability to quickly test the basic decoder functionality using a 9V battery against the locos wheels.  Having DC enabled does not cause any problems on the DCC systems I use (CVP EasyDCC and NCE).  But I hear of enough problems with locos taking of on DCC layouts that I agree that it makes sense to disable DC, at least while troubleshooting the problem.

Gary:  the DC setting should have no bearing on the auto-reversers. The decoder is simply seen as an electrical load (regardless whether it is running in DC or DCC setting).  The booster's (or reverser's) circuitry doesn't know or care about how the decoder is configured.

I'm also  puzzled as to how whatever "zapped" the decoder was able to set just the analog bit on in CV29 ( instead of totally scrambling its contents, like it did with the address CVs) and also hoe the mfg. ID would have changed.  I assume you mean CV8. That CY is hard-coded and read-only. You cannot modify it by writing to it.  SO CV8 no longer shows TCS as the manufacturer?  If CV8 got scrambled than who knows what else got scrambled inside the microcontroller.  Weird.  Or did the factory reset procedure also reset CV8?!

[Greg Elmassian]

Pretty strange to get a wrong readout from CV8, but I've gotten bizarre things from TCS decoders when power has been interrupted, or some limit has been exceeded, a case in point in Z scale is the older Marklin 3 pole motors, which must have some really nasty BEMF or just noisy operation (electrically)...

A common occurrence is either full speed operation, or the inability to control the speed, and only a decoder reset seems to fix it. I have seen strange CV readbacks, but when a decoder becomes uncontrollable, a reset is pretty much the next thing I do. With and without DC mode enabled made no difference.

Greg

[jagged ben]

I would fire up Decoder Pro, and Write Full Sheet on the Basic page with the addresses.  Or even Write all Sheets.

I dislike how often I seemingly have to do this with TCS decoders.

[BN1970]

Short circuits are not always +12 volts to zero volts, they can typically have a lot of electrical noise / spikes, depending on whats the cause.  If you leave the DC Mode enabled in the decoder and that decoder does not see valid DCC packets it will time out and assume its to run in the DC Mode and at times you may experience a run away locomotive as its gone into DC.  If you need to test a loco under DC just turn that CV back on when needed.

At times after a short I’ve found some decoders need to be reset by rocking one side of the locomotive off the rails for a second or so, to allow it to reset.  This has happened on HO layouts using none Digitrax command stations with non TCS decoders.  Short circuits can garble decoders temporarily from what I have observed.  I’ve yet to experience a decoder that won’t reset if you remove its power for a second or two.  But I’m sure its only a matter of time before I’ll get one needing a trip back to the programming station.

My second point and more to what Gary’s problem may be, was to set up your short circuit protection, as not every short circuit is equal.  What I mean by that, if your DSC100 goes into short circuit mode not only does the layout go down, your probably going to be dealing with higher spikes.  Thats assuming that you have dropped the current trip value on you PSX’s to a level thats less than what your DCS100 is set for?

Ideally the PSX / PSX-AR trips under a short before the DCS100.  Its like having a short circuit in your house taking the local substation down, not a good idea.  Short Circuit protection should be set up in layers. —Brian

[ChrisKLAS]

I've had the same issue with dispatched locos/consists (only those with TCS decoders) taking off when the layout was first powered up for years. My "poor man's" solution was just to refrain from dispatching them. I never had any luck tracking down the source of this issue. It's good to know that this behavior is seemingly tied to the analog-DC option on the decoders, and I'll be disabling that ASAP. Thanks!

[peteski]

I don't know the ins and outs of Digitrax system but I just don't understand why dispatching the loco address would change the behavior of the decoder when other non-dispatched decoders on the same tracks are behaving properly. They all receive the same DCC packets from the track.  If there is no DC voltage on the track (since the other locos are receiving the DCC packets) the dispatched loco should not see any DC voltage and start running.

[OldEastRR]

I've had the same issue with dispatched locos/consists (only those with TCS decoders) taking off when the layout was first powered up for years. My "poor man's" solution was just to refrain from dispatching them. I never had any luck tracking down the source of this issue. It's good to know that this behavior is seemingly tied to the analog-DC option on the decoders, and I'll be disabling that ASAP. Thanks!

Hmmm... sounds a lot like my problems with TCS decoder in my infamous RDC. Tho disabling the DC option doesn't seem to have changed anything.

[John]

http://tonystrains.com/why-decoders-run-away-or-reset/

[bobthebear]

Thanks John for that post. Everyone should read that.
Bob.

[peteski]

Yes, that is an excellent, accurate, and easy to understand by everybody explanation.