TCS dead decoders

[jagged ben]

I have also found that TCS CN-GP decoders forget their settings.  Mind you, often my run sessions of those certain locomotives are months or years apart.  Anyway, JMRI is indispensable, when it happens I just put them on the programming track, pull up the roster entry, click 'write all sheets' and go off to get the next loco out of the box while I wait.

Now it would be nice if they would stop their odd reverse runaway behaviors.  Sometimes it sure looks like they think they just got a high voltage DC signal and momentarily go into analog mode.  Mine are all first run, maybe they've improved quality since then, but I've prioritized converting  locos that can be easily done without them in the meantime.

[peteski]

I have also found that TCS CN-GP decoders forget their settings.  Mind you, often my run sessions of those certain locomotives are months or years apart.  Anyway, JMRI is indispensable, when it happens I just put them on the programming track, pull up the roster entry, click 'write all sheets' and go off to get the next loco out of the box while I wait.

Now it would be nice if they would stop their odd reverse runaway behaviors.  Sometimes it sure looks like they think they just got a high voltage DC signal and momentarily go into analog mode.  Mine are all first run, maybe they've improved quality since then, but I've prioritized converting  locos that can be easily done without them in the meantime.

Simply disable analog mode (in CV29).  Few years ago Digitrax decoders and certain DCC systems had a similar problem and this solution was recommended.

[jagged ben]

Simply disable analog mode (in CV29).  Few years ago Digitrax decoders and certain DCC systems had a similar problem and this solution was recommended.

It's been a while, but I think I tried that, and it didn't help.  Maybe the decoder forgot that setting too.   

Oh, the other thing was that if the train had a short, the decoder was likely to forget its settings then, too. 

[peteski]

It's been a while, but I think I tried that, and it didn't help.  Maybe the decoder forgot that setting too.   

Oh, the other thing was that if the train had a short, the decoder was likely to forget its settings then, too.

Shorts across the rails will often produce a short spike of voltage which can "blow decoder's brains". I have observed that on multiple brands of decoders - not just TCS. But maybe TCS decoders are more susceptible to being "erased" by voltage spikes.

[Greg Elmassian]

I embarked on making custom speed tables for all my Z scale, on a loop with no switches.

Super clean track, one loco, no cars, NCE PowerCab...

Still have the TCS lose their minds more than any other decoder, can't remember when I had to reset a Zimo or Digitrax or NCE decoder, but full reset and runaway operation many times on TCS.

Then when I found that there are problems making a custom speed table (setting one CV sometimes radically affects others), gave up. I would get one close, and changing one of the steps would lead to a runaway... constantly re-loading the custom speed table.

I think there is an internal math error... you can actually wind up with a decoder where the steps do not all increase in speed...

I explain more here: (Z scale at bottom) https://elmassian.com/index.php?option=com_content&view=article&id=440&Itemid=504

Greg

[peteski]

I think there is an internal math error... you can actually wind up with a decoder where the steps do not all increase in speed...

I explain more here: (Z scale at bottom) https://elmassian.com/index.php?option=com_content&view=article&id=440&Itemid=504

I (and others) have discovered this problem few years ago. Yes, it seems to be a math error in the decoder's firmware.  TCS actually acknowledged the problem and told me that the problem has been corrected in the current run of decoders. But they have not told me who to tell whether the decoder has the old or corrected version of firmware.  I don't know if they have even updated CV7 (and I don't have any "new" Z2 decoders to check.

When I was testing my decoders, I noticed that some higher speeds steps were actually slower than the previous step, then the following higher step would jump to the correct higher speed.  So as I was increasing the speed steps on the throttle the loco was slowing down and going faster.

Here are some related posts:
https://www.therailwire.net/forum/index.php?topic=38397.msg464463#msg464463
https://www.therailwire.net/forum/index.php?topic=42276.msg532457#msg532457
https://www.therailwire.net/forum/index.php?topic=41588.msg519972#msg519972  and few following posts.

You could always dump the TCS Z2 and go with Digitrax new DZ126T. It's size is very similar to Z2.  Too bad that none of the European manufacturers produce decoders with this footprint.

[RBrodzinsky]

The LokPilot Nano is smaller than the Z2

[peteski]

The LokPilot Nano is smaller than the Z2

Yes, it is 7mm x 8mm (DZ126T is 14mm x 7.13mm) but the wires are attached on the 8mm which makes a bit awkward when trying to install it longitudinally in a narrow hood loco.  Sill, it is an alternative.

[AKNscale]

I think there is an internal math error... you can actually wind up with a decoder where the steps do not all increase in speed...

I explain more here: (Z scale at bottom) https://elmassian.com/index.php?option=com_content&view=article&id=440&Itemid=504

Greg

This is why I dropped Digitrax. I could get the locos close with min max mid, but had all kinds of problems trying to fine tune the loco speed for the speed tables. Much better now with ESU.

[MK]

But that quote is for TCS. 

[Greg Elmassian]

I have no issue with digitrax customer speed tables. Bear in mind that in my experience ALL decoders with custom speed tables have interaction between one "element" in a speed table and 1 or more "neighboring elements".

Also I see many speed tables strangely influenced by the highest "element"... so I have developed a technique where I basically set the speed table like CV's 2, 5, 6 and then "tweak" in between. That seems the fastest way for me. Actually I use a speedometer and match the smph to the speed step in 128 ss mode. I find a reasonable prototype top speed, and set that up (I "flatten" the speed curve at and above the prototype top speed)... that seems to be the part that "messes with" the rest of the speed table the most.

Peteski: when specifically (year and month) did TCS tell you they fixed it? From your post it was in 2016 at the Springfield show.

Any information from them is useful, it would be great if they said "from this firmware version forwards"...

Thanks, Greg

(sorry for the partial derailment)

[peteski]

Peteski: when specifically (year and month) did TCS tell you they fixed it? From your post it was in 2016 at the Springfield show.

Any information from them is useful, it would be great if they said "from this firmware version forwards"...

They didn't give me any specifics.  I don't even know if they keep track of the firmware revisions in any of the decoder's CVs. They just told me that if I have a misbehaving decoder to sent it to them and they will make it good (re-flash the microcontroller or replace the decoder?).  Maybe if you contact them, they will provide more specific info?

[AKNscale]

I have no issue with digitrax customer speed tables. Bear in mind that in my experience ALL decoders with custom speed tables have interaction between one "element" in a speed table and 1 or more "neighboring elements".

I was happy with Digitrax until I tried to match them precisely. They are much better than any of the Lenz, NCE, and MRC that I’ve dealt with(I’ve never tried speed match a tsunami to anything). However, in my experience, ESU does a much better job with motor control.