Why simulation?
~The logistical hurdles of using real hardware: programming, power,
packaging, the coupling of sensors to the environment and other
hardware vagaries prevent us from focusing the soundness of
the application/algorithm itself.
~Complete visibility into the system
~Controlled, deterministic environment enables one to tweak the system
and to reproducible problems

Overly simplistic noise model
~Indoor radio propagation channel are notoriously difficult to model 
accurately.
~Enable better understanding of the algorithms.
In the early stage of development of a new algorithm,
subtle effects of the radio or sensor channels are often
invisible compared to the basic problems caused by code itself.
When code is first written, even a trivial channel model will
reveal fundamental design flaws and protocol bugs, sanity-check
the offered load against the channel capacity, and tell common software
problems such as memory overruns, broken interfaces, and plain coding error.

TOSSIM:  UCB
EmSTAR: UCLA
ATEMU :  UMD

1)Host: Do we have to  rebuild and recompile from simulator to actual 
mica2dot
TOSSIM   PC     based
EmSTAR   Linux based: pure simulation, true in-situ deployment
         (ceiling array, portable array), hybrid
ATEMU    AVR  microprocessor based systems
If  we compile the application on Linux, it runs on x86, then we have to 
rebuild
and recompile when it runs on the MICA2. With ATEMU, we run the exact same
binary as you would on MICA2.

2) Heterogeneousness  of nodes
TOSSIM     N, same type of nodes, same application, same binary
EmSTAR     N, same type of nodes, same application
ATEMU      Y,  a different binary for each node

3)Simulation level:
TOSSIM : bit level
EmSTAR: packet level
ATEMU:  ???

4)Network characteristics: packet loss rate, latency, sensing accuracy, etc.
TOSSIM: packet loss rate; anything higher dependent on how the packet
        layer being used
EmSTAR: ? ??
ATEMU: doesn't come with canned metric; have to be specified in the
        application to measure them

5)Radio/channel  model
T:     [-r <static|simple|space ] not radio propagation
       but radio abstraction of directed independent bit errors between two 
nodes.
E:     channel models of ceiling array and portable array.
A:     D-squared model can be changed, but we will have to write C code to 
implement our own model radio



~Shortcoming:
Interrupts are non-preemptive
T:  No mica2 stack,( unless you care about CC1000 specific operations)
E:  1) sort of works with TinyOS
    2) Does not support CC1000
A:  The operation of sensor boards is not modeled yet; it is still very much 
work in progress


TOSSIM usage
1.  Compilation: under  application directory: make
                                               make pc

2.  Usage: executable: main
     main  [options] num_nodes
     [ -h| --help]
     [-r <static|simple|space>] : radio model
     [-l] invocation logging ; mote 0 to a TCP socket

3. Ctrl-C: exit cleanly

4.dbg
   .Have to set DBG at least with one mode, otherwise all would be enabled, 
the simulation will run very slowly.
   .Four modes are reserved for application components.
   .Save dbg statements to a file. Perl scripts or other tools can read in 
the log of the run and provide info. on packet loss rates, routing 
state.etc.
   . Time stamp(packet transmit delay) --- In external_comm.c., 
printTime(char* buf, int len).
     transmit time = preamble/start symbol time + data time
     delay time = receive time - send time - packet duration

5. Radio model
  An extensible radio model, user has to specify the level of accuracy in 
code.
.distance does not effect signal strength; interference is worse than real
.Two types of models
     simple
     lossy: lossy.nss by default -rf file
               LossyBuilder generates packet loss rates and models 
interference and corruption but not noise.

?6.Connectivity models :
        1) single cell         2) cells.txt

7. Environmental Model
     User has to write complex real-world models,
     Ex. environmental plugin -- the calamari plugin,

8. GUI
TinyViz, a Tython console, or both simultaneously
~ TinyViz
     . change topology  through a GUI panel, by dragging motes and setting 
options
     . TinyViz plugins
     . visualize what goes on in the network
     . manual manipulation, precompile their plugins
         ----limited interactivity. cursory exploration
~ Tython
     . a scripting interace to TOSSIM
     . Tython is based on Jython,

9.Data processing
.TOSSIM cannot talk to MATLAB.
.Tython supports using Python scripts (and libraries) to process data.