Table of Contents
Prototyping, Engineering Analysis, Simulation
Old SD Write Function
New SD Write Function
Upon further examination of where the system actually attempts to write data to the SD card it was found that the system functions did not have proper usage compared to the FreeRTOS documentation. Updated and fixed issues with the function to conform to the FreeRTOS usage. Moving forward we will have to examine how all system functions are used in the code base to ensure they are conforming. This may have been due to an update in the current FreeRTOS version, or was always incorrect.
Feasibility: Prototyping, Analysis, Simulation
- How can we efficiently capture data and write to the SD card in the correct rate?
- How can we learn from the source code and build upon it?
- How can we make the design of the box better, able to withstand higher temperature and more portable?
- 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.
- Testing out various components and questions have been created to ensure that we have the correct answers for what we are analyzing.
- 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.
- 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.
- 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
- 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
- Accelerometer - Acceleration data must be within 5% of the expected value on bench test.
- Vibration and Torture Testing of System and Enclosure - System must be able to withstand volatile in-car environment
- Mounting Bracket Design and Production - Brackets must be manufactured/adaptable to the various mounting locations within the vehicle.
- Lap Time Acquisition - Configuration of timer module to pair to GPS data for timestamps
- All sensors must acquire data within 5% tolerance.
- Device is able to store at least one hour of data to an external storage device 32GB in size without overwriting buffer
Outputs and Destination
- 5% tolerance of all sensors
- Gain a greater understanding of the source code to move forward and create greater progress
- Continuously compare to other concepts to ensure we are on the right track
- Find better and cost-effective materials to create a stronger box