P18071: Wireless Concussion Detection/public/
Subsystem Build & Test
Table of Contents
Team Vision for Subsystem Level Build & Test Phase
Planned To Accomplish
- Begin Design of testing rig
- Perform preliminary tests
- Connect web application to database
- Be able to pull data from database
- Assemble the power management PCB and test for the desired functionality.
- Tests were performed at packaging science lab
- Web application can connect to database and pull data
- Assembly of the PCB was finished. Found possible design issues.
- Testing Rig in Progress. Waiting on final materials
Test Results Summary
- Whilst our testing rig was being designed, some tests were still to be run to verify our approach
- Results from the testing session can be seen below
- Our rig to be designed was first laid out in CAD to
plan its functionality and the minor details about it
- Red shows updates to CAD model previously not included to help improve initial design
- With parts we had come in, we were able to construct
the majority of the rig
- Final part additions are to be added on the 19th, due to the final parts coming in over the weekend
- To drop the helmet, a quick release mechanism is to be used in order to ensure the helmet drops properly
- Current model is broken at the pegs
- Possible Solutions
- Switch to wood and screws
- Reprint with stronger density
- Use screws instead of pegs
Raspberry Pi Application
- Finalized the application that interprets the UDP packets from the collector
- Was able to make the application multi-threaded so that when a new packet is received the time that it is blocking the application is minimal
- In the threaded application after the data is interpreted, it is then sent to the database using the procedure that inserts the data into both the recent G force table and History Table
- Worked on stress testing database with high CPU usage
and did not see any drop in preformance when an estimated
load of 10 users was put on the DB
- We will continue testing the DB under higher loads to find the limit of this database set up.
- Finalized Database Structure
- This database structure reduces redundancy as well as reduces insertion/update because of the reduced redundancy
- Procedures created
- Procedure to get the most recent G Force and Battery Data
- Procedure to insert data when new data is available into the recent G Force table and the History table
- Created initial screen that allows users to enter the sensor ID that they would like to view data for
- Added back end code to connect to database and run important queries
- After entering the sensor ID, the web application will then return the most recent data for requested sensor ID
- Determined there will be three types of users that
will need to be determined when creating an account
- Player account : needs to have a sensor ID when creating the account and can only view information about their player
- Coach account: has the ability to create teams with players so he can view all of the players together
- Observer account: has the ability to view individual player data or team data but cannot modify teams
- The PCB was assembled with the exception of the micro-usb connector, which will be attached after a session of troubleshooting an issue that is addressed below.
Battery Source Test
- A single cell lithium-polymer battery measured with a voltage of 3.75V was connected to the input of the PCB (white JST terminal).
- A problem was encountered when no voltage output was found across the output pins. Expected approximately 3.6V
- Suspecting a possible issue with the power plane after measuring the voltage supplied to the ICs from the battery were found to be measuring at 0V as well.
- Found that the input GND pin for the the battery power supply wasn't properly grounded. Grounding this fixed the issue with not voltage flowing through the power plane.
- No output from the linear regulator. Possible cause can be that the two input pins and two output pins must be utilized for a fully functional design. Currently using one of each.
Risk and Problem Tracking
- Like all other phases of the project, the risks involved are always changing and the list of them is being updated. A link to our most recent risk assessment can be found here.
- For our latest problem tracking document, click here.
Functional Demo MaterialsA pre-read document for the review can be located here
Plans for next phase
Individual Four Week Plans
- Complete Testing Rig
- All but hockey puck and quick release parts should be in by Review
- Assist Packaging Science with controlled drop to confirm maximum height
- Attach electronics to helmet
- Begin outline for Final Paper
- Review Potential Design Challenges for submission
- Implement Methods to determine if the sensor has been inactive for 2 minimal
- Finish implementing buffer on Raspberry Pi to store data if database connection is down
- Continue working on sensor Code to only send data when there is a high impact felt
- Continue Creating database functionality to make web development smoother
- Continue assisting teammates with Web application and Battery Board application
- Finish apparatus
- Run preliminary test to ensure we will get high enough forces.
- Adjust as necessary.
- Run systematic drop tests at required angles.
- Run Temperature stress tests.
- Update visual aesthetic of recent impact page
- Incorporate login page
- Add functionality difference between coach and player
- Test data pull for multiple sensors at once
- Keep edge up to date
- Finish Test Rig
- Continue communicating with Packing Science
- Run systematic drop tests at required angles
- Determine final location for helmet components.
- Troubleshoot PCB to find the design flaw. Possibly bring it to a functional state for system integration testing.
- Complete the redesign of the PCB if necessary.
- Assist mechanical team with battery placement and wiring.