How does a DCC decoder calculate acceleration/deceleration?

[MarshLane]

A question for the technically minded among us.  On a DCC chip there is inertia - Zimo chips with a @pauliebanger Paul Chetter sound project on them for example generally have inertia that represents a trailing load or a light engine.  My question is how is this data stored or calculated in the chip, regardless of the manufacuter? I am assuming there must be some formula for acceleration or deceleration (coasting to a stand) and while not perfect, it does provide more far realism than the sudden stops and stars.  But there cannot be that much space for data storage in relation to speed, time, velocity changes etc..

 

Can anyone enlighten me?

Rich

Edited October 22, 2023 by MarshLane

[jamesed]

CV3 and CV4 settings are different for different manufacturers.  Zimo, for example use 1-255 whilst in a Lokommander it's 1-62 for some reason. In a Zimo chip, each decimal unit corresponds to about 0.9 of a second.  In other words, a setting of cv3=10 means it will take 9 seconds to accelerate from stop to maximum speed. 

 

Unlike CVs 2, 5 & 6 which are specified by the NMRA there is no standardisation for CVs 3 & 4. 

 

If 'active braking' is set up in a Zimo decoder then CV4 values are ignored when the brake function button is applied (usually F2 but can be set to any function number) with the value in CV349 taking precedence.

 

Sound projects will usually apply their own defaults to these CVs but you may be able to adjust them within certain limits. Then you've got 'shunting mode' with a whole different set of parameters - typically reducing cv3 and 4 values by 75%. 

 

I'm not sure if that answes your question. 

[55020]

42 minutes ago, jamesed said:

CV3 and CV4 settings are different for different manufacturers.  Zimo, for example use 1-255 whilst in a Lokommander it's 1-62 for some reason. In a Zimo chip, each decimal unit corresponds to about 0.9 of a second.  In other words, a setting of cv3=10 means it will take 9 seconds to accelerate from stop to maximum speed. 

 

The exact same info applies to the LokSound/LokPilot 5 DCC decoders.  However the "multi-function" LokSound/LokPilot 5 decoders use a multiplier of 0.25 (and I have no idea why!).

 

The ESU decoders also allow for heavy and light loads, effectively adjusting the effects of intertia as mentioned in the first post.

 

 

Steve

[RAF96]

It should be like this . . .

The acceleration and deceleration rate change per increment in CV value is determined according to a formula issued by the NMRA. Please check the NMRA web site for a full description.

[MarshLane]

Hi @jamesed

Thanks, not quite.  I get that the decoders allow programming of the CV values to increase or decrease the rate of acceleration and deceleration .. but I am thinking more of the software on the chip ... what does it do with that number (and how) to give the inertia control.  It must use a maths equation or amend a predefined acceleration or deceleration curve which it reads to then direct the motor outputs.  

 

Rich

[jamesed]

10 hours ago, MarshLane said:

Hi @jamesed

 I am thinking more of the software on the chip ... what does it do with that number (and how) to give the inertia control.  It must use a maths equation or amend a predefined acceleration or deceleration curve which it reads to then direct the motor outputs.  

 

Rich

 

Can't help there sorry - way above my pay grade! 

 

 

 

[Suzie]

The formulas are different for different manufacturers. Typically the decoder will have a regular polling time where it will add or subtract a an amount from the current speed until it reaches the target speed each time it polls. There are better ways to do it so some might adjust the amount added to create a smoother transition to the target speed.

 

Storage on a decoder is not a big issue nowadays, and there is plenty of processing power to do what is quite a simple task in the scheme of things.

 

Have a look at the source code for some of the DIY decoders that you can make such as the MERG or DIY Decoder Project to see how it is done.

[Nigelcliffe]

1 hour ago, Suzie said:

The formulas are different for different manufacturers. Typically the decoder will have a regular polling time where it will add or subtract a an amount from the current speed until it reaches the target speed each time it polls. There are better ways to do it so some might adjust the amount added to create a smoother transition to the target speed.

 

Storage on a decoder is not a big issue nowadays, and there is plenty of processing power to do what is quite a simple task in the scheme of things.

 

Have a look at the source code for some of the DIY decoders that you can make such as the MERG or DIY Decoder Project to see how it is done.

 

And remember that both of those DIY designs are using code which is over 20 years old, and even then were not "state of art".    So things in the better commercial decoders are considerably more complex and advanced, using vastly more powerful microprocessors.  

[Crosland]

19 hours ago, jamesed said:

Unlike CVs 2, 5 & 6 which are specified by the NMRA there is no standardisation for CVs 3 & 4. 

 

Actually there is a recommended standard in NMRA standard S-9.2.2 https://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.2.2_decoder_cvs_2012.07.pdf I believe (from posts by someone who was on the standards committee) that this was based on one manufacturers practice at the time, but the details are lost.

 

The problems are that (a) it was standardised after decoders were already available with whatever the manufacturer did and, (b), manufacturers continue to ignore the DCC standards in all sorts of ways.

 

[MarshLane]

7 hours ago, Suzie said:

The formulas are different for different manufacturers. Typically the decoder will have a regular polling time where it will add or subtract a an amount from the current speed until it reaches the target speed each time it polls. There are better ways to do it so some might adjust the amount added to create a smoother transition to the target speed.

 

Storage on a decoder is not a big issue nowadays, and there is plenty of processing power to do what is quite a simple task in the scheme of things.

 

Have a look at the source code for some of the DIY decoders that you can make such as the MERG or DIY Decoder Project to see how it is done.

 

Thanks for that Susie, useful - I didn't think about looking at the MERG decoder, and really should have done - especially as I am a member!

 

5 hours ago, Nigelcliffe said:

And remember that both of those DIY designs are using code which is over 20 years old, and even then were not "state of art".    So things in the better commercial decoders are considerably more complex and advanced, using vastly more powerful microprocessors.  

 

Thanks Nigel, interesting thought.

 

I am playing about with a version of a decoder idea, but in the style of a DC controller, using a modernised cab-control system.  I dont want to go down the DCC road for a variety of reasons.  It's also partly a 'can I actually achieve it' project.  I have been playing with it for a couple of years now on and off, the hardware side I think is sorted, based on a PIC18F chip.  But I want the controller (when in an auto mode) to accelerate a 1,100 ton coal train far slower than a two-car Class 108!  So I came up with the idea of establishing acceleration/deceleration graphs (although the more I thought about it, the more complex it became as the graph is obvious different for each speed, trailing load etc.) but it issues with how such data could be stored and easily referenced.  That led me to wonder how the DCC decoders do it (although I acknowledge its a far simpler approach with just light engine or load options).

 

I know there are various people in MERG working on similar options, but they are slightly different to how I envisage this system working, and as I say, I wanted to prove to myself I could actually achieve it.

 

Id welcome any thoughts if anyone has them.  

 

Rich

[jamesed]

2 hours ago, Crosland said:

 

Actually there is a recommended standard in NMRA standard S-9.2.2 https://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.2.2_decoder_cvs_2012.07.pdf I believe (from posts by someone who was on the standards committee) that this was based on one manufacturers practice at the time, but the details are lost.

 

The problems are that (a) it was standardised after decoders were already available with whatever the manufacturer did and, (b), manufacturers continue to ignore the DCC standards in all sorts of ways.

 

 

The key word there is "recommended" and there is no obligation to follow it. Just like function mapping. Most people are familiar with the NMRA recommended function mapping but if you've got, for example, a Lenz decoder it's default mapping is different.  The only mandatory CVs in the NMRA standard are for cv1 cv7 cv8 and cv29.  Then there is cv2 cv5 cv6 and cv11 which are all "strongly recommended". Everything else is just "optional".  The best advice is to always read the manual for every type of decoder you have.

Edited October 23, 2023 by jamesed

[RAF96]

22 hours ago, RAF96 said:

It should be like this . . .

The acceleration and deceleration rate change per increment in CV value is determined according to a formula issued by the NMRA. Please check the NMRA web site for a full description.

Extract from the NMRA document linked to above.

 

[MarshLane]

@RAF96 Thanks for highlighting that.  I have downloaded the NMRA document but haven't yet had chance to go through it.  Much appreciated.

 

I wonder in some respects if I am doing my usual thing and trying to make it too complicated.  The DCC acceleration works reasonably well, although not perfect, but if it is simply working on a value multiplied by 0.896, divided by the speed steps, that is a simple approach. I was approaching it from the point of view that acceleration is not a constant, and getting a train moving (such as a 36 wagon MGR or long rake of loaded TEA tanks) would take longer, than actually increasing the speed once the train is moving, and taking into account that getting to one speed (for example) 35mph would be achieved quicker than the next step from 35mph-50mph (again for example).

 

Rich

[melmerby]

10 hours ago, Crosland said:

 

Actually there is a recommended standard in NMRA standard S-9.2.2 https://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.2.2_decoder_cvs_2012.07.pdf I believe (from posts by someone who was on the standards committee) that this was based on one manufacturers practice at the time, but the details are lost.

 

The problems are that (a) it was standardised after decoders were already available with whatever the manufacturer did and, (b), manufacturers continue to ignore the DCC standards in all sorts of ways.

 

Possibly it was Lenz as The NMRA standards themselves were based on Lenz's DCC system.

[Nigelcliffe]

8 hours ago, MarshLane said:

@RAF96 Thanks for highlighting that.  I have downloaded the NMRA document but haven't yet had chance to go through it.  Much appreciated.

 

I wonder in some respects if I am doing my usual thing and trying to make it too complicated.  The DCC acceleration works reasonably well, although not perfect, but if it is simply working on a value multiplied by 0.896, divided by the speed steps, that is a simple approach. I was approaching it from the point of view that acceleration is not a constant, and getting a train moving (such as a 36 wagon MGR or long rake of loaded TEA tanks) would take longer, than actually increasing the speed once the train is moving, and taking into account that getting to one speed (for example) 35mph would be achieved quicker than the next step from 35mph-50mph (again for example).

 

Rich

 

You're now describing what some decoder makers offer - a variable rate of acceleration.    But they're adding to their algorithm which already does the basics.   

 

 

[RAF96]

11 hours ago, MarshLane said:

@RAF96 Thanks for highlighting that.  I have downloaded the NMRA document but haven't yet had chance to go through it.  Much appreciated.

 

I wonder in some respects if I am doing my usual thing and trying to make it too complicated.  The DCC acceleration works reasonably well, although not perfect, but if it is simply working on a value multiplied by 0.896, divided by the speed steps, that is a simple approach. I was approaching it from the point of view that acceleration is not a constant, and getting a train moving (such as a 36 wagon MGR or long rake of loaded TEA tanks) would take longer, than actually increasing the speed once the train is moving, and taking into account that getting to one speed (for example) 35mph would be achieved quicker than the next step from 35mph-50mph (again for example).

 

Rich

The algorithm applies to speed steps, thus dependant upon your speed curve, which may be linear or custom in any profile, will be your actual change rate.

[55020]

15 hours ago, MarshLane said:

I was approaching it from the point of view that acceleration is not a constant, and getting a train moving (such as a 36 wagon MGR or long rake of loaded TEA tanks) would take longer, than actually increasing the speed once the train is moving,

 

That's why I use an "exponential" speed curve with my ESU decoders.  Using LokProgrammer I am able to set this up with one simple click (preset).  This doesn't effect the acceleration and deceleration rates previously discussed, which simply dictates the number of seconds taken to get from 0 to max speed and max speed to zero.

 

[RAF96]

If you change that speed curve as shown below you alter the time it takes to get to an applied speed . Red line the loco is good for fine low speed control then races away to a given top speed to return to shed. Blue line gets you up to line speed quicker, but in each case the rate of change between speed steps is per the formula.  CV3rate x .896 / speed steps in use.
 

[MarshLane]

Yes you see I have always thought a proper acceleration curve is similar to that attached (very poor representation on my part) ... it takes sheer power and tractive effort to get a weight moving, but once it is acceleration to a set speed is reasonably constant (assuming a level route, no signalling etc..) but to get from that specific speed to operating speed, line speed or max speed takes a lot more time.

 

 

I did a cab ride once on an HST and the driver was saying, once you get the train moving, getting to 80-90mph is relatively quick and easy.  But the stretch from 90 to 125mph takes a lot longer.

 

But it is this kind of curve that I was originally looking to replicate.  I think on hindsight I think working on a mathematical equation that can create a realistic acceleration, and be varied depending on the load is going to be the better option.  I probably need to dig out my old Graphical Calculator from uni days!!

 

Rich

 

[34theletterbetweenB&D]

Generally, the power demand for acceleration increases in direct proportion to the square of the speed (on the level, i.e. no other assistance).

 

From stationary a train on the level requires minimal power to start, which is a good job because the power available can easily result in wheel slip. There's a concave curve from stationary to dead slow as the train gets into motion and then an inflexion to a convex curve which progressively flattens and (if the line speed limit allows) terminates at the ' balancing speed' where the power available is fully absorbed overcoming drag.

 

That's the speed curve that delivers maximum realism in conjunction with the CV3 and 4 time constant. Problem is that most modellers don't like waiting for five minutes for the train to graft up to full speed, or then waiting for five minutes before the thing comes to rest. Looks good though.