Programing problems

[Shedmaster 47]

Hi folks ;

I have a niggling problem with an Hornby class 37 TTS sound fitted Hornby loco ...

All works fine from the box and i managed to reprogram the address from the default of 3 ....i have sinse changed the body on this loco , so naturally want to change its address to match the new body !!

This is where the problems start. It refuses point blank to change from address 3 ...all functions still work ( sounds and movement )....

I use an prodigy express on a program track..i also have a Dynamis system and an NCE powercab

NONE of the above will rrprogram said loco ...Ive even done a decoder reset , now it appears locked into address N°3!!.....

Any ideas would be welcomed .

Thanks

Allan

[tractor_37260]

Hi folks ;

I have a niggling problem with an Hornby class 37 TTS sound fitted Hornby loco ...

All works fine from the box and i managed to reprogram the address from the default of 3 ....i have sinse changed the body on this loco , so naturally want to change its address to match the new body !!

This is where the problems start. It refuses point blank to change from address 3 ...all functions still work ( sounds and movement )....

I use an prodigy express on a program track..i also have a Dynamis system and an NCE powercab

NONE of the above will rrprogram said loco ...Ive even done a decoder reset , now it appears locked into address N°3!!.....

Any ideas would be welcomed .

Thanks

Allan

 

If possible, try programming it on the main - POM  - that "may" work ? 

[Crosland]

Also, try turning the loco around on the programming track. Various TTS decoders have had various issues relating to programming.

[Shedmaster 47]

Thanks for your help gents .

After building a seperate programing section on my layout ( so as not to accedently program ALL my loco at once on the layout ) i have now managed to change the address of this troublesome machine by programing it with the NCE " on the MAIN " ....All now works fine with a NEW address asigned !!

Thanks again ...

[Phil S]

Also, try turning the loco around on the programming track. Various TTS decoders have had various issues relating to programming.anadian

If turning the loco physically around on the track DOES resolve the problem - then contact Hornby Service to have the decoder reprogrammed (firmware) -  I arranged to send 12 back at the end of last year and they were returned within the week .... whilst I had spent 'months' periodically pondering on the problem before picking up on the problem of the loco behaving differently [dead] when physically rotated - as mentioned by a Canadian contributor on here back in April 2017 ... it originally seemed so implausible that such an error could occur with an AC track waveform [dcc] without using 'loco 0 - assymetric mode'

[malcolmv]

Help,I have tryed to fit a TTS decoder to Hornby R3443 Flying Scotsman,which run fine with a none sound decoder I have now tried 5 different TTS decoders & have the same problem none of them will program,I use a Prodigy advanced.My model shop have no advice & are fed up of keep changing them they say almost all the TTS decoders they,ve sold are being retured.Is this a common problem??

[smokebox]

See https://www.Hornby.com/uk-en/forum/Hornby-tts-decoders-reported-problems/?p=1

[Crosland]

whilst I had spent 'months' periodically pondering on the problem before picking up on the problem of the loco behaving differently [dead] when physically rotated - as mentioned by a Canadian contributor on here back in April 2017 ... it originally seemed so implausible that such an error could occur with an AC track waveform [dcc] without using 'loco 0 - assymetric mode'

 

Poor decoder design and asymmetric (but still within spec) output from the command station.

[RAF96]

Poor decoder design and asymmetric (but still within spec) output from the command station.

Not convinced that a fault recovered by reprogramming the firmware can be called poor decoder design. A fault in the code or programmer possibly. Allied to the fact that the problem was seen mostly by folk using ‘alien’ controllers shifts the problem sideways a tad in my view.

 

(Alien = non Hornby)

 

Rob

[Phil S]

Poor decoder design and asymmetric (but still within spec) output from the command station.

Phil;: NO the controller outputs were NOT assymetric at BIT level - all zero crossings were perfectly timed, and the shapes appeared symmetrical.

Controllers I tested were Roco Maus 2 and Hornby Select* (NEITHER introduced the problem, but Multimaus, MultimausPro/MultiCentralePro (software in the MCP box not handset) and Z21 all revealed the problem ... didn't get around to trying my Sprog2 or Massoth Dimax.   I no longer have any ZTC or LGB MTS or Bachmann EZ dcc to try..

 

Assymetric processing in the receiving (Hornby) decoder presumably.  The Powered and Dummy VTEC HSTs had to be facing opposite ways ('as normal' to work - suggesting their software is slightly different !!! )

*Severe ringing on output but still working. Ringing largely damped by 2 TTS decoders (HST)  All Roco, and Select controllers using their SMPS supplies

Edited January 30, 2018 by Phil S

[Roger Sunderland]

Not convinced that a fault recovered by reprogramming the firmware can be called poor decoder design. A fault in the code or programmer possibly. Allied to the fact that the problem was seen mostly by folk using ‘alien’ controllers shifts the problem sideways a tad in my view.

(Alien = non Hornby)

Rob

Surely there is no such thing as an "alien" controller? All DCC systems should program all decoders. Are you suggesting that TTS decoders should only be programmed by Hornby systems.

I think the number of reported faults in TTS decoders on this forum (on many different threads) suggests where the problem lies.

[RAF96]

Surely there is no such thing as an "alien" controller? All DCC systems should program all decoders. Are you suggesting that TTS decoders should only be programmed by Hornby systems.

I think the number of reported faults in TTS decoders on this forum (on many different threads) suggests where the problem lies.

And we all know that some sound decoders need more current to program than is allowed under the NMRA spec, so where does one go from there if the spec doesnt allow stuff to work.

 

As stated elsewhere on the forum many manufacturers dont even bother to get NMRA approval, merely say their kit complies without the official stamp.

 

Shades of the EU in my opinion.

Rob

[Crosland]

Not convinced that a fault recovered by reprogramming the firmware can be called poor decoder design. A fault in the code or programmer possibly. Allied to the fact that the problem was seen mostly by folk using ‘alien’ controllers shifts the problem sideways a tad in my view.

 

The firmware is an inherent part of the decoder design. If it can be fixed then the initial design was poor. This is not the only issue that TTS users have experienced due to poor design. Some Class 67 TTS decoders need extra pre-amble bits when programming, for example. Again due to poor design or testing.

 

If all parts are designed and tested to the spec then there is no such thing as an "alien" system when it comes to decoder programming. Some of the TTS problems clearly stem from not being tested with a wide enough selection of systems.

[Crosland]

And we all know that some sound decoders need more current to program than is allowed under the NMRA spec, so where does one go from there if the spec doesnt allow stuff to work.

No they don't actually.

 

I have invested a lot of effort in sound decoder programming and I can say with confidence that all sound decoders I have come across meet the NMRA requirement to draw less than 250 mA, 100 ms while after power up.

 

There are a lot of systems, however, that cannot, or could not, cope with an initial high inrush current, even though it is within the spec, hence the various kludges such as resistors and programming boosters that we've seen over the years.

[Crosland]

Phil;: NO the controller outputs were NOT assymetric at BIT level - all zero crossings were perfectly timed, and the shapes appeared symmetrical.

Controllers I tested were Roco Maus 2 and Hornby Select* (NEITHER introduced the problem, but Multimaus, MultimausPro/MultiCentralePro (software in the MCP box not handset) and Z21 all revealed the problem ... didn't get around to trying my Sprog2 or Massoth Dimax.   I no longer have any ZTC or LGB MTS or Bachmann EZ dcc to try..

 

Assymetric processing in the receiving (Hornby) decoder presumably.  The Powered and Dummy VTEC HSTs had to be facing opposite ways ('as normal' to work - suggesting their software is slightly different !!! )

*Severe ringing on output but still working. Ringing largely damped by 2 TTS decoders (HST)  All Roco, and Select controllers using their SMPS supplies

 

In that case there is another mechanism that explains the problem. I can't think how to explain it in simple terms, but the decoder must be making invalid assumptions about the encoding of the bits. Turning the loco round will make each half bit change polarity so the decoder sees two half bits of 1, 0 instead of 0, 1 and fails to decode anything. Only the timing matters for decoding the data, not the actual voltage levels.

 

Technically minded can go to the NMRA specs to see what I mean by half bits and how the data is encoded.

[malcolmv]

Not convinced that a fault recovered by reprogramming the firmware can be called poor decoder design. A fault in the code or programmer possibly. Allied to the fact that the problem was seen mostly by folk using ‘alien’ controllers shifts the problem sideways a tad in my view.

 

(Alien = non Hornby)

 

Rob

Rob,how many of us use Hornby controllers,maybe a starter

[Phil S]

In that case there is another mechanism that explains the problem. I can't think how to explain it in simple terms, but the decoder must be making invalid assumptions about the encoding of the bits. Turning the loco round will make each half bit change polarity so the decoder sees two half bits of 1, 0 instead of 0, 1 and fails to decode anything. Only the timing matters for decoding the data, not the actual voltage levels.

 

Technically minded can go to the NMRA specs to see what I mean by half bits and how the data is encoded.

You appear to be making the assumption that all decoders are detecting the edges and therefore timing rather than using level detection - which they may also use with a noise window to avoid false results. -  - as in  'flywheel' circuits used in sync separators - and for example needed in timecode readers - a similar mark-space /FM coding system to cope with speed/timing changes ( not that the timing of a dcc controller(s) should vary much except with loco 0 which is not allowed on many anyway ) or even viterbee decoding ( unlikely in a cheap decoder?! - but extensively used for DTV decoding and digital video tape)        - but the principle applies. The surprising thing is that anything works on a 'Select' with that much ringing ... although it does appear to damp down with load.

BUT a Roco Maus2 ALSO has no problem with the problematic TTS decoders: - using the same Amplifier and Power Supply as for the other Roco systems tested -  

As the Active-Loco capability of the Roco Maus2 is less than the Multimaus and in turn less than the MCP and Z21, I did wonder if it was to with the CYCLE TIME of ACTIVE LOCOs ... 8 with Maus2   16 with the Multimaus and 32 with the MCP  (or that may be 32 and 64 on the last 2 - its a long time since I counted them on an NCE dcc reader ) - it might be that the 'more advanced' controllers are taking too long for the problematic TTS decoders to wait to respond??

THis is one reason why I did intend to try them on my Massoth Dimax - as the user can select the number of active locos and therefore the data cycle time - the idea being that in 'dirtier gardens' you can send the loco speed more often ... LGB decoders having always made a feature of their memory use to cope with brownouts in data as an alternative method to 'keep going'.

Another useful feature of the RocoMaus2 is its multiple programming methods and the user control offered if needed - but otherwise transparent; which is why I retain one, whilst having used the remainder to provide great-nephews with a simple controller which meets their immediate needs

[RAF96]

Rob,how many of us use Hornby controllers,maybe a starter

Start a poll??

[RAF96]

No they don't actually.

 

I have invested a lot of effort in sound decoder programming and I can say with confidence that all sound decoders I have come across meet the NMRA requirement to draw less than 250 mA, 100 ms while after power up.

 

There are a lot of systems, however, that cannot, or could not, cope with an initial high inrush current, even though it is within the spec, hence the various kludges such as resistors and programming boosters that we've seen over the years.

 

What about those sound locos that will only program on the main such as MTH multi-protocol locos.

[RAF96]

The firmware is an inherent part of the decoder design. If it can be fixed then the initial design was poor. This is not the only issue that TTS users have experienced due to poor design. Some Class 67 TTS decoders need extra pre-amble bits when programming, for example. Again due to poor design or testing.

 

If all parts are designed and tested to the spec then there is no such thing as an "alien" system when it comes to decoder programming. Some of the TTS problems clearly stem from not being tested with a wide enough selection of systems.

I wonder how many other manufacturers test with as many other make controllers as Hornby do.

[Crosland]

What about those sound locos that will only program on the main such as MTH multi-protocol locos.

WHat about them? They simply do not properly support service mode programming, nothing to do with current drain. See http://www.rmweb.co.uk/community/index.php?/topic/122463-mth-locomotives-and-dcc/ for example.

[Crosland]

I wonder how many other manufacturers test with as many other make controllers as Hornby do.

 

So you know how many Hornby test with? Please enlighten us  Not enough, obviously.

Edited January 31, 2018 by Crosland

[Crosland]

You appear to be making the assumption that all decoders are detecting the edges and therefore timing rather than using level detection

Quite the opposite. I am assuming level sampling with repeated samples to resolve the data, based on Dean Probst's old design and the MERG decoders. i can see how it would be easy to detect the incorrect level.

 

Edge detection is only really useful for tricks like Lenz's USP. It allows capacitive coupling so you can continue running over a sheet of paper. Not many layouts are built that way

 

 

As the Active-Loco capability of the Roco Maus2 is less than the Multimaus and in turn less than the MCP and Z21, I did wonder if it was to with the CYCLE TIME of ACTIVE LOCOs ... 8 with Maus2   16 with the Multimaus and 32 with the MCP  (or that may be 32 and 64 on the last 2 - its a long time since I counted them on an NCE dcc reader ) 

 - it might be that the 'more advanced' controllers are taking too long for the problematic TTS decoders to wait to respond??

On the programming track there is only one loco and all commands are sent to that loco, so this cannot be the problem.