Enlightenment for Hartmut

There's something very romantic about a lighted passenger train passing through the night. Mysterious voyagers on their way to mysterious destinations, seen briefly as they cross the night-silent countryside.

It looks good on the garden railway too, a train chugging along in the dark garden. You can imagine yourself standing on a hillside, the rural tortillard trundling through the night, taking a few sleepy farmers home from the market. So it has been my goal since the beginning to have all the passenger trains illuminated.

Two of them I did a while back, but the third was still waiting. The engine is the LGB Saxon IV K 0-4-4-0 Mallett, which we christened Hartmut - alongside his bigger brother Helmut, the big 0-6-6-0 Mallet (2085D) of uncertain prototype. He has an authentic train of three coaches from the Royal Saxon Railway.

The first two trains are Thomas, with his coaches Annie and Clarabel, and Marcel with his two French coaches. In Thomas's case, it was partly driven by necessity. He has completely rigid wheels, with no vertical freedom of movement. He would constantly get stuck because often only one wheel is in contact with the rail on one side. Between dirty track and intentional dead sections - for example, on points - that can just never work. The solution was to adapt one of the coaches to collect power too, and run a cable to the engine. While I was at it, it seemed simple enough to add lighting as well.

So Thomas, and each of his coaches, have 4-pin JST connectors to form a link throughout the train. The first coach has LGB pickups on both axles, and metal wheels. In the roof are a couple of 6V grain of wheat bulbs in series, from Micromark.

Inside Thomas is a buck converter from eBay that reduces the 18V track power to something suitable to drive the lights. In real life there were just a couple of oil lamps, lit at dusk by the guard, very different from the bright fluorescent lamps in modern trains. You wouldn't be able to read, you'd just about be able to make out your neighbours' features - should you want to. Running the nominal 12V light chain on 9V gives just the right dim, yellowish gloom. The lights are controlled by the DCC decoder in the engine, meaning you have to remember to turn them on.

When I first installed the lights in Marcel's train, I didn't bother with the power pickup in the coaches, since he is an LGB engine with pick-up skates and some vertical flexibility to the wheels. But even so he sometimes has trouble especially on the siding pointwork. When I restored him to operation after his lengthy service as a guinea pig for my intelligent locomotive experiments, I added power pickup to the first of his coaches. Apart from that, the setup is identical to Thomas.

One thing I realised is that there's no point in being able to control the lights. During the day, and even quite a long way into twilight, they are invisible, so it's harmless to have them on. And at night, you always want them on. That means there's no need to connect to the locomotive, which simplifies things a lot. Instead I fitted power pickups on the first coach. This also meant I could use smaller 2-pin JST connectors, which are easier to connect between the coaches and less likely to get in the way of the couplings.

The grain of wheat bulbs work well enough but they are a pain to install. On the web I saw some LED light strips for LGB coaches, so I bought three of them. In fact they are just short segments of readily-available LED ribbon, with six LEDs, together with some connectors and a big (8200µF) capacitor for each one, so they don't flicker on dirty track. It would have been a lot cheaper and just as simple to have bought a 6-foot length of ribbon.

To finish the job needed a little eBay buck converter hidden on the floor of the coach, to turn the track power into something suitable for the LEDs. It turned out that 9V was just right for them, too. I used one of the 8200µF capacitors, so dirty track has no effect. The lights stay on for about 10 seconds even when the track power is turned off completely.

The little circuit board with (left to right) the big reservoir
capacitor, the voltage reduction board, and the
bridge rectifier.

In real life all trains carried - and still do - a red tail lamp. This is very important because it makes it easy to see whether part of the train has gone missing. The signalmen had to watch each train carefully to be sure the light was still there, day or night. If not, it was time to send an urgent message - a bell code of 4-5 in UK practice - to the previous signal box, so another train wasn't cleared to run into whatever was left behind. It has been on my list for a while to add a tail lamp to the long goods train, so I thought Hartmut's train should have one too.

The under-body wiring, with the wheels on the left side
removed.

In my box of LGB bits and pieces I found an LGB tail lamp. It's designed to clip on to a vehicle, and fits perfectly onto the veranda of Hartmut's coach. Whether that is the prototypically correct position, I have no idea. I searched for a picture of the tail end of an old-fashioned German passenger train, but to no avail. Goods trains evidently carried two tail lamps, one on each side as high as possible. The lamp comes with a bulb in a huge brass holder, that would be very conspicuous. I replaced it with a red LED, the wiring concealed behind the veranda. The wiring hides a 2K2 resistor which reduces the LED's brightness, though having watched the train at night, I think a higher value (lower current, less light) would have been better.

The LED strip installed in the roof, secured in place with two
little bridges of Sugru.

One unexpected problem I ran into is that the LED strips kept falling off the roof. They have double-sided sticky tape on the back, but it clearly wasn't up to the job. I added a layer of double-sided sticky foam, and then made little bridges of Sugru to be doubly sure. If you haven't used it, Sugru is wonderful stuff. It's a bit like epoxy putty, but much simpler to use since it doesn't have to be mixed. You open up a little foil envelope, take out a piece the size of the end of your thumb, and mould it to whatever shape you need. It is set reasonably hard after a few hours, and completely after 24 hours or so. And it lasts for ever. The first thing I ever used it for was to hold a heavy soap rack in place in the shower. After several years it is as strong as ever. I used quite a bit more to hold wires in place, especially underneath the carriages.

I put Hartmut and his train back together, keen to see them trundling around in the twilight. But I was disappointed. The lights came on, but Hartmut showed no signs of mobility. On the bench I discovered that his Zimo DCC decoder, which he has had since I first got him nearly 20 years ago, had died. Luckily I had a spare, but on that one the light outputs seem to be non-functional. Since Hartmut only ever goes in one direction, I just hot-wired the front lights to be on all the time. Running at night, I noticed that the interior light in the cab is way too bright, so that will need a resistor added somewhere.

After all that, Hartmut and his train are lit up like the others. They look very good and slightly mysterious as he chuffs slowly round the layout in the dark.

Hartmut and his train by twilight

Flowers for Marcel - the end of my intelligent locomotive experiment

This weekend I finally abandoned my attempt to build an intelligent, "internet of things" locomotive for my garden railway. It was a very disappointing decision, because it so nearly worked. It worked on the bench, but the realities of a garden railway with dirty track, poor connections and so on meant that it was never reliable outside.

I'd chosen the most reliable and simplest of all my LGB locomotives, the Corpet-Loubet 0-6-0. This was the first one I ever bought, back in 1999, and had given perfect, trouble-free service ever since, using a Zimo decoder for DCC.

Objectives

The objectives for the project were:

1. 100% compatibility with DCC - the loco should work on my DCC-enabled layout exactly like any other
2. tight feedback control over speed, so the selected speed would be maintained regardless of load or layout voltage variations
3. "non stop" operation to keep the loco moving over dirty track, dead spots and so on, using a substantial super-capacitor
4. constant status reporting over WiFi of several things including motor current, track voltage and distance travelled
5. in addition to DCC control, the ability to control speed, accessories, CV settings and everything else over WiFi

Design

I selected the Particle Photon as the microprocessor. It is about the size of a USB memory stick, yet has a powerful ARM processor running at 125 MHz and, built-in WiFi. My earlier experiments with adding WiFi to the Arduino had been a painful failure, so this was extremely important. Another important advantage is that the libraries are a superset of the Arduino. As it turns out, however, it isn't really suited to this job - more on that later.

To meet the first requirement, I needed an implementation of a DCC decoder. Fortunately there is a very nice one out there, NmraDcc. It's written for the Arduino, but needed only one small change to run on the Photon - because the Photon does not support hardware timer interrupts. You write functions to handle speed changes, accessory operations and so on, and it calls them when the corresponding DCC commands are received.

For a computer to be useful, it needs to communicate with the world around it. I needed the following inputs:

1. Track voltage (analog)
2. Internal power supply voltage (analog)
3. Supercap voltage (analog)
4. Motor current (analog)
5. Motor back-EMF, used to measure speed and hence keep it constant (analog)
6. Axle position sensor, used to measure absolute train position (digital)
7. DCC signal, via opto-coupler from track voltage (digital)
8. Motor control signal feedback (digital)
9. Motor over-current (digital)
10. Accessory over-current (digital)

and the following outputs, all digital:

1. Control signal to motor control FET, operated via built-in pulse width modulation (PWM)
2. Control to motor reversing relay
3. Accessory outputs, as many as possible (limited by number of available GPIO pins)

The first thing to get right was the power supply. The non-stop feature is built using two 30F 2.7V supercaps in series, giving a 5.4V 15F capacitor. This is kept charged by a tiny buck regulator from Ebay, adjusted to give a constant 5.3V output. It has built-in current limiting to 1A. When the loco is placed on the track it takes about a minute for the cap to charge. A 3A boost regulator, also from Ebay, then turns the 5.3V back into 16V to run the motor. An arrangement of hefty Schottky diodes (chosen because of the lower voltage drop) normally takes current direct from the track, but as soon as the track voltage drops below 16V, the supercap provides the power. This arrangement is also used on my LGB track cleaner, where it works perfectly.

The power supply to the microprocessor comes via a second Ebay buck regulator, that drops the supply voltage to 12V for the accessories (lights etc), then a 7805 linear regulator that provides a stable 5V supply. At least, it is supposed to, though that turned out to be one of the weak spots of the design.

The motor is controlled via a power Mosfet, an IFR9540 that can happily switch 20 amps. Reversing uses a relay. The conventional way to control a motor these days is via an H-bridge (e.g. an L298) but I couldn't see how to get the back EMF this way, so I went for a relay instead. (I did think of a way later but by then I had built the board).

The analog inputs are first scaled by a couple of resistors, so they will never be more than the 3.3V input range of the CPU, then connected to it via a 4K7 resistor. This ought to protect the CPU, but experience showed that it doesn't.

The digital outputs are buffered via 4K7 resistors to an ULN2804 8-way Darlington. The accessory outputs, of which there are 6, are taken to a terminal block.

Software

That just leaves the software. There are several components to this:

1. DCC decoder, using NmraDcc
2. Basic motor and accessory control, turning the intended speed into a PWM ratio to control the motor voltage, direction into the sense of the reversing relay, and setting the accessory outputs
3. Feedback-based motor control, reading the actual speed and adjusting the motor voltage so it matches the intended speed
4. WiFi interface, sending and receiving messages.
5. Generating status messages
6. Interpreting commands received by WiFi

I invented a log format, which is sent once per second and includes not only the items to be monitored but also various internal variables that show how the motor feedback calculations are working. These messages are sent to an IP multicast address, so the loco does not need to be configured for where to send them. They contain the IP address of the loco, which can be used for sending commands back to it. A simple Python program listens to the messages and logs them, and allows commands to be typed and sent to the loco.

Speed Control

The hard part of the software is the feedback based speed control. The concept is simple enough: measure the actual motor speed, and adjust the motor control so that it matches the desired speed as set by the user. It seems simple, but control systems are always a compromise between agility, i.e. responding quickly to changed circumstances, and stability, which most importantly means not oscillating. In this case there's no point if it takes say ten seconds to respond, since the changed circumstances - like going round a tight curve - will likely have gone away.

Motor speed is measured by back EMF, the voltage that all electric motors generate in the opposite direction to the supply. Since the motor is controlled by turning the power on and off, it's straightforward to measure the voltage while no power is applied. A complication is that it is not at all linear with the motor speed, so the software needs to understand the actual relationship.

I also implemented direct speed compensation in response to supply voltage variation. As the supply voltage drops (due for example to dirty track) the motor feed is directly increased in proportion. This sounds like a good idea, but it does lead to problems as described below.

In practice I never found a set of control parameters that really worked. Anything that gave enough agility also led, some of the time, to control oscillation, meaning that the loco sped up and slowed down as it moved along at a constant speed setting.

Photon - the Good, the Bad and the Ugly

The Photon seemed the perfect part to use for the CPU in this project. It has a lot of good points, but in the end the bad points overcome them:

• it takes a long time to start. By default, it not only has to find and log on to the WiFi network, but also set up a connection to its cloud-based server. This can take up to 10 seconds. In the situation where it is rebooting because it has briefly lost power, this is completely hopeless. It's possible to program it to avoid the second part, but it still takes a couple of seconds before it starts running its program again. The PIC processors typically used on DCC decoders are running code within milliseconds, meaning that the outage passes unnoticed.
• it's impossible to run fine grained (microsecond) timers. For some reason to do with the cloud server, again, the finest timer resolution you can get is one millisecond. It would have been good to control the output FET directly in software, but that's impossible. Instead you have to use the on-board PWM, which significantly complicates the software.
• it's electrically very fragile. Even a momentary signal over 5V applied to its inputs, even via a 4K7 resistor - meaning the current is limited to a milliamp - instantly destroys the whole chip.
• it loses its configuration pretty easily - the WiFi credentials and worse, the credentials needed to contact the cloud server. Of the five Photons that gave their lives to this project (see previous point), one in particular lost it every time the software crashed. Reinstalling it is a painful process, requiring a physical USB connection to a computer and a whole series of arcane commands.
• it's very difficult to debug. This is normal for a small embedded processor or Arduino, but the Photon is trying to be one step above this. There's no interactive debugger support, and no way to do "debug with print statements" either. Programs bigger than you could run on an Arduino are just impossible to develop as a result.

The Photon is no doubt a good part to use if there is a rock-solid power supply, it's interfaced only to gentle things using the same stable supply, and the program is pretty simple. But none of those applied in this case.

Practical Experience

The Photon board, carefully trimmed to fit - just! - in the available space.
The CPU is to the right, with the power controller to the left.

I spent a long time - several months, on and off - trying to make this work. Getting all the necessary electronics onto a board that would fit inside the loco was quite a challenge. It looks as though there is loads of room, until you try squeezing all the components in. There is also a fairly severe height limitation, especially at the sides in the water tanks. It would be easy enough using tiny surface mount parts, but they don't lend themselves to prototyping. Instead I used 0.1" stripboard, and a lot of wires.

The first Photon was a victim even before the board was built, when I was testing the basic circuit ideas using plug-in breadboards. Two wires touched and pfff! - the end of the first Photon. Another one died when I foolishly ran the board without it being firmly screwed down in the locomotive, and short-circuited the traces underneath it on some tool on the bench. That did a lot of damage, and not just the CPU. Two more just mysteriously died, for no obvious reason.

The feed-forward in the speed control turns out to have an unfortunate effect on dirty track. As the voltage drops, the loco tries to pull more current, the voltage drops further, and so on. If the initial voltage drop is large enough - i.e. the track is dirty enough - the track voltage drops so low that the loco stops. In the end it's better just to accept the loco slowing down.

There was a similar problem with the non-stop circuit, which is trying to keep its supercap fully charged even if the track voltage is lower than normal. That also leads to the same kind of evil feedback loop.

The biggest problem, though, was with the power supply to the CPU. On the bench, everything worked perfectly. But out on the garden track, no matter how carefully I isolated it, no matter how many smoothing caps I introduced, the CPU would unpredictably reset itself. This wouldn't matter, except that (see above) it then took several seconds before the train would start to move again, if at all.

Lessons Learned

The main thing I learned from this is not to do it again. The benefit is really not worth it. That said, if I did do it again I would;

• use a CPU board that is more of a microprocessor rather than a "cloud of internet of things".
• enforce total galvanic isolation of the CPU from all of the ugly electrical side of things. There are chips available that do this even for analog signals.
• build a power supply for the CPU which is galvanically isolated - there are some neat chips that do this - and protected in every possible way from any kind of electrical ugliness: supercaps to keep it running for tens of seconds, beefy zeners to protect against over-voltage spikes, and so on.

My plan for now is to re-purpose the board I built. It's still useful to have real-time monitoring of the electrical conditions around the track. I plan to put it into one of Marcel's carriages, just as a passive WiFi reporter of track voltage.

The End of the Experiment

Marcel's new simplified electronics - just a Zimo decoder and
a tiny board to make the 9V for the carriage llighting.

I might have persevered for longer, but summer time came round, and Marcel's two French coaches looked lonely sitting in their siding. I really wanted to get him back on the layout and running. It took me just an hour to construct a carrier board for his old Zimo decoder, and a tiny Ebay buck converter to run the lights. Very soon he was chugging happily round the layout with his coaches in tow. He seems extremely happy, and probably very glad to get off my workbench and back outdoors.

Marcel on the layout with his short train of two French coaches