# Sastry NEST meeting notes
# Date: 4/9/2004
# Present: Phoebus, Bruno, Dr. Lee, Bonnie, Mike, Massimo, Luca, Parvez, Tanya
#          Dengfeng
# Scribe: Phoebus Chen with Bonnie's Notes

Bruno: Next Week, we will need to give a presentation to UTC describing our
research.  Will need to put together the slides Wednesday/Thursday of next
week.  Bruno will coordinate.

- Final version of pinOut board sent out to Advanced circuits
  * expect to get back next week (Thursday?).  Will need to send out to
    DigiCom for assembly.
  * D. Culler placed another order of 50 eMotes, since his original supply is
    gone.
  * We have the PoE switch already.  Mike will talk with Soda Hall Testbed guys
    Eric and Albert to see how they modded their eMotes, and test that they
    can be powered over the PoE switch.
  * 40 mote parts are almost ready.  Wires soldered and crimped to batteries
    and charger boards, and ready for assembly onto wooden mounting boards.
    ~ can run experiments, though pain to reprogram many without pinOut
      boards ready.


Setting Short Term Goals for 2 weeks later
******************************************
- We need to start to really evaluate the software tools available and 
  integrate into a "metric parameter extraction" framework.
  * need to be prepared to write a design doc two weeks later
  * Key idea: easy to dump collected parameters into something like MATLAB for
    data analysis
    ~ optional: visualization tools in MATLAB to graph parameter
      changes/correlations, so we get an idea of what's going on.
  * Everyone needs to learn TinyOS and become an expert in an "area"
  * People assigned (see below) will give a 5-10 minute spiel on how we can
    use a piece of software for our project (or if we shouldn't use it)
    ~ preferably some hands on "tinkering" with code, tell us how easy
      to use it.
    ~ questions below are just to start thinking, not to encompass all
      possible issues to be explored.
  * Everyone will be expected to code when we finally implement some software
    so we need to start tinkering now


- Top Down: evaluate application software that potentially can be used to 
  diagnose the network
  * TinyDB (Mike Manzo)
    ~ can it be used for parameter extraction?  How does "querying" work?
    ~ does it add easily to an existing application (run in parallel and
      easy to take out)?
  * Surge (Bruno)
    ~ How can we use the current visualization tool?  Is it easily modified?
      Very modular?
    ~ what is the message protocol (ex. packet structure) used to talk
      between the network and the java application at the base station?
    ~ is it easier to write from scratch the NesC code for network
      parameter extraction, or is it easier to modify what they have?


- Bottom Up: try modifying current implementations to add parameter extraction
  Actual Coding/Tinkering required!
  * Alec's Multihop Routing (Tanya)
    ~ What parameters do we want to extract?
    ~ What code did we have to modify and how?
  * PEG Crumb Routing (Phoebus)
    ~ What parameters do we want to extract?
    ~ What code did we have to modify and how?
    ~ can we get parameter extraction as a "service" that we turn on?


- Other: Simulation Environments
  * TOSSIM, TinyViz, EMSTAR (Bonnie)
    ~ What does EMSTAR do?  How is it different from TOSSIM?
    ~ Can we change the radio environment being modeled easily?  How?
    ~ Can these simulation environments be used to provide "perfect 
      localization" and "perfect sensing" to isolate and test the correctness
      of pursuit evasion and network routing algorithms?
    ~ How does one get data in/out of the simulation environment (ex. to
      talk to MATLAB, running a pursuit evasion algorithm)?  
    ~ What plugin work has already been done to model the environment?
      How does it interact with TinyViz/TOSSIM (any timing issues, order of 
      events simulated)?
    ~ How can we use the simulations evironments to relate (graph/analyze) low
      level network parameters to higher level characeristics like
      1) packet loss rate
      2) latency
      3) sensing accuracy
      that a pursuit evasion algorithm might be concerned with?