Speed matching Digitrax and Tsunami2?

[peteski]

What's with the (head)lights flashing rapidly thing?  Is that some sort of indication or some unintended effect of some problem (bug) with the decoder's firmware?

[Maletrain]

My interpretation of the rapid flashing was that it was some sort of dithering for low speed that produce no actual speed in the model. 

Because it happened at speed step 1-of-28 but not at step 1-of-128 for the same 28 step speed table settings, but also occurred at step 4-of-128 for the same speed table settings, I am guessing that it is an algorithm problem in the decoder firmware. 

It is very repeatable with the decoder I was programming.

[reinhardtjh]

If it was the Digitrax decoder that was flashing the headlight, then it's possible that it was in 14-step mode.  Older Digitrax decoders used to do that when they were in 14-step mode, but receiving 28 or 128 step speed commands.  I'm not sure if they still do that, I haven't used any of the more recent Digitrax Decoders.

[peteski]

My interpretation of the rapid flashing was that it was some sort of dithering for low speed that produce no actual speed in the model. 

Because it happened at speed step 1-of-28 but not at step 1-of-128 for the same 28 step speed table settings, but also occurred at step 4-of-128 for the same speed table settings, I am guessing that it is an algorithm problem in the decoder firmware. 

It is very repeatable with the decoder I was programming.

If there was dithering, it should be in the H-Bridge motor driver, not in the separate headlight circuit which uses the raw rectified (blue) positive voltage and common (ground) on the negative side.

The speed step mismatch headlight flashing John describe is not specifically rapid. The headlight will flash on and off during odd and even speed step values in the packets sent to the decoder. The flashing speed would be directly related to how fast you are turning the speed control knob. Also, that speed-step mismatch flashing affects all decoders, not just Digitrax. Techincal details are explained in https://sites.google.com/site/markgurries/dcc-welcome-page/advanced-topics/decoder-motor-drive/mixing-up-speed-step-modes

The whole thing sounds wonky (not your experiment, but the decoder's behavior). It does seem like a bug in TCS firmware. Just like the Z3 decoders speed control behavior bug which made me swear off using those decoders.

[Maletrain]

On the TCS decoders, there is dithering - it is the TCS substitute for "kick" and has a couple of CVs to vary rate and intensity.  But, I understand that it should not affect the headlight.  Then again, there seem to be a lot of things that "shouldn't" happen but do.

The latest weird happening was when I put a loco with a TCS decoder on the programming track of my PR4 connected to only a laptop running JMRI.  I have done that multiple times without this happening, but this time the loco took off towards the end of the programming track and I had to catch it.  After I manually  stopped it, it stopped spinning its wheels and could be read and written to normally.  I had taken that loco off the loop I run with a Power Cab, and am positive that it was at zero speed when I took it off the other powered track.  I did not think the PR4 put out enough current to run a loco, but it certainly did that time.

[peteski]

On the TCS decoders, there is dithering - it is the TCS substitute for "kick" and has a couple of CVs to vary rate and intensity.  But, I understand that it should not affect the headlight.  Then again, there seem to be a lot of things that "shouldn't" happen but do.

The latest weird happening was when I put a loco with a TCS decoder on the programming track of my PR4 connected to only a laptop running JMRI.  I have done that multiple times without this happening, but this time the loco took off towards the end of the programming track and I had to catch it.  After I manually  stopped it, it stopped spinning its wheels and could be read and written to normally.  I had taken that loco off the loop I run with a Power Cab, and am positive that it was at zero speed when I took it off the other powered track.  I did not think the PR4 put out enough current to run a loco, but it certainly did that time.

Not familiar with PR4 unit but as defined by NMRA, the service  mode programming track can supply enough current to run the motor. You can see it when the motor gets a power pulse used for command acknowledgements.  As defined, programming track can supply up to 250mA (which is still a fraction of standard DCC booster output.)

[Maletrain]

Yes, 250 mA should run any N scale loco I have.

But, why it was somehow running that loco for more than a blip, I still don't understand.

I am guessing that the 250 mA at full voltage is always available, so I am guessing that it was something to do with the decoder.  It was set to disable DC running, so I really don't understand how it would just take off like it did, then stop and not repeat.  When I grabbed it, I probably disrupted its connection to the track, but it did not take off again after I took my hand off it.

[peteski]

Yes, 250 mA should run any N scale loco I have.

But, why it was somehow running that loco for more than a blip, I still don't understand.

I am guessing that the 250 mA at full voltage is always available, so I am guessing that it was something to do with the decoder.  It was set to disable DC running, so I really don't understand how it would just take off like it did, then stop and not repeat.  When I grabbed it, I probably disrupted its connection to the track, but it did not take off again after I took my hand off it.

I can't explain that (especially since the DC running was disabled in that decoder), other than it was some glitch in the decoder.

Here is a good write-up about programming track specs by Stuart Baker from  NCE-DCC group.io
12/29/23   message #129325

I will chime in here on the topic of program track standards. The standards are pretty simple. The NMRA S-9.2.3 ( https://www.nmra.org/sites/default/files/standards/sandrp/DCC/S/S-9.2.3_2012_07.pdf ) states:
For the purposes of this STANDARD, limited energy is defined as 250 mA, sustained for more than 100 ms.

RailCommunity RCN-216 ( https://normen.railcommunity.de/RCN-216.pdf ) provides further guidance. They in fact have a very nice illustration within the document.

    Current limited at 250 mA.
    Limit for short-circuit detection at 100 mA from 100 ms after turning on program track.
    The decoder recognizes the reset packets and switches off all current consumers. The program track is current limited to 250 mA during this time period.
    A few smaller capacitors are still be charged, which cannot be switched off.
    After 100 ms, the current must have fallen below 100 mA.
    After 150 ms, the current consumption must have stabilized.
    After 190 ms, the sending of 25 reset packets, plus initial 3 reset packets, is terminated as part of the command sequence. Now commands for reading and writing configuration variables can be sent.
    The decoder responds to a command with a current pulse. The current can be below the 100mA limit or above it. It is limited to 250 mA by the current limitation of the program track.

A properly implemented program track should transition into current sourcing mode whenever the 250 mA limit is reached. I have done a tear down of the PowerCab, and it does not have a proper 250 mA current source circuit, and therefore would not technically be in compliance of either the NMRA or RailCommunity standards, IMHO. I'm have not done a tear down of the PowerHouse Pro, or its successor, so I cannot speak to either system.

Keep in mind that there are decoders in the market, mostly older products, that cannot be programmed successfully by an NMRA standards compliant program track. In this case, the decoder is not compliant with the standards. However, many systems in the market go above the NMRA limits in order to achieve greater compatibility with these older non-compliant decoders. So the PowerCab not implementing the proper NMRA limits does have that advantage. The disadvantage is that the program track is less "safe" in that it is more likely to damage a decoder that is improperly installed before the problem can be corrected.

In the interest of disclosure, I contributed to the hardware and software design of the TCS CS-105 and LT-50 command stations. The programming track circuit and accompanying software is designed to be fully compliant to both the NMRA and RailCommunity standards, the RailCommunity standard being the more strict of the two. This means it does implement a proper 250 mA current source in "limit" mode, and the software monitors in detail the current profile of the entire program track sequence. The TCS system has a configuration option to bypass the 250 mA current limit for the purpose of programming older non-compliant decoders. In the bypass mode, the CS-105 will source peak currents up to 1A and sustained currents up to ~500 mA. The bypass mode is still energy limited, but it is inherently less safe than the standards compliant 250 mA mode. The extra circuitry does contribute non-trivial cost to the bill of materials for both systems. If you are wondering why these systems are not price leaders in the market, yes you do get more by paying [a little] more, at least in this case.

Thanks,
Stuart