Nigelcliffe

1 - exactly how did you wire this ? As I understand them, DCC-Concepts Nano LEDs come with series resistors. I assume those were also fitted in series with the LEDs. As such, they would either "light" or "not light" depending whether the supply from the decoder was the right way round. The resistors would ensure that the current flow was minimal in any wiring combination. To cause a decoder failure implies a short circuit, which to my mind, means a mistake in wiring. Leaving out the resistors could result in an effective short circuit through the LED, which could be toast for a DCC Decoder. Accidentally connecting one side of the decoder directly to pickups could result in toasting a DCC Decoder - lighting circuits may use track for one side of their power *if done correctly*. 2 - three-wire two colour LEDs come as either common anode or common cathode. DCC-Concepts website says "common positive", so reasonable to assume that is correct. Resolution - needs understanding of the wiring changes being made.

The MX-series decoders are no longer made. You need to look at MN-series equivalents (MN-340 is MX638 replacement), which all the Zimo stockist will have. Zimo's pricing of some MX-series decoders in the UK seemed very much a "UK only" policy - they were never as cheap in other countries. And yes, things are more expensive because the components which go into them are more expensive (and DCC decoder makers are at the end of the component shortage queues as tiny niche makers of things when compared to most other uses).

As per Hamburger: a) you mean CV2 (not CV1). b) CV6 only exists in some ESU decoders, depends on the specific decoder type. Paul's might be "DCC only" types (North American) which do have CV6, or might be "multiprotocol" (European) which don't. Given his models are Chinese prototypes, there's no automatic assumption of one type or the other. Which means the solution is one of - use CV2 and (mostly) CV5 and hope to hit something full 28 point speed curve (definitely works, but highest amount of effort) CV5 and CV6 if it is a "DCC only" ESU decoder, and may get things close enough.

Paul has the relevant hardware for JMRI connection to layout and command station ( I've talked stuff through on the phone to configure LocoNet devices via a LocoNet-to-Computer link). Someone may have to demonstrate how it works, I think it's a tricky one to do remotely. Best arrangement is generous radius circuit, so the reference loco can be timed at each of the key speeds, and then the secondary locos adjusted to match the same timings at the same key speeds. Can run both at the same time and same speeds, with a gap between them, and see which is faster/slower, making adjustments to the speed curves as they are moving. If the speed matching is for double-heading, then additionally reducing the BEMF influence (another CV setting) will mean the locos will compensate internally for differences in speed (the faster one will take a little more draw-bar load and that will cause it to slow slightly).

If two (or more) locomotives have the same address, then they respond identically. By default, new decoders are set to address 3, which is why they all arrive as address 3. Sensible advice is to always program a new address into a new loco, and also give it a new name that makes sense to you. - Nigel

1 - stop overthinking this stuff. The Z21 sorts out the "loco address" and use that. Stop worrying about CVs. 2 - Addressing. There are three types of address in a DCC decoder that people will typically encounter; short address, long address and Consist Address. a) Short address. Takes values from 1 to 127, though some systems will only allow 1-99. This is stored in CV1. b) Long address. Takes values from 1 to 10,239. But the allowed values in systems varies, it might be 1-9999 or 100-9999 or 128-9983, or (pick different range of choice). The values are stored across CV17 and CV18, using a moderately awkward calculation method (or easy method if you're good at binary maths!). c) The decision inside a decoder to respond to the Long or Short address is set in CV29, along with lots of other things also set in CV29. d) If using an "Advanced Consist" (double/multiple heading method, and one of several ways of arranging double-heading), then the Consist Address is stored in CV19. If CV19 is not zero, the Consist Address applies, and the loco responds to that, rather than its locomotive address. Consist address is 1-127, adding 128 to the address means the loco runs backwards (eg. two class 20's running nose-to-nose, one needs to run backwards to the other). There are a few decoders which support long addresses in Consists, stored in a combination of CV19 and CV20, but this is a very small niche at present. 3) From the permitted addresses in various systems, there are certain loco addresses which should be avoided if wanting to move locos from one system to another. Addresses 100-127 might be "long" or "short" depending on system, so best avoided. Long addresses 0001-0099 are likely to confuse, so avoid those if your system allows them as long addresses. And Long addresses above 9983 might not work on some systems. Tools for calculating CV29 and CV17/CV18 are on the webpage I wrote a dozen years ago: https://www.2mm.org.uk/articles/cv29 calculator.htm

There are many elements in making a wheel, and the centre is only one of them. You need to think about: a) getting power from the rim to whatever pickup your loco contains. If re-wheeling a commercial loco, that's either wiper pickups on back of wheels, or its pickup on a tube in the centre of the wheel. If a typical 2mm kit chassis, it's split frame onto the axle. Obviously new pickups could be fabricated for the loco, but that's another small fiddly thing to add to a loco. b) fixing the axle so it is perpendicular to the wheel. A narrow wheel print has a tendency to go slightly squint and give a wobbly wheel. Hence 2mm Scale Association wheels have an axle with a flange to seat in the rear of the wheel. The current stainless prints have a recess on their rear face for the flange to sit in (doing it flush will result in too little clearance from wheel to chassis). c) fixing the crankpin so it is perpendicular to the wheel, in a manner which allows the crank-pin "nut" to be secured to the crankpin. Typically people solder fine washers to crankpins as the "nut", so that's heat going into the crankpin, which mustn't move/melt the wheel. d) securing the rim to the centre. Typically its done with a retaining compound (from either Loctite or 3M), which in turn requires some space to expand into - create the space in the 3D print. I'm quite certain that resin printed centres can work, but there are a lot of things to consider to get them from a nice looking centre to a functional wheel. Several people have used resin prints as prototypes, then transfer that design to use as investment in brass casting processes. - Nigel (designer of the current 2mm Scale Association shop wheels ).

As Riddles says - there is no messing with complicated CVs. The Z21 app will do all the Long Address calculations when setting the address. (As will just about any DCC system currently available).

As its one loco, one decoder, and you know what other ones work, the solution seems obvious - different decoder from a different maker.

The "free with the decoder" small electrolytic capacitors which come with some Zimo decoders offer negligible run-time. They're usually around 470uF (0.00047 F). The "supercap" based devices which much of this thread has been about are typically above 0.1F. As run time is, very very roughly, proportionate to energy stored, and if 0.1F can give 10 seconds, then 0.00047F will give 0.047sec, which won't be visible (though it may stop a decoder rebooting if there is a minute momentary power hick-up). Those electrolytic capacitors are also extremely cheap as components, which is why they're given away for free by the UK Importer of the decoders. My experience in 2mm scale with smaller motors is 470uF is on the boundary of "useful", double that desirable. That can be achieved with very small devices, such as Tantalum capacitors - wander into the 2mm finescale bit of the forum and people squeezing them into tiny tank engines, pre-grouping little engines, etc.. will be found.

I have a thought on measuring this stuff.... Requires minimum of a decent volt meter, but ideally an oscilloscope. Loco will need to be on bench in some sort of cradle (running on rollers might be good). Connect the measuring device to the motor wires inside the loco. And then run it on the different power sources (DC, DCC, different track voltages). See what happens to the applied volts at the motor at different throttle settings. Ideally this would also be coupled with some measure of RPM of the motor, or wheel RPM, which will equate to running speed. No idea if the above kit is available to do the testing. - Nigel

Replace your track/wiring until you don't have a dead spot. Replace the slips with designs which don't have 1 second gaps in conductivity. We're into the old question of : "are stay alives a band-aid for poor quality elsewhere, or a Rolls-Royce running tweak for already good designs". Damage.... loco valve gear gets something from the scenery in it, how much can you mangle with a loco which can't stop for 20-seconds ? Loco leaves track for some reason, how far does it go horizontally before falling to the floor.

I can't see why anyone needs beyond 1 second of stay-alive running time(*). So, if the Train-o-matic is giving the performance required in all other respects, why change it ? There is a reason for much larger storage capacity, and that's a Zimo feature whereby the decoder can detect if it comes to a standstill on a dead-spot. Then, the decoder will attempt to nudge the loco along until contact is restored. To do that requires lots of energy as motors need a lot to start them moving. I think that's a "Zimo unique" feature, and independent of the "run time" value going out to 25 seconds (if the energy store holds out that long). (* I've done a few comedy demo setups. Recently, a Bachmann J72 which would run about 20 inches along the sleepers (no rails) of a layout under-construction with a wagon containing rail and chairs behind it. Hugely entertaining, and turned down in decoder settings to sensible immediately after the fun. I'll routinely test stay-alive installations by running a loco onto a piece of paper to see how far it goes. But then set the run-time to sensible. ) - Nigel

Have you swapped the combination between locos for the figures you quote ? Or are they different locos ? Different locos will have a massive impact on the run-times, a high-efficiency motor will give 20 seconds running, a low-efficiency might be exhausted in under 2 seconds. There are CV's inside Train-o-matic for stay-alive run-on. I don't know how they impact the 2-wire stay-alives (the decoders are, like ESU, designed for three-wire setups), but its possible they are relevant. Default run time is quite short, because they've decided locos which run over the scenery are probably going to cause damage to themselves and the layout.

Incorrect for Lenz/ESU/Zimo/Train-o-matic/etc... (Can't answer for DCC-Concepts, they did their own thing, and it isn't compatible with everyone else). What the direction of travel CV indicates is "Left rail" or "Right rail" in the direction the loco is moving. So, with a single Brake Module, in the normal direction of travel, with the CV set to that rail (only), the loco will stop a loco regardless of travelling chimney first or tender first. If travelling the opposite direction, with the CV set to the single rail (only, as above), then the loco ignores the stop section. However, a different stop section on the other rail would be effective (because everything has been turned around). There are, in different decoders, usually options to disable ABC braking from a function key which might allow your tender locos to drive tender-first through the brake section, assuming that's what you would want to happen. I think your setting will give "wrong behaviour". If you've set them to "both sides" then they'll stop whether travelling up or down the line. (that's what the setting does! - it stops the loco if it detects a brake instruction on either side "in the direction of travel"). I think you want them set to "one direction only" as with the tender locos above. - Nigel

Post your questions on the JMRIusers group on Groups.IO. That's where JMRI tech support is found. There are dozens of Mac users on there (half the JMRI development team use Macs). Its likely a very simple settings matter, or an old file lying around in your profile (which is what it sounds like if you've a reference to a JMRI version 3 file). - Nigel

RunTime value of 60 ought to give best part of 2 seconds. All looks OK from what I can see in the photo. Now into guesswork territory... 1) check the function mapping (takes a long time to read all of that in DecoderPro). Is Aux7 set in any mapping rows ? If so, could that be a factor ? I'd be tempted to remove it from any rows. 2) whilst I thought the ESU powerpack doesn't care about analogue operation being possible (just doesn't operate in analogue), just maybe its confused by it, so turn off analogue in CV29, and also the analogue modes in CV50. Thereafter, its discuss with the supplying retailer and/or ESU. I don't know if SouthWest Digital still offer support in the UK for ESU products ?

Basic wiring first.... An ESU stay-alive has three wires. Decoder Positive, Ground and a control wire, all need connecting, the control is only on the decoder, the positive and ground are on decoder and duplicated on the loco after the Next18 socket. Are they all connected to the correct places ? The run time is set on the "Advanced" Pane, fair way down left column for "Power Pack Maintain Time".

In an ESU decoder, any CV above 255 doesn't make any sense without quoting its index numbers (CV31/CV32) as well, because otherwise "CV323" can be any of at least a dozen different things. Those are listed in DecoderPro files, they consist of three numbers in succession in the CV list, such as "16.0.323", the first two being the index values, the last the specific CV. The setting you're looking for is on the "Function Outputs" pane, scroll down to Aux7, and set it to "PowerPack". - Nigel

Yes, that's one. Some other Zimo retailers are significantly cheaper. How to fit it together - read the instructions 😀 You need both the Staco-3 instructions (come with it or Zimo website) and the decoder instructions (Zimo website). You'll need to attach two wires from Staco to the "positive" ("Pluspol" on some diagrams) and "ground" ("mass" on some diagrams) of the decoder. On a six-pin decoder, both of those are solder pads on the decoder. And then join the two capacitors in series with each other, and attach the pair of capacitors to the other two wires from the Staco. There's a certain amount of: if you can't follow the manufacturer's instructions then don't go blowing up electronics parts. I did say that I didn't know if it would fit, just that from a photo I thought it might fit. - Nigel

New wire means can put green marker pen on the outside of each strand. That ensures the electrons stay inside the wire and don't ping off altering the sound...

I've not got any measurements, but looking at the photos, I'd think the newer Zimo "Stacco" stay-alive circuit with two small super-caps might fit. Probably need to throw out the 6-pin socket to create the space, and then wire direct to decoder. That should give more than enough run-on time to overcome any momentary drops in pickup. - Nigel

Some time ago, I bought a collection of ESU decoder wire in multiple colours. It was moderately expensive for the amounts, but will keep me going in wiring locos for a very long time. It has very thin internal cores, very flexible, solders well, etc.. Unlike some other thin multi-strand wire I've had from other sources.

Dunno, but you could use a multi-meter to trace that connection on the MXTAPS to the decoder positive on one of the decoder sockets, eg. PLUX.

My limited experience of DJM items in 4mm scale has been "new chassis , the DJM one is a disaster". If the Zimo can't be made to run the motor, then start looking at the mechanism. As suggested above, supplying DCC directly to the chip (skipping all the pickups) would rule those out. It also takes out the need for any stay-alive devices at this stage of investigating. Are there any other components on the DJM PCB ? They may be making things worse. Could try turning down the BEMF influence in the decoder CV's, that may help, but at the risk of reduced quality of control. One might find a sweet spot. (if the DJM chassis is like the J94 design, it induces variable BEMF from the motor due to the way the gearing and rods in the chassis can "fight" each other). I suspect it will be as Izzy suggests. There's nothing to be done with such a pathetic little motor. ( I have used a smaller motor on a 4mm scale Wickham trolley, but that's a 4volt radio-control solution to making a small model ).