DCC for Rede Valley

Right from the start I intended to Run the Rede Valley line using Digital Command Control. DCC was something I had absolutely no experience of, so there would be a learning curve, not least which system to choose. The Rede Valley is a large layout, so I knew right from the outset that a DCC starter system simply wouldn’t be up to the job. The size of the layout was one reason for adopting DCC. I really didnt fancy wiring up all those section switches that traditional DC control requires, and I didn’t want to have to explain to a visiting operator all the complexities of driving a train around the layout. From the start simplicity was the watchword, and by and large still is.

I quickly identified some basic requirements:

• To be able to run the layout without need to teach a visiting operator how to switch all the sections etc
• Incorporate sound, both inside locomotives, and be able to have background sound from the landscape the railway passes through
• Allow the possibility of automation to support a solo operator, as most of the time I would be running trains by myself
• Allow up to 5 trains to be operated at any point in time, so that trains can circuit the main line while yards are being shunted
• 4 digit addressing so the DCC number of each engine is the number on the cabside, again keep it simple for the visitor
• Keep operation of turnouts simple (I’d always been used to an electric pen to touch contacts on a track diagram on previous DC control systems)

It quickly became obvious that DCC by itself wasn’t going to do the job and a computer would be needed to support automation. Around this time I discovered the JMRI project and realised that JMRI Panel Pro could potentially support turnout control with a mouse click on a track diagram, would be able to support signalling, and was beginning to develop functionality for automatic train control.

For automation the DCC system would need to know positions of individual trains on the layout, so I knew I needed a system with a PC interface and a feedback system. This immediately ruled out the emerging offerings from Bachmann and Hornby, and the Gaugemaster / MRC Prodigy, which otherwise looked a very functional system for a reasonable price. Research on the JMRI website pointed me to the two heavyweight DCC systems then on the market, Digitrax; and Lenz Digital-Plus. I chose Lenz simply because it seemed to be favoured by UK and European Modellers, while Digitrax was very much a USA favourite. A trip to Hershey in the USA was approaching, and by chance I located a US DCC supplier (DCC Roundhouse) in Hershey. I quickly realised I could buy a Lenz system in the US for around 40% discount on UK prices, so e-mails were exchanged and I returned home with a Lenz Set100, a LI101F PC interface, along with my first feedback module and a number of accessory and locomotive decoders.I acquired an TR150 transformer on ebay to power the system and we were good to go.

The Lenz system was easily attached to the under construction layout, and it became standard practice that each new length of track was wired to the layout as soon as it was laid.

Simplicity has been the rule. A DCC “Control Bus” consisting of 6 cables (2 for track supply; 2 for feedback; and 2 for accessory power) passes around the layout under every baseboard, and through a set of terminal connectors on each baseboard section to allow connection of any track feeds on the board with the track supply and link to any accessory or feedback modules.

My daughter acquired a new laptop ready to head off to university, and a rather aged Compaq desktop became free. Suiddenly the Rede Valley had its own dedicated PC running JMRI panelpro and permanently connected to the layout.

I knew that the one hand held controller supplied with my Lenz set would not be enough, and I began to make plans to run Lenz Expressnet around the layout too, with sockets to plug additional handheld controllers at strategic points. Fortunately a great innovation appeared and saved me from this. WiThrottle.

WiThrottle is an iphone app that allows an iphone or ipod touch to become a handheld wifi model railway controller. It connects to the railway via the JMRI system that i’d already installed on the railway room computer. I’ll describe WiThrottle more completely in another post, but suffice it to say here that I can operate trains wirelessly (two at once on the same phone), and additional operators simply need to have an iphone with the correct app installed to join in an operating session. As far as I can tell there is no limit to the number of phones that can connect simultaneously.

Points are all controlled by Seep point motors connected to LS150 accessory decoder modules. these will also be used to control signals at some point in the future. While the DCC signal to tell a point when to change comes from the track supply, I opted to give the accessory decoders a separate independent power supply. I use an additional Lenz transformer (a TR100 is adequate) connected directly to the “Control Bus”. This means that point motors don’t take power away from locomotives. The Lenz system provides 5 Amps to the track which is fine to run 5 or 6 engines simultaneously. I could see that number being reached once I figured out automatic operation, so decided it was safest to keep the accessory supply out of the equation.  I’ve used JMRI panelpro to build a very rudimentary panel to operate point motors and set routes from the PC

Automation is still a future project. I intend to experiment with infra red train detection. I obtained a number of Heathcote electronics IRDOT2 modules on e-bay, and these will be placed at train stopping points around the layout. I plan to attach the IRDOT detectors to Lenz LR101 feedback modules, and use some of the block occupancy and automatic throttle functions in JMRI. More recently I’ve acquired a number of block detection sensors manufactured by LDT. These RS-8-F units feed power to individual block sections and report occupancy directly to the feedback bus. Each module powers 8 sections and so far I’ve acquired 6 of them, enough for 48 block sections in total, however actually fitting these is going to be a major exercise in rewiring and some track alteration to incorporate isolation between blocks.

One of the great strengths of JMRI is Decoder Pro, which allows a locomotive decoder to be programmed through the PC and allows easy access to all the c.v. functions on the chip. Seeing all the chip functions on a PC sereen beats the LCD display of the handheld Lenz controller any day. I use a SPROG connected to a portable programming track to programme decoders. Details of the programming track can be found here.The SPROG can be used with any PC with JMRI installed, so I tend to use my MacBook, rather than do this job in the railway room. Basic instructions on chip programming with DecoderPro canbe found here The MacBook and my work laptop are also used to work on JMRI panels.

All my PCs are connected to Dropbox, a cloud based remote file storage and synchronization tool. Each PC has a local Dropbox folder, and the contents of the folder automatically synchronize with the  cloud, I keep all my current files, plus the user directory and locomotive roster for JMRI within Dropbox, the practical upshot of this is that all machines automatically have the latest versions of all files. Any work done on JMRI outside the railway room automatically arrives on the railway room PC as soon as it is switched on and connects to the internet.

Have I made any mistakes?

Yes, and there are a couple of things I’d do differently if I was starting again

1) The DCC power bus: I now know that the cable standard I adopted for the layout is not good enough. Yes, I did follow advice at the time, and the cable I’ve used is suitable to carry the 5amps a DCC system will require at peak load, but the cable I chose is really only suitable for small to medium layouts. Don’t get me wrong, there is no problem resulting from it right now and everything works the way it should. The potential problem could be voltage drop, due to the long distance of the cable runs, and inductance between the two separate cables corrupting the DCC signal with noise. Fortunately the solution if I choose to do so will be reasonably straightforward: Replace the bus wires with domestic mains cable, probably the 2.5mm stuff, and twist the cable as it passes around the layout to form what is known in the IT industry as a “twisted pair”. The thick cable will prevent voltage loss, and the twists will prevent inductance.

2) Modify all the electrofrog points prior to laying, so that the point blades aren’t relied upon to power the frog – I’m suffering real problems with this, and secondly ensure that each point blade is permanently polarised in the same way as the track next to it. A standard point will have both blades the same polarity all the time. In DC this doesnt provide too great a problem, as any short circuit caused by a bogie wheel off the track or poor wheel standards  wont shut the layout down, in DCC such a short circuit causes the control system to cut out. Up to now this hasn’t been a big issue and shorts on the rede valley are rare, but as time moves on and my standards get higher I’d really like to do as much as possible to eliminate the potential problem. I’m beginning to experiment with sound chips, and these can reset to start up mode when DCC signal returns after the  short circuit is reset, which is not always what you want to happen!

I’d encourage anyone new to DCC to get a good book. The ones below are among the best