Hello, Well I am seeing a problem with TCS decoders, and I am not the only one. One of my good friends is seeing the same thing. You get a TCS decoder install it and program it. You run it a while and then you set is aside for a while. Now when you come back to it, all of the programming is gone and the decoders does not accept new programming either. The timeline we figured out was between June 2013 and October 2016. It was so bad, my friend, a TCS distributor, stopped dealing with TCS decoders. Anyone else see this? We spent a great deal of time checking out the wiring and the power etc, but with several different layouts we do not think it is the layout that is the problem. In fact all other brands of decoders installed before this time are still working well. So tihs only affects TCS decoders.
Not seen anything like that. All my TCS, except one, are still working as expected. The one which isn’t, which is from before your timeframe, does all sorts of craziness, particularly thinking it is on DC, even with the CV set to turn it off. It is one of the “up next” locos for ESU conversion, though.
Well all mine and a couple of members of Peninsula N-Trak are all seeing the same things. I am thinking the same thing and replacing all the defective TCS with ESU or Zimo. I have had a really great experience using the Zimo MX621 decoders for wired decoder application and the 6 pin version is in all my Fox Valley locomotives. I am hoping that ESU will do more board replacement decoders for Kato locomotives and I will be dancing in the streets!
Here is what I get: It cannot read the decoder address, JMRI identifies it as the wrong decoder Here is the Front page of JMRI showing the decoder information And the last page is showing the manufacture date. This is what me and my associates are seeing. Cannot even reset the decoder, no decoder found comes back.... I can supply additional screen shots. This happens with every TCS board decoder so far meaning Altas, Kato and Intermountain
I do have a number of SD45's with TCS decoders that have become unresponsive. I only have some freemoN modules to run on so I run what works. I have not attempted to recover those unresponsive units yet. I hope the problem comes back to a simple setting as I always liked the smooth operation from the TCS decoders.
I did too, I dropped all plans for Digitrax once TCS added Trim and started making Kato drop-in decoders.
I had what sounds like a similar problem with a few TCS MZA4 decoders. Decoders were programed in JMRI with a DCC++ base station. While in operation on the main, the engine would freeze and became unresponsive. I was unable to read, program CVs, or reset the decoder on the programming track. I figured I had a dead decoder. Tried to do a factory reset with a NEC power cab and then I was able to reset the decoder and it came back to life. I figured it was an issue with DCC++ at the time. I never had a problem with them that a factory reset wouldn’t fix so my issues may be completely unrelated to the issues you describe. Matt
Tried that with my ESU ECos System, same result. I am an Electrical Engineer by trade and have done more troubleshooting than I care to type out and explain. It is what it is, a QA issue with TCS manufacturing.
Update I have been working with TCS about this. With the information I gave them, it lead them back to a bad batch of processors. And being a stand up company, they are offering to replace every one of the bad decoders regardless of warranty status. We now have the cause and solution.
Does this suggest that they shipped defective decoders to customers? Don't they test every one for functionality as part of the production process?
That's the kind of response I've come to expect from TCS. I find their decoders are fantastic, and they've always rectified every issue I've had.
Not to my knowledge. About a half dozen of us friends saw these issues and we were told to contact TCS to replace the decoders.