P19345: Model Railroad Control Panel

Detailed Design

Table of Contents

Team Vision for Detailed Design Phase

For the Detailed Design Phase, the following goals were included in our team vision:

Progress Report

A progress report was sent out to customer Charles Rothbart, the RIT Model Railroad Club, our guide Harold Paschal, and all team members on 4/18/2019. The progress report addressed what we planned to accomplish by the end of the detailed design phase, what tasks have been accomplished and what tasks are pending from the 4/18/2019 date, what decisions we had made and what questions we had to continue moving forward.

To view our 4/18/2019 progress report, please click here

Prototyping, Engineering Analysis

Hardware Schematics

The designs for the hardware undergoing prototyping and analysis in the section below can be found under Preliminary Detailed Design


Voltage regulation circuit:

One of the challenges of our design will be wire management. Each Raspberry Pi Zero (RPi Zero) will require 5 V at ~1 A. From a wire management perspective, it would be undesirable to run a dedicated power line from an outlet (via a 120 VAC to 5 V wall wart or other means) to each RPi Zero. Fortunately, there is a 12 V supply available that we can tap into. However, this will need to be regulated down to 5 VDC.

There are two options available for voltage regulation: linear and switching regulation.

Linear voltage regulators perform regulation by dissipating excess voltage as heat. While the regulated output is typically pretty good with minimal ripple voltage, they are inefficient, may require a significant amount of heatsinking under light loads, and may adversely affect surrounding components with the heat. Additionally, the current sourcing abilities of a typical linear regulator may be less than we require. We have not determined the actual maximum current that our design will require.

Switching regulators operate on the concept of pulse width modulation (PWM) and feedback to output an average voltage. Switching regulators store energy in magnetic and electric fields via and inductor and capacitor. They are much more efficient, but require extra components, can produce a significant amount of high frequency noise, and can have high output ripple voltages. In spite of these drawbacks, we believe that a switching voltage regulator is the correct choice, partly because their ability to source more current than a linear regulator (such as a LM7805) without the need for significant heatsinking.

Thus far, we have assembled a prototype of our 12 – 5 V switching conversion circuitry based around the Texas Instruments TPS56220 switching regulator. We chose this regulator because of its small-footprint package (SOT-23-6) and its ability to source 2 A of current. The circuitry was designed (read: copied) directly from the design documentation that they provide for that particular regulator for the conditions we will be using it in (5 V).

Voltage Regulator Prototype

Voltage Regulator Prototype

At light load (3.3 kOhm resistor), it was measured that the regulator output was ~5.2 VDC with a significant amount of ripple voltage (400 mV). It has been theorized that at such a light load (1.5 mA), the switching frequency of the regulator is very low, leading to long (in the digital world) times between the output switching on and off. At this light of a load, the switching is audible.

To determine whether or not this is the case, a heavier load will be applied to the output. We have acquired low resistance, high wattage resistors (5 Ohm, 5 W) in order to determine how the circuit performs under heavier loads. This testing has not been performed yet.

If this does not turn out to be the case, we will have to experiment with the values of the inductor and output capacitors. We will also need to keep the saturation current of whatever inductors we choose in mind, so that we do not saturate the output inductor of our regulation circuit. Output capacitance will be added as needed until ripple voltage is determined to be an acceptable level (TBA).

We may want to explore the option of adding Schottky diodes to the input and output as an added safety measure to prevent significant damage that may result from reversing +12 V and ground when connecting to our design.

8-to-3 Encoder circuit:

In order best utilize the limited GPIO pins that each RPi Zero has, we are choosing to implement the control panel track switching selection with an 8-to-3 priority encoder. Specifically, our first implementation is with a SN74HC148. This is a widely available and inexpensive part.

Our idea for implementation is to have one encoder on each “side” of the control panel. With this, up to 8 switches on each “side” of the control panel can be controlled. Under normal operation, only one switch per “side” will be activated. Using the encoder, the status of 8 switches can be monitored with only 3 GPIO pins.

With no switches pressed, the normal status of an input to the encoder will be pulled high via a 10 kOhm resistor. When a switch is pressed, the pin is driven temporarily low to ground. The 8 different inputs are then encoded with the SN74HC148 into a 3-bit binary number (8 different combinations of bits), each of which represent the status of a different switch. I anticipate that there may be some timing issues, and debouncing will likely need to be handled in software.

Timing considerations will be further determined by measuring the input and output statuses of the 8-to-3 encoder to determine whether debouncing will be an issue or not.

If possible, I believe that the best implementation would be a generation of interrupts based on the switch status so that every switch does not have to be constantly polled. Even if this is not the case, I don’t anticipate that polling the GPIO inputs will require much computational power or time.

Encoder and Decoder prototype

Encoder and Decoder prototype

3-to-8 decoder circuit:

Signaling and indication is a major component of our project. Realistic signaling and lighting is crucial to the immersive feeling that one desires when operating a model railroad system.

We have determined that the best way to achieve some of the signaling and indication is with a 3-to-8 decoder. We selected the SN74HC138 as a viable option due to its availability, simplicity, and price. With the decoder, we can control 8 different signals (LEDs) at a time, individually, with only 3 GPIO pins.

We have yet to verify that the decoder can source the required current necessary to light the LEDs, keeping in mind that some LEDs may be a somewhat significant distance away connected by a small-gauge wire.

For more complex LED arrangements (like multicolor LEDs), the GPIO configuration will be less flexible. We have not yet determined how many “complex” LED arrangements that we would need to support at any given time.

RS-485 to UART circuit:

Communication around the railroad layout is accomplished with RS-485, which is a popular differential communication protocol. Because the RPi Zeros have UART-compatible GPIO pins, we must convert this differential signal into a single-ended signal.

The schematic for this portion of the circuit was adapted from schematics for an existing RPi Zero design (https://www.abelectronics.co.uk/docs/pdf/schematic-rs485pi.pdf).

We have yet to reach a point where we are troubleshooting this circuitry, but because it is based on an existing design, we are fairly confident that there will not be any major, insurmountable issues.


Voltage regulation circuit:

Solder the voltage regulator on prototype board and switch out 10uF bypass capacitors to 22uF. Connect 12V to the input and use multimeter to measure the output voltage is 5.48V. We were concerned about the additional 0.48V which may cause issue to raspberry pi. Then we use oscilloscope to confirm our assumption of noisy ripple voltage. From oscilloscope, we measure the difference between upper and lower voltage of 0.48V and frequency is 2.747kHz which is lower than normal operational frequency 560kHz.

We then connected a 10 ohm load to simulate RPi Zero and get a more stable output voltage at higher frequency. From the oscilloscope, we measured a ripple voltage of 0.16V and frequency of 532kHz. The DC voltage was measuredto be 5.16 V, so we'll need to adjust the voltage-setting resistor in the feedback circuit of the voltage regulator.

Noisy regulator output with light load - 1.5 mA

Noisy regulator output with light load - 1.5 mA

Stable regulator output with heavy load - 0.521 A

Stable regulator output with heavy load - 0.521 A

Note that when comparing the images above, the y-scale of the lower image is 5x smaller than the upper image (200 mV/div vs. 1 V/div)

We also looked at the transient on and off response of the voltage regulation circuit. The purpose of this was to ensure that we were able to reach a steady voltage without any significant overshoot or undershoot, which could damage the RPi Zero. As seen below, we did not experience any overshoot or undershoot when turning the circuit on or off. As we get closer to integrating the system, we will make multiple measurements to ensure that we can consistently verify these preliminary results.

On-response of regulator

On-response of regulator

Off-response of regulator

Off-response of regulator

We also compared the efficiencies of using a switching regulator vs. using a linear regulator. We measured the efficiency of the switching regulator to be 88.78%, and measured the efficiency of the linear regulator to be 41.5%.

Further, we are expecting that the ripple voltage of the switching regulator decreases once it is on a proper PCB with reduced parasitics as compared to the prototype circuit.

8-to-3 Encoder and 3-to 8 decoder circuit:

The input of encoder is control by 8 dip switch an output a 3-bit binary to the decoder. The decoder will determine the binary input from encoder and switch on LED accordingly. For simulation, connect directly with the output of encoder A0, A1 and A2 to the input of decoder A, B C on the breadboard without going through raspberry pie. We found out that 7/8 of the LEDs are initially ON when we power up the circuit and the dip switch is not corresponding to LEDs. After we verify all the connection is correct, we decide to test encoder and decoder separate. Provide different combination to input of decoder to drive LEDs. 7 out of 8 LEDs turns ON and 1 LED OFF instead of only 1 LED ON and the rest is OFF. We soon found out that the truth table for SN74HC138 is opposite of what we want. We did not have the chance to test for encoder circuit but will further investigate later.

LEDs with wrong logic

LEDs with wrong logic

Software Design Concept

High Level Overview

The current software design is described in this section. It is acknowledged that this design will be altered and updated throughout later phases of the project.

The figure below is a diagram that contains the information of how the different components of the system will be connected.

Updated System Architecture Diagram

Updated System Architecture Diagram

Command Station

Layout Control Brain

Control Panel Controller

Control Panels

The telephone module pictured above is a method currently implemented in the club to act as a central hub for the star topology the existing RS-485 bus is wired in. The plan is to emulate this to keep the wiring of the new bus to a minimum.

Below is a general block diagram of how the different parts of the overall system are connected to each other. The block diagram does not include the hardware components that will be included during integration of subsystems.

General block diagram of overall system

General block diagram of overall system

Software Functions and Data Structures

In the diagram, a Computer Interface node connected with a dashed line can be seen. This is included to indicate that the Computer Interface can be connected or removed from the overall system. A requirement given was to have certain components of the system continue running even if there is not a computer interface connected to the system. A Raspberry Pi 3 (Pi3) and Raspberry Pi 0 (Pi0) can also be seen in the diagram. Both Pis will have programs loaded onto them, and each will be written specifically for either the Pi3 or the Pi0. In each program, a set of functions that were considered useful will be written. A list of these functions can be seen below. The chosen functions for the design may be changed / updated throughout later phases of the project.

Functions that may be useful for writing the programs on the Pi0 and Pi3
Board Function Description Notes
Pi3 initPi3 setup the Pi3 for communication and GPIO Function will include initializing any data structures needed for the program, and initializing any process needed to be used on the Pi3 (UART - communication with the Pi0)
connectPi3toCS initiate communication between the Pi3 and the Command Station This topic needs to be researched on for more detail, but initial ideas include the use of an RS232-to-USB connection.
sendCommandToCS(command) allow Pi3 to send a command directly to the CS Function can be used to send commands based on Pi0 input / output
getSysConfig getting layout's current configuration SW can use this function to store information about layout current configuration. Initial ideas for storing layout configuration includes a graph coded in a dictionary data structure in Python.
getBlockOccupancy getting information about which blocks are currently occupied or not Function can be used to send information to necessary components about which signaling LEDs need to be turned on as certain colors
sendColor(color) allow Pi3 to send information about which color a certain signaling LED should be Function can be used for logic statements when deciding which color signaling LEDs should be based on block occupancy information
ledON / ledOFF / toggleLED turn on / off / toggle certain LEDs associated with a certain GPIO pin Function can be used to send a command to the CS saying which LEDs should be ON / OFF on the test bench and / or control panel board prototypes (for testing purposes at least)
getButtonPressInfo retrieving data from a Pi0 about which buttons were pressed on the control panel associated with the Pi0 Function can be used to send information to the CS about which switches to toggle / which signaling LEDs should change color / etc.
Pi0 initPi0 setup the Pi0 for communication and GPIO Function will include initializing any data structures needed for the program, and initializing any process needed to be used on the Pi0 (UART - communication with the Pi3)
connectPi0toPi3 initiate communication between the Pi0 and the Pi3 Topic needs to be further researched, but initial ideas include the use of UART between the Pi0 and Pi3. During initialization, an identifier will have to be given to the Pi0 being initialized so that it can be identified by the Pi3 as a specific Pi0
ledON / ledOFF / toggleLED turn on / off / toggle certain LEDs associated with a certain GPIO pin Function can be used to turn LEDs on / off / toggle LEDs on the control panel board prototype
setButtonPressInfo when buttons are pressed on a control panel board (prototype or not), the Pi0 will store the button press information allowing the Pi3 to the get the information for it's use Information will, initially, be stored in a dictionary data structure for ease. A code snippet can be seen below for how the dictionary will be setup for storing the button information on a control panel
Code snippet of dictionary for storing control panel buttons information

Code snippet of dictionary for storing control panel buttons information

The above functions are the ones that have been broken down into the category of Pi0 or Pi3. However, there will be additional functions that will be included in the design, but were not placed in the two categories. These functions, as of now, will be written in a separate file, and are related to timing. These timing functions will be used for timing analysis of the overall system. Since the location of these functions is not crucial, a separate file will allow for the code to be readable for future users. These timing functions are listed down below.

Timing functions that will be used for timing analysis of the overall system
Function Description
startTimer(timer) have the selected timer start counting
endTimer(timer) have the selected timer stop counting
printTime(time) print out how long a timer has run in a readable format
resetTimer(timer) put the value of the selected timer back to zero
initTimer(timer) create a timer to use

It has been acknowledged that the functions listed above will be changed and updated throughout later phases of the project.

After discussing functions that will be useful for the software design, a programming language was chosen. The language that will be used is Python, Version 3.3. This language was chosen because of it's readability, and availability of many frameworks and libraries for the software design team to use. Because Python has been chosen, it was decided the web framework Flask will be included in the software design to fulfill the requirement of interaction with the railroad system using a REST API. From general research on the framework, plenty of documentation is provided on using the framework for using REST APIs to control GPIO pins for some application.

Wrapping up the software design, some questions were left still unanswered. After a series of discussion, answers were provided for each question. The questions and answers can be seen below.

Visual representation of a possible layout configuration

Visual representation of a possible layout configuration

NCE Accessory Command Format

NCE Accessory Command Format

Documentation for the NCE Protocol and Commands can be found here

Operator/Dispatcher Use Cases

Provided below is an updated use case framework for the characteristics the software will need to have. This will be used as a high level guide that will be used in conjunction with the software designs detailed above as well as the test plans found below.

Updated Use Cases and System Characteristics

Updated Use Cases and System Characteristics


The system will need to support multiple signal states and ensure that said states are generic. The goal is to be able to abstract the states in a way that would allow a user to map a new signaling format to the system without having to change the underlying code. Shown below is an example of the different states provided by the Northeast Operating Rules Advisory Committee (NORAC). The Model Railroad club will be using New York Central and Baltimore and Ohio signaling rule sets in their layout so these rule sets will be used for preliminary testing of the signaling states.

Signaling states the system will need to support

Signaling states the system will need to support

As mentioned throughout the section, it is understood that this software design may not be the final design that is given to the customer at the last phase of the project. If other solutions are discovered to be a better fit for the solution to the problem, then documentation will be updated to reflect those changes.

Bill of Material (BOM)

At the end of MSD_I we have utilized $251.97 of our $1,000.00 budget. The majority of items purchased for prototype testing are able to be repurposed and used within our final design implementation. Any new components or parts can be order over the summer.
Updated Budget

Updated Budget

Test Plans

To conceptualize our test plans, we first identified all engineering requirements and prototype concepts that would need to be tested. This included the 11 engineering requirements we have from previous MSD 1 phases and 2 additional hardware tests we added to document prototype testing. These testing requirements are visible in the Testing Requirements image below.
Testing Requirements

Testing Requirements

We utilized the MSD test plan template to standardize the format and documentation of what will be tested, what materials will be needed, how data will be collected and stored, and what process should be followed to complete testing. After formating the template, as a team we brainstormed ideas on how to adequately populate the testing document and how to complete testing, such as what cases will be tested and what signifies a test as successful or unsuccessful. These ideas were written in our log books. Examples of our logbook notes are visible in the F3 and F4 Requirement Test Plans image.

F3 and F4 Requirement Test Plans

F3 and F4 Requirement Test Plans

Going forward, we formatted our testing plans into the MSD test plan template to be followed and completed when testing begins. For all of our tests, we included a requirement to complete at least 25 tests within the testing cases to provide a sufficient sample size to complete statistical analysis on. For testing, we decided that multiple tests within each test case will need to be completed to confirm if the test is successful or not. The multiple tests will be factored into the conclusion section of the test plan with associated statistical analysis. To view an example of one tab within our test plan document, please see the below image titled T6 Test Plan. This format is followed throughout our entire test plan excel sheet. Each tab represents a different test plan for each of the engineering requirements, and specific testing cases are visible within the testing flowchart section.

T6 Test Plan

T6 Test Plan

To view the live test plan document, please click here

Risk Assessment

Within the past few phases, we have utilized a risk register and risk register graph to monitor our risks. Each risk is assigned a letter code and rated based off of a 1-3-9 rating in severity and likelihood with 1 being the least severe and 9 being the most severe.

The Risk Register was assessed to determine if any mentioned risks have been encountered or if their likelihood or severity have changed. As seen below in the risk register graph, risks G and L were re-evaluated and adjusted to show a lower RPN this phase. Risk G reflects the risk "A lot of extreme snowfall". With the seasons changing, the risk of having snow affect our meeting ability has reduced in severity from 9 to 1. Within MSD II this risk will be reassessed further. Risk L reflects the risk "Technology needed for project cannot be purchased or is no longer being sold". At this point in the process, we have purchased the majority of components needed for the design due to prototype testing. With our design, we also kept the customer in mind by utilizing components that are easily accessible to purchase. This risk was reduced in likelihood from 3 to 1. Another risk was added to the risk register, risk Y "Team does not finish design by MSD1". This risk has a severity of 1 and a likelihood of 9. At this point in the process, we have concepts to implement, but we recognize that further analysis is needed to confirm the designs. To respond to this risk, we are creating a plan on how to finish the design within the first two weeks of MSD II.

No risks were completely deleted out of the risk management system this phase, only adjusted in RPN value. The deleted risks visible in the graph are from prior phases.

Risk Register Visual Interpretation

Risk Register Visual Interpretation

Risk Register

Risk Register

To view our risk register, please click here

Design Review Materials

To view our Design Review powerpoint, click here

Plans for next phase

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation