Arduino Controls and a Simple Throttle

Having covered the motor control and the sensors, my next step in creating the automated two tram controller was to deal with the very small number of controls I need to have. In my original design, the plan was to have just three pushbuttons:

- Run: when pressed, the trains would start to move.
- Park: when pressed, the trains would return to their starting locations so the system could be turned off.
- Emergency Stop: when pressed, the trains would come to an immediate stop until run was pressed again.

And all three were to be “on when pressed, off when released” pushbutton switches. I was already thinking this needed to be changed, and when I started playing with switches I became even more convinced.

There are two benefits to using toggles versus “on while held” button switches: first, I eliminate a switch, since I need two toggles rather than three pushbuttons. Second, I avoid using those pushbuttons, which have proven to be problematic in my testing. They tend to “bounce” for a long time, and they may remain “on” only for a fairly brief time, making it hard to avoid all bounces and still reliably tell that they were pressed in the first place.

The other control I wanted to add was a way to customize the top speed of a train (or trains, really), so the different models could be made to run at similar (and prototypical) speeds. I don’t want one train rocketing down the tracks while the other creeps along, even if they have very different motors and gear-trains. So I’m going to add a pair of potentiometers, used as “tram #1 max speed” and “tram #2 max speed” controls. And note that these are for the trains, not the motor shield A/B outputs. At various times each tram will be controlled by one or the other.

My first step was to create a simple throttle that used one pot, three switches, and one motor control to run a train on a simple test track. This gives me a proof-of-concept example that ensures I really understand what I think I understand (always a concern with me and electronics).

Arduino CPUs and Motor Shields

I’m still playing with Arduinos this week, but the little beasties are multiplying. That’s partly because I want to be able to test with the various CPU architectures, but also because each has unique strengths and weaknesses, and I’m still evaluating which of them is going to be the right choice for my tram controller. At the same time, it turns out that there are a number of options for motor shields, as I mentioned last time, and they too have strengths and weaknesses.

Revisiting Arduino

Two years ago I wrote about my plans to use an Arduino to control a pair of trams on a double-track line sharing single-track stations at each end, replicating the design of the Tōkyū Setagaya line. That’s briefly written up in that earlier post, and I also have a full page about the project that goes into more detail, with a sub-page about the current testing work.

Back then I bought an Arduino Mega 2560 and a bunch of other parts including a “shield” used to drive DC motors, loaded the basic test program that blinks a LED into it just to convince myself I could do it and the hardware worked, and then put it on a shelf for “later”. And forgot all about it while I worked on other things, only infrequently looking at the empty tram tracks and thinking “I really should figure out how to make that work.” It’s not like I dislike the work: I enjoy both programming and soldering simple circuits together. I just never could work myself up to starting what I expected to be a fairly major project. It was always: “I’ll work on that after I finish project ‘X’”, but there was always another “X” to occupy me.

Corrected PWM

Update (3/29/13): The “percent of maximum” numbers are all wrong. I’m never going to get this right. I need to go back and recalculate those, but that’s not happened yet. When it does, I’ll correct this post (and maybe make another one).


I really thought I was going to be done with PWM and back to working on decoders this week. But, as is now noted on the last post, I got it wrong. As I mentioned then: “I’m not an electrical engineer. I think I know what I’m talking about, and my conclusions appear to line up with observed reality. But I could have fallen down the rabbit hole and just not noticed. Take it all with due caution and a grain of salt.” Yep, down the rabbit hole I went.

So, as Bullwinkle used to say, “this time for sure!”. Well, sort of. I’ve fixed my problems, but my model isn’t an exact one. For the details of that, and what conclusions I can draw from what I have, read on.

More About PWM

Update 3/16/13: Ok, my graphs (and some conclusions drawn from them) had a serious flaw. I’d modeled both the growth and decay curves incorrectly, and this caused current to drop to zero in a lot of situations where it wouldn’t have. Don provided an interesting simulator model, which led me to do some more reading and correct my model. It’s still not complete, but rather than re-do this post, I’m adding a new one that is the correction. I’ll leave this one here for history’s sake, but please see the new one.

PWM Motor Control

DC motors are controlled by varying the voltage and polarity of the DC power connected to them. In a simple DC power-pack a rheostat is used to provide a voltage to the track that varies from zero volts to the power pack’s maximum, which is often around 16 Volts. A simple switch is used to swap the positive and negative outputs to change the polarity (and thus the direction the motor turns). This tends to waste a lot of power as heat, but since that’s happening inside the power pack (and “a lot” isn’t really all that much at these voltages) that’s acceptable.

DCC decoders need to take a constant-voltage AC input from the rails, and control a DC motor somehow. Even if they could use a rheostat, wasting power as heat inside a plastic model is more problematic. The technique normally used instead is called Pulse-Width Modulation, and it’s a fairly simple and commonplace, and efficient, method of controlling DC motors from a digital controller. The same technique is used in many other applications. Read More...

Decoder Wars II - Lightboards

Comparing decoders for cab cars is actually relatively simple. These don’t need to do very much, so it’s really about checking basic functionality. I’ve laid out the full testing details on my Decoder Comparison Testing page, and here I’m going to summarize the findings for the capabilities of interest to me.

Wired Decoders II

Although the rest of my decoder order still hadn’t arrived, I decided to start work on my first wire-in motor decoder, to let me get some experience with the installation process, and to do some more experimentation. I used the Micro Ace Sobu E231 as previously planned, and to start with, a DZ125 decoder from Digitrax.

Plans for an Arduino-based Tram Controller

Today I want to mention one of my other projects: the control system for the Tram line of the Urban Station scene. Now this is a simple, short, out-and-back line, which exists mainly to give me an excuse to buy some of the Tōkyū Setagaya line light-rail vehicles (see the Tram section of my Roster) and to experiment with Tomix’s mini-rail Finetrack. So far I’ve run this manually, with a Kato powerpack. But I want to automate it, since the trams are just supposed to be background activity to make the station look busier, as I concentrate on running my commuter and express EMUs and freight trains.

The problem I had was that I wanted to replicate a two-track line with unidirectional running, and a single track station at each end that let the trains switch between the two tracks, and I wanted to do this with more than one tram running at a time. The track I’m using has slip switches, which allow a train to run through them even with the switch set against it. This lets me leave the switch in one position, and have a train enter the end station from one track and leave on the other, without any switch-control needed. Read More...