Changeset 2817

Timestamp:

10/30/09 20:21:49 (4 weeks ago)

Author:

jaein

Message:

 

Location:

HydroWatch/Tim/doc/ipsn10

Files:

• sec_energy.tex (modified) (1 diff)
• sec_eval.tex (modified) (1 diff)
• sec_sysarch.tex (modified) (1 diff)

HydroWatch/Tim/doc/ipsn10/sec_energy.tex

@@ -83 +83 @@
 \subsection{Deriving Harvest Predictions}
 
-The next step is to predict the solar radiation variation for the future day $k$
+The next step is to predict the solar radiation variation for future day $k$
 when the cloud cover for day $k$ is given as $C_i(k)$. Given a confidence value 
 $\lambda \in (0, 1]$, we can find the estimated solar radiation variation $\hat{\delta}$ 
-as the value of that satisfies:
+as the value that satisfies:
 \begin{align}
         \int_{\hat{\delta}}^1  p(\delta | C_i(k)) d\delta = \lambda 

HydroWatch/Tim/doc/ipsn10/sec_eval.tex

@@ -9 +9 @@
 
 \subsection{Optimization Protocol}
-In order to validate the performance of our optimization protocol we have retrospectively tested our protocol on several months of outdoor environmental solar data. Given the lack of periods of little sun from this data, we simulated this by inserting periods of low solar energy in order to be able to validate performance under these types of conditions.
-
-Figure~\ref{fig:vlsb1} shows the performance of the protocol over 110 days of data for a typical node. In this case an interval is defined as one day where the parameters $F_s(n,k)$ and $F_r(n,k)$ are recalculated every day/interval. Figure~\ref{fig:vlsb1}(a) shows the case where 3 days ahead energy prediction is used, whereas Figure~\ref{fig:vlsb1}(b) shows the case where an estimate of the energy on the day only is used. We can observe the way in which longer-term energy forecast information changes the behavior of the system. The forecast information allows the system to take greater risks in how far it can drop it's stored energy below the target value. This in turn allows for a smoother progression of report and sample parameters. In the case of limited forecast information, there is much greater fluctuation in these same parameters in order to keep within the target energy range.
+In order to validate the performance of our optimization protocol, we have retrospectively tested our protocol for several months on outdoor environmental solar data. Given the lack of periods of little sun from this data, we simulated this by inserting periods of low solar energy in order to be able to validate performance under these types of conditions.
+
+Figure~\ref{fig:vlsb1} shows the performance of the protocol over 110 days of data for a typical node. In this case, an interval is defined as one day where the parameters $F_s(n,k)$ and $F_r(n,k)$ are recalculated every day/interval. Figure~\ref{fig:vlsb1}(a) shows the case where 3 days ahead energy prediction is used, whereas Figure~\ref{fig:vlsb1}(b) shows the case where an estimate of the energy on the day only is used. We can observe the way in which longer-term energy forecast information changes the behavior of the system. The forecast information allows the system to take greater risks in how far it can drop it's stored energy below the target value. This in turn allows for a smoother progression of report and sample parameters. In the case of limited forecast information, there is much greater fluctuation in these same parameters in order to keep within the target energy range.
 
 \begin{figure*}[ht]

HydroWatch/Tim/doc/ipsn10/sec_sysarch.tex

@@ -30 +30 @@
 
 \subsection{Basestation}
-The base station acts as a bridge between the 802.15.4 radio network and the system server. In order to allow streamlined communication between a basestation and a remote-server we make use of the BLIP \cite{BLIP} network stack allowing low-powered communication over IPv6.
+The base station acts as a bridge between the 802.15.4 radio network and the system server. In order to allow streamlined communication between a basestation and a remote-server, we make use of the BLIP \cite{BLIP} network stack allowing low-powered communication over IPv6.
 
 \subsection{WSN nodes}
-In order to receive commands from the server (such as updating report and sample frequency), nodes run a binary-shell protocol that BLIP supports. This effectively provides a convenient mechanism for sending Remote Procedure Commands (RPCs) from the server (or client machine) and address directly to any node in the network. 
+In order to receive commands from the server (such as updating report and sample frequency), nodes run a binary-shell protocol that BLIP supports. This effectively provides a convenient mechanism for sending Remote Procedure Commands (RPCs) from the server (or client machine) and address any node directly in the network.