Starting this assignment we will start looking into the popular area of wireless sensor networks. Sensor networks is an traditional area in engineering, which has gained recent focus with the conjunction of wireless technology miniaturization and low power electronics. The University of California at Berkeley, developed one such hardware system, which has become the de-facto standard for sensor networks. Moteiv is a Berkeley spin off company which designs, manufactures and sells these sensor motes. We will make use of these devices for our experiments in the lab.
Many of you may find this lab very exciting especially since it changes many notions of computing. It has a totally different custom hardware which have been designed for a specific purpose. There is also a rich set of software, which is a great work in the area of systems.
For those who are interested in more reading can refer to the TinyOS and Moteiv websites for more information. Some of which you will learn through this simple yet exciting exercise.
For this experiment we will make use of the "Tmote Sky" model of motes from the Moteiv corporation. These motes are impoverished as compared to the computational hardware which we see. For example, this specific mote we use has a processor which runs at 8Mhz, and has no more than 10k of RAM. However, this rather small hardware has some exciting applications given that is can be powered with just two AA batteries. They also have a radio which can communicate over reasonable distances, and have the option of attaching an antenna for higher distances. Adding to the computational and communication hardware they also have some built in "sensors". These sensors are just ADCs (analog to digital converters). They can be used any where from environmental monitoring to something more electronic such as voltages at some locations. The choice of sensor used is not relevant to the basic mote development and is considered orthogonal to our study. A similar paradigm to sensors on the motes is the availability of various peripheral devices for desktop computers (PCI cards).
As mentioned the motes we use come with a few different sensors, viz. Temperature (internal and external), Voltage (internal), Humidity and Light (total ambient and visible).
In this lab you will learn to compile and install a new application on a Tmote Sky mote. You will also see how these motes will communicate with the PC with the help of a serial/USB port (in this lab there will be no use of the radio communication capability, which will be covered in a later lab). An application is provided in the TinyOS distribution which can read information from available sensors and pass it to any application which connects to the TCP port on which this application is listening. Similarly, they also provide another application which can take these readings and plot them on the screen (similar to an Oscilloscope, which is what the application is called).
As the first step of your assignment, you will have to build and upload your application to the tmote. The paradigm of application for motes is quite different from what you would expect on day to day to computers. The main difference is that, there is no distinction between the operating system and the applications, and there is in fact only one thread of control. Hence, any application which is being built has to be so written that it is a complete standalone software system (including the Operating Systems). For example, if you were to write an application which sends a packet to the USB port and on the radio, you will unable to develop two stand alone applications, one which writes to the USB and one which sends the information out on the radio. You would have to write both applications in one main program. The immediate concern would be that of complexity. For this very reason the TinyOS developers developed a C extension known as the nesC programming language, which eases this. In this application programming language, you would "wire" a few standalone applications into one. For example, an application which would sense and send information on the serial port, would "wire" the sense application and the send application and compile them into one binary with the entire operating system. Interested readers can obtain many resources from the TinyOS website on this.
In this assignment your main goal will not be to develop a new application but to only use an example application and understand the eco system. Since this application requires the use of a java based GUI, you have to make use of the X windowing start. So when booting up the machine, select the *FIRST* UBUNTU option. (Ubuntu, kernel 2.6.17-10-generic).
First, you need to setup the directories which you will need, so run the following script in your home directory:
For this, you will use what is known as the "Oscilloscope" example application. This application is available in the directory "$TOSROOT/apps/Oscilloscope" . First CD into this directory. Next, connect a mote to the USB port of your machine. This will immediately power on the device (please don't be concerned if any lights blink or don't, perhaps some one already loaded an application and did not erase it). Now, use the following command.
This will immediately produce an output which will look like this.
Reference Device Description ---------- ---------------- --------------------------------------------- M4A0P2PZ /dev/ttyUSB0 Moteiv tmote sky
It could say USB1 instead of USB0. If so, change everything to USB1 below. The above line means that there is a Moteiv Tmote Sky mote which has been attached to the USB at /dev/ttyUSB0. If you do not see this, please try to remove and re-attach the mote to correct any loose connections. If the problem persists, please contact the TA and ask for assistance.
Hoping that things went fine until now. Let us compile and install the application on the mote which is attached to the USB port now. You will need to use the following command in the directory with the Oscilloscope code.
$ make telosb install.1 bsl,/dev/ttyUSB0
There may be an error produced not allowing you to write to the USB port. If so, you will need to run the following command to provide you with permissions, and then rerun the make command above. If there are still errors, please email me or call the office: 217-244-5791.
$ sudo chmod 666 /dev/ttyUSB0
The above command will compile the program in the current directory and install it on the mote attached to /dev/ttyUSB0 using the "bsl" command tool. The number "1" in the command is the address the mote will use in all it's communication and can be thought of as analogous to an IP address. Once you invoke this command you will see a host of lights blinking on the mote and will be able to guess that there is a lot of communication going on.
Once the command is invoked the application is first compiled to the architecture mentioned (using a cross compiler). Next, the "loader" program is invoked (which in our case is "bsl"), and the compiled binary is loaded to the device mentioned (/dev/ttyUSB0 in the above example). Once the loading completes, the mote is reset automatically and the application loaded starts running on the mote.
As previously mentioned, the application is configured to sense some status (From the available ADCs on the board), and relay it to the machine via the PCs serial port (USB). Right now, this is happening, however the data is not being read by any application, and is being discarded by the operating system.
Now, let us start a JAVA application which can read this information. This application is called the "Listen" application. First change to the $TOSROOT/tools/java directory. Now, you will be required to set an environment variable which the application will use to determine the kind of mote being used for accurate parsing.
$ export MOTECOM=serial@COM1:tmote
You can view its value with the following command
$ echo $MOTECOM # Will return serial@COM1:tmote
This environment variable is used to determine which communication port and mote type to use to read the values. In Linux, there is no such thing as COM1, however the javax.comm package exports /dev/ttyUSB0 as com1, /dev/ttyUSB1 as com2, etc.
~/$TOSROOT/tools/java>$ java net.tinyos.tools.Listen
You will immediately observe an output such as follows.
~/$TOSROOT/tools/java>$ java net.tinyos.tools.Listen serial@COM1:57600: resynchronising 1A 00 00 00 00 00 7E 00 0A 7D 01 00 88 3B 01 00 AD 00 C3 00 A2 00 B2 00 C3 00 A1 00 AF 00 C4 00 A4 00 B0 00 1A 00 00 00 00 00 7E 00 0A 7D 01 00 92 3B 01 00 C8 00 AB 00 B2 00 BC 00 AF 00 B7 00 B6 00 AF 00 BC 00 B3 00 1A 00 00 00 00 00 7E 00 0A 7D 01 00 9C 3B 01 00 AB 00 BF 00 AB 00 B1 00 C0 00 A6 00 B2 00 C4 00 A4 00 B2 00
This is the raw packet which is being passed in by the mote to the serial port. This application by itself is of little use unless interested in reading raw packet values. So let us start the application which can read these packets from USB and pass it on to any application via a TCP port. This application is called the SerialForwarder and can be invoked via the following command.
~/$TOSROOT/tools/java>$ java net.tinyos.sf.SerialForwarder -comm serial@COM1:tmote
This will bring up a window which will look like this
As you can see from the screenshot, the application is listening on TCP port 9001 and will send the information it is reads as packets to any application which connects this machine on port 9001. Take a screenshot of this window using the "ksnapshot" application. After which you must close the window (application) to free the COM1 port.
Now, let us try some application which can actually make sense out of this information. For starters we will use an application which can plot this information on the screen. Again this application is available from the TinyOS distribution.
Remember that based on the information being sensed and passed you can write many interesting applications. Starting from toy tools such as burglar alarms (how would you do this?) to complicated environmental monitoring applications.
The tool we will use to graph the information is known as the Oscilloscope application. This is available with the following command
~/$TOSROOT/tools/java>$ java net.tinyos.oscope.oscilloscope
This will bring up a screen which looks like as below, after properly adjusting the axes. To adjust the axes please zoom out of X and Y using the respective buttons on the JAVA GUI, until you find a green spec, and zoom in with it at the center to get more detailed information. You would also want to make use of the scroll buttons which are marked with the directional arrow icons.
The above application used an arbitrary sensor available on the mote, usually the "demosensor". However, there are other sensors available on the tmote. These sensors can be used all at once, or in any combination. Let us now see if we change the sensor being used.
Previously, it was also mentioned that we can wire in any component as we would like using the nesC programming structures. In fact if you open the Oscilloscope.nc file, you will get a feeling of what we mean. Many components, such as a timer, a demosensor etc. are linked in, and this application as such looks minimal. However the main functionality is usually enclosed in another file, which typically ends with a *M.nc. You can open the OscilloscopeM.nc file and find the implementation where they talk to the serial port. You can also notice the parts of the application which are available from external components such as the demosensor etc.
Your task would now be to change the sensor we are using from demosensor and use a specific sensor. In this example, we will use the light sensor, since this is the environmental condition which changes often.
The light sensor for the tmote is already available from an application known as Hamamatsu (the name comes from the manufacturer). Hence, we need to wire in the application component HamamatsuC in place of DemoSensorC. This is done by just changing the one line which reads as DemoSensorC as Sensor in the Oscilloscope.nc file to HamamatsuC as Sensor. Once you change this line, run the following command, which will output something as shown.
$TOSROOT/apps/Oscilloscope$ make telosb mkdir -p build/telosb compiling Oscilloscope to a telosb binary ncc -o build/telosb/main.exe -O -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -target=telosb -fnesc-cfile=build/telosb/app.c -board= -I%T/lib/Deluge -Wl,--section-start=.text=0x4800,--defsym=_reset_vector__=0x4000 -DIDENT_PROGRAM_NAME=\"Oscilloscope\" -DIDENT_USER_ID=\"cck\" -DIDENT_HOSTNAME=\"nhv-cck\" -DIDENT_USER_HASH=0xedcde517L -DIDENT_UNIX_TIME=0x439e09b2L -DIDENT_UID_HASH=0x8f565921L -mdisable-hwmul -I/home/cck/tmote/tinyos-1.x/tos/lib/CC2420Radio Oscilloscope.nc -lm Oscilloscope.nc:58: ambiguous match make: *** [exe0] Error 1
Once you open the file you will notice that line 58 (could be a different line on your
machine, please look at the error output) being referred to, has this
piece of code "OscilloscopeM.ADC -> Sensor;". This error is because the
component HamamatsuC.nc has two sub-components in it (i.e.,. the total ambient
radiation and visible radiation). Hence, we need to mention which ADC to refer
to. You can find the Hamamatsu.C file in the directory
$TOSROOT/tos/platform/telos/HamamatsuC.nc. If you open it, you will be
able to figure out that the two different sensors are called PAR and
TSR. We will use PAR for now. Hence, change line 58 from
OscilloscopeM.ADC -> Sensor;
OscilloscopeM.ADC -> Sensor.PAR;. You may test the compile by using the same command as above, this time though you should not see any errors.
Once you have successfully compiled the application to get information from the light sensor, please repeat the procedure of uploading the application to the tmote and use the Oscilloscope. Execute the following command, as you previously did for uploading the unmodified application.
$ make telosb install.1 bsl,/dev/ttyUSB0
One uploaded, you will find that you are able to change the external light and see the value change accordingly on the Oscilloscope screen. Take a screenshot of this showing enough variation on the oscilloscope.
After completing the experiment, please logout of X windows and logout from command prompt to allow other groups to work after you are gone. Leaving the mahcines logged in, is a security risk.
Please turn in screen shots of the application windows above (serialForwarder and the Oscilloscope), as jpg images (please be considerate of my mail box size). You can use the "ksnapshot" application to get the screen shots. The second screen shot where you show the light sensor in work should contain major fluctuations in the readings which you can cause by placing a paper on the mote to cut out any light or by exposing it to bright light (please don't be rough to the motes, they are expensive and fragile devices). You can save these files by using the network. Either ftp them to your EWS account, or send yourself the files through an email. If you have problems accessing the internet, make sure that eth1 is DOWN. Run 'ifconfig' and if you see 'eth1', run 'sudo ifdown eth1'. Now, check the internet again. If it still does not work, see if you can ping any of the other laptops. If you can, copy your stuff to one of them as a backup. If none of this works, contact the TA.
What do you think about the development model?
Can you come up with an idea to develop a burglar alarm using the light sensor on two motes? If so, explain it in no more than 5 lines.
In the first part on sensor networks you looked at how you can use the sensors
already available on the Motes to sense the environment, and display it on the
screen. It was also discussed in class that sensors by themselves are not a new
concept, except that miniaturization, low power, programmability, etc., along
with wireless capabilities synergize to make them a power tool. Today, you will
make use of these motes in a scenario where they will communicate over wireless
and send information to a sink node. This way, sensors could be used to sense
locations which may be unreachable or unwieldy to sense by normal wired
In this assignment, we will program two motes to sense data and send all their information to a sink mote. Hence, you will need a total of 3 motes. First, let us program the motes which will send information as radio packets to their surrounding motes. You will make use of a slightly modified version of the Oscilloscope application, which senses and sends packets via the radio interface, instead of sending them over USB. The sink mote will use an application which can read decode these packets off the air, and send them over USB for the java Oscilloscope application to read it.To upload the "OscilloscopeRF" application, first change to the directory "$TOSROOT/apps/OscilloscopeRF". Similar to the commands used to upload an application in part I, use the following command.
# Upload the OscilloscopeRF application to the mote connected on # "/dev/ttyUSB0". Check that the mote is visible to the OS by # running the "motelist" command. $TOSROOT/apps/OscilloscopeRF> make telosb install.1 bsl,/dev/ttyUSB0 # In the above command, "1" is the address given to the mote
As explained previously, the number which follows the word "install" is analogous to an IP address, and is a 16 bit address given to the motes. We will number the motes, starting from the two source motes, as 1 and 2, to end with 3 for the sink mote (the mote which will read the packets and send them to USB port of the computer to which it is attached).
Disconnect the first mote from the USB port gently, and connect the second mote to the USB port. Recheck, by running "motelist", that the mote is visible to the operating system. We will upload the same OscilloscopeRF application to the mote, but assign it a different address. To do so, execute the following command.
# Mote is given the address '2' $TOSROOT/apps/OscilloscopeRF> make telosb install.2 bsl,/dev/ttyUSB0
Again, disconnect the mote gently from the USB port, and connect another mote. Recheck to see that the mote is visible to the operating system. Only this time, the mote will be configured as a sink mote. That is, this mote will only read any data packets which are sent over the wireless medium, and send them as a packet to the USB port. This information can then be read by any application, which may process or display the data.
The application which does this is located in the directory named, "$TOSROOT/apps/TOSBase". First, change to this directory, and upload the application to the mote as done previously, with a unique address. You may may use the following command.
# Mote is given the address number 3. $TOSROOT/apps/TOSBase> make telosb install.3 bsl,/dev/ttyUSB0
Do not detach this mote from the computer. Since this mote will send decoded wireless packets over the USB, it should stay connected to the PC. Let us now start the application which can read data from the USB port and display it on the screen. We will once again use the Oscilloscope JAVA application, used in the previous assignment.
# Start the Oscilloscope application $ java net.tinyos.oscope.oscilloscope
Currently, you will not notice anything on the screen since the source motes are not powered on, and hence no data is being sent to the sink. To start sensing, power on the other two motes previously configured to send data over the wireless medium. This is done by gently connecting the other two motes, to any of the laptops next to node_a. If you wish to make use of batteries to power the motes, you may do so now.
Following this, adjust the oscilloscope application's view so that you can see both sets of data being reported. Take a screen-shot of this behavior, showing some data from both the source motes, in one view, using "ksnapshot".
Please Turn In Screen Shots Of The Oscilloscope Application, With Both Sets Of Data Being Visible. You Can Use The "Ksnapshot" Application To Get The Screen Shots. You can save these files by using the network. Either ftp them to your EWS account, or send yourself the files through an email.
1. Are there any advantages of using the wireless medium in comparison to what
you did in the last assignment?
2. Can you come up with some potential advantages of this simple source and sink model when motes may have to communicate over multiple hops? Please comment on how you may use the "in-network" data aggregation idea.