X-Git-Url: https://oss.titaniummirror.com/gitweb/?a=blobdiff_plain;f=doc%2Fhtml%2Ftutorial%2Flesson5.html;h=d6ac345e143bcb59f640c81a2412e51819075d4c;hb=66e00c1a642638b16e359383b1115ea2db01beb9;hp=0de25831926033c8c87aef6218aac2e518dfa081;hpb=88310b5b8bef79664226b49fdad032d5313adb93;p=tinyos-2.x.git
diff --git a/doc/html/tutorial/lesson5.html b/doc/html/tutorial/lesson5.html
index 0de25831..d6ac345e 100644
--- a/doc/html/tutorial/lesson5.html
+++ b/doc/html/tutorial/lesson5.html
@@ -28,24 +28,22 @@ sensing was syntactically connected with analog-to-digital converters (ADCs):
TinyOS 1.x applications such as Oscilloscope
or Sense
used the ADC
and ADCControl
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 ADCError
-have to be introduced, but it became clear that equating a sensor with an ADC was
-not always the appropriate thing to do.
+the serial interface, not only did additional interfaces like
+ADCError
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, Sense
is meant to run on any TinyOS platform. How can
-Sense
know the configuration details (e.g. input channel, 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, Sense
is meant to run on any TinyOS platform. How can
+Sense
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,
-i.e. (the light sensor on the tmote and the one on the eyes platform.
-Unless Sense
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
-Sense
application can collect sensor data even though it is
-agnostic to the platform it is running on.
+configuration details of sensors will be different from platform to platform.
+Unless Sense
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 Sense
application can
+collect sensor data even though it is agnostic to the platform it is running
+on.
In TinyOS 2.0 platform independent sensing applications such as
Oscilloscope
, Sense
or RadioSenseToLeds
@@ -239,10 +237,10 @@ generic configuration DemoSensorC()
In its implementation section, however, DemoSensorC
may differ
from platform to platform. For example, on the telosb platform
DemoSensorC
instantiates a component called VoltageC
,
-which reads data from the internal voltage sensor. Because the micaz
-doesn't have any built-in sensors, on the micaz platform
-DemoSensorC
instantiates a component called
-ConstantSensorC
, which returns a constant. Thus
+which reads data from the MCU-internal voltage sensor. Because the micaz
+doesn't have any built-in sensors its DemoSensorC
uses system
+library component like ConstantSensorC
or
+SineSensorC
, which return "fake" sensor data. Thus
DemoSensorC
is a means of indirecting sensor data acquisition from
a platform-specific sensor component (like VoltageC
) to
platform-independent applications like Sense
or
@@ -264,13 +262,13 @@ to something like
components new ConstantSensorC(uint16_t, 0xbeef) as DemoSensor;
-Which sensors are available depends on the platform. Sensor components are
+What sensors are available depends on the platform. Sensor components are
usually located in the respective platform subdirectory
(tinyos-2.x/tos/platforms
), in the respective sensorboard
subdirectory (tinyos-2.x/tos/sensorboards
) or, in case of
microprocessor-internal sensors, in the respective chips subdirectory
-(tinyos-2.x/tos/chips
). ConstantSensorC
can be found
-in tinyos-2.x/tos/system
.
+(tinyos-2.x/tos/chips
). ConstantSensorC
and
+SineSensorC
can be found in tinyos-2.x/tos/system
.
DemoSensorC
component. For a
-quick solution you can copy DemoSensorC.nc
from
-tinyos-2.x/tos/platforms/micaz
to your platform directory; then
-you will see constant "sensor" readings (a good starting point on how to create
-sensor components is probably TEP 101 and TEP 114).
+your platform has not yet implemented the DemoSensorC
component.
+For a quick solution you can copy DemoSensorC.nc
from
+tinyos-2.x/tos/platforms/micaz
to your platform directory (a good
+starting point on how to create sensor components is probably TEP 101 and TEP 114).
If you have a mica-family mote and a "basic" (mda100) sensor board, you
can get a more interesting test by compiling with
@@ -300,11 +297,15 @@ SENSORBOARD=basicsb make platform install
to run Sense
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
-DemoSensorC
represents a sensor whose readings are fluctuating
-greatly you may see the LEDs toggle, otherwise Sense
does not seem to
-be very impressive. Let's take a look at a more interesting application:
+
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 Sense
cannot know the
+precision (value range) of the returned sensor readings and, for example, the
+three most significant bits in a uint16_t
sensor reading sampled
+through a 12-bit ADC would be meaningless (unless the value was left-shifted).
+If your DemoSensorC
represents a sensor whose readings are
+fluctuating you may see the LEDs toggle, otherwise Sense
is not
+very impressive. Let's take a look at a more interesting application:
Oscilloscope
.
The Oscilloscope application
@@ -367,16 +368,15 @@ module OscilloscopeC
Oscilloscope
is a combination of different building blocks
introduced in previous parts of the tutorial. Like Sense
, Oscilloscope
uses
+ href="#sense">Sense
, Oscilloscope
uses
DemoSensorC
and a timer to periodically sample the default sensor
of a platform. When it has gathered 10 sensor readings
OscilloscopeC
puts them into a message and broadcasts that message
via the AMSend
interface. OscilloscopeC
uses the
Receive
interface for synchronization purposes (see below) and the
-RadioControl
interface, which is a actually a
SplitControl
interface, to switch the radio on. If you want to
know more about mote-mote radio communication read lesson 3.
+ href="lesson3.html">lesson 3.
Oscilloscope
is installed (e.g. install Oscilloscope
on a second node with make telosb install,2
and so on). A node
-running Oscilloscope
will togle its second LED for every message
+running Oscilloscope
will toggle its second LED for every message
it has sent and it will toggle its third LED when it has received an
Oscilloscope
message from another node: incoming messages are used
for sequence number synchronization to let nodes catch up when they are
@@ -405,19 +405,17 @@ toggle for every message bridged from radio to serial.
To visualize the sensor readings on your PC first go to
tinyos-2.x/apps/Oscilloscope/java
and type make
. This
-compiles the necessary message classes and the Oscilloscope
Java
-GUI. Now start a SerialForwarder and make sure it connects to the node on which
-you have installed the BaseStation
application (how this is done
-is explained in the previous lesson). In case you
-have problems with the Java compilation or the serial connection work through
-the previous lesson.
-
-When you have at least one node running Oscilloscope
on it you
-should see SerialForwarder increasing the number of packets it has read from
-the BaseStation
(once every 2.5 seconds, at least). Now start the
-GUI by typing ./run
(in
-tinyos-2.x/apps/Oscilloscope/java
). You should see a window
-similar to the one below:
+creates/compiles the necessary message classes and the
+Oscilloscope
Java GUI. Now start a SerialForwarder and make sure
+it connects to the node on which you have installed the
+BaseStation
application (how this is done is explained in the previous lesson). In case you have problems with the
+Java compilation or the serial connection work through the previous lesson.
+
+
Once you have a SerialForwarder running you can start the GUI by typing
+./run
(in tinyos-2.x/apps/Oscilloscope/java
). You
+should see a window similar to the one below:
BaseStation
node to all nodes in the network. You can clear all
received data on the graphical display by clicking on the "clear data" button.
The Oscilloscope
(or Sense
) application displays
-the raw data as signalled by the Read.readDone()
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).
+the raw data as signalled by the Read.readDone()
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).