CSE 466 Lab 7:
Project Preparation & Miscellanea

Introduction

This week, you'll work on several small things that will be useful for the final project. The focus of this lab is less on the deliverables and more on making sure you're ready to start working on the project.

WARNING: NEVER attach or detach the iMote2 from the debug board or the sensor board when power is attached. ALWAYS make sure you've unplugged ALL of the USB cables when connecting or disconnecting the sensor board, debug board, or SuperBird.

Objectives

In this lab, you will:

Suggested Reading and Resources

Part 1: RSSI and Location

Download this version of the radio driver, which should provide RSSI information. Refer to the TOS_Msg struct in tosmac.h and note that it has a 'strength' field.

For this lab, you should experiment with the RSSI values and determine how they could be used to estimate the relative distance between two iMote2s in the final project. Here are a few suggestions:

  1. Read the section of the CC2420 datasheet on RSSI.
  2. Write an application that sends packets (your packets should have a unique identifier so you can identify them, but otherwise the content is not important) at some fixed rate. To avoid using excessive bandwidth, limit yourself to about 10 packets per second.
  3. Write another application that receives the packets, and display the RSSI value for each packet received.
  4. Experiment with moving the sender and receiver around and watching the effect on the RSSI. You can use the SuperBird with a battery and disconnect your iMote2 from the computer; this will allow you to separate the transmitter and receiver by greater distances.
  5. Try using different channels. Does a particular channel show a better correlation between distance and RSSI?
  6. Try altering the transmit power. (There is an ioctl() in tosmac.h to do this. Note that it we haven't tested it yet; it may or may not work.) Does lowering the transmit power provide more correlation between distance and RSSI?

Part 2: Threads with pthreads

In the previous lab, you created a synthesizer with a single thread. If you want to adjust the parameters or otherwise control your synthesizer, you must do this in the short amount of time between writing buffers of data to the audio device. Your program spends the rest of its time blocked while the sound device is not ready for new data. If you spend too much time preparing the next buffer of data, the audio will skip because the audio device will run out of samples to play before the next buffer is ready.

For the final project, the control section of your program will be much more complex and will not be able to complete in the small amount of time between buffers. You will need to implement separate control and synthesis threads that will run in parallel. The synthesis thread will run in a loop waiting for data from the control thread.

In this part of the lab, you will learn how to program with the pthreads API. Then, you will modify your synthesizer application and separate your control and synthesis threads.

  1. First, implement a simple application with a few threads to introduce yourself to the pthreads API. This tutorial provides an example of a simple pthreads program. Note that when you compile a program that uses the pthreads API, you should use the -pthread compiler flag.
  2. Your program can be as simple as threads that loop several times, print out their IDs, and sleep for a few seconds. When you run it, you should see output from all of your threads to indicate that they are running concurrently.
  3. Separate the control and synthesis threads in your synthesizer application. Your threads can communicate through shared global variables, but make sure you use mutexes when accessing shared data structures to avoid synchronization errors.
  4. When your synthesis thread is idle (i.e. not producing sound and waiting for input from the control thread) it should wait on a condition variable. When your control thread wants to start playing sound, it should signal the synthesis thread to wake up.