Wireless sensing was named one of the Top 25 ideas to ever emerge from the state of California by California Magazine as selected by the faculties of UC Berkeley and UCLA. Also included in the list are Google, the Simpsons, low-energy lightbulbs, and computer generated imagery (CGI). The article mentions our colleagues (and former advisors) from UC Berkeley and UCLA. Both motes and TinyOS are mentioned as technologies invented here in California.
Read the article at California Magazine >>
Last week wireless sensors were also touted by Business 2.0 and CNN as one of the "Top 8 Technologies to Save the World". Also of interest is nuclear waste neutralizers, which are featured as one of the other 7 technologies. The technologies promise to make the world a better place, while making entrepreneurs "green" too.
8 technologies to save the world >>
 |
Moteiv announces the release of Boomerang 2.0.4 that includes numerous bug fixes and additions from the previous Boomerang releases. Notable changes in 2.0.4 include:
- New applications including a Remote Control using Tmote Invent
- Lower power consumption and active energy monitoring
- New dissemination protocol for data buffers (Spram)
- New Tmote drivers, motelist, and bootstrap loader for increased robustness
- Updates to match TinyOS 2.x interfaces and TEPs
- Bug fixes and performance improvements
For a full list of changes, view: http://www.moteiv.com/community/Boomerang_ChangeLog
Boomerang can be downloaded for free from Moteiv
|
Last year, I published a paper in Sensys about A Unifying Link Abstraction for Wireless Sensor Networks. I also wrote a dissertation on the subject. This link abstraction, that I called SP or Sensornet Protocol, is the primary communications abstraction in Moteiv's Boomerang product.
Since writing two implementations of SP, a number of network protocols, and investigating different link layer technologies, I have some observations about the usefulness of each of the concepts presented in the original paper. In this entry, I will summarize what I've found useful, what is probably not necessary, and what I'd like to see in the future.
- Message Pool. The message pool has been invaluable for storing messages until a later point in time that they can be sent. It decouples the power management policy from the data transmission policy, which in turn means you can submit a message whenever you want and it will go out on the radio.
- Message Futures. Due to the decoupling above, message futures are necessary if you generate more than one message per power cycle. Keeping a queue (we use cqueue by Cory Sharp) in the networking protocols allows each protocol to decide how deep the queue is and how to prioritize it. This can also be accomplished with a buffer pool that network protocols share and extract buffers when needed.
- Neighbor Table. Moteiv doesn't use the Neighbor Table for storing link estimates, instead we've found its usefulness in maintaining power schedules. The
neighbor table makes it easy for the link to either insert schedule or
the network protocol (such as NetSync and NetWake in Boomerang) to add
other schedules.
One shortcoming--We will be changing the interface to comply more with TEP102 for timers. Currently the neighbor table takes a 32-bit absolute time for turning the radio on and off. Because TinyOS is not real-time, delays can cause an event to be missed, and lead to 36-hour delays (32-bit rollover)! The solution is the TEP102 proposal for Alarms--use t0 and dt to specify the next wakeup interval. This then couples nicely with the Timer/Alarm system and makes the overall implementation easier. - Link Estimation turns out to be a bit of bust because you can't do it very well in an application-independent manner. Jack Stankovic pointed out at one of our meetings that different applications have different opinions on what a high-quality link is. Cost-based routing is one thing, but geographic or sensor-based routing has different requirements. Link estimation in the base case doesn't have to be fancy, nor does it have to give me "real units" like dBm or PER, relative link estimates are just fine for all the protocols we've encountered.
- Reliability. I don't care how you implement reliable transport at the link, but you need to give protocols the option to ask for reliability and get feedback as to whether the reliability was achieved. This point should be obvious, but it is absolutely critical for us to have bi-directional reliability data to make informed decisions about what to do with the next message.
- Timestamping. I've never figured out why Timestamping is not a core piece of metadata available with each packet in the default implementations of TinyOS. It is trivial to provide a timestamp either on an SFD, or when SFD isn't available, on the packet dispatch. Sure, it won't be 100% accurate, but with a 30.5us clock it doesn't really matter. The #1 best addition to SP in Boomerang was timestamping, and has served us very well.
- Naming. This is an overrated topic. We initially thought we were going to implement Arsalan's SP handle idea, where each link address is given a virtual handle for network protocols to use to decouple the link address (size, interface, type, etc) from the network decisions.. Then we starting looking at the realities of the situation and decided that, in practice, it was never going to be needed and could easily be pulled in if we needed it at a later date. There was no point confusing users with a handle when they're still trying to figure out what "address" means.
- Congestion. Clearly this isn't completely important from a practical perspective. From a research/academic perspective it was quite fascinating to see we could build some congestion control schemes that had basic working properties in a platform/link independent manner. I still am fascinated by that, but practically speaking--our motes are off most of the time and our goal is to do as little data transfer as possible, so 99.9999% of the time there is no congestion.
- Phase/Delay feedback. Not necessary with the message pool decoupling transmission from the network protocols. David Culler and I initially thought that this was a requirement for the decoupling, but experience with SP has shown that the message pool can do an effective job of the decoupling without complicating the other protocols with additional phase/delay feedback.
- Urgent. I think this is somewhat useful and doesn't need to have more than 1-bit of information. There's a number of papers out there, including one from Stankovic, that talk about how 1-bit of information can provide effective prioritization of network traffic. Arbitrary numbers of priority levels, in my opinion, are complex and aren't required by any existing protocols. The wireless sensor system is supposed to work together--if you are worried about resource constrained systems fighting internally with themselves, you're probably developing your application incorrectly.
- Abstract data types. The initial version of SP required you to specify the fields in the message structure itself by directly accessing them. Phil Levis was right in complaining that it led to a lot of programmer error. In SP in Boomerang, we moved to a system where we explicitly prohibited users from editing any of the fields of an sp_message_t structure. Instead, you set fields using the SPSend.send() and SPSend.sendAdv() commands, and access fields through the SPMessage interface of SPC. This is a much safer implementation and has reduced the number of headaches that we encountered in the initial implementation of SP for the Sensys paper.
- Receive. We completely threw out the TinyOS method of Receive where you must return a message pointer and we introduced a new interface, SPReceive, that can fan out to as many protocols as you need. This has been a time and bug saving development. The notion is the following: If you need data in the received message, you must copy or do something with it before returning from the SPReceive.receive() function. The buffer passing mechanism of ReceiveMsg in the main TinyOS distribution, although novel in principle, just wasn't used in practice.
To summarize:
Critical to support: Message pool, message futures, neighbor table schedule information, reliability control and feedback, timestamping, abstract data types and non-direct accessing of structure field, non-buffer passing receive interfaces
Don't get too caught up with: Link estimation, Urgent/Priority
May not be completely useful: Congestion, Naming
Haven't found a need for yet: Phase/Delay feedback
|
Somehow I missed this article in Sensors Magazine written by my former advisor, David Culler. David discusses TinyOS, how it is composed, and some architectural decisions made when moving to TinyOS 2.0.
Boomerang, Moteiv's distribution of TinyOS, is a combination of TinyOS 1 and TinyOS 2, enbling backwards compatibility for old TinyOS 1 applications while leveraging the robustness and new abstractions from TinyOS 2 where possible.
http://www.sensorsmag.com/sensors/article/articleDetail.jsp?id=324975
|
Chad Metcalf has updated his guide for using Moteiv's Tmote modules on Ubuntu. The recent update covers how to get Boomerang working. You can check out Chad's guide at his website:
http://www.chadmetcalf.com/tinyos-1x-on-ubuntu/