[Tinyos-2.0wg] Meeting Minutes - 2006/06/19

[Prabal Dutta]

-------------- next part --------------
T2WG Teleconference

Present: Phil Levis, Jan Hauer, Vlado Handziski, Kevin Klues, Philip
Huppert, Prabal Dutta, Martin Turon

Date: Wed, Jul 19, 2006

Notes: Prabal Dutta


pl: Kristin is on vacation.

pl: Prabal, do you have access to webs?

pd: Yes.

pl: I'll send you a pointer to change.

pl: TU Berlin, have you been reading the power monitoring discussion
on devel?

vh: Yes.  Eyes 13uA.  Using battery

pl: Which battery?

vh: Just using Li+ cell.  Not surprised to see values.  More HW on
Eyes than on Telos.  Some files have not been optimized.

pl: Values reported for T1 is 5uA.

vh: Bit-banged I/O to shut down peripherals on Eyes adds some
overhead.

pl: Quantifying the wakeup time with a scope would be a good idea.
Frequency and length of wakeup are also factor.

vh: Integrating the power profile would be interesting.

pl: Wonder why sleep current is so high?  Maybe there's a coating?

vh: Sent out notes on ADC mods.  Changes have been tested.  Feedback
welcome.

pl: My concerns.  Different ADCs/MCUs have different configuration
options, parameters, etc.  The new proposal has a chip-independent
interfaces but uses a typedef to pass chip-specific parameters to the
interface.

vh: Yes, I see where you're going.  Narrow vs. Wide typing.  But, it's
the same as message_t.

pl: Just moving the typing around.

vh: Could implement things though a variety of chip-specific
interfaces, but the pattern of using platform-neutral interfaces
coupled with typedefs for platform-specific options.

vh: The ADC driver cannot know the setup & hold time (requires knowing
the resistivity of the sensor).

vh: Should export volts, not counts, from the HIL.

pl: Does this mean that an ADC would need to measure battery voltage
as well, especially for a batteries that don't have cliffs?

vh: Yes, basically.

pl: Change config path so it's more portable?  Let people read over
the docs.  Jack Stankovic is the external reviewer, so let's see if we
can get an outside perspective.

vh: Outsiders may not want to dig this deep.  I went through all of
the old threads and this seems like we're actually converging rather
than diverging.

pl: Just saying that we should make sure there are no surprising
remarks or unforseen implications.  Community feedback is a good
thing.

vh: OK, but would also like to get feedback from our internal group.
Always pushing on the HIL for some critical functionality, but in the
final analysis, we really care about the physical voltage.

pl: OK, for next week, homework is to look at TUB's proposal.  David G
is out of town but might be able to provide 

pd: Should get Jonathan's feedback as well, if possible.

pl: TimerMilliC should be HilTimerMilliC.  TimerMilliC should be a
generic on top of that.

jh: Only one component provides local time.  Alarm?

pl: See CounterToLocalTimeC.

pl: For MSP, HilTimerMilliC is provided by chip, not platform (should
be moved).  Also, doesn't provide LocalTime.  Needs some cleanup.

pl: Martin, you're one of the authors.  Do you want to take a lead on
the cleanup?

pl: Martin?  Still there?

pl: Prabal?

pd: Yes, I'm still here.

pl: Good.  I just heard silence.  Sounds like Martin disappeared.

pl: Any other comments on the TEP?  Will ask Martin, Cory, ...

vh: Can we turn off all clocks?

pl: My assumption is that LocalTime is a continuously-running value
that doesn't stop when the counter is asleep.

vh: So, you'll always have to keep this clock on.  TimerMilliC
provides local time.  I know several platforms that don't have
external clocks that will make them unportable to TinyOS.

pl: What does LocalTime mean?

vh: In the TEP, should lower the expectation of the TEP.

pl: Maybe say component SHOULD provide LocalTime instead of MUST.

pl: Then, people can write apps assuming SHOULD and deal with the
exception when it occassionally doesn't provide it.

pl: Change topic to tinyos.net

pl: Does anybody have an account on tinyos.net?

...silence...

pl: If you have an account, you can update pages, etc.  Does anyone
want an account.

pd: Who's sort of "in charge" of it now?

pl: Nominally, Kristin.  Now, you just mail Kristin and she changes
it.

pd: What about giving WG members R/W access and let people just go and
change content?

vh: Could also set up groups (groups <-> WGs) and provide permissions
for members of subsections of websites.  Could make people responsible
for their own pages.  Key is to distribute workload, not make another
person responsible for the project.

vh: I'm not familiar with many open-source projects that allow users
to randomly submit issues to a bug tracking database.  Rather, we need
another level of filtering, to make sure bugs are real.  Don't have
time to test all bug reports to see if they are real or not.

pl: OK, so (1) clean out SF bug list, (2) users e-mail to a bug list,
(3) developers verify bug and the submit to an SF bug report to the
responsible developer.