[Tinyos-2-commits] CVS: tinyos-2.x/doc/html/tutorial lesson5.html, 1.4, 1.5

Fri Apr 20 05:23:38 PDT 2007

Update of /cvsroot/tinyos/tinyos-2.x/doc/html/tutorial
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv31408

Modified Files:
	lesson5.html 
Log Message:
Fixed typos, facilitated explanations, made some adaptations (SineSensorC is now mentioned).

Index: lesson5.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tutorial/lesson5.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** lesson5.html	12 Dec 2006 18:22:53 -0000	1.4
--- lesson5.html	20 Apr 2007 12:23:35 -0000	1.5
***************
*** 29,50 ****
  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 did additional interfaces like <code>ADCError</code>
! have to be introduced, but it became clear that equating a sensor with an ADC was
! not always the appropriate thing to do.

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 sensors will be different from platform to platform, 
! i.e. (the light sensor on the tmote and the one on the eyes platform. 
! Unless <code>Sense</code> knows about all sensors on all platforms it will be unable to
! 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
--- 29,48 ----
  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 did additional interfaces like
! <code>ADCError</code> have to be introduced, but it became clear that equating
! a sensor with an ADC was not always the appropriate thing to do.

Usually sensing involves two tasks: configuring a sensor (and/or the
! hardware module it is attached to, for example the ADC or SPI bus) 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 (like ADC input channel, the
 required reference voltage, etc.) of an attached sensor? It can't, because the
! configuration details of sensors will be different from platform to platform.
! Unless <code>Sense</code> knows about all sensors on all platforms it will be
! unable to perform the configuration task. 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
***************
*** 240,247 ****
  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
--- 238,245 ----
  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 MCU-internal voltage sensor. Because the <i>micaz</i>
! doesn't have any built-in sensors its <code>DemoSensorC</code> uses system
! library component like <code>ConstantSensorC</code> or
! <code>SineSensorC</code>, which return "fake" sensor data. Thus
  <code>DemoSensorC</code> is a means of indirecting sensor data acquisition from
  a platform-specific sensor component (like <code>VoltageC</code>) to
***************
*** 265,275 ****
  </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>.

--- 263,273 ----
  </pre>

! What 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> and
! <code>SineSensorC</code> can be found in <code>tinyos-2.x/tos/system</code>.

***************
*** 287,296 ****
  </pre>

! your platform has not yet 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
--- 285,293 ----
  </pre>

! your platform has not yet 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 (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>).

If you have a mica-family mote and a "basic" (mda100) sensor board, you
***************
*** 301,309 ****
 to run <code>Sense</code> using the mda100's light sensor.

! 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> does not seem to
! be very impressive. Let's take a look at a more interesting application:
 <code>Oscilloscope</code>.

--- 298,310 ----
  to run <code>Sense</code> using the mda100's light sensor.

! Once you have installed the application the three least significant bits of
! the sensor readings are displayed on the node's LEDs (0 = off, 1 = on). It is
! the least significant bits, because <code>Sense</code> cannot know the
! precision (value range) of the returned sensor readings and, for example, the
! three most significant bits in a <code>uint16_t</code> sensor reading sampled
! through a 12-bit ADC would be meaningless (unless the value was left-shifted).
! If your <code>DemoSensorC</code> represents a sensor whose readings are
! fluctuating you may see the LEDs toggle, otherwise <code>Sense</code> is not
! very impressive. Let's take a look at a more interesting application:
 <code>Oscilloscope</code>.

***************
*** 368,372 ****
  <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
--- 369,373 ----
  <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
***************
*** 374,381 ****
  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>
--- 375,381 ----
  via the <code>AMSend</code> interface.  <code>OscilloscopeC</code> uses the
  <code>Receive</code> interface for synchronization purposes (see below) and the
  <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>
***************
*** 389,393 ****
  <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
--- 389,393 ----
  <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 toggle 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
***************
*** 406,422 ****
  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>. 

! 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>
--- 406,420 ----
  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
! creates/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>. 

! Once you have a SerialForwarder running you can 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>
***************
*** 426,433 ****
  </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
--- 424,431 ----
  </p>

! Each node is represented by a line 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
***************
*** 435,443 ****

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 degrees 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>
--- 433,440 ----

The <code>Oscilloscope</code> (or <code>Sense</code>) application displays
! the raw data as signalled by the <code>Read.readDone()</code> event. How the
! values are to be interpreted is out of scope of the application, but the GUI
! let's you adapt the visible portion of the y-axis to a plausible range (at the
! bottom right).

  <p>