Author Topic: Trouble speed matching with TCS ADL4 decoders in Atlas SD70s  (Read 841 times)

0 Members and 1 Guest are viewing this topic.

jagged ben

  • Crew
  • *
  • Posts: 3292
  • Respect: +516
Re: Trouble speed matching with TCS ADL4 decoders in Atlas SD70s
« Reply #15 on: April 15, 2025, 08:14:14 PM »
0
Actually looking back at Maletrain's original post he's seeing the same speed for a range of 28 CV values.  That's quite a bit worse than I remember but maybe it's just worse than I remember. 

Maletrain

  • Crew
  • *
  • Posts: 3658
  • Respect: +674
Re: Trouble speed matching with TCS ADL4 decoders in Atlas SD70s
« Reply #16 on: April 21, 2025, 06:47:57 PM »
0
OK, Easter company has left, so I can get back to this.  (The "train room" had become a temporary bedroom.)

I gave up on matching with CVs 2,5 and 6 and went to the 28 step table.  To get a speed table to match the Atlas loco to, I went back and programmed one of the TCS K1D4 decoders in the Kato units with 28 steps starting at a value of 0 and ending at 150, as a straight line.

And, that has identified another quirk. 

The speeds increase in a smooth (but slightly arched) curve up to a value of about 127, and then the lap times get clearly more erratic, and have a jump followed by a different slope of speed vs CV value.

My first thought was that back EMF was being turned off somewhere in the speed step increases.  (I had left it on and checked CV61 to be sure that it is on - CV61 is 49.)  So, I started poking around in TCS CV documentation, and found this  https://docs.tcsdcc.com/wiki/CV_10 .  It says that the cutout CV value can be adjusted from 1 to 127 with this CV, but a value of zero means that BEMF is always on.  CV10 in this loco is set to zero.  But, having tried 2 somewhat different sets of CV values for the 28 step table, the erratic nature and jump in speed seems to occur where a speed step value first reaches or exceeds 127. 

So, apparently, BEMF is turning off at speed step value 127, even though CV10 is set to zero.

I guess I can live with that, but I really would like to have a "standard" that doesn't have any quirks, so that I can just match other decoders with quirks to that, instead of trying to juggle quirks with everything.

I also found that lap times at the highest speed steps can change substantially with run time.  For example, with the top speed step value set to 150, I can get 10-lap average times that range from 15.82 to 16.26 seconds, and that slightly overlaps with the range I can get with the next lower speed step.

Still, that difference would be only about a 7" gap between uncoupled units for a full lap, so still probably good enough speed matching wise.  The individual lap times are only a bit more in any of the 10-lap runs.

I typically warm up locos for 15 minutes before trying to check speeds, but even short interruptions seem to change the results at these higher steps.

Because I am trying to set things up for least wear during extended run times during open house events, I will be be trying for speed tables that represent performance during long run times.  I am finding that I need to measure/set all 28 steps in a table in one session, and even keep the loco running laps while I am fiddling with the computer, etc., if I want consistent results from trial to trial.  Otherwise, I can get the next higher step given me an unchanged or even lower speed.  PITA!!!

It also seems a little weird that the speed seems to increase when BEMF is turned off.  Perhaps that is because the loco is running very fast with no cars for a load. 

I'll experiment a bit more before settling on a "standard 28 step speed curve".  I may see what happens at the 127 value with a small train attached.  Eventually, I may just set a curve that none of these locos match without adjusting individual CVs, so that it is at least a smooth curve for speed


peteski

  • Crew
  • *
  • Posts: 33671
  • Gender: Male
  • Honorary Resident Curmudgeon
  • Respect: +5763
    • Coming (not so) soon...
Re: Trouble speed matching with TCS ADL4 decoders in Atlas SD70s
« Reply #17 on: April 21, 2025, 11:14:41 PM »
0
I know that these aren't your models, but it demonstrates why I switched to ESU and ZIMO.
. . . 42 . . .

Maletrain

  • Crew
  • *
  • Posts: 3658
  • Respect: +674
Re: Trouble speed matching with TCS ADL4 decoders in Atlas SD70s
« Reply #18 on: April 22, 2025, 09:57:03 AM »
0
What are the group's thoughts about using BEMF in consists?  Remember, in my case here, the consists do not use CV19, so none of the parameter changes that are invoked when CV19 is non-zero apply to my question here.

I noticed that the previous layout coordinator set many of the loco CV10s to "1", which means that BEMF would apply only to the first speed step, or no speed step if the first one is set to a value of "2".  In the cases I have found, speed step 1 has been "0" or "1".

I have read various arguments that BEMF should be turned off for consists because it makes the locos fight each other more.  I can see how that might be true, but I am not convinced it is true. 

The layout where these consists will run has some steep grades, peaking at about 4% in one place, so trying to keep long trains running at reasonably consistent speeds and not stalling is important.

I will probably have to experiment on the layout itself, but am interested in reading others' experiences with BEMF in consists before diving into that.

peteski

  • Crew
  • *
  • Posts: 33671
  • Gender: Male
  • Honorary Resident Curmudgeon
  • Respect: +5763
    • Coming (not so) soon...
Re: Trouble speed matching with TCS ADL4 decoders in Atlas SD70s
« Reply #19 on: April 22, 2025, 10:58:58 AM »
0
BEMF in DCC consists? Seems like a prefect subject for a new, separate thread.  :)
. . . 42 . . .

Maletrain

  • Crew
  • *
  • Posts: 3658
  • Respect: +674
Re: Trouble speed matching with TCS ADL4 decoders in Atlas SD70s
« Reply #20 on: April 22, 2025, 01:52:11 PM »
+1
OK, I started a separate thread on that topic.

I will continue with this one as I find other issues.