nido.tex

无线通信的主要编程软件,是无线通信工作人员的必备工具,关天相关教程我会在后续传上.

Running LossyBuilder will, by default, generate a loss topology for a
10 by 10 grid with a grid spacing of five feet (45' by 45'), and print
it to standard out. It prints the loss topology in the form that \sim
expects. The {\tt -i} option allows you to specify an input file of
(x,y) positions, which has the format

\begin{verbatim}
x y
x y
x y ...
\end{verbatim}

\noindent where the coordinate system is in feet. The first (x,y) pair
is the position of mote 0, the second is the position of mote 1,
etc.

For example,

\begin{verbatim}
java net.tinyos.sim.LossyBuilder -d 20 20 -s 10 -o 20x20-10.nss
\end{verbatim}

\noindent will output a loss topology of a 20 by 20 grid, with
ten foot spacing, and write it to the file ``20x20-10.nss''.

\subsection{Bit Errors and Packet Errors}

The forumula for calculating packet error rates ($E_{p}$) from bit
error rates ($E_{b}$) for the mica RFM 40Kb stack with SecDed encoding
is:

\begin{eqnarray*}
&&E_{p} = 1 - (S_{s} \cdot (S_{e})^{d})\\
&&S_{s} = (1 - E_{b})^{9}\\
&&S_{e} = (1 - E_{b})^{8} + (8 \cdot E_{b} \cdot (1 - E_{b})^{12})\\
&&E_{p} = 1 - ((1 - E_{b})^{9} \cdot ((1 - E_{b})^{8} + (8 \cdot E_{b} \cdot (1 - E_{b})^{12}))^{d})
\end{eqnarray*}

where $S_{s}$ is the start symbol success probability, $S_{e}$ the
probability a packet byte is uncorrupted (zero or one bit errors), and
$d$ is the number of bytes in the packet.

The simple model can be represented in the lossy model: it is a fully
connected graph, in which every edge has a loss probability of
zero. However, doing so requires specifying the entire graph to \sim;
the simple model is an easy shortcut (and has an internal
representation that's more efficient).

\subsection{Lossy Model Actuation}

Specifying a loss topology with a file defines a static topology over
an entire simulation. There are simulation situations, however, in
which changing topologies are needed. \sim therefore allows users to
modify the loss topology at run-time. Applications can connect to \sim
over a TCP socket and send control messages to add, delete, or modify
network links. Currently, the only application that does so is
TinyViz, discussed in Section~\ref{sec:tinyviz}. The TinyViz network
plugins use the same empirical model of LossyBuilder to generate link
loss rates; moving motes causes TinyViz to send the appropriate
commands to \sim.

\section{ADC Models}
\label{sec:adc}

\begin{figure}
\centering
\includegraphics[width=6.5in]{fig/adc-viz.png}
\caption{Setting ADC values in \tinyviz}
\label{fig:adc-viz}
\end{figure}


\sim provides two ADC models: random and generic. The model chosen specifies
how readings taken from the ADC are generated. Whenever any channel in
the ADC is sampled in the random model, it returns a 10-bit random
value (the rene and mica ADCs are 10 bits).

The general model also provides random values by default, but has
added functionality. Just as external applications can actuate the
lossy network model, they can also actuate the generic ADC model using
the \sim control channel, setting the value for any ADC port on any
mote. Currently, only \tinyviz, (discussed in
Section~\ref{sec:tinyviz}) supports this, through the ADC
plugin. Left-clicking on a mote selects it; using the ADC panel, you
can set the 10-bit value read from any of the mote's ADC
ports. Figure~\ref{fig:adc-viz} shows a screenshot of this \tinyviz
functionality.

\section{EEPROM}
\label{sec:eeprom}

\sim models the EEPROM at the line (16-byte block) level. \sim models it
with a large, memory-mapped file. By default, this file is anonymous,
and disappears when a simulation ends. However, with the {\tt -ef}
option, a user can specify a named file to use; this allows the EEPROM
data to persist across multiple simulation invocations.


\section{\tinyviz}
\label{sec:tinyviz}

\tinyviz is a Java visualization and actuation environment for
\sim. The main \tinyviz class is a jar file,
{\tt tools/java/net/tinyos/sim/tinyviz.jar}. \tinyviz can be attached
to a running simulation. Also, \sim can be made to wait for \tinyviz
to connect before it starts up, with the {\tt -gui} flag. This allows
users to be sure that \tinyviz captures all of the events in a given
simulation.

\tinyviz is not actually a visualizer; instead, it is a framework in
which plugins can provide desired functionality. By itself, \tinyviz
does little besides draw motes and their LEDs. However, it comes with
a few example plugins, such as one that visualizes network traffic.

\begin{figure}
\centering
\includegraphics[width=6.5in]{fig/tinyviz.png}
\caption{\tinyviz connected to \sim running an object tracking
application. The right panel shows sent radio packets, the left panel
exhibits radio connectivity for \mote 15 and network traffic. The
green arrows and corresponding labels represent link probabilities for
\mote 15, and the magenta arrows indicate packet transmission.}
\label{fig:tinyviz}
\end{figure}

Figure~\ref{fig:tinyviz} shows a screenshot of the \tinyviz tool. The
left window contains the simulation visualization, showing 16 \motes
communicating in an ad-hoc network. The right window is the plugin
window; each plugin is a tab pane, with configuration controls and
data.

The second element on the top bar is the {\bf Plugin} menu, for
activating or de-activating individual plugins. Inactive plugins have
their tab panes greyed out.

The third element is the layout menu, which allows you to arrange
motes in specific topologies, as well as save or restore
topologies. \tinyviz can use physical topologies to generate network
topologies by sending messages to \sim that configure network
connectivity and the loss rate of individual links.

The right side of the top bar has three buttons and a slider. \tinyviz
can slow a simulation by introducing delays when it handles events
from \sim. The slider configures how long delays are. The On/Off
button turns selected motes on and off; this can be used to reboot a
network, or dynamically change its members. The button to the right of
the slider starts and stops a simulation; unlike the delays, which are
for short, fixed periods, this button can be used to pause a
simulation for arbitrary periods. The final button, on the far right,
enables and disables a grid in the visualization area. The small text
bar on the bottom of the right panel displays whether the simulation
is running or paused.

The \tinyviz engine uses an event-driven model, which allows easy
mapping between TinyOS' event-based execution and event-driven
GUIs. By itself, the application does very little; drop-in plugins
provide user functionality. \tinyviz has an event bus, which reads
events from a simulation and publishes them to all active plugins.

\subsection{\tinyviz Plugins}
\label{sec:plugins}

Users can write new plugins, which \tinyviz can dynamically load.  A
simple event bus sits in the center of \tinyviz; simulator messages
sent to \tinyviz appear as events, which any plugin can respond
to. For example, when a mote transmits a packet in \sim, the simulator
sends a packet send message to \tinyviz, which generates a packet send
event and broadcasts it on the event bus. A networking plugin can
listen for packet send events and update \tinyviz node state and draw
an animation of the communication.

Plugins can be dynamically registered and deregistered, which
correspondingly connect and disconnect the plugin from the event
bus. A plugin hears all events sent to the event bus, but individually
decides whether to do anything in response to a specific event; this
keeps the event bus simple, instead of having a content-specific
subscription mechanism.

A plugin must be a subclass of {\tt net.tinyos.sim.Plugin}. {\tt
Plugin} has the following signature:

\begin{verbatim}
public abstract class Plugin {

  public Plugin() {}

  public void initialize(TinyViz viz, JPanel pluginPanel) {...}
  public void register() {...}
  public void reset() { /* do nothing */}

  public abstract void deregister();
  public abstract void draw(Graphics graphics);
  public abstract void handleEvent(SimEvent event);
}
\end{verbatim}


Plugins register themselves with the \tinyviz event bus, which then
notifies them of all events coming in from TOSSIM; it is up to an
individual plugin whether to do something. The {\tt draw} method is
used to draw visualizations in the left pane of the TinyViz window.


\section{Using {\tt gdb}}

The binary executable produced by typing {\tt make pc} in any app
directory can be debugged using GDB. Developers of TinyOS code can
step through programs they have written, debugging deterministic,
logical aspects of their code before loading programs onto motes.

When accessing variables and functions in \sim under GDB, specific
prefixes precede them, to distinguish variables from different
components that have ths same name.  The nesC compiler takes each
component's fields and functions and renames them with unique
identifiers. This renaming for fields of a component is done by taking
the field name, and preceding it by the component name and a {\tt \$}
sign. Functions are renamed by taking the name of the function and
preceding it by the name of the component it is defined in, followed
by a {\tt \$} sign, followed by the interface name, followed by
another {\tt \$} sign.

The maximum number of nodes that can be simulated is determined at
compile time.  This value, as mentioned in section {\tt \sim
Architecture} specifies the size of the array for each component's
fields during code generation of the compilation process. When
compiling for the {\tt pc}, each declaration of a component field is
followed by {\tt [}, the value of {\tt tossim\_num\_nodes}, and {\tt
]}, where tossim\_num\_nodes is specified by the flag {\tt
-fnesc-tossim\_tosnodes=} in {\tt Makerules}, or by default, set to
1000.  This is the way \sim simulates multiple motes. \sim keeps an
array for each variable of state, and references each mote's
corresponding state when running code for that mote.

During code generation for the {\tt pc}, all references to component
fields are followed by {\tt [}, {\tt tos\_state.current\_node} and
{\tt ]}, where {\tt tos\_state.current\_node} refers to the moteID of
the mote \sim is currently executing code for.

For, for example, the {\tt Counter} component has a variable named
{\tt state} of type {\tt uint\_16t}. This translates to the C name
{\tt Counter\$state}. When compiled for \sim, it becomes {\tt
uint16\_t Counter\$state[MAX\_NODES]}. If a component has a variable
that's an array (e.g., {\tt uint8\_t buffer[8]}, it becomes an array of
arrays (e.g., {\tt uint8\_t buffer[8][MAX\_NODES]}). Laying out module
variables in this way means that overrun and underrun bugs will have
different effects on real motes and in TOSSIM. On a real mote, such a
bug will corrupt that mote's state; in TOSSIM, it will corrupt other
motes' state.

Using the application {\tt Blink} as an example, type {\tt make pc} in
the {\tt /apps/Blink/} directory to compile the application for
\sim. Run {\tt gdb} on the executable produced by typing {\tt gdb
build/pc/main.exe}. Examining {\tt BlinkM.td}, to break at the
function Clock.fire(), type {\tt break *BlinkM\$Clock\$fire}. {\tt
break} (or {\tt b}) specifies a breakpoint in GDB, and the {\tt *}
tells the GDB command line parser to examine the entire block of text
following it as a single expression. It is currently necessary to
specify the {\tt *} before the function name for GDB to parse it
properly. {\tt BlinkM} denotes the component the function is defined
in, and {\tt Clock} specifies the interface the function {\tt fire}
belongs to.