Nigelcliffe

Given that a Prodigy-2 Advance costs around £400-£470, that's a fair sized budget, particularly for a old limited capability system (its a re-badged MRC system from the US, not a Gaugemaster design). Alternative at about the same price which is up-to-date: Roco Z21 (capital Z, black colour), perhaps with optional Roco WlanMaus handset, or can use a Phone/Tablet as input. (eg. Scograil in Ipswich have a Z21 plus WlanMaus for about £475 - odd name for firm, but they've been around for a long time selling European brands). Cheaper Roco z21 (small z, white) might be OK, but it has quite a lot of technical limitations compared to the black Z21. If willing to "take a bit of a punt", then I'd look at TCS' new "LT50" system (around £275). Conceptually the handset is like either the Prodigy or PowerCab handset, but its an up-to-date design, rather than something which is 20 years old. Still a little new in the UK to be sure of how well it performs. There are cheaper options. With the exception of TCS, anything which is US-designed has the problem over "latching" key behaviours for the F2 key being fixed at manufacture, which then compromises how locos are controlled. Which brings things back to European designs, or systems which are a bit of "DIY" in how they go together, or which require a computer in the loop.

The trainTech SC300 is a DCC decoder, so goes on the DCC signal, responds to DCC commands. Which I don't think you currently have if you are directly driving turnout motors from switch levers. It would appear to be an expensive way to control one signal. This approach with a relay and capacitor (or relay, capacitor and four diodes) looks simpler and a lot cheaper. It could attach to the on/off switch in the Cobalt motor, or to one of the switch contacts on the Cobalt lever. https://modelrailmusings.weebly.com/Dapol-signals.html

The problems you have are all at the Dapol signal end due to Dapol's quirky control method. Adding more stuff (DCC Concepts Encoders) at the human input end won't help. Specifically: which Dapol signal do you own ? If it is one of the types which need a single push button (push once to move, push again to move the otherway), then there may be a way with the DCC Concepts levers, but its more wires from lever to signal. The DCC Concepts S-levers have passing contact switch - intended to operate a solenoid turnout motor. Those outputs could be used to move the signal; you need to combine both directions of passing-contact. If the signal gets out of step with the lever, you also need a "reset" push button also connected to the control wire, which push-once will bring the lever position back into line with the signal. Alternatively, you need some of the electronic methods mentioned, which gets around Dapol's quirky/daft/bonkers method of control. Its a fairly simple DIY electronics project to take the output from the Cobalt switches and use those to cause an appropriate pulse to operate the Dapol signal.

If you have "lots" and an NCE system, then these options exist (and probably a few more): a) NCE minipanel, takes on/off switches or push-buttons (pair) as inputs to control the signals. Can also control other things b) Computer interface and any number of alternative control interfaces. c) Various DCC-Concepts add-on devices to offer control over NCE cab-bus.

Depends which version of Dapol signals. Dapol had a period of stupidity in signal design - push button once to change signal, push again to change signal - which means that you can't use a switch (or contacts in a point motor) to change the signal to a known position. Hence the use of external control devices to try to make sense of the silly design.

Yes. It works because you'll have four independent transformer windings (two sets of windings in each Duette, each winding feeding one DC speed controller). So, their return paths are all independent to different transformer windings. That said, there are a lot of reasons to not use Duettes, such as the asbestos content in some examples, probably life-expired components, etc., etc..

I hear this a lot. Then I put a stay alive in an otherwise excellent loco for someone, and their response is "transformative", "now I get why you keep saying its worth doing". - Nigel

An old-style car sidelight bulb (nominal rating of 12volt, 5watt) would be fine on most DCC systems. Car electrics whilst nominally 12v are a lot higher in practise. - Nigel

The switch you showed can be easily wired for one-colour illumination. But doing it for both colours on the switch is complicated. ( Using the SPDT switch wiring options in the Tortoise manual). - Nigel

Because Circuitron understand what their product does. The motor limits the current flowing to around 15mA at "stall", which is within the maximum current of typical 3mm or 5mm LEDs (20mA or 25mA is common). With the motor limiting the current flow, the LED will just work. No extra resistors ! ( Though if two motors are in parallel, then their combined resistance is halved, the stall current is now 30mA and the LEDs placed over the common feed to the motors will be over-current and may blow But, if put in the wires after they split to each motor, the LEDs will still be fine..). That then brings us back to switches. Yes, DPDT work, but with the appropriate power supply, one can reduce the layout wiring substantially and use a SPDT switch. With a DPDT switch there are two wires from switch to each motor. With a SPDT switch there is one wire to each motor, and one common wire from all motors back to the power supply. But, the SPDT option requires a slightly more complex power supply; the simpler being an AC source and two diodes for half-wave rectified output, the more complex being two DC supplies "stacked" (positive of Power-supply-1 connected to negative of Power-supply-2) so they provide -9volts, 0volts and +9volts (or -12, 0, +12 if wanting faster moving motors). Both are shown in the Tortoise manuals. - Nigel

Turn off the DCC track power. Multi-meter set to "continuity buzzer", or if lacking that option, to "resistance". Probe on fixed track rail of turnout, other probe on frog. If turnout is set such that those two rails should connect, then you get "buzz" (or nearly zero ohms resistance). Throw the point motor, and repeat measurement, and continuity should be from the other rail to the frog (and will be the correct way round if the same wheel has gone from the rail to the frog due to the way the blades are set).

From reading the manual, having not done this on a V5, but have been playing with coupler waltzes and loco mounted couplers for a very long time. The value of CVH = 1 , for Function Key 26 Then CV32 changes value from the left of table to the right of table, so set a new value for CV32, before setting CVN=64 Next Page 85, where you found the CV246/247/248 the section ends by saying that a function output has to be setup..... if things don't work yet, then they really mean it - an output is required ! In the function mapping, set an output (probably one not in use, and even not with a connected pin on the decoder) on the row as well, eg. Aux8 which is in CVL=2 (check the CV32 value before setting, should be same as CVN for that row). Then, to Pages 79-83. Unless there's a motor driving a coupler, the output isn't really being used, the values may not matter too much, but may need actually setting to something. Page 79 says CV31=16, CV32=0 before setting one of the outputs to Coupling behaviour in the Select Mode column, eg. if picking output "aux8", then its CV331=28 (see Page 82 for the value of 28) Then, need to set the "switch off delay" and "automatic switch off", which (back to Page 79) are, for the row with Aux8, CV332, CV333. And Page 83 read across, and "Special CV1" for coupler strength (back to Page 79, and the Aux8 row) which is CV335 That may help....

Further to the above, the only Gaugemaster decoder in JMRI is the DCC25 as Izzy reports above. It's partly for the reasons Keith mentions; Gaugemaster are a small local supplier to a little island off the coast of Europe, not an international player. And if the people who write decoder files don't use their products, they're not that likely to be written up. Most (all?) Gaugemaster decoders are rebadged from other makers, some current ones being rebadged Digitrax items, so the matching decoder in the Digitax listing will do the job. And, because of that, it would be pretty quick for someone who wanted to add the Gaugemaster Ruby range to do so - find the relevant Digitrax file (its XML, so readable in any decent text editor), change the handful of parameters which identify the decoder as "Gaugemaster" rather than "Digitrax", and its probably done - submit to JMRI and the person has become a new contributor to the JMRI project. Sorry to hear the news about Mark Gurries that Izzy reports, I hadn't picked it up elsewhere. - Nigel

Whilst some stay-alives can cause programming problems, most do not. Whether you encounter the problem will depend on both the decoder and the programming device. If you can, programming-on-the-main won't encounter these problems, but I have no idea whether ZTC supports that.

That's a "depends" (depends on maker, specific decoder, etc.. etc.. ). As a general rule, a function output on a decoder is "track voltage minus a bit", so around 14volts DC. That is measured to "decoder positive" (blue wire), which is one of the wires in the 8-pin plug. The brightness of any item can be adjusted on most decoders by a PWM setting (so its full volts, but on/off rapidly to appear a lower average volts), but the amount of control varies by decoder maker. The best decoders will have far more outputs than four, and can do various things with some of those additional outputs, such as moving a servo motor between two or three positions. Using those then becomes a matter of imagination and amount of wire/circuitry that you can cram into a vehicle.

If you want the best control, then it costs more than the prices you indicated. So, depends how much you'll compromise. Possibly best: Zimo, ESU, maybe Lenz. Above £30, often nearer £40. A bit cheaper: Train-o-matic (odd name, but pretty good for the price), perhaps £22-£25. Then the rest with a long tail of decreasing quality of performance. Many people seem happy with the cheaper (and poorer performing) decoders, so they do work. But equally, I've known people chuck out those poor performers once they've experienced better (pay twice.... then get decent performance ? That doesn't seem sensible to me! ). An 8-pin decoder plug supports three functions (lights), plus motor control, any "fourth function" will be a wire to connect. - Nigel

If the encoder is suspected, then a squirt of contact cleaner into an encoder may bring it back to working for a while. Most likely it will still need replacing, but gives confirmation before doing the replacement.

What did you do to achieve "resetting the decoder". That could be interpreted in multiple ways. Yes, it sounds like an issue originating at the command station. Could be user-error (or button fault), could be internal fault. Might be layout wiring (the idea of trying of "snubbers" at the far ends of the layout wiring raises its head). - Nigel

I can't find any reference in the DCC specs to a minimum track voltage, and certainly not 14v. So "not following standards for voltage" in the DCC system doesn't appear relevant.

There is RFID support in JMRI, and has been for quite a few years. Supports a number of formats/connections. In addition to Dave's list above, there's also sending in messages using MQTT over WiFi as an alternative to cabled networks. (We're doing that on Burntisland-1883 with RailCom reports, but our detectors might as well be RFID, happy to discuss code/approach if relevant, and we're "local". ). One extremely radical approach for control might be DCC+Ex - that now supports many "motor shields" (aka "boosters), and setting the output of a given "booster" to Analogue (PWM) or Digital. This can be swapped "on the fly", so in principle different parts of a layout could be analogue and others digital (I'd suggest that's going to lead to tears, so don't do it on a layout!). With Analogue, there are issues around crossing PWM boundaries between different "boosters" which will lead to short circuits unless handled carefully (the most recent IoTT video on YouTube discusses this). My recommendation - take a step back and ask "is this a model making project" or "is this an IT project". Because it sounds like it might be an IT project. - Nigel

Yes. (And turn off your Laptop's WiFi - often a key for that on the keyboard - so it doesn't try to connect to other things such as your home network via WiFi)

Can't say what Zimo are doing, but I know another decoder maker is moving to "silent Ack" response, with the circuitry for the Ack part of the decoder, rather than using the motor coils to generate the pulse. That maker is considering also flashing the lighting outputs to indicate something is happening, but a decision on that not yet made. ( I have some prototype decoders to look at from the maker ) - Nigel

It is how the "Select" was meant to work.... For the US market, there were a collection of "Select" downloads one could put onto any Select decoder. BUT those files are totally different to other LokSound files and can't be created by ordinary LokProgrammer owners. So, they're a fixed list provided by ESU, can't create new ones of your own.

If your setup is working for other decoders, then the issue is the new loco/decoder. I assume it runs, since you say you can write to it - that would confirm you've put the decoder in the right-way round ? One possibility is that the model has a very low current motor inside it, and the programming track is a little "deaf", so can't detect the responses. (I'd have hoped that a new Digitrax system was OK on that, but some systems can have problems with some decoders and not detecting the response pulse). There may be clues in the Digitrax online help/knowledgebase to improve programming track response. - Nigel

The only "on the main" reading a Digitrax system can do is to "Transponding" equipped decoders (almost no decoder makers other than Digitrax have transponding). To make it work requires a significant amount of additional Digitrax hardware. Its a tiny niche, and not worth pursuing. Using the DT602, can you read other decoders on the programming track ? If the answer is "no", then you've either got a setup issue in the Digitrax system, or a fault with the programming track output on the DCS210. ( Do NOT connect the programming track outputs to the mainline track outputs, that's a way to blow the transistors on the programming track. The often suggested "create a siding with turnout to mainline" for programming is dangerous - something sitting over the isolation join links programming to main.... So, don't do have a programming siding and don't take the risk... Instead, fully isolated programming track, which does require lifting things on/off that track.) If the answer is "yes", then : a) Can you read those same decoders with JMRI ? if "yes", then your JMRI setup appears to be all correct. b) Start to work out why the MX617 cannot be read.... With the DT602/DCS210 known to be able to read other decoders, then why might a MX617 not read ? Possibly a faulty decoder - rare, but not impossible. Poor electrical contact onto programming track: wire connections, dirty rails. Pickup problems in loco, not enough to stop running, but enough to upset programming. Not enough current coming back from loco for the "ack" pulse. Try the decoder in something else. Wrong programming track "mode". Zimo decoders will usually read with any mode, but probably best with "direct". This is a "divide the problem up" approach - is it the entire programming setup ? is it one loco/decoder ? Is it JMRI ? Prove the DT602/DCS210 works, then prove JMRI works, then prove it works with the specific decoder. JMRI is effectively a smart and fast throttle, it does the same as manually programming with the DT602, just very quickly and keeping a record of what has been done. - Nigel