[Tinyos-2.0wg] blocking items for 2.0 release
Joe Polastre
joe at polastre.com
Wed Aug 2 20:33:33 PDT 2006
Low power is extremely challenging, and if you stall on the low power
stack you may never release 2.x. Until the system is in long term
deployment, it is hard to gauge that the low power stack is actually
working correctly (trust me, this is one of those things you wish
would go right but 7 days down the road results in a different power
state).
If you want an HIL for power management for radios, SP is the way to
go, even if you don't agree with all the bits/flags. I was unable to
build an effective low power implementation without SP. With SP in
place, writing a low power protocol was amazingly easier, and has
proven true for our customers as well.
My perspective is that all platforms should be low power, not just
CC2420, and if you simply solve the CC2420 problem, you're just
delaying the inevitable. I also agree that TinyOS without power
management is fairly useless.
You're welcome to use Moteiv's SP and low power protocols under the
Moteiv license, most of which are 2.x compatible with some tweaks.
Certainly that would save you time.
Other notes:
TEP 122 isn't committed to the tinyos-2.x CVS so its hard to review.
Seems like it is reinventing IEEE EUI and I'm not convinced of its
necessity.
-Joe
On 8/2/06, Philip Levis <pal at cs.stanford.edu> wrote:
> In the call today, David C. noted that we should try to remove the
> blocking items for a 2.0 release in order to keep it on track. Here's
> the current list of things that we've so far agreed are needed for 2.0:
>
> Deluge
> Surge-like app
> Sensor board support
> Completed tutorials
> Power management for virtualized devices (low power CC2420?)
> - HIL power management for the radio
> Radio metadata
> Test/evaluate that power management works and doesn't have gotchyas
> (so far seems fine)
>
> Bonus items:
> Security
> Test suite
>
> For the most part, a lot of this just involves writing code. I have a
> student working on a Surge-like app, and should have some updates
> soon. Kevin has been evaluating power management, and it sounds like
> will soon be able to check in the arbitration updates. I will prod
> Martin about sensor boards for the mica family. The really big ones
> that nobody has actively picked up are:
>
> Top-half of Deluge (large-item dissemination): this might be in
> net2's camp, but I don't know who in net2 will do it. I'm currently
> firing cylinders on collection, and that's where a good deal of the
> effort is. This will require someone stepping up to the plate to
> drive it forward. I think that person will be able to get help, but
> it needs a leader.
>
> A low power radio stack for the CC2420. I'm not sure if I'm really
> comfortable with releasing 2.0 unless we have demonstrated that it's
> possible to implement a reasonable low-power solution on the CC2420
> with the current interfaces, given how heavily used the chip is. Push
> comes to shove, we may have to release without it, but that seems
> like a bad idea...
>
> It would be good to get updates on the status of a few TEPs:
>
> 105: David, do you have a timeline for getting a draft to the group?
> 109: Gil and David, this is a blocking item for Crossbow to make
> progress on sensor boards
> 122: What's the status on the unique ID TEP? Haven't heard much since
> the initial round of comments.
>
> I chatted with Rodrigo today, and the net2 group is producing another
> Documentary TEP, TEP 123, on collection protocols. The tentative
> names are CTP (collection tree protocol) and RCTP (rooted collection
> tree protocol), but those are very likely to change.
>
> Phil
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
More information about the Tinyos-2.0wg
mailing list