Sudden Impact Challenge - Blog Entry 2

Its been a while since my last update. In this time I have received the contest kit, which I will outline below, and outline a basic approach to move forward taking into account the short period of time left for this project. There has also been some analysis done on data rates and possible data representation for end users.

Kit Outline

The kit came with everything as expected. One big Tektronix box with the oscilloscope, four brown boxes one each with the AD8232 breakout board, evaluation kits for the ADXL375, ADXL362 and with the ADuCM350 development kit. Lastly there was the ADT7320 flex board and the ADXL377, ADXL375 and ADXL362 breakotboards. All the break boards were well sized to include just main components with its needed external components as well as space for a through hole connector. Opening everything at once was rather overwhelming. At this point it was decided a plan was needed to move forward, the previous one step at a time and hope it all works was not going to work.

Project Outline

Looking at what parts there where, their complexity to use and the project duration an outline was formed. As there is no way to use this project fully without a user interface (maybe a flashing LED in case of severe injury…) this was determined to be the first step. It allows for parts delays and other unforeseen issues to carry on while work moves forward. For the interface I have decided to use QT due to its apparent simplicity as well as due to the easily available help I have due to its use in my work place.

While I work on the interface there is the need for the embedded code to move forward as well. For this an MSP430F5529 will be used for two reasons. Firstly it integrates easily with the CC3100 that will be used to transmit the data back to the PC. Secondly it is relatively easy to use and with only two months to complete the project using a controller and IDE that is known will help save precious time. Unfortunately do this this choice the possibility of using the heart rate monitor may be reduced do to the abilities of the MSP430F5529. During this time all code will be written in a hardware independent nature so as to allow for switching the controller at a later date should the possibility arise.

Keeping the available time frame in mind the sensor choice has also been reduced. The system will start with just the two high g accelerometers and a temperature sensor. This will allow for a basic system to help iron out the basic bugs. Also as these sensors do not need any intense calculations to get them up and running their data will be useful to test and work out any bugs in the WiFi connection as well as in the the user interface. One main aspect that will be attempted will be to have a hardware abstraction layer to allow for the overall system to be ported to a separate microcontroller at a later stage should time permit,

System Capabilities

Looking over the system there was a clear need for a single wireless connection that could handle all the data. A quick calculation was done to determine what bandwidth was needed in order to allow for a better choice of wireless protocol.

Figure 1. Data Flow & Data Rates as Data Moves through the System

At the above calculated data rate of 264 kbps there was no real choice other than WiFi. While for a single player or even two players other options may be possible, for a full team the data rate quickly climbs above 1Mbps and only WiFi has a practical data rate above 3Mbps. While in theory the WiFi can handle the data rates for a team of players it is unclear at this point if the range needed to cover a hockey rink is possible. As the design moves forward this will be tested and hopefully resolved.

Basic Sensor Fusion

Due to both the relatively high data rate needed as well as the need to verify data values using redundant data the system will incorporate a very basic form of sensor fusion. To reduce noise in the system only shocks above a predetermined threshold will be registered. The accelerometer data will be combined to using an as yet undetermined algorithm (potentially simple averaging will produce sufficient results). This single result will be relayed back to the PC helping to reduce the required bandwidth as well as presenting the end user with only easy to understand data. In the first iteration there will be only one temperature sensor but there is a hope to add a second sensor. Having two sensors positioned on the temples will allow for a easy averaging and easily averaged results that should yield a consistent and repeatable body temperature.

Figure 2. Simple Representation of How Data Will Be Merged in the System

User interface

The other aspect of the design that has been looked at and has been started is the user interface. The concept is to have an uncluttered easy to read and understand interface that allows for anyone to quickly understand the situation of a player. For this reason there is both a text based output as well as a graph based output. These together allow for both an immediate situational understanding as well as a context to be added to the current situation to help understand the whole situation. For now there is no method for looking at more than one players information but the hope is to add in tabs or a drop down menu to allow a user to select an individual player to view in detail. Also in order to allow for a coach to quickly identify an issue even if the coach is not viewing a the information of a player who may be in trouble that players tab will flash yellow or red depending on the severity of the situation, there may be the potential to rather automaticly switch tabs so immediately the coach could see the relevant information.

Figure 3. Simple User Interface Displaying All the Relevant Data in an Easy to Understand Format

Original post on Element14 can be found here