(file) Return to README CVS log (file) Jump to this file's LXR Page (dir) Up to [CENS] / tos-contrib / motesync

File: [CENS] / tos-contrib / motesync / README (download)
Revision: 1.1, Wed May 10 18:01:24 2006 UTC (3 years, 6 months ago) by jhicks
Branch: MAIN
CVS Tags: pregeonet, acoustic-05-18-06, PRE_TOSNIC_FIX, PRE_64BIT, HEAD, CYCLOPS_RELEASE_CANDIDATE_2_0, CYCLOPS_PRERELEASE_STABLE, CENTROUTE_EMSTAR_SOCKETS, BG_1_0, AMARSS_JR_DEPLOYMENT_6_05_07
Initial documentation for the new motesync module used to timesync the motes
remotely.

MoteSync - 

Purpose:
        MoteSync is a router independent protocol made for direct communication
with a mote.  Current functionality only includes pushing time out to the mote
and, if desired, a response confirming the time update.  Time packets can either
be directed toward a single mote, or broadcast to all motes in range.  The
module is easily extendable to include additional functionality such as:
asking for current battery voltage, asking if the mote as a route to the sink,
etc.

Usage:
        To enable MoteSync on a mote, simply add MoteSyncC to your components
list in your main configuration file, and wire Main.StdControl to MoteSyncC.
Define the flag MOTESYNC_ENABLE_REPLY to enable the motes to acknowledge
packets.  Note that enabling replies uses an additional 60 bytes of RAM.
        To use MoteSync on your sink within EmStar, you must run the MSSink
application within EmTos, and the motesync application in devel/motesync.  The
motesync_sink.run file in devel/motesync/ gives an example (it is possible
to use the run file directly if desired).

Interface:
        The main external interfaces relate to the MoteSync routing protocol.
The routing protcol was written to seperate the mote side application from 
the underlevel dealings with sending and receiving packets:
  - MoteSyncSendI.MoteSyncSend: Used to send a packet out from the application 
    to the radio.  Takes in a pointer to data (which will be copied in a send 
    buffer), length of that data, a send to address, and the packet type 
    (defined in MoteSync.h).
  - MoteSyncSendI.MoteSyncSendDone: Signalled when the packet send process is 
    complete.
  - MoteSyncRecvI.MoteSyncRecv: Signalled upon the reception of a packet.  Header 
    is stripped off and pertinent information is sent in as parameters to this 
    event.

Functions:
        Here is a list of functions that will require modification to add 
increased functionality to MoteSync on the mote side:
  MoteSync.h:
    - Add your new type to the packet type struct.
    - Add one or more types to the state machine struct.
    - Add a packet struct defining your new packet type.
  MoteSyncM:
    - result_t process_msg: Add your new type to the case statement in this
      function.  Update the state machine to your specific state, and process
      the packet.  Start the reply timer is you need to reply back.
    - result_t Timer.fired: Add your new state to the case statement.  Reply
      as necessary.
       
        On the sink side, you will need to modify:
  motesync.c:
    - void motesync_unparse_pkt: Add your packet type to the case statement.  
      Here is where the packet is parsed out to the stream device.
    - void motesync_send: Add your packet type to the case statement.  Setup
      your packet, and add it to the send buffer.
    - int motesync_parse: Here is where the commands given to the command
      device are parsed out.  Add your commands and call motesync_send.
    - int motesync_handle_packet: Here is where a packet first gets into the
      sink code.  Parse out your packet data, and shove it off to pd_receive
      (which goes to motesync_unparse_pkt).


CENS CVS Mailing List
Powered by
ViewCVS 0.9.2