P20225: Doc B Racing Real Time Telemetry

Preliminary Detailed Design

Table of Contents

Team Vision for Preliminary Detailed Design Phase

What did your team plan to do during this phase?

During the Preliminary Detailed Design phase, the team planned on working through each step of the more in-depth designs in groups of two or three, and then meeting together to discuss the designs and making sure the new additions to the product would not interfere with past work. When a new section of the preliminary detailed design was discussed in class, the team members would discuss who would cover a specific part of the design during that phase, allowing no redundant work to be done.

The first part of the preliminary design phase was planned for testing on the previous teams work too see what requirements could be satisfied, and what would have to be modified or added to satisfy both the engineering and customer requirements. The testing was planned to complete sufficient analysis on the current capability of the sensors, the data collection of the SD card, and the user interface software for viewing the data collection and adjusting the sensors. During the testing the use case scenarios for operator setup/configuration and for driver saving data on SD card were simulated and tested, while the use case for driver sending data over Wi-Fi was not as the Wi-Fi capability has not yet been added too the product as it is still being designed. The testing was planned to show how far the team is away from satisfying all requirements, and what design changes will allow the product to demonstrate feasibility for both the hardware and software.

Once the testing and simulation was completed the feasibility questions, assumptions, and approaches from the Systems Design phase were modified based off of the information gathered during the testing. The feasibility questions were planned to be modified since the testing would answer some of the questions from the previous phase, while bringing up new questions. The three questions chosen for the EDGE page will be the three major topics discussed during the testing and simulations.

After the feasibility was completed the team planned to work on the schematics of the hardware and software, and more in-depth system level design flow charts. The schematics were planned to be used from the previous teams’ work, as the hardware portion of the design is going to be kept generally the same. The changes that will be made to the hardware will be shown in the schematics and flow charts, to show why the team choose to change what the previous team did, and how it will benefit the system. The systems flow charts and design were planned to show the software flow of the system, and how the data will be able to flow from the sensors to the SD card as in the Systems Design phase, but in a more detailed manner. From the schematics and flow charts made, the team will also update the Bill of Materials with what has been and will be bought. The team will also show the previous teams BOM, to show what materials are currently in use and have already been purchased, so that the current teams funding can be used towards different acquisitions.

Along with the testing, feasibility, and schematics the team will also be working on updating the risk assessments from what was gathered during the testing phase. The team will look at the likelihood and severity of risks added before and see if they can be moved down after the testing and simulation was completed. The team also planned to show what was found during the simulations in the test plans portion of the preliminary detailed design. By doing this the team would show what the purpose of the testing was, along with what was found and what needs to be added/changed to the current design to improve its functionality. Lastly the team will plan to complete their three-week plans to show what they each have individually completed, and to show what they plan on completing in the next phase.

What did your team actually accomplish during this phase?

During the Systems design phase, the team completed all of the steps planned by working together during senior design class and at home on Google drive. The testing and simulation of the previous teams’ work was completed during the senior design class in the laboratory, and the team used the simulation that was used from by previous team during Imagine RIT last year, to show the functionality of the sensors and the data throughput of the SD card, along with the user interface. The testing was done numerous times to show the feasibility in the sensors and the SD card data collection, along with the ability to flash the SD card so that it would receive the data from the sensors properly. From the testing the sensors and SD card data collection were found to be working properly, while the user interface to see the data and change the sensors setting was not functioning properly. The team plans to continue to work on getting the user interface to function properly, along with talking to the previous teams’ member for help on fixing the issue. Besides the user interface, the requirements for the SD card and the sensors were found to be satisfied from sufficient analysis, as will be discussed in the prototyping and test plans sections of the preliminary detailed design phase.

The feasibility questions from the previous phase were modified from the information gathered during the simulations and testing. From the previous phase, the question on how accurately of a speed can the sensors measure was taken out, and the two other questions were modified to from the different priorities seen form the stimulations. A feasibility question was added about the source code from the previous team as that is where a majority of the changes from the previous team will take place, and it is best to understand everything about the code before the current team goes to change or modify anything. The other feasibility topics stayed on the SD card capture data and the design of the box, as they are the two other main changes that are being discussed and designed by the team currently.

The hardware and software schematics and flow charts were first started by looking at the previous teams’ schematics and seeing if anything needed to be added or changed. If nothing needed to be changed from the previous teams’ schematics it was left the way it was and added to the hardware or software schematics or flowcharts area. The schematics and hardware that needed to be modified, like the PCB, are discussed in the schematics section of the EDGE page, and the materials needed to be purchased to be added to them were added to the BOM. From going through the materials, the previous team left, the BOM was updated with purchases needed to continue to do testing and simulation, such as deutsch connectors, and to improve the functionality of the PCB, such a s a USB port.

From the testing, the risk assessment was updated, taking out the risk of going over budget, and adding new mechanical risk for the enclosure design and accelerometer and usb additions to the PCB. The team also showed what testing was done and how in the test plans area, to show the degree at which the engineering requirements were satisfied, and the accuracy of the feasibility models. Lastly each team member completed their individual three-week plan, and the whole team worked together to decide where they want to be in three weeks during the next review.

Prototyping, Engineering Analysis, Simulation

For this phase a basic analysis of the internal temperature that would be seen by the board was performed to ensure that the SD card function would not be impaired. As can be seen on the plot, as long as the temperature does not exceed 80C the SD card should survive.

Feasibility: Prototyping, Analysis, Simulation

Feasibility Questions

  1. How can we efficiently capture data and write to the SD card in the correct rate?
  2. How can we learn from the source code and build upon it?
  3. How can we make the design of the box better, able to withstand higher temperature and more portable?


  1. The data can be captured and seen on a console; however, the rate at which it is capturing it is faster than at which the SD card can take it in.
  2. Testing out various components and questions have been created to ensure that we have the correct answers for what we are analyzing.
  3. Making a smaller design would allow easy-to-fit spaces and placing the box in a low temperature spot would help it not damage any of the internals. Either a stronger plastic or different, but cost-effective material would help.


  1. The SD card problem lies within how fast data is read from the vehicle and when it starts to write to the actual SD card. A delay mechanism needs to be implemented in which the the data can be read and then a delay is applied in which the data will be stored; after this, data will be written in big chunks to the SD card. New data will then be stored in an array while the data written to the SD card will be in another array. Emptying the array which is written to the SD card will allow for the other array to populate into the new one. This process of using two arrays will add a delay factor by populating and emptying each array. This will be called an inverted buffer. An example of this method is provided below.

https://edge.rit.edu/edge/P20225/public/Photo%20Gallery/SD_Part1.PNG https://edge.rit.edu/edge/P20225/public/Photo%20Gallery/SD_Part2.PNG

  1. Currently, source code is available to be viewed for the SD card data processing. The source code has been analyzed and questions about the source code have been written. Continual division of labor within the group is required to assist within reading the code. This will aid within speeding up the process taken to understand the code-base
  2. New materials need to analyzed to ensure that the box can withstand high temperatures and fit easily in any compartment. Ceramic Polymer and other sorts of plastics have been looked into in regards to the temperature process; furthermore, new sizing of the box has been taken ensure a better fitting for the future.

Inputs and Source

Outputs and Destination

Hardware Schematics

Power Schematic

Analog Front End





CAN Transceiver

USB Circuit

Subsystem Flow Charts

System Architecture (From Last Phase as Reference)


Input Control Processing


Configuration Conditioning


Output Data Processing


Output Data Conditioning and Write Back


The subsystem flow charts illustrate, in detail, the logic which will be used to implement each major components of the system architecture through software processing on the micro-controller.

Bill of Material (BOM)

Completed BoM and Budget

Test Plans


The purpose of the testing plan this phase was to ensure all sensors function properly from the previous Imagine Day; furthermore, the SD card data storage method is to be finalized.


Throughout this phase:
  1. Initially began via testing the component from the Imagine Demonstration the previous team worked on to ensure the sensors tested from last year work with live-time viewable data.
  2. A discussion with the previous team was held to understand where the project currently is and how to get previous year's demonstration up and running.
  3. The previous team guided us on moving forward into the data acquisition portion. A concept of an inverted buffer was discussed as a possible method for storing data at an appropriate rate. Pseudo-code was written to figure out how to implement such a strategy.
  4. Hardware schematics were analyzed to understand the layout of the PCB board.

Inputs and Source

Outputs and Destination

Risk Assessment

Design Review Materials

Link to PowerPoint Presentation below:

Plans for next phase

As a team, where do you want to be in three weeks at your next review?

In the next phase the teams’ goal is to complete the detailed design of the system by the next review. During the detailed design completion, a progress report should be sent to the customer during the week of Thanksgiving break. The progress report will tell what the team plans to accomplish during this phase, what task have been accomplished in the previous phases, what are the remaining task and what team member is responsible for it, what decision on the product have been made final by the team, and what questions still remain for the customer to continue moving forward with the completion of the design. In the progress report the previous teams work will be reported as well, to show what will stay the same and what designs will be modified or added. During the next phase more testing and simulation will take place as well, to try and get all sensors tested, and to get the user interface functional. Along with the testing the drawling, schematics, flow charts, and simulations will be recorded and written out thoroughly enough so that another team could recreate what we have done just from what is posted on the EDGE page. The team will also update the Bill of Materials, Test Plans, and Risk Assessments as the simulations and testing goes on, as more various testing will take place once each sensor is found to be functional in sending data to the SD card. Once each sensor in operational in a simulated version, they will be than taken to a track or placed in a normal car to test in the real environment, along with the test of the wire harness. The designs and flowcharts will also be update from the previous phase if anything is changed, and the final goal of the next phase is to figure out what is needed to prepare for MSD II.

Individual Three-Week Plans Below:

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