Speed mapping puzzle with TCS decoders

[GaryHinshaw]

Group,

The bulk of my fleet is equipped with TCS K1D4 decoders and I have encountered a puzzling speed mapping issue that I can't figure out.  I am using Decoder Pro to set up 28/128 speed tables and the particular tool I'm using lets you enter individual speed values from 0-255 for each of 28 steps.  It then sends the necessary commands to program the corresponding CV values.  That all works fine, and the program is very simple to use.  The issue I'm having is that when I run the locos with a DT402 throttle, which has encoder values from 0-99, the locos will "stutter" at certain throttle settings as if the speed table were putting the decoder into some sort of limbo.  At these settings, the motor seems to vibrate a bit, but the loco does not move and the LED flickers.  As soon as you go to a "clean" throttle setting, everything works fine again, and in fact, the motor control is generally outstanding, making this one feature especially puzzling.

The particular 28/128 mapping I am using is a linear ramp over the 28 steps with a minimum of 0 at the lowest step and a maximum of 127 (half the maximum voltage) at the highest step.  This generally works very well, except at DT throttle step 3, where I consistently see the stutter.   

It's possible that I don't understand the logic of a 28/128 speed table.  Are there 28 or 128 actual voltage steps in the output of this type of decoder?  To be more precise, let T be the throttle setting (0-99), D be the decoder step value (0-27) and V be the actual voltage, such that Vmax=255.  Then, for my particular CV settings, I could either have:

V = INT(128*T/100)   (gives 100 distinct values for a DT throttle, but 128 total steps are possible with other throttle types)

or

V = V(D) = V(INT(28*T/100))    (gives 28 distinct values)

Since I can see speed differences between settings T=0,1,2, I think it must be the former: 128 actual speed (voltage) steps that are specified by 28 points in the decoder firmware plus some formula for interpolating between them.  For a linear ramp, this would give the following map:

T     V
0     0
1     1
2     2
3     3
4     5
5     6
etc.

In this example,  throttle setting 3 is the highest value before the map skips a voltage step due to the way the integer truncation works.  I suspect some peculiarity in the firmware interpolation may be responsible for this, but that is difficult to prove.  Anyone have any insights to this?  When I tried setting the speed curve to the range 0-99, to match the number of throttle settings, the situation was even worse with more T steps causing stuttering.  Clearly there is something in the speed mapping logic I don't understand...

Thanks,
Gary

[ednadolski]

Are there 28 or 128 actual voltage steps in the output of this type of decoder?

Is it a straight DC voltage output, or some kind of waveform?    Would be interesting to put a scope on it.

Ed

[C855B]

Is it a straight DC voltage output, or some kind of waveform?    Would be interesting to put a scope on it.

The "lights flickering" puzzles me, because, yes, there is a waveform on the motor drive, a PWM signal that phases to straight DC. But that shouldn't impact the lights.

I was thinking there was some manner of poorly-managed hysteresis issue in the PWM transition when using the speed tables, but the flickering lights dissuade me from that idea. I think overall it's a question for TCS.

[peteski]

Gary, what I find invaluable in questionable situations like this is the DCC Pocket Tester from PRIcom http://www.pricom.com/Trains/DCCTester.shtml .  It is the most complete DCC packet analyzer I have ever seen.  I love it!

You mention 128 speed steps vs. 0-99 throttle setting.  Using that tester hooked up to the track you can actually "snoop" for all the control packets sent to that particular locomotive. So for example you see what is the actual speed step command being sent to the decoder at any throttle setting.

The speed matching I'm used to is the simpler Vstart/Vmid/Vmax CVs.  I find that good enough for most applications (and it is so much easier to set up).  But I don't expect the locos to be perfectly speed matched - I survived MU-ing locos in the DC days in long trains on N-Trak layouts. 

As far as the motor control of DCC decoders goes, since day one they used PWM (Pulse Width Modulation) of the full decoder voltage to produce variable speed at the motor. But I don't know whether there are actually 128 distinct steps of the PWM waveform on those particular decoders.

[ednadolski]

The "lights flickering" puzzles me, because, yes, there is a waveform on the motor drive, a PWM signal that phases to straight DC. But that shouldn't impact the lights.

I thought 'flickering lights' was generally indicative of a power dropout.  in most cases the cause would be poor contacts or improper installation.  But here it almost sounds like the hardware is reaching an operating point that puts it on the margins of what the onboard power supply can provide, so the microcontroller starts cutting in & out.   You could even be tripping on a hardware or firmware bug, if this happens the same way on multiple decoders.  I'd agree that this seems like a question for TCS (and while snooping packets may be interesting, it probably won't be very helpful in this case).

I don't suppose there is a way to parallel an additional keep-alive capacitor to see if that makes a difference?  Or if you have similar model decoders with later revisions of hardware and/or firmware?

(Caveat: I'm a software guy, so anything more than changing a light bulb is out of my league.)

Ed

[peteski]

If electrical pickup is in question, Gary could simply take the shell off the loco, place it upside down on his bench (or on the layout) then using couple of jumper leads wire the chassis halves to the track. That way the question of intermittently pickup can be eliminated.  I assume that the motor armature will be visible so that he can observe whether it is running, stopped, or stuttering.  The headlight LEDs will also be readily visible.  I suspect that Ed is correct - it is probably a software (firmware) bug.

[GaryHinshaw]

Hi guys,

Been offline all day, but thanks for the responses!  I'm 99% sure this is not a contact issue because it is repeatable across many locos and decoders (but all model K1D4 in this case - and I don't see this with my few Digitrax decoders).  It occurs repeatably on a specific throttle setting, then goes away on the next step up.  It sure smells to me like a software issue.

BTW, setting 28 step maps with Decoder Pro is *very* easy.  I actually had more stuttering steps with a 3-point map, which is what made me try a 28-step version.

I'm going to try watching the Loconet Monitor, then maybe I'll try getting a Pocket Tester, then I'll contact TCS.  I'll keep you posted.

Cheers,
Gary

P.S. This is really just a minor annoyance, nothing more.

[peteski]

... repeatable across many locos and decoders (but all model K1D4 in this case ext step up.  It sure smells to me like a software issue.- and I don't see this with my few Digitrax decoders). 

  I actually had more stuttering steps with a 3-point map, which is what made me try a 28-step version.

To be honest my experience is mostly with Digitrax decoders - I haven't done much with speed tables on TCS decoders.

[ednadolski]

After reviewing this TCS page, a few other thoughts come to mind.  Most of these are installation-related, so they probably are OK, but it doesn't hurt to verify on one loco.

 - Are the motor contact clips installed securely onto the circuit board, and properly insulated from the frame with Kapton tape?
 - Are the decoder power pickup pads making a good contact with the frame clips?  Note that this installation procedure calls this out as a potential source of problems, and they even wedge in a bit of the foam packaging to press the contact pads tightly against the frame.
 - Have you trimmed the four red-circled plastic pins on the interior of the shell as indicated in the photo?
 - Does it make any difference if BEMF is enabled or disabled?


HTH,
Ed