Table of Contents
Team Vision for Detailed Design PhaseFor the Detailed Design Phase, the following goals were included in our team vision:
- Confirm the proposed design appropriately addresses the engineering and customer requirements provided from the RIT Model Railroad Club, the team's PRP, and the customer interview
- Complete a software design concept to achieve open source goal
- Complete a hardware design concept
- Configure the Pi Zero and Pi Three to have communication with each other, and for integration
- Create prototypes for a voltage regulator, and for a decoder and encoder circuit
- Complete a set of test plans with strict outlines of what materials and procedures will be needed and what criterion to test against to prove the test successful
- Document design concepts with information including why and how a specific design was chosen
- Provide a document containing a plan for team member contribution towards designing, building, testing, and integration during the first two weeks of MSD II
- Prepare design, test, build plans, and any other documentation for implementation in MSDII
- Reevaluate the high risk items to mitigate any potential issues with prototyping and designing
Progress ReportA 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 AnalysisHardware 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).
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.
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.
SimulationsVoltage 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.
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.
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.
Software Design ConceptHigh 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.
- Will communicate with layout control brain via RS-232 port
- Will receive accessory commands from the layout
control brain and provide accessory information back
- Serialization software will treat the USB port as a serial port.
Layout Control Brain
- Will handle signal logic, remote interface, and communication with the control panel controllers
- Will communicate with control panel controllers via RS-485.
- Will have a custom shield that handles UART to RS-485
- Polling and Interrupts will drive this communication
Control Panel Controller
- Raspberry Pi Zero with custom shield will drive peripheral I/O.
- Shield will also convert RS-485 back into UART to be
processed by the board.
- Polling and Interrupts will be used to accomplish this
- Existing control panel will be starting point for testing
- New control panels will be created to test various turnout and interlocking combinations
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.
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.
|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|
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.
|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.
- How will the information about the system be stored?
- Initial design is to have a graph structure
imitated by a dictionary data structure in Python.
- Neighbors of each node will be different components connected to one node. A node may be blocks, and each block (node), will contain information about which blocks are connected to it, and what switches and / signaling LEDs are included in the block. A visual example of this structure is depicted below, and a code snippet of how the visual representation can be written in code can be see in this Python file. A text file version that maybe interpreted by a web browser can be seen with this text file link.
- Initial design is to have a graph structure imitated by a dictionary data structure in Python.
- How will the Pi3 know which Pi0 is communicating with
- During initialization and through UART connection, the Pi0s will send a unique identifier to the Pi3. The Pi3 will store this information in a dictionary data structure. The dictionary's keys can be used to check if a Pi0 is already connected to the Pi3, or not. Other information can be included as part of the value for the key of the specific Pi0.
- How will communication between the Pi3 and Pi0s be
- Using UART, a prioritized interrupt or polling system will be used. Both styles of communication can be used to transmit and receive data, and will be tested throughout later phases to compare timing results. Further research will be done on each topic before the finished product is presented.
- Is the communication between the Pi3 and the Pi0s
going to be prioritized?
- If it is found that the Pi3 is not able to handle a certain number amount of Pi0s trying to send and receive information from the Pi3, then certain commands / instructions will be prioritized based on some criteria. This criteria will be created once timing results of the different communication styles have been collected and analyzed. After criteria has been made, then prioritized instructions / commands will be selected.
- Which NCE commands need to be supported?
- Documentation containing the commands included in
the CS were used to make a list of commands that may
need to be supported. The list of commands taken from
the documentation can be seen below.
- return status in AIU
- read and write bytes
- execute macro
- accessories / signals command
- Given the documentation for each individual command was not well documented, further research needs to be done to get a better understanding of what the selected commands do, and which commands need to be supported for the final software design. An example of NCE documentation on commands available can be seen below.
- Documentation containing the commands included in the CS were used to make a list of commands that may need to be supported. The list of commands taken from the documentation can be seen below.
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.
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.
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.
Test PlansTo 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.
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.
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.
To view the live test plan document, please click here
Risk AssessmentWithin 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.
To view our risk register, please click here