Midway Design Report Motion Analyzer for Physical Therapy by dwv40440


									                         Midway Design Report:
                   Motion Analyzer for Physical Therapy
                             Constantina Tyes, James Rutter, Sean Klaiber, and Arjuna Baratham

   Abstract—Physical therapy is a regular part of life for millions   In addition, electro-mechanical devices that measure physical
of people recovering from injuries. Currently, reliable               therapy related quantities such as the maximum angle of
quantitative data can only be collected with a one-on-one patient-
                                                                      motion are bulky, expensive, and impractical from a usability
physical therapist interaction. This results in a costly, time-
consuming process for both the patient and the physical therapist     standpoint.
(PT). Here, we propose a simple, reliable, and portable device          Our design aims to solve these problems by creating a
that will capture and analyze physical therapy-related motion, all    minimally intrusive system that is affordable and usable by all
within the confines of the patient’s home. Removable memory           potential users. The user-side system will consist of a
will allow easy transportation of the recorded motion data for        wearable sensor apparatus and a portable storage and feedback
further analysis by the PT back in the office, thus saving time
                                                                      device (PSFD). The wearable sensor will likely be a leg band
and money for the patient. For this paper, a prototype was
developed consisting of the wearable motion sensors                   or strap that securely holds the sensor in place while the
communicating wirelessly to an embedded processor (Arduino),          patient performs a particular strengthening or range of motion
where a simple graph was drawn to demonstrate correct and             exercise. The PSFD will serve two pain purposes; first, to
useful data.                                                          record aforementioned motion data to a removable memory
                                                                      device and second, to provide the user with a simple interface
                                                                      in addition to feedback regarding the proper motion compared
                       I.   INTRODUCTION                              to the patient’s actual motion. We will show that the data is
                                                                      highly reliable and accurate by comparing device-recorded

T     HE field of physical therapy has remained largely
     unchanged by technology in the past decade. Most
measurements are still done by hand, using protractor-like
                                                                      data with traditional PT-recorded data. The final piece to the
                                                                      project is the software running on the PT’s computer. This will
                                                                      analyze the motion data in depth, allowing the therapist to see
devices to measure ranges of motion, which proves tedious for         exactly what the patient has been doing and to assess the
both the patient and the physical therapist. In addition, most        patient’s progress.
exercises require that a physical therapist (PT) be with the            Figure 1 summarizes the flow of data in the motion analyzer
patient in order to ensure that the exercise is done correctly: an    system. The motion sensor device on the patient’s body will
incorrectly performed exercise can be useless and even                wirelessly send motion data to some portable device all in the
detrimental to a patient’s recovery curve. This leads to              user’s home. Then, the memory unit will be physically
multiple visits to the PT office, costing everyone time and           transported to the PT’s office, where further analysis will be
money.                                                                done using special software on the PT’s computer. This
  The methods of data recording and storage are also                  information will then be used to help the PT modify and/or
relatively old-fashioned, with the PT simply recording all            correct the patient’s exercise movements and regimen.
measurements with pencil and paper. The idea of a patient
who performs exercises on his or her own without the
supervision of the PT has been explored, but has not taken
effect due to the skepticism of the reliability of the data

                                                    Figure 1: System Flow Diagram
                         II. DESIGN                                sensor on each ‘stick’ limb, with all sensors attached
                                                                   together in one wearable strap. For example, for a knee joint
                                                                   range of motion exercise, the wearable device will consist of
 A. System Overview
                                                                   two sensors, one on the lower leg near the shin and one on
   The design consists of three main blocks, as seen in Figure     the upper leg near the thigh. This will give us all the
2. The wireless sensor device consists of the accelerometers       information necessary to calculate the angle between sensor

                                                       Figure 2: System Block Diagram

and the wireless transmitter. This sensor device must be           1 and sensor 2. The accelerometers will be the 3-axis 5g
lightweight and unobtrusive to the user. This is to ensure that    ADXL335 accelerometer, meaning that they measure
the device will not affect or hinder the patient’s range of        acceleration in the three directions x, y, and z, and they have
motion, which would render the entire product useless. The         a maximum reading of 5g. This will be more than enough
wireless transmitter will send this data to its receiver           range for our application, in which users move in slow
counterpart on the PSFD. The PSFD will be the main                 motions with very few fast jerks. It can be assumed that
user interface, consisting of the main CPU and feedback            throughout the use of the sensors, the maximum acceleration
peripherals in addition to the memory storage device. It will      they will experience will be within -1g and +1g, since this is
allow the user to choose the exercise to be performed, and will    the maximum effect of gravity. The exact algorithm for
give feedback to the user based on how well (or how poorly)        calculating the necessary angles is discussed in section III.B.
they perform the exercise. The final block of the design is the      The wireless communication from the accelerometer to the
software in the PT’s office, allowing for more detailed            PSFD will be done by XBee Series 2 radios, which
analysis of the patient’s recorded motion data.                    implement the Zigbee protocol stack. XBee
                                                                   provides a simple way to convert analog signals, such as
                                                                   those coming from the accelerometers, to digital ones
 B. Detailed System Specification                                  suitable for transmission through the wireless channel. This
   1) Wireless Sensor                                              is done by the 3 embedded A/D converters included on the
   The wireless sensor is the only part of the system that the     XBee module itself. Therefore the analog signals can be
 user will wear on his or her body. There will be one wireless     directly wired to the XBee device.
  The transmitter will send data to the receiver on the PSFD,      simple file storage, organization, and retrieval. The
with a raw data rate of 250 kbps. With a range of up to 30 m,      software will be open source for any persons who feel the
these modules were ideal for this application since the user       need to modify the software in any way.
can be assumed to be within eyesight of the PSFD. The short
range of these radios enables a very low power consumption         4) Design Alternatives
– only 1 mA when transmitting. In addition, these modules            A number of component choices and other design
cost less than the XBee Pro modules, which consume more            alternatives were discussed in developing the motion
power but offer a greater range.                                   analyzer project. One was to sense more than just
                                                                   kinematics, and to extend the sensor device to include
                                                                   temperature sensors, gyroscopes, and/or optical rotary
 2) Portable Storage and Feedback Device (PSFD)                    encoders. Research into each of these possibilities was
    The PSFD will have an identical XBee module as the             done, and it was concluded that they would be unnecessary
 wireless sensor. This radio will serve as the endpoint of         and impractical for our application. For example, optical
 data communication from the user, and will pass the data          rotary encoders seemed to be bulky, heavy, and often
 to the CPU, which will be a Beagle Board equipped with            expensive. In addition, these sensors would require a
 an OMAP processor capable of running an embedded                  mechanical device that retained contact with the sensor at
 Linux operating system. This will allow us to handle data         all times. This would most likely get in the way of a user
 in files (possibly one file per day or per exercise session)      trying to perform an exercise, resulting in an imprecise and
 resulting in much better organization and ease of design.         possibly unsafe situation.
 The operating system will be booted from one SD card                Another major decision we made was to forego the
 which cannot be used for any other data storage.                  internet-based data transportation from the user to the PT
    Also, the Beagle Board comes equipped with many                (via e-mail or other wireless protocol). This would add too
 external ports that allow for peripherals to be connected to      much complexity to the user box since it would require the
 the board, peripherals which we will use to provide               user to own and operate a computer. This greatly reduces
 feedback to the user. The way such feedback will be               the number of potential users, so we decided to make the
 generated involves real-time motion data comparison to a          PSFD the only thing that the user has to operate. In
 small number of static variables. If the workable                 addition, the issue of security would be introduced if such
 assumption that all exercises are designed to be performed        a method was used, with users’ sensitive personal data
 in one plane is used, then some variables include the             traveling through unsecured wireless channels.
 amount of sensor deviation from this plane, expected                Finally, a major alternative we considered was regarding
 max/min pitch values, and max amount of accepted sensor           the software in the PT’s computer. At first we wanted to
 jitter or shakiness. If the user is found to have strayed from    use a signal processing language that was familiar to us,
 any of these static variables, an alert in the form of an         such as MATLAB, but since this is proprietary software, it
 audio message or an LCD message may be displayed.                 would require that the PT buy such software which would
    The last function of the PSFD is to write the motion data      again reduce the likelihood that our product be used in real
 to the removable memory device, a second, portable SD             situations. Therefore, we decided to go with Octave, which
 card. This will be then transported to the PT’s office for        appears to give us all the processing capabilities that
 further analysis.                                                 MATLAB does, but at no cost to the user.

 3) PT Software
                                                                          III. MDR PROTOTYPE IMPLEMENTATION
    The software running on the physical therapist’s
 computer will be written in the open-source numerical
 computing environment GNU Octave. The interface will             A. Overview
 be a Java GUI that allows the PT to view detailed graphs           The prototype developed for the Midway Design Review
 and statistics about the user’s performance on each              (MDR) consists of a wireless sensor and a primitive PSFD
 exercise. Since the PT will have the raw accelerometer           that actually has an Arduino instead of a Beagle Board. At
 data as received by the PSFD, there is no foreseeable limit      this point the system demonstrates that useful data can be
 to the information accessible by the PT.                         sent from the wireless sensor to the portable Arduino board
    The Java GUI will provide a simple interface for the PT       and displayed in Octave. As stated earlier, the ADXL335
 to plot motion and related data including error plots,           analog accelerometers were used as they provide the three-
 improvements plots, etc. The interface will also allow for       axis measurement capabilities at the resolution we need.
Also, the XBee series 2 wireless radio modules were used,
as they are the low power, low cost devices that we need for
such an application as our motion analyzer. The power is
supplied by a 9 V battery which is fed into a voltage
regulator that outputs 3.3 V. This voltage is sufficient to
power both the accelerometer and the XBee radio. The
Arduino processes the Zigbee packets and extracts the data,
which it then passes to Gobetwino. Finally, the data is
passed to Octave, in which graphs are drawn, displaying
pitch versus time.

B. Data Flow and Algorithm
                                                                                 Figure 3: Derivation of Pitch Formula
  The sensor is calibrated once according to a simple method
that reads the acceleration when the device is laying flat on
some surface. This corresponds (ideally) to 0g acceleration
in the x and y directions and 1g acceleration in the z              C. Testing and Results
direction. Since only the x- and y-axes are used in the tilt             We performed two basic test types to test the reliability
calculation, only the x- and y-axes are calibrated. The actual    of our prototype: angle accuracy and timing accuracy tests.
calibration is done by taking 10 consecutive readings of x        We focus more on angle accuracy tests since at this point our
and y acceleration and averaging them, yielding the average       prototype introduces many delays that will not be present in
deviation from 0g. This offset is later used in the pitch         the final version using the Beagle Board.
calculation when it is subtracted from the acceleration                 In order to test the reliability in the angle measurements
readings before the inverse tangent is taken. Specifically, to    of our device, we used the physical therapy device called the
find pitch of the x-axis when moving in the xy-plane we use:      goniometer, which is a protractor-like apparatus that measures
                                                                  angles. We attached the wireless sensor to the movable arm of
                                                                  the goniometer, and keeping the baseline arm steady, were
                  =                                   ,           able to vary the angle at which the wireless sensor was
                                                                  situated. Then, with the receiver and sensor turned on, we
                                                                  varied the angle from 20° to 30°, stopping there for a few
Figure 3 illustrates how this formula was derived. Where
                                                                  seconds, and then moving it back to 20°. Then it was moved
        is the acceleration measured in the x direction,
                                                                  up to 40° and this continued in 10 degree increments, always
      is the zero offset in the x direction, and   is a           returning back to 20° each time. When viewing the resulting
                                                                  plot, it was clear that at each 10 degree increment, the line
scaling factor used to convert from radians to degrees. This      leveled out, and stayed relatively steady. At each 20° return
dual axis calculation results in a greater resolution or          point, the plot correctly indicated that 20° was the reading
sensitivity than if only one axis was to be used, especially      from the sensor. In addition to the accuracy of the device, this
around the 0 +/- 10 degree position. From this tilt value,        experiment showed that there was no accumulation of drift: at
relative position can be calculated assuming that the             each 20° stop, the graph correctly showed a line at 20° and did
positions of the accelerometers are stationary. Since no
                                                                  not drift away in one direction. The ripples at each 10°
integration or summations are done in calculating the tilt, the
                                                                  multiple represent the error or noise in our measurements. One
device does not need to be calibrated more than once per
                                                                  of our immediate goals is to flatten out these plateaus by using
session. The only remaining source of error is the rounding
                                                                  some sort of averaging or low-pass filtering. The exact details
error coming from the analog-to-digital converter. Since we
                                                                  of this SNR optimization have yet to be derived.
are using an 10-bit AD-converter, this rounding error is
                                                                       In terms of the timing calculations, only very rough
relatively insignificant. The resolution we achieve has been
                                                                  experiments were carried out. These involved performing
calculated to be 1 step/degree, meaning that for every step in
                                                                  some motion (a rapid increase of 10°, for example) at clearly
the A/D digital output (from 0-2023), we get 1 degree of
                                                                  defined time intervals, say every 5 seconds. The result was a
change in the angle measurement.
                                                                  plot that had nearly vertical steps every 5 seconds. Again, the
                                                                  5 second intervals did not get longer over time, indicating that
                                                                  the accumulation of error is not a factor in the system. More
                                                                  precise timing measurements will be performed after the
Beagle Board is integrated into the project.
     Wireless transmission data rate was also tested and
compared to an expected, calculated theoretical data rate. To
do this, we calculated the average time for one packet (30
bytes) to travel from transmitter to received. The parameters
we used were the A/D sample rate (1ms), number of samples
before transmission (3), raw data rate (250 kbps), UART baud
rate (96500 bps), and static delays introduced in the receiver’s
Arduino code. The last delay proved to contribute most to the
timing calculation, accounting for 92% of the total delay. The
calculated, expected amount of delay was 98.2 ms per packet,
while the observed delay was steady at 116 ms.

                 IV. PROJECT MANAGEMENT
 A. Team Roles
   • Wireless Sensor: Constantina
   • Wireless Send/Receive: Arjuna
   • PSFD Data Input: James
   • PSFD Output: Sean
                         V. APPENDIX                                 the Beagle Board, the main source of time delay will be
                                                                     greatly reduced and we will achieve far greater than the
  A. Application of Mathematics, Science, and Engineering            roughly 10 Hz (100 ms) end-to-end latency that we observe
          In developing the prototype, we used material from at      now. This will be suitable for slow motions such as the
least three science or engineering courses:                          movement of a leg in a range of motion PT exercise.

1.       Physics 151: Using effective forces and gravity
                                                                       B. Design and Performance of Experiments, Data Analysis,
           relationships in order to calculate the pitch of an
                                                                       and Interpretation
           object from its acceleration in different directions.
2.       ECE 323: We had to build a circuit on the wireless                    In order to test the reliability in the angle
           sensor that took into account power/voltage issues.       measurements of our device, we used the physical therapy
3.       ECE 374: Using data rates and packet sizes, an              device called the goniometer, which is a protractor-like
           overall data rate was calculated and compared to          apparatus that measures angles. We attached the wireless
           actual, measured rates.                                   sensor to the movable arm of the goniometer, and keeping the
                                                                     baseline arm steady, were able to vary the angle at which the
Detailed Example                                                     wireless sensor was situated. Then, with the receiver and
          When wireless communication was first established,         sensor turned on, we varied the angle from 20° to 30°,
the data rate was far too slow, with on average one packet           stopping there for a few seconds, and then moving it back to
being received every 25 ms or so. Wireless transmission data         20°. Then it was moved up to 40° and this continued in 10
rate was tested and compared to an expected, calculated              degree increments, always returning back to 20° each time.
theoretical data rate. To do this, we calculated the average
                                                                     When viewing the resulting plot, it was clear that at each 10
time for one packet (30 bytes) to travel from transmitter to
                                                                     degree increment, the line leveled out, and stayed relatively
receiver. The parameters we used were the A/D sample rate
(1ms), number of samples before transmission (3), raw data           steady. At each 20° return point, the plot correctly indicated
rate (250 kbps), UART baud rate (96500 bps), and static              that 20° was the reading from the sensor. In addition to the
delays introduced in the receiver’s Arduino code. The last           accuracy of the device, this experiment showed that there was
delay proved to contribute most to the timing calculation,           no accumulation of drift: at each 20° stop, the graph correctly
accounting for 92% of the total delay.                               showed a line at 20° and did not drift away in one direction.
          The calculated, expected amount of delay was 98.2                    The ripples at each 10° multiple represent the error or
ms per packet, while the observed delay was steady at 116 ms.        noise in our measurements. This ripple, which also is affected
The delay due to the sampling was simple to calculate: 3             by human error (trembling, viewing the goniometer angles by
samples/packet occurring every 1ms, corresponding to a time          eye), seems to stay within +/- 1 degree when held absolutely
of 3 ms per packet. The raw data rate of 250 kbps or 250*1024        still. This is assumed to be mostly (outside of human error)
bps was used to transmit 30 bytes (240 bits) per packet. Thus,
                                                                     due to the inherent noise in the accelerometer, which at the
the data rate delay was 240/(250*1024) s = 1.0 ms per packet.
                                                                     voltages we use should be within +/- 0.1 degree. Since a 10-bit
The baud rate of 57600 bps transmitted 240 bits again,
resulting in a delay of 240/57600 s = 4.2 ms. Finally, the static    A/D converter is being used, this +/- 0.1 degree variance could
delay in the program of 3ms/byte results in a total static delay     force the A/D over a boundary, outputting an entire degree
of 3*30 ms = 90 ms per packet. Summing these four values we          higher than the actual angle (since the A/D resolution was
obtained a value of 90 + 4.2 + 1.0 + 3.0 ms = 98.2 ms. The           calculated to be 1 degree). One of our immediate goals is to
delay from the Arduino program accounted for 90/98.2 = 92%           flatten out these plateaus by using some sort of averaging or
of the entire delay.                                                 low-pass filtering. The exact details of this SNR optimization
          In order to optimize this data rate as best as we could    have yet to be derived. Octave was used to graph the results,
for the prototype, we tested lowering the static delays to 2.5, 2,   which is show below in Figure 4.
and 1 ms, but all of these resulted in an unstable receiver. We
did similar configurations on the baud rate, increasing it up to
115200 bps, but the benefit from such an increase was
negligible compared to the instability that this gave the
receiver. The samples per packet variable was experimented
with and it appears that 3 samples before transmit was suitable
for our system. We assume that when we transfer operations to
                                               Figure 4: Pitch vs. Time Sensor Graph                                                   7

                                                                     D. Multi-disciplinary Team Functions
  C. Design of System, Component, or Process to Meet                      Arjuna Baratham, CSE: Worked to enable wireless
  Desired Needs within Realistic Constraints                              communication, transmission/extraction of sensor
          The system requirements consist of requirements of              data. Worked on configurations to optimize wireless
the wireless sensor and the requirements of the data                      transmission latency with James.
processing. The sensor must be comfortable and minimally
intrusive to the user in order that they can perform the exercise           Sean Klaiber, EE: Wrote Octave and Gobetwino
fully and produce meaningful data. The wireless sensor must                 scripts that take sensor data and plots it against time.
be lightweight so as not to hinder the range of motion, and                 Sean also set up the team’s website and is in charge
must also be completely wireless. These could be considered                 of posting documents onto it.
health and safety constraints since they also directly affect the
safety of the patient. Our wireless sensor is completely                    James Rutter, EE: Worked on developing the angle
wireless, using the Zigbee protocol to communicate to the                   calculation for the sensor data in Arduino. Also
receiver. However, as it stands right now, our prototype is                 worked to optimize wireless transmission latency
slightly bulky and heavy (due to the prototyping board and big              with Arjuna.
9 volt battery). This will be addressed in future prototypes and
the final design, in which a PCB will be used and the 9 volt                Constantina Tyes, EE: Designed prototype wearable
battery replaced by a lightweight coin battery.                             sensor. In charge of planning the future power supply
          The other main category of real-world constraints in              and final sensor design.
our design is the sustainability of our system. Our prototype
doesn’t have any power-indication, but as we progress, some
                                                                      E. Identification, Formulation, and Solution of Engineering
sort of “low battery” light will be introduced. In addition,
rechargeable batteries, possibly rechargeable coin cells will be
used in order to provide a long lifetime and little need to                   As previously stated, one of the main obstacles we
replace batteries.                                                  overcame was the poor data rate of the wireless transmission.
                                                                    To solve this we utilized techniques learned in previous
                                                                    courses in addition to the configuration options of the XBee
                                                                    radios in order to mitigate the per-packet delay. By observing

that the vast majority of the time delay (over 90%) was due to                Our project will have positive societal impacts by
the delay line in our code, we decided that Arduino would be        allowing persons with physical injuries or disabilities to
unsuitable for the final design and that Beagle Board would be      perform recovery routines that would normally have to be
a much better option. The parameters that we could change,          done at a distant location within the convenient spot of their
however, were optimized, and the result was a workable              homes. Since the people who will be using out product are
prototype in which the actual data rate was around 10 Hz.           already injured in some way, in most cases they shouldn’t be
                                                                    driving to a physical therapy clinic for safety reasons.
                                                                    Allowing the recovery routines to be performed at the
  F. Understanding of Professional and Ethical
                                                                    patient’s home will also increase the amount of time the
                                                                    patient has for other activities and the amount of time the
          An issue of professional responsibility that arose with   physical therapist could be more actively analyzing a patient’s
 our project involved dealing with the people who are targeted      data or handling other patients entirely.
 by our project. Since none of the team members have had                      Providing the ability for useful therapy related
 significant involvement with the physical therapy process,         recovery exercises to be performed in ones home will
 either assumptions had to be made or a professional                hopefully also increase the speed of patient recovery. People
 contacted. Professionally, it only made sense that we would        are often removed from obligations such as work while
 be in frequent contact with a physical therapist. We quickly       involved in therapy and our product may allow them to attend
 met with Joe Mathers, a physical therapist at University           to these obligations in a timelier manner.
 Health Services and established a professional relationship.
          During the idea development stage of our project we
 met with Joe on four occasions to confirm the projects              I. Application of Material Acquired Outside of Coursework
 usefulness and question where it was lacking. In an                        Three examples of sources used outside of
 intermediate product testing stage and for MDR, Joe was                    coursework are:
 helpful enough to lend us a Goniometer, the physical therapy
 tool used to measure the pitch of a patients knee, for                      1.   Product user manuals and data sheets, including
 comparison to our found values.                                                  [3], [4], and Beagle Board documentation. These
                                                                                  helped us get started with each component or
                                                                                  device, in addition to being valuable
 G. Team Communication
                                                                                  troubleshooting resources.
         In this section we describe the various means the                   2.   Previous projects posted on the internet such as
team are using to communicate as a team.                                          [5] and [6]. These provided us with specific
   Team communication has been done at weekly team and                            solutions to problems we were having late in the
faculty meetings as well as less formal meeting times that                        implementation phase of our prototype.
have been establishing themselves. The weekly faculty                        3.   [Detailed example] Application-specific
meeting is scheduled for Mondays at 2:20 and the weekly                           technical papers such as [1] and [2]. These
team meetings on Wednesday at 2:20 with the occasional                            papers on accelerometer calculations and
(about three times) team follow-up meeting Friday at 2:20.                        calibration served to guide us in our design. We
During the faculty meeting, individual progress is discussed                      based our calibration scheme and sensitivity
along with the most challenging technical problems that                           calculations on [1] although our sensitivity
individuals or the group have encountered. At weekly team                         calculation is slightly less precise than Tuck’s. In
meetings, the focus is generally on group work integration and                    [2] we used the various formulas for angle
planning for future steps.                                                        calculations.
         We have also been fortunate in that an unplanned
schedule has been formed in that the entire team will usually
(about 75%) occupy the same areas in the M5 project space            J. Knowledge of Contemporary Issues
between 2:30-4:40 Tues-Thurs. Although team members work                      The field of physical therapy has a vast amount of
during these times are not always SDP oriented, the proximity        tools used for measurement and diagnosis for injuries. These
has resulted in SDP related concerns almost always being             tools can be incredibly accurate but are also far too large or
discussed.                                                           expensive to be taken home by the user and can only be used
         Written and stored communication has been done              in a clinic. In our research, we found tools such as the
through e-mails and individual notebooks of which pages are          expensive but accurate arthrometer. These tools perform
often shared among team members.                                     similar pitch measurements to ours but none that the patient
         Constantina Tyes has also served as the primary             could take home and get similar or better accuracy than can
faculty contact in charge of setting up any necessary faculty        be done at the therapy clinic. So there is currently no method
meetings and design review places and times.                         for a patient to get accurate results and data beneficial to the
                                                                     physical therapist outside of the clinic. The function of our
                                                                     project would be to act as a proxy physical therapist,
 H. Understanding of the impact of engineering solutions in
                                                                     providing real-time feedback for certain exercises, as well as
 a global, economic, environmental and societal context.
                                                                     a data logger providing the therapist with enough information

 to make decisions without the patient present. This can all be
 done within the comfort of the patient’s home.

 K. Use of Modern Engineering Techniques and Tools
       Three engineering tools we used were:

        1.   X-CTU software which provided us with a GUI
             to make programming the XBee simple and fast.
             Also used to verify that the module was
             receiving correct data. This consisted of a
             command-line type terminal that accepted direct
             serial input and also printed out serial responses
             from the XBee.
        2.   The Arduino embedded system platform was
             used to develop the data receiving and
             processing software. It allows for easy
             programming and interfacing to the ATMega328
             AVR microprocessor.
        3.   The open source software Gobetwino was used
             to read data sent out by the Arduino on a serial
             port and interpret this data as we specified.
             Arduino sent timestamp and pitch messages that
             Gobetwino stored in a text file in a format
             specified by a team effort of Gobetwino and
             Arduino code. Other serial port messages were
             used to overwrite this text file with a blank file at
             the command of a toggle switch connected to the
             Arduino. Gobetwino allowed us to store data that
             would otherwise be read and discarded by the

[1] Tuck, Kimberly. “Implementing Auto-Zero Calibration
    Technique for Accelerometers”. Freescale
    Semiconductor, March 2007.
[2] Tuck, Kimberly. “Tilt Sensing Using Linear
    Accelerometers”. Freescale Semiconductor. June 2007.
[3] XBee Product Manual v1.xAx – 802.15.4 Protocol. PDF.
    IEEE 802.15.4 OEM RF Modules by MaxStream, Inc.
    October 2006.
[4] ADXL330 datasheet. PDF. Analog Devices. 2006.
[5] Faludi, Rob. “XBee Firmware Upgrade”.
    XBee/XBee_firmware_upgrade.html. Web.
[6] Faludi, Rob. “Common XBee Mistakes”.

To top