# Sastry NEST meeting notes
# Date: 4/23/2004
# Present: Phoebus, Cory, Bonnie, Mike, Massimo, Luca, Tanya, Dengfeng
# Scribe: Phoebus Chen

- Physical Hardware update:
  * The pinoutTestTelos3 PCBs that arrived back from Advanced Circuits had 
    holes that were too small for the mica2dot connector pins.
    ~ They had thought that the holes were vias, and filled them in.
    ~ a new run of the board is being made (free of charge) and should arrive
      early next week.
    ~ Moral of the Story:
      1) tolerances for pin hole sizes are +/-5 mils normally, and +/- 3 mils
         for production runs if we specify so in the README file with your 
         order.
      2) pin hole sizes 18 mils and smaller are automatically considered as
         vias, and may not have inner diameters that are to specification.
      3) good rule of thumb to make all holes 6 mils larger than the spec
         size for the pin.
  * Phoebus talked to Mo Ohady at DigiCom about assembly of PCBs
    ~ Estimated Time to Completion once they get the order is about 2 weeks
      for 50 boards.
    ~ We will need some people to solder and populate some boards if we wish
      to use them in the interim... we'll have sign up slots for shifts
      if we are doing this ourselves.
  * MIB600, the eMotes, have arrived.  We have 50 of them
    ~ Mike has talked with Eric Fraser about how to mod them so that Power
      Over Ethernet works with the HP routers.  Eric says that Mo should have
      schematics/designs and know how to mod them.
    ~ We will mod 45 of the boards at DigiCom and leave 5 for ourselves to mod.
      This is in case it takes Digicom 2 weeks, and we need the eMotes sooner.
  * Bonnie assembled most of the motes onto the wooden boards, for use before
    the pinOutTestTelos3 boards come back and are populated.  Tanya cut some
    antenna wires.


Software investigation reports
******************************
(Recap: evaluating software to determine how to write code and extract
        parameters from our sensor network, dumping it into a database for
        analysis.  How to write a software tool that will help us 
        understand the network and do research on  "metrics".)


- Crumb Routing used in PEGSensor (Phoebus)
  * didn't get around to modifying code.  Have compiled PEGSensor using
    fixes suggested by Cory, and can generate documentation using Graphviz.
  * Crumb Routing Operation (with help from Cory)
    ~ builds static routing tree to route to landmark (a designated mote)
    ~ crumb route is built from pursuer to the landmark
    ~ all packets routed to the landmark, then landmark routes to end
      of crumb route next to moving pursuer
  * Cory's code in SystemC/routing sits underneath the spanning tree stuff.
  * will talk to Naveen and look at code more to understand how code is 
    structured.  Then, will write documentation for it.
  * Conclusion from discussion with Cory: will have to hand modify each
    file to dump state variables over UART.
    ~ May have conflicts with radios using GenericComm when writing to UART
      just have to hope it doesn't matter too much.
    ~ Won't worry about bandwidth issues, since wire line is much faster than
      radio and mote operation


- Alec's Multihop Routing (Tanya)
  * Didn't get a chance to look at code, but read Alec's paper.  Will need to
    talk to Alec to sort out some details.  May not be able to code because
    working on Master's Thesis.
  * Alec's routing has a similar approach to Tanya's Beacon Routing work
  * Dynamic Link Estimation.  Maybe useful to dump link estimation information
    out of each node over UART.


- TinyDB (Mike)
  * seems to run as a separate application but can run in parallel with other
    applications (just wire in at Main.init())
  * very computationally expensive (according to paper... not sure how 
    expensive)
  * can query on low level components.  Not sure how it can be used to query
    on state variables in code of an existing application... probably can't 
    help here since this is not what it was designed for.
  * Mike will look into whether any of the existing GUI tools for TinyDB
    are easily modified for our own use.


- Simulation Environments (Bonnie)
  * a lot of information... look at the file simulation_comparison.txt for more
    details.
  * best use will be using simulation environment initially for code
    verification to catch bugs.
  * We will need to put in more work (changing their code) to be able to test
    different environment models.  Most do not support it natively (ex. 
    modeling sensors, sensing events, effects on sensing derived from sensor
    locations)
    ~ closest to supporting environment models is Tython.
  * TOSSIM still seems to be the best environment to work with of the three
    surveyed, for  our purposes. (others being EMSTAR and ATEMU)


- Surge (Bruno)
  * Bruno was not present.  Maybe next meeting.



- (Massimo) IPSN will be going on next Monday and Tuesday in the Sibley Aud.
  Please attend.

- Instructions for how to get PEGSensor to compile are now online (courtesy of
  Cory).


Directives:
***********
1) There are no general directives for everyone.  No software design doc was
   written after this meeting (ex. specifying parameter packet format for
   relaying back to the base station, if there is a canonical way of making
   function calls to dump data on the UART, etc.).
2) Suggestion: Tinker with some code!  Anything, so that we have a better idea
   next week on what everyone's role is in writing software to extract data
   from the network.