-<!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
- <title>Lesson 5: Sensing</title>
- <link href="../../stylesheets/tutorial.css" rel="stylesheet" type="text/css">
+<meta http-equiv="Refresh" content="5; url=http://docs.tinyos.net/index.php/Sensing">
</head>
-<body>
-
-<!-- $Id$ -->
-
-<div class="title">Lesson 5: Sensing</div>
-<div class="subtitle">Last Modified: 16 June 2006</div>
-
-<p> This lesson introduces sensor data acquisition in TinyOS. It demonstrates
-two sensor applications: a simple application called <a href="#sense">Sense</a>
-that periodically takes sensor readings and displays the values on the LEDs.
-And a more sophisticated application called <a
-href="#oscilloscope">Oscilloscope</a> where nodes periodically broadcast their
-sensor readings to a basestation node. Using the Mote-PC serial communication
-described in the <a href="lesson4.html">previous lesson</a> the basestation
-forwards the sensor readings to the PC, where they are visualized with a
-dedicated graphical user interface.
-
-<a name="introduction"><h1>Introduction</h1></a>
-
-<p> Sensing is an integral part of sensor network applications. In TinyOS 1.x
-sensing was syntactically connected with analog-to-digital converters (ADCs):
-TinyOS 1.x applications such as <code>Oscilloscope</code> or <code>Sense</code>
-used the <code>ADC</code> and <code>ADCControl</code> interfaces to collect
-sensor data. When new platforms appeared with sensors that were read out via
-the serial interface, not only additional interfaces like <code>ADCError</code>
-had to be introduced, but it became clear that equating a sensor with an ADC is
-difficult.
-
-<p> Usually sensing involves two tasks: configuring a sensor (and/or the
-hardware module it is attached to, for example an ADC or SPI) and reading the
-sensor data. The first task is tricky, because a sensing application like, for
-example, <code>Sense</code> is meant to run on any TinyOS platform. How can
-<code>Sense</code> know the configuration details (e.g. input channel, the
-required reference voltage, etc.) of an attached sensor ? It can't, because the
-configuration details of, for example, the light sensor on the <i>tmote</i>
-platform will be different from the <i>eyes</i> platform. Unless
-<code>Sense</code> knows about all sensors on all platforms it can't perform
-the configuration task, since the interfaces for the configuration of a sensor
-will differ from platform to platform (and potentially from sensor to sensor).
-However, the second task - reading the sensor data - can be solved so that the
-<code>Sense</code> application can collect sensor data even though it is
-agnostic to the platform it is running on.
-
-<p> In TinyOS 2.0 <i>platform independent</i> sensing applications such as
-<code>Oscilloscope</code>, <code>Sense</code> or <code>RadioSenseToLeds</code>
-are not using configuration interfaces like <code>ADCControl</code> anymore;
-instead they are only using the standard data acquisition interfaces
-<code>Read</code>, <code>ReadStream</code> or <code>ReadNow</code> for
-collecting sensor data. All configuration details are hidden from the
-application and this is why you can compile <code>Sense</code> and display
-sensor data on the <i>telosb</i> or the <i>micaz</i> platform, even though the
-actual sensors and their connection to the rest of the system may be completely
-different.
-
-<p> This raises questions like the following:
-
-<ul>
-
-<li> Since the <code>Sense</code> application component only uses standard
-data acquisition interfaces who defines what sensor it samples ?
-
-<li> If the <code>Sense</code> application component is not configuring the
-sensor, who is responsible for that ?
-
-<li> How can an application like <code>Sense</code> display sensor data when it
-does not know the details about sensor configuration ? This includes questions
-like "what is the value range of the sensor data" or "is a temperature reading
-to be interpreted in degree Celsius or Fahrenheit" ?
-
-<li> Let's assume there are several sensors on a platform: what steps have to
-be done to let the <code>Sense</code> or <code>Oscilloscope</code> application
-display data of a different sensor ?
-
-</ul>
-
-<p> After reading this tutorial you should be able to answer these questions.
-Using the <code>Sense</code> and <code>Oscilloscope</code> application as an
-example, the following sections explain how the data acquisition interfaces are
-used, how the configuration procedure works and, as an example, how
-<code>Sense</code> can be hooked up to a different than the default sensor on
-the <i>telosb</i> platform.
-
-<a name="sense"><h1>The Sense application</h1></a>
-
-<code>Sense</code> is a simple sensing demo application. It periodically
-samples the default sensor and displays the bottom bits of the readings on the
-LEDs. The <code>Sense</code> application can be found in
-<code>tinyos-2.x/apps/Sense</code>. Let's first look at the <code><a
-href="../../../apps/Sense/SenseAppC.nc">SenseAppC.nc</a></code> configuration:
-
-<pre>
-configuration SenseAppC
-{
-}
-implementation {
- components SenseC, MainC, LedsC, new TimerMilliC();
- components new DemoSensorC() as Sensor;
-
- SenseC.Boot -> MainC;
- SenseC.Leds -> LedsC;
- SenseC.Timer -> TimerMilliC;
- SenseC.Read -> Sensor;
-}
-</pre>
-
-The <code>SenseAppC</code> configuration looks similar to the
-<code>BlinkAppC</code> configuration described in <a href="lesson1.html">lesson
-1</a> (if you have not done so, read the sections on the Blink application in
-lesson 1). To understand the wiring let's look at the signature of the <code><a
-href="../../../apps/Sense/SenseC.nc">SenseC.nc</a></code> module:
-
-<pre>
-module SenseC
-{
- uses {
- interface Boot;
- interface Leds;
- interface Timer<TMilli>;
- interface Read<uint16_t>;
- }
-}
-</pre>
-
-Like the <code>BlinkC.nc</code> module the <code>SenseC.nc</code> module uses
-the interfaces <code>Boot</code>, <code>Leds</code> and
-<code>Timer<TMilli></code>. Additionally, it uses the
-<code>Read<uint16_t></code> interface. The sequence of actions in the
-<code>SenseC.nc</code> implementation is as follows: <code>SenseC.nc</code>
-uses the <code>Boot</code> interface to start a periodic timer after the system
-has been initialized. Every time the timer expires <code>SenseC.nc</code> is
-signalled a timer event and reads data via the
-<code>Read<uint16_t></code> interface. Reading data is a split-phase
-operation, it is divided in a command <code>Read.read()</code> and an event
-<code>Read.readDone()</code>. Thus every time the timer expires
-<code>SenseC.nc</code> calls <code>Read.read()</code> and waits for the
-<code>Read.readDone()</code> event. When data is signalled in the
-<code>Read.readDone()</code> event <code>SenseC.nc</code> displays it on the
-leds: the least significant bit is displayed on LED 0 (0 = off, 1 = on), the
-second least significant bit is displayed on LED 1 and so on. <p> The <code><a
-href="../../../tos/interfaces/Read.nc">Read</a></code> interface (in
-<code>tinyos-2.x/tos/interfaces</code>) can be used to read a single piece of
-sensor data, let's look at it in detail:
-
-<pre>
-interface Read<val_t> {
- /**
- * Initiates a read of the value.
- *
- * @return SUCCESS if a readDone() event will eventually come back.
- */
- command error_t read();
-
- /**
- * Signals the completion of the read().
- *
- * @param result SUCCESS if the read() was successful
- * @param val the value that has been read
- */
- event void readDone( error_t result, val_t val );
-}
-</pre>
-
-If you are not familiar with generic interfaces you will wonder what the
-meaning of <code><val_t></code> (in the first line) is and why the
-signature of <code>SenseC.nc</code> is using <code>Read<uint16_t></code>.
-What you see above is a <i>generic interface definition</i>, because the
-<code>Read</code> interface takes a type parameter. Generic interfaces are
-explained in the nesC Language Reference Manual (version 1.2 and above).
-Here it is enough to know that generic interfaces have at least one type
-parameter and two components can be wired together only if they provide/use the
-interface with the same types (note that the <code>readDone</code> event passes
-a parameter of the <code><val_t></code> parameter, which is a placeholder
-for the actual data type). This means that since <code>SenseC.nc</code> is
-using the <code>uint16_t</code> variant of the <code>Read</code> interface, it
-can only be wired to a component that provides the
-<code>Read<uint16_t></code> interface and thus <code>SenseC.nc</code>
-expects to read 16 bit unsigned integer sensor data. If you tried to wire
-<code>SenseC.nc</code> to a component that provides, for example, a
-<code>Read<uint8_t></code> interface you would get an error from the
-nesC compiler.
-
-<p>Recall that the wiring is defined in the <code>SenseAppC.nc</code>
-configuration. Let's again take a look, which component <code>SenseC.nc</code>
-is wired to with the <code>Read<uint16_t></code> interface in the
-<code>SenseAppC</code> configuration. The interesting lines are
-
-<pre>
- components new DemoSensorC() as Sensor;
-</pre>
-and
-<pre>
- SenseC.Read -> Sensor;
-</pre>
-
-This means that the <i>generic</i> <code>DemoSensorC</code> component provides
-the <code>Read<uint16_t></code> interface to <code>SenseC.nc</code> (a
-<i>generic component</i> is a component that can be instantiated more than once
-and can take constant and type arguments; each instantiation is a
-different component).
-
-<p> It is important to understand that the <code>SenseC.nc</code> module has no
-way of telling which sensor it is connected to; in fact it cannot even tell
-whether it is getting data from a sensor at all, because it can be wired to any
-component that provides a <code>Read<uint16_t></code> interface. On a
-platform without any built-in sensors (like <i>micaz</i>) and no attached
-sensorboard the <code>DemoSensorC</code> component could simply return constant
-values. The last sentence hints that the <code>DemoSensorC</code> component is
-different for every platform: therefore you will not find
-<code>DemoSensorC.nc</code> in the TinyOS libraries. Instead
-<code>DemoSensorC.nc</code> has to be written for every platform, because, for
-example, on the <i>telosb</i> platform <code>DemoSensorC</code> needs to be
-implemented differently than on the the <i>micaz</i> platform. This is the
-answer to the first question asked in the <a
-href="#introduction">introduction</a>: the <i>platform dependent</i>
-<code>DemoSensorC</code> component defines which sensor the <code>Sense</code>
-or <code>Oscilloscope</code> application is sampling and every platform that
-wants to run sensing applications such as <code>Oscilloscope</code>,
-<code>Sense</code> or <code>RadioSenseToLeds</code> has to provide its own
-version of <code>DemoSensorC</code>. Additionally, sensor boards may come
-with their own version of <code>DemoSensorC</code> (e.g., the
-<code>basicsb</code> sensorboard for the mica-family of motes is defined to
-be that board's light sensor).
-
-<a name="demosensorc"><h2>The DemoSensorC component</h2></a>
-
-<p> Let's take a closer look at the <code>DemoSensorC</code> component. Every
-<code>DemoSensorC</code> component has the following signature:
-
-<pre>
-generic configuration DemoSensorC()
-{
- provides interface Read<uint16_t>;
-}
-</pre>
-
-In its implementation section, however, <code>DemoSensorC</code> may differ
-from platform to platform. For example, on the <i>telosb</i> platform
-<code>DemoSensorC</code> instantiates a component called <code>VoltageC</code>,
-which reads data from the internal voltage sensor. Because the <i>micaz</i>
-doesn't have any built-in sensors, on the <i>micaz</i> platform
-<code>DemoSensorC</code> instantiates a component called
-<code>ConstantSensorC</code>, which returns a constant. Thus
-<code>DemoSensorC</code> is a means of indirecting sensor data acquisition from
-a platform-specific sensor component (like <code>VoltageC</code>) to
-platform-independent applications like <code>Sense</code> or
-<code>Oscilloscope</code>. Usually the configuration of a sensor is done in the
-component that <code>DemoSensorC</code> instantiates.
-
-<p> How can <code>Sense</code> be changed to sample another than the platform's
-default sensor? Usually this requires changing only a single line of code in
-<code>DemoSensorC</code>; for example, if you wanted to replace the
-<code>VoltageC</code> component on <i>telosb</i> by the constant sensor
-component <code>ConstantSensorC</code> you could change (in
-<code>DemoSensorC</code>)
-
-<pre>
-components new VoltageC() as DemoSensor;
-</pre>
-to something like
-<pre>
-components new ConstantSensorC(uint16_t, 0xbeef) as DemoSensor;
-</pre>
-
-Which sensors are available depends on the platform. Sensor components are
-usually located in the respective platform subdirectory
-(<code>tinyos-2.x/tos/platforms</code>), in the respective sensorboard
-subdirectory (<code>tinyos-2.x/tos/sensorboards</code>) or, in case of
-microprocessor-internal sensors, in the respective chips subdirectory
-(<code>tinyos-2.x/tos/chips</code>). <code>ConstantSensorC</code> can be found
-in <code>tinyos-2.x/tos/system</code>.
-
-
-<h2>Running the Sense application</h2>
-
-To compile the <code>Sense</code> application, go to the
-<code>apps/Sense</code> directory and depending on which hardware you have,
-type e.g. <code>make telosb install</code>. If you get errors like the
-following
-
-<pre>
-SenseAppC.nc:50: component DemoSensorC not found
-SenseAppC.nc:50: component `DemoSensorC' is not generic
-SenseAppC.nc:55: no match
-</pre>
-
-your platform has not implemented the <code>DemoSensorC</code> component. For a
-quick solution you can copy <code>DemoSensorC.nc</code> from
-<code>tinyos-2.x/tos/platforms/micaz</code> to your platform directory; then
-you will see constant "sensor" readings (a good starting point on how to create
-sensor components is probably <a href="../tep101.html">TEP 101</a> and <a
-href="../tep114.html">TEP 114</a>).
-
-<p>If you have a mica-family mote and a "basic" (mda100) sensor board, you
-can get a more interesting test by compiling with
-<pre>
-SENSORBOARD=basicsb make <i>platform</i> install
-</pre>
-to run <code>Sense</code> using the mda100's light sensor.
-
-<p> Once you have installed the application the three most significant bits of
-the sensor readings are displayed on the node's LEDs (0 = off, 1 = on). If your
-<code>DemoSensorC</code> represents a sensor whose readings are fluctuating
-greatly you may see the LEDs toggle, otherwise <code>Sense</code> is not so
-impressive. Let's have a look at a more interesting application:
-<code>Oscilloscope</code>.
-
-<a name="oscilloscope"><h1>The Oscilloscope application</h1></a>
-
-<code>Oscilloscope</code> is an application that let's you visualize sensor
-readings on the PC. Every node that has <code>Oscilloscope</code> installed
-periodically samples the default sensor (<a href="#demosensorc">via
-<code>DemoSensorC</code></a>) and broadcasts a message with 10 accumulated
-readings over the radio. A node running the <code>BaseStation</code>
-application will forward these messages to the PC using the serial
-communication. To run <code>Oscilloscope</code> you therefore need at least two
-nodes: one node attached to your PC running the <code>BaseStation</code>
-application (<code>BaseStation</code> can be found at
-<code>tinyos-2.x/apps/BaseStation</code> and was introduced in the <a
-href="lesson4.html">previous lesson</a>) and one or more nodes running the
-<code>Oscilloscope</code> application.
-
-<p> Let's take a look at the <code><a
-href="../../../apps/Oscilloscope/OscilloscopeAppC.nc">OscilloscopeAppC.nc</a></code>
-configuration:
-
-<pre>
-configuration OscilloscopeAppC
-{
-}
-implementation
-{
- components OscilloscopeC, MainC, ActiveMessageC, LedsC,
- new TimerMilliC(), new DemoSensorC() as Sensor,
- new AMSenderC(AM_OSCILLOSCOPE), new AMReceiverC(AM_OSCILLOSCOPE);
-
- OscilloscopeC.Boot -> MainC;
- OscilloscopeC.RadioControl -> ActiveMessageC;
- OscilloscopeC.AMSend -> AMSenderC;
- OscilloscopeC.Receive -> AMReceiverC;
- OscilloscopeC.Timer -> TimerMilliC;
- OscilloscopeC.Read -> Sensor;
- OscilloscopeC.Leds -> LedsC;
-}
-</pre>
-
-The actual implementation of the application is in <code><a
-href="../../../apps/Oscilloscope/OscilloscopeC.nc">OscilloscopeC.nc</a></code>.
-This is the signature of <code>OscilloscopeC.nc</code>:
-
-<pre>
-module OscilloscopeC
-{
- uses {
- interface Boot;
- interface SplitControl as RadioControl;
- interface AMSend;
- interface Receive;
- interface Timer<TMilli>;
- interface Read<uint16_t>;
- interface Leds;
- }
-}
-</pre>
-
-<code>Oscilloscope</code> is a combination of different building blocks
-introduced in previous parts of the tutorial. Like <a
-href="#sense"><code>Sense</code></a> <code>Oscilloscope</code> uses
-<code>DemoSensorC</code> and a timer to periodically sample the default sensor
-of a platform. When it has gathered 10 sensor readings
-<code>OscilloscopeC</code> puts them into a message and broadcasts the message
-via the <code>AMSend</code> interface. <code>OscilloscopeC</code> uses the
-<code>Receive</code> interface for synchronization purposes (see below) and the
-<code>RadioControl</code> interface, which is a actually a
-<code>SplitControl</code> interface, to switch the radio on. If you want to
-know more about mote-mote radio communication read <a
-href="lesson3.html">lesson 3</a>.
-
-<h2>Running the Oscilloscope application</h2>
-
-To install the <code>Oscilloscope</code> application go to
-<code>tinyos-2.x/apps/Oscilloscope</code> and depending on which hardware you
-have, type e.g. <code>make telosb install,1</code>. Note the "<code>,1</code>"
-after the <code>install</code> option, which assigns ID 1 to the node.
-Assigning IDs to nodes is helpful to differentiate them later on in the GUI, so
-make sure you assign different IDs to all nodes on which
-<code>Oscilloscope</code> is installed (e.g. install <code>Oscilloscope</code>
-on a second node with <code>make telosb install,2</code> and so on). A node
-running <code>Oscilloscope</code> will togle its second LED for every message
-it has sent and it will toggle its third LED when it has received an
-<code>Oscilloscope</code> message from another node: incoming messages are used
-for sequence number synchronization to let nodes catch up when they are
-switched on later than the others; they are also used for changing the sample
-rate that defines how often sensor values are read. In case of a problem with
-the radio connection the first LED will toggle.
-
-<p> Install <code>BaseStation</code> on another node and connect it to your PC.
-As usual, on the <code>BaseStation</code> node you should see the second LED
-toggle for every message bridged from radio to serial.
-
-
-<h2>Running the Java GUI</h2>
-
-To visualize the sensor readings on your PC first go to
-<code>tinyos-2.x/apps/Oscilloscope/java</code> and type <code>make</code>. This
-compiles the necessary message classes and the <code>Oscilloscope</code> Java
-GUI. Now start a SerialForwarder and make sure it connects to the node on which
-you have installed the <code>BaseStation</code> application (how this is done
-is explained in the <a href="lesson4.html">previous lesson</a>). In case you
-have problems with the Java compilation or the serial connection work through
-the <a href="lesson4.html">previous lesson</a>.
-
-<p>When you have at least one node running <code>Oscilloscope</code> on it you
-should see SerialForwarder increasing the number of packets it has read from
-the <code>BaseStation</code> (once every 2.5 seconds, at least). Now start the
-GUI by typing <code>./run</code> (in
-<code>tinyos-2.x/apps/Oscilloscope/java</code>). You should see a window
-similar to the one below:
-
-<p>
-<CENTER>
- <IMG SRC="img/oscilloscope.jpg">
-</CENTER>
-</p>
-
-Each node is represented by a graph of different color (you can change the
-color by clicking on it in the mote table). The x-axis is the packet counter
-number and the y-axis is the sensor reading. To change the sample rate, edit
-the number in the "sample rate" input box. When you press enter, a message
-containing the new rate is created and broadcast via the
-<code>BaseStation</code> node to all nodes in the network. You can clear all
-received data on the graphical display by clicking on the "clear data" button.
-
-<p> The <code>Oscilloscope</code> (or <code>Sense</code>) application displays
-the raw data as signalled by the <code>Read.readDone()</code> event. They do
-not perform semantic processing and cannot decide questions like "is a reading
-to be interpreted in degree Celsius or Fahrenheit". This decision is forwarded
-to the user and therefore the GUI let's you adapt the visible portion of the
-y-axis to a plausible range (at the bottom right).
-
-<p>
-<a name="related_docs">
-<h1>Related Documentation</h1>
-</a>
-</p><ul>
-<li> <a href="http://nescc.sourceforge.net/papers/nesc-ref.pdf">nesC reference manual</a>
-</li><li> <a href="../tep101.html">TEP 101: ADC</a>
-</li><li> <a href="../tep114.html">TEP 114: SIDs: Source and Sink Independent Drivers</a>
-</li><li> <a href="http://csl.stanford.edu/%7Epal/pubs/tinyos-programming-1-0.pdf">TinyOS Programming Guide</a>
-</li></ul>
-
-
-<!-- Begin footer -->
-<br>
-<hr>
-<center>
-<p>< <b><a href="lesson4.html">Previous Lesson</a></b> | <b><a
- href="index.html">Top</a></b> | <b><a href="lesson6.html">Next Lesson </a> ></b>
-</center>
-
-</body>
-</html>
+<img src="http://www.tinyos.net/scoop/images/tos-jwall.jpg"></img>
+<br><br>
+The tinyOS tutorials have been moved into a wiki.
+You will be redirected there in 5 seconds ....
+</html>
\ No newline at end of file
projects / tinyos-2.x.git / blobdiff