Performance Analysis of Task 7

Task Description:
"Perform a performance analysis of the application described in task 7 to determine whether the battery-aware element of the algorithm works."[1]

Experiment Basic Information and Precondition:

The main purpose of this experiment is to find what factors can affect SPOTs’ battery life and evaluate the performance of my algorithm for Task 7. We use “Supply Voltage” to measure SPOTs battery life and think this value can range from 3050MV to 4900MV. So 3050MV means no energy (0%) and 4900MV means full-energy (100%).

In the following tests, each SPOT has been charged for 200 minutes. I implemented all tests by two different network architectures:

Network Architecture 1

Network Architecture 2

If there is no special explanation, the test is done by Network Architecture 1.

In testing result chart, X axis stands for Work-Time that records how long SPOTs can stay and the unit of Work-Time unit is second; Y axis stands for Battery-Remaining (Current Supply Voltage) measured in millivolt.

1. To measure how reading frequency can affect SPOTs’ battery life.

No Deep-Sleeping Mode

Deep-Sleeping Mode

Result:

The frequency of readings can affect SPOTs’ battery life, especially for those SPOTs with deep-sleeping mode. In a deep-sleeping mode, there is no battery consumption if the SPOT doesn’t take readings and communication with the base station. So a SPOT’s battery cannot keep itself alive for long if it frequently takes readings and uses the radio.

But the affect of reading-frequency is NOT obvious without deep-sleeping mode. The SPOTs mainly use the radio device during the whole process of taking readings. The other devices in a SPOT consume much more power than the radio so that the extra battery consumption weakens the affect of reading-frequency very much.

“While considerable power can be saved during shallow sleep, it is still necessary to power much of the Sun SPOT hardware:

• CPU – power on but CPU clock off (the CPU's power saving mode)

• Master system clocks – power on

• Low level firmware – power on

• RAM – power on but inactive

• Flash memory – power on but inactive

• CC2420 radio – power on

• AT91 peripherals – power on”[1]

[1]Quoted from Sun™ Small Programmable Object Technology (Sun SPOT) Developers’ Guide(Page 37-38) Author: Sun Labs 16-April-2007

2. To measure how deep-sleeping mode can affect SPOTs’ battery life.

Result:

The deep-sleeping mode can affect SPOTs’ battery life very much. In deep-sleeping mode, SPOTs almost don’t consume power between readings so that the battery can work for a long time.

3. To measure how different communication ways can affect SPOTs’ battery life

Network Architecture 1

Network Architecture 2

Result:

SPOTs can save a little more power by the Point-to-Point way than the broadcast way but this affect is not very important.

4. To measure how different network configurations can affect SPOTs’ battery life.

Communication Way : Broadcast

Communication Way: Point-to-Point

Result:

Different network configurations can affect SPOTs’ battery life only a little. All SPOTS with equivalent power can stay for almost equivalent time by Network Architecture 1 and the affect between SPOTs is very small. In Network Architecture 2, the middle SPOT keeps working in the shortest time, the one close to the base station stays longer and the last one keeps alive in the longest time. The number of transmission Packages through the middle one are much more than the number of those packages through the other SPOTs. So a mesh router consumes much more power than a regular SPOT. In addition, Network Architecture 2 is not as stable as Network Architecture 1 because some package is possibly lost while transmitting messages by mesh routers and the whole network doesn’t work once the middle one turns off.

5. To measure whether my algorithm is better than the basic ones.

Result: The performance with my algorithm is better than the basic one because I keep all SPOTs in the deep-sleeping mode and also change the frequency of readings. I just decrease the frequency of readings a little bit by my algorithm in order to save testing time so that the performance is probably not as good as our expectation.

In one word, the deep-sleeping mode is the most important factor to save energy for SPOTs. If SPOTs are in deep-sleeping mode, we can weaken SPOTs’ battery-consumption by decreasing the frequency of readings.

Conclusion:

According to my experiments, the deep-sleeping mode and frequency of reading can roughly determine how long the battery can keep alive. Basically, we can make SPOT keep working longer as long as we turn on their deep-sleeping mode and decrease the frequency of readings. But each SPOT has different power-storage and power-consumption abilities so that there are some performance-bias exist for the same algorithm by different SPOTs. In addition, the value of battery remaining(Supply Voltage) is not accurate by the function getVbatt().

Time Distribution:

Task	Description	Deadline	End Date	Total Time (hrs)
8	Performance Analysis of Task 7	08/15/2008	07/21/2008	203.5
Sub Task				Time
Modify previous source code				1
Testing				197
Miscellaneous Task (updating the blog, documents and so on)				5.5

[1]Quoted from the section "Task 8" of Class Requirement Document
Written by Professor Sami Rollins

[2]Quoted from Sun™ Small Programmable Object Technology (Sun SPOT) Developers’ Guide(Page 37-38) Author: Sun Labs 16-April-2007

Advanced Battery Monitor

Task Description:
"Modify the temperature sensing application described in task 5 to be battery aware. Rather than taking a temperature reading every 20 seconds, the frequency of the readings should be in proportion to the amount of battery the sensor has in comparison to the amount of battery its neighbors have. A sensor with a low battery that is connected to sensors with high batteries should take readings infrequently. Between readings, a sensor should be put into deep sleep."[1]

Analysis:
The major different part between this task and task 5 is to design an algorithm about reading-frequency calculation. I have to propose a good solution to determine how long a free-spot needs to report its battery remaining. I thought about three different solutions based on all kinds of possible situations. The following is my final strategy to get through this issue:

iThreshold_Power -- the voltage that indicates the battery remaining is enough
Its default value is 4000(Based on my observation)

iThresdhold_NoPower -- the voltage that indicates the battery is going to be dead
Its default value is 3400(Based on my observation)

These two variables can be reset by commands from the base station.



iVolt -- Current remaining voltage
iVoltMax -- Maximum value among the remaining voltage of its neighbor and itself


Rule:

iVolt > iThreshold_Power
The spot just needs to send its current remaining information to its neighbor each s without reporting it to the base station. In the test scenario, it also sends remaining to the base station.

iVolt <= iThreshold_Power and iVolt > iThreshold_NoPower
The spot needs to not only send its current remaining information to its neighbor but also report it to the base station. In addition, the time-span between two times to read information is based on this formula:

Time-Span = 20000 *(iThreshold_Power/iVolt) * (iVoltMax/iVolt);

So there are two factors to determine the time-span: One is the given threshold ; The other is the comparison to its neighbors' battery remaining.

iVolt < iThreshold_NoPower
The spot needs to report its remaining information to the base station. In addition, it should send its neighbor a trigger that make them report their current remaining to the base station one minute later.

The work-flow chart is similar to the one of task 5:


Implementation:
1. How to get battery remaining?
The same thing done in Task 6:
IPowerController ipc = Spot.getInstance().getPowerController();
... ipc.getVbatt();

2. How to make a spot deep sleep?
ISleepManager ism = Spot.getInstance().getSleepManager();
ism.enableDeepSleep();
try{
ism.ensureDeepSleep(iSleepTime);
}
catch (com.sun.spot.peripheral.UnableToDeepSleepException ex) {
ex.printStackTrace();
}

3. How to determine the reading frequency?
Just like what I talked about in Analysis Section.

Difficulty and Challenge:
The challenge involved in this task is to design a good algorithm about reading frequency. I designed 3 solutions and finally chose the most difficult one. But the performance about the chosen algorithm will be evaluated in the next task.

Time Distribution:

Task	Description	Deadline	End Date	Total Time (hrs)
7	Advanced Battery Information Monitor	08/06/2008	07/03/2008	17.7
Sub Task				Time
Design a algorithm for calculating reading frequency				6.2
Modify the code of task 5 based on the chosen algorithm				2.5
Carefully debug and check all source code of this task				1.5
Created some test cases and test this task				5
Miscellaneous Task (updating the blog, documents and so on)				2.5

[1]Quoted from the section "Task 7" of Class Requirement Document
Written by Professor Sami Rollins

Battery Remaining Monitor

Task Description:
"Implement an application that collects energy information about the network. Periodically, each sensor collects its own battery remaining and reports this number to an application running on the host computer."[1]

Analysis:
This task is similar to Task 5 but much easier than Task 5. I just need to collect battery remaining information for each sensor and report it to the base station. The free-range spots use a thread to take battery remaining reading and broadcast the result each 20 seconds. The bast station also uses a endless thread to receive the report information and print it out.

Implementation:
1. How to get battery remaining
IPowerController ipc = Spot.getInstance().getPowerController();
... ipc.getVbatt();

Difficulty and Challenge:
The function "getVbatt()" can just get supply voltage that can roughly indicate the battery remaining so that I need more parameters to make the remaining information accurate. But due to using the green spots, there are some limitations to get them. For the blue spots, we can get much more information about battery by IBattery(com.sun.spot.peripheral.IBattery).

Time Distribution:

Task	Description	Deadline	End Date	Total Time (hrs)
6	Battery Information Monitor	07/18/2008	07/01/2008	12
Sub Task				Time
Read documents and new Sun Spot APIs				3
Finish the host application				1
Finish the spot application				2
Debug two applications and add some new functionalities				4.5
Miscellaneous Task (updating the blog, documents and so on)				1.5

[1]Quoted from the section "Task 6" of Class Requirement Document
Written by Professor Sami Rollins

Experiment about Mesh Router

In task 3, I need to make a free-range spot turn to be a mesh router. I executed the command "ant set-system-property –Dkey=spot.mesh.enable –Dvalue=true" to turn on all spots' mesh-router-mode. It seems there are some limitations about using mesh routers according to SUN Spot Developers Guide.

"You want the SPOT to act as a mesh router but the application running it does not use the radio."[1]

Experiment Scenario:

1. Network Structure

Each spot can communicate with its neighbor and only Spot 1 can directly connect to the base station.

2. Test Cases
a. I deployed the same application to Spot 1,2,3 and 4. This application can use radio receive messages from the base station. In this case, the application and radio all worked. So we can draw a conclusion that the mesh router can extend the wireless signal in the entire network and we can probably use radio.

b. I made a little modification based on Case a. I removed the radio part from the previous application and configured it to Spot 1, 2 and 3. Then only spot 4 use radio for receiving messages. Finally, it still worked. So we can totally believe that turning spots as mesh routers is a good method to propagate a message in a mesh network.

c. In task 4, the mesh router can not only receive messages but also directly send (or broadcast) messages by radio.This case is kinda an addition of Case a.



[1]Quoted from Section "Configuring network features"(Page 21) of Sun™ Small Programmable Object Technology (Sun SPOT) Developers’ Guide .This version of the Guide refers to V2.0(updated 16-April-2007)

Temperature Monitor Network

Task Description:
"Implement a temperature sensing application that works as follows. Each sensor will monitor the temperature in its area, sensing every 20 seconds. If a sensor senses that the temperature has risen above a given threshold(e.g., 80 degrees), it will do as follows:
1. It will sense more frequently, every 5 seconds, until the temperature drops below the threshold.
2. It will report its readings to an application running on the host computer attached to the base station.
3. It will trigger its neighbors to report their readings to the base station for the next 1 minute."[1]

Analysis:
I need to combine task 2 with part of task 4 for implement this task. But the sensor needs to send a message to not only the bast station but also its neighbor so that I have to spend a little time to think about the possible conflicts. In addition, I added one small functionality to this task: the base station can set or change the temperature threshold.

I also drew a work-flow chart like before:

From the above chart, we know that there are four threads involved in the spot side and two threads in the base station side.

Base Station Side
1. Set Threshold Thread
This thread can get user's command input and broadcast this command in the entire network. The format of user's input should be like this: degree XXX.XX

2. Receiver Thread
When the base station receives the temperature reported from a free-range spot, it should print it out.

Free-range Spot Side
1. Threshold Receiver Thread
I set up a internal parameter to store the value of threshold. The spots should change the threshold's value after they get the command from the base station.

2. Temperature Detecting Thread
This thread is derived from task 2. The LEDs will blink in different color according to the degree of current temperature. If current temperature's degree is great than the given threshold, the spot should accomplish two things including reporting this degree to the base station and sending a trigger to their neighbors.

3. Trigger Receiver Thread
When a spot receive a trigger from its neighbor, it will store current time-stamp into a hashtable.

4. Trigger Handle Thread
It's a endless thread to check all existing elements of the above hashtable one by one. If any elements have been kept in this hashtable for a minute, it should report current temperature to the base station and remove this element.

Implementation:
1. A spot receivers a trigger from its neighbor
...
((RadiogramConnection)dgConnection).setMaxBroadcastHops(1);
...
dg.reset();
dgConnection.receive(dg);
tmp = dg.readUTF();
...

2. A spot sends current temperature to the base station
...
((RadiogramConnection)dgConnection).setMaxBroadcastHops(4);
...
dg.reset();
dg.writeUTF("T"+strDegree);
dgConnection.send(dg);
...

3. Testing
I spent most time on testing this task. I use the following use cases:
a. Set the default threshold as 60
All spots reported current temperature to the base station because current temperature is higher than 60.

b. Turn off the spot after it sends a trigger to its neighbor
The triggered neighbor spot exactly reported current temperature to the base station one minuter later.

c. Continuously change the threshold by command line
All spots worked very well based on different thresholds.

Difficulty and Challenge:
This task seems easy for me because I already accumulated some experience about Sun Spot. Basically, I didn't encounter any big trouble while programming. About challenge, I have to say testing is still a time-consumption part.

Time Distribution:

Task	Description	Deadline	End Date	Total Time (hrs)
5	Advanced Temperature Monitor	07/11/2008	06/30/2008	15.7
Sub Task				Time
Experiments about using mesh routers				0.5
Finish a host application containing two threads				1.5
Finish a spot application including four threads				3.2
Test all applications				8
Miscellaneous Task (updating the blog, documents and so on)				2.5

[1]Quoted from the section "Task 5" of Class Requirement Document
Written by Professor Sami Rollins

SPOT Network Monitor

Task Description:
"Implement an application that collects coarse topology information about the network. Each sensor will discover its neighbors and report the number of neighbors it finds to an application running on the host computer attached to the base station. A superior implementation would track the IEEE address of the neighbors for each sensor."[1]

Analysis:
This task looks easier than the previous one and I can take advantage of some existing code. In my opinion, the important thing involved in this task is about work-flow design.

First of all, all free-range SPOTs broadcast a "alive" message to its neighbors and its neighbors can get its IEEE address by analyze this message. There is a hashtable stored in SPOT side that can maintain the information about neighbor SPOT. The SPOT will add one pair of key and value to this hashtable when it gets a new address. It will also delete the old information if it cannot get its neighbor's information in 5s.

Secondly, I need to discard the "broadcast" thing while making the free-range SPOT report its IEEE information to the base station. So every SPOT should know the base station's address before they transfer any message. The base station keeps all IEEE address information in a hashmap and it will print out the content when users input the word "print".

The following is my work-flow chart about communication:



Implementation:
1. How to get an IEEE address?
a. To get its own address
long ourAddr = Spot.getInstance().getRadioPolicyManager().getIEEEAddress();
You can use "IEEEAddress.toDottedHex(ourAddr)" to format the address as xxxx.xxxx.xxxx.xxxx

b. To get the message source's address
Datagram dg = null;
...
dgConnection.receive(dg);
String strAddress = dg.getAddress();

2. How to output all IEEE address?
if(!hmAddress.isEmpty()){
    Iterator iAddr = hmAddress.entrySet().iterator();
    ArrayList strAddrList;
    while(iAddr.hasNext()){
        Map.Entry entryAddr = (Map.Entry)iAddr.next();
        strAddrList = (ArrayList) hmAddress.get(entryAddr.getKey());
        if(strAddrList.isEmpty()){
            System.out.println("There is no neighbor information related             to sensor " + entryAddr.getKey().toString() +"\n");
        }
        else{
            System.out.println("IEEE address list of sensor " +                      entryAddr.getKey().toString() +"\n");
            for( int i=0; i1){
                strTotal+="s.";
            }
            else{
                strTotal+=".";
            }
            System.out.println(strTotal);
        }
        System.out.println("----------------------------------------------------------------\n\n");
    }
}
else{
    System.out.println("No IEEE address existing!\n");
}



2. How to get only neighbors?
((RadiogramConnection)dgConnection).setMaxBroadcastHops(1);
The above line can narrow down the number of neighbors. For example:



Spot 3 has only one neighbor: Spot 2;
Spot 4 has 4 neighbors including 1,2,5 and 6;
Spot 6's neighbor is Spot 4;

Difficulty and Challenge:
In general, I didn't encounter any problem except testing during the whole development process. Sometime the base station couldn't receive the message from a free-range SPOT. I found out the reason is about the router mode according to some experiments. For the previous task, I turned on their special router mode that caused radio malfunction.

Time Distribution:

Task	Description	Deadline	End Date	Total Time (hrs)
4	Collecting and tracking SPOT network information	06/27/2008	06/27/2008	20.2
Sub Task				Time
Requirement Analysis and work-flow Design				4.5
Create a Host application to implement a superior’s functionality				3
Create a Spot application to discover its neighbors				3.2
Debug and Test this task				7
Miscellaneous Task (updating the blog, documents and so on)				2.5

[1]Quoted from the section "Task 4" of Class Requirement Document
Written by Professor Sami Rollins

Transferring a COLOR command in the entire SPOT network

Task Description:
"Implement an application that will enable a user to specify a color and will propagate to all sensors a command to blink in the user-specified color. The user will issue the command from a host computer attached to a base station node. The base station will broadcast the command, and the sensors will use the mesh networking protocol provided by the API to propagate the command to the entire network. "[1]

Analysis:
We can divide this task into two individual tasks: 1. The base station broadcasts the "Change Color" command; 2. free-range SPOT that can directly communicate with the base station sends the same command to the other SPOTs that are beyond the base station's radio range.The core part of this task is to use communication APIs and debug all applications. We need import com.sun.spot.io.j2me.radiogram to realize communication between base station and free-range SPOTs or among free-range SPOTs.

There are two ways to propagate the command in the entire network.
1. A free-range SPOT continuously resend the same command after it receive the "Change Color" command. In this case we need a good algorithm to avoid command conflicts because of communication time delay.

Free-Range SPOT Side Work Flow

Command Process Algorithm among free-range SPOTs:
After a SPOT receives a "Change Color" command, it will parse this command to get the source's "NodeLevel" nlA. If this value is less than its own "NodeLevel" nlB, we think the source node could be its ParentNode so that we blink LEDs in this given color and set "NodeLevel" nlB as "NodeLevel" nlA + 1. Otherwise, we need to check whether its previous ParentNode is still alive. If its ParentNode is dead, we set the source node as its new ParentNode by changing "NodeLevel" nlB to "NodeLevel" nlA + 1.

There is a Hashtable inside to maintain all SPOT nodes' "Alive" information that current node can reach. When the SPOT get any "Alive" message from the other SPOTS, it just modifies the relevant value.

2. Turn a free-range SPOT as a mesh router.
When the base station broadcasts the command, this command will go everywhere in the whole network. In order to realize this, we need to execute the following command to set SPOT.
"ant set-system-property –Dkey=spot.mesh.enable –Dvalue=true"

In addition, we need to set the number of hops when we create the connection like this:
((RadiogramConnection)dgConnection).setMaxBroadcastHops(4);


Note: Users use command line to specify different color. Currently, we support two ways to input:LEDColor and RGB so that users can just provide colors' name or rgb value.

Implementation:
In SPOT host side, I used two threads to execute sending and receiving message. The following code can demonstrates the communication process:

// Create a DatagramConnection
DatagramConnection dgConnection = null;
Datagram dg = null;

// Datagram Connection Configuration
dgConnection = (DatagramConnection) Connector.open("radiogram://broadcast:37");
//Set the number of hops
((RadiogramConnection)dgConnection).setMaxBroadcastHops(4);
dg = dgConnection.newDatagram(dgConnection.getMaximumLength());

// Send Messages
dg.reset();
dg.writeUTF(strMessage);
dgConnection.send(dg);

// Receive Messages
dg.reset();
dgConnection.receive(dg);
strMessage = dg.readUTF();

I used "regular expression" to parse the commands that users input. The standard command format is like below:

1. name ColorName E.g. name red name blue
Regular Expression:
name (blue|chartreuse|cyan|green|magenta|mauve|orange|puce|
red|turquoise|white|yellow){1}$

2. rgb value value value E.g. rgb 100 100 100 rgb 255 0 0
Regular Expression:
rgb( ([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3}$


In free-range SPOT side, I reused color-control code finished in Task 2 to change LEDs' color and propagate the commands to the other SPOTs by "broadcast" mode.

Testing:
I designed ten test cases to simulate different network structure. But we can satisfy this task's requirement if these applications can pass through some typical scenarios. So I chose a couple of test cases.

Different Test Scenarios(4 Free-Range SPOTs)

(Finish Testing in the above Scenario)

(Finish Testing in the above Scenario)

(Finish Testing in the above Scenario)



(Finish Testing in the above Scenario)

Difficulty and Challenge:
In this task, testing brought me a lot trouble because it's difficult to check the intermediate value hidden in a free-range SPOT. So I spent a lot of time on testing. This task is much harder than the previous one. I drew a work flow chart to help myself deeply figure out the communication process among SPOTs.

Problem: Can't use the Console to run a host application
1. To attach require jars' path to the current classpath
2. To enable the base station by executing the command "ant selectbasestation"
3. To run "ant host-run"

Time Distribution:

Task	Description	Deadline	End Date	Total Time (hrs)
3	Transferring a COLOR command in the entire SPOT network	06/20/2008	06/20/2008	32.9
Sub Task				Time
Requirement Analysis				1.5
Study 2 demos related this task again				4
Create a SPOT Host Application and implement “broadcast” functionality				2
Finish the work flow on free-range SPOT side				4.5
Create a SPOT application and implement all functionalities				3.2
Simple Test				8
Create test scenarios				1.2
System Test				4
Turn a SPOT as a mesh router and test				1
Miscellaneous Task (updating the blog, documents and so on)				3.5

[1]Quoted from the section "Task 3" of Class Requirement Document
Written by Professor Sami Rollins