[Tinyos-contrib-commits]
CVS: tinyos-1.x/contrib/rincon/apps/MeshCollect
readme.txt, NONE, 1.1 MeshCollect.h, NONE, 1.1 MeshCollectC.nc,
NONE, 1.1
dmm
rincon at users.sourceforge.net
Thu Jul 27 16:38:27 PDT 2006
- Previous message: [Tinyos-contrib-commits]
CVS: tinyos-1.x/contrib/rincon/apps/MeshCollect/core
MeshAnalysisM.nc, NONE, 1.1 MeshAnalysis.h, NONE,
1.1 MeshManagerM.nc, NONE, 1.1 MeshTransferM.nc, NONE,
1.1 MeshAnalysisC.nc, NONE, 1.1
- Next message: [Tinyos-contrib-commits]
CVS: tinyos-1.x/contrib/rincon/apps/MeshCollect/interfaces
RouteSelect.nc, NONE, 1.1 RouteControl.nc, NONE, 1.1
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Update of /cvsroot/tinyos/tinyos-1.x/contrib/rincon/apps/MeshCollect
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv18715/contrib/rincon/apps/MeshCollect
Added Files:
readme.txt MeshCollect.h MeshCollectC.nc
Log Message:
Added the MeshCollect component to CVS; Testing will continue on this component
--- NEW FILE: readme.txt ---
A demo app is provided in /apps/TestMeshCollect
Make sure your radio's ack's are enabled!
/**
* This Mesh Network component is based on MultiHopLQI, with updates:
*
* > Built on top of Transceiver, which provides a publically shared
* message pool that's application-wide and managed automatically.
*
* > QuickJoin functionality allows the mote to quickly
* connect to its surrounding network. QuickJoin is run when
* the mote is first turned on, and when it loses communication.
*
* > MultiHop and SingleHop Transceivers allow an application
* to either transmit data out to the base station through the network,
* or communicate directly with a nearby mote.
*
* > Collect message signatures allows an application to know for sure
* if a sent/received message is really a multihop message.
*
* > Increased simplicity by removing Snoop and Intercept - which does
* decrease functionality to some degree, but makes the overall component
* more of a no-brainer. The SinglehopTransceiver makes up for this somewhat.
*
* > Mesh Analysis provides the ability to find out how the network is doing.
* At the moment, custom implementation is involved to do anything
* useful with the locally heard or multihop collected analysis packets.
*
* > Multiple base stations are allowed, and it's easy to force a mote
* to be a base station at compile time by setting the FORCE_BASE_STATION
* preprocessor variable to 1
*
* > Ability to dynamically turn a mote into a base station mote and back,
* if you ever need that functionality.
*
*
* This is not a replacement for Drain, it's something a little different
* with its roots still more toward automated tree maintenance. I also
* changed some of the names and references from 'MultiHop' to 'MeshCollect'
* to emphasize the fact that we are not multihopping packets to and from
* any location in the network; we're specifically collecting data from the
* network and removing it using the base station node. I'm sure that's why
* Drain got the name it has as well.
*
* Some files were renamed from MultiHopLQI, but maintain similar functionality:
* MultiHopC became MeshCollectC
* MultiHopEngineM became MeshTransferM
* MultiHopLQIM became MeshManagerM
*
* According to Phil Levis's comments in TinyOS devel (6/8/2006)
* the history of this protocol goes something like:
*
* Berkeley:
* MHOP -> BLESS -> lib/Route -> lib/MintRoute -> lib/MultiHopLQI -->
* --> Drain
* --> MeshCollect
*
* So you see, Drain and MeshCollect are on two different branches from
* MultiHopLQI. Phil writes, "The change between MultiHopLQI and Drain was that
* Drain produces a static tree, which can be regenerated from the tree root,
* while MultiHopLQI, following the MintRoute approach, has a continuously
* updated tree."
*
* This component, MeshCollect, follows the MintRoute/MultiHopLQI approach
* in that the tree is continuously updated. It uses the same
* parent selection algorithms as MultiHopLQI. The QuickJoin functionality
* and deployment analysis were added after gaining experience from
* actual deployed networks, and the code was completely revamped to make
* it easier to debug and hack. Flexibility is provided by
* altering the compile time preprocessor variables.
*
* @author David Moss - dmm at rincon.com
*/
--- NEW FILE: MeshCollect.h ---
// $Id: MultiHop.h,v 1.5 2004/11/16 21:09:22 gtolle Exp $
/* tab:4
* "Copyright (c) 2000-2003 The Regents of the University of California.
* All rights reserved.
*
* Permission to use, copy, modify, and distribute this software and its
* documentation for any purpose, without fee, and without written agreement is
* hereby granted, provided that the above copyright notice, the following
* two paragraphs and the author appear in all copies of this software.
*
* IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
* DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT
* OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF
* CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
* ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO
* PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS."
*
* Copyright (c) 2002-2003 Intel Corporation
* All rights reserved.
*
* This file is distributed under the terms in the attached INTEL-LICENSE
* file. If you do not find these files, copies can be found by writing to
* Intel Research Berkeley, 2150 Shattuck Avenue, Suite 1300, Berkeley, CA,
* 94704. Attention: Intel License Inquiry.
*/
/**
* @author Philip Buonadonna
* @author David Moss
*/
#ifndef _TOS_COLLECT_H
#define _TOS_COLLECT_H
#include "AM.h"
/**
* The number of seconds between sending out a beacon update
* Increasing this number makes the network more volatile and
* able to adapt, but decreases battery life of the whole network.
*/
#ifndef BEACON_PERIOD_SECONDS
#define BEACON_PERIOD_SECONDS 30
#endif
/**
* The number of beacon messages that have to be missed
* from the parent before this mote is disconnected from
* the network and tries to QuickJoin again.
*/
#ifndef BEACON_TIMEOUT
#define BEACON_TIMEOUT 3
#endif
/*
* We can use a compile define to force a mote to become a base station
* which allows other mote ID's to play the role if necessary
*/
#ifndef FORCE_BASE_STATION
#define FORCE_BASE_STATION 0
#endif
/**
* Size of the queue that contains info about the last few messages
*/
#ifndef COLLECT_HISTORY_SIZE
#define COLLECT_HISTORY_SIZE 4
#endif
typedef struct TOS_CollectMsg {
uint16_t signature;
uint16_t sourceaddr;
uint16_t originaddr;
int16_t seqno;
int16_t originseqno;
uint16_t hopcount;
uint8_t data[(TOSH_DATA_LENGTH - 12)];
} TOS_CollectMsg;
typedef struct BeaconMsg {
uint16_t parent;
uint16_t cost;
bool requestReply;
} BeaconMsg;
enum {
AM_BEACONMSG = 0xFB,
};
enum {
COLLECT_SIGNATURE = 0xC011, // C011EC7 :)
};
#endif /* _TOS_COLLECT_H */
--- NEW FILE: MeshCollectC.nc ---
/**
* This Mesh Network component is based on MultiHopLQI, with updates:
*
* > Built on top of Transceiver, which provides a publically shared
* message pool that's application-wide and managed automatically.
*
* > QuickJoin functionality allows the mote to quickly
* connect to its surrounding network. QuickJoin is run when
* the mote is first turned on, and when it loses communication.
*
* > MultiHop and SingleHop Transceivers allow an application
* to either transmit data out to the base station through the network,
* or communicate directly with a nearby mote.
*
* > Collect message signatures allows an application to know for sure
* if a sent/received message is really a multihop message.
*
* > Increased simplicity by removing Snoop and Intercept - which does
* decrease functionality to some degree, but makes the overall component
* more of a no-brainer. The SinglehopTransceiver makes up for this somewhat.
*
* > Mesh Analysis provides the ability to find out how the network is doing.
* At the moment, custom implementation is involved to do anything
* useful with the locally heard or multihop collected analysis packets.
*
* > Multiple base stations are allowed, and it's easy to force a mote
* to be a base station at compile time by setting the FORCE_BASE_STATION
* preprocessor variable to 1
*
* > Ability to dynamically turn a mote into a base station mote and back,
* if you ever need that functionality.
*
*
* This is not a replacement for Drain, it's something a little different
* with its roots still more toward automated tree maintenance. I also
* changed some of the names and references from 'MultiHop' to 'MeshCollect'
* to emphasize the fact that we are not multihopping packets to and from
* any location in the network; we're specifically collecting data from the
* network and removing it using the base station node. I'm sure that's why
* Drain got the name it has as well.
*
* Some files were renamed from MultiHopLQI, but maintain similar functionality:
* MultiHopC became MeshCollectC
* MultiHopEngineM became MeshTransferM
* MultiHopLQIM became MeshManagerM
*
* According to Phil Levis's comments in TinyOS devel (6/8/2006)
* the history of this protocol goes something like:
*
* Berkeley:
* MHOP -> BLESS -> lib/Route -> lib/MintRoute -> lib/MultiHopLQI -->
* --> Drain
* --> MeshCollect
*
* So you see, Drain and MeshCollect are on two different branches from
* MultiHopLQI. Phil writes, "The change between MultiHopLQI and Drain was that
* Drain produces a static tree, which can be regenerated from the tree root,
* while MultiHopLQI, following the MintRoute approach, has a continuously
* updated tree."
*
* This component, MeshCollect, follows the MintRoute/MultiHopLQI approach
* in that the tree is continuously updated. It uses the same
* parent selection algorithms as MultiHopLQI. The QuickJoin functionality
* and deployment analysis were added after gaining experience from
* actual deployed networks, and the code was completely revamped to make
* it easier to debug and hack. Flexibility is provided by
* altering the compile time preprocessor variables.
*
* @author David Moss - dmm at rincon.com
*/
includes MeshCollect;
configuration MeshCollectC {
provides {
interface StdControl;
interface Transceiver as MultihopTransceiver[uint8_t id];
interface Transceiver as SinglehopTransceiver[uint8_t id];
interface Packet as MultihopPacket;
interface Packet as SinglehopPacket;
interface RouteControl;
}
}
implementation {
components MeshTransferM,
MeshManagerM,
MeshAnalysisC,
TransceiverC,
StateC,
TimerC;
StdControl = MeshTransferM;
StdControl = MeshManagerM;
StdControl = MeshAnalysisC;
StdControl = TransceiverC;
MultihopTransceiver = MeshTransferM;
MultihopPacket = MeshTransferM;
RouteControl = MeshManagerM;
SinglehopPacket = TransceiverC.Packet;
SinglehopTransceiver = TransceiverC.Transceiver;
MeshTransferM.RouteControl -> MeshManagerM;
MeshTransferM.RouteSelect -> MeshManagerM;
MeshTransferM.SubTransceiver -> TransceiverC;
MeshTransferM.SubPacket -> TransceiverC;
MeshManagerM.NormalBeaconTimer -> TimerC.Timer[unique("Timer")];
MeshManagerM.QuickJoinTimer -> TimerC.Timer[unique("Timer")];
MeshManagerM.BeaconTransceiver -> TransceiverC.Transceiver[AM_BEACONMSG];
MeshManagerM.State -> StateC.State[unique("State")];
}
- Previous message: [Tinyos-contrib-commits]
CVS: tinyos-1.x/contrib/rincon/apps/MeshCollect/core
MeshAnalysisM.nc, NONE, 1.1 MeshAnalysis.h, NONE,
1.1 MeshManagerM.nc, NONE, 1.1 MeshTransferM.nc, NONE,
1.1 MeshAnalysisC.nc, NONE, 1.1
- Next message: [Tinyos-contrib-commits]
CVS: tinyos-1.x/contrib/rincon/apps/MeshCollect/interfaces
RouteSelect.nc, NONE, 1.1 RouteControl.nc, NONE, 1.1
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Tinyos-contrib-commits
mailing list