Author Topic: Question regarding Speed Matching and BEMF  (Read 506 times)

0 Members and 1 Guest are viewing this topic.

kiwi_bnsf

  • Crew
  • *
  • Posts: 238
  • Respect: +240
Re: Question regarding Speed Matching and BEMF
« Reply #15 on: January 05, 2025, 08:07:10 PM »
0
Okay, so by sharing my values out of DecoderPro, I think I have ended up confusing things when I attempted to explain these both in terms of the DecoderPro names, and CVs.

Here are three annotated screenshots of the DecoderPro settings for my reference Kato SD40-2 Mid Production roster entry:







Decoder Pro can display the CVs via tool tips (i.e. when you hover your mouse over a value). You enable this feature in Settings > Roster > Programmer > Show CV numbers in tool tips

The above reference loco has a perfectly linear speed response from 0 to 60 mph as measured by an Accutrak II speedometer. I prefer to use all 28 steps in the speed table to give the maximum throttle resolution. This allows a finer degree of throttle control than is possible if you configure the max speed at speed table Step 14 of 28. I just remember that 100% throttle is 60mph, 50% throttle is 30mph, 25% throttle is 15mph etc.



The more complex part to this question is how actually do these two CV's impact your speed settings.  I have tried to look this up on Digitrax and by looking at You Tube Videos on Speed Matching and no one has explained it.   I was of the understanding that I used these if for example, I had two loco's consisted (I use simple consisting, both loco's with same decoder number) and they ran smoothly in one direction but were not speed matched in the other direction.  I could then use the Forward or Reverse Trim to adjust the direction that was out of Match to bring them closer.  Haven't used it a lot, so I have little experience to draw on, but that was my understanding.

Correct! Forward and Reverse Trim [CV66 and CV95] are used when a loco runs faster forward relative to reverse. The trim allows you to balance this out so that a loco will always run at the desired speed regardless of which direction it is running. Generally you should only need to make very small adjustments to this value (maybe 128 ± 2-4). Also, I would not be too concerned if the directional speed difference is only measurable at max speed. You really only need to trim out differences that are measurable in the first half of the speed response table — as this is where it will cause the most issues in consists. If you do adjust trim, then you will also need to re-adjust your entire speed table, as it changes some of the interpolation maths in the decoder.


Next question Tim is with respect to CV65 Kick Start.  Assuming that I have a loco which starts to creep at Speed Step 1, what does Kick Start, CV65, contribute to the running of the loco.  My understanding of Kick Start, and I am showing my lack of knowledge of electronics here, so forgive me if I get terminology wrong, is that it give a jolt of current to the motor to get it spinning and moving.  If I am already crawling at Speed Step 1, why is that necessary?  I would say that a number of my Kato SD40's have Step 1 in the Speed Table set at 40 or 50 to get them to crawl.  I notice that all of your Step 1 settings are in single digits, does the use of CV65 allow you to reduce the number needed to get the crawl at Speed Step 1.

Correct. CV65 Kick Start configures only a momentary spike in voltage to overcome initial cogging/friction in the drive train. I find that Kato locos need very little kick start, whereas older Atlas locos need a lot more. However, with BEMF enabled, I always end up using at least some kick start – because if you really want to optimise the BEMF settings for slow speed, a little bit of kick start will allow a lower value for speed step 1 in the speed table. You can see this effect where by testing progressively lower values for speed step 1 [CV67] that can only be maintained when you reduce the throttle from 25% down to speed step 1 (but cannot be maintained from a standing start — leading to a lurch at speed step 2 or 3). The kick start allows a slower speed to be achieved from a standing start.


You are showing CV57 as Advanced Droop Compensation.  Is this another term for BEMF?  Am I correct in my assumption that setting CV57 to 0 in fact turns BEMF off?

Correct. Setting CV57 to 0 will disable BEMF.
Unfortunately I caused confusion with my initial post (now corrected) because CV57 is split between the "Motor" and "Digitrax" tabs in Decoder Pro — see screenshots above. To disable it completely in Decoder Pro you will need to set it to zero in both tabs.

@peteski I rarely ever interact with raw CVs, but I have just checked and CV57 has a value of 119 for the above roster entry (I simply let DecoderPro manage the complexity of combining the values for CV57 — in fact I didn't even know it was combined until today).


Lastly Tim, you mentioned setting for older Atlas locomotives.   I was going to send you a PM and my email address, which I can still do if you wish, but thought it would be better if you could just post those settings so that others who might be interested also get a chance to see them and possibly use them as a template.  I have had issues with speed matching with the older Lenz decoders that came with many of the early 2000 Atlas.  The combination of their slow speed motors and Lenz decoders, I can barely get them to run at around 25 to 30 scale MPH.  I use a bunch on some coal drags, otherwise its Kato all the way.  I have done factory resets and fiddled around with them a bunch with little progress.  I would be interested to see your settings.

Please feel free to shoot me a PM with your email. I'd be happy to share some DecoderPro roster entries.

I was never able to get adequate performance from the factory Lenz decoders in Atlas locos. I ended up replacing these with Digitrax DN163 series decoders. With BEMF and a custom speed table I was able to match these to Kato (and this is using the later Scale Speed motors). Here's a profile from an Atlas Dash 8 with a DN163A0 — note the highly non linear speed table that is required to achieve a linear speed response:



(Also note that this loco has a trim applied due to it running faster in reverse)



More recently, I've ended up swapping the chassis on all my Atlas locos to the new ESU sound equipped versions, but it is absolutely possible to speed match older Atlas and Kato locos.

Hope this helps!
« Last Edit: January 06, 2025, 12:34:48 AM by kiwi_bnsf »
--
Tim Benson

Modelling Tehachapi East Slope in N scale circa 1999

shark_jj

  • Crew
  • *
  • Posts: 303
  • Respect: +697
Re: Question regarding Speed Matching and BEMF
« Reply #16 on: January 05, 2025, 08:36:28 PM »
0
Thanks Tim, this was helpful, I have a better understanding and feel relieved I wasn't too far out in left field with some of my understandings.
John

peteski

  • Crew
  • *
  • Posts: 33201
  • Gender: Male
  • Honorary Resident Curmudgeon
  • Respect: +5460
    • Coming (not so) soon...
Re: Question regarding Speed Matching and BEMF
« Reply #17 on: January 05, 2025, 10:38:58 PM »
0
@peteski I rarely ever interact with raw CVs, but I have just checked and CV57 has a value of 119 for the above roster entry (I simply let DecoderPro manage the complexity of combining the values for CV57 — in fact I didn't even know it was combined until today).

Yes, Tools like Decoder Pro or LokProgrammer make it easy for user to configure the decoder, but those tools can also obfuscate what goes on "behind the scenes".  Yet, literature or KB articles (like the KBfrom Digitrax I quoted earlier) uses (and explains) the "raw" CVs and how they work.   Now that you explained where your information came from, it makes sense.

While I like the ease of using those programming tools, I also like to understand what goes on "behind the scenes".   This is a perfect example where you just looked at one section of Decoder Pro and thought the CV57 value was one thing where in fact, it was a different value.  There aren't many split CVs, but they do exist.
. . . 42 . . .

kiwi_bnsf

  • Crew
  • *
  • Posts: 238
  • Respect: +240
Re: Question regarding Speed Matching and BEMF
« Reply #18 on: January 05, 2025, 11:05:00 PM »
0
With the complexity of modern decoders, and the number of CVs involved, I'm content to let DecoderPro and my LokProgrammer software do all the heavy lifting.

Aside from changing a custom Loksound SoundCV that I've defined myself to designate consist state, and with exception of this thread, I can't remember the last time I read, wrote, or interpreted a CV.

I'm happy to live in a world where I don't have to know the value of CVs or how to calculate them — my available hobby time is way too short to be worrying about such low level interaction. I just need to know what the software is capable of, and what functionality is possible. Worst case, Decoder Pro and the LokProgrammer roster files have the values all documented.

I often wonder how many people are put off DCC and some of its more advanced concepts like speed matching and consisting due to the fact that the steps historically involve manipulating CVs manually (or interpreting documentation that references CVs and hex values). Without higher level tools like DecoderPro, I definitely wouldn't have ever discovered and experimented so much.
« Last Edit: January 05, 2025, 11:19:10 PM by kiwi_bnsf »
--
Tim Benson

Modelling Tehachapi East Slope in N scale circa 1999

peteski

  • Crew
  • *
  • Posts: 33201
  • Gender: Male
  • Honorary Resident Curmudgeon
  • Respect: +5460
    • Coming (not so) soon...
Re: Question regarding Speed Matching and BEMF
« Reply #19 on: January 05, 2025, 11:33:27 PM »
0
You have point Tim.
I just happen to be one of those people who when they buy a new gadget, take it apart to see how it works (sometimes even before even trying it first). :facepalm: It is a sickness, but it also educates me.  :) That's how I have reverse engineered all those ESU decoders and presented the info on TRW. I like to see what makes things "tick". I also know that I'm one of only few like that.  However in this case it made me catch a mistake or incomplete information.
. . . 42 . . .