Date: Fri, 12 Apr 2002 10:37:57 -0700
From: David Culler
To: vraghavan
CC: [ list ]
Subject: Re: Sensor Boards
Sensor boards are finally rolling off the line. They are going to come in waves
due to part availability. We have the first set of boards with light, temp,
acoustic, magnetometer, and accelerometer ready. They don't have a sounder,
because that is still being built overseas.
We need to get the contact person associated with each kit nailed down. If you
think you are the contact person for a kit, send mail to shanah@cs.berkeley.edu
giving your contact info and identifying which group you represent. We'll cross
check that against the record from the PI meeting to hopefully get a solid list
that we can push things out to as the sensor boards come in. In this first set,
full kits will receive 8 sensors, half kits will receive 4.
From: Alec Woo
To: minitasks@millennium.berkeley.edu
Date: Tue, 2 Apr 2002 00:17 EST
Subject: [minitasks] March 22nd teleconf notes
Participants:
Berkeley, Memphis, Notre Dame
Summary:
As the first step, we narrow down the problem definition into three
basic communication problems: many to one, one to many, and many to
many. "Many to one" describes the scenario where nodes propagate data
to a node with more capability such as a base station. "One to many"
is basically a flooding mechanism where a node needs to disseminate a
piece of information to the entire network. "Many to many" involves
the gossiping problem where n nodes need to talk with k nodes.
For all three scenarios, we assume nodes lie on a 2D plane and only
communicate using a single radio channel. There is a probability
distribution of connectivity p(i,j) between node i and j, where p(i,j)
may not equal to p(j,i) and this probability distribution is some
function of distance rather than using a binary circular disc approach,
with p(i,j) = 0 if distance > radius and p(i,j) = 1 if distance <=
radius. For simplicity, we start with a distribution such as Gaussian
that is convenient to work with. However, the problem becomes more
complicated when we take into account power cycling the radio for
energy conservation since p(i,j) = 0 if j's radio is off. Now, the
classic scheduling/coloring problem has to work with a connectivity
graph, which is not only stochastic but also changes over time. The
multi-hop nature also intermixes scheduling with routing, as nodes need
to turn on the radio in order to route traffic. Potential goodness
metric may include transmission frequency derived from the transmission
schedule and the overall energy cost for data delivery.
On the "many to one" scenario, the scheduling needs to take into
account the multi-hop capacity of the network since all traffic flows
to the single destination and routers close to that will be congested.
The global schedule of transmission should rate limit nodes to avoid
congestion and such global schedule should be derived only using local
rules.
Some work on the "one to many" scenario using the simplest epidemic
flooding has been down here in Berkeley. The overall result reflects
that collision is a dominant effect. We also discussed using a
randomized approach to solve the problem. How many nodes can be
covered if everybody randomly transmits and receives over a period of
time? We expect there probably exists a phase transition.
As a starting point, we can assume node's position are fixed and time
are synchronized up to some degree since localization and time
synchronization problem are not solved completely yet. We can relax
things in the future by making time synchronization and location
estimation probabilistic. For now, we can also assume cell coverage is
a circular random cell.
Related reading can be found in www.cs.berkeley.edu/~awoo/discovery/
Date: Tue, 26 Mar 2002 15:50:03 -0500
From: Robert Laddaga
To: vraghavan , Alex Meng
CC: Howie Shrobe , Brian Charles Williams ,
Jonathan Bachrach , Doug Dodds
Subject: Re: NEST Baseline demonstration
Vijay:
Sorry to be a little late with this. The revised document is attached.
Bob
vraghavan wrote:
>
> Hi everybody,
> [...]
> Please remember, the baseline demo is your chance to show off your stuff
> in the best possible light, to create the best impression.
>
> Shall we say Monday, March 25, as a new deadline for the revised report?
>
> -- Vijay
Demo Description
(MS Word version)
Date: Wed, 20 Mar 2002 18:53:15 -0600
From: Akos Ledeczi
To: vraghavan
CC: [ list ]
Subject: Graphical Development Environment for TinyOS
Announcing the availability of
GRATIS
Graphical Development Environment for TinyOS
GRATIS v0.6, a Graphical Development Environment for TinyOS,
is a fully functional sophisticated environment for the
visual development of TinyOS-based applications. It is based
on the Generic Modeling Environment (GME 2000), a configurable
modeling and code generation environment also developed at ISIS.
GRATIS enables the user to graphically create TinyOS components,
specify their command and event interfaces, wire components
together and then automatically generate the corresponding
.comp and .desc files along with a skeleton of the C
implementation.
The code generator component, written in Python, is bidirectional,
that is, it is able to parse existing TinyOS source trees and to
automatically generate the corresponding GRATIS models. The
sophisticated constraint management capabilities of GME 2000,
along with the error checking built into the Python code, make
sure that many common errors are caught during the model building
phase. The current TinyOS tools are not able to catch all of
these problems. In fact, using GRATIS we found some minor
inconsistencies in the current TinyOS release (v0.6).
GRATIS is freely available from
http://www.isis.vanderbilt.edu/projects/nest/gratis
Note that you need to have the latest GME 2000 release installed
on your machine before being able to use GRATIS. GME 2000 is
available freely from
http://www.isis.vanderbilt.edu/projects/gme
The GRATIS release includes the modeling paradigm to configure
GME 2000 for GRATIS support, the Python model interpreter and
the parsed version of TinyOS v0.6.
*********************** IMPORTANT ***********************
GME 2000 (and GRATIS) is a sophisticated environment with a *STEEP*
learning curve. Please, read the README file, available in the
release and the web site, carefully. Also, it might be a good idea
to look at the short tutorials available in the GME 2000 release
to familiarize yourself with GME 2000 concepts.
*******************************************************************
Akos Ledeczi
Senior Research Scientist
ISIS
Vanderbilt University
From: vraghavan
To: [ list ]
Subject: RE: NEST Baseline demonstration
Date: Mon, 18 Mar 2002 10:56:56 -0500
Hi everybody,
I have gone through all your descriptions of baseline demonstrations with
Alex Meng of Mitre. I would like to iterate through this once more, because
I am not completely satisfied with what I have received. I hope that you now
have acquired some experience with the motes and will therefore find my
suggestions for revision easy to accommodate.
My single biggest whine is with the evaluation metrics. You have to make
the metrics more concrete, i.e., quantifiable. Please say what it is that
you will be measuring, giving units and unless it's perfectly obvious, a
definition of the quantity that's being measured. For example, "impact of
degree of parallelism" is not a well-defined metric, but one can think of
ways to make this concrete. I realize that certain things are inherently
difficult to measure (for example, "level of application-independence" or
"ease and naturalness of coding basic operations") and here I would suggest
using some indirect metrics to gauge these entities (for example, "level of
application independence" may be estimated by key performance metrics in
different applications using the same package and comparing that against the
performance of application-dependent software).
Basically, what I am looking for is a tangible relationship between your
stated objective(s) and the evaluation metrics. If your objectives say that
you are providing technology X for NEST, then the metrics should be a list
of measurable entities that will provide a many-one map to the objectives;
i.e., I should be able to use the metrics to justify that the technology X
has been successfully provided (or not). If you need to provide more than
one metric to arrive at an intelligent evaluation of X, so be it.
Another aspect of the demo is that it should be easily reproducible. You
will be asked to send your entire demo software to Mitre in a manner that is
easy for them to run, collect data, and do more of an in-depth evaluation
than may be possible during the PI meeting. For this reason, try to stick to
the hardware that is available to all. In other words, minimize the use of
your own set of specialized robots, sensors/actuators, etc in the demo.
Finally, make sure that your demo is aligned to the Berkeley challenge
problem. One should be able to see the connection of your demo to the
challenge problem as a whole; it is for this reason that you were asked to
articulate this relationship and say what, in your opinion, are the missing
links. The hope is that the union of all the pieces that are provided will
be composable to get at the challenge problem.
Please remember, the baseline demo is your chance to show off your stuff
in the best possible light, to create the best impression.
Shall we say Monday, March 25, as a new deadline for the revised report?
-- Vijay
From: vraghavan
To: [ list ]
Subject: NEST Baseline demonstration
Date: Mon, 25 Feb 2002 09:28:54 -0500
Dear all:
As discussed in the PI meeting that just concluded, we will
have a day of baseline demonstrations at the next meeting. All the teams
that received a kit of motes (50 or 100) are required to do this
demonstration. Also, as discussed in the meeting, you should provide a
clear, 2-page specification of your demonstration by March 1. To help you
along, I am attaching a Word document to serve as a guideline.
Best,
-- Vijay Raghavan
PS. I apologize for the somewhat scattershot mailing. Despite my
pruning, not everyone who receives this may need to do a baseline demo.
NEST Demo Day Description Template
(MS Word version)
Subject: IMPORTANT NEST MOTE update...
Date: Thu, 21 Feb 2002 14:21:20 -0800
Thread-Topic: IMPORTANT NEST MOTE update...
Thread-Index: AcG7Jod+Rr+jN3Q7SgicoEgCPWCdew==
From: "Jason Hill"
To: [ list ]
RX sensitivity update.....
There is another update to help with RF connectivity. Stefan Bartok
from vanderbilt noticed that RF reception sensitivity decrease after the
first packet transmission. This resulted in a significant decrease in
transmission range in multi-hop applications.
The fix: update tos/platform/mica/SPI_BYTE_FIFO.c
Get the new version from:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tinyos/nest/tos/platform/mica/SPI_BYTE_FIFO.c
The original update was to:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tinyos/nest/tos/system/POT.c
Jason
Date: Fri, 15 Feb 2002 18:21:55 -0800
Subject: NEST Berkeley OEP software updates.
From: "Jason Hill"
Thread-Topic: NEST Berkeley OEP software updates.
Thread-Index: AcG2kLIfbaFq+QDES+Wi5QNKMFKi7g==
To: [ list ]
This message is intended for those working with the Berkeley NEST open
embedded platform:
Periodically, we will need to send out software updates. Please email
me the person in your organization who should receive these updates. I
will establish a mailing list for this purpose.
Secondly, we already have our first minor BUT IMPORTANT update.
There is a new version of POT.c in sourceforge that will greatly improve the communication range
for MICA nodes. At Berkeley, we see roughly a 10x improvement in range.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tinyos/nest/tos/system/POT.c
Thanks,
Jason Hill