ECoS and latest TTS decoders

[PeterMC]

Hi , Is anyone else having problems with their ECoS controller and the latest Hornby TTS loco's. I have found recently with both a new Class 31 TTS and the Merchant Navy TTS that they will only respond to the ECoS when facing in one direction only. Change their facing Direction either manually or via a turntable or even a reversing loop and both of theses locos become unresponsive to the ECoS control. All ealier TTS locos of which I have quite a few work fine.

 

Anyone?

[Crosland]

There have been other problems with previous TTS decoders (class 67) on the programming track, but I haven't heard of this one.

 

It sounds like the ECoS may be putting out a non-symmetrical waveform on the track, the decoder only samples the signal from one rail and this batch of decoders are not tolerant.

 

I know which one I would put my money on being compliant with the NMRA specs

[RAF96]

Is this TTS going to work with just one plug? I'm rather new to all this.

I am not sure I fully understand your question if at all,

 

Edit: - or are you talking about the name Twin Track Sound. If so all it means is the decoder has one output channel (track) for playing basic speed dependant chuffing/engine noise and another channel for the user to play spot sounds like horn, whistle, brakes, etc.

Rob

Edited August 21, 2017 by RAFHAAA96

[Brian]

Hi

I have replied to this question on another forum with the text below. It may? help resolve the running issues if tested. IMO worth a trial anyway.

 

Assuming the system is locked to 128 speed steps (This is important with TTS decoders!) It now reads that the problem loco(s) are seeing DC and acting as though DC is their source.  Hence only operating in one direction.

 

I would suggest as a trial you turn off DC operation on the decoder. Usually this is via CV29 and setting it to 2 or 34. But I'm unsure of the TTS decoders CV settings, so check the decoder manual to see how DC operation is turned Off. This CV29 calculator site is useful for seeing the number changes needed. http://www.2mm.org.uk/articles/cv29%20calculator.htm

 

Once turned off, recheck locos operation on DCC, ensuring 128 steps is selected for that loco.

 

If the decoder cannot have CV29 set to 2 (unusual!) then consider adding bus filters to the rails or DCC bus pair. These should filter out any noise that the decoder is seeing? Well worth a try.  You can buy filters ready made, Gaugemaster should sell them under the DCC Concepts brand name or make your own from just two components.. See http://www.brian-lambert.co.uk/DCC.html#On

 

Another thing worth checking is the actual DCC rail volts. These should be around 13.5 to 15volts AC.  You will need a multimeter set onto its AC volts range to do this, unless the ECoS can read output rail volts?   Of course ordinary meters wont give an accurate DCC voltage reading but will give usually a good indication. For accurate DCC rail voltage readings you need a RRAmp meter or True reading RMS meter capable of reading at 10KHz or an oscilloscope.

[PeterMC]

I have posted a video of the issue I am experiencing with the ECoS controller which might clarify the situation:-

 

 

-Peter

[RAF96]

Very interesting and informative video Peter and methodical fault finding.

 

It all points to a setting in the ECoS somewhere conflicting with a CV setting in those particular TTS decoders, but I honestly haven't a clue, but let's see if Hornby can get to the root of it for you.

 

I will have another read of the short ECoS manual to see if anything else pops up.

 

Edit: Any way you can post a list of CVs and their values for the errant TTS models as these could be helpful.

 

Rob

Edited August 22, 2017 by RAFHAAA96

[Brian]

Hi

 

Just a quick question... I note your temporary track is using a plug-in track power clip.., Is this a DCC one? It must me so, and not a DC power clip.  Pop open the power clips case and look inside to see if there is a capacitor inside. (often a brownish orange colour) If there is snip its leads off and remove it and refit cover.

Edited August 22, 2017 by Brian

[Izzy]

 

Hi

 

 

Assuming the system is locked to 128 speed steps (This is important with TTS decoders!) It now reads that the problem loco(s) are seeing DC and acting as though DC is their source.  Hence only operating in one direction.

 

 Forgive me for going a bit OT, but I didn't know TTS decoders must only be used on 128SS. Since getting my TTS 31 I have only mainly used it on 28SS. I have had programming issues via JMRI/Decoder Pro but non at all using POM with the decoder set to 28SS or running the loco/sound. Have I just been lucky?

 

Izzy

[Brian]

Possibly? There are instances of TTS decoders not working correctly being reported when 128 resolves the issue! Unless Hornby have in the last few months changed the decoders spec.?

Instances around particularly the lighting controls not working in anything other than 128 setting.

Edited August 22, 2017 by Brian

[PeterMC]

Hi Brian, Yes the power clip is DCC compatible, its says DCC on its underside. The video correctly reflects exactly what is happening on my main layout that has a power bus and soldered droppers

Edited August 22, 2017 by PeterMC

[RAF96]

Izzy

 

I always understand that Decoder Pro will only correctly recognise a decoder after someone has written the 'spec' for it into the supported decoder listing, although one would like to think there was a basic decoder in the table that would at least read what was there even if it did not supply a proper description of each and every CV.

Rob

[GoingUnderground]

Have you checked that your ECoS is configured to use DCC only, with the MM, Selectrix and mfx/M4 digital protocols turned off?

[PeterMC]

Hi GoingUnderground

 

Yes the ECoS is configured for DCC128 and nothing else

 

-Peter

[Crosland]

Izzy

 

I always understand that Decoder Pro will only correctly recognise a decoder after someone has written the 'spec' for it into the supported decoder listing,

The service mode programming issues referred to may be the decoder at fault, not DecoderPro.

 

Some TTS decoders (class 67 in particular) cannot be programmed on systems that adhere to the NMRA spec but transmit only the minimum required "preamble bits". I am not sure if the problem is present in other models. This is what I was referring to in my earlier post.

[two tone green]

Have you tried turning Railcom off in the ECoS to see what happens.

[GoingUnderground]

Have you tried turning Railcom off in the ECoS to see what happens.

Worth trying, as the TTS manual that I found googling made no mention of the TTS decoder being Railcom compatible.

[PeterMC]

Hi Two tone and underground..........

 

Yes that was one of the first things I did when I got the controller, hearing that railcom could cause possible issues. It has made no difference with regard to the problematic TTS decoders I have.

 

-Peter

[PeterMC]

Hi All

 

Just a quick up date to anyone who is interested

 

I contacted Southwest Digital who are the UK importers of ESU equipment and it appears they have recently become aware that there is a compatibility issue between the ECoS and some Hornby TTS decoders. They said that they had made ESU aware of this but were unsure has to if or when an upgraded firmware to resolve this (if its possible) would be issued. They also advised me that a similar issue has been reported with the Bachmann Dynamis controller which is also an ESU product.

 

I also contacted Hornby who advised they have also recently become aware that the Class 31 TTS and the new Merchant Navy TTS would not work correctly with some controllers. they were not aware of any issues with the Virgin 125 TTS. However I am to parcel up the afflicted locos and return them to Hornby for further investigation under warranty.

 

I also left a message on the ESU support bulletin board but to date have had no response

 

Guess I should have done this from day one rather than rely on retailers to sort it out. Lets us see what transpires

 

-Peter

Edited August 25, 2017 by PeterMC

[GoingUnderground]

Thanks for the update.

[Robby S]

I've had exactly the same problem programming TTS 31 andTTS 20 decoders using Sprog and JMRI, also with my Roco Z21. Looks like they only programme with Hornby controllers? Has anyone successfully programmed them with any other make of controller? Its not too bad with a diesel as it doesn't matter too much which way round they are, but I hesitate to try to programme the TTS A1/A3 chip I've bought, as it would have to spend half its time running backwards.

[Sunnysa]

I've had exactly the same problem programming TTS 31 andTTS 20 decoders using Sprog and JMRI, also with my Roco Z21. Looks like they only programme with Hornby controllers?.

Not that this solves the problem, but, this is what happened with early Hornby decoders. They would only work etc, with Hornby systems. Looks like the old  problem has happened again. 

 

Cheers

Ian

[Phil S]

IF the orientation of the Hornby Decoders when programming is the ONLY issue, ten they are not alone - as (some) LDT modules/decoders and some others I have found are 'polarity sensitive' IN PROGRAMMING - and it is possible that a re-read of the NMRA spec may allow this ??? - it is not the same as this problem occuring when running normally on  the dcc track, and responding operationally to incoming data. - the 'solution' during this case is simply to reverse the connections (or rotate the loco) during programming.  [ It suggests that the software is looking for a rising edge to trigger a proxess  ..  also, programming often starts from '0' volts ... with data/voltage only being present on the prgramming thrack for a short time whenthe programming command is confirmed by the user ..... this was previously a known problem for programming sound decoders, and the Hornby Accessory Decoder, as I recall ..... the work-arond solution was to ensure track power was present until the last moment before programming to ensure the larger capacitors were charged before programing started.

 

This may or may not be related to the 'compatibility' issue I found recently when using the HST and some other (Gadwall ... ) decoders in which I 'lost control' as they appeaed to 'latch up' into an unknown/unresponsive state with my Roco Multimauses/pros, BUT always worked with a Hornby Select or Roco Maus2 !! [ ALL of which checked out to have the correct waveform timings - BUT may have varied in preamble OR certainly in 'cycle' time before the controller returned to them ] 

{ A Roco Maus2 I think had an 8 loco cycle, the Multimaus uses 16, and the Multimaus Pro 32  .... unless the latter two were 32 and 64 respectively: The original Lenz/LGB/Roco/Arnold Maus has an 8 loco limit.  There were 'complaints' from users about the slow response of the MCP which may have been related to the long cycle time in comparison to its predescessor.      I did observe a 'spark' when placing the TTS locos onto the track - which makes me think in terms of charged / discharged capacitors being involved in the problem.... especlially as if left for 2 days (to self discharge), the locos all responded normally again on all the controllers.

I may be able to test the cycle time as part of the effect by using my Massoth Dimax - which gives the user a choice of  cycle time / number of active locos possible, as well as a reducable track voltage  ( defaulting to 20V bcause it is primarily intended for Garden use with LGB )

[Robby S]

Having programmed numbers of class 20TTS and railroad class 31 with TTS chip on Sprog and JMRI and they only work one way round, I put on elink and Railmaster and they work fine both way round without any reprogramming. I guess Hornby only checked that new TTS decoders worked on their own systems. Any ideas?

[RAF96]

Phil

You say that in post 23 that reversing the loco or swapping the leads during programming may be a solution. If not do you see the original problem swapping ends using this method. i.e. before it say only went forwards, reprogram from the other way round, does it now only run backwards.

 

The interesting thing in Robbys post 24 is that without any other rework the thing responds correctly using Hornby controllers and that the DCC waveforms appear correct. A direct comparison to see if there is a different noticeable detection point on the curve would be good.

 

Also is there any difference in directional response if the loco is programmed on the Hornby kit than if it is programmed on non Hornby kit. If so that would lead one to think the 'fault' is with the errant controller, else it lies within the decoder.

Rob

Edited September 8, 2017 by RAFHAAA96

[Izzy]

 The TTS decoders I have work fine in both directions on my Gaugemaster/MRC PA2 system and program without issue using POM - I never hook up the PA2 program outlets - but as others state can only be seen and programmed using my Sprog/JMRI in one direction, the other way around all that happens is that error messages are generated.

 

I believe that the reasons why this may be happening has been mentioned in a post somewhere and due to the differing ways particular systems communicate with decoders, the signals that are used.

 

I think that perhaps I am just lucky I have a system that works with them, but frankly it shouldn't just be down to luck and I hope it gets resolved one way or another.

 

Izzy