Zimo MS490 - Braking too sharp on light engine (F5)

[Ruston]

I have a Hornby Peckett, fitted with a Zimo MS490 with the Digitrains Peckett sound project. When running normally (as if with a train) the braking on F2 works as normal, i.e. the steam brake sound plays and the brakes squeal at the last moment before it comes to a gentle halt. When running light engine (F5 selected), however, it stops abruptly, the steam brake sound barely has time to play and the brake squeal does no play at all. I know that this is not right as I have several of the same model with the same sound project and even though the braking distance is meant to be shorter on light engine, it isn't this short and the full braking sounds do play.

 

The decoder is a replacement for a faulty one that was sent back and until that went pop, the loco ran perfectly on it, so I am wondering if the CVs have been messed with.

I have checked Cv4, which is set at 100, the same as others but I believe that is ordinary deceleration, not braking, or am I wrong?

Is there a different CV that comes into play for light engine deceleration and if so, what is it?

Is there a different CV that comes into play for braking and if so, what is it?

 

Thanks

[Ray H]

Take a look at CV349. That's the CV used with the active brake facility.

 

Is function 2 (or whatever key has been nominated for the active brake) selected when you run light loco?

 

CV309 will tell you which key has been assigned for the active brake.

 

The above CV numbers were those with the MX range of decoders. I don't know if they've changed with the MS range.

[RedgateModels]

One for @pauliebanger methinks. Ray might have hit the nail on the head with the MX/MS possible issue?

[Ray H]

21 minutes ago, RedgateModels said:

One for @pauliebanger methinks. Ray might have hit the nail on the head with the MX/MS possible issue?

 

Just checked the new MS manual, the use of the two CVs mentioned above hasn't changed. I don't know if there is a separate CV related to braking aligned to the light engine function.

[Ruston]

Thanks for the replies. I have called Digitrains and have the answer.

 

Other people have reported the same problem and the conclusion is that the latest firmware is the cause. I have been advised to try altering CV390 to value 20 and CV349 to value 10, which should make stopping distances longer. If that doesn't work it needs the older version of the firmware installing.

[Nigelcliffe]

CV390 is the momentum multiplier when running light engine.     

 

The whole thing is not the tidiest of things to setup.  

Standard CV3/CV4 momentum, then CV349 for brake key value.  Then CV390 as a multiplier over those values when running light engine.    I'd look at higher values for CV390 than 20 (which is 8% of the normal momentum).   

 

- Nigel

 

[pauliebanger]

ZIMO Brake Key feature:

 

There is no problem that I am aware of with the latest MS firmware regarding the Brake Key feature - works fine on my models.

CV390 = 20 is just wrong. This will produce a very strong change in Light Engine mode (see below) automatically creating a very sharp braking effect in this mode. Value of 100 or more is required.

 

CV309 sets the Function key for the manual brake. (typically F key 2, but could be any)

CV349 sets the 'efficiency' of the brake. Low numbers give harder braking.

There is no need (and no separate way) to set different braking force for Light Engine as this is one of the functions of this mode. You can, however, adjust the global effect of this mode.

CV390 sets a 'factor' of CV3 and CV4 when 'Solo' or 'Light Engine' mode is engaged, automatically changing the inertia/momentum simulation to match this mode. Low values temporarily reduce CV3 and CV4 significantly, high values give a less dramatically different effect. Since the braking force (CV349) is a factor of the current CV4, if Light Engine mode is engaged, CV4 will be reduced and a similar factor of a reduced figure will consequently be lower too.

For after market purposes, the value in CV390 is usually set to a reasonable starting point, useful in a range of models in which this project might be fitted. Models have different characteristics from each other, and individual users will have their own special requirements. eg. on small point to point layouts, with slow running, a high value in CV390 may be better whilst on a high speed a med to low value may give a more realistic effect.

 

A good starting point for this will be CV390 = 100

 

In the case of projects for R-T-R sound fitted models, the values in each of the above CVs will be decided by the manufacturer. But of course, these can still be customised as above to suit individuals' and layouts' needs.

 

The way you operate this feature has a big impact on the results. So the following gives explanations and advice which some may find helpful.

 

The braking simulation on these decoders is quite sophisticated, with several physical criteria modelled into the algorithm to simulate a closely as possible real llife characteristics. It's not a simple switch between CV4 values (As the designer of this feature, I can vouch).

How realistic the braking simulation appears can also be heavily influenced by the way in which the Brake Key is operated. This is greatly assisted if the chosen operating key is set at 'momentary'.  (available on most if not all DCC controllers at F key 2*, hence why I decided on this key as my default).

 

The same considerations apply in either Heavy or Light Engine mode.

 

The most important thing to remember is that the 'braking force' (CV349) is increased progressively over time.

 

The feature only has an effect after the requested Speed Steps have been reduced. This can be to any slower speed (say for a speed restricted zone) or to zero.

 

When the Brake Key is engaged, there is a short period, a few milliseconds, where there is no effect at all. This is to simulate the lag between the driver applying the brake and the brake mechanism starting to 'bite'. You can see, therefore, that a very quick 'dab' on the Brake Key will only produce a short brake application sound. (also possible if Brake Key is applied without reducing throttle beforehand).

 

If the Brake Key is continously engaged (or latched, see later) the apparent brake force is applied exponentially. Retardation begins slowly but quickly increases in intensity so that eventually the road speed matches the requested speed steps (throttle position).

In real life this would normally only be used for Emergency Braking.

 

More typical use in fully manually controlled braking will be to throttle down and use a blend of gradual deceleration (coasting) and speed trimming using the brakes in short or longer applications to achieve the desired road speed. If the Brake Key is engaged for similar variable durations, the brake effect only happens during application time. Each release will reset the brake application sound and the brake force value is returned to it's starting position. (and coasting will continue as assigned but at the new speed).

 

In simple terms, 3 dabs each of 0.5 seconds duration will not slow the model's road speed by the same amount as 1 application of 1.5 seconds. This allows the user full control to vary the simulation to suit different conditions.

 

*Special note for PowerCab users. On these handsets, the F2 key is always 'latched', so if you use the button labelled '2' for braking, you will have to press once to engage and again to disengage. This is not optimal, given what I have explained above. However, the button labelled Whistle/Horn operates whatever is assigned to F2 but in this case it is operated as a 'momentary' key. If you are not already doing so, my strong recommendation would be to use only the 'Whistle/Horn' button for manual brake applications.

 

Best regards,

 

Paul

Edited December 5, 2022 by pauliebanger

[Ruston]

2 hours ago, pauliebanger said:

There is no problem that I am aware of with the latest MS firmware regarding the Brake Key feature - works fine on my models.

CV390 = 20 is just wrong. This will produce a very strong change in Light Engine mode (see below) automatically creating a very sharp braking effect in this mode. Value of 100 or more is required.

Hi Paul. I am only going by what I was told, this morning. I set the values to those advised to me but it made no discernable difference to braking in F5, or without it. As I said, it braked perfectly well without F5 anyway.

 

I have just put the very first Hornby Peckett that I fitted with sound on the Program Track. It has an MX648 with the same Peckett sound project as the one that is giving trouble. I have never messed with either CV 349 or CV390 on this loco. It works perfectly in every way. The value for CV349 is 6 and the value for CV390 is 40. I assume these are the standard values that you built into the project when you designed it?

 

I put these exact same values into the problem loco and the problem persists.

 

As per your advice, above, I have just changed CV390 to 100 and CV349 to 20. The abrupt stop with F5 has ceased, and it now stops at the rate that it should. BUT... Without F5, although it still slows and stops as it ought to, the final brake squeal is now like an echo, playing 3 times instead of just once.

 

What I don't understand at all is why, if these effects are caused by CV changes, the CVs have been changed at all. The decoder came straight from Digitrains. I fitted it and ran the loco without making any CV changes myself. The only thing that I did change was the loco's address. And why do the exact same values when put into a decoder that carries the same sound project, and is fitted into the exact same model, not have the same effect?

 

[pauliebanger]

Dave,

 

The default settings for those CVs are what Digitrains and I decided was appropriate for the Hornby Peckett model, and from your posts, have not been altered. Individual users can choose to change them to suit- that's the advantage of highly configurable decoders like ESU and ZIMO. The downside is that they can seem complicated, unfathomable even, for some.

 

The same project on the same decoder in the same model with the same operator should produce similar results, within a small margin. This gives at least 4 possible areas where dissimilarities can arise, and you can add one more when layout type is added. Given your displayed skills at customising, re-engineering and re-motoring models are you sure you are comparing like with like?

 

Regarding repeating brake squeal. This is a consequence of changing the sound project's parameters. Here's a brief explanation.

 

The brake squeal sound sample is of a finite length.

The decoder is internally programmed to play the Brake Squeal during the final portion of F2 brake application.

If the duration of brake application exceeds that of the brake squeal sample, the decoder will play the sample again.

 

During sound project creation, these are balanced to produce the correct single play event.

If parameters are changed, this balance may be upset

 

CV349 = 20 which you have used will give a braking duration far longer than the CV349 = 6 which is the project default, thus requiring three times the sample length to cover the braking duration.

 

 

There are several changes you can make via CVs to bring this back into balance so that the brake squeal plays only once. I suggest that you make small changes at a time to one or all of them until you are satisfied with the results.

 

My suggested order is as follows:

 

1, Lower the threshold at which the Brake Squeal sound begins. This will shorten the 'play' duration to more closely match the length of the sound. CV 387 = 40 is the default, try 20 or even 10.  (It is possible to reduce this too far which results in the Brake Squeal being reduced so much that it becomes almost inaudible, so use some discretion)

 

2. If this does not prevent the repeats, increase the brake efficiency a little at a time. CV349 = 6 is project default. Lower numbers give shorter stopping distances, higher values give longer. Small changes can make a large difference. I find that values between 5 and 10 are most useful, a value of 20 suggests you have a leak in your brake pipes! Lol. (just my view).

 

3. Reduce the 'normal' value in CV4. The default is 100, try something around 80 (the smaller the number, the quicker the stop). This has implications beyond Brake Squeal duration so use with caution.

 

If you get lost, CV8 = 8 will reset to defaults so you can start again.

 

 

 

Are you using Shunt Mode when these problems occur? The way this operates has changed on MS decoders and may have an undocumented impact here. Try the above, first, and let me know outcomes.

 

One further thought. The MS decoder hardware is of significantly higher specification than the MX and requires higher power for programming . Make absolutely sure that when you make a CV change or perform a re-set, that it actually occurs. Repeat if necessary.

 

Best regards,

 

Paul

Edited December 6, 2022 by pauliebanger

[Ruston]

Thanks, Paul.

 

5 hours ago, pauliebanger said:

Are you using Shunt Mode when these problems occur?

I am not using shunt mode, just normal running and light engine (F5).

 

Here's something else to ponder. I had a faulty MS500, which went back for repair and the replacement has just arrived, today. I have just now finished installing it into another Peckett. The sound project on this one is the L&Y Pug. It too has the same problem of coming to a dead stop when the brake key (F2) is used when in light engine mode.

 

I have another of the same loco, same decoder, same project, that I bought and installed a couple of months ago and it does not have this problem.

 

I have just had both engines on the program track and have read the values of CV349 and CV390. Both have the same values of 6 and 40, respectively. How can two mechanically identical models, with the same decoders, the same sound projects, and the same CV values that affect braking behave so differently?

 

I have 8 engines with these two projects that have the same values for CV349 and 390 and all, except these latest two that were purchased in the last few weeks, work exactly as they should. I have never altered, or had need to alter, these CVs on any of the others.

 

Does this not suggest that there is some merit in what the chap at Digitrains said about the firmware?

 

[pauliebanger]

Dave,

 

I can't answer your question any differently.

 

One of the possible variables I mentioned earlier is the decoder. This could be due to changes in hardware*, firmware or a combination of the two. *Shortage of components has caused some design changes.

 

So, yes, it may be the firmware.

 

What is the firmware version on the L&Y which works to your satisfaction? And the version loaded on the more recent one? (CV7 for the main version number and CV65 for the sub-version).

 

BTW, issues with multiple triggering of brake squeal below the value in CV287 should have been fixed at V4.205 (December 2021)

 

Best regards,

 

Paul

[Ruston]

Cheers, Paul. I will have a look, later, and report back.

[Ruston]

6 hours ago, pauliebanger said:

What is the firmware version on the L&Y which works to your satisfaction? And the version loaded on the more recent one? (CV7 for the main version number and CV65 for the sub-version).

The problem one is 4/226. The other one is 4/219.

[pauliebanger]

I'll contact my colleagues at ZIMO and get back to you.

[pauliebanger]

Hi Dave,

 

I had a lengthy technical response from ZIMO just now.

 

The bottom line - the Firmware has been changed at V4.226  (actually at V4.225.1 and V4.225.2 but I don't think these are public releases) regarding the Brake Key in Light Engine mode.

 

You're probably not going to like this next bit, however. LOL.

 

The operation in V4.219 was incorrect. V4.226 aligns the brake effect with the way it has always operated on MX decoders.

 

So, you have a couple of options.

 

1. Backdate your firmware to V4.219. (but see below*)

2. make the adjustments I suggested earlier to achieve the correct balance to suit your needs.

 

 

If you do think about changing the firmware to an earlier version, please note this warning which I copied from the firmware page on ZIMO's website.

 

ATTENTION!
As of SW version 4.225, downdates are STRONGLY DISSUADED!

After an update to SW version 4.225, a downdate of the decoder to an older SW version is only possible to a very limited extent for technical reasons -
the decoder may no longer respond!
A downdate with MXULF works on decoder firmware level, but the loaded sound project including settings is no longer accessible! (ZIMO sound projects can, however, be reloaded from the sound database). Future updates can then be downgraded to version 4.225 again.

 

 

Best regards,

 

Paul

[Ruston]

Thanks, Paul.

 

So far I have only played around with CVs 349 and 390. I have managed to eliminate the echo sound on normal braking and have got the start of the squeal to play when in light engine mode, even though it still pulls up far more quickly than it should. I will have a go with CVs 4 and 387 and will see what I can do there.

 

Does all of this mean that these same sound projects, if bought in future, will need all of these CVs to be adjusted from now on, or will you be working on updates versions of your own projects so that they come with them already set to give the ideal performance that they had before the firmware changes?

[pauliebanger]

4 hours ago, Ruston said:

 

Does all of this mean that these same sound projects, if bought in future, will need all of these CVs to be adjusted from now on,

 

or will you be working on updates versions of your own projects so that they come with them already set to give the ideal performance that they had before the firmware changes?

Dave,

 

Maybe they will, so it's worth keeping a note of ypur prefered values. 

 

I will not be directly involved with these projects in future as Digitrains will be maintaining and updating them.

 

Best regards,

 

Paul