Delta Application...

modified boomerang Delta application...
(voltage, humidity & temperature)
----------------------------------------
CommunicationsMoteiv’s communication system includes three main components: a Multihop mesh networkingprotocol, a network duty cycling protocol, and the recently proposed “Sensornet Protocol” (SP)abstraction for sending and receiving messages. All of these protocols are used in Moteiv’smesh networking application, Delta.

Multihop Networking
Moteiv’s on-demand ad-hoc networking utilizes spatial and temporal redundancy to reliabilitydeliver messages across a network to their destination. To use the Multihop library in anapplication, first include Multihop in your configuration:

• component Multihop;

Then wire your application to the appropriate message handlers for your message type. Forexample, in your configuration:

• AppM.Send -> MultiHop.Send[APP_ID];
• APPM.Receive -> MultiHop.Receive[APP_ID];

Where APP_ID is a unique 8-bit identifier for your service or application defined in a header file.Please see the documentation for details of using the Send interface in Moteiv’s APIdocumentation available at /opt/moteiv/docs/nesdoc

Messages are submitted to the Multihop service and queued until there is an opportunity toroute the message towards the destination. After a message is successfully sent, an event(Send.sendDone()) is fired to your service notifying you that it is now safe to use themessage buffer for other purposes.

Low Power Operation
Moteiv’s software includes a synchronization protocol for low power wireless network. Thenetwork duty cycling approaches uses SP (described below) for establishing and maintaining aschedule whereby the entire network wakes up together and then returns to sleep.

Including Moteiv’s network duty cycling is as simple as adding a single parameter to thecompilation command. Simply add the lowpower keyword after the compilation platform. Forexample:

• make tmote lowpower

Try the low power networking by using Delta, the mesh networking data collection application,with the lowpower option:

• cd /opt/tinyos-1.x/contrib/boomerang/apps/Delta
• make tmote lowpower

Be aware that bandwidth is very limited in low power mode (each node is only awake for a fewmilliseconds every two seconds). The initial synchronization of the network may require up to15 minutes to stabilize, but will reliably report data after the initial setup phase. Please bepatient!

Information about Moteiv’s network duty cycling is included in the API documentation for theNetSyncC and NetWakeC components. The source is at /opt/moteiv/tos/lib/netsync;however we strongly recommend that only the most advanced users consider modifying thiscode. Please note that Moteiv does not support any modifications to our source.

Sensornet Protocol (SP)
SP is a unifying link abstraction for running network protocols over a variety of link layer andphysical layer technologies without changing network protocol implementation. SP isimplemented by the SPC component.

SPC and its interfaces are described in detail in the following publication:A Unifying Link Abstraction for Wireless Sensor NetworksIn Proceedings of the Third ACM Conference on Embedded Networked Sensor Systems(SenSys), November 2-4, 2005.
http://www.polastre.com/papers/sensys05-sp.pdf

Messages are transmitted using the SPSend interface and message futures are handledthrough the SPSendNext interface. To send a message on a particular AM type, such as AMtype 5, wire your network protocol to SPSend[5]. The SP message pool will hold on to amessage and its corresponding packets until it may be sent over the channel.

Fields of each SP message (sp_message_t) should never be directly accessed. Instead, theycan be set using the parameters of the SPSend interface. Reading parameters should be donethrough the SPMessage interface.

Reception is on a per packet basis (not a per message basis like SPSend). Packets areimmediately dispatched to higher layer services based on AM type. SPReceive providesinformation about each packet, including a token that identifies which interface a messageoriginated.

The SP Neighbor Table is accessed through the SPNeighbor interface. Users must wire to theSP Neighbor Table with the parameter unique("SPNeighbor"). Each service has its ownidentity for controlling the insertions, removals, and changes of entries in the SP NeighborTable. See the SPNeighbor interface in the API documentation for more information.

Various utilities as part of SP's processing are available in the SPUtil interface. These utilitiesinclude link estimation functions and link post-arbitration time stamps.

- moteiv corp -