P19345: Model Railroad Control Panel
/public/

Subsystem Build & Test

Table of Contents

Team Vision for Subsystem Level Build & Test Phase

Our team vision for the Subsystem Build and Test Prep phase was to build all hardware and software designs and begin testing. This phase, we were able to meet with our customers in the Model Railroad Club and review our project scope and progress. Through communication with the club, it was determined that more capacity will be needed in terms of additional lines of i/o and power for our deliverables. Adjustments to our hardware design and layout are discussed below. These changes affected the completion of all the of the listed test plans and our projected spending. As a team, we now are accommodating parts lead times to finish build. Aside from these changes, the following tasks were accomplished this phase:

Build Summary

Customer Updates on Software and Hardware Build

In the beginning of this phase, we met with our customer Charles and discovered that we were overthinking the route based buttons. The MRC club is looking for macro support for the project. To further discuss this, we walked around the layout and determined exactly where each panel was going to be located so we have a total total number we'll need for the layout at the end of MSD II. Charles said we should probably be able to support a 50%-100% larger layout, so as a team we were required to rethink our design. We determined through research that 32 microcontrollers other than the pi3 is a good ceiling number to start with for communication timing design.
Build Research Reference

Build Research Reference

Hardware

Schematics

The following changes were made to the schematic after discussing with the customer to meet their exact requirements. The changes include adding a wall plug to change 120Vac to 5Vdc with 2A. There was a concern that the 12Vdc hanging around the track wouldn't provide enough current. Then we added a linear regulator to change 5Vdc to 3.3Vdc to power all the components, instead of relying on the 3.3Vdc that the RPi generates internally, as this would not be able to provide the current required to drive any significant number of devices. Both the wall plug and 12 to 5Vdc feature are being built in the PCB to add convenience.

Also, we removed the two 8-3 encoders that were originally being used to interface with the buttons on the control panel, and replaced them with one single GPIO expander. This allows us to utilize the two pins required for I2C communication, rather than requiring 6 pins to read two 8-3 encoders. This brought the total number of GPIO expanders to 5, in order to better meet the customer requirements of the quantity of LEDs and switches we need to support. Additionally, a "hybrid" GPIO expander circuit as added. This allows one of the 5 GPIO expanders to be used for control panel button presses, driving LEDs/signaling, or any combination of the two by making some resistor changes.

This functionality will be discussed more thoroughly in the documentation of the next phase.

New Schematics

New Schematics

PCB Layout

To integrate all of the changes we mentioned in the schematics above, a larger PCB is needed to implement our changes. We created a 10cm X 10cm layout in AutoCAD and imported the board shape into Altium CircuitMaker. We placed all of the power source components on the top of the PCB separate from other components to limit any noise and distortion that may occur. We reduced to 2 standoff for the pi zero because the 40pin header can be its own standoff. The layout for all of the other components is for their convenience.


PCB Routing

PCB Routing

Support Components

With our current PCB layout design, the following information was calculated and is displayed below.
|Number of components supported by our PCB Design

|Number of components supported by our PCB Design

Software

Information about overall software design

For the software portion of the project, various functionality were coded, implemented, and tested. A list of these progressions can be seen below.

Communication between the Pi3 and Command Station

- This task was to get some commands delivered properly from Python code to the Command Station of our test bench. The functionality is needed so it can be said a connection to send data from the Pi3 to the Command Station is established. Code for communication between a device and the Command Station using Python was given by a member of the RIT Model Railroad Club. The basic functionality of moving the locomotive and the switch on the test bench was expanded upon to include more functionality and can be seen in the Block Detection Information Implementation section below.

I2C Microchip LED Implementation

- This task was to have an LED turn on when it's associated button was pressed, or off when the associated button was released, on our prototype control panel. The functionality is needed to confirm the correct data format used by the model railroad system can be used for different functions. It also is needed to provide some basis logic for button presses and LED actions based on the button presses. Code for implementation of the I2C microchip along with timing functions can be seen here.

Block Detection Information Implementation

- This task was to have a Pi receive and decipher block detection information from the Command Station, which got the block detection information from the AIU. This functionality was needed so that an LED would turn on for a control panel when a locomotive was detected on a certain block on our test bench. This is also needed for signaling purposes so that logic can be done with the information to determine if a train should continue, slow down, or stop. As mentioned above in the Communication between the Pi3 and Command Station section, the basic functionality of moving a locomotive and switch on the test bench was expanded upon in code. This expanded code now includes block detection. All files needed to run main block detection script, control.py, are listed below.

Test Results Summary

Before testing different subsystems, the Pi0s and Pi3 currently owned by the team were connected to the RIT WiFi. This was not needed for the overall project. However, it can be expanded upon for future rotations of the project where the project can possibly go wireless. The tutorial used to get the WiFi set up on the Pi devices can be seen with this link.

Different tests were done using both hardware and software components to confirm proper implementation of the different subsystems completed during this phase. Updated tests can be seen in the Test Plan document in either .xlsx format, or .pdf format. An image of one completed test plan can be seen below.


Button Press Testing Data

Button Press Testing Data

In the Button Press Testing, the following information was added to provide more information about the test itself.

Along with providing information to the test plans created in a previous phase, behavioral testing was done for the progressions listed below.

Communication between the Pi3 and Command Station

- Communication was tested by having Python code implemented by a member of the RIT Model Railroad Club send bytes of information to move either a switch on the tracks on our test bench, or by moving a locomotive on our test bench. Correct behavior based on the implemented code was observed. Timing results were not included for this test, but will be included in future testing to provide a basis for timing when it comes to data being sent from the Pi3 to the Command Station.

I2C Microchip LED Implementation

- Implementation and utilization of the microchip was tested by observing the behavior of the LEDs based on button actions. During behavioral testing, it was observed that the LEDs behaved, at first, not as expected. The logic of when the LEDs would turn on and off was not implemented correctly, causing only one combination of button presses to allow both LEDs to be on. After changes in the implementation of the code, it was then observed the LEDs behaved as expected. LEDs turned on and off when the associated was button was pressed or released. All combinations of button presses and releases also caused the LEDs to perform as expected. Along with behavioral testing, timing was implemented in this code. Timing was included to provide a basis for timing for the Pi0's response time when processing an input. Timing results can be seen in the Test Plan document in either .xlsx format, or .pdf format.

LED is on when button is pressed LED is off when button is released

Block Detection Information Implementation

AIU Block Detection Decoding

AIU Block Detection Decoding

When using the AIU information from the Command Station, bytes of data is sent. Certain bits in that bit became 0 when the locomotive was detected on a block. The decoding was used to determine which block is associated with which bit, because there is no specific order or association when a block is connected to the AIU.

Block Detection GIF 1 Block Detection GIF 2 |Block Detection GIF 3

Cost Projection

Current State
Mini Panel Cost

Mini Panel Cost

Switch8-Mk2 Cost

Switch8-Mk2 Cost

Our Design

Cost Analysis

Cost Analysis

Cost Requirement

Cost Requirement

Bill of Materials

At this point in the project we have utilized $508.45 of our $1,000.00 budget. The price per one board is $50. There is $491.55 left over in our budget to spend. However, a majority of the components that are able to produce 5 to 8 PCBs depend on customer needs and changes. We don't anticipate any purchases for electrical parts unless tremendous change is require. Most of the items purchased are used in the PCB along with a few tools necessary for soldering.
New Bill of Material

New Bill of Material

Risk and Problem Tracking

Within our risk register, we assigned all risks with a letter code. The risks we identified were based off of a 1-3-9 rating, 1 being least severe to 9 being most severe. The ratings were given to the severity of the risk and the likelihood of the risk occurring. A risk register graph was created to depict where the majority of our risks fall in terms of severity and likelihood, as well as if any risks are added or deleted out.

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, risk L was resolved and risk Q was re-evaluated and adjusted to show a lower RPN. Risk L represents the risk "Technology needed for project cannot be purchased or is no longer being sold" and has been resolved due to our recent purchases to adjust our design. All necessary parts were able to be purchased successfully. Risk Q reflects the risk "Modular design is too complex for users outside of RIT MRC to replicate" and was re-evaluated to show a likelihood from 3 to 1 and a severity value from 3 to 1. The total RPN value was adjusted from a 9 to now a 1. This is due to an adjustment in our design to encompass a model railroad layout that could be approximately 50% bigger than the RIT MRC (our customer). Also, our design is for the most complex layout presented in the RIT MRC which is the Niagara layout, so our hardware and software reflects the ability to accomodate a difficult layout schematic with capabilities for expansion if desired. This adjustment in design was also to confirm adaptability and use within external customers so that if an external stakeholder was interested in implementing our design, they could do so due to our expanded capability and future deliverable of work instructions for installation and use.

Risk Register Graph Visual Representation

Risk Register Graph Visual Representation

To view a comprehensive list of all active, encountered and resolved risks, please click here. These risks reflect a snapshot of where MSD Team P19345 is at during the Subsystem Build and Test Phase of MSD 2.

External Stakeholder Impact

For this project, our customer is the RIT Model Railroad Club. With the goal of designing our deliverables as open-source and generic as possible, it is important to recognize external stakeholders who may also benefit from our design. At our current state, we are working to design for the RIT Model Railroad's most complex setup, their Niagara layout. As we build our designs and code, we are acknowledging how our build could affect external stakeholders if they choose to follow our design.
RIT MRC Niagara Layout

RIT MRC Niagara Layout

RIT MRC East Niagara Layout

RIT MRC East Niagara Layout

RIT MRC West Niagara Layout

RIT MRC West Niagara Layout

RIT MRC Middle Niagara Layout

RIT MRC Middle Niagara Layout

Number of equipment needed for each layout in Niagara

Number of equipment needed for each layout in Niagara

For example, we have the East Texas Model Railroad Club (ETMRC) with their entire club layout visible below. Ideally, we would like our design to be modular and generic enough that another Model Railroad Club could adopt it within their current system. To clarify, the below image encompasses ETMRC's entire layout where as the RIT MRC Niagara image demonstrates one specific section with complex interactions within RIT's layout.

ETMRC Layout Design

ETMRC Layout Design

To view a comprehensive list of potential external stakeholders located in the North Texas area, please click here.

Plans for next phase

Marianna Palacios- 3 Week Plan

Rui Chen -- 3 Week Plan

Denisse Aquino - 3 Week Plan

Kevin Bradford - 3 Week Plan

Derek Schwartz - 3 Week Plan

Integration Build & Test Phase Team Plan

Integration Build & Test Phase Team Plan


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