TTS locos only working in one direction...

[Froggie]

Me again,

To recap: I have an ECoSII and I have been having trouble with re-adressing a Class67 with TTS.

I may have good news - and this is only from my personal experience. Having read here, and in other fora and on other sites about problems regarding TTS and other makes of DCC controllers, here is what I did in the last couple of hours or so...............

The loco had already been detected with address Default3 but I was unable to read the decoder profile. Ensuring that the loco was still recognised by the ECoS, I left it on the track with lights on only. I then changed the default of DCC28 to DCC128 and turned off all the boxes regarding Railcom and changed the programming to Programming On Main POM. Tentatively, I then changed the address from 3 to 4 (daring I know). Lo! It responded to a direction change (lights fore and aft reversed). It also responded to throttle. I then gave it its 4-digit number to which again everything worked - lights, sound, throttle.

HOWEVER, what it didn't like at all, and it's taken me ages to re-set, was trying to read the decoder profile. It decided it was under Motorola14 protocol and it lost all the functions bar the first 8. Once having reset the address back to Default3 and re-assigned manually the function keys (9 to 23 only as I need a firmware update for the ECoS for others), it worked again and took its 4-digit address. It kept on working even after I reset the DCC and Railcom defaults.

So, for the time being, I have a working TTS loco with all functions working AND a 4-digit address. What I don't have is a means of reading the decoder profile and changing CV addresses - but then I don't need to - nor can I set the maximum speed, but I shall live with that as I have no layout. So until there is a fix that covers reading the decoder, I'm leaving well alone. Thumbs up to me ;)).

If anyone else wants to try, be aware that your mileage may vary according to your particular set-up.

Cheers,

Phil

[96RAF]

Well done Phil

 

There is a clue in what you have done and that is putting the ECOS into 128 speed steps. This is an absolute requirement for TTS decoders to work correctly along with setting CV3 and 4 (accel/decell) to a value of at least 15 (15=default).

 

After your ECOS update things may be improved even more.

Rob

[Bigskybirds]

The update earlier this week from Hornby was their technicians had found the issue which requires the loco to be returned for the decoder to be reprogrammed. They said to contact them again in a couple of weeks to arrange for my loco to be returned for this procedure to take place. 

[Phil_Spiegel.]

Hopefully they will make a formal announcement of the procedure involved, and perhaps which BATCH numbers are affected (if known).  It would be helpful if anyone reporting a problem ALSO identified the Loco production code/date (from the white label) if it was pre-fitted, or from the TTS Decoder box if it was bought separately.

I have 3 x Virgin East Coast HSTs (2 decoders in each set), a Gadwall A4 and Class 47, 67, K.Castle, Std 7P, Scotsman  pre-fitted with TTS,  and now a batch of 7 of the after-market separate decoders I am fitting - these not having shown the problems so far... 

GADWALL on test:REF01-91227 R3285TTS -43-852   

The following is a re-edited summary of tests made this afternoon, which were ale to RECREATE the problem(s) and also showed recovery from them - but although 'repeatable' not specifically on demand each time 8-(

I had previously reported the apparent 'lockout' of several pre-fitted TTS locos, when used with Roco Multimaus+Amplifier, MultiCentralePro, and Z21 - BUT NOT with a Select OR ROCO MAUS2 ... the lockout lasting for possibly several days before appearing to hae recovered - which must frustrate anyoe looking at a loco returned by post !! - but which changed instantly to either the Select OR MAUSE 2 from any of  the others.  [select having only limited addressing and other problems, Roco Maus 2 only locos 1-99.].  When a spark is also observable placing a loco onto the track, a capacitor related problem is suggested!

A POSSIBLE CLUE:   EARLIER THIS AFTERNOON - when testing after reading these forum posts:

Yes - lookat the 14 / 28 / 128 speed step settings  BEFORE ADDING THE LOCO TO THE TRACK... AND IF IT IS POWERED UP on 14, THEN YOU CREATE THE PROBLEM even after you have changed the controller settings to 28 or 128  .... I NOW have an unresponsive loco which will now not work on any of the speed settings   (Gadwell in today's test) ...From previous experience, although, it willl probably respond okay on a Select or RocoMAUS2, the problem will recur as soon as I go back to a Roco Multimaus,  MulCentrrale PRo or Z21 .... until I leave the loco to stand unpowered for a day or two.

As I reported earlier this year, when experiencing this - and checking all the waveforms/timings to be correct (actually, the Select looks terrible for ringing until loaded by a loco or 2 on the track !!) - all my voltages are correct (Roco Multimaus/MCP both powered from SMPS giving a stable 16Vdcc on track which is well within spec (Anyone using a Multimaus+Amplifier with the original heavy transformer should replace it with a 18Vdc SMPS of 3-4A rating, as now supplied by Roco - the Amplifier accepts dc power)

"It behaves as if a capacitor 'latches up' when the situation occurs" ... and until this has had time to decay away, the problem will persist WHATEVER subsequent changes are made = ALTHOUGH this thought IS confused by changing to a Select or MAUS2 .. which made me think it may be related to PREAMBLE durations (which MIGHT be different) OR NUMBER OF LOCOS in the ACTIVE CYCLE sent to the track -  With a Multimaus it is 32, and MultiCentralePro it is a longer 64 loco cycle. [Is the Select 10 ? and the Maus2 possibly 8 ??]  [As the timings of individual 1's and 0's on the different systems including Select were all the same]

So does the Hornby decoder 'store' a speed-setting related value on a capacitor rather than rewriting a non-volatile memory element??

WITH REGARD TO REVERSAL ON A PROGRAMMING TRACK to have successful programming  - this MAY be within a loose NMRA spec - I have Accessory Decoders from LDT, for example - and they are not alone - in which it is stated that programming may not occur with one phase of the dcc connection - and to reverse the leads if that is the case.  During PROGRAMMING on the programming track, it is NOT the 'normal direction agnostic' situation - but a 'programming sequence of events' ..and the designers may have made this 'polarity sensitive'  [ and in this situation we are talking about the TTS decoder designers ] :  For instance, on Lenz (original designer of nmra DCC), the 2 track connections are identified by letters, so that the phase is known and can be standardised on each accessory device  - it MAY be affected by the differing ways different makes ground/float their outputs - especially when other parts such as Feedback busses are included in the system.   Do not make the assumption that ALL decoders from ALL manufacturers operate or detect the signal the same way!

Level, and Edge triggering / detection are both valid methods - and when noise-windows or shapes/levels of adacent pulses are also considered (  as in the case of digital TVs and 'Vitterbee decodong' ) ... they may respond differently in different environments - hence gving the user some choice.

In the time taken to write this so far - the Gadwall appears to have recovered, and is working on 14 28 and 128 speed steps - there being no LIGHT on the loco to show a visible difference betweem 14and 28 or 128 steps  ... only my controller menu setting (usually on a default and loco by loco basis)         If the 14 speed step startup is the cause, then this would mean my MCP controllers would regularly trigger the effect as (since a particular s/w version) they default to 14 speed steps - unless overwritten by the Library value or connected-PC value for that loco ..   a known but annoying error when used at exhibitions each morning 8-(

It is also working on 14 /28/128 speed steps on both the Multimaus+Amplifier and MulticentralePro - so much for cycle lengths ???

BUT NOW I am testing one [two ends] of the Virgin TTS HSTs .... both ends apparently dead [no sound lights or movement], and not responding to resetting or other programming ---  TURNED ROUND on the track - and resetting worked immediately and then programming to a long address..  I turn it round again and its as dead as before  ..... and this loco had not been used for months.

(This was tried on both Rocomaus+Amplifier - where, when the correct way round, programming suceeded ( no readback used ) but when on the MCP which uses readback, the programming attempt 'hung' in a similar way to that reported for the ESU...

THE TTS DECODERS used inthe Virgin EC HST are of the '2 part' variety. The after-market TTS have been 'single chip'

 Time to get some other work done...

 

 

[olly]

Hopefully Hornby will make an announcement about the TTS decoders soon then everyone will know what's happening .

 

I won't be buying any more till the issues have been resolved .

 

I have a hornby elite at the moment but may buy something else in a year or so when I build new layout so don't want to buy something that might not work in the future 

[Phil_Spiegel.]

AN UPDATE on my Friday posting  on TTS Unidirectionality  ( also mentioned on rmweb and sent to customer support )

Modifiying my original impression that it was behaving like a capacitor charge / latchup problem -- because they worked again a few days later.....

As with many others, it seems, I am experiencing problems with the Hornby TTS Sound Decoders - 'Unidirectionality' - when used on 'other makes' controllers (my default) - such as Roco Multimaus, MultiCentraleCPro (with Multimaus or MultimausPro), and Z21 - others reporting it with ESUs and more.

When I originally started buying the TTS fitted models, and tested them, I did not realise that I needed to try them facing both ways !

When experiencing the 'suddenly dead' locos, I tested them with many different controllers - but omitted to rotate the models !!! I did measure the timings and observe the waveforms in each case - the timings were absolutely identical. I DID APPEAR TO FIND that they 'recovered' after being left for a few days - making me think it was behaving like a 'capacitor' problem ... which had to self-discharge for recovery.... but it MAY of course be that when I tried them a few days later, they were simply facing the other way 8-(   bad diagnosis 8-( [ previously reported in H Forum ]

To confuse the situation these locos appear to work on the Hornby Select and Roco MAUS2 (the latter using the same amplifier and SMPS Power Supply as the Multimaus). - and since they 'recovered instantly' when on either of these - it is more suggestive that it was the DIRECTION of the PHYSICAL LOCO which was the difference. !!!!! --- BUT these controllers (Select or Maus2) ALSO REQUIRED that only short addresses be used ( I normally use 4 digit )   [Another possibility being 'cycle time' before repeating the loco data / and timeout problems  as the differing controllers support a different number of active locos ]

I first experienced the  'lockout'  in February, when testing a layout for Eurotrack using my Great Nephews to operate it : I had taken some UK TTS locos for them to try because of the added sound effects (and their durability) ... And of course locos were lifted on and off the track ovals - POSSIBLY changing direction but without me thinking of it as any problem ..except when they stopped working if the Multimaus was Master Controller. BUT since I had provided the boys with Maus 2 controllers [for their Playmobil'G Scale], we swapped over ( because I have also discovered that they program some locos others can't - the Multimaus which had previously programmed them now refusing to do so ), I used the Maus2 to reprogramme the locos to short addresses and they then worked... (with the Maus 2 ... and perhaps if facing one way whenever I retried the Multimauses later.)

There have been suggestions that 14 Speed steps created a problem with them - the manual advocates (only) 128 - a decoder can be set for 14 (old standard) or 28/128 {newer standard] as part of CV29 . Again, I thought I had verified this on Friday - BUT it might have been confused by a direction swap ???

WIthout the Problem of Lights going on and off with speed change, there should be no real difference in operation between 14 and 28/128 steps - NONE of the models under test had lights connected [it is so easy to lose confidence in the reliability of a product .. and having bought many of them.. with more on order, more concerning.. I also thought I saw the 'forward' direction change when it was set to 14 speed steps - (on a steam loco) but this is not easy to recall with diesels [ again, there was a historical change from the 'early days' to nmra DCC - which is why LGB /'MTS' locos run the other way [and Bachmann G Scale locos include a switch to avoid the problem. Hornby's Zero-1 changed its forward direction a few weeks after launch (Red Fwd/Rev Labels were provided to us early purchasers 8-) ]

There has been, and on Friday during testing, with one loco, I did seem to experience that the 'lockout' occurred after sending 14 speed step commands - BUT at the time I may still not have been fully taking into account the 'rotational' effect that should not be occurring !!! ( I was still thinking in terms of a capacitor at the time)

My current list of 'uni-directional' TTS models on Roco Multimaus has grown to: ============================================================

3 x Virgin East Coast HST (6 decoders),

1 x M/N Holland-Africa Line R3382TTS LOT01- PO10001181 R3382TTS-16-421

2 x Class 31 -added decoder REF01-10002972 R8101 27 421

 

Okay at present: no unidirectionality observed

===================================

2x King (added decoder) REF01-100002973 R8109-27 421

Class 67 Cairn Orm 6704 TTS fitted A4 (added decoder)

A1 Railroad Flying Scotsman REF01-91227 R3284TTS 18-078 Factory-fitted

Not yet RE_tested for 'uni-directionality'

=======================================

Class 47 TTS fitted,

Kilwilly Castle TTS fitted

Class 40TTS fitted

Tornado - add-on decoder ,

A1/A3 Pacific - add-on decoders x2

 but GADWELL A4 TTS okay at the moment REF01-91227 R3285TTS -43-852 (matching the Okay behaviour of the Add-On A4 mentioned above)

Someone else reports Hornby have a solution ! Meanwhile .... no more hard-wired installations, even though my replacement speakers have arrived today 8-(  [ 20mm needed for the Non-Railroad Class 31, adjacent fan ]

Checking one of my class31s intended for sound addition showed it had also suffered from metal bending of the cab floor casting which has broken the body moulding at front and back! TOPS 31270 Weathered Blue - ouch !! Mazak fatigue ??? 

I remain intrigued as to what they have done in the decoder design to create this total lockout occurring in one physical orientation from an ac signal !!!    The loft-layout my UK stock is intended for has both auto-reverse sections and turntables - so needs to be resolved.

[Fishmanoz]

For a start your TTS sounds will only work on 128 speed steps apart from any other faults. 

[Bigskybirds]

 @Phil_Spiegel

 

I think you will just have to wait and once Hornby have finally resolved this send your locos back for reprogramming. It is not a problem with the controllers it is Hornby's TTS decoders. They told me they will not be sending out replacement decoders but reprogramming existing ones with this issue, which if this is the case they must know what the cause is.

[Phil_Spiegel.]

Fishmanoz said: "For a start your TTS sounds will only work on 128 speed steps apart from any other faults." 

Phil Spiegel replied: You are incorrect !!    They DO work on 14 speed steps as well (when they work)  Otherwise I would not have written as such after testing them on  14, 28 and 128 speed steps.    If you have a controller capable of selecting different speed settings on a loco by loco basis - try them.    However, IF there were directional lights on F0, then these would of course work incorrectly on 14 speed steps as the decoder is set for 28/128.

 

 

 

 

[96RAF]

I think what Fishy was trying to get across was that according to the instructions TTS decoders need to be run on 128 speed steps to work correctly. This is due to the way the decoder synchronises the sound against track speed and throttle setting (loaded - accellerating or coasting - decellerating) including by way of bemf sensing, as well as the minimum required set values for those parameters (CVs 3&4 @ 15). The fact that TTS works after a fashion on other ranges, including DC power is beside the point.

Rob

[Phil_Spiegel.]

DCC Function commands F1- F28 are totally independant commands from the speed+direction command byte(s).

The main discussion has been as to whether ANY response at all occurred with these decoders - with some having suggested that 14 speed steps was an issue.    Programming and Operation both fail with 'loco orientation' on the track for the models I specified that  suffered from the problem.   When working; the movement, sounds and lights (if fitted) respond regardless of controller speed setting.

 

Whether the sound amplifer stage,  motor drive stages and function outputs work, OR NOT IS PRECISELY THE POINT !!

No decoder CVs were altered between changing speed step settings at the controller - and the loco was unpowered between settings, and so saw each as a fresh start.  Whilst CVs for acceleration, decelleration and starting delay MIGHT affect 'synchronisation'**, as with the speed commands sent, they do NOT affect whether sounds, lighting or movement are produced at all (other than the effect on directional lighting of the combined 14speed step and 'F0' direction byte), if present).   

The response was therefore an incorrect 'Red-herring' - and required correction ... in the same way that I have corrected my earlier interpetation that it was 'capacitor-like' in its latching up the loco.   [ ** TTS has no direct mechanical synchronisation to revolutions ]

I can now also report that my factory-fitted  7MT Duke, Kidwelly Castle and Class 40  do not appear to suffer from the problem.  My Class47 still untested.    I have also connected the track via a PSX intelligent circuit breaker - and this makes no difference - the  orientation fault is still present on affected locos as before.

 

[96RAF]

Phil

In that case assume those decoders are faulty and do as suggested by HFM - arrange to send them back for reprogramming.

Rob

[Fishmanoz]

Dennis’s post led me to read back a bit and I find I seem to have missed Phil’s reply to me on 14 v 128 speed steps, hidden as it was in a useless yellow box.  My mistake Phil, I was sure I’d seen this in a TTS leaflet but not so.  Interesting though re-reading the CV29 notes which indicate it is usually not necessary to edit bit 1 as the decoder will handle it automatically.  Does that mean you can set your controller to 14 and lights will still work as the decoder is still on 128?

[Metadyneman1]

I'm so glad I found this thread because I thought I was going mad when my TTS class 31 decided to stop working. I turned it round 180 degrees and it sprang into life! So it seems I have one of the affected decoders in my 31. It is a hybrid 31 with a lima body and i have hard wired lights into it so i sincerely hope I don't have to return it to Hornby because it will require desoldering and such like!  I might just put up with it "as is" if that is the case. 

[Fishmanoz]

Hi Mm, welcome to the forums. It’s just the decoder needs to go back, not the whole loco.

[96RAF]

I would explain to Hornby that the TTS decoder is hardwired into a loco with lights and could they reprogram it as is - in situ.

My knowledge of the reprogramming procedure is the decoder needs to go in a bench jig so that the programmer interface ‘pins’ can make accurate alignment.

Discuss with HCC is my advice, rather than live with a known problem that can be fixed.

Rob