CSE466 Lab 7: “Radio Communication”

Objectives

The goal of this lab is to write a module for TinyOS and gain some experience with radio communication and sensor networks. In this lab you will learn the following:

Important Warnings

  1. DO NOT power the mote from the AC adapter and batteries at the same time. ALWAYS turn off the mote’s battery power before placing it in the programming board. Only one mote should be plugged into the MIB510 programmer. 
  2. Be careful when placing your soundboard into the MIB510 programming board, make sure that the power switch is in the off position. Note: You may charge the soundboard while on the programming board as long as the power switch is off.

Important Notes

  1. The types of motes you will be using in lab are the "mica2" and "mica2dot". Make sure to compile your program for the correct piece of hardware. (e.g. 'make mica2' NOT 'make mica' For mote programming you will be using the MIB510 serial programming board.
  2. Use the number on your sound board's colored sticker as your group number in hex. Please make sure to type in your group number as a hex number.
  3. The mica2 and mica2dot are built around the ATmega128 microcontroller not the ATmega16. Register names may vary slightly.
  4. Use the default radio fequency and programming board. If you don't specify the radio frequency or programming board it will automatically choose a correct value.
  5. Make sure your MOTECOM variable is properly set when trying to communicate to the devices over serial. The mica2 communicate at 57600 baud while the mica2dots communicates at 19200.

Resources

TinyOS Tutorials
ATmega128 datasheet
nesC 1.1 Language Reference Manual (in course pak)

Yamaha Datasheet (in course pak)
Application notes section for the AVR 8-bit RISC family

Suggested Steps

PART 1:

In this part of the lab, you will be using a java app called Surge.

Surge is a common application of sensor networks used to periodically sample a sensor (e.g., light or temperature) and report readings to a base station. Surge uses ad-hoc multi-hop routing over the wireless network to deliver samples to the base station.

Surge motes organize themselves into a spanning tree rooted at the base station. Each mote maintains the address of its parent and its depth in the tree, advertising its depth in each radio message (either sensor sample or forwarded message) that it transmits. A node selects an initial parent by listening to messages and choosing the node with the smallest depth; to seed the creation of the spanning tree, the base station periodically broadcasts beacon messages with depth 0. Nodes estimate parent link quality; when the link quality falls below some threshold, nodes select a new parent from their neighbor set based on link-quality estimates and depth. Once a second, each mote samples its light sensor and sends the sample to its parent. Parents acknowledge received packets. Surge uses the acknowledgments to provide a reliable transport layer; parent link quality is calculated as the fraction of transmitted messages that are acknowledged. When a node receives a message from another node, it forwards the message to its parent. Sensor samples are collected at the base station where they can be analyzed or visualized

Surge has an accompanying java program for displaying the multi-hop routing topology.

For help on Surge, see:
http://webs.cs.berkeley.edu/tos/tinyos-1.x/doc/multihop/multihop_routing.html

  1. You'll need to work with other lab groups so that you have more than two motes. All groups in the same day's lab will work together.
  2. Choose a group number for Part 1 for all the motes in your big group. NOTE: For the other 2 parts of the assignment you should use your assigned group number to not interfere with other groups.
  3. Program your motes with the Surge application (in /cygdrive/z/apps/surge). Be sure to use a single unique group ID during the installation, but each mote needs a unique node ID. The base must be node 0. Leave the node 0 mote on the programming board to communicate with the serial forwarder. All nodes have the same code but the node with an ID of ‘0’ acts as the base and should be connected to the programming board. Node IDs are programmed by the command "make install.N mica2dot" where N is the node ID.
  4. Deploy your nodes. You may need to place some nodes outside 003 and/or bend the antenna to limit strength to get multi-hopping to work. The default range on the nodes has a large distance.
  5. Start SerialForwarder.
  6. Run surge with the command:
    'java net.tinyos.surge.MainClass GroupId'
    where GroupId is the group number used when compiling the motes’ application.
  7. Once surge has loaded, press "Start Root Beacon" button to get things started.

 

PART 2:

For Part 2 of this lab, you will implement your Yamaha FM sound module in TinyOS. You will need to download these files (HPLSoundBoardM.nc, SoundBoard.h, and YamahaControl.nc) as a starting point. These files provide the lower level sound generation, but you will need to implement the higher level details.

  1. Implement your Yamaha sound generation module to play one song and repeat after a defined period of time you choose.
  2. Add the remaining 15 songs to your TinyOS sound module. You should select the next song to play randomly from the 16 possible songs. You will need to put the songs into program memory to store them all.  You can use the macros and types defined in progspace.h to do this.  To generate random numbers, use the random Linear Feedback Shift Register (LFSR) provided in TinyOS (tos/system/RandomLFSR.nc).
  3. After your mote plays a song, you must send a radio packet stating which song was just played. For these packets, you should use AM Message type #42.

 

While you are working on your sound module, keep the following hints in mind:

Songs:

If you're not filling the fifo completely, end with a rest in the fifo (0x8000), otherwise the chip will repeat the last note over and over. See #5 on page 28 of the Yamaha datasheet.

Then set the Interrupt register 0x34, with the interrupt enable bit set, and the interrupt set point to the appropriate value. See "Interrupt control" on page 18. It says:

When the amount of data remaining in FIFO becomes less than the IRQ point set value, an interrupt signal is generated. 

So, set 0x34 to 0x21 (IRQE = 1 and set point = 1) and the chip will interrupt when it hits the rest at the end of your note data.

Finally, you should set the FM bit ST in 0x32 to start the sound. See page 17. 

 

Interrupt:

When the interrupt occurrs, you should:

1.  Clear the interrupt enable bit in 0x34.

2.  Clear the ST bit in 0x32.

3. Then refill the fifo with the appropriate amount of data and a rest.

4. Then set the Interrupt register 0x34, with the interrupt enable bit set, and the interrupt set point to the appropriate value.

5. Set the FM bit ST in 0x32 to start the sound.

 

PART 3:

In Part 3 of the lab you will create a sensor network that collects light level readings from surrounding nodes and selects a birdsong to play based on the average light level of these collected light readings. You will need to implement nodes that will perform two primary objectives: 1) Take periodic light readings and send the reading over the radio and 2) Receive light readings from the 20 closest neighbors, calculate an average light level, select and play a song to play based on this calculated light level, and then send notification over the radio specifying what song was just played. Unfortunately you do not have enough motes to test/demonstrate your sensor network so you will need to build a test fixture to verify your code works.

 

  1. Implement the first objective of your application by taking light readings every second and transmitting the 8 most significant bits of the ADC value (the ADC functions return all 10-bits of precision) on AM message type #20. The payload/data of your packet should contain the following information byte[0] = sender address, byte[1] = 8-bit light reading, byte[2] = signal strength. One method of determining which mote is closer is to compare signal strengths of the received radio packets. NOTE: The smaller the signal strength the closer the node (see page 33 of the Chipcon CC1000 datasheet). Since we will be simulating multiple nodes from a single node you should send the signal strength as a data field of the packet (instead of using the value measured from the radio) to avoid every node having similar signal strength. IMPORTANT NOTES:

If all messages are coming from the node connected to the PC simulating the other nodes they will appear to all be the same distance away; therefore, the signal strength should be included in the packet.

We are recommending that you use only an 8-bit address to simplify packet parsing by only using one byte in the payload/data section for the sender address. (Even though TinyOS uses 16-bit addresses)

  1. Implement the second objective of your application by obtaining an average of the 20 closest light readings (from 20 different nodes, including your own) being sent over AM message type #20.  Use the result of the calculation to determine which birdsong should be played. You should map light level by: (number_of_songs*average_light_level)/max_light_level. NOTE: You should recalculate and then play another song every 30 seconds.
  2. A simple test fixture system has been provided that will allow you and your partner to design specific test scenarios to help debug your system. The testing system takes as an input a file with specified test packets that it will processes and send out over the radio. Here is the Test Fixture Tar.  Please refer to the “README” file for more information on how the system works. The system was developed by one of the previous 466 TA’s to help students to design and debug sensor networks. Note that there is a LightSensorPacket type that matches the specifications from Part 3 of this assignment. An example test file called “LightSensorTestfile” has been included as an example.

 

Since songs are selected and played every 30 seconds, you will most likely want to utilize delays in your test file to create accurate tests.

Deliverables

For all files turned in, the comments at the top of the file should contain:

  1. Demonstrate Part 1 working to a TA during lab. Turn in a picture of your sensor network taken from the Surge app.
  2. Demonstrate Part 3 to a TA during the first half and hour of the next lab.
  3. Turn in hardcopy of your commented nesC code for both Part 2 and Part 3.
  4. Turn in at least one of your test scripts from Part 3 with an explanation of why the test scripts prove your program works correctly.