Week: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | photos
Monday
Carla picked me up at my apartment and we went over to the Computer Science department at the Levine Science Research Center (LSRC). There I met Rebecca, who just finished her PhD and wrote the base simulator as her thesis project. They explained the project and gave me some research papers to read on wireless sensor networks (WSNs).
Carla showed me around the building and local area - the cafeteria, coffee shop, library, and the student union (Bryan Center). Since I was completely exhausted after my red-eye flight from Oakland I was sent home to get some sleep.
Tuesday
I read the original wireless sensor network project proposal that was submitted to and approved by the National Science Foundation. It describes the long term goals and plans for implementing the sensor network and includes information on the environmental science aspects of the project. I started reading Simulating the power consumption of large-scale sensor network applications which is a paper on powerTOSSIM, a wireless sensor network simulator that models power consumption.
Wednesday
In the morning there was a team meeting and I was introduced to other professors and students who are working on the project. Afterward I met with Carla and Rebecca and they answered some questions I had about simulators and measuring power consumption. They warned me that the words power and energy are often used interchangeably, but they are actually different concepts: Power (Watts) = Current (amps) x Voltage (volts). and Energy (joules) = Power (watts) x Time (seconds). Obviously, I'm not an Electrical Engineering or Physics major.
Carla gave me some slides from her course, Experimental Methods in Computer Systems, that describe simulator-related concepts like workload and metrics and explain different types of simulation techniques (execution-driven vs. event-driven, etc.) and I was assigned two other papers to read: ATEMU: a fine-grained sensor network simulator and Avrora: scalable sensor network simulation with precise timing.
Carla and I went out to lunch at the LSRC cafeteria where I got some spinach pizza and we talked about Mills, and the house she is planning to build on an island in Washington, among other things. In the afternoon I continued reading.
Monday
I finished reading the simulator papers and wrote summaries of some of them.
Tuesday
I searched through various WSN papers looking for methods of simulating the CPU specifically. I looked again at Avrora, ATEMU, TOSSIM, and powerTOSSIM, and also SENS, EmSim, Emstar, and SensorSim. A lot of them simulate the functions of the network components, but do not model the CPU. The simulators that do model the CPU often do so very abstractly. The most common way is to keep track of the assembly code instructions that are executed block by block. This can be done because mote manufacturers provide data sheets that list the number of clock cycles for each instruction.
Wednesday
I met with Carla and Rebecca to discuss ways that we might simulate the CPU. We decided to start out by simulating the CPU by first testing the speed and power consumption of the MICA2 mote CPU, and then scaling the results found to the CPU of the hardware and platform that the simulator will eventually run on (for the summer, at least, this means my laptop). While this is not a very accurate way to simulate the CPU, and the simulator would have to be modified (or configured) to run on different machines, it is easier and will allow us to start thinking about how the CPU simulator will plug into the already existing parts of the simulator.
Thursday
In the morning I participated in a user study of Angela's project, FaceOFF. FaceOFF is an application for mobile devices that helps save battery power by switching the LCD screen on or off based on a user's eye movements. If the user looks away from the screen for 3 seconds the LCD display goes off and when you look back at the screen it turns back on. In order to test the project Angela set up a "simulated" office - During the test I had to check e-mail, read a newspaper, watch a downloaded video (about the planet Mars), receive a phone call, and take a break to go get coffee.
I installed TinyOS 1.1.0 on my laptop so that we can test the motes and begin developing the CPU simulator, and I then started one of the TinyOS tutorials. Even though I successfully installed TinyOS and was able to compile a TinyOS program, Blink, problems occurred when trying to transfer the program to the mote. My computer was not properly communicating with programming board so I searched through some help files. Part of the difficulty is that I am not very familiar with Cygwin or the Linux build system.
Friday
I uninstalled TinyOS 1.1.0 and began installing the beta version of TinyOS 2.0. It took all day, but I finally got the application Blink to run on the mote. The problem turned out to be a fairly simple one - I never installed the drivers for the USB-serial cable so Windows did not display the USB port number that the mote's programmer board was connected to. The command to upload the program into the mote required the USB port number so while trying to debug I had to try every port number every time a command was run. Not so efficient.
Once I knew the port number, I tried several commands from the MICA2 manual, the TinyOS tutorial, and then finally the MICA2 getting started guide. Part of the difficulty of solving the problem was that the documentation is not consistent. For example, the MICA2 manual says to use the command MIB510=/dev/ttyS4 make mica2 install, while the TinyOS tutorial does not give an example command for the MICA2 platform at all and instead says to use a command in the form of make telosb install,2 bsl,3.
Finally the MICA2 getting started guide command, make mica2 install mib510,com5 worked and the green, yellow, and red LEDs twinkled. Christmas indeed.
Monday
Today I started reading more about NesC and TinyOS. The paper The nesC Language: A Holistic Approach to Network Embedded Systems was informative. I read a couple TinyOS tutorials, starting with Lesson 1: Getting Started with TinyOS and nesC. It explains the structure and syntax of TinyOS programs, what components, modules, and configurations are, and how to use interfaces and "wire" components together.
Then I modified the Blink program to make the LEDs blink at random. Not that interesting... but it's a start.
Tuesday
Carla, Rebecca, and I went to the forest to see the sensor network currently deployed (see photos). In this part of the forest there are five Wisard nodes and a huge tower that acts as the gateway.
Over the next few weeks I will continue to learn about TinyOS, and write a couple test programs in nesC, one that uses a lot of memory and one that doesn't. The program that uses memory should have bad locality so that it avoids caching. I also have to find a way to turn off the compiler optimization. One idea is to write a method that calculates random numbers and stores them in random array indexes. The programs will then be tested on a mote and a PC to compare the running times.
Wednesday
I looked through the list of TinyOS interfaces and components and read the TinyOS serial stack TEP so I can learn how to construct serial packets. This is needed because in order to get output of programs that are run on remote motes any information must be sent back to a base mote that is physically connected to a PC.
Every Wednesday for the summer there is lunch and a talk for the undergrads put on by the Computer Science Education group. Today we got a demo of the new Lego Mindstorms kits. It was pretty cool. The latest version of the robot can actually drive straight! Yay.
Thursday
I tried to code a program that would send serial packets from the mote to the PC, but I could barely get anything to compile.
Friday
I gave up trying to figure out the serial stuff, and it turns out I was "reinventing the wheel" - There are already built-in methods and tools for sending data from the motes to a PC. So I attempted to install the SerialForwarder and Oscilloscope programs. I had to install ncc and the Java JNI library. The hardest part was actually getting the CLASSPATH environment variable correct. The TinyOS tutorial lists the wrong classpath and Cygwin could not locate the java compiler. Eventually got SerialForwarder to run (now whenever something won't compile or run I just cycle through different classpaths because I can never remember which one does what). But at the end of the day SerialForwarder still didn't show any packets being read, and nothing was being displayed in the Oscilloscope program.
Monday
Carla got two Wisard nodes and setup a circuit between them and a multimeter to measure the power of Wisard nodes which are the custom-built nodes currently being used in the Duke forest. The Wisard nodes have a command-line program that can be run on a laptop and lists a node's scheduled events such as soil moisture, light, and battery readings. I was to record the power level of each event as it happened. The only difficult part is that each event lasts only four seconds, so the power has to be "eye-balled", and if you miss an event you might have to wait a while.
Carla gave me a diagram of how to set up the circuit, and I put it all together again in my office. After an hour or so I decided I wanted to go work at home. I packed up all the stuff, and went back to my apartment and set it all up again. No problem...
Err #5, Access is denied.
FLOAD: Err -3 Opening Comm Port
So the program wouldn't start! I rechecked the wiring, rebooted the computer a couple times, and copied the program fresh from the disk. I even tried starting the program with an uppercase 'L' instead of lowercase 'l'. No luck, so I e-mailed Carla and she told me various things to try: Make sure it's using the right serial port number and baud, delete or change permissions on the log file, etc. Still no luck.
Tuesday
I spent some more time trying to get the Wisards' program working. I felt bad because I thought I had broken it - Before I had left the office I pushed the mysterious black button, which gets you into "command mode". I had tried to add some new events and I thought maybe I accidentally reset something.
Wednesday
Carla had spent Tuesday evening figuring out what happened with the Wisard program. It turned out that a Palm Pilot program had taken control of the serial port when I had restarted the laptop at home.
Friday
I spent most of Wednesday, Thursday, and Friday trying to get the TinyOS tools working. I scoured through 4+ months of TinyOS mailing list archives. I looked through the Oscilloscope source code. I changed the settings on the serial port. I recompiled the programs (a couple times). By the end of the week it still wasn't working and I was thoroughly frustrated.
Monday
Over the weekend I posted a message on the TinyOS mailing list, and got a couple responses. It turns out I had the wrong program installed on the mote connected to the programmer board. I installed the program BaseStation, and (by golly) everything worked perfectly. A small success but I was stoked, and now I can actually start programming.
I looked through the ncc and gcc compiler man pages to find a way to view the assembly language code produced by nesC programs. This will help determine whether the programs are using cache or memory. I found out that all TinyOS/nesC programs are converted to C code and saved as app.c, and then the assembly code can be viewed by using the command gcc -s.
I read about timers available for TinyOS, so that the running time of the methods can be recorded. The interface Counter seemed like it would work the best, but I could not figure out how to "wire" it to an appropriate component. I ended up using an interface called LocalTime which is implemented with the HilTimerMilliC component on MICA2 motes.
Tuesday
I looked through some of the TinyOS sample programs to find one that I could use as a model. I chose the program RadioCountToLeds, removed some unnecessary code (like the Receive method), and modified it to calculate, store, and send random numbers in packets. I downloaded the program onto the mote and ran the Listen program, which displays the contents of the packets sent over the radio:
$ java net.tinyos.tools.Listen
serial@com6:57600: resynchronising
FF FF 07 22 06 00 00 09 00 00 00 01 00
FF FF 07 22 06 00 00 29 00 00 00 08 00
FF FF 07 22 06 00 00 06 00 00 00 01 00
FF FF 07 22 06 00 00 28 00 00 00 07 00
The eighth byte is the random number generated, and the twelfth byte is the time in milliseconds.
Wednesday
Carla brought in the mother of all multimeters so that we can test the energy consumption of the Wisard nodes. This multimeter can log the current consumed by the nodes to an Excel file. Two Wisard nodes and two laptops were setup: One laptop runs a program that shows a node's scheduled events and my job is to keep track of this schedule. Carla controls the logging of current in Excel on the other laptop. Since there is a lot of idle time and events are pretty unpredictable we had to be careful not to miss anything. We ran the experiment on the "master" node for about an hour - enough time to record several occurrences of each event.
Thursday
We ran the experiment again on the "slave" node. Both types of nodes have to be tested because they implement slightly different events at different frequencies.
This week I organized and analyzed the Wisard node data.
Nine events are currently implemented on Wisard nodes: Light, temperature, and soil moisture readings are gathered via probes connected to nodes that are deployed in the forest. There are two kinds of sending and receiving: "Send data" (SD) and "receive data" (RD) are part of discovery mode and occur when nodes are searching for other nodes to communicate with. "Send message" (SM) and "receive message" (RM) events deliver the data collected from the sensors, and are part of the process of sending readings to the gateway node. The battery (BAT) event records the current state of a node’s battery, and the schedule event (SCH) calculates the schedule for the next frame.
I started pulling events out of the raw log files and graphing their current in Excel. The hard part was trying to tell the difference between each event and figuring out when they start and stop based on the current that was recorded. Even though we kept track of events during the experiment it was sometimes hard to tell which were which because the current is not always consistent, and sometimes events were adjacent to each other.
This week I continued graphing events, and found average energy consumption for each. Based on the averages and the frequency of events I estimated the energy consumption over one hour for each node, and made a pie chart showing the relative energy of each event. I also made a diagram of the experiment setup in Photoshop.
I started creating PowerPoint slides about the experiment for a presentation I will give later on. It contains a list of events, the graphs and averages, discusses the experiment setup and method, and includes a screencap of the nodes' schedule and other miscellaneous findings.
Carla, Rebecca, and I had pizza lunch with Kelly Shaw (a former student of Carla's at Duke who's now a CS professor at University of Richmond) and her DMP student this summer, Brittany.
I finished writing the TinyOS programs. In total there are five small programs: Two of them are simply large empty loops and the other three use memory. One of them stores numbers in indexes that are powers of two, and hopefully this defeats the cache. The other two programs loop and fill an array and then retrieve the values. I wrote equivalent programs in Java and tested the running times.
At first the programs in Java reported a running time of 0ms so I had to increase the size of the loops. The problem was that because the motes' RAM is only 4kb and I was using 16 bit integers the arrays could only store about 2000 values. I solved this by just using a larger nested loop. Another thing that was interesting is that the Java running times were less precise than the nesC times, so the tests had to be run about 10 times and then averaged.
Carla and I went over the TinyOS/Java tests and found that the programs do not scale consistently. The programs that didn't use memory ran less than 10 times faster in Java than nesC and the programs that used memory ran about 150 times faster in Java. Looking on the bright side, at least we found out what method *not* to use in the simulator. Fortunately, these results may help other people working on the project that have written algorithms or programs in Java and want to estimate the running time on TinyOS.
This week I gave my presentation to a small group of people. I was nervous at first but felt pretty comfortable after the first couple minutes. Thankfully, it turned out to be more of a discussion.
Susan Rodger and Jeffrey Forbes took a few undergrads to The Dive, Duke's virtual reality lab. In a giant sound-proof room a 10x10 cube is setup and images are projected onto each side. Some of the programs and games we got to see included a roller coaster that you could design and then ride, a model of the ancient Greek coliseum that you could fly above and walk through, and virtual forest where the goal was to entice a multi-headed monster into eating little pink cakes. It was very impressive.
To conclude the ten week program Carla and I went to Duke Homestead, Washington Duke's home and tobacco farm. It was interesting to learn about the history of the university and how tobacco is grown and processed. The most surprising thing to me is that the family lived in a small 4-room house.