Nigelcliffe

As you say the DS64 doesn't offer this directly, then, simplest I can think of, with no "build your own electronics" would be a Relay on the outputs of the DS64. The Relay would connect between a turnout output (eg. 1R) and the common positive, and would energise in one direction only of the DS64. Alternative to the Relay would be a transistor switch (eg. Mosfet module from various online sellers), again energised by one output of the DS64. There will be accessory devices which do exactly what is required, but I'd usually "build my own" rather than buy a commercial unit. A decent DCC retailer ought to know what various products do, and the requirement for the GF board is pretty simple - connect two contacts and allow a low current to flow, or release those contacts.

Voltage divider resistors (as drawn) don't really work for this, because you need to match their chosen values to the power drawn by the motor. You'll end up with very fat low ohm-value resistors and possibly needing to keep them cool, so won't be possible inside a loco. Ideally use a low voltage power supply, and if you're running on DC, that's the way to go - arrange to switch in a different speed controller when using those locomotives. If using DCC, then there are a handful of decoders around which are designed for low-voltage motors (Zimo have one announced for release, D&H make one, CT (defunct) used to have some, there are probably others). A common dodge used by some (including some loco manufacturers) is to fit a resistor in series with the motor. That's likely to work without causing too much heat inside the model. Those motors work well with radio control equipment and a circa 4v battery, and a suitable radio-control speed controller. I have one in an open-sided Wickham Trolley in 4mm scale.

Wrong information unless the sound decoder dates from before ~2012. Way back, a dozen years ago, some ESU v3.5 decoders would be built in such a way that a reset returned them to "ex factory" rather than "ex sound file developer". ESU fixed that in their sound creation software a very long time ago. And even if the decoder is a dozen years old, and one of those which will be "reset ex factory" , it doesn't "wipe the sound files", it just changes a number of CVs that would need to be re-entered to make the sounds play.

Still unsure what you're asking. However, keeping things really simple... 1) Use the existing switch/controller for turntable rotation. Anything else makes it more complex. 2) Need to reverse the track power feed wires (yellow on the examples I've seen) as the turntable rotates, otherwise after turning, the loco will "short" as it leaves the turntable to the regular track. This is done with some sort of change-over switch. Cheapest is a double-pole change over operated manually, or simpler in use would be an "auto reversing" circuit bought from a DCC supplier which changes automatically (there are several brands, and what works will depend on your DCC system - the reverser needs to be faster than the short-circuit protection on your DCC system).

What resistors were present on the locomotive PCB which has been removed ? That gives you the answer....

Not really correct, and an excessively pessimistic view of the what is possible and normal for a sound decoder. There are two basic ways of getting the rate of cylinder movement from the model: - one is difficult to fit to many models - a timing switch (usually done with a hall-sensor) on the axle feeding into the decoder, tends to be more practical at 7mm scale and upwards. - the easier method is by measuring the motor speed from the BEMF algorithm: the motor is control in decoders a lot more complex than "turn up the volts". Decent sound decoders offer both of these options (ESU, Zimo, D&H, etc.. etc), and have done so for ages. The decoder makers publish manuals which include the settings to alter the decoder to match the specific installation (motor choice, gearing, etc.. ). I can get four chuffs per revolution from a decoder over a range of speeds in a huge variety of models (2mm scale, 4mm scale, 7mm scale). It takes a bit of time to setup the values, but once set for a particular model it remains set and will still work exactly the same on that model years later.

I've been fitting sound to UK prototype locos for approx 15 years. Generally Zimo or ESU chips, with a few cases of "others". Steam have always been 4-chuffs-per-revolution (2-cylinder locomotives), with a small difference in emphasis/sound on each (because standing trackside will give a difference). They'll always "coast" with just rod-noises, representing the regulator being shut, and thus slow and stop with just rod-clank and the odd wheeze - certainly don't "chuff to a stop". Low speed chuffing rate would be set extremely carefully, so at all lower speeds there are precisely the four-per-revolution. There is a reproduction issue at high running speeds, even with different chuff recordings at different speeds (which will improve things), eventually the sounds will appear to merge into a mush. The pragmatic solution is to slightly reduce the frequency of chuffs at higher speed; decoders usually have things to do this. Most people can't tell that's happening as the model's movement is too fast to attribute individual noises to wheel/rod movement (plus one is usually viewing a fast running locomotive at a distance, when the sound of the real thing would be changed further by observation distances). I've had the benefit of building models which are used by current drivers of real steam locomotives. They will say if things are wrong. There always has been a large toy-train element in model railways, I guess DCB has tripped over one of those.

Agreed. In general, using DCC power as basic power is expensive, but there are niche cases where it makes sense. With the DC output powering things, fit something to control the back-emf from the electromagnet(s). Otherwise the control button will burn out rather rapidly. The control of back-emf could be: a "squelch" diode over the electromagnet, or; a DC transistor switching device, such as a "Mosfet" circuit available from Ebay/Amazon/etc..

Cheap and DCC++ and physical knobs: 1 - design/build own device to connect to DCC++. There are a few ideas out there which would be a starter. 2 - USB "OTG" cable, and a physical volume USB encoder device. That plugs into an Android Phone/Tablet. With the EngineDriver App (probably the one already used for DCC++), the Volume and buttons give you speed/direction, loco selection is still on phone touch screen. Cost about £20-30 in bits and pieces, assuming you have the phone/tablet. Cheap and physical knobs: MERG DCC system, but its DIY build. Cheap and physical knobs: Pick something up second hand.

Impossible for me to diagnose from the information provided. However, you could try JMRI 5.7.x (the "test releases") which would rule out the bug you report. There are other things to check: Look in "preferences/defaults" to see that buttons look correctly "ticked". That you are trying to "program" and not "edit" the decoder information ("edit" is editing the locally stored file, not doing anything to the decoder) And probably other setup issues. And then can move on to trying commands manually to see if hardware is working.

Servo with appropriate movement reduction mechanism. These days I'd design and 3D print my own, to get the mechanical movement required from (almost) full-throw of the servo motor. Commercially, the Dingo Servo Mounts would be where I'd direct someone to look. I'd try to avoid servo mechanisms where the servo has to be set to only move a few degrees - too many risks that something causes an over-shoot or twitch, leading to a large movement angle and damaging mechanism or signal.

Given what you've spent in time and money on an Alan Gibson kit and a Portescap motor... Do you think it sensible to use the cheapest any-old-tat decoder you can find, or should you fit something of equivalent quality to the rest of the model ? Personally I'd use a Zimo decoder. It will work properly. Expect to pay around £35 these days, though you may strike lucky and pick up some older stock items for a bit less. Some Bachmann badged decoders are made by Zimo (it will say that it is made by Zimo on the packaging, if it doesn't say that, it isn't one of those). And, for the ultimate in smooth control, I'd recommend adding a stay-alive module to the decoder. It will make a difference to running quality - you take an already superb model and push it up another notch in smoothness and reliability. ( I used to fit decoder's and stay-alive's to the late John Watson's 7mm locomotives, see various MRJ articles on his models. There was a G6 in the collection, almost certainly starting out as an Gibson kit. ). You don't need an 8-pin, unless you also plan to wire in an 8-pin socket, so chances are you need a "wires only" decoder and hard-wire it (four wire connections - two pickup wires and two motor wires). It is often as simple to get an 8-pin and cut the plug off as part of wiring. A Hornby DCC controller will work. Not the best thing there is, but the command station side of things has less impact on running quality, is more "user feel" of how the controls work.

All stuff gets obsolete eventually. What's the specific issue ? This page says your MacOS version is fine for now. https://www.jmri.org/install/MacOSX.shtml There is a bug in JMRI 5.6 which affects some MacOS versions with Sprog. It is fixed in test release 5.7.1

In principle, any booster that accepts a low power DCC signal as input. Its on two of the four wires in the "control bus" from the CS02. You may also need a "ground" wire to deal with short circuits, depends on details of booster(s) used. I suggest you research the details carefully, as I'm sure there will be ways to blow things up if done wrongly.

Still not enough "wobble" to cause me to worry. The voltage is well within what I'd expect of any system: movement of at most 0.4v, and that assumes the readings are accurate (don't know the specification of the devices used within the z21 to get those measurements). . Current fluctuation is very small, and if there is a loco running, that's going to be the cause of those changes.

Perhaps re-read your thread postings - first posting, title and content ambiguous as to what its about. second posting, reveals you have an ECoS system, which is a pretty fundamental point in understanding the question, let alone giving an answer. For a long while, RailCom-Plus was a proprietary ESU+Lenz affair, with ESU demanding that anyone else using it would hand over lots of technical details of their products to ESU - clearly other manufacturers were not going to do that. There is now a RailCommunity Standard on data exchange, but even within that I think there's a fair amount of "manufacturer can do their own thing". Zimo published details of where they saw their implementation heading about 18 months ago.

The "lock" is purely a tie between the file and the serial number of the decoder (each decoder has a unique serial number). If you still have a "locked" sound file stored on computer, you can only load it onto the specific serial-number of decoder. If you load a new sound file onto a decoder, it replaces an existing sound file (locked or unlocked, doesn't matter what was on the decoder previously). As the downloads from ESU's website are not locked, then anything installed is also not locked (unless you choose to modify a download file to make it "locked" as an experiment in how the locking mechanism works).

You skipped out " Purchase ESU LokProgrammer Hardware Device and connect to your Windows computer " Its probably cost-effective for anyone in a club to arrange for sharing one LokProgrammer around the club.

Cheapest DCC Sound - "Virtual Sound Decoder", which is a component within JMRI. Free. Plays out either through computer speakers, or through Android throttle running Engine Driver.

I've seen glitches which involve the protocols available (CV12). It may be worth experimenting with those, turning off the "not needed" ones. (The glitches I saw with those were affecting RailCom behaviour, not power management ). Otherwise, suggest a support email to Zimo, they usually answer if your issue is explained clearly.

Pedantically, there is only "JMRI". PanelPro and DecoderPro are just different starting screens of the same software, and all of the features of either are available from either starting place - just traverse the menu structures to get the different commands. One can setup different preferences for the starting places (so things then do behave differently), or even have multiple different preferences (profiles). Rob - regularly take a backup copy of the SD card in your PI. They do go "squit" sometimes, and the backup copy means you can put that onto a new SD card and be back where you were. A better option for a regularly used system is a SSD disc drive, but I think that's only practical on a Pi-4 processor. The Pi-5 has some teething issues over JMRI compatibility (along with numerous other software package compatibility issues), its getting there, but may be a little flakey for some users. - Nigel (who designed the roster view, which is the starting page listing locomotives, in "DecoderPro" ).

The key with thinned flanges is extending (or creating new) bearing blocks so the wheels are adequately supported. A different axle length is a very small matter in comparison to the bearings. - Nigel

You need the decoder manuals, different decoders will do things differently. Then, relate the relevant CV changes to how to make those changes on your PowerCab handset. Ideally you also need documentation from the provider of the specific sound file loaded in the decoder (otherwise you've no idea where to start*) For many decoders, it is incredibly complicated button-pushing-madness-inducing-insanity to do it on a handset. Yes, its possible if you're very methodical, but its much simpler with a computer interface and software (eg. JMRI) to help with things. (* unless you read all the CVs and work out the initial setup, which brings me back to "use a computer" to help...). - Nigel

Coastal DCC have a shop, with demonstration facilities (part of a larger building shared with Orwell Model Railways). Car park spaces on the forecourt. For any retailer, it is sensible to contact in advance to be sure the relevant expert will be present with time available for the customer.

Compare with TCS UWT-50 (I prefer the 50 over the UWT-100). I think as handset designs, the TCS units are amongst the best on sale. But, as with everything, need to check/create suitable infrastructure in the layout to use them. The trouble with any handset design work is the cost of manufacturing them. Plastics/hardware are expensive for the numbers likely to be sold for for model railway controllers. ( I used to work in the design of phones, biggest difference to model railway controllers being the numbers likely to be sold. Which in turn relates to cost to make, and budget available for design work ). - Nigel