The first step to getting everything running on DCC is to make the Command Station. Or Booster. Or Cab. The terminology starts to fall apart a little bit when you try and apply it to the system that I’m making. So, for this initial portion, I’m going to refer to my laptop as the Cab and the circuit I’m about to describe as the Command Station, with the Booster just not existing. This Command Station is essentially going to be something that can both power an Arduino while modulating the voltages on the track using the L298 h-bridge.

Grabbing a L78M05C because it both matches my needs and was conveniently available at Anchor Electronics, I had everything necessary to make the circuit. If you look at the Design Considerations of the L78M05C datasheet and the Applications section of the L298 datasheet, we’ve pretty much got the whole circuit designed for us. I’m not sure off the top of my head what the values of the capacitors should be if they’re going to be shared between the two chips but we’re not trying to preserve any signals here so we should be able to just slap a larger capacitor in that spot and call it a day. I happen to have several 330μF and 100μF capacitors on hand, so we’ll just use those, and we’re at the stage where pretty much any Schottky diode will work for the flybacks:

Now, to be clear, I technically have a degree in this sort of electronics work but I haven’t touched it in almost ten years. Because of this, I both wildly overestimated my soldering abilities while simultaneously being completely unaware that custom PCBs are now affordable. Last time I looked into custom PCBs, we were talking prices close to $200 just to start production and then $20/board for the first 50 boards, minimum order of 50. I assumed that manually soldering would be the right way to do this and that I would be so much better at it than I am. So, to kick things off right, I attempted to manually figure out the circuit board via pen and paper, assuming I’d be able to fit all of this onto a 1⅞"x1⅞" board. If you can’t tell by the picture below, it didn’t go well.

I started to do a hand-drawn circuit board layout for a board that was double the size, but I quickly realized that I would be much better just admitting that it was time to accept that I needed to learn a new technology and learn me a PCB designing program. If you’re wondering how I made the schematic above without knowing one of these programs, then you’ve caught me in a lie - the schematic was also hand-drawn but I lost it, so this blog contains the schematic I used later.

I decided on KiCad because it was both open source and seemed to be relatively highly recommended, so I installed that and started messing around to get a general feel of how things worked. It seemed pretty clear that blue and red lines were the front and back of the board, the vias looked like holes in the perf board, and the components spoke for themselves, so between that I felt like I was in a position to design the layout. I’m not going to show a picture of it here, partially because I don’t think it’s too interesting, partially because the picture to the left would make the layout of this section pretty bad, but mostly because it’s available in the Gitlab Repository. If you’re really curious about the final schematic, you can find it there.

With the design done, it was time for much swearing, burning of fingers, and general terrible soldering. The end result is pretty ugly but everything works and we’re able to generate the DCC signals that we want to be able to generate. I elected to not include a current sensing diode as I don’t have the bits of track that commonly cause short circuits, so the current Command Center is a bit of a risk to use.

Lets start with the world’s quickest explanation of DCC control. The trains only have two contact points with the rails, the left and right rails, so signals can’t be sent the way most embedded signals happen. I.e., we can’t have a data line that alternates between a high and low value. Instead, we have to alternate which rail is high and which rail is low, generating something that kind of looks like a square wave if you squint a little. The value transmitted by the DCC signal is based on the amount of time between the rising edge of the signal.

The DCC standard states that a 1 nominally has two half periods of 58μs, meaning the time between rising edges for a value of 1 is nominally 116μs. Seem pretty clear, right? Well, most other resources say that the nominal time for a 1 is 106μs, which means that either I don’t understand basic math or some conspiracy is happening (or, maybe more realistically, most places are mistakingly referring to the minimum time period as the nominal, which is incorrect). For a 0, the standard gives a massive range of values in order to enable something called Zero Stretching, but for our purposes we can just use 232μs as the period for 0 in order to make some of the code simpler.

One final thing to mention before we start getting into the Arduino code itself. The DCC specification defines an "idle packet" that can be sent along the rails when there are no other packets to be sent. We’re going to use this packet without talking about what DCC packets look like in general in order to get something up and running quickly - we’ll address the packets themselves later on. If we send the idle packet correctly, the Caltrain’s headlights will turn on and the train won’t move. If we didn’t send the packet correctly, either the train’s lights will stay off or we’ll see the train assume it’s in DC mode and begin to move. Once we have this basic command working, we’ll move on to actually controlling the train and understanding the packets.

We could start by keeping the Arduino code very simple by just writing to the pins and using delayMicroseconds but (1) I don’t think that actually makes the code much cleaner and (2) we’ll very quickly need to move away from that anyway. We need the output of the packet to happen at very specific time intervals, even if the main logic of the Command Center is doing something else, like communicating with the Cab. Using PWM is an option but trying to accurately manage the timing of modifying the width seems like an absolute hell, so we’ll just use timer interrupts.

The Arduino runtime doesn’t want us messing with Timer1, which is the only one that can natively represent 58μs intervals, so we will need to modify the prescalar for the timer. After some quick maths, we write our code:

Hooking up the Arduino to the board and the board to the tracks, we do in fact see the train turn on its headlights without moving anywhere. Success! I’d take a picture of it and add it here, except for the fact that this section is already pretty crowded with non-prose content. Instead, we’re going to move on to adding the Bluetooth connection so we can control the train remotely. That section also happens to be the experience that really motivated me to actually write this blog.

I don’t want to have my computer physically connected when this thing runs, since there’s just too much of a chance that I will accidentally send 12V straight into my laptop’s USB port. So, we’re going to follow every HC-05 guide on the internet (like this one) and get things up and running. Simple, right? Everything is built into the module, shouldn’t have any issues, right?

Wrong.

Sometime between when the HC-05 was first created and early-to-mid 2024, something about the Bluetooth stack on macOS changed. I have in my possession two MacBooks, one circa 2015 running macOS Monterey 12.7.4 and another circa 2019 running macOS Sonoma 14.4.1, and both experience this issue. What is the issue? The HC-05 connects but never transmits or receives data. I was able to rule out issues with the Arduino by directly connecting the tx and rx pins on the HC-05. I was able to rule out the HC-05 itself by using the "Serial Bluetooth Terminal" Android application like all of the tutorials said. I even know it wasn’t something with the specific HC-05 module because I tried multiple of them. The problem is with the laptops.

Of course, if you do some Google searching, you’ll find people saying MacBooks don’t support SPP anymore. This, of course, is wrong. How do I know? Because I can almost always get the HC-05 to connect to the MacBook but very rarely can I get it to actually transfer any information, but it does happen.

Do I have a solution to this? Not really. But I have noticed two things:

So, every time I want to connect to the HC-05 via the laptop, I completely forget the device and repair the two. When I want to transmit data over the connection, I make sure I either have my program open the TTY in read/write mode or I have screen open it. I know this isn’t really a good explanation or resource for resolving the problem, but I was having so much trouble finding anything that even acknowledged that this problem exists that I wanted to put out a blog just so that people can be assured that someone else had this same problem. If you don’t have this issue then please let me know what might be different about your setup that might help me debug this issue.

Because of all this, I am going to skip the section about the TUI app I created in order to control the train. If you want to see it now, then the code for it is available on Gitlab and it doesn’t actually require the Bluetooth to be connected to run (at least, not on my machine). So, hopefully someone finds this section reassuring, if not helpful, and we’ll move on. From this point forward, just know that I am using the "Serial Bluetooth Terminal" application on my phone to control the train.

This is less about the steps in making a DCC controller and more just a story that I want to tell people. When I was trying to debug the above Bluetooth issues, I noticed that my Bluetooth module wasn’t flashing its LEDs anymore. "Curious," I thought to myself, "I wonder why that could be." I spent some time trying to figure out what was going on but wasn’t able to determine the issue.

Thinking that I must have ruined my HC-05 somehow, I rushed to Anchor Electronics mere moments before they closed for the weekend and bought myself a new HC-05. I came home, hooked it up, and then immediately saw the magic smoke leave my Arduino. Being the brilliant man I am, I immediately assumed that the previous HC-05 must have ruined my Arduino, so I plugged in a Raspberry Pi Pico that I happened to have on hand. This also somehow released the magic smoke.

Ooh. Cool. My breadboard power supply’s 5V output sent 12V straight into the 5V pin of my Arduino, the VBUS pin on the Pico, and the VCC pin of the HC-05. Lovely.

This is the final section of the blog post - it’s gotten a little long, hasn’t it? It feels that way to me but, again, I don’t like writing. At this point, I had no Arduino and I’m struggling with the HC-05, so it seemed time to move on to a different microcontroller. I happened to have two on hand: an ESP32 and a Raspberry Pi Pico (a different one, not the one I fried).

On the surface level, the two seemed pretty close to identical. Both have Wi-Fi and Bluetooth Low Energy to replace the HC-05 struggles I’ve been having. Both are dual core, relatively low power consumption (remember: I have several amps of 12V power available) and the Rust support is approximately equal between the two. So, it really boiled down to which one I thought I could get up and running quicker because, up until I melted the Arduino, I had a train responding to DCC commands and I wanted to keep playing.

So, getting this up and going required learning a little more about DCC command packets. The DCC standard for basic locomotive control is actually fairly straightforward. The previous Arduino code allowed us to send generic bytes as a DCC packet, so we just need to make sure that the bytes have the right bits. For basic speed and direction, we care about this packet:

Reading from left to right, that is the order the bytes need to be transfered or, in other words, bytes are sent in big-Endian order. The address is the address that the train is programmed to respond to and, in most cases, that is a default value of 3. The speed portion is a little bit weird in that the C bit is sometimes the least-significant bit of the speed value and sometimes it’s headlight control. The error portion is just an XOR of the first two bytes. This doesn’t quite fit into 32 bits, but five bytes isn’t too bad of a deal.

At this point, I’m going to continue using the HC-05 module because, something that was news to me, BLE isn’t nearly as straightforward as the Bluetooth SPP. The "protocol" that we’ll be using for sending command on the serial port is just a positive or negative integer character representing the "notch" we want to put the engine’s pretend throttle in, keeping it simple to interface with using the "Serial Bluetooth Terminal" mentioned previously.

We’re also going to take advantage of the message queues that the Pico’s utility library provides in order to communicate information to the timer interrupt. All that being said, here’s the code:

In the future, this code is probably either going to transition to assembly or to Rust, depending on which I think will be more fun, but this was quick to get going and I officially have a train that I can control remotely.