]> oss.titaniummirror.com Git - tinyos-2.x.git/blobdiff - tos/lib/net/blip/doc/README
Merge TinyOS 2.1.1 into master.
[tinyos-2.x.git] / tos / lib / net / blip / doc / README
diff --git a/tos/lib/net/blip/doc/README b/tos/lib/net/blip/doc/README
new file mode 100644 (file)
index 0000000..8ae52d2
--- /dev/null
@@ -0,0 +1,94 @@
+
+ @title blip documentation
+ @author Stephen Dawson-Haggerty stevedh@eecs.berkeley.edu
+ @release public
+---------------------------------------------------------------------
+
+ 1. Installation
+
+ - This is only going to work on linux.
+
+ - The recommended version of TinyOS is a recent CVS checkout.  This
+   is necessary for appropriate radio stack support.
+
+ - Make sure the c serial tools are built in
+   $TOSROOT/support/sdk/c/sf.  You may need to run ./bootstrap,
+   ./configure, and make in that folder to generate libmote.a.
+
+ 2. Building
+
+ - Build a test app:
+      * cd to $TOSROOT/apps/UDPEcho/ and try typing `make <platform> blip`
+ - Build the Ieee802.15.4 bridge to your computer
+      * cd to $TOSROOT/apps/IPBaseStation/ and `make <platform> blip`
+ - Build the driver 
+      * cd to $TOSROOT/support/sdk/c/blip
+      * run ./bootstrap
+      * run ./configure
+      * run make
+
+ 3. Running
+
+ - Install IPBaseStation on a mote.  This will be your
+       computer's interface to the world of low-power radio.  Setting
+       the node id and channel is not important-- these settings will be
+       overwritten.
+
+ - Start the driver (once you've built it)
+      * cd $TOSROOT/support/sdk/c/blip
+      * edit the config file $TOSROOT/support/sdk/c/blip/serial_tun.conf
+         * set 'addr' you would like your computer's interface to use on the PAN
+         * leave 'proxy' set to 'lo'
+      * sudo driver/ip-driver /dev/ttyUSB0 telosb
+           (replace the device and baud with whatever you're using)
+   The config file is assumed to be in the CWD when ip-driver starts;
+       if this is not the case it may be specified using '-c <config file>'
+
+ - The driver registers itself on the fec0::/64
+       subnet (or whatever you have specified in the config file).
+
+ - If you program a few motes with UDPEcho, their addresses are formed
+       with octets 15 and 16 of the IPv6 address comming from the
+       802.15.4 short address you programmed them with.  Octets 9-14
+       are zero, so the address formed is:
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |  network prefix       |     zero        | id  | 
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+       ICMPv6 DAD is not performed.
+
+ - For instance, if you program a mote with ID 101 (0x65), you can try
+       ping6 fec0::65
+       tracert6 fec0::65
+       nc6 -u fec0::65 7
+       nc6 -u fec0::65 2000
+       
+       UDPEcho runs an echo service on port 7, and a simple shell on
+       port 2000; type 'help' for a list of commands.
+
+ - The motes can also report back statistics every 15 seconds over
+       UDP.  They will send these reports to an address specified in the
+       application make file; however these reports are disabled by default.
+       You can observe these statistics using the Listener.py
+       script in $TOSROOT/apps/UDPEcho/: `python Listener.py`.
+
+ - The driver provides a simple console when running, which allows you
+       to inspect and manipulates routes, and view statistics.  The
+       console runs as a telnet service on port 6106.
+
+ - A good way of understanding what is happening is to start wireshark
+       on tun0; you should be able to observe the neighbor discovery
+       process as motes boot.  You may also notice messages sent to
+       ff05::1; these are routing updates.  They are sent from a
+       binary exponential timer with a maximum period of 5 minutes to
+       inform the router of mote's presence; however, they are
+       suppressed by data traffic since the routing updates will be
+       piggybacked on it.
+
+ - Further reading: doc/ contains a numbers of README's related to
+       pieces of blip such as the socket interface, the shell, and
+       network programming support.  For more technical details on
+       IPv6, please see any reference on the subject.  Many of the
+       documents produced by the IETF ROLL and 6lowpan working groups
+       are relevent to this design space.