Prototyping a New Z Scale Model Railway Controller using Arduino

Welcome back to Element for Presents. I'm Clen and the best thing in life is combining your interests. What could be more awesome than combining your interests by using one to achieve something with the other? I'm very into electronics development. So, this time I'm showing you the proof of concept and what I can actually do with it and what it means by building a super smooth train controller for my new tiny train. It's already in the picture. Can you see it? Seriously, it's already there. You just have to come closer. Even closer. That's how tiny it is. The original controller of my train set is 50 years old and it seems to be a variable transformer. If I look at the waveform it produces on the scope, I can see it's meant to produce DC, but it's quite ripply. And also the smoothness in control. It seems to should appear analog, but in reality, there are distinct changes and the voltage changes quite abruptly. So, there's no way for me to control my train as softly, smoothly, and especially as slow as I want because I want to do like real shanting operations where you have to go really slow with the train and be very careful about not to knock uh down the other carriages from the track. So, we need a new controller and we're going to use an Arduino to prototype that or to proof of concept it because that is what Arduinos are actually meant for. No matter what you're building, you can always boil down the concept of proof of concept into three distinct things. You have an input, a thing that processes that input and an output. So you want to verify that whatever you get at the input uh can produce the desired output and what you adjust is the processing. If that works as you intended, congratulations. your proof of concept has worked and you're now ready to take these parts that you have now verified work into a prototype. But before we get to that, we have to know our steps. So what are our inputs? What's the processing? And what do we even want as the output? My output goal is to move this super tiny train. It's set scale by the way. So that's really tiny. I think it's 1 to 220. I want this to work at the right scale speed for shunting operations. They are allowed to I think run 10 km an hour during shunting operations and I have to get that down to the right scale. So it has to be really slow and controlled. But it still must have enough power to move around the carriages. So in this case just removing the voltage that won't help any much. It will act slower, but it also will have no power. So, what I need is a way of processing the power to get the desired output. My input will be an analog dial or an a dial that feels analog. For my input, you might want to think that I'm using a potentiometer. And it looks like these Ultrain controllers would use potentiometers, but they actually don't. you actually move the uh wiper inside a variable transformer. So you are uh reducing or increasing the number of windings that are active for the output for such a variable transformer which is not uh gradual. It's actually in steps be there are a lot of steps. But if I would use a potentiometer, I would have to dissipate all the power through that potentiometer. That would be first a big waste of power and I would need a massive potentiometer for that one. So I don't do it that way. What I actually use is an encoder. An encoder encodes rotation in a digital way. It only gives a pulse in either direction when I turn it. And then I can read that with a microcontroller and adjust the outputs. This is how modern train controllers do it. And because some of them go upwards of €700, I would rather build my own or completely design my own from scratch than building them because I combine my hobbies. As my processing unit, I'm using an Arduino Uno R4. Don't mistake that for the older ones. You say, "Oh, why is using this old 8-bit microcontroller? " I'm not. I'm using an R4, which has a 32-bit Renesis microcontroller. So, you

know where you have to go with your comment. And on top of it, I'm using the Arduino Motor Shield, also revision free. Uh, it's the more modern one. It still uses an L298N which is a very classic Hbridge motor driver dual one. So we can actually control two motors at once if you want to. And guess what? A train set in its essence is basically a motor connected to cables that are in the shape of train tracks and then there's a controller attached to it to control the speed. analog train sets that is the digital ones work differently but we're not dealing with that right now. So in our processing how do we adjust the power PWM pulls with modulation. So we are basically turning on and off the signal in a very rapid fashion faster than the motor actually could react. So the motor sees uh quick on and off switches but he actually processes them like he's just turning slower or faster. It's kind of a similar concept to persistence of vision where you can't actually see the hundreds of images right now that make up this scene. Uh to you it's just motion but in reality it's just a lot of pictures one after the other. PWM works pretty much in a similar way. So we're using that to control the output stage which is basically MOSFETs driven by that signal and that gets transferred over the wires or over the train tracks to a motor and the motor in our case is inside the locomotive. I've built up my test setup just on a random wooden board. Here's my Arduino with the motor shield. Here are my inputs. I have a encoder that has distinct steps that you can feel and one that is smooth, so it feels like there are no steps, but there actually are. I want to know which of these feels more natural. That's how I verify the input stage. If I adjust the code, that's how I verify my processing stage. And by seeing the little train move along this little piece of track, I can verify my output. And to know how act fast it's actually going, I use a ruler that I just glue on here. And now I just place this on my workbench and verify uh the current situation. And then I adjust my processing until the concept is proven or it's disproven and I have to start again. Let's see. Because it's sometimes hard to judge what is actually going on inside a circuit when you don't really have any verified outputs yet. I've also put just a normal DC motor on the second channel of my driver. I apply the same signal, but this one uh tends to be noisy, not electrically noisy. Different topic. It's noisy in the audio spectrum. So, I can hear it engaging, but it still won't turn. I hear the vibrations of the PWM. So, that gives me an indication if the PWM is actually applied and how it continuously gets more and more while I turn my dial. And then I can judge when the actual uh carriage will start moving. And by uh changing the code then I can basically adjust that to see how much turning is needed to make it actually work or is there even enough power at a specific stage. I can then uh better judge how to adjust my code. It's a little bit of a helping trick when you're doing PWM things. Get a noisy motor. The first experiments are in. Uh it's not perfect. So let's adjust the code and see what we can do about that to adapt our processing. Welcome to the programming void. So instead of just uh explaining the code and how it works, we'll go through the process. So first I just use normal PWM signal, just an analog right on the output pin. That works. You can now use a higher voltage but still make the train go slow. Uh by testing I consider it 9 to 10 volts would be the ideal range because all the locomotives that I have work in that range and are not damaged by too high voltage. Some more modern locomotives uh need a lot less voltage for the same amount of power. And the old one that I got from the 50 train set needs quite a lot of power that goes up to 16 volts. But I will never run that train that fast. And with 10 volts, I can run pretty much any train by any manufacturer in ZK. But if I just directly apply the analog right, it feels a bit twitchy. It stops and starts very not smooth, very abruptly. That's not how it's in reality done. So I use a concept called ramping where I have a starting value and then I increase that value by one each cycle.

the microcontroller does until I reach the desired uh PWM value. I can make that slower and faster by just waiting in between the rides. And because it still happens very fast, it feels quite smooth and natural. The problem is if I do it that way, I'm always blocking the code in between writing because the microcontroller just waits for the next time it's okay to do the next PWM value. So if there's anything in between, it won't have time to react. So if I have to abruptly stop the train because it's running into something, it will first ramp up, take its time for that, and then ramp down again for that, and it won't even know that my input has changed already. So with an encoder, it might miss the pulses. So for the post counting, I'm using interrupts and whenever an interrupt happens, it should abort everything else and uh keep the count of the interrupt, right? and then resume the writing function. This is great for uh quick controls, but we are not getting rid of the blocking in that regard. So, we're doing something else. We're using nonblocking code. So, we're instead of just waiting with a delay function, we basically count the time that has elapsed since. And that's done with a millise function. Here's how I did that in code. And this allows us to quickly ramp up and down stuff and still react to all the events that are happening. That's how we build the processing function of our proof of concept. Now for my favorite part, we have to play around with the train until it runs exactly as we like it and we can verify that the settings are all right. And if they're not, we're adjusting them. So I try to shunt around uh other carriages. I try to make the train go as smoothly as possible. I try to move it very slowly but still with some load attached. And of course, I also want to run it fast and then stop at a specific point. And to see if all these operations work, I just play around with my train. — The difference between science and fooling around is writing it down. I got that from Adam Savage. And I'm certainly doing science here. I certainly enjoy running my little train, but there's a little hard pill to swallow. I can't just not run it as slow as it would be in scale, but it's still almost there. It's almost there. So, there might be improvement if I build my own custom controller. Maybe I should use a different uh output stage. Maybe there's something in the code that I could do. Now that I know my proof of concept is working, I can go to the prototyping stage. That's a different thing. That's where you don't use pre-made boards, but you use these boards with their verified construction to build your prototype. which means I now go to the Arduino repo for that exact board, get the schematic, use the exact same parts, and build my prototype around them because I already know that these parts will work for my purpose. That's why it's important to have quality dev kits because these actually have the exact components that are on there in the schematics and not just similar ones or whatever. They use schematics from devices that they cloned. So you know exactly what you're getting into and if you build your prototype exactly the same way and use your old code, they will still behave the same. You're not going back in your development. You're going forward. That's why an Arduino is a tool, not a component. So I don't buy 50 of them uh to embed into every project. I have a few different ones and then I use them for proof of concepts and then build prototypes around their schematics. That's what makes them really valuable to me. So now I have verified my design in hardware. I've decided on the input I will use the encoder that goes smoothly without any indentations. This gives a great illusion of true analog control. It's a lot more con convincing than I thought. I will use the same processor that is on the Arduino Uno R4 because that worked perfectly for the purpose and I have a lot of overhead to control all the turnouts in my layout and lighting effects and whatever. So, I'm not having to uh use a lot of microcontrollers with a lot of different code on them that will be hard to keep track up to date. Instead, I have one main controller that will basically run the whole layout and I only have one piece of code to update. Great thing. And the uh motor shield convinced me that this not very like sophisticated

motor controller is plenty enough to run such a train. I don't actually need a really expensive motor control chip. I use that one that is tried and true and proven and you can get it in a lot of different form factors. So, I will use the THT one because that's just easier to solder. And because I'm only building one train layout, I will likely stick to a lot of THD components to make them easy to repair. If you now want to build your own super smooth train controller, be my guest. Download all the files for free on the Element 14 community. There's also the parts list, every component that I used. I hope this helps a lot in achieving that. But if you have a different idea and just want to make it real, why not build a proof of concept? That's what most makers actually do. Like most of the projects out there, technically there are proofs of concept. And maybe there's one that is worth building a fullyfledged prototype afterwards in case you need more than one or in case your idea is really good and you want to make it big and share it with the world. If you have more ideas for projects that we can build on the show, always keep them coming on the Element 14 community. I'm also there to answer all the questions that you might have and make sure to download all the files for this and many other projects there. I will need to see a doctor now because I might have swallowed a tiny locomotive. But then another project is waiting for me. —