Foot Acceleration Sensor: Vicki Chuang and Laura Sharpless

Introduction

This project was designed to aid a research study by Cornell Professors Bob Nafis and Yingxin Gao on the reasons behind the higher rate of ACL injuries suffered by female athletes. This injury rate can be up to three to eight times higher than the rate of similar injuries suffered by male athletes. The project focuses on creating a set of electronics using an Atmel ATmega324P microcontroller that can be worn on soccer cleats to measure shocks to the foot during play.

Using an accelerometer to measure the acceleration of the foot during walking, running, and play, we send gathered data via a wireless XBee connection to another microcontroller connected serially to a computer. Importing the data into Matlab, we are able to plot and analyze the data, comparing to different thresholds of walking and running. The purpose of the project is to compare data obtained during athletic activity with normal activity to see if there are any differences in acceleration that the foot experienced that could have caused or lead to an ACL injury.

High Level Design

There are two main components of the project. The accelerometer sensor that is attached to the foot along with a transmitter, and the receiver station attached serially to the computer.

The accelerometer sensor consists of a Kionix KXSD9-2050 three-axis accelerometer, XBee wireless transmitter, and an ATmega324P microcontroller. The receiver station consists of an XBee wireless receiver, ATmega324P microcontroller, and Max233 chip for RS232 serial communication. The sensor takes acceleration data from the accelerometer, creates packets of 15 sampled data points along with the time they were obtained, and transmits the packets wirelessly to the receiver. The receiver then parses the packets and responds when Matlab requests data over the serial port. The high level design is shown in the following block diagram.

Figure 1: High Level block diagram of project

Hardware Design

The two major hardware components of the project are the wireless connection implemented through XBee transmitters and the accelerometer to determine acceleration of the foot during walking and running. Because we require two UARTS to simultaneously interface with the XBee and the serial, we decided to use the Mega 324P microcontrollers because they have two hardware UARTS, as opposed to writing a software UART.

Because both the XBee transmitters and the KXSD9-2050 accelerometer run at 3.3 V, we designed our MCU prototype boards with a 3.3V regulator (LP2950CZ-3.3-ND) to obtain the correct Vdd for the project. On the sensor end, the accelerometer was connected to the SPI pins on PORTB and the XBee was connected to UART0 through pins D0 and D1.

On the PC end of the project an additional connection to the computer through a MAX233 chip and serial port is required. Since UART0 on the microcontrollers is reserved for the XBee modules, the RS232 connection is through UART1. Schematics of the two systems can be found in the appendix.

XBee Modules:

We implement a wireless connection in our project to transmit data from a wearable accelerometer on the foot to a computer for analysis. This connection is made with two on-chip antenna XBee wireless modules (XB24-ACI-001) operating at 1mW transmitting power. They interface with the microcontroller through the UART and operate in the XBee’s API mode. Both receiving and transmitting XBees are configured with AT commanding to have the following properties, allowing for correct transmission:

38400 baud rate
API mode enabled
Module local address is set to enable 64-bit addressing
Channel Mask set to 0x1000 to only transmit and receive on channel 15
Sleep Mode set to 1 on the transmitter side to enable Pin Hibernation when there is no useful accelerometer data (when the person is standing still) to save power. This reduces current draw from 200 microAmps to <10 microAmps.

Since the XBee transmitters interface with the UART on the microcontroller, we chose to use the ATmega324P which has two built-in UARTS. The XBee interfaces with UART0 on the Mega 324P microcontrollers and on the receiver end, the serial to PC RS-232 interface interfaces with UART1. Dout on the XBee is connected to the RX pin of the corresponding UART and Din is connected to the TX pin. The XBee's also have a pin spacing of 2mm which is incompatible with the 0.1" standard spacing on solder boards. To convert the spacing, we used a breakout board (BOB-08276) and 2mm sockets (PRT-08272) obtained from SparkFun that converted the 2mm pins of the XBee to 0.1" headers to attach to our project.

Kionix KXSD9-2050 Accelerometers:

The KXSD9-2050 is a three-axis accelerometer that we use to gauge foot acceleration during walking and running, which relates to effects felt by the knee due to foot impact and twisting. Since the accelerometer comes in an un-solderable by hand 3x3x.9mm LGA package only, we use a Kionix pre-soldered evaluation board to interface the accelerometer with the SPI on the microcontroller. Datasheets and schematics for the accelerometer, evaluation board, and pin numberings can be found in the appendix. The appropriate SPI lines are connected through PORTB on the microcontroller. The accelerometer is configured through two control registers, reg_B and reg_C, set during initialization and the following configuration is used in this project:

±4g range scale with a 12-bit sensitivity of 410 counts/g
A Motion Wake-Up Threshold of ±2g
A Filter Corner Frequency of 50 Hz (the operational bandwidth of the accelerometer)

Hardware Difficulties:

The trickiest part of the hardware design was getting the accelerometers to work. When we first tried the accelerometers, we received junk as output and could not find anything wrong with the SPI code. We tried all different combinations of clock polarity and clock phase to determine if it was a timing issue, but the results didn’t change. Since all of these did not work, we assumed that the accelerometers may have been blown since we had accidentally run them at 5V although they were only rated for 3.3V. We ordered replacement parts, but saw the same effect as before: capacitive coupling between SCLK and the HI-Z output. After many headaches, we finally were able to discern the problem.

Figure 3: Pin Layout of the Accelerometer Evaluation Board

Since pin numbers on the Kionix evaluation board schematics were unnumbered, we first assumed that it followed usual (MCU) convention with pin numbering 1 through 7 down the first column followed by 8 through 14 up the next column. This was incorrect, however, as the pin numbers actually increased across the rows instead of down the columns. Due to incorrect pin connections, the accelerometers had not been attempting to receive or send data, and were not even powered up. After encountering the same problem with the new accelerometers, we discovered the incorrect pin connections after close examination of the the schematics. Figure 3 shows the actual pin numbering of the evaluation board.

We also ran into problems using the XBee wireless modules. After solving basic software connection problems, we were able to transmit and receive, however it was very unreliable, with a very high percentage of packets getting dropped. Sometimes it would start on power-up, and other times, we had to keep resetting until we could find a connection. Sometimes it wouldn't work unless we power cycled the receiver XBee module by unplugging its power cables and then plugging them back in to start receiving. To solve this problem, we first tried to reduce the channel scanning time by only transmitting and receiving on channel 15. This helped a little bit as we were able to find a connection more often than before, but it was still unreliable on restart and power up of the microcontrollers. The eventual solution was to increase the baud rate of the XBee modules. Originally we were running them at 9600 baud rate to coincide with the UART baud rate for simplification. By changing the baud rate to 38400, a 4x increase, we decrease the percentage error caused by running the MCU at 16MHz. At a baud rate of 9600, there are .0006 bits received/cycle, while at 38400, this increases to .0024 bits/cycle, so the receiver has a lower error rate. Once we changed the baud rate to 38400, the XBee wireless connection became completely reliable, and a connection is immediately established if both transmitter and receiver are powered up at the same time.

Hardware Pictures:

Figure 4: The Wearable Accelerometer and transmitter

Figure 5: The Receiver Station

Software Design

Two ATmega 324P microcontrollers were used in the project, one for transmitting and one for receiving. They each had their own individual main code since their functionality differed, but the wireless link source code was the same to ensure link stability. The link source code was based heavily on the XBee network code from Adam Shapiro. Using Matlab, we import the data from the receiving microcontroller to the computer through the serial port and plot the data to show acceleration versus time. All of this code can be found in the appendix.

Common MCU Code:

Both MCUs are clocked by a 16Mhz crystal, which is set to divide by 64 with OCR0A set at 250to create a 1 mS interrupt through Timer0. In this interrupt, Link_UpdateTimers() is called to update link_activityTimer, which influences the Xbee’s wireless link refresh rate. Main() initializes the ports and timers, as well as the UART flags, then calls turns on interrupts with sei(). Link_Init(0) is then called, with DEVICE_TYPE=1 for the transmitter and DEVICE_TYPE=0 for the receiver, declared in the project settings. This initializes the Xbees as a transmitter and receiver, respectively. The argument of Link_Init() specifies the UART that the Xbee should use to communicate with the MCU. Since the Mega324P’s have two UARTs, UART0 is specified so that the receiver can use UART1 to serially interface with Matlab.

The MCUs also rely on the same Xbee .c and .h files found in the appendix. These were obtained from Adam Shapiro and modified slightly for our purposes. The main modifications took place in link.c for Link_Init(). Since his code was developed for Xbee networks, we removed the router specifications (in this file and in the others) and changed the file to only reference UART0. We also modified the channel mask to only allow communication on channel 15. The majority of the rest of Adam’s code remains structurally unmodified.

Transmitter Side:

The transmitting side of the project includes the accelerometer and the XBee wireless link. The microcontroller is programmed with xbee.c. xbee.c polls the accelerometer for data at a rate of 1kHz using SPI in the main while() loop. This was done to regulate the data acquisition rate with the transmission operation and is implemented by setting dataFlag in the Timer0 Interrupt Service Routine. When dataFlag is set and there have been less than 15 data points sampled (the size of a transmission packet) as counted by the dataCounter variable, then the accelerometer is polled by calling get_Accelerometer(). When 15 data points have been sampled (dataCounter = 15), then there is enough data to form a packet for the XBee to transmit. Because there is overhead of 14 bytes in packet formation, sending anything less than 10 data points at a time is not practical. The data registers x_hi_data, y_hi_data, and z_hi_data along with the acquisition time of each, savedTime, is copied into the 60 byte data transmission array. This data array becomes the payload of the transmitted packet. Link_Execute() is called to check the status of the XBee’s wireless link, and the packet is sent with Link_SendFrame() if the XBee transmitter is not in sleep mode.

The accelerometer is polled for data using SPI in get_acceleration(). The microcontroller is the master and the accelerometer is the slave in our setup. To acquire a data point, the accelerometer SPI specification requires the microcontroller to send the 8-bit address of the desired register which corresponds with XOUTHI, YOUTHI, or ZOUTHI to return the upper 8 bits of the 12-bit acceleration data. After delaying 200 µs for the A/D conversion by the KXSD9-2050 as specified in the datasheet, the accelerometer will return the corresponding byte of data. These points are stored in their corresponding data arrays to be created into packets for the XBee after 15 data points have been polled. In order to count 15 data points, dataCounter is incremented each time this task is called. The savedTime register stores the time in milliseconds of each data acquisition so that an acceleration vs. time plot can be created on the receiving end.

Since the transmission side of this project runs on battery power, we want to conserve power when the wearer is standing still and thus not acquiring useful data. When this occurs, we want to stop data transmission and send the XBee transmitter into a sleep mode where it will consume less than 10 micro-Amps of power versus the 200 micro-Amps consumed when enabled. The wake-time is 13.2 mSec, and this is a trade-off of losing the first 13 initial accelerometer data points, but considering the application of this project, can be considered negligible. To implement sleep mode on the XBee, the command to set the SM property of the XBee to 1 for Pin Hibernate is done through a direct connection of the XBee to the UART and serial port. When this property is set, pin 9 of the XBee controls whether the XBee is in sleep mode (Pin 9 high) or in transmit mode (Pin 9 low). When the accelerometer has been in the same state (consistently very little or no change in acceleration) for more than 5 minutes, we send the transmitter into sleep mode. To do this in the code, we check the acquired accelerometer data in get_acceleration() and compare it to the previous value by taking the absolute value of the difference. If this value is less than 20, accounting for minor variations due to vibrations or shifting weight, then the sleepCount variable is incremented if the transmitter is not already asleep (checked by the sleeping flag). If there are significant changes in the acceleration warranting movement, then the task will check to see if the transmitter is sleeping. If it is, a startup flag will be asserted to start transmission again the main loop, and if not, sleepCount will be reset to 0. At the end of the task, the previous x, y, and z acceleration values are reset to the current ones for the next round of data acquisition.

In the main loop, if sleepCount is greater than 300000 (5 minutes since this is incremented every millisecond) then this means that the accelerometer has not moved significantly in 5 minutes and this most likely means that the wearer is standing still. When this happens, PORTD4, which is connected to Pin 9 on the XBee, is asserted and the XBee enters sleep mode. The sleeping flag is also set to indicate that the transmitter is currently asleep. If the sleeping and startup flags are both set, then this means that the XBee has been signaled to wake-up. PORTD4 is set back to 0 to enable the transmitter and all the flags are reset to 0 to restart the sleep timer.

Receiver Side:

The receiving microcontroller is programmed with xbee_rx.c. xbee_rx handles the receiving end of the wireless transmission and creates a handshake with Matlab to transfer the accelerometer data. There is a second ISR which is a nonblocking UART driven receive. This ISR builds a string in r_buffer and asserts r_ready when the string has terminated with a carriage return, then turns off the receive ISR. The function receive() removes the new string from r_buffer, resets the UART flags and turns on the receive ISR to wait for a new string.

Main() solely initializes the necessary port, timers, and flags, then transfers control to the main while(1) loop. Link_Execute() is called to check for inactivity, then the Xbee receives a packet. If the return type of this reception is LINK_TYPE_RX, meaning the packet was valid, the packet’s payload is parsed into rxBuffer and the rxHead pointer is incremented by 60, the payload’s length. rxBuffer is a FIFO 960 byte array which stores the accelerometer data until Matlab can retrieve it. After this, receive() is called to check for new input from Matlab. If there is new input, a data point is printed to UART1 in the form:

((xAcceleration yAcceleration zAcceleration time))

This formatting is necessary to ensure that the Matlab / MCU handshake is successful with a complete data point sent and successfully received each time. After the data is sent, rxTail is incremented by 4 to point to the next new data point. If there are no new data points in rxBuffer, represented by the condition rxHead = rxTail, then a carriage return is printed. This is to ensure that Matlab doesn’t hang while waiting for new data from the MCU, when none is available. This event loop is iterated through until the MCU is turned off.

Matlab Code:

To run the Matlab interface, accelerationGUI.m must be loaded and executed. This will load the GUI used to interface with the receiving end of the wireless link, shown below in Figure 6.

Figure 6: Basic Acceleration GUI

After ensuring that the correct serial port is shown in the control section, press the ‘Start Plotting’ button. This will begin getting data from the MCU and plotting the acceleration’s magnitude and x, y, and z components in separate plots. Data reception can be paused by pressing ‘Stop Plotting’ and the plots can be cleared with the ‘Clear Plot’ button. The ‘Status’ box in the top right corner displays messages about the status of the connection and your recent actions in the GUI. When Matlab does not receive data points for a few seconds, the transmitter is assumed to be sleeping, and the user is informed that plotting has paused. The ‘View Threshold’ dropdown menu allows the user to display ‘Walking’ or ‘Running’ thresholds on each plot, which are calibrated to that axis’s response under each condition. When points are outside of these thresholds, they are of more concern than points within the thresholds, which are considered to be within the realm of normal user activity. The ‘Data File’ text box allows users to specify the file to which accelerometer data should be logged.

The Matlab GUI was structured through GUIDE, the Matlab GUI design tool, so the initialization code and callbacks were provided after the interface was designed, which is available in the appendix along with the Matlab code. accelerationGUI() initializes the basic GUI, and all of this code was provided through GUIDE. accelerationGUI_OpeningFcn() provides the structure for the GUI, initializing all of the serial variables to be part of the GUI’s handle, and setting up the four plots. serialPort_Callback() is called when the ‘Serial Port’ field is changed in the GUI. This merely sets the variable handle.s to the desired serial port. dataFile_CallBack() performs a similar task, setting handles.dFile to the desired datafile, and then initializing it if it doesn’t already exist. thresholdPullDownMenu_Callback() sets handles.wThresh and handles.rThresh appropriately based on the selected value, to control the visibility of the walking and running thresholds on the plots.

startButton_Callback() contains the main program for interfacing with the MCU and parsing and plotting the retrieved data. First, the log file is created if it doesn’t exist, then the serial port object, handles.s is created with the specified port, a baud rate of 9600, a Terminator of 13, and a Timeout of 1. This means that the port will communicate at 9600 symbols/sec with the MCU (also set with a baud rate of 9600), each sent/received line will terminate with a carriage return, and the waiting time for receiving data is a second. This serial port object is then opened, is not already open, and startButton’s ‘UserData’ field is set to 1. This is important for ensuring that the function will actually stop when stopButton is pressed. So while this field is still set to 1 and the serial port is still open, a space is printed to the port, then three fgetl() functions are called with pauses in-between. The first two parse out the empty lines, and the third gets the actual accelerometer data point. The pauses are necessary to ensure that the entire line/data point is obtained each time, so this gives the MCU enough time to print to the serial port.

As long as the returned value is enclosed with parentheses, ‘Status’ box in the GUI is updated to reflect the fact that there is new data coming in from the serial port, then the returned value is parsed as a string, the parentheses are removed, and the string is tokenized into four parts, the x, y, and z acceleration magnitudes, and the time the sample was obtained. These are converted to numbers, and the time is updated to reflect the actual time.

Note: Since the Xbees transmit bytes of data and a packet is 60 bytes long, only the lowest byte of the transmitter’s system time is actually sent to the receiver, so Matlab needs to rebuild the actual system time from the lowest byte. This is done by storing the last received time, and incrementing handles.tcount by 256 when the current time is less than the previous time. This assumes a one-byte overflow each time the time value wraps around. Although this is not the most precise way to maintain the time value, it is more economical in terms of wireless transmission. When the transmitter goes to sleep or rxBuffer overflows (and thus overwrites valid data), the actual plotted time value is wrong, but while the Xbee transmitter and Matlab are interfacing with the Xbee receiver, the time values are all accurate relative to each other.

After the time value is updated, the temporary y, z, and time variables are added to the log file and checked for validity along with the remainder from parsing the string. This again ensures that the data point is valid. Only then is total number of samples incremented. If the total number of samples (handles.numSamples) is less than the desired number of samples to be displayed on the plots at a time (handles.tend), then the x, y, z, and t values are appended to the arrays, and the acceleration’s magnitude is calculated and also appended. If there are more samples than handles.tend, the first value in each array is removed and the new value is appended. Then each plot is updated with the new arrays using the set() command to save time. Then the walking and running threshold lines are plotted in green and red if handles.wThresh or handles.rThresh, respectively, are valid. If not, the lines are re-plotted in white, to erase any old lines. The values of the respective thresholds were obtained from testing in lab to determine the distribution acceleration within each axis for each activity, and thus each is merely a guide. A screenshot of the GUI showing thresholds along with walking (1) and running (2) data is shown below.

Figure 7: Acceleration Data for walking(1) and running(2)

If the data obtained from the MCU has repeatedly been an empty string, the transmitter is assumed to be asleep, and thus not providing new data, so the ‘Status’ box in the GUI is updated to reflect this. When the serial port cannot be opened, the ‘Status’ box is also updated to reflect this for the user.

stopButton_Callback() merely updates startButton’s ‘UserData’ field to 0 and the ‘Status’ box to reflect that plotting has been stopped. Once the startButton_Callback() function rechecks the ‘UserData’ field, the plotting iteration will stop and exit the callback. The stopButton callback is also responsible for closing the serial port. clearButton_Callback() solely repaints the thresholds and resets the applicable arrays and variables, then replots the arrays to return the GUI to its initial state.

Software Difficulties:

The trickiest part of the creating the program was getting the XBees to transmit and receive wirelessly. The devices are fairly complex and the datasheet was not written for people who had never used Xbees before, only as a reference for those familiar with the devices. By debugging the connection with Adam and ensuring that packets were being sent by the receiver using an oscilloscope, we were able to debug the receiver until it could establish a link every time.

Transferring data between the receiver and Matlab had a slow learning curve. We initially printed data to the serial port as it arrived, but over half of the data points were lost in the process. Then we determined that a handshake between Matlab and the MCU would be the best way to transfer data. This involved understanding the ‘Terminator’ character and Matlab’s explicit interaction on the command line with the serial port. After this was fixed, we were creating moving plots in real-time, but it was not very user friendly, so we ported it to a GUI.

The Matlab code was straightforward while it was one large function and while(1) loop, but once we tried to import it into a GUI, the code became significantly more complicated the code. The process was also complicated by the fact that neither of us had programmed a Matlab GUI before and thus half of our problems were with Matlab and not with the actual serial port / accelerometer data.

Results

The delay between an acceleration event and the data being displayed in the GUI is about 3 seconds. In this time, the accelerometer has produced 15 acceleration values for the x, y, and z-axes, this data has been wirelessly transmitted to the receiver, and Matlab has obtained this data a single point at a time and plotted it. The Xbee link ensures data coherency using a parity bit, and the receiver/Matlab handshake also ensures a correct data transfer. Thus the only room for error is in the accelerometer’s A/D conversion, or error in the final data due to the relatively slow (1 KHz) data sampling rate. Thus data that is plotted has a very low error rate, which is essential for this application, and the relatively real-time plotting is convenient.

This device is completely user friendly due to real-time plotting as well as a basic user interface. The GUI provides a simple interactive interface to the receiver; it just needs to be loaded after the receiver has been turned on. The transmitter is also quite user friendly; it is a complete package which can only be turned on and off. The only slight problem associated with the final result is that if the transmitter and receiver are not turned on almost at the same time, sometimes the connection will not initialize. But power-cycling both devices reinitiates the link and data collection can begin.

Since this device utilizes the XBee modules, RF interference can occur if other projects are also using the XBee frequency of 802.15.4 on channel 15 which is the channel we are broadcasting on. WiFi may also be a potential source of interference as the XBee frequency is the same as WiFi.

Safety issues involved with this design center around the wearer’s contact with the transmitter. By insulating the 9V battery and making the packaging as compact and protected as possible, the user is protected from any electrical problems with the transmitter. Also, the device was designed with the final goal of fitting inside the user’s shoe, so as a prototype, there are few potential electrical shock problems that the final version would not solve. The final version would be completely insulated from the user, thus removing all hazards due to shock. The receiver does not come into contact with the user other than during power up and power down, so that end is less of an issue. The other safety issue with the transmitter is that it could poke or jab the user during data collection, so the transmitter needs to be completely secured to the user’s foot to ensure safety as well as accurate data collection: if the accelerometer does not closely follow the foot’s motion, the data will become invalid.

Conclusions

The final transmitter measures about 2x2x3 inches, which is much too large to fit in a shoe. This is the only part of our final design that did not meet our initial expectations. Using a 9V battery instead of a 3.3V lithium-ion battery significantly increases the transmitter size and weight, as does the use of the accelerometer evaluation board and large XBee breakout boards. If the resources and time had been available, we would have liked to compile all the components onto a single PCB board with a CR 3.3 V battery to vastly reduce the size to be able to fit inside a shoe. Besides this, we are able to plot data from the accelerometer in real time, consistently and accurately, while being mindful of the transmitter’s power consumption. All of these are imperative to a successful working transmitter / receiver pair, and by fulfilling these, our project was successfully completed.

We received significant help from Adam with the Xbee code, but he had previously released this and thus since it is open source code, there are no intellectual property problems on that end.

Since the project was developed with guidance and support from a Cornell research team, we will be handing the hardware and software off to them for continued development. But at this point, the code we have developed can be released as open source because we have intellectual property rights to the code and hardware, and since we are not looking to publish or obtain patents, others could benefit from the release of our code.

There are few legal issues associated with this project besides the issue of intellectual property rights. The accelerometer, MCUs, and Matlab are not regulated, so only the wireless transmission is of legal concern. The Xbees operate according to the IEEE 802.15.4 protocol, operating in the 902-928MHz unlicensed band in the United States. The Xbees have been approved by the FCC, and since we have not done anything to change the band on which they are broadcasting or the protocol they use, our project does not have any legal implications.

A discussion of legal issues should only be followed by a discussion of a few ethical considerations related to this project, with the main one being that the focus of this research is women and the benefits derived from this research will benefit women significantly more than men. Because the research is only being done for half of the population, one could argue that the research is not ethical, that men are being disadvantaged because of this project. But by looking at the underlying reasons for this project, one sees that women are already disadvantaged due to the fact that their ACLs tear three to eight times as much as men’s ALCs. Thus it could be argued that this research is only furthering the equalization of men’s and women’s ACLs, and overall the research can only expand the understanding of the effect of shocks on the knee in general. Looking at the project through this lens would seem to show that there are few ethical concerns associated with it in the near future. But assume that this research expands and enters the market, so the accelerometer/transmitter and receiver are sold with a program to monitor the condition of your ACL. When this technology enters the market, the price point will be fairly high, so it will only be available to an upper class that is able to pay for it. This would only benefit a select few, thus there are ethical considerations in that area. If many people could benefit from the technology but don’t have access to it, is the provider being ethical? Who should have access to this technology, at the expense of a lower profit margin for the manufacturer? Currently these are not ethical issues directly associated with this project, but if research continues and the product is commercialized, these could become major concerns.

Other Potential Applications

There are many potential applications that our accelerometer sensor could be adapted for. Because it is a compact accelerometer sensor that measures acceleration and movement in all three axes, it can be used to analyze sports activity or shock and injury activity (as in the ACL research case it was designed for). A list of potential applications that the accelerometer sensor could be used for are as follows: