Marathon Man
`
`by
`Maria S. Redin
`
`Submitted to the Department of Electrical Engineering and Computer Science
`in Partial Fulfillment of the Requirements for the Degrees of
`Bachelor of Science in Computer Science and Engineering
`and Master of Engineering in Electrical Engineering and Computer Science
`at the Massachusetts Institute of Technology
`
`June 15, 1998
`
`-
`
`@ Copyright 1998 MIT Media Labratory and Maria S. Redin. All rights reserved.
`
`The author hereby grants to M.I.T. permission to reproduce and
`distribute publicly paper and electronic copies of this thesis
`and to grant others the right to do so.
`
`Department of Eietacal tngne
`
`ad Computer Science
`June 15, 1998
`
`1w
`
`,-
`-
`--
`VwW O.icha .H ley
`The
`Sup
`isor
`
`/ -" Arthur C. Smith
`Chairman, Department Comfnittee on Graduate Theses
`
`Author
`
`Certified by
`
`Accepted by
`
`-141998
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 1
`
`

`

`Marathon Man
`
`by Maria S. Redin
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 2
`
`

`

`|PR2020-00910
`
`Garmin, et al. EX1029 Page 3
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 3
`
`

`

`Telvision
`Newpaper
`
`6 Conclusion
`
`Future Work
`Sensor Hardware Architecture
`Communications Systems
`Power Management
`Human Factors
`Data Gathering
`Data Display
`Data Understanding
`Spin-Offs
`A Final Word
`
`7 Appendix
`
`8 References
`
`Table of Contents
`
`Acknowledgments
`Abstract
`
`1 Introduction
`
`The Story
`The Concept
`
`2 Background
`
`Wearable Computing
`PAN and BodyNet
`Affective Computing
`Soldier Monitoring
`Muscles and Lost Patients
`Sports Instrumentation
`
`3 Vision and Requirements
`
`Requirements
`
`4 Technical Specifications
`
`Data Acquisition
`Global Positioning System Receiver
`Heart Rate Monitor
`Temperature
`Cadence
`IRX
`Local Logging and Transmission
`Local Logger
`Wireless Transmission Link
`Remote Logging and Display
`Server Software
`Display Applets
`Other Elements
`Connections
`Batteries
`Packaging
`Cellular Phone Link
`Support Team
`Other Alternatives
`
`5 Observations
`
`Boston Marathon
`San Francisco Marathon
`Data Sets
`Time Scale
`Media Coverage
`Internet
`
`Marathon Man
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 4
`
`

`

`|PR2020-00910
`
`Garmin, et al. EX1029 Page 5
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 5
`
`

`

`For this thesis, I had a whole team of people to help
`me design,
`laugh,
`research, deal,
`redesign, gripe,
`develop, think, solder, consult, glue, organize, pack,
`understand, pad, break, tape, encourage, photograph,
`whine, code, sigh, draw, listen, read, support, read
`some more, help, type, smile, correct... well, the list is
`endless.
`
`My gratitude goes to them: Matt Debski, Brad Geilfuss,
`Matt Gray, Kristin Hall, Michael Hawley, Matt Lau,
`Rob Poor, Oliver Roup, and Manish Tuteja. Alas,
`without them, PIA would still be talking to penguins.
`
`© B
`
`ut I would specially like to thank Brad Geilfuss,
`Michael Hawley, and Rob Poor. They
`took on
`responsibilities beyond their fair share. A specially big
`thanks to Jason Hunter, who gave me an inordinate
`amount of his love, time, patience and support.
`
`All pictures were taken by members of PIA unless
`otherwise noted.
`
`Acknowledgments
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 6
`
`

`

`Abstract
`
`This thesis describes the design and development of
`the Marathon Man system. The system consists of a
`personal "black box" recorder worn on a belt that logs
`time, latitude, longitude, direction, speed, heart rate,
`In
`temperature and running pace of the wearer.
`the system can transmit this
`addition to logging,
`information wirelessly to an Internet server. The
`server stores the information and makes it available to
`arbitrary Internet applications, like Java applets, which
`display it.
`
`The goal of this project was to engineer such a system
`and take it through a number of grueling tests in order
`to illuminate the practical aspects of the design and its
`performance in real field situation.
`
`Marathon Man
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 7
`
`

`

`|PR2020-00910
`
`Garmin, et al. EX1029 Page 8
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 8
`
`

`

`ntroduction
`
`ntroduction
`
`1I
`1 I
`
`|PR2020-00910
`
`Garmin, et al. EX1029 Page 9
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 9
`
`

`

`The Story
`
`Hawley, Wisneski and Geilfuss take
`their pills before the marathon.
`
`On a bright and sunny April morning in Hopkinton,
`Massachusetts, three MIT scientists were sitting in the
`grass, watching a large crowd gather along Main Street.
`Just before 8 a.m. each took out a lumpy white pill and
`swallowed it with a gulp of water. Standing up, they
`wove their way through the crowd on to Main Street,
`and ran the Boston Marathon in the name of science.
`The pills were radio thermometers. They transmitted
`core body temperature to a tiny receiver each runner
`carried in a belt pack. The belt pack was a "black box
`for humans", capable of logging footsteps, heart rate,
`and GPS position, as well as body temperature. These
`vital statistics were to be recorded in a small computer
`ready to be relayed live to the Internet. The runners,
`Brad Geilfuss, Craig Wisneski, and Professor Michael
`Hawley, were the first runners to carry live health
`monitors during a marathon 1. Five hours later, all
`three of them had crossed the finish line. However,
`only Professor Hawley was still carrying his sensors;
`the other two had left their recorders behind near mile
`20. Much analysis would ensue aiming to understand
`what had worked, what had not, and what was to
`follow this five-hour experiment.
`
`Three months later on the morning of July 13th, the
`weather in San Francisco was cold and rainy. Geilfuss
`and Hawley were standing on the Golden Gate bridge
`in a thick and gray mist, shivering. They were joined
`by Anil Tiwari, a serious amateur runner from Trimble,
`Inc.. The sensors and recording system had been
`redesigned and repackaged after Boston, and were
`ready for yet another marathon. A film crew from
`ABC World News Tonight began interviewing them.
`At the same time, a lone MIT engineer, groggy from an
`all-night computer hacking session, worked to set up a
`temporary web site at "Mission Control" just south of
`Market Street. A little after 7:30 a.m., as the runners
`began making their way towards San Francisco, he
`watched as bits from the runners' sensors began to
`
`1 Apparently, Associates & Ferren attempted to transmit a live heart
`rate from a runner in the New York Marathon to ABC television in
`the 1980's, using an infrared beacon and an observer in a
`helicopter. Unfortunately when the runner discovered he was in
`the lead, he jettisoned the equipment, and it was trampled by the
`rest of the pack [2].
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 10
`
`

`

`The Concept
`
`TV cameras film the team preparing
`the runners for the marathon.
`
`blink on to the computer screen. Vital statistics were
`not only being logged, but also broadcast live to the
`Internet.
`
`Kazuhiko Nishi of ASCII Corporation suggested that
`it might be interesting to build "black box" flight
`recorders for cars to capture data at the time of a
`crash. Digital technology had evolved to the point
`where a black box for cars is already underway. Every
`that all
`Formula One car has a crash recorder
`information relevant to the car. Pushing Nishi's idea
`in a different direction, we decided a challenging
`application would be a personal black box that could
`relay its information live. Marathon Man began in
`January of 1997 as a device that would gather data
`about the location and health of its wearer just as its
`airborne counterpart records data about a plane's flight
`plan and status. We proposed to build it and test its
`capabilities in the Boston Marathon.
`
`This system looked at the heart rate, temperature,
`cadence and location of three athletes as they ran a
`marathon. We wanted to record these statistics and
`relay them live to the Internet. Our goal was to gain
`an understanding of the engineering necessary to create
`a personal device capable of large-scale and real-time
`sensory collection for extended periods of time and
`under varied conditions. The previous scenarios were
`the culmination of months of engineering and the first
`two large-scale tests of the Marathon Man system.
`
`to
`is
`The larger goal of the Black Box Project
`understand the requirements and nuances of complete
`systems that bring real-time information from the
`physical world to a virtual realm where it can be
`collected and used in different applications. Marathon
`Man gathered vital statistics from three runners while
`they ran a marathon and relayed the information back
`to be displayed on the web. Kevin Kelley, of Wired
`Magazine, points out that although there are currently
`500 million processors in PC's around the world, most
`people are unaware of the over 6 billion somewhat
`more modest computer chips in objects like cars,
`appliances, and toys. Furthermore, the computational
`
`Marathon Man
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 11
`
`

`

`power in such "things" is increasing at a rate vastly
`greater than that of conventional computers[l]. The
`to perform complex
`power of everyday objects
`computational tasks is generating a whole new category
`of "intelligent objects." As these objects attempt to
`behave in an intelligent manner they will need more
`and more information about their surrounding. This
`raises innumerable questions about how to get this
`information, how to store it, how to manage it, how to
`share it and how to understand it. Black Box's first
`project exploring these questions was Marathon Man -
`- a "personal black box".
`
`This thesis describes the work done on the Marathon
`Man system from conception to execution in both the
`Boston and the San Francisco marathons. Chapter 2
`to
`the
`relating
`describes work done by others
`Marathon Man system. Chapter 3 gives an overview of
`the vision and requirements of the system. Chapter 4
`explains the technical specifications of the systems
`built for the Boston and San Francisco marathons and
`the reasoning behind the architecture. Chapter 5
`discusses the engineering observations made during
`both marathons. Finally, Chapter 6 provides a wrap
`up discussion of what was learned, where this research
`is heading, and future projects based on this system.
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 12
`
`

`

`ackground
`
`ackground
`
`2 B
`2 B
`
`|PR2020-00910
`
`Garmin, et al. EX1029 Page 13
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 13
`
`

`

`It need not take much technology to run a marathon.
`In fact, running shoes are perhaps the most advanced
`piece of engineering on a runner, and Abebe Bikila
`won the 1960 Rome Olympic Marathon without them.
`This thesis documents the first time anyone has run a
`marathon with substantial live computer monitoring.
`is
`similar
`It
`to other
`efforts of
`scientific
`instrumentation in that we want to measure certain
`body signals, but it differs in that we have a more
`capture
`and
`transmission
`set of
`demanding
`requirements.
`
`As we began to design the Marathon Man system for
`the runners, we discovered a number of components
`and similar efforts that were relevant to our project.
`We collaborated with several of these groups. They
`technical expertise, advice, and
`provided us with
`grounding for our work. The following sections
`discuss each of them.
`
`A human being is a particularly intriguing thing to wire
`with sensors. The notion of cybernetic clothing brings
`a whole new meaning to the term personal computing.
`Wearable technology seems to be gaining momentum
`as an important new field of interest. As evidence of
`this, cellular phones, pagers and small personal digital
`assistants
`have had enormous
`success
`in
`the
`marketplace. This suggests that computing power and
`communication devices that accompany us through
`out the day are reaching a high level of acceptance.
`Currently there is a burgeoning volume of research on
`wearable systems. For example, Steve Mann has
`investigated the benefits of carrying a computer with
`him at all times and applying its ubiquitous availability
`In addition, in the fall of
`for non-traditional tasks [3].
`1997, MIT hosted the first scientific conference on
`wearable systems and large-scale public symposium to
`discuss the diffusion of technology into clothing and
`personal articles [4].
`
`Wearable Computing
`
`research group at the
`Wearables'
`MIT Media Lab. @ S. Ogden
`
`BodyNet and PAN
`
`When one begins to look at the mechanics of at
`computing on and around the body, the problem of
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 14
`
`

`

`internetworking emerges. How might you send the
`information from your smart shoes to your watch or to
`your doctor? Olin Shivers at the MIT Laboratory for
`Computer Science proposed the notion of a BodyNet.
`A BodyNet is a communications medium that utilizes
`the electromagnetic properties of the human body to
`communicate information between peripheral devices.
`Each of the devices shares the medium, much the same
`way that the different devices in a computer share its
`data bus [5]. Neil Gershenfeld and his team at the
`Media Lab have created early forms of this medium,
`which they describe as "Personal Area Networking"
`[6]. His team is continuing to explore the speed and
`bandwidth issues involved in utilizing this medium for
`personal computer devices. Similarly, Phil Carvey of
`BBN has been working on an implementation of a
`two microjoules per
`system
`that requires
`radio
`transmitted bit and four microjoules per received bit
`for a network on the body [7].
`
`Networking in, on, and around a body is a nascent
`area, which has been driven into existence by the force
`of many practical needs. As sensors and personal
`networks mature, it will become possible to measure
`more interesting nuances in the signals generated by
`Is the person happy, or sad, or perhaps
`the body.
`angry? These questions fall into what Rosalind Picard
`has termed Affective Computing, a study of the
`different aspects of the relationships between human
`If the tools we
`emotional states and computing [8].
`use everyday can sense human emotions, then they can
`the
`from
`thus benefit
`accordingly and
`adjust
`information. The system worn by our marathon
`runners clearly points in this direction.
`
`In trying to improve the working and living conditions
`of its soldiers, the U.S. Army has been researching
`their soldiers under
`real
`technology
`to monitor
`conditions. At the moment, soldiers are assessed for
`fatigue by visual determination of the commanding
`officers. Unfortunately, commanding officers rarely
`have sufficient information about the actual state of
`
`Marathon Man
`
`transmitter and PAN
`PAN
`RS232-to-body modem.
`
`III
`
`Affective Computing
`
`Soldier Monitoring
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 15
`
`

`

`Muscles and Lost Patients
`
`accurately. To help alleviate
`this,
`the Army has
`developed
`systems similar
`to Marathon Man for
`monitoring soldiers during the course of their training.
`
`An example of this is the Body Core Temperature
`Monitor (BCTM) developed by BBN for the Defense
`Advance Research Project Agency (DARPA).
`It
`consists of a receiver and a pill developed by the Johns
`Hopkins University Applied Physics Laboratory
`in
`collaboration with NASA's Goddard Space Flight
`Center. Once the pill is ingested by the subject, it
`transmits a
`low-intensity
`radio-signal
`to a
`radio-
`receiving device that accumulates body temperature
`statistics.
`
`Medical science literature is filled with experiments
`measuring the many different parameters and signals of
`the human body. As we geared up for the marathon,
`we met the design team at the Boston University
`Neuromuscular Research Center led by Don Gilmore.
`They were working on measuring muscle fatigue
`through electromyographic measurements.
`They
`looked at the electric signals from the muscles across
`time and determined when the muscle was fatigued
`based on the variance in electromagnetic signals [9]. In
`time it would be very interesting to test these sensors in
`the real world.
`
`At Draper Laboratories not far from the Media Lab,
`work was done to combine paging technology with a
`Global Positioning System receiver. The aim was to
`track Alzheimer's patients as they moved around in
`their daily schedules.
`Such
`tracking allowed
`the
`patients greater
`freedom
`in
`their
`lives without
`sacrificing the security of around the clock monitoring.
`Draper created a simple device that captured GPS
`coordinates. The device then sent this data through a
`two-way pager
`to a medical
`tracking service
`[10].
`Unfortunately, the research was discontinued because
`of the high cost of paging and fact that GPS does not
`work indoors.
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 16
`
`

`

`Sports Instrumentation
`
`Screen shot of the Whitbread home
`page.
`
`tape and
`the discovery of measuring
`Ever since
`stopwatches people have felt much more in touch with
`the quantitative aspects of training and competition.
`Quokka, a San Francisco-based technology company,
`demonstrates a more ambitious example of sports
`instrumentation. They seek to link live sensors to
`athletes and equipment, and make the data from these
`sensors available through the Internet. Their goal is to
`bring the analyzed data to the home viewer as a new
`dimension to already existing sports events. This type
`of monitoring is similar to, though not quite as public
`as other efforts such as "helmet cameras" used on
`quarterbacks and skydivers or the real-time digitally
`traced hockey puck developed by FOX television [11].
`
`Currently, Quokka is monitoring the Whitbread yacht
`race by transmitting positional information and other
`details to their web site2. However, yacht racing as a
`sport avoids many of the more extreme problems
`like marathon
`inherent in more physical activities
`running. It will be interesting to see how their projects
`develop in comparison to the Marathon Man Project.
`
`Along the same lines, the BBN team pursuing the
`temperature monitor work spun off a startup company
`called Personal Electronic Devices (PED), Inc. PED
`in designing specialized health-
`is engaged
`Inc.
`monitoring systems for the consumer market place,
`and is currently working on a select few sensors and
`actuators which will enable users to monitor vital signs
`while participating in fitness activities. Their goal is to
`have devices that are stylish or inconspicuous, wireless
`and could be worn as apparel, jewelry, and fashion
`accessories. We worked directly with PED to modify a
`version of the pill-temperature sensor, and provided
`the opportunity for PED to test its sensors in-place in
`a complex recording system.
`
`2 http://www.whitbread.org/main.html
`
`Marathon Man
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 17
`
`

`

`|PR2020-00910
`
`Garmin, et al. EX1029 Page 18
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 18
`
`

`

`Vision +
`Requirements
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 19
`
`

`

`Imagine the following 20 minutes into the future:
`
`Maria is lying down on her couch after her daily run. A
`bit of analysis is being performed on the data she
`transmitted while she was running. As she walks over
`to the refrigerator for a drink, a projection is cast on
`the door. Position, heart rate, blood pressure, oxygen
`and sugar level graphs appear as she pours a glass of
`water. Her heart rate seems not to quite have calmed
`down from that last minute sprint. The map of her run
`plainly shows that today she took a little shortcut; she
`double-backed a little sooner than she should have.
`The data is clearly projected in front of her, and soon
`enough, it will be in front of her personal trainer as
`well, who will not like what he sees. Usually he
`monitors Maria from the gym while she is running,
`giving her feedback and motivation, shouting while she
`
`climbs the hills. She decides to console herself by
`
`looking at her best friend's data. Geeta was always the
`
`slacker anyway. She pulls up the data graphs for Geeta,
`and discovers she is running at the moment.
`In fact,
`she is at the very hill Maria decided to skip. A graph
`appears. It compares both heart rates versus altitude.
`It does not look good. Geeta has been training for only
`two weeks and her heart rate is already lower that
`Maria's. Maria decides that it is time to step up the
`training.
`
`The description in the paragraph above is one scenario
`of what a system like Marathon Man could do. The
`requirements for such physical system include minimal
`weight and size, ruggedness, self-encapsulation and
`extensibility. Let us examine each requirement.
`
`Minimal Weight and Site. Because running a marathon is
`a physically exhausting endeavor, the system must be as
`small and light as possible. Ideally, the system should
`be invisible to the runner. Worn on a belt or a vest, it
`should automatically start logging vital statistics once
`the runner puts it on.
`
`Ruggedness. A marathon is hard on the body and
`anything that goes with it. The system needs to be able
`to withstand the shock of long distance running.
`
`Requirements
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 20
`
`

`

`Sef-contained. We want to monitor the running without
`disrupting it. The runner should not have to interact
`with the system once it is working. This means that the
`runner should be able to turn on the system, put it on
`and complete a marathon without any other input to it.
`It should be as simple as putting on your shoes, if they
`are not already included in them.
`
`Extensibiliy. The Marathon Man system is only an
`instance of a typical Black Box project, so the base
`architecture needs to be modular. We want to facilitate
`the process of adding different sensors, updating or
`changing the data collection methods, trying different
`ways of data storage, etc.
`
`Marathon Man
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 21
`
`

`

`2222
`|PR2020-00910
`
`Garmin, et al. EX1029 Page 22
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 22
`
`

`

`4T
`
`echnical
`Specifications
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 23
`
`

`

`wireless
`receiver
`
`data display
`
`remote
`logging
`
`+'
`
`I
`
`the
`through
`flow
`Data
`components of the system.
`
`major
`
`Data Acquisition
`
`The system described in the vision above lends itself to
`be divided into five major components:
`
`* Data Acquisition
`* Local Logging
`* Wireless Transmission
`* Remote Logging
`* Data Display
`
`the data
`is done by
`The measurement of data
`acquisition hardware, which consists of an array of four
`satellite
`sensor measures GPS
`One
`sensors.
`information for time, position, speed and direction.
`The other sensors measure heart rate, temperature and
`cadence respectively. The data collected by the sensors
`is stored immediately by the local logging sub-system.
`Once secured, the transmission module sends the same
`data to the remote logging server, which takes the
`incoming data, stores it and indexes it for anyone who
`needs it. The data display applets take the information
`from the server and plot the data for visual analysis.
`
`The data acquisition hardware is made up of four
`sensors: a GPS unit, a heart rate monitor, a temperature
`sensor and a cadence measurement device. The four
`sensors have four wires: power, ground, ping and data,
`which are connected to the power and input pins of an
`IRX board [12]. The IRX continuously listens to the
`GPS data line for an output sentence. Once it hears
`the sentence from the receiver, it places the data on the
`serial line. The IRX then proceeds to query each of the
`remaining sensors, one at a time, for their current state.
`Raising the voltage on the ping line starts the querying
`for the particular sensor. Once the sensor detects the
`level change, it returns it state data. Each of the
`sensors' responses are tagged with the respective ID
`and sent through the serial line following the GPS
`sentence. Once all the sensors have been queried, the
`IRX returns to listening for the next GPS sentence.
`
`This architecture effectively emulates a master-slave
`arrangement with the IRX as the bus master and the
`GPS as the clock. The GPS receiver acts as the trigger
`for the querying cycle because we use the clock from
`the GPS as the time stamp for all the data. This cycle-
`based querying mode architecture can easily be
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 24
`
`

`

`modified to accommodate additional sensors by simply
`inserting them in the querying cycle. The following is a
`more detailed description of each of the components.
`
`Global Positioning System Receiver
`
`The Global Positioning System (GPS) is a collection of
`satellites owned by the U.S. Government. These geo-
`synchronous satellites provide worldwide positioning
`and navigation
`information by broadcasting
`their
`position at all times. GPS receivers listen for these
`satellites and use their beacon
`transmission as a
`reference point to determine precise location, direction
`and speed.
`
`For both marathons we used the Trimble Lassen SK-8
`OEM kits. They were the smallest GPS receivers
`available in the market. The kit consisted of a receiver
`board and an antenna. The power requirement was
`200mA at 5V. The frequency as well as the type of
`output was configurable. We chose ASCII NMEA
`$GPGGA and the $GPVTG 3 sentences once every
`second. The output was sent serially at TTL levels
`through one of the pins on the board at 4800 baud.
`This made it simple to connect to one of the pins of the
`IRX board for reception.
`
`Heart Rate Monitor
`
`To track heart rate data, the Marathon Man system uses
`Polar's monitoring equipment, which consists of a chest
`strap and an OEM receiver board. Each heartbeat is an
`electrical signal sent by the sinoatrial node to the heart
`muscles. This electrical impulse can be detected on the
`skin. The Polar chest strap detects
`the voltage
`differential generated by this signal and sends a wireless
`notification
`to the receiver.
`The receiver board
`
`3 The $GPGGA sentence contains UTC of position, latitude,
`longitude, GPS quality indicator, number of satellites in use,
`horizontal dilution of precision, antenna altitude, geodial
`separation in meters, age of differential GPS data and
`differential reference station. The $GPVTG sentence
`includes track made good in degrees true, track made good
`in degrees magnetic, speed over ground in knots and speed
`over ground in km per hour. Out of these we only use time,
`position, true direction, and speed in km per hour.
`
`Marathon Man
`
`Trimble Lassen SK-8 GPS receiver.
`
`Polar Heart Rate receiver board.
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 25
`
`

`

`calculates the rate and stores the data until it is polled
`by the IRX board.
`
`For both marathons we used this chest strap/receiver
`configuration. The receiver board utilized very little
`power. The output of the board was configured such
`that it would return 2 hexadecimal characters for heart
`rate each time one of the pins on the board was set to
`high. They were also transmitted at 4800 baud.
`
`Temperature
`
`As described in the Background chapter, BBN designed
`the BCTM unit for DARPA. The BCTM consists of
`two components: a pill transmitter and a receiver unit.
`The pill is a small non-toxic radio transmitter that
`generates a continuous radio signal, whose frequency
`changes in proportion to the temperature. When the
`pill is swallowed, these changes in frequency correlate
`with fluctuations in the core body temperature of its
`carrier. The receiver sits outside the body, typically on
`a belt pack and captures the signal. Although the data
`that comes back
`from
`the BCTM
`is directly
`proportional to the temperature, it still depends on a
`calibration number for the pill as well as a calibration
`number for the receiver.
`
`The BCTM was used for both marathons. The system
`had to be retrofitted to match our system because the
`original design stored the data in the receiver, and we
`wanted to have the information when requested. PED
`Inc. modified the system such that holding one of the
`pins high returned the state data. A set of frequency
`metrics was
`later used
`to decode
`the data and
`determine actual body temperature.
`
`Cadence
`
`PED Inc. designed the cadence sensor for the system.
`The cadence sensor is basically an accelerometer worn
`on the hip. The downward force of each footstep
`causes a spike on the accelerometer. Counting the
`number of spikes that are sufficiently large results in
`the number of steps. Both marathon systems used the
`cadence sensor. It is extremely lightweight and uses
`very little power because of its simple mechanism.
`
`Body Core Temperature Monitor
`receiver board.
`
`Cadence monitor board.
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 26
`
`

`

`Following our original architecture, the sensor returns
`the number of steps taken when one of the pins is held
`high.
`
`IRX
`
`The IRX board, designed by Rob Poor at the Media
`Lab, is a multi-purpose housing for a PIC 16C84 micro
`controller.
`It powers
`the chip, synchronizes
`its
`operations with a time crystal, and exposes the chips
`I/O pins for easier incorporation into larger devices.
`In addition, the IRX has logic for performing serial
`I/O operations. The PIC 16C84 is an EEPROM
`micro-controller with 14K of ROM and 36 bytes of
`data storage memory. It has 13 I/O pins, which take in
`TIL level logic.
`
`The IRX board was used as an arbitrator to collect the
`data of all of the sensors and serialize it for logging and
`transmission. The PIC 16C84 was adequate for this
`task; it had enough processing power to perform the
`synchronization and encoding operations and its light
`weight did not encumber the rest of the system. The
`program written for this task loops continually while
`listening on the pin assigned to the GPS. The ASCII
`sentence from the GPS consists of about 80 characters
`when all information is present. When the IRX hears
`this sentence, it starts to pass the characters to the serial
`output. This is necessary because the PIC does not
`have enough memory to store the whole sentence.
`Once the sentence has been fully
`transmitted, the
`querying cycle starts for the rest of the sensors. For
`each sensor, the IRX holds the ping pin high for a short
`amount of time. Then it listens on the return pin of the
`current sensor for the answer. The IRX takes the
`return data and concatenates it with the sensor's tag.
`The tags are "PR" for the heart rate, "CA" for cadence
`and "BT' for the temperature. The new tagged data
`item is then sent through the serial line to the logger.
`
`IRX board
`
`Logging and transmission of the collected data required
`more sophisticated hardware and software than could
`be provided by
`the
`IRX board and
`its PIC
`microprocessor.
`The
`local
`logging sub-system
`
`Local Logging and Transmission
`
`Marathon Man
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 27
`
`

`

`required about 2Mb of storage space for the data4. The
`transmission system required that the data be sent over
`a wireless communications network. These functions
`were combined and handled by a general purpose CPU
`running on a palmtop computer.
`
`The IRX board output is fed to the palmtop via its
`serial communications port. A custom written software
`sub-system interprets and stores the output. The sub-
`system takes the encoded data from the serial line and
`parses it, discarding the ID tags and compressing the
`remaining data. The compressed data is then saved to a
`file. Once the data is secured locally, a copy of it is
`transmitted through the wireless network link to the
`main server. This module is designed to do as little
`It simply serves as a pipe
`conversion as possible.
`between the sensors and the server.
`
`the
`is a complete CPU,
`the palmtop
`Although
`functionality we used was minimal and could have been
`built into a micro-controller more powerful than the
`16C84. However, utilizing the palmtops at this stage
`allowed us to assemble the system faster and use more
`conventional market driven products for the wireless
`network link for modularity. The palmtop computers
`running a conventional operating system permitted a
`number of different wireless network and software
`configurations; this allowed us to determine which
`architectures worked best without having to reconstruct
`the entire system each time. On the other hand, we
`could not use the palmtop to replace the IRX and act
`as a bus controller because it only had one serial port.
`It needed a "data funnel," namely the IRX board to
`serialize the sensor data.
`
`Local Logger
`
`The data logger for the Boston Marathon was a HP
`200LX palmtop computer running the DOS operating
`system. For the San Francisco Marathon, we updated
`our platform to a Compaq 120 palmtop computer
`running the Windows CE operating system. Both
`
`4 We estimated our runners would at most take 6 hours to finish
`the marathon. The system sent out state data each second. The
`data sentence consisted at most of 100 characters. Thus
`6*60*60*100 = 2MB.
`
`IPR2020-00910
`Garmin, et al. EX1029 Page 28
`
`

`

`SI hp 0l12 0X
`
`IIt.oide
`
`Lon1t.:.
`
`I~ ll
`
`It-co
`
`1 7:'55:35I 1703- , -I|N,1* ,6
`0
`6$12011 : SS7
`...
`
`1.- 1
`21 ,
`O06Ill 25 1361173 5140R42.16.946 W 1 22 5081 1.021 901466.11
`06 12211S5: 37117 33.S1141042 16.949 4071.22 5081 I 021 01466 21
`06123115:3I 17:13:).l;N042.11,946 O? 22 0 1 02 .
`I0146.21
`061241.:9