From: janhauer 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, In TinyOS 2.0 platform independent sensing applications such as
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 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
- 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 When you have at least one node running Once you have a SerialForwarder running you can start the GUI by typing
+
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.
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.
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
.
Running the Sense application
@@ -286,12 +284,11 @@ SenseAppC.nc:50: component `DemoSensorC' is not generic
SenseAppC.nc:55: no match
-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; 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).
Sense
using the mda100's light sensor.
-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:
+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.
Running the Oscilloscope application
@@ -388,7 +388,7 @@ 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
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.
-
-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.
+
+./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).