Fullscreen HTML5Med Res (??MB)HTML4

By Tim Blythman Decoder Base Station Using DCC Remote Controller DCC Booster Digital Command Control is a great way to run multiple trains on a layout at the same time. Our DCC Base Station allows control of five locomotives, but there is only the option to directly drive one at a time. The DCC Remote Controller allows more trains to be controlled at the same time, and Image source: www.pexels.com/photo/miniature-train-in-a-garden-9018266/ multiple can be connected to one Base Station! DCC Remote Controller T he previous articles in this series have included the designs for adding DCC (Digital Command Control) to a model railway. The first part, a DCC Decoder, constitutes the electronics that is fitted to rolling stock such as locomotives and self-powered railcars. A decoder uses the electrical DCC signal from the track to control the motor in a locomotive. It can also control lights and accessories, if fitted to the locomotive. The DCC signal provides both power and control commands. The signal is generated by a DCC Base Station and our design was presented last month. It has an LCD touchscreen for user input and status display. It needs only a low-voltage DC supply, typically 12V, to operate. The Base Station offers a main track output for running trains on a layout and a programming track output that can be used to configure decoders through configuration variable (CV) programming. In addition to the two constructional articles, we also ran a feature article about getting started with DCC, including what CVs should be programmed and how to choose the necessary values. That feature focused on using our Decoder and Base Station, but we expect that it will be helpful to anyone starting out with DCC. DCC Remote Controller Many commercial DCC systems offer so-called ‘throttles’, which are units that can plug into a base station There are a handful of regular SMD parts on the PCB, plus some larger ones, such as the RJ45 sockets, the OLED screen and tactile switches. The LED is a throughhole part that’s surfacemounted. Note the extra wire securing OLED display MOD1. 62 Silicon Chip Australia's electronics magazine to expand its capabilities, allowing the control of a locomotive through inputs such as buttons, knobs and switches. Our Controller is in this vein. We have designed it to be simple and inexpensive, so it is not onerous to add more than one. The interface we have designed is both simple and powerful. It uses a straightforward serial data protocol to transmit data. It can be used to send any type of DCC packet directly to the track, meaning that its capabilities are not restricted, even if the DCC standards were to change. The protocol can also be used to send operating commands to the Base Station, including the ability to switch the track power off and on. There is scope to add new and different commands, if necessary. The Base Station firmware was developed with such a Controller in mind, so it does not need a software update to work with this design. Interface We noted in the project article that the Pico 2 microcontroller pins chosen for the extension interface (on CON5 and CON6) of the Base Station are capable of either I2C or UART (asynchronous serial) mode operation. Ultimately, we have chosen to use serial communications, mostly siliconchip.com.au Features & Specifications 🛤 Potentiometer speed knob and six tactile pushbuttons for control 🛤 Multiple Controllers can be daisy-chained 🛤 Status LED and compact OLED display 🛤 Can select decoder addresses independently of the Base Station 🛤 Compact design fits in a UB5 Jiffy box 🛤 Uses common Ethernet (Cat 5/6) cables for connection 🛤 Control pages for three locomotives on each Controller 🛤 Power provided from Base Station; a separate power supply not needed 🛤 Only 12mA current draw per Controller DCC PROJECT KITS DCC Decoder, December 2025 (SC7524, $25) includes everything in the parts list DCC Base Station, January 2026 (SC7539, $90) includes everything in the parts list, except for the case, power supply, glue, CON4 & CON5 headers DCC Remote Controller (SC7552, $35) includes all required parts, except for the UB5 case and wire/cable because programming microcontrollers to work as I2C slaves can be fraught with difficulties. I 2C is also designed for short-­ distance communications within a single PCB; it is short for “inter-­ integrated circuit” after all. Serial data has been proven to work over longer distances, and we are using a low rate of 9600 baud. This rate also means that the time to send a packet on our bus is about the same time as it takes for the Base Station to send it to the track. Fig.11 shows the arrangement of the wiring between a Base Station and a pair of daisy-chained Remote Controllers. The design permits more Remote Controllers to be connected at the right-hand end in the same fashion. The number of connected units is not subject to any hard limit, but will depend mostly on factors such as bus latency and traffic. The general idea is that the bus will allow communications from the Base Station to any connected Controllers (from the upstream end to the downstream end), while also allowing communication from any Controller back to the Base Station in the upstream direction. The first important point is that, like DCC, this data is divided up into siliconchip.com.au packets of various types. One packet type is used to transmit a DCC packet on the rails, so these packets need to encapsulate binary data. We’ll describe the packet format in more detail in the Firmware section. Secondly, the microcontroller we are using has two UART peripherals, with the left-hand end of the Packet Processor using one UART to communicate with the next device upstream. The other UART communicates downstream. We can easily handle the cross-traffic in software. Thus, the Packet Processor is mainly concerned with handling the daisy-­ chain of data lines by moving data between the two UARTs as needed. The green lines in Fig.11 indicate packets sent from the Base Station. At each Controller, the packets are copied, with one copy kept for local processing, and the other sent downstream to the next Controller. The packets can also be modified before being sent out. For example, one packet type passes an index value along the chain. Each Controller adds 1 to the index as it is processed, so each Controller knows its position in the chain. The blue lines indicate traffic heading towards the Base Station. Here, the Packet Processor is tasked with queuing the packets that are sent from this Controller alongside other packets coming from other Controllers further downstream. Each Packet Processor keeps a buffer of incomplete packets, and only forwards a packet once it is received successfully. Since each packet includes a data checksum, corrupted packets are rejected before they reach the Base Station. The queuing process adds a small amount of latency, typically 20ms per Controller in one direction, but that is not much more than the time taken to receive and then retransmit each packet. It is a cooperative system, so any Controller that does not promptly forward the packets that it receives will lock up the bus. Of course, such problems are possible with other systems. For example, an I2C device can lock up its entire bus by simply holding either of its connected lines (SDA or SCL) low. On the other hand, the system is simple and expandable. Controllers can forward packets even if they don’t understand them. Just about any microcontroller with one UART peripheral can be used to put data Fig.11: what appears to be a single bus is actually separate devices that receive, process and then add or retransmit data. Each leg is logically separate; the system is designed so that each Controller acts as a bus repeater. Australia's electronics magazine February 2026  63 Table 2 – SLIP encoding Packet content Serial line data End of packet marker 0xC0 0xC0 0xDB 0xDC 0xDB 0xDB 0xDD All other bytes unchanged Fig.12: microcontroller IC1 takes the user inputs from switches S1-S6 and potentiometer VR1 and produces commands to send to the Base Station. It also moves data as needed between the downstream (CON2 and CON4) and upstream (CON1 and CON3) legs of the bus, and shows information via LED1 and OLED display MOD1. onto the bus, as long as it does not have any other devices further downstream of it. Circuit details Fig.12 shows the circuit of each Remote Controller. IC1 is a 20-pin PIC16F18146 microcontroller with the standard 100nF bypass capacitor and 10kW pullup on its MCLR line. During operation, 3.3V power is available at CON1-CON4; typically, it will be supplied from CON1 or CON3, since these will be facing the Base Station at the upstream end. CON5 is a header to allow in-circuit serial programming (ICSP) of IC1, with power, ground and three of IC1’s other pins connected as needed for this purpose. To simplify development, pins 18 and 19 are dedicated to programming and not used for anything else. CON1 is a four-way header and would be expected to connect to CON5 on the Base Station. CON3 is an RJ45 socket that can connect (via a Cat 5 or similar Ethernet cable) to a matching RJ45 socket (CON6) on the Base Station. Similarly, CON2 and CON4 would connect to either CON1 64 Silicon Chip or CON3 of a subsequent downstream Controller in a chain. We used the RJ45 sockets and Cat 5 cables for practically all of our prototypes. The cables must be wired ‘straight through’; pin 1 to pin 1, pin 2 to pin 2 and so on. So-called crossover cables will not work. We also built a prototype Dual Controller using two Controller PCBs fitted into a 3D-printed case. To connect these two PCBs, we soldered insulated wires directly to the pads of CON1 and CON2 where the two boards abut. Two I/O pins (TX1/RX1) connect to the communication lines on CON1/ CON3, while another pair (TX2/RX2) connects to the downstream CON2/ CON4. All of these lines are provided with 2.2kW pullup resistors to ensure that the lines are in a known state, even if nothing else is connected. The bulk of the remaining circuitry forms the user interface for the Controller. Six tactile pushbuttons connect between various I/O pins on IC1 and circuit ground. Internal pullups on these pins allow the state to be determined by the micro. Australia's electronics magazine 10kW variable resistor (potentiometer) VR1 is used primarily as an analog speed control, so it is wired as a divider across the 3.3V supply. Its wiper is connected to a 100nF capacitor via a 10kW resistor to filter out noise and provide a low source impedance for the analog-to-digital converter pin that is used to read its position. OLED module MOD1 connects to a further two pins on IC1. These provide a ‘bit-banged’ I2C interface to display a small amount of text for the user. Since there are two more I/O pins free, we have connected them across bi-colour LED1 and its series resistor. This is another indication we can provide the user. The circuit diagram shows two options for this LED; either a standard two-lead through-hole part or a four-lead reverse-mount SMD device can be fitted. The latter is wired in inverse parallel to provide the same function as the two-lead device. Firmware The firmware running on microcontroller IC1 must perform the packet processing mentioned earlier, as well as receive user input and display that on siliconchip.com.au the OLED and LED. It must also generate packets based on the user input and forward them to the packet processor. Plain serial data does not have a native packet marker. If we were interested in sending only ASCII text over the link, we could use one of the ASCII control codes (hexadecimal 0x00 to 0x1F) as a packet marker. But we want to send binary data, so we need a different technique. SLIP (serial line internet protocol, also known as RFC 1055) is a protocol from the 1980s designed to encapsulate internet protocol (IP) packets for transmission over serial connections. This encoding uses one byte code (0xC0) as an end-of-packet marker. The only place this code can appear is at the end of a packet. If this byte needs to occur inside the packet data, a two-byte sequence is used instead. Thus, a few single-­ byte values are encoded as two-byte sequences while travelling on the serial data line. Table 2 shows the encoding scheme. To this, we add a simple packet type marker byte as the first byte of each packet, and a checksum byte for error checking as the last byte of each packet as it exists in memory (and not the data on the serial line). The checksum system is the same as used for DCC; it is simply the XOR of all the other bytes. This means that if you calculate the checksum of the packet, including the checksum byte, it should result in zero (0x00). In our firmware, this means that a single function can be used to both generate and validate the checksum value. Since the checksum scheme is the same as DCC, and DCC packets must have a checksum of zero, the checksum for a packet carrying a DCC packet is the same as the packet type marker byte. For our scheme, we have chosen code point 0x42, which is the same as ASCII ‘B’. Fig.13 shows the encoding for a typical DCC packet. When the Base Station sees a packet containing a DCC packet, it sends it to the track output, if possible. The upshot of this is that it is quite simple to create a device to generate data that the Base Station can understand. You could build your own Controller variant using this protocol. There are commands that can instruct the Base Station to switch the main track power off or on, and Table 3 below lists the supported packet types. siliconchip.com.au Fig.13: the encoding of a DCC packet (with ‘B’ marker) onto the bus requires adding the marker and checksum bytes in memory and then translating the byte sequences as they are sent out on the wire. Other packet types (see Table 3) have different marker bytes, allowing the recipient to identify their purpose. Fig.14: this simple design uses the PCB as the front panel, so all components and traces are relegated to one side. A handful of components that would normally be mounted in through-hole fashion are instead treated as SMDs, using pieces of wire as necessary. The first overlay shows the Controller as built from the kit. The second overlay uses the alternative components listed in the parts list, with four-way headers for CON1/CON2 and a throughhole LED1. Australia's electronics magazine February 2026  65 The DCC Remote Controller can connect to our DCC Base Station via Cat 5/6 cables. Multiple Controllers can be added & each provides the ability to control up to three locomotives. The Controller stores the states of up to three locomotives, and they can be separately updated by rotating VR1 or operating the switches. A priority system sends out packets more frequently when data is changing, making the best use of the bus. We will provide more detail on the user interface once assembly is complete. Assembly This is an SMD design, so you will need tweezers, flux, a magnifier and so forth. None of the parts are too small, so it should not be too difficult (see Fig.14). Start by fitting the SMD parts on the black PCB, which is coded 09111245 and measures 83 × 53 × 0.8mm. This includes IC1, the two capacitors and seven resistors. Tack one lead of each, check the part is aligned and then solder the remainder of the pins. Now is a good time to fit the LED, whether you are using the surface-­ mounting version or not. If you are using the through-hole part, bend the leads over by 180° so that they reach the adjacent pads and allow the lens to shine through the hole in the PCB solder mask. For the through-hole part, check the data sheet or test its polarity to determine the lead that is the anode for the red element and cathode for the green element. This lead should be placed so that it is closest to the potentiometer. If you are using the SMD part, be sure to align the dot on the part with the silkscreen marking. Clean up any excess flux and allow the PCB to dry. There are now enough components fitted to allow IC1 to be programmed if necessary. If you have purchased a kit or IC from the Silicon Chip Online Shop, Table 3 – DCC Remote Controller Packet types before encoding Type Marker byte Notes DCC Packet ‘B’ (0x42) Sent by the Controller to the Base Station (see Fig.13). The packet content is a ‘B’ followed by the DCC data bytes, including a checksum, followed by a ‘B’ as the packet checksum. Host query ‘C’ (0x43) Sent by the Base Station, with an index that is noted by each Controller and incremented by one when the packet is sent to the next Controller. The first Controller sees 0x43, 0x01, 0x42 and sends 0x43, 0x02, 0x41 to the second. The third sees 0x43, 0x03, 0x40 and sends the fourth 0x43, 0x04, 0x47 etc. Host reply ‘D’ (0x44) When a Host query is received, the Controller replies in the format 0x44, nn, dd, cc. Here, nn is the index from the Host query, dd is an arbitrary ID byte and cc is the checksum. For the ID byte, the Controller generates a fixed but random value from its internal MUI (Microchip Unique Identifier). This allows the Base Station to know how many Controllers are connected and to calculate the bus latency by measuring how long the Host reply took from each Controller. System ‘I’ (0x49) Currently supported commands can be used to control the main track power. The sequence 0x49, 0x00, 0x49 will switch the track power off and 0x49, 0x01, 0x48 will switch it on. 66 Silicon Chip Australia's electronics magazine then there will be no need for programming. If programming is needed, solder a five-way header strip vertically to CON5 so that the pins point directly up. This header can be left in place, since it should not foul the wall of the enclosure. Connect a PICkit 5, PICkit 4, Snap or PICkit Basic programmer and use the MPLAB IPE to program and verify the 0911124C.HEX file into IC1. Solder the RJ45 connectors next, if you are using them. We found it easiest to tack the larger pads in place and then solder the smaller leads. We didn’t need to use much extra flux because the pads are much larger than most surface-mounting parts, and the solder we used has a flux core. Next, fit the OLED screen. This is done similarly to other projects where we have used a PCB as a front panel, including the USB-C Power Monitor (August & September 2025 issues; siliconchip.au/Series/445), which used the same screen module. Take four lengths of wire around 15mm long and make a right-angle bend about 3mm from one end. Solder the L-shaped wires to the pads of MOD1 on the PCB so that the long legs are pointing upwards. Remove the protective film from the OLED module and thread it over the wires. Push it down flat against the PCB and gently adjust it so that it is square within the marked silkscreen outline, then solder each wire to its pad and trim the excess. The longer pads towards the other end of the OLED can be used to affix a piece of wire to physically secure the screen module better. You can see how we have done this in the photos of our prototype. Next, solder the tactile switches. siliconchip.com.au We fitted two Controllers to a 3D printed case, making for a compact unit that can directly control two locomotives simultaneously. See the photo below for how we wired the two Controllers together. Tack one lead of each and carefully adjust them so the actuator is centred on the hole through the PCB. The 0.8mm-thick PCB allows the actuator to protrude slightly, so make sure that the tops are even, too. When they are all aligned neatly, solder the remaining leads. Like the RJ45 connectors, we didn’t need extra flux to do this. Next, thread potentiometer VR1’s shaft through the PCB and secure it from the outside with the washer and nut. It should line up squarely with the silkscreen outline. Solder short lengths of wire between the pads on the PCB and the leads of VR1. At this stage, you should be able to connect CON3 to a Base Station using a Cat 5/6 cable. Power on the Base Station and you should see a display like Screen 1. This is a good indication that everything is working as expected. CON3 (or CON1) should always connect to the cable going to the Base Station, with CON4 (or CON2) used to connect more Remote Controller(s) if required. This ensures the serial data travels in the correct direction. In use Controller protocol. You can connect to a computer via the USB socket on the Pico 2 on the Base Station, and use a serial terminal program to view status information about the connected Controllers. To allow one potentiometer to control multiple decoders, we need a way of switching control without immediately relying on the position of the potentiometer, at least until we can be sure that it does not conflict with the last setting made for that decoder. This is the <SP indicator visible on Screen 1. It is an instruction to rotate the pot anti-clockwise until it matches the last speed setting used. At startup, that position corresponds to zero speed. You might also see SP>, indicating that the pot should be rotated clockwise until it matches the speed setting. You’ll see this indication pretty much every time you change screens. Screen 2 shows the controls for the first (1:) slot on the Controller. No locomotive address is selected, so --- is shown on the first line. The HOLD > is an instruction that helps the user to set an address. Fig.15: two simple symmetrical slots for the RJ45 sockets are all that are needed to fit the Controller to its UB5 case. One edge of each socket is right on the centreline of the box. All dimensions shown are in millimetres. There is no need to update the Base Station firmware, since our original release incorporated support for the Screen 1: the initial screen. The “<SP” means to turn the pot anti-clockwise. Screen 2: with the pot rotated, it now shows HOLD > to help set an address. siliconchip.com.au Inside the-3D printed case, we soldered wires directly between CON1 on one board and CON2 on the next. Note that the wires need to cross over. Australia's electronics magazine February 2026  67 The left-hand end of the Controller is the upstream end and connects via the Cat 5 cable to the Base Station. Further Controllers are added in similar fashion. The second line shows the direction and speed, which can be toggled with the REV and FOR buttons (S1 and S2). These can also be used to set the speed to zero without adjusting the potentiometer. The three dots (...) show the function outputs, which are all off at startup. The 1 at lower right is the host index received from a Base Station, so no two Controllers should show the same value. If this is showing --- for more than five seconds, the Base Station might not be communicating due to a problem with the connectors or wiring. Hold the SEL > (S3) button for a second and release it; this will take you to Screen 3 to select an address. You can set a short address by pressing F0 and adjusting the potentiometer until the address is shown. The address shown at upper right will be activated when SEL > is pressed again. Pressing F1 will allow the top two digits of a long address to be set, and F2 sets the lower two digits. All long addresses are shown with five digits on all screens. You can also use the REV button to cancel address selection. Screen 4 shows a short address set for slot 2, with the <SP indicating that the potentiometer needs to be adjusted. The LED will be off; it will switch on when the position is correct. Generally, red means stopped and green means a speed greater than zero. You can see that the lighting function control F0 (shown as L) is on, as is F1, while F2 is off. Pressing the FOR or REV buttons will toggle direction and speed control. You can perform low-speed shunting by leaving the potentiometer set and toggling the direction and speed with just the FOR and REV buttons. 68 Silicon Chip A display of --- means that the speed is toggled off (set to zero); pressing FOR or REV will change direction or activate the speed set by the potentiometer. If a number is shown, that speed is being actively sent to the selected address. Pressing SEL again will show slot 3, as in Screen 5. Here, a locomotive with short address 19 is operating normally in the forward direction at speed step 22 with its F0 (headlight) output activated. The LED will be lit green. One more press of SEL will bring up the system page (Screen 6). Pressing FOR or REV will send a signal back to the Base Station to switch the main track power on or off, the LED will light up green or red to show the command that has been sent, and a message should appear on the display. Pressing F0 will save the currently selected locomotive addresses, so they will be available after a power cycle. Finally, the operation of the F1 and F2 buttons can be switched between toggle and momentary action (for control of function outputs) by pressing the respective button. The next press of the SEL button will return to slot 1, as in Screen 1 or Screen 2. Summary Since the Base Station is simply passing packets from the Controllers Parts List – DCC Remote Controller 1 double-sided black PCB coded 09111245, 83 × 53mm (0.8mm thick) 1 UB5 Jiffy box [Altronics H0205, Jaycar HB6015, Bud Industries CU-1941] 2 four-way right-angle 0.1in (2.54mm) pitch locking headers (CON1, CON2; optional) 2 SMD RJ45 sockets (CON3, CON4) [DigiKey 4414-3253-0007-02CT-ND] 1 five-way 0.1in pitch header strip (CON5; optional, for ICSP) 1 0.91-inch 128×32 pixel I2C OLED module (MOD1) 6 reverse-mount SMD tactile switches (S1-S6) [Adafruit 5410] 1 10kW linear 9mm horizontal potentiometer (VR1) [Jaycar RP8510] 1 knob to suit VR1 [Jaycar HK7734] 1 10cm length of lead offcuts or similar solid uninsulated wire 1 Cat 5/5E/6 ‘straight through’ cable OR wire to suit CON1/CON2/bare solder pads if using those Semiconductors 1 PIC16F18146-I/SO 8-bit microcontroller programmed with 0911124C.HEX, wide SOIC-20 (IC1) 1 red/green reverse-mount SMD LED (LED1) [Kingbright AAA3528SURKCGKC09] OR 1 3mm bicolour red/green LED (LED1) Capacitors 2 100nF M3216/1206 X7R 50V SMD ceramic capacitors Resistors (all SMD M3216/1206 size, 1% ⅛W SMD) 2 10kW 4 2.2kW 1 1kW Australia's electronics magazine siliconchip.com.au The first article in this DCC series was the Decoder shown here. The Base Station followed that. directly to the track, it’s advisable to set CV11 (packet timeout) on all locomotives. That way, if there is a communication problem, such as a Controller being inadvertently unplugged, the locomotives will stop after the timeout instead of running away out of control. A one-second timeout should be sufficient, but you can try a higher value if the locomotives appear to be stopping unexpectedly. For our Decoder, the CV11 value is measured in seconds, so a value of 1 should work for most small layouts. The Controller sends out packets for each address every 400ms, at most. If the controls are changing, then packets can be sent out as close as 100ms apart for each active address. Remember that each slot will continue to send commands for the last speed selected, whether the slot screen is visible or not. There are no interlocks against changing a slot’s address without setting the speed to zero. Again, the CV11 timeout is expected to perform the safeguard role. We measured each Controller’s current draw at between 8mA and 12mA. The switch-mode regulator on the Pico 2 can source 800mA, so the current consumption of the Controllers should not dictate how many can be connected. Each Controller adds around 20ms of latency to each packet. We ran some tests with five Controllers connected and did not think there was a noticeable delay, even from the most remote unit, although this will depend on how much bus traffic is present. This Controller design rounds out our suite of DCC equipment to include most of the things you might need to add DCC to a small layout running up to about 10 trains at a time. Having said that, it's possible we'll expand the system in future. The protocol used for communication between the Controllers and Base Station is simple but powerful, so it could be used to add more custom SC features to the DCC system. Screen 3: selecting the address of the locomotive to control. Screen 4: short address 3 has been selected in slot 2. Screen 5: the loco is going forward at speed 22 with F0 active. Screen 6: the system page lets you turn the track power on/off and more. siliconchip.com.au Screen 7: the terminal output from a Base Station with two Controllers connected. The Host Check is sent every five seconds, and the times shown are for a return trip (host query and host reply). Typical working latencies are half the figures shown for regular packets, such as commands from the controllers. Australia's electronics magazine February 2026  69