DCC Speed Matching Question

[shark_jj]

I have been speed matching a whole bunch of locomotives over the last year.  Primarily it is Kato engines with Digitrax decoders, though there is the odd TCS sprinkled in.  It seems like every so often an engine will lose its "speed table" for unexplained reasons.  It seems I read somewhere that if you experience a short on the layout, the momentary kind when someone runs into a switch they didn't throw, that this can effect decoder settings.  Does anyone know if that is accurate or if there is another explanation for why the speed table seems to alter and the decoder reverts to its default settings.  Secondly, I have been moving CV57 which I believe is Back EMF to 0 when I am doing the speed matching.  Should I be resetting this after I speed match, and if so what is the setting I should be using. 

Thanks for any insights you can provide.

John

[peteski]

Yes, some types of voltage spikes (which can be caused by a DCC circuit breaker shutting the power down or turning it back  on) or even tens of thousands of Volts static electricity generated by you touching the rails or mthe model can erase/change (corrupt) the decoder's internal memory circuits (which old the CV values).    After all a decoder is a highly-integrated tiny computer with not much protection from electric spikes. So, it is possible that certain CVs can seemingly spontaneously change in the decoder.

I'm curious as to exactly what you have to reprogram in those decoders to get them to work properly. Have you done any investigating, or you just blindly reprogram them?

Do you use the 3-step speed matching (CV2, 5, ans 6) or  the full 28-speed step table?
If you use the 28-step table, is only CV29 messed up, or some or all of the 28-speed step CVs are messed up?

While knowing the above details will not make the problem go away, it would be interesting to see exactly what is affected when the problem occurs. 

[shark_jj]

Peteski, here is the background.  I have somewhere between 50 and 60 locomotives on the layout.  There are 23 consisted sets.  I am using simple consisting, ie. all of the engines in the consist have the same 4 digit decoder address.    Engines are not swapped between consists.  Observations are anecdotal.  This has happened maybe a half dozen times over the last 6 months.  All of the consists have been speed matched, and at the time that I did it I was satisfied that they ran together relatively smoothly.  Over the last 6 months I have had to speed match a consist again somewhere between 3 to 6 times.  This is due to them now being noticeably mismatched.  Nothing else is affected.  The address remains the same, CV29 to the extent that it controls direction, forward or reversed in the consist, is not affected.    Decoders for the most part are from the same family since the engines are Kato SD40's, SD40-2's primarily. 

I am using the 3 step speed matching method CV2, CV5, CV6.  I have removed momentum, CV3 and CV4 to O, and taken off Back EMF, CV57 to 0.  I do have JMRI but have not been using the speed curves, as the 3 step approach has proven simpler and with my programming track right on the layout, more convenient. 

I do have several operators who have a bad habit of running up on turnouts that they haven't thrown and causing a momentary short.  The speed match in the consist hasn't been reported till later by an operator running that consist in a train so it is impossible to conclude a cause and effect from the shorts.  I was hoping someone else had a similar experience and had been able to resolve it.

[MK]

My consisted engines have BEMF set to 0.  I turned them off.

[peteski]

Yes, when using advanced consisting (CV19 < 0) Digitrax does weird things with BEMF (I'm not up on the details). But since shark_jj uses simple consist (just sets the address of all the locos to be the same), that is not a problem.  But even if the simple consist locos are speed matched, If BEMF is enabled, it might cause the locos to fight each other.

Shark_jj:  while you provided lots of info, you didn't answer my original question:  Did you check which CVs were scrambled, and what did you to get the models speed-matched again.  Do you just re-write its CVs with what is stored in DecoderPro?

As for CV29, my only thought was that if its bit was set to use the 28-speed table, I was wondering if it reset to go back to the 3-step table.  I'm talking about CV29 bit 4.   If the problem occurs again check CVs 2, 3, 4, 5, 6, 29, and 57 for mismatch with what you have stored in DecoderPro.  That should give a clue as to what CVs got scrambled.

As far as resolving the problem, I suspect the only solution is for the operators not to cause shorts.  I suspect that even if the decoder was locked (if Digitrax has that feature), it will still be prone to getting scrambled by voltage spikes.

[kiwi_bnsf]

I have been speed matching a whole bunch of locomotives over the last year.  Primarily it is Kato engines with Digitrax decoders, though there is the odd TCS sprinkled in.  It seems like every so often an engine will lose its "speed table" for unexplained reasons.  It seems I read somewhere that if you experience a short on the layout, the momentary kind when someone runs into a switch they didn't throw, that this can effect decoder settings.  Does anyone know if that is accurate or if there is another explanation for why the speed table seems to alter and the decoder reverts to its default settings.  Secondly, I have been moving CV57 which I believe is Back EMF to 0 when I am doing the speed matching.  Should I be resetting this after I speed match, and if so what is the setting I should be using. 

Thanks for any insights you can provide.

John

As I see it, there are two likely explanations:

1. The shorts are causing a reset or a partial reset of CVs in the decoders. I have definitely experienced this with Digitrax decoders. I'd recommend to create a JMRI DecoderPro roster entry for each loco that you speed match so that it's quick to re-apply the speed table and motor settings if these are lost (and you could even compare them to confirm 100% that they are being scrambled).

As an aside, it would be possible re-apply speed tables and motor settings using programming on the main if you had each loco on an individual road number and used CV19 for consisting (you just need to ensure that the CV57 "Droop" value is the same for non-consisted and consisted operations for Digitrax decoders — this is in two places in Decoder Pro: in the Motor tab, and the Digitrax tab). For more info on Droop and Speed Stabilisation check out the Digitrax documentation: https://www.digitrax.com/tsd/KB926/cv55-cv56-cv57-scaleable-speed-stabilization-back-/#:~:text=CV57 controls the droop separately,2 or 4 digit address


2. The other possibility is that you are observing variation in locomotive speed response due to environmental factors. Several of my locos behave quite differently when cold as compared to when warmed up, and this can dramatically change the speed response. Typically I find this is most obvious with Atlas locos equipped with ScaleSpeed motors which will speed up after 10-15 minutes of running, but some of my older Kato locos suffer this too. If there is any over-lubrication in the drive train (especially of the motor bearings), then this can have a big effect.

I've found the solution to this is to always use BEMF when speed matching. The BEMF motor control does a good job over overcoming environmental factors that affect the load on the motor. It seems to be widely documented that BEMF + Consisting = Bad. This is simply not the case so long as you do a fairly decent job of speed matching your locos. All my locos have BEMF enabled and run in CV19 Advanced Consists, and I don't get any fighting at any speed across a wide variety of loco and decoder manufacturers. I've found this to be very reliable over the long term.

Hope that this info helps.

[jagged ben]

Shark_jj, are you actually reading back CV2, CV5, CV6 on the programming track after you notice the change and determining that the values have changed from what you previously set them to?  (Are you using JMRI to keep track?) 

Because if not, I find it really hard to say that it's not just little things affecting the loco mechanisms.  Something like a tiny bit of grit in the gears could easily slow down loco speed. (Or conversely, if the grit was there when you speed matched and then gets loosed, it could speed up.)  Dirty wheels or other pickup issues would also slow down speed.  Or any of a number of other barely noticeable changes to the mechanism. 

I also speed match my locos with the basic method like you, and I find that the loco speeds frequently just change without easy explanation.   Sometimes it happens in the middle of a speed setting session, and I have to start all over.  (Probably happens less with Katos, other than 'screwless', but still happens with them sometimes.)   Other times it seems like a loco's speed gradually changes by 10-20% during the session as it warms up.   Whenever I take apart a loco for any reason I consider the speed matching to be out of date and need to be redone.  I've just sort of accepted a certain degree of this; I don't think N scale loco mechs are made with the precision or protection from dirt and handling needed to be more consistent. Redoing speed matching every so often is something I expect.

I will say that I definitely have also experienced decoders losing programming during shorts, up to and including the address itself.  And if I recall correctly, I found TCS prone to this in a way that Digitrax and ESU are not.  But from what you've said I don't find it all definitive that that's what's happening to you.  Could just be the mechs.

[Maletrain]

Running-in 4 ER Baldwin Sharknose DC units on a test loop, I find that, as a coupled group, the lap time starts out at about 54 seconds, and steadily decreases for about 15 minutes to a value around 43 seconds.  So, about a 25% increase in speed as they warm-up.  Furthermore, when uncoupled and run on the same loop, they ones that run fastest when cold are not the ones that run fastest when warm.

In the case of these 4 units, they are essentially identical mechanisms, and they do not run all that much differently from each other if they are all in the same state of warmed-up.  They all start at nearly the same voltage, too.

However, it tying to speed match a pair of little steam locos for my club, I had a problem.  Both are DCC with apparently the same OEM MRC decoders, with apparently the same motor and gearing, but different driver sizes.  One is a 4-4-0 and the other is a 2-6-0 with smaller drivers than the 4-4-0.  I could match these when warmed-up, but not when cold.  So, the 2-6-0 would drag the 4-4-0 when first started (4-4-0 wheels would not even be turning unless throttled into a jackrabbit start), but then the 4-4-0 would try to drag the 2-6-0 when warmed-up.  Apparently, the differences in the resistance of the larger wheels and associated valve gear just would not allow a match over the speed range and temperature range at the same settings.

None of that difference was due to momentum effects, which I had set to zeros to speed match.

I think that it is just a fact of life that some locos will not speed match the same when cold as when warmed-up.

That said, I do have a pair of Scale Trains dash 9s that I acquired over a year apart, which will maintain the same separation for multiple laps around my test loop, and I have not touched the speed settings in either one.

[shark_jj]

Thanks everyone for the sharing your insights.  It has been helpful.  I am clearly getting the message that I need to do a better job of tracking original settings and then verifying whether or not they are different when I see a change occur in the speed matching.  It is also a good point about warm up vs cold running.  My consists may sit for weeks, and then be run during an operating session for perhaps 20 or 30 minutes and then sit again for an extended period.  I have noticed smoother performance the more they run so that is a good point.  I'm pretty certain the issues aren't mechanical.  Once I reset the speed range, I can speed match the two locos again without too much issue.  If the problem was mechanical it would be ongoing.  Jagged Ben also made an interesting point about finding this problem more prevalent with TCS decoders and I do have a few sprinkled in.  I haven't really tracked whether it may be happening to them as opposed to the digitrax decoders.  That is also something I will monitor going forward. 

[peteski]

While we are presenting all sorts of info about speed matching locos, shark_jj was originally asking about the decoder's "brains" getting scrambled due to shorts caused by locos running switches (causing speed mismatch in a simple consist). Specifically "It seems like every so often an engine will lose its "speed table" for unexplained reasons."

But he has not yet come back with some vital info:
1. Did he check several individual CV involved in the locos running (which were mentioned in my last post) when the loco started misbehaving, to see which values got scrambled.
2. He did not elaborate as to what he did to get the locos to run correctly again.

Those 2 points are important to understand what happened.

EDIT:  Hmmm . . . why would someone down-vote this post?

[shark_jj]

Sorry Peteski, I thought I had answered your questions, though in hindsight a bit indirectly.  On the question of "did i check the CV's" , I  didn't which is why i said I would have to do a better job of monitoring that going forward. With respect to what did I do to get them to run correctly again.  As mentioned previously, I redid the speed matching. I know that doesn't help much with your efforts to analyze the problem which is why if it occurs again I need to do a more effective job of documenting the current state of the CV's and their state after the problem has occurred. 

[peteski]

Sorry Peteski, I thought I had answered your questions, though in hindsight a bit indirectly.  On the question of "did i check the CV's" , I  didn't which is why i said I would have to do a better job of monitoring that going forward. With respect to what did I do to get them to run correctly again.  As mentioned previously, I redid the speed matching. I know that doesn't help much with your efforts to analyze the problem which is why if it occurs again I need to do a more effective job of documenting the current state of the CV's and their state after the problem has occurred.

No problem.
I now understand that you just rewrote the CV2, 5, and 6 performing new speed matching the procedure.  Basically no evidence of the problem was collected.   If re-doing the 3-step speed matching took care of the problem that implies that CV29 was likely unchanged, and the problem was likely with CV2, 5, or 6.   The fact also remains that if your operators keep causing shorts, the problem will likely return.

But looking at the big picture, even if we knew what CVs were scrambled, this will not solve the problem since it is caused by external cause (the short).  I was interested in what CVs were scrambled to satisfy my curiosity.   My daytime job is troubleshooting computer system problems, so it is a second nature to me to collect as much of information about the problem as possible to be able to better understand and troubleshoot the problem.

The important thing is that the decoder was not permanently damaged by the short, and you were able to speed match it with the rest of the consist.

EDIT:  Hmmm . . . why would someone down-vote this post?