From: janhauer Date: Fri, 20 Apr 2007 12:23:35 +0000 (+0000) Subject: Fixed typos, facilitated explanations, made some adaptations (SineSensorC is now... X-Git-Tag: tinyos/2.0.1~17 X-Git-Url: https://oss.titaniummirror.com/gitweb/?p=tinyos-2.x.git;a=commitdiff_plain;h=66e00c1a642638b16e359383b1115ea2db01beb9 Fixed typos, facilitated explanations, made some adaptations (SineSensorC is now mentioned). --- 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.

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).

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.

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. - -

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:

@@ -425,20 +423,19 @@ similar to the one below:

-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 +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 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).