Booklet Technion by alicejenny


									   Power Consumption
   Awareness by using a
                 Final Report

Submitted by:
Lior Kuchinski    –   034835348
Asaf Bar          –   040551848
Denis Kosovich    –   304549470

Introduction           –3

Problem Description    –7

General Layout         –8

Main Modules           – 10

Main Algorithms        – 15

Results Analysis       – 20

References             – 23

                           1 - INTRODUCTION

1.1 - Mobile phone
  In 1978 the first commercial mobile phone service was launched in Japan. By
  November 2007 the total number of mobile phone subscriptions in the world had
  reached 3.3 billion - half of the human population.
  Mobile phones send and receive radio signals with any number of cell site base
  stations fitted with microwave antennas. These sites are usually mounted on a tower
  or building, located throughout populated areas, then connected to a cabled
  communication network and switching system. The phones have a low-power
  transceiver that transmits voice and data to the nearest cell sites, normally not more
  than 8 to 13 km away.

  In parallel to the rise of the mobile phone popularity, the products’ technology
  advanced. What was mainly designed to achieve voice communication, progressed
  over the years and nowadays offers text messages, games, video features, digital
  camera, internet connection and much more.

  Cell phones’ new functionalities have greatly increased the demands from the
  phones’ batteries. The batteries technology has gone a long way, but still the
  problem remains – how to make the battery last longer?
  One way is to use the cell phone’s capabilities smarter. Many functionalities of
  the cell phone depend on its position. Knowing it, would make it easier to
  conserve battery power.
  But how can we determine one’s location?

1.2 - Global Positioning System
  The Global Positioning System (GPS) is a satellite-based navigation system made
  up of a network of 24 satellites placed into orbit by the U.S. Department of Defense.
  GPS was originally intended for military applications, but in the 80s, the U.S.
  government made the system available for civilian use. GPS satellites circle the
  earth twice a day in a very precise orbit and transmit signal information to earth.
  GPS receivers take this information and use triangulation to calculate the user's
  exact location. Essentially, the GPS receiver compares the time a signal was
  transmitted by a satellite with the time it was received. The time difference tells the
  GPS receiver how far away the satellite is. Now, with distance measurements from a
  few more satellites, the receiver can determine the user's position and display it on
  the unit's electronic map.

 A GPS receiver must be locked on to the signal of at least three satellites to
 calculate a 2D position (latitude and longitude) and track movement. With four or
 more satellites in view, the receiver can determine the user's 3D position (latitude,
 longitude and altitude). Once the user's position has been determined, the GPS unit
 can calculate other information, such as speed, bearing, track, trip distance, distance
 to destination, sunrise and sunset time and more.

 Certain atmospheric factors and other sources of error can affect the accuracy of
 GPS receivers. Today’s GPS receivers are accurate to within 15 meters in average.
 Newer GPS receivers with WAAS (Wide Area Augmentation System) capability can
 improve accuracy to less than three meters on average. Users can also get better
 accuracy with Differential GPS (DGPS), which corrects GPS signals to within an
 average of three to five meters.

 If the GPS is so effective, why not use it to calculate the position of the cell
 phone in order to conserve battery power? The question is similar to: “Why
 not kill flies with a bazooka?”. What if you only need to know if you’re inside a
 building or not? GPS itself has high power consumption, it requires satellite
 communication, it is ineffective within structures etc.
 What we need, is a much simpler system that could automatically track our
 position, using very little battery power.
 So what’s the alternative to GPS?

1.3 – Dead Reckoning
 “From the great oak take 12 steps east and then 15 steps north-west. That’s where
 the treasure lies.”
 That’s exactly what dead reckoning is all about: calculating the current position of an
 object, given its initial position, the distance passed and the direction of the

 The positioning method used in this project is based on Dead Reckoning
 principles. In order to determine one’s location you would need a way to
 discover one’s heading and the distance he has traveled. The heading could
 be determined using a magnetic compass. We will not deal with heading in the
 Our goal will be: calculating the distance one has traveled.
 How can we accomplish that without using GPS?

1.4 - Accelerometer
  Accelerometer is a device that measures the acceleration of a structure. The
  acceleration causes inner mass to "squeeze" the piezoelectric material which
  produces an electrical charge that is proportional to the force exerted upon it. Since
  the charge is proportional to the force, and the mass is a constant, then the charge
  is also proportional to the acceleration.
  A low impedance accelerometer has a charge accelerometer as its front end but has
  a tiny built-in micro-circuit and transistor that converts that charge into a low
  impedance voltage that can easily interface with standard instrumentation.

  When a human walks, his torso, typically rocks vertically and horizontally.
  Which means: it creates a typical pattern of acceleration during each stride.
  We will calculate the distance a human travels based on readings of an
  accelerometer mounted on his body. The final goal of the project is to
  calculate the position a cell phone – which means that the accelerometer, the
  magnetic compass and the software that analyses the data will be mounted on
  the cell phone.
  But how does one write a software that a cell phone could run???

1.5 - Binary Runtime Environment for Wireless (BREW)
  Brew is an open-source on-line application development platform for wireless Code
  Division Multiple Access (CDMA) devices from Qualcomm. BREW is designed to
  allow developers to write in different languages. Native BREW application are written
  in C or C++ and BREW supports programming in other languages, such as Java and
  XML. Using BREW, developers can create portable applications that will work on
  any CDMA device.

  We shall use BREW in order to write a code that analyzes data coming from an
  accelerometer and identifies a human stride and it’s length. BREW supplies a
  simulator that runs on a PC. All that is missing, is an accelerometer that could
  also connect to a PC…

1.6 - Wii remote
  The Wii Remote is the primary controller for Nintendo's Wii console. A main feature
  of the Wii Remote is its motion sensing capability, which allows the user to interact
  with and manipulate items on screen via movement and pointing, through the use of
  accelerometer and optical sensor technology.

  In this project we will use Wii remote to simulate mobile phone motions. The
  remote provides 3 axis acceleration data, which will be processed by the
  application inside BREW.
  But this is a remote control for a video console. How can we connect to a PC?

1.7 - Bluetooth
  Bluetooth is a low-power consumption and short-range wireless technology for
  personal area networks (PANs). It connects personal electronic devices, such as
  laptops, mobile phones, digital cameras, audio equipments and printers without
  clutter of cables.

  Nintendo Wii remote control uses Bluetooth technology in order to transfer
  data to the console. But based on the fact that Bluetooth is a standard, there
  are individuals that took it upon themselves to write code that would make it
  possible to connect the Wii remote to a PC via Bluetooth. We shall use that
  code in our project to extract the three axis acceleration produced by the

1.8 - Transmission Control Protocol/Internet Protocol (TCP/IP)
  A set of communications protocols that implement a stack protocol, TCP includes
  not only lower-level specifications (such as TCP and IP), but also specifications for
  common applications as email, terminal emulation and file transfer.
  TCP/IP will be used to in this project to communicate between a server process that
  will read the accelerate data from the Bluetooth driver and send it to the application
  inside BREW.

  We will use TCP/IP protocol to transfer data between two different modules in
  our project.

                 2 - PROBLEM DESCRIPTION

2.1 - The problem
  Location based power usage is one of the techniques to preserve mobile battery life.
  In this aspect the mobile phone activity is restricted to specific boundaries, this way
  reducing the electric consumption out of the restricted area.
  Determining the mobile phone location is the higher level purpose of this project.
  A common solution to the problem is the GPS receiver, however despite the GPS
  advantages there are some major pitfalls which need to be taken into account:
      - The main goal in this project is to decrease the battery usage while GPS
          requires high electricity consumption.
      - GPS information is not always permanently available.

2.2 – The solution
  In this project we will implement an algorithm for a pedometer. A pedometer is an
  electronic device that measures the distance a person travels by foot, either by
  walking or by running, which it does by sensing 3- axis acceleration data which is
  taken from the built in accelerometer. A pedometer's basic function is to count the
  number of steps the person has made and measure how far he has been walking.

  To achieve the main goal, pedometers are being used in a wider aspect of
  movement inspection - the Personal Navigation Application (PNA). PNA combines
  the pedometer with an electronic compass to allow the user to determine their
  position relative to a given starting point.
  The position determination is done by "dead reckoning" – calculating the integration
  of acceleration in each axis over time. The problem with this kind of calculations is
  accumulated DC errors. A better approach is to combine "dead reckoning" with GPS
  receiver which can provide periodic reference positions often. This way the effect of
  the DC errors is reduced dramatically and even gives preferable accuracy than a
  standalone GPS.

                             3 - General layout
  In our project, we shall use a Nintendo Wii remote control (which contains an
  accelerometer) as an input source. It will be connected to an MS Windows operated
  PC through a standard USB device.

  Our project will be divided, according to functionality, into three interacting modules:
  the “Input Module”, the “Analysis Module” and the “Output Module”.

3.1 – The modules diagram

3.2 - Input Module
  As a part of this module, we shall use an existing “Managed Library For Nintendo’s
  Wiimote”. The functions included in the library will enable us to extract and isolate
  data that is relevant to us (the acceleration in X Y and Z axis) from the data sent to
  us by the remote control (which includes much more than we need).
  This data will then be passed to the next module.

3.3 - Extract & Analysis Module
  The received data will be collected and processed into a final result by an
  implementation of the main algorithm and then passed on to the next module.

3.4 - Output Module
  An application in the Brew simulator will present the data relevant to the end user,
  such as: step indication, the length of the last step, etc.

3.5 - Integration
  The Analysis and the Output modules will be integrated into the Brew environment
  (and as such will be developed in C).
  The Input module only simulates the reality, in which the accelerometer will be a part
  of the gadget. That is why the module will be external - not integrated into the Brew
  and will use technologies that don’t need to be compatible with Brew (such as the
  “Managed Library For Nintendo’s Wiimote”, which is written in Java).

  Note: The fact that the input of our project is received differently than in the reality,
  explains why we chose to divide the Analysis module in two (one part handles the
  extraction of data and will have to be replaced if the project is used in the real
  device, and the second part handles the analysis and will not have to be replaced).

3.6 - Interaction between modules
  Input – Analysis:
         The Input module will send its output via designated socket in a fixed format.
         It will then be extracted from the socket by the Analysis module.

  Analysis – Output:
        The Analysis module will store its output in a local, fixed size, database which
        will be approachable for the Output module, which will extract the data in
        order to present it.

                           4 - MAIN MODULES:

4.1 - The Input Module:
  The input module is responsible for getting the acceleration samples from the Wii
  remote and sending them to the application inside Brew, for analysis.

4.1.1 – The module threads:

  The input module contains 3 threads:

  1. Initial thread:
  - The first operating thread creates the common data structures used by the other
    threads (a linked list to save the acceleration data and a flag to indicate the
    application status).
  - Creates the next 2 threads and exits.

  2. WRLImpl:
  - This thread uses the free (closed source) java package – WiimoteJ, to maintain
    connection with the remote and get the acceleration samples from it.
     Each time an "acceleration event" occurs (the remote sends acceleration data to
    the driver) and the brew application's mode is operational, the thread saves the
    acceleration data inside the common linked list. Otherwise the acceleration data is
    ignored. The common linked list will be approached by the TCP server for the
    transmission of the samples.
   - If the remote is manually closed, the server application ends (both threads).

  3. TCP server:
  - This thread waits for the brew application connection.
  - It responds to the following requests:
          Get - sends the last valid acceleration samples using TCP packages.
          Pause - wait until the application requests to resume the transmission.
          Stop - end the transmission and wait until a new application instance is

4.1.1 – The module data structures:

  - progFlag:
         A common data structure between the TCP server thread and WRLImpl
         thread, that indicates the application state.
                - disconnected: the initial state, during which the TCP server thread
                  doesn’t send acceleration samples to the application.
               - connected: the application requests acceleration samples from the

         A common data structure between the TCP server thread and WRLImpl
         thread. When the application requests acceleration data, the WRLImpl thread
         writes the samples into the linked list (each sample is node in the list). At the
         same time, the TCP server thread gets the latest acceleration sample from
         the linked list, removes it and forwards the data to the application through the
         TCP socket.

4.1.1 – Synchronization:

  The code of the threads implements the access to the data structure as
  “synchronized”, which means – only one thread can access the data structure at any
  given time.

4.2 - Extract and Analysis module
  This module has 2 main roles:
     1) Extracting the accelerometer data from the TCP/IP socket.
     2) Analyzing the data according to chosen pedometer algorithm (see part 6).

  This module will be influenced, of course, from the user's input since BREW is
  event's based platform.

  4.2.1 – Extract data

  When application mode is operational the module opens a socket using TCP/IP
  It reads the data from the socket, parses it from string to float data and then it
  analyzes it, iteratively.

  4.2.2 - Analyze

  This module detects steps and calculates stride's length according to the pedometer
  algorithm taken from the article "Human Walking Analysis Assisted by DGPS".
  If step detection was occurred the common memory area is updated with the last
  step length, total distance that has been travelled and the total number of steps that
  were taken.
  Actually this module generates output for the output module.

  One of the services that this module has to offer is a log file named "logfile.txt",
  which contains all the accelerations and step declarations when a step is detected.

4.3 - Output module
  The module is a GUI that is built to interact with the application’s user.
  It presents the user with the output of the analysis module and reacts to the user’s

  The module is primarily composed of seven “screen drawing functions”
  (‘pedometer_DrawAScreen’ through ‘pedometer_DrawGScreen’).
  Also the ‘pedometer_HandleEvent’ function should be considered as a part of this
  module, as it contains the code that reacts to events such as key presses made by
  the user.

  The GUI consists of the following seven screens:

     1) A Screen:

                          This is the startup screen of the application.
                          It greets the user and presents a choice: begin using the
                          pedometer (by pressing the OK button, which will load the B
                          Screen), or calibrate it (by pressing the * button, which will
                          load the D Screen).

                          A bit about the BREW simulator: As you can see, the
                          simulator presents the user with a cell phone look-alike
                          application. The keys can be pressed by the mouse or by
                          respective keyboard keys. From now on (in order to save
                          blank space) the images will not contain the bottom part of
                          the simulator, but only its screen.

2) B Screen:

               This screen is presented while the pedometer is in action.
               It shows the number of steps the user has currently made,
               the length of the last step, and the total distance traveled so
               At this stage, in order to stop using the pedometer, the user
               should press the OK button (which will load the C Screen).

3) C Screen:

                This screen presents the summary of the last pedometer
                It shows the total distance traveled and the total number of
                steps made.

                At this stage the user can resume using the pedometer by
                pressing the OK button (which will load the B Screen again
                and begin counting the steps and distance from zero), or
                return to the startup screen by pressing the CLR key (which
                will load the A Screen).

4) D Screen:

                This screen presents the user with the instructions on how
                to calibrate the pedometer.

                Note: as explained further (in the ‘Main Algorithms’ section
                of this document), this application calculates the length of
                each stride, based on a formula that contains a constant
                (K), which is set empirically during the calibration process.

                At this stage, the user should press the OK button (which
                will load the E Screen), to begin the calibration process.

5) E Screen

               This screen is presented during the calibration process.
               Once the user has finished walking, he should press the
               OK key (which will load the F Screen).

6) F Screen:

               When this screen is loaded, the user is prompted to enter
               the distance he has passed during the calibration (in
               centimeters). It is done by using the 0-9 keys.
               With each key press, the new digit appears on the screen,
               and vice versa, when a digit is deleted.
               In order to delete a digit, the user can press the CLR key.

               When the user is done entering the distance he should
               press the OK key (which will load the G Screen).

7) G Screen:

               This screen is presented at the end of the calibration
               It includes at notice that thanks the user for calibrating the

               In order to return the startup screen, the user should press
               the OK key.

                       5 – MAIN ALGORITHMS

5.1 - Step detection
  As a conclusion from observing the acceleration samples of the different 3 axis and
  as has been suggested in the academic researches, we choose to detect a step by
  observing the vertical axis.

  Here are three examples of vertical acceleration graphs created by walking:

     1) Step appearance research 1- “Human walking analysis assisted by DGPS”

                Accelerometer position – lower back (up), thorax (down).

     2) Step appearance research 2 - “Comparison of step length estimators from
        wearable accelerometer devices”

                   Accelerometer position – the lower lumbar spine.

   3) Our samples – 3 different persons walking 5 steps:

Subject 1:

Subject 2:

Subject 3:

As you can see from both the academic researches and our tests, step indication
may vary when testing different persons and different positions of the accelerometer.
As a result we have decided to use SMA (simple moving average) to “smoothen” the
graph by observing the average of the last X samples instead of the last sample
alone - to get a strong step indication that will suite different persons. The chosen
value of X should be the one that gives the clearest step indication.
As a conclusion from different tests we found that setting X to 23 will give the most
distinct results for step detection.

The new graph: (the average of the last 23 samples)
Subject 1:

Subject 2:

Subject 3:

5.2 - Step detection – the algorithm
   avgSamp - the average of the last 23 vertical samples.
   Max - the maximum value of "svgSamp" in the current step, initialized to -1000.
    Min - the minimum value of "svgSamp" in the current step, initialized to 1000.
    Timer - counts the number of samples during stage 2.

(Setting max to -1000 and min to 1000 is done for getting new min/max each step).

    - The algorithm starts at stage 0.
    - The automation switches between the stages according to the last "avgSamp"
    - The first "avgSamp" value is calculated only after the first 23 vertical samples
      are received, then each new sample results a new "avgSamp" value.


                   0                                               1
          If (avgSamp < Min)                          If (Max < avgSamp)
              Min = avgSamp                                  Max = avgSamp
          If (Max < avgSamp)                          If (Max-avgSamp>0.075)
              Max = avgSamp                               Max = -1000, Min = 1000
                                                          Step indication
                                                          Timer = 0
          If (avgSamp-Min>0.075)                          Move to stage 2
             Move to stage 1

                   If (avgSamp < Min)
                        Min = avgSamp

                   If (Timer > 100) Move to stage 0
                   Else: If (avgSamp-Min>0.075)
                              Move to stage 1

5.3 - Step length calculation
  The algorithm we chose to calculate the step length uses the following empirical
  Stride length = k 4 Amax  Amin
  Amin - is the minimum acceleration measured in the vertical axis in a single stride.
  Amax - is the maximum acceleration measured in the vertical axis in a single stride.
   K - is a constant which has to be calibrated for each individual based on
   experimental data. To do so, the user must walk a certain distance, measure it and
   then divide the real distance by the distance measured by the accelerometer (that
   measures the distance using the formula when K=1).

                       6 – RESULTS ANALYSIS

  Much of our work has been based on empiric data – at each stage of the
 development extensive testing had to take place to make sure that we are on the
 right track and that the theory matches the reality. Those tests have not been
 documented, off course.

 At the end of the project we have conducted a series of tests in order to check the
 accuracy of the final application.

 The goal of the project was to create an application that would:
    1) Correctly identify a human step
    2) Accurately calculate the distance the person has passed

 Respectively, the testing was divided in two: step identification and walking distance
 Three different testers were used.

6.1 – Step identification

 During the development of the application, we have discovered that there are
 differences between step patterns of the same person.

 One type of differences results from three kinds of steps the person can take: the
 first step, a step in the middle of a long walk, and the last step. All three kinds differ
 from one another.
 This difference had an effect on our step detection algorithm. We had to make sure
 that we could detect all three kinds of steps correctly.

 The second kind of differences is based on the notion of a person of how many
 steps he’s about to take.
 For example: when a person knows he is about to take only one step, the first (and
 only) step that he takes will be much more delicate than a first step the same person
 would take if he was to walk five steps.
 This difference had an effect on our testing: we have decided that testing a long walk
 wasn’t enough. In addition to a sixty steps long walk, we have tested a walking
 pattern that involved one step and a break followed by five steps and a break
 followed by final ten steps.
 Another test (which was mostly for fun) was a running test…

 Another thing we wanted to test was: how does the position of the pedometer on the
 person’s body effect the step recognition.
 The application was written based on the assumption that the pedometer is placed in
 the thorax of the person (as suggested in the articles we have used as a base for
 this project).

Nevertheless, as the final goal of the project was to create an application that could
be integrated into a cell phone, we wanted to check how would placing the
accelerometer on different places on the body effect the results.
We have placed the accelerometer on 4 different places: thorax, lower back, pants
front pocket, pants back pocket.

Here are the results:

                                         Steps          Deviation
                            Tester                                        Deviation
                                        detected         percent
                            Tester 1       60                 0
 Continuous 60 steps –
                            Tester 2       60                 0              0%
accelerometer at thorax
                            Tester 3       60                 0
 Continuous 60 steps –      Tester 1       60                 0
 accelerometer at lower     Tester 2       59                1.6           0.53%
          back              Tester 3       60                 0
 Continuous 60 steps –      Tester 1       60                 0
 accelerometer at front     Tester 2       62                3.3           5.53%
         pocket             Tester 3       52               13.3
 Continuous 60 steps –      Tester 1       60                 0
 accelerometer at back      Tester 2       59                1.6            3.3%
         pocket             Tester 3       55                8.3
                            Tester 1     1,6,10             6.25
1,5,10 steps with stops –
                            Tester 2     1,5,10               0            2.08%
Accelerometer at thorax
                            Tester 3     1,5,10               0
1,5,10 steps with stops –   Tester 1     2,5,10             6.25
accelerometer at lower      Tester 2     1,6,10             6.25           8.33%
          back              Tester 3     1,6,11             12.5
1,5,10 steps with stops –   Tester 1     1,6,11             12.5
 accelerometer at front     Tester 2     2,5,13              25            22.92%
         pocket             Tester 3     2,7,12            31.25
1,5,10 steps with stops –   Tester 1     2,6,11             12.5
    accelerometer at        Tester 2     1,5,10               0            10.42%
      back pocket           Tester 3     2,7,10            18.75
                           Tester 1       12                20
   Running 10 steps –       Tester 2       11                10             10%
accelerometer at thorax     Tester 3       10                 0

As expected, the best results were yielded when the accelerometer was placed at
the thorax, and during a continuous sixty steps walk.
Placing the accelerometer on the lower back gave the second best results, followed
by placing it in the back pocket. Placing the accelerometer in the front pocket has
given the worst results.

6.2 – Walking distance calculation
 Based on the results of the first set of tests, we have decided to do the walking
 distance calculation testing, when placing the accelerometer at the thorax.
 The reason for this decision is pretty obvious: the distance calculation is based on
 calculating the length of each step taken, and summing them. In case the application
 miscounts even one step, the error in distance calculation is very large and the
 testing doesn’t serve its purpose.
 As explained in the “Main Algorithms” section of this report, the formula we have
 used in order to calculate a single step length is: k 4 Amax  Amin .
 In order to calculate the K, the user must walk a certain distance.
 During this phase of testing we wanted to see if changing the distance walked during
 the calibration (calculation of K), has any effect on the final results. We have done
 two different tests: one that was based on a five steps calibration and another one
 that was based on a calibration that was approximately twenty steps long.
 Each tester has walked three different distances (around five, ten and twenty steps).
 Here are the results:
 5 steps long calibration results:
             Actual distance (cm)      Distance measured (cm)   Deviation percent
                     326                        321.7                 1.3%
  Tester 1           655                        668.6                  2%
                     1657                      1618.2                 2.3%
                     372                        367.8                 1.1%
  Tester 2           750                        757.5                  1%
                     1678                      1721.1                 2.5%
                     350                        343.9                 1.7%
  Tester 3           679                        722.8                 3.7%
                     1674                       1692                   1%
 Average deviation percent: 1.84%
 ~20 steps long calibration results:
             Actual distance (cm)      Distance measured (cm)   Deviation percent
                     335                         331                  1.1%
  Tester 1           678                         667                  0.2%
                     1647                       1645                  0.1%
                     380                        368.7                 2.9%
  Tester 2           737                        742.1                 0.7%
                     1689                      1722.8                 2.3%
                     346                        339.4                 1.9%
  Tester 3           698                        715.6                 2.5%
                     1679                      1648.5                 1.5%
 Average deviation percent: 1.46%

 As we can see, the longer calibration has yielded better results by 0.38 percent in

                             7 - REFERENCES
7.1 – Articles
 As a theoretical base for this project, we have used the following two articles:

     1) “Human Walking Analysis Assisted by DGPS” by Quentin Ladetto, Vincent
        Gabaglio, Bertrand Merminod, Philippe Terrier, Yves Schutz.
     2) “Comparison of Step Length Estimators from Weareable Accelerometer
        Devices” by Diego Alvarez, Rafael C. Gonzalez, Antonio Lopez, Juan C.

7.2 – Development environment
Most of the project was written for the BREW environment, using the BREW
development environment. Here’s a link.

Also, we have used three free Java libraries in order to establish a connection
between the Wii remote and a PC computer.

1) “WiiremoteJ” – the primary library we have used.
2) “BlueCove” – an auxiliary Bluetooth library.
3) “Commons-Logging” – an auxiliary logging library.


To top