--- /dev/null
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+<title>Sensor Boards</title>
+<meta name="author" content="David Gay, Phil Levis, Wei Hong, and Joe Polastre" />
+<style type="text/css">
+
+/*
+:Author: David Goodger
+:Contact: goodger@users.sourceforge.net
+:date: $Date$
+:version: $Revision$
+:copyright: This stylesheet has been placed in the public domain.
+
+Default cascading style sheet for the HTML output of Docutils.
+*/
+body {
+ font-family: Times;
+ font-size: 16px;
+}
+
+.first {
+ margin-top: 0 ! important }
+
+.last {
+ margin-bottom: 0 ! important }
+
+.hidden {
+ display: none }
+
+a.toc-backref {
+ text-decoration: none ;
+ color: black }
+
+blockquote.epigraph {
+ margin: 2em 5em ; }
+
+dd {
+ margin-bottom: 0.5em }
+
+/* Uncomment (& remove this text!) to get bold-faced definition list terms
+dt {
+ font-weight: bold }
+*/
+
+div.abstract {
+ margin: 2em 5em }
+
+div.abstract p.topic-title {
+ font-weight: bold ;
+ text-align: center }
+
+div.attention, div.caution, div.danger, div.error, div.hint,
+div.important, div.note, div.tip, div.warning, div.admonition {
+ margin: 2em ;
+ border: medium outset ;
+ padding: 1em }
+
+div.attention p.admonition-title, div.caution p.admonition-title,
+div.danger p.admonition-title, div.error p.admonition-title,
+div.warning p.admonition-title {
+ color: red ;
+ font-weight: bold ;
+ font-family: sans-serif }
+
+div.hint p.admonition-title, div.important p.admonition-title,
+div.note p.admonition-title, div.tip p.admonition-title,
+div.admonition p.admonition-title {
+ font-weight: bold ;
+ font-family: sans-serif }
+
+div.dedication {
+ margin: 2em 5em ;
+ text-align: center ;
+ font-style: italic }
+
+div.dedication p.topic-title {
+ font-weight: bold ;
+ font-style: normal }
+
+div.figure {
+ margin-left: 2em }
+
+div.footer, div.header {
+ font-size: smaller }
+
+div.line-block {
+ display: block ;
+ margin-top: 1em ;
+ margin-bottom: 1em }
+
+div.line-block div.line-block {
+ margin-top: 0 ;
+ margin-bottom: 0 ;
+ margin-left: 1.5em }
+
+div.sidebar {
+ margin-left: 1em ;
+ border: medium outset ;
+ padding: 0em 1em ;
+ background-color: #ffffee ;
+ width: 40% ;
+ float: right ;
+ clear: right }
+
+div.sidebar p.rubric {
+ font-family: sans-serif ;
+ font-size: medium }
+
+div.system-messages {
+ margin: 5em }
+
+div.system-messages h1 {
+ color: red }
+
+div.system-message {
+ border: medium outset ;
+ padding: 1em }
+
+div.system-message p.system-message-title {
+ color: red ;
+ font-weight: bold }
+
+div.topic {
+ margin: 2em }
+
+h1 {
+ font-family: Arial, sans-serif;
+ font-size: 20px;
+}
+
+h1.title {
+ text-align: center;
+ font-size: 32px;
+}
+
+h2 {
+ font-size: 16px;
+ font-family: Arial, sans-serif;
+}
+
+h2.subtitle {
+ text-align: center }
+
+h3 {
+ font-size: 12px;
+ font-family: Arial, sans-serif;
+}
+
+hr {
+ width: 75% }
+
+ol.simple, ul.simple {
+ margin-bottom: 1em }
+
+ol.arabic {
+ list-style: decimal }
+
+ol.loweralpha {
+ list-style: lower-alpha }
+
+ol.upperalpha {
+ list-style: upper-alpha }
+
+ol.lowerroman {
+ list-style: lower-roman }
+
+ol.upperroman {
+ list-style: upper-roman }
+
+p.attribution {
+ text-align: right ;
+ margin-left: 50% }
+
+p.caption {
+ font-style: italic }
+
+p.credits {
+ font-style: italic ;
+ font-size: smaller }
+
+p.label {
+ white-space: nowrap }
+
+p.rubric {
+ font-weight: bold ;
+ font-size: larger ;
+ color: maroon ;
+ text-align: center }
+
+p.sidebar-title {
+ font-family: sans-serif ;
+ font-weight: bold ;
+ font-size: larger }
+
+p.sidebar-subtitle {
+ font-family: sans-serif ;
+ font-weight: bold }
+
+p.topic-title {
+ font-weight: bold }
+
+pre.address {
+ margin-bottom: 0 ;
+ margin-top: 0 ;
+ font-family: serif ;
+ font-size: 100% }
+
+pre.line-block {
+ font-family: serif ;
+ font-size: 100% }
+
+pre.literal-block, pre.doctest-block {
+ margin-left: 2em ;
+ margin-right: 2em ;
+ background-color: #eeeeee;
+ border-color: #000000;
+ border-width: thin;
+ font-size: 14px
+}
+
+span.classifier {
+ font-family: sans-serif ;
+ font-style: oblique }
+
+span.classifier-delimiter {
+ font-family: sans-serif ;
+ font-weight: bold }
+
+span.interpreted {
+ font-family: sans-serif }
+
+span.option {
+ white-space: nowrap }
+
+span.option-argument {
+ font-style: italic }
+
+span.pre {
+ white-space: pre }
+
+span.problematic {
+ color: red }
+
+table {
+ margin-top: 0.5em ;
+ margin-bottom: 0.5em }
+
+table.citation {
+ border-left: solid thin gray ;
+ padding-left: 0.5ex }
+
+table.docinfo {
+ margin: 2em 4em;
+}
+
+table.footnote {
+ border-left: solid thin black ;
+ padding-left: 0.5ex }
+
+td, th {
+ padding-left: 0.5em ;
+ padding-right: 0.5em ;
+ vertical-align: top }
+
+th.docinfo-name, th.field-name {
+ font-weight: bold ;
+ text-align: left ;
+ white-space: nowrap;
+ }
+
+h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
+ font-size: 100% }
+
+tt {}
+
+ul.auto-toc {
+ list-style-type: none }
+
+</style>
+</head>
+<body>
+<div class="document" id="sensor-boards">
+<h1 class="title">Sensor Boards</h1>
+<table class="docinfo" frame="void" rules="none">
+<col class="docinfo-name" />
+<col class="docinfo-content" />
+<tbody valign="top">
+<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">109</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Core Working Group</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
+</tr>
+<tr><th class="docinfo-name">Status:</th>
+<td>Draft</td></tr>
+<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
+</tr>
+<tr><th class="docinfo-name">Author:</th>
+<td>David Gay, Phil Levis, Wei Hong, and Joe Polastre</td></tr>
+<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">19-Apr-2005</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.1</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2005-10-31</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
+</tr>
+</tbody>
+</table>
+<div class="note">
+<p class="first admonition-title">Note</p>
+<p class="last">This memo documents a part of TinyOS for the TinyOS Community, and
+requests discussion and suggestions for improvements. Distribution
+of this memo is unlimited. This memo is in full compliance with
+TEP 1.</p>
+</div>
+<div class="section">
+<h1><a id="abstract" name="abstract">Abstract</a></h1>
+<p>This memo documents how sensor boards are organized in TinyOS, and the
+general principles followed by the components that provide access to
+its sensors.</p>
+</div>
+<div class="section">
+<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
+<p>This document defines the default organization of a sensor board in
+TinyOS. There likely will be sensor boards that cannot conform
+to this specification, but following as closely to its spirit as possible
+will simplify generic applications that use a range of sensor boards.</p>
+<p>This document assumes that sensors return uninterpreted 16-bit values, and,
+optionally uninterpreted, arbitrary-size calibration data. Conversion of
+sensor values to something with actual physical meaning is beyond the
+scope of this document.</p>
+</div>
+<div class="section">
+<h1><a id="directory-organization" name="directory-organization">2. Directory Organization</a></h1>
+<ul class="simple">
+<li>A sensor board MUST have a unique name, composed of letters, numbers
+and underscores. Case is significant, but two sensor boards MUST
+differ in more than case. This is necessary to support platforms where
+filename case differences are not significant. We will use SBOARD to
+denote the sensor board name in the rest of this document.</li>
+<li>Each sensor board MUST have its own directory named SBOARD; default TinyOS
+sensor boards are placed in tinyos-2.x/tos/sensorboards, but
+sensor board directories can be placed anywhere as long as the nesC compiler
+receives a <cite>-I</cite> directive pointing to the sensor board's directory.</li>
+<li>Each sensor board directory MUST contain a <cite>.sensor</cite> file. This file
+is a perl script which contains any additional compiler settings needed for
+this sensor board (this file will be empty in many cases).</li>
+<li>If the sensor board wishes to define any C types or constants, it SHOULD
+place these in a file named SBOARD.h in the sensor board's directory.</li>
+<li>The sensor board directory SHOULD contain sensor board components
+for accessing each sensor on the sensor board. The conventions for these
+components are detailed in Section 3.</li>
+<li>A sensor board MAY include additional components providing alternative or
+higher-level interfaces to the sensors (e.g., for TinyDB). These components
+are beyond the scope of this document.</li>
+<li>Finally, the sensor board MAY contain any number of components,
+interfaces, C files, etc for internal use. To avoid name collisions, all
+externally visible names (interface types, components, C constants and
+types) used for internal purposes SHOULD be prefixed with SBOARD. All such
+components should end in P.</li>
+</ul>
+<p>A simple example: the basic sensor board is named <cite>basicsb</cite>, it's directory
+is <cite>tinyos-2.x/tos/sensorboards/basicsb</cite>. It has no <cite>basicsb.h</cite> file and
+its <cite>.sensor</cite> file is empty. It has two components, <cite>PhotoC</cite> and <cite>TempC</cite>
+representing its light and temperature sensors.</p>
+</div>
+<div class="section">
+<h1><a id="sensor-board-components" name="sensor-board-components">3. Sensor Board Components</a></h1>
+<p>We have not yet selected any naming conventions for sensor board
+components. Please select reasonable namesldots</p>
+<p>A sensor board component MUST provide:</p>
+<ul class="simple">
+<li>An <cite>Init</cite> interface.</li>
+<li>A <cite>StdControl</cite> or <cite>SplitControl</cite> interface for power management.</li>
+<li>A non-empty set of <cite>AcquireData</cite> interfaces for sampling.</li>
+</ul>
+<p>A sensor board component MAY provide:</p>
+<ul class="simple">
+<li>Some <cite>CalibrationData</cite> interfaces for obtaining calibration data.
+A calibration interface for a sensor accessed via interface X should
+be called XCalibration.</li>
+<li>Some <cite>AcquireDataNow</cite> and <cite>AcquireDataBuffered</cite> interfaces, for high-speed
+or low-latency data acquisition.</li>
+<li>Any other appropriate interface.</li>
+</ul>
+<p>The <cite>CalibrationData</cite> interface is shown below, while <cite>AcquireData</cite>,
+<cite>AcquireDataNow</cite> and <cite>AcquireDataBuffered</cite> are in TEP 101. The
+<cite>AcquireData</cite> interface returns uinterpreted 16-bit data. This might
+represent an A/D conversion result, a counter, etc. The optional
+calibration interface returns uninterpreted, arbitrary-size data.</p>
+<p>A sensor board component SHOULD be as lightweight as possible - it should
+just provide basic access to the physical sensors and SHOULD NOT attempt to do
+calibration, signal processing, etc. If such functionality is desired, it
+SHOULD be provided in separate components.</p>
+<div class="line-block">
+<div class="line-block">
+<div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">CalibrationData</span> <span class="pre">{</span></tt></div>
+<div class="line-block">
+<div class="line-block">
+<div class="line"><tt class="docutils literal"><span class="pre">/*</span> <span class="pre">Collect</span> <span class="pre">uninterpreted</span> <span class="pre">calibration</span> <span class="pre">data</span> <span class="pre">from</span> <span class="pre">a</span> <span class="pre">sensor</span> <span class="pre">*/</span></tt></div>
+<div class="line"><br /></div>
+<div class="line"><tt class="docutils literal"><span class="pre">/**</span> <span class="pre">Request</span> <span class="pre">calibration</span> <span class="pre">data</span></tt></div>
+<div class="line-block">
+<div class="line"><tt class="docutils literal"><span class="pre">*</span> <span class="pre">@return</span> <span class="pre">SUCCESS</span> <span class="pre">if</span> <span class="pre">request</span> <span class="pre">accepted,</span> <span class="pre">FAIL</span> <span class="pre">if</span> <span class="pre">it</span> <span class="pre">is</span> <span class="pre">refused</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">*</span> <span class="pre">data</span> <span class="pre">error</span> <span class="pre">will</span> <span class="pre">be</span> <span class="pre">signaled</span> <span class="pre">if</span> <span class="pre">SUCCESS</span> <span class="pre">is</span> <span class="pre">returned</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">*/</span></tt></div>
+</div>
+<div class="line"><tt class="docutils literal"><span class="pre">command</span> <span class="pre">result_t</span> <span class="pre">get();</span></tt></div>
+<div class="line"><br /></div>
+</div>
+<div class="line"><tt class="docutils literal"><span class="pre">/**</span> <span class="pre">Returns</span> <span class="pre">calibration</span> <span class="pre">data</span></tt></div>
+<div class="line-block">
+<div class="line"><tt class="docutils literal"><span class="pre">*</span> <span class="pre">@param</span> <span class="pre">x</span> <span class="pre">Pointer</span> <span class="pre">to</span> <span class="pre">(uinterpreted)</span> <span class="pre">calibration</span> <span class="pre">data.</span> <span class="pre">This</span> <span class="pre">data</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">*</span> <span class="pre">must</span> <span class="pre">not</span> <span class="pre">be</span> <span class="pre">modified.</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">*</span> <span class="pre">@param</span> <span class="pre">len</span> <span class="pre">Length</span> <span class="pre">of</span> <span class="pre">calibration</span> <span class="pre">data</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">*</span> <span class="pre">@return</span> <span class="pre">Ignored.</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">*/</span></tt></div>
+</div>
+<div class="line"><tt class="docutils literal"><span class="pre">event</span> <span class="pre">result_t</span> <span class="pre">data(const</span> <span class="pre">void</span> <span class="pre">*x,</span> <span class="pre">uint8_t</span> <span class="pre">len);</span></tt></div>
+</div>
+</div>
+<div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
+</div>
+<p>Some common setups for sensor board components are:</p>
+<ul class="simple">
+<li>A single <cite>AcquireData</cite> interface. This is probably the most common case,
+where a single component corresponds to a single physical sensor, e.g., for
+light, temperature, pressure and there is no expectation of high sample
+rates.</li>
+<li>Multiple <cite>AcquireData</cite> interfaces. Some sensors might be strongly
+related, e.g., the axes of an accelerometer. A single component could then
+provide a sensor interface for each axis. For instance, a 2-axis
+accelerometer which can be sampled at high speed, and which has some
+calibration data might be declared with:</li>
+</ul>
+<div class="line-block">
+<div class="line"><tt class="docutils literal"><span class="pre">configuration</span> <span class="pre">Accelerometer2D</span> <span class="pre">{</span></tt></div>
+<div class="line-block">
+<div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">{</span></tt></div>
+<div class="line-block">
+<div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">StdControl</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">AcquireData</span> <span class="pre">as</span> <span class="pre">AccelX;</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">AcquireDataNow</span> <span class="pre">as</span> <span class="pre">AccelXSingle;</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">AcquireDataBuffered</span> <span class="pre">as</span> <span class="pre">AccelXMultiple;</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">CalibrationData</span> <span class="pre">as</span> <span class="pre">AccelXCalibration;</span></tt></div>
+<div class="line"><br /></div>
+<div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">AcquireData</span> <span class="pre">as</span> <span class="pre">AccelY;</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">AcquireDataNow</span> <span class="pre">as</span> <span class="pre">AccelYSingle;</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">AcquireDataBuffered</span> <span class="pre">as</span> <span class="pre">AccelYMultiple;</span></tt></div>
+<div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">CalibrationData</span> <span class="pre">as</span> <span class="pre">AccelYCalibration;</span></tt></div>
+</div>
+<div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
+</div>
+<div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
+</div>
+<ul class="simple">
+<li>A parameterised <cite>AcquireData</cite> interface. If a sensor board has multiple
+similar sensors, it may make sense to provide a single component to access
+all of these, using a parameterised <cite>AcquireData</cite> interface. For instance,
+a general purpose sensor board with multiple A/D channels might provide an
+<cite>AcquireData</cite> interface parameterised by the A/D channel id.</li>
+<li>In all of these examples, if high-speed sampling makes sensor for the
+sensor (e.g., a microphone), and the sensor is connected in a way that
+supports high-frequency and/or low-latency access (e.g., via an
+on-microcontroller A/D converter), the component should offer
+<cite>AcquireDataNow</cite> and <cite>AcquireDataBuffered</cite> interfaces.</li>
+</ul>
+<p>Sensor board components MUST respect the following conventions
+on the use of the <cite>Init</cite>, <cite>StdControl</cite>, and <cite>SplitControl</cite>
+interfaces. These are given assuming <cite>StdControl</cite> is used, but the
+behaviour with <cite>SplitControl</cite> is identical except that <cite>start</cite> and <cite>stop</cite>
+are not considered complete until the <cite>startDone</cite> and <cite>stopDone</cite> events are
+signaled. The conventions are:</p>
+<ol class="arabic">
+<li><p class="first"><cite>Init.init</cite>: must be called at mote boot time.</p>
+</li>
+<li><dl class="first docutils">
+<dt><cite>StdControl.start</cite>: ensure the sensor corresponding to this component is</dt>
+<dd><p class="first">ready for use. For instance, this should power-up the sensor if
+necessary. The application can call <cite>getData</cite> once <cite>StdControl.start</cite>
+completes.</p>
+<p class="last">If a sensor takes a while to power-up, the sensor board implementer can
+either use a <cite>SplitControl</cite> interface and signal <cite>startDone</cite>
+when the sensor is ready for use, or delay <cite>dataReady</cite> events
+until the sensor is ready. The former choice is preferable.</p>
+</dd>
+</dl>
+</li>
+<li><p class="first"><cite>StdControl.stop</cite>: put the sensor in a low-power mode.
+<cite>StdControl.start</cite> must be called before any further readings
+are taken. The behaviour of calls to <cite>StdControl.stop</cite> during
+sampling (i.e., when an <cite>dataReady</cite> event is going to be
+signaled) is undefined.</p>
+</li>
+</ol>
+</div>
+<div class="section">
+<h1><a id="sensor-file" name="sensor-file"><cite>.sensor</cite> File</a></h1>
+<p>This file is a perl script which gets executed as part of the <cite>ncc</cite>
+nesC compiler frontend. It can add or modify any compile-time options
+necessary for a particular sensor board. It MAY modify the following perl
+variables, and MUST NOT modify any others:</p>
+<ul class="simple">
+<li>@new_args: This is the array of arguments which will be
+passed to nescc. For instance, you might add an include directive
+to @new_args with push @new_args, <cite>-Isomedir</cite></li>
+<li>@commonboards: This can be set to a list of sensor board names which
+should be added to the include path list. These sensor boards must be
+in tinyos-2.x/tos/sensorboards.</li>
+</ul>
+</div>
+<div class="section">
+<h1><a id="example-mts3x0" name="example-mts3x0">Example: mts3x0</a></h1>
+<p>The mica sensor board (mts300/mts310) has five sensors (and one actuator,
+the sounder) -- the accelerometer and magnetometer are only present on
+the mts310:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<tbody valign="top">
+</tbody>
+</table>
+<div class="line-block">
+<div class="line">Name | Component | Sensor Interfaces | Other Interfaces |</div>
+</div>
+<p>+===============+===========+===================+==================+</p>
+<div class="line-block">
+<div class="line">Accelerometer | AccelC | AccelX | |</div>
+</div>
+<div class="line-block">
+<div class="line">| | AccelY | |</div>
+</div>
+<div class="line-block">
+<div class="line">Magnetometer | MagC | MagX | MagSetting |</div>
+</div>
+<div class="line-block">
+<div class="line">| | MagY | |</div>
+</div>
+<div class="line-block">
+<div class="line">Microphone | MicC | MicADC | Mic |</div>
+</div>
+<div class="line-block">
+<div class="line">| | | MicInterrupt |</div>
+</div>
+<div class="line-block">
+<div class="line">Light | PhotoC | PhotoADC | |</div>
+</div>
+<div class="line-block">
+<div class="line">Temperature | TempC | TempADC | |</div>
+</div>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<tbody valign="top">
+</tbody>
+</table>
+<p>Each physical sensor is represented by a separate component. Specific
+sensors that have more than one axis of measurement (AccelC and MagC)
+provide more than one <cite>AcquireData</cite> interface on a single component. Some
+sensors, such as the magnetometer and microphone, have additional
+functionality provided through sensor-specific interfaces.</p>
+<p>Although light and temperature are represented by separate components, in
+reality they share a single microcontroller pin. The two components PhotoC
+and TempC sit on top of the PhotoTempP component, which controls access to
+the shared pin, and orchestrates which sensor is currently connected to
+it. From a programmer's perspective, they appear as individual sensors,
+even though their underlying implementation is a bit more complex.</p>
+<p>The board's mts3x0.h file contains private configuration data
+(pin usage, ADC ports, etc).</p>
+<p>The mica sensor board has an empty .sensor file.</p>
+</div>
+<div class="section">
+<h1><a id="author-s-address" name="author-s-address">6. Author's Address</a></h1>
+<div class="line-block">
+<div class="line">David Gay</div>
+<div class="line">2150 Shattuck Ave, Suite 1300</div>
+<div class="line">Intel Research</div>
+<div class="line">Berkeley, CA 94704</div>
+<div class="line"><br /></div>
+<div class="line">phone - +1 510 495 3055</div>
+<div class="line"><br /></div>
+<div class="line">email - <a class="reference" href="mailto:david.e.gay@intel.com">david.e.gay@intel.com</a></div>
+<div class="line"><br /></div>
+<div class="line">Wei Hong</div>
+<div class="line">Arched Rock</div>
+<div class="line">Berkeley, CA 94704</div>
+<div class="line"><br /></div>
+<div class="line">email - <a class="reference" href="mailto:wei.hong@gmail.com">wei.hong@gmail.com</a></div>
+<div class="line"><br /></div>
+<div class="line">Philip Levis</div>
+<div class="line">358 Gates Hall</div>
+<div class="line">Computer Science Department</div>
+<div class="line">353 Serra Mall</div>
+<div class="line">Stanford, CA 94305</div>
+<div class="line"><br /></div>
+<div class="line">phone - +1 650 725 9046</div>
+<div class="line"><br /></div>
+<div class="line">email - <a class="reference" href="mailto:pal@cs.stanford.edu">pal@cs.stanford.edu</a></div>
+<div class="line"><br /></div>
+<div class="line">Joe Polastre</div>
+<div class="line">467 Soda Hall</div>
+<div class="line">UC Berkeley</div>
+<div class="line">Berkeley, CA 94720</div>
+<div class="line"><br /></div>
+<div class="line">email - <a class="reference" href="mailto:polastre@cs.berkeley.edu">polastre@cs.berkeley.edu</a></div>
+</div>
+</div>
+</div>
+</body>
+</html>
projects / tinyos-2.x.git / blobdiff