DCC issue

[Nick_Burman]

Hello all,

 

I've fitted DCC to my Japanese fleet (mainly Tomytec with one Kato "Pocket" loco; 4 Micro-Ace locos are being converted as I write now), my cars/locomotives are all fitted with TCS Z2 decoders, set to 128 steps with acceleration and deceleration values inserted + top speed restricted. I run trains using a Bachmann Dynamis system and program them through a JMRI interface. However I'm having an odd issue with my equipment, namely erratic acceleration - when I notch up the controller the cars sometime slow down rather than accelerate or show an erratic slow-fast behaviour. When running on the JMRI throttle this issue doesn't happen, acceleration and deceleration is smooth. As soon as I switch to the Dynamis the erratic behaviour begins. Oddly enough, the behaviour ceases if I switch the controller from 128 to 14 steps (which is quite interesting, as is is the closest DCC offers to a real traction controller). Am I right in thinking that the Dynamis is having trouble "conversing" with the Z2s or is the problem different?

 

Cheers NB

[KenS]

Dynamis uses a wireless (infra-red) throttle. I've read of people having problems with them at exhibitions.  Is it possible you're getting interference from sunlight or a bright incandescent/halogen room light? What you might be seeing is the base station having trouble getting the instructions from your throttle. I don't know why switching to 14 steps would affect that though.

 

All that either throttle should be doing is sending a "speed" number that's proportional to the base station (aka command station), which will translate that into the appropriate DCC throttle "speed step" to send to the train's decoder.  In 14 (or 28) step mode, this uses a 16-value or 32-value setting (with two or four values meaning various kinds of "stop"), in 128 step mode a 128 value number is used (of which two mean stop, so it's really 126 steps). But while it uses a different instruction, and hence you could be seeing some kind of decoder problem, normally a Z2 should handle both identically (except with larger jumps in speed on 14/28 than for 128).

 

Is there any chance in programming the Z2 that you zeroed out CV29, or set it to some value lacking bit 1 (the bit with value 2)?  If bit 1 isn't set, 28/128 mode isn't enabled, and that could be a problem. The normal default value would have that enabled.

 

Edit: corrected to the description of which bit controls 28/128 mode to be more clear.

Edited November 9, 2013 by KenS

[Vato]

I have a same problem with MRC prodigy (kato sunrise express with digitrax DZ125)

[Nick_Burman]

Dynamis uses a wireless (infra-red) throttle. I've read of people having problems with them at exhibitions.  Is it possible you're getting interference from sunlight or a bright incandescent/halogen room light? What you might be seeing is the base station having trouble getting the instructions from your throttle. I don't know why switching to 14 steps would affect that though.

 

All that either throttle should be doing is sending a "speed" number that's proportional to the base station (aka command station), which will translate that into the appropriate DCC throttle "speed step" to send to the train's decoder.  In 14 (or 28) step mode, this uses a 16-value or 32-value setting (with two or four values meaning various kinds of "stop"), in 128 step mode a 128 value number is used (of which two mean stop, so it's really 126 steps). But while it uses a different instruction, and hence you could be seeing some kind of decoder problem, normally a Z2 should handle both identically (except with larger jumps in speed on 14/28 than for 128).

 

Is there any chance in programming the Z2 that you zeroed out CV29, or set it to some value lacking bit 1 (the bit with value 2)?  If bit 1 isn't set, 28/128 mode isn't enabled, and that could be a problem. The normal default value would have that enabled.

 

Edit: corrected to the description of which bit controls 28/128 mode to be more clear.

 

 

Ken,

 

I spent the whole afternoon experimenting. First, tried my DCC station in an environment without direct sunlight or artificial lights (indirect natural sunlight). Station behaved as usual. Second, I verified CV29 on all items of rolling stock - all items had it properly enabled. No problems there - JMRI seems to write values correctly.

 

I also converted the whole fleet from Vmin/Vmid/Vmax speed control to Speed Tables. It improved operation quite a bit (in some cases I can run in 28 step mode), but I'm still mainly forced to run my trains under 14 controller steps. However, while experimenting with speed tables I found another issue...I would set the 1st step in the table with value 1 (range 0 - 255), then when I tried running the car/locomotive it would run away at a scale 200mph+ the moment I opened the throttle into the first notch (a few pieces of rolling stock almost launched off the table...). Oddly enough, as soon as I moved into second notch and beyond it would reduce speed back to normal and would continue accelerating normally and smoothly.

 

 

Somehow I think that the whole issue is one of a DCC station which is unable to "talk" correctly with the decoder. I need to try another station to see I'm talking correctly.

 

Cheers NB

Edited November 10, 2013 by Nick_Burman

[Nick_Burman]

I have a same problem with MRC prodigy (kato sunrise express with digitrax DZ125)

 

I think that "El Cheapo" systems like the Dynamis or the Prodigy have difficulty "talking" to some decoders. However I would need to try another, higher range, system before being sure of what I'm saying. I used to have a Digitrax (it left with my layout) and my memory of it was that it "spoke" better to other brands of decoders.

 

Cheers NB

[KenS]

But with JMRI, aren't you still using the command (base) station of the Dynamis? Which would imply the base can talk to the decoder just fine. Or do you have a second DCC command station (what brand?) for JMRI to use?

 

While I can't say you're wrong, since I don't have any experience with a Dynamis, I'd be really surprised after all these years if any name-brand command station couldn't successfully talk to a name brand decoder.  Those standards have been set in stone for a long time.

 

But yeah, it does sound like the throttle command is getting scrambled somewhere.

[Nick_Burman]

But with JMRI, aren't you still using the command (base) station of the Dynamis? Which would imply the base can talk to the decoder just fine. Or do you have a second DCC command station (what brand?) for JMRI to use?

 

While I can't say you're wrong, since I don't have any experience with a Dynamis, I'd be really surprised after all these years if any name-brand command station couldn't successfully talk to a name brand decoder.  Those standards have been set in stone for a long time.

 

But yeah, it does sound like the throttle command is getting scrambled somewhere.

 

Ken,

 

Sorry, forgot, I'm using JMRI connected to SPROG to program equipment; Dynamis is only used to run the trains. I'm unsure if I could use JMRI through Dynamis (Bachmann makes an extra base station for the Dynamis system which could be wired to a computer).

 

Be surprised then, because I've seen several decoders who still don't talk correctly to some stations, standards or no standards...worst offenders are Broadway Limited and MTH...

 

My Kato Pocket Line loco has accepted running on 28 steps. However because I'm having problems with decoders running away as soon as I open the first notch, I'm forced to set it to 0 (it will begin accelerating from notch 2 onwards) and even so some times it decides to run away on notch 1...

 

 

 

Cheers NB

Edited November 10, 2013 by Nick_Burman

[KenS]

Runaway behavior probably means that the decoder isn't seeing a valid DCC signal, although it can also happen if it just gets confused (I've had that problem when programming Digitrax decoders).  It might be worth checking your wiring to make sure it's all solidly connected and not damaged anywhere.  And if you're using sectional track without a feeder on every section, look for bad joints (with no train, test resistance across the joiner by touching the multimeter leads to the middle of each track section away from the joiner, resistances of more than a few ohms indicate a bad joiner).

 

Another thing to do is factory-reset the decoder and re-program it to what you want. Sometimes that will fix problems in the decoder caused by changing the configuration multiple times without a reset as you work out a valid configuration.

[Nick_Burman]

Ken,

 

Thanks once more for the great (freebie.. :)) tech support. I've reset the decoders on my equipment several times now. No luck...I think the issue lies with the Dynamis. Indeed, after several resets one of my decoders "went stupid" - it now refuses to read settings for speed tables, only Vmin/Vmid/Vmax works...it also means I can't MU this particular decoder with the rest of the fleet...

 

 

Cheers

[KenS]

Always glad to help. Although it seems to far I'm just using up bits and not actually helping.  Well, bits are cheap. :)

[Nick_Burman]

After a bit of experimentation I finally think I got down to the root of the issue. I installed JMRI/SPROG into another computer, updating the software to the latest release in the process. Then I began looking into the decoders...only to discover I was trying to program the wrong decoder model! :huh: :blink: :wacko: In fact most of my decoders were M1s, with only one Z2...the older version of JMRI I was running was unable to ID them properly... I then reprogrammed everyone and there was a marked improvement in performance. However the runaway behaviour was still present...I "cured" that by setting CV67 to 2, then creating my speed table from there (I wonder if the Dynamis interprets a setting of 1 as "full speed"). With this measure the decoders can now work at 14, 28 and 128 steps without problems. I set my freight equipment to 128 steps, but the passenger motors were kept at 28 steps.

 

Cheers NB