TinyOS-1.x Examples

nesdoc documentation

These are introductory examples to become familiar with nesC programming.
  1. Hello - Create a new application in TinyOS: as a pre-requisite, make sure that the Lesson 1 of the TinyOS tutorial is completed. The Hello application provides a minor addition to the Blink application. The objective is to create a new application in TinyOS environment.
  2. Counter - A simple counter; the result is diplayed on LEDs. Create a counter application that displays binary numbers on the LEDs; the counter is reset to 0 after reaching the maximum, 8. The TinyOS components for Counter should not be used; for practice, the code should be written from scratch.
  3. CounterSounder - An enhanced counter application; a sound is produced when the maximum value is reached. For more practice, the counter application is enhanced by producing a sound when the maximum value is reached. The Sounder component available in tos/sensorboards/micasb/ should be used.
  4. SensePhoto - A photo sensor reading is shown on LEDs. As a pre-req, Lesson 2 and Lesson 3 should be completed. The SensePhoto application provides a minor modification to the Sense application. This application displays the lowest three bits of the photo sensor reading. The DemoSensorC component available in tos/sensorboards/micasb/ should be used.
  5. SenseSounder - A photo sensor reading is shown on LEDs; a sound is produced when the lowest 3 bits are 1s. Similar to CounterSounder, this application provides the opportunity for more practice with the DemoSensorC component.
  6. CounterSend - The counter reading is sent on radio frequency, as well as, displayed on LEDs. As a pre-req, Lesson 4 should be completed. Although Lesson 4 teaches two topics: radio communication and component decomposition, the focus for this application is to practice radio communication only. The component decomposition topic is ignored at this stage. For this application, you are not allowed to use the components available in the Counters directory. You must write the code from scratch. As you can suspect, the component will become relatively bigger and there may be a repetition of code in several components. Once you have become comfortable in writing in nesC, the component decomposition will be demonstrated. For RF communication, the GenericComm component at tos/system/ should be used.
  7. CounterReceive - The value received by the radio frequency is displayed on LEDs. Program one mote with CounterReceive and another mote with CounterSend and ensure that the counter value is properly transmitted from one mote to the other one.
  8. SenseSend - The photo sensor reading is transmitter over RF and displayed on LEDs. Similar to CounterSend's focus, the emphasis is on radio communication only; the component decomposition will come later on. Test the application with SenseReceive.
  9. SenseReceive - The value received by the radio frequency is displayed on LEDs. Check SenseSend application.
  10. MultiSend - Several photo sensor readings are transmitted in one packet. Although Lesson 6 is not a pre-req, the Lesson 6 tutorial should be consulted for more details. Moreover, a serial forwarder application can be used to forward the packets to the Internet.

      Files: MultiSend.nc, MultiSendM.nc, zip, MultiMsg.h, and tossim.txt.

    1. The TOSSIM simulation output, tossim.txt is generated by build/pc/main.exe 1 > tossim.txt. The details of the first packet are given below: 
      0: Sending message: ffff, a
	7e 00 0a 88 18 00 00 00 00 88 00 a6 03 2a 02 be 03 f3 00 6b 00 8b 00 21 03 79 00 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

The packet fields are described as follows:
	
	00 7e - destination address (UART)
	0a - handler ID
	88 - group ID
	18 - message length
	00 00 - source address
	00 00 - packet number
	00 88 - reading 0 (0000 0000 1000 1000 - RGY=000, last three bits, as shown by LEDs)
	03 a6 - reading 1 (0000 0011 1010 0110 - RGY=110, last three bits, as shown by LEDs)
	02 2a - reading 2 (0000 0010 0010 1010 - RGY=010, last three bits, as shown by LEDs)
	Similarly, the remaining entries can be confirmed.
      Check the tossim.txt file for complete details.
    2. The packets transmitted can be viewed by the net.tinyos.tools.Listen tool available in tools/java. A sample output is given below: 
      7E 00 0A 88 18 00 00 02 00 86 00 88 00 87 00 88 00 87 00 87 00 87 00 86 00 87 00 86 00 
7E 00 0A 88 18 00 00 03 00 87 00 88 00 87 00 87 00 87 00 86 00 86 00 86 00 87 00 87 00 
7E 00 0A 88 18 00 00 04 00 87 00 87 00 86 00 87 00 87 00 86 00 86 00 86 00 86 00 87 00 
7E 00 0A 88 18 00 00 05 00 87 00 86 00 86 00 86 00 85 00 85 00 85 00 87 00 87 00 86 00
      As expected, the above output is quite similar to the tossim simulator output.
    3. A Java application, similar to Listen, can be easily written to receive the messages. The Message Interface Generator (mig) tool is used to generate Java class(es) corresponding to the structure(s) in the header file; see the Makefile file to generate MultiMsg.java. The MultiSendApp.java is written to receive the messages transmitted by MultiSend. The execution details are given below:
      • create a Makefile file in tools/java/net/tinyos/multisend
      • execute make: MultiMsg.java and MultiMsg.class will be created
      • create a Java application file, say MultiSendApp.java in tools/java/net/tinyos/multisend
      • compile the Java application, javac MultiSendApp.java
      • set MOTECOM environment variable, export MOTECOM=serial@COM1:mica2
      • run the application: java net.tinyos.multisend.MultiSendApp - the current directory is tools/java (use pwd to check present working directory)
      • A sample output is given below: 
        Message  
  [source=0x0]
  [packetNumber=0xec]
  [data=0x8d 0x92 0x8f 0x94 0x96 0x96 0x97 0x94 0x91 0x8e ]

Message  
  [source=0x0]
  [packetNumber=0xed]
  [data=0x8e 0x8d 0x8c 0x8b 0x8b 0x8b 0x8b 0x8b 0x87 0x6c ]
    4. A Web Server, WebServer.java, is implemented to view the MultiSend messages received at the serial port. The MultiMsg.java file, which is created in the above step, is needed to retrieve messages from the seria port. The Web server sends a few recent messages (number of messages is equal to the WINDOW_SIZE,5). A sample output is shown here. The latest messages are obtained by the browser's refresh button. Moreover, several web clients can simultaneously retrieve the messages.
  11. MultiBase and MultiRF - The MultiBase application receives MultiMsg packets over RF and then the received MultiMsg packets are forwarded over UART. The MultiRF application sends MultiMsg packets over RF; three motes were used to transmit RF packets. The WebServer tool, as described above, is used to view the contents of the packets. A sample output shows that packets from three different motes are receieved. Since the sensors were placed in different light conditions, the senor readings are distinct for each of the three nodes.

    Files:

  12. CmdBase and CmdReceive - The CmdBase application receives CmdMsg packets from a Java application, CmdLedApp, and then the received CmdMsg packets are broadcast over RF. The CmdReceive application receives CmdMsg packets through RF and the received information is displayed over LEDs. In other words, this application is the opposite of MultiBase application, where first the information was generated at remote sensors; then, the information was transferred to the base station using RF; finally, the base station forwards the information to a Java Web application or a Web Server. In CmdBase, the information is generated by a Java application; then, through the base station, the information propagates to the remote sensor motes; finally, the information is displayed by the LEDs of the remote motes.

    1. As discussed above, the Message Interface Generator (mig) tool is used to generate the CmdMsg.java file; see the Makefile file to generate MultiMsg.java. The CmdLedApp application creates CmdMsg packets that are sent to the base station. The execution details are given below:
      • create a Makefile file in tools/java/net/tinyos/cmds
      • execute make - CmdMsg.java and CmdMsg.class will be created
      • create a Java application file, say CmdLedApp.java in tools/java/net/tinyos/cmds
      • compile the Java application, javac CmdLedApp.java
      • set MOTECOM environment variable, export MOTECOM=serial@COM1:mica2
      • run the application: java net.tinyos.cmds.CmdLedApp - the current directory should be tools/java.

    2. A CmdServer is a WebServer that provides a Web interface to send CmdMsg packets. The CmdMsg packets are created using the data entered through a Web browser form. In principle, the CmdServer is identical to CmdLedApp, which is described above. The index.html file is sample web page for the user input; a sample response to a user input is given here.
      • run the application: java net.tinyos.cmds.CmdServer - the current directory should be tools/java.
      • The index.html and style.css files must be in tools/java/net/tinyos/cmds directory.

    Files:

  13. QueryBase and QueryNode - The QueryBase application is a base station to send and receive query packets (QueryMsg) from the QueryNode application. The QueryBase application receives queries from an external program, a stand alone Java application or a web server. In this application, the query retrives the photo sensor readings from the sensors provided the reading is greater than a user specified threshold value. In other words, the query can be described as follows: There is some in-network processing because the query condition is checked locally at the sensor nodes; the packets are transmitted only if the condition is true; otherwise, nothing is transmitted from the remote sensor node.

    Files:

  14. QueryAllBase and QueryAllNode - These applications are similar to QueryBase and QueryNode but sensor readings include: photo, temperature, magX, magY, accelX, and accelY. Moreover, the results are shown in a tabular format.

    Files:

Research | Home | CS | Acadia
For comments or suggestons, please send an email to Sajid (dot) Hussain (at) acadiau.ca