Trouble speed matching with TCS ADL4 decoders in Atlas SD70s

[Maletrain]

I am trying to speed match at least 1 of 2 Atlas loco to a pair of Kato locos.  The Kato locos have K1D4 decoders, and I was able to match them with each other  pretty easily, although I was surprised that the same decoders in the same models were not already close enough.

But the Atlas decoders do not seem to be properly responding to changes in CV5 top speed. 

At best, I am betting getting big step changes in lap times between large ranges of no change.  For example in one decoder, CV5 = 140 to 167 gives the same lap times of 20.1 sec, but values 168 and above give 16.5 sec, and vales of 139 and below give values of 24.1 sec. 

In the other decoder, I am getting speeds that seem backwards: laps with CV5 = 100 only take 12 sec, but with CV5 = 169 to 180, they take 16 sec.   

Both decoders have CV15 = 0, so should not be locked. 

Trims are all set a 128. 

Have not tried resetting, yet. (Hoping for better advice.)

[peteski]

I think reset would be the fist thing I would try (it is not like you are resetting  a sound decoder losing dozen of CV setting.

As for mentioning decoder lock, why not just read back the CV5 value (in service mode) to see if the changes you are making are taking.
I don't have any experience with TCS speed matching. Maybe they need a "reboot" for the CV5 change to be taken into account?  It would make no  sense so it is doubtful, but who knows?

As for mismatched speed in identical Kato locos, that probably means there is extra mechanical friction in one of the mechanisms, or something going on with the motor.

[Maletrain]

I did read back the CVS and noted that the CVs I changed read back as changed to what I had input.  But, because it was not having the desired result on the actual speed, I also checked that the decoder lock was not active (CV15 = 0).  When one thing isn't working as expected, I tend to try to check everything, rather than just assume that other things are doing what I expect.

I also wondered if the decoder really only has 14 speed steps.  But, running it at various speed steps does show fine speed control.  For example, with CV5 =140, throttle setting of 63 = 38.5 sec/lap, 64 = 37.8 sec and 65 = 36.7 sec.  So, I do seem to be getting 128 speed steps (or actually 126 on my Power Cab), not just 14 or even 28. 

But, trying to adjust the top speed with CV5 seems to be giving me more like 29/256 change steps, looking like a range of ~ 9 change steps for the top speed.  I did verify that the lap speed does not change for multiple CVs between 140 and 167 in order to find that the top speed does change between CV5 = 139 and 140 and between 167 and 168.

This is all with the 3-step speed control.  I don't want to go to the speed table until I fix, or at least understand, why the 3-step table isn't working as I expect it should.  Having just successfully speed matched 2 TCS "version 89" decoders in Kato locos, I am not understanding what is so different with the "version 88" TCS decoders in the Atlas Locos.

I did put a support ticket in to TCS, but too late on Friday to expect a response before COB Monday.

[peteski]

Maybe version 88 has a bug in the firmware?  I had a TCS Z3 decoder with a buggy firmware where the speed step control behaved strangely.  I don't use TCS decoders anymore.

[Maletrain]

I am dealing with a batch of club locos that are a mixture of things donated to the club and things bought by club members who are now deceased.  So, plenty of possibilities for previous screwups with no documentation of what way done before.

Supposedly, a previous club member speed matched 7 locos on the layout, but I have not found even a pair that are reasonably matched, so far.  Maybe when I get into the 4 axle versions.  But the 6 axle versions are a real hodge podge.

I am just trying to get 2 sets of 3, for now.  If I can't change the top speed of the Atlas locos to match the Katos as the Katos are now set, I will match the Katos to one of the Atlas locos, instead. 

But, I do want to make sure the Atlas doesn't have any more quirks before I make that effort.

[peteski]

I'm sure you know of the Digital decoder's BEMF weirdness when it comes to advanced consisting. I'm just reminding you about it.

[Maletrain]

I appreciate the reminder, but I am doing this for a Digitrax layout, so it will be "UniVersal" consisting, with not "knowledge" by the decoders that they are in a consist because all of the consist info is in the command station, not the decoder CVs.

I am also being careful of differences in forward and backward speeds of each unit, because some of them will be run "backwards" when the consist is going "forward".

[peteski]

I appreciate the reminder, but I am doing this for a Digitrax layout, so it will be "UniVersal" consisting, with not "knowledge" by the decoders that they are in a consist because all of the consist info is in the command station, not the decoder CVs.

I see. But for my information, isn't Digitrax also capable of utilizing advanced consists?

[reinhardtjh]

I see. But for my information, isn't Digitrax also capable of utilizing advanced consists?

Yes. It can.  But I believe that you have to do everything with Advanced consisting yourself.  The Digitrax command stations don't have any internal routines to automatically program CV19 and any other CVs that would be needed.  What Digitrax calls "Universal Consisting" is their preferred method which creates the consists in the command station only.
https://www.digitrax.com/tsd/KB575/multiple-unit-or-consist-operations-overview/

[Maletrain]

I have never tried to make or break an advanced consist on a Digitrax system.  I just make them on my home NCE system and take them to a Digitrax system at my club. 

But, from the manuals, I understand that you can set up the Digitrax system to default to making "Advanced Consists" instead of "UniVersal Consists" as described here https://dccwiki.com/Multiple_Unit_Consisting/Digitrax_Advanced_Consisting .

As usual, there is little info about what the Digitrax command station actually does with the info that it has made an advanced consist.  It has to keep track of some info if it is going to be able to "break" the consist on demand.  In particular, it needs to know which loco addresses it needs to write zeros into their CV19s.

[peteski]

Interesting, one would have thought that the most popular DCC system in USA would be fully capable of advanced consisting (since that DCC feature is far from being new).  It is also interesting that the Digitrax decoders not only support CV19 but also provide separate BEMF setting for when the model is in advanced consist, yet the command station does not fully support that feature.

[jagged ben]

I've had similar issues with step changes on TCS decoders.  Maybe they are older versions but I just don't think their implementation is any good.  It's one reason I stopped buying TCS. 

[Maletrain]

I got a "reply" from TCS that completely failed to address the issue.  So, I am still experimenting.

Strangely, I can change the top speed by changing the 28 step speed table top speed - no other changes except CV29 going from 34 to 50 to use the table.

So, I guess the firmware code in the decoder that adjusts power to the motor is different for the 3-step and 28-step CVs.

So, the decoder is apparently useable for speed matching, but only with the 28 step table.

Odd thing is that this is TCS version 88, and TCS version 89, in the Kato version of the SDs, works fine with the 3 step table used for matching top speeds.

TCS owes me an explanation, so I will be doing more to pin down the malfunctioning aspects to ask a more direct question.

[peteski]

TCS owes me an explanation, so I will be doing more to pin down the malfunctioning aspects to ask a more direct question.

Good luck with that!

That explanation makes no sense (likely on purpose). Motor in any DCC decoder is powered with PWM pulses which result in the motor "seeing" a variable voltage DC.  Voltage in this instance is power. From zero to full power.

CV2, 5, and 6 or the 28-step table allow you to control the way the voltage (power) is applied to the motor in relation to the speed step instructions coming from your throttle.

The 3-step adjustment allows control of the starting voltage, mid-step voltage and the top speed.   Of CV5 is set to less than 255 then the top speed voltage will be trimmed down to less than full rectified voltage in the decoder (usually 12V).  The 28 speed table does the same thing in most decoders, but with more granular control of the motor voltage as it relates to the speed step command from the throttle. 

Since it is a 28-step curve, it is best matched with a DCC system set for 28 speed steps.  If you are operating your DCC system in 128 step model the math gets a bit fuzzy, especially if the decoder's firmware can only provide 28 discrete speed (voltage) steps  to the motor (I don't know if that is how TCS decoders are).  In either case, some math in the decoder's firmware will have to take place to arrive in a voltage range for the motor.  Especially when you make the starting voltage higher than zero and max voltage less than maximum.

I'm sure you already know all that, and from what you mentioned TCS' reply was, the terms they used don't seem to be fully explaining what's going on.  I also thought that functionality of CV2 and 5 was fully defined in the NMRA specs.  CV5 should control the motor's top speed.

That's why after moving to ESU and ZIMO decoders I have never looked back at the other domestic brands.  They are not perfect either, but they are years ahead of the domestic brands.

[jagged ben]

...
Since it is a 28-step curve, it is best matched with a DCC system set for 28 speed steps.  If you are operating your DCC system in 128 step model the math gets a bit fuzzy, especially if the decoder's firmware can only provide 28 discrete speed (voltage) steps  to the motor (I don't know if that is how TCS decoders are).  In either case, some math in the decoder's firmware will have to take place to arrive in a voltage range for the motor.  Especially when you make the starting voltage higher than zero and max voltage less than maximum.
...

The decoders I've had this issue with support 128 speed steps, and the throttle response is smooth.  What's not nearly so smooth is the response to CVs 5 and 6 (and maybe 2).   It's as if there are only around 28 or 32 possible max and mid voltage values, to which the 8-bit CV setting  gets 'rounded off'.  I actually wonder if the algorithm is simply ignoring the last 3 bits of the byte, because it seems to take a difference of about 8 in the CV value to change the speed.  Or maybe it's more like 9 or 10 because it has something to do with 256/28, I haven't studied it exhaustively but hopefully you get the idea.

For a locomotive that would go 256 scale mph at a CV5 setting of 256 (I'm making the math easy, but this is not unrealistic for a Kato) that means you may not be able to match the max speed closer than about 4mph to another loco, which is a noticeable difference.  I do think it's plenty sufficient for functional performance in a consist, but it certainly pales in comparison to other brands. 

Perhaps TCS has improved their firmware but I'm also one of those who has gravitated toward European decoders, I'm mostly doing ESU now, even when it means hardwiring instead of plug-and-play.