Loch Lochy - DCC Control

THE 1889 PROPOSAL to build the West Highland Line into Fort William included a short branch from Spean Bridge to a loch-side pier on Loch Lochy - a large loch to the south west of Loch Ness in the Great Glen. After negotiation with the Highland Railway over their concerns about the line being extended to Inverness, that part of the plan was dropped. However, several years later an illfated branch line was built by the Invergarry & Fort Augustus Railway, from Spean Bridge to Fort Augustus. It closed on 1st January 1947 and you can still walk part of the long-dismantled line but there was never a pier or station on the shores of Loch Lochy.

The original plans for the proposed line to Loch Lochy by the Highland Railway are available on the National Archives for Scotland website and, interestingly, the original proposal doesn't quite follow the same line as the Fort Augustus branch but was on the south side of the river Spean for most of its route. I overlaid the plan onto a modern OS map and was able to plot where the line would have been built from Spean Bridge to Loch Lochy, including where the pier would have been.

Therefore, this layout is a “what might have been” but is closely based on the style of the West Highland Line.

The addition of the bay platform allows me to satisfy my need for parcels vans but passenger traffic is usually a couple of Mk 1s – typically a BCK with an SO or SK and occasionally a TTA attached to the rear. I also run a Class 122 DMU for local services although I’ve no evidence of one running in that era. However, it’s very convenient to have it shuttling back and forth under automatic control whilst I indulge in some shunting and I don’t think it’s too unlikely that they could have appeared on the line. Motive power is predominantly Heljan Class 20 and 27s (modified from their Class 26s using PRMRP and Vincenzo parts), and JLTRT Class 37s in the 80s. I also use a Judith Edge Class 06 and both a Dapol and an MMP Class 08 for shunting duties. A JLTRT Class 25 makes an occasional visit as I have evidence of them on the West Highland Line.

All are fitted with Zimo DCC decoders and have Peter Clark smoke units wherever there is space. I’m currently experimenting with ultrasonic piezo transducers, which generate a fine water vapour mist and which are quite promising.

The quayside with a small fishing boat moored by the fish factory

The layout is DCC controlled using the Lenz LZV100 command station and the comparatively new LH101 controllers. I have dabbled with other DCC systems but always end up coming back to Lenz because it is just so reliable. Points are controlled with Cobalt motors whilst signals are servo controlled using MegaPoints driver boards from MERG (the Model Electronic Railway Group) of which I have been a member for many years. These boards give you the functionality of the off-the-shelf boards from MegaPoints but in kit form and at a substantial saving. Both points and signals are connected to MERG DCC accessory decoders. In addition, the switches in the Cobalt point motors are connected to either Lenz LR101 Feedback Encoders or LDT RS-16 feedback modules so I get a confirmation that the point motor has moved. This is very useful when it comes to automatic control which I’ll describe shortly. Track occupancy detectors are MERG 8-channel current detectors, which don’t appear to be available currently. It’s surprising that for a comparatively small layout I have 24 block sections but this level of granularity is useful for computer control. The block occupancy detectors are also connected to the feedback encoders along with other peripheral devices and push buttons. This means that all routes, signals, trains and train detection are connected to the DCC system. A typical short West Highland Line train consisting of an SK and a BCK

Having everything connected to a common system allows a lot of flexibility as to how to control the layout. It also makes it very easy to rearrange the configuration as I have a habit of changing and adjusting the setup as I think of better or new ways of achieving things. I could control the layout in a variety of ways: using mimic panels, traditional toggle switches, push buttons, lever frames, DCC handsets (which can be quite unwieldy) or I could use a desktop computer/laptop. Indeed I could use different types of control simultaneously if I wanted. In the end I decided to use a mimic panel at the storage siding end of the line (Spean Bridge) and a computer for Loch Lochy as I wanted to recreate an NX style panel. The downside is having to be reliant on a computer for route setting, but I thought I could always build a mimic panel with point control if it became an issue. In practice it never has, and I now also use the computer for control of layout lighting, and for other purposes such as monitoring power and timetable configuration.

In fact TrainController is so versatile I can use it in different ways depending upon how I want to run the layout. Although the default screen is configured as a pseudo NX panel, whereby you press on-screen buttons to set the start and end of the route, I can also use it in different modes:

• Automatic – Trains can shuttle back and forth from Spean Bridge and Fort William. This is very useful if I have visitors as I can have something running all the time whilst chatting. DMUs are ideal for this but it does require a little modeller’s licence.
• Mixed – DMUs run under automatic schedules but I can manually shunt freight. At any time I can take a route onto the branch and the utomatic schedule pauses. * When the route is cleared the schedule automatically resumes.
• Manual – I can set routes manually and drive trains as desired or to a timetable. Timetables can be configured using a web-based application I wrote, which interfaces to TrainController for interlocking and to train information panels driven by Raspberry Pi computers.

It also connects to the block instruments, which can be operated manually when there are two or more operators; or by a single operator with the Spean Bridge block being automatically controlled by the timetable. In this mode the Spean Bridge block instrument is run by software I developed called ‘Auto Ken’; named after a good friend of mine who is a retired signalling engineer.

In addition, TrainController allows me to control trains either using on-screen throttles, the Lenz handheld controllers or via a mobile device. My preferred option is the Lenz handheld controller as I like having tactile feedback of what I am doing. It’s very difficult to adjust the speed of a train using an on-screen control with a mouse whilst watching the train at the same time.

Moving head lights
There are a few other lights, such as low level LED spotlights, which are used to create long shadows for early morning sun effects, a blinder which is used for bright flashes to simulate lightning, and an old Strand spotlight given to me by an ex-cameraman neighbour. I’ve added a circular gobo (a metal screen used to project a shape) to this to create a moon effect on the back scene. In addition, I’m experimenting with moving headlights to dynamically change lighting effects. Moving head lights have a fixed base but the head projecting the beam can move in different ways. You can control the brightness, the colour, strobe and position of the beam. Some professional moving head lights allow you to create different beam effects (think Strictly Come Dancing) but this is a bit over the top for a model railway!

Arduinos (small single board micro controllers) are used to provide lighting effects on the layout itself, such as random flicker starts for the fluorescent lights in the oil siding, changing the colour of the ‘sodium’ street lights from red to orange when they come on, and making various fires in the signal box and station change from yellow to orange to red as they are lit, burn vigorously and then die down, before the cycle starts again to simulate having more coal put on the fires.

I looked at various options to control the lights but settled on using the DMX lighting protocol. This is the standard for controlling lights in theatres, concert venues, nightclubs, etc. via a digital control signal. I guess you could think of it as DCC for lights. DMX is a separate low voltage control signal which is daisy-chained from light to light and each light has one or more addresses depending upon the functionality. You can have up to 512 addresses in a ‘universe’ but if you run out you can have more universes – more than enough for a model railway.

Some theatre lights have built in DMX decoders whilst others require an external method of interfacing to DMX. All the LED tapes are 12V and I power the lights from computer-type power supplies via DMX dimmers. These dimmers have inputs for 12V DC and DMX, and have five outputs for the LEDs of up to 8 amps each. I originally used 8-bit dimmers but because of the nature of LEDs you could see the step changes in levels when dimming (8 bits equate to 256 steps). Therefore I now use 16 bit dimmers which do not have this issue as they have 65,536 steps. I also use DMX switches for lights that are simply on or off. This is ideal for lights within buildings, platform lights, etc. All the Arduino controlled lighting effects also have their own DMX connections so in this way all the lights on the layout, and those that illuminate the layout, are connected to DMX.

The DMX signal is connected to the computer via a small interface device that converts DMX to USB (or vice versa). There are lots of different software products available to provide a DMX signal but the software I use is by Chamsys and is called MagicQ. This is free software used by lighting designers to plan and pre-visualise lighting for events. It will run on PCs under Windows, Mac and Linux with up to 64 output universes. A 3D visualisation of a lighting design is a feature of the software and in this way the designer can program a complete performance off line, store the design on a USB memory stick, and then take it along to the venue on the day where they can plug it into the actual physical lighting console.

Changes in lighting are stored as cues in the software and in this way a sequence (or ‘chase’) of stored lighting changes can be automatically run through to create whatever sort of lighting effects are required. Therefore I can run a complete sequence from sunrise through to midday sun, an afternoon thunderstorm, a spectacular sunset and a night time with a full moon completely automatically. Alternatively, you can assign lighting channels to on screen faders and control everything manually. DCC to DMX interfaces are available so theoretically TrainController could also control the lighting, although I don’t currently do this. Overall, the software is a steep learning-curve but it does give you incredibly powerful control. Dusk falls on Loch Lochy

Most of the time Loch Lochy is operated by me so I have several small CCTV cameras mounted in the adjacent storage sidings in the shed, and at strategic points along the line, to enable me to see the movement and location of trains from the main operating position in the garage. I use small 7in. TFT LCD monitors that are readily available online and sold as car rear-view camera monitors, or as DVD monitors for rear seat passengers, to view the cameras.

The next problem was that I had more cameras than monitors so I needed a way of being able to view them and, ideally, without me having to press more buttons. After a bit of thought, I wondered whether I could use TrainController to automatically operate the view from each camera as the movement of trains were detected by the block sections. Each camera has a composite video output as opposed to digital IP cameras (which are more expensive), so I needed to find a suitable method of switching the output of the cameras to different monitors. I thought about building something myself but then discovered how cheaply ex-professional video switching matrixes were available. This is because composite video is old technology and everyone moved over to digital a few years ago. However it means that you can pick up these devices for silly money, considering what they would have cost when new. I purchased an old Extron broadcast video and audio matrix switcher very cheaply from a well-known online auction site for the price of a wagon kit. It is capable of switching 32 sources to 32 destinations both in composite video and stereo audio. It even has dual power supplies for resilience – demonstrating its professional design. I knew I would never use all those options but I did think I might outgrow the next smallest I saw which was only 8×8 sources/ destinations. The main benefit of this rather over-specified switching matrix for me though was it that it has an RS232 interface, which means it can be remote-controlled. RS232 is a serial digital data interface that was originally designed in the 1960s but it is fine for this purpose.

The next issue was that I needed to convert the output from TrainController from DCC to RS232 to control the switching matrix. Luckily all the manuals for the Extron matrix are readily available online so I set about designing something based around an Arduino. Although there are switches to control the matrix on the front of it, that is not particularly user friendly, so I thought it would also be good to have an array of push buttons available in a more convenient position where I operate the layout. Therefore the interface gained a number of buttons (48 in the end) so I could control 24 of the 32 sources and destinations, view what sources were switched where, and also make use of the matrix’s inbuilt functionality to store switch configurations. The complete 32 sources and destinations can be switched from TrainController but I thought 24 would be more than enough and a suitable compromise.

The finished product works well and allows TrainController to automatically switch the output from the cameras to the monitors as trains progress down the line; or I can manually override the views as may be required. Since building this system, I’ve discovered just how small some cameras can be and they are ideal for hiding in buildings or other such places around the layout. These are great for giving a real passenger’s eye view which you just couldn’t get otherwise.

I’ve always liked operating with block instruments but the issue was how to integrate that type of operation with TrainController, especially when operating by myself? I wanted a physical type of instrument, rather than something on screen, but at the same time something that gave an operation that was reasonably prototypical for that type of single line.

After a few chats with my friend Ken Gray, a retired signalling engineer, we came up with a form of electronic token block that uses two instruments to allow an exchange of bell codes and the issuing of tokens electronically – physical tokens just wouldn’t be appropriate when operating the layout by myself. Holding down the bell button on an instrument after a sequence of bell codes offers a token to the other instrument and is indicated by a flashing token button light. The token can then be accepted by pressing the token button. Similarly holding down the bell button when a train leaves the section allows the token to be released. The token is effectively just a red light showing that a token has been issued for either an Up or Down train but that is good enough for this application.

The bells are recordings of actual bell instruments stored in small MP3 audio modules which have a surprising amount of storage capacity. This means you can have easily have different bell tones for different locations. I also have the sound of a bell tapper being pressed for the sending instrument to provide a little more realism to the sound of the modern illuminated push button I’ve used.

This works well when there are two people or more operating the layout but how could it work when it was just myself? Clearly it would need some form of integration with TrainController but how best to do it?

Again I decided to connect the instruments to the DCC bus which is really the best way of integrating with TrainController. I built a small control box with an LCD display and an Arduino which allows selection of 16 different trains/bell codes for Down trains (from Spean Bridge). When an Up route is selected within TrainController then the token instrument at Spean Bridge expects the start of a bell sequence from the manually controlled instrument at Loch Lochy. It listens for the bell codes and detects and responds to them appropriately, including the issuing of a token. It will also send a bell code for ‘train out of section’ when the train is detected by the block section as arriving at Spean Bridge, and then release the token on completion of the move.

The opposite process happens when a Down train route is selected in TrainController – the Spean Bridge box will automatically start a bell sequence, request a token and then release the token at the end of the move. The trains still have to be run manually and I’ve no plans to change that – you can take automation too far! However there is an option to provide interlocking back to TrainController, which inhibits any signals being set unless the token has been issued.

The next logical step was to integrate Auto Ken with a timetable so that I could manually run an operating sequence, with me acting as the Loch Lochy box and driving the trains, but with the Spean Bridge box working automatically to a timetable. I also wanted the timetable displayed to operators preferably on a screen that bore some resemblance to the widely used yellow text on black background departure board displays.

I already had an internal website which I use for displaying voltage, current and power consumed from the railway power supplies, along with other things, so it seemed a logical step to expand upon this functionality. I was also using a Microsoft SQL database for various purposes so, over a few evenings, I built a web application based upon this technology to create routes and train types. These routes and train types could then be used to build timetable templates, again via the web front end. A template can then be activated with a specific starting time, which runs in real time, and which is displayed on the timetable display screens for operators. These screens are small colour LCD screens connected to Raspberry Pi computers running web pages in full screen mode and with my desired yellow on black appearance. These are automatically updated every few seconds to reflect changes and updates of the timetable.

If I’m operating by myself then a neat feature is that Auto Ken will work from the timetable. When a Down train is due from Spean Bridge (the storage sidings) Auto Ken will initiate the bell sequence at the appropriate time. The timetable on the database is aware of train movements from tokens being issued by Auto Ken for a specific direction, and also the train types from the bell codes. Therefore if a train movement hasn’t completed within the time scheduled a ‘Delayed’ indication will appear alongside the scheduled train on the display screens. If it all gets too out of hand then a train ‘Cancellation’ can be issued by the signaller (me!).

If I’m not working from a timetable, but by myself with Auto Ken, then the display screens will indicate appropriate trains based upon the bell codes exchanged. It may sound complicated but if you are used to bell working then it would be very familiar. I’ve also tried to write into the program enough contingencies to detect when things may be going wrong and indicate as such.

However, I’ve now reached the programming capacity of the Arduino that I’m using so if I wanted to expand it further I would have to look at other microcontroller options. Train control software

At the end of the day all of this technology is just trying to make operating the model railway more like the real thing and hence more fun. However I try only to use technology where it can make life easier, for example with the CCTV tracking of trains. I have occasionally stopped myself from creating something which would probably have been fun but not enhanced the operation of the layout.

Technology seems to be developing faster than it ever has before and I seem to have a track record of dabbling with new technology as it becomes available, so who knows what the future may hold!