Commit b4434d36 authored by Robert Ricci's avatar Robert Ricci

A document on how e-motes are used in the testbed.

parent 473a8d50
Copyright (c) 2005 University of Utah and the Flux Group.
All rights reserved.
<h1>Motes on E-Motes</h1>
<li> <a href="#INTRO">Introduction</a>
<li> <a href="#HARDWARE">Hardware</a>
<li> <a href="#SPECIFICATION">Specification in NS Files</a>
<li> <a href="#PROGRAMMING">Programming Motes</a>
<li> <a href="#SERIAL">Serial Consoles</a>
<li> <a NAME="INTRO"></a>
The <a href="/tutorial/mobilewireless.php3">mobile wireless testbed</a>
includes two static nodes hosted on
<a href="">E-Mote</a>
Ethernet gateways. This document describes how these devices fit into the
larger Emulab system.
<li> <a NAME="HARDWARE"></a>
The static motes in Utah's emulab are hosted on E-Motes. E-Motes (also known
as the MIB600CA) from <a href="">Crossbow</a> provide three
key features:
<li>They have a power supply that comes from the power grid, so there is no
need to worry about battery life on the attached mote.</li>
<li>They provide the ability to reprogram the attached mote over Ethernet -
thus you don't need to worry about wedging your motes, we can simply
reprogram them to recover them to a known state.</li>
<li>They export the mote's serial console to a TCP port. This opens up
several possibilities. First, it means that you can use any of them as base
stations to gateway between the Internet and your mote network. Second, it
provides a back channel over which to send commands to the motes or extract
data from them.</li>
The overall goal of the second two features for us is to provide something
analogous to our PCs'
<a href="/tutorial/docwrapper.php3?docname=tutorial.html#ControlNet">control
<h3>Specification in NS Files</h3>
Since motes in Emulab are hosted on other nodes such as E-Motes and Stargates,
you must specify two nodes in your NS file: the mote itself and its host. A
mote specification in your NS file may look something like this:
<blockquote style="border-style:solid; border-color:#bbbbbb; border-width: thin">
set inky [$ns node]
set inkyhost [$ns node]
tb-set-hardware $inky mica2
tb-set-hardware $inkyhost motehost
tb-fix-node $inky $inkyhost
tb-set-node-os $inky TinyOS-CntRfm
This code asks for a Mica2 mote, which we name <code>inky</code>, and places it
on a host called <code>inkyhost</code>. By giving the generic type
<code>motehost</code>, we are saying that we don't care what this mote is
attached to. If we wanted an e-Mote, we could have set the type to
<code>emote</code>, or <code>garcia</code> if we wanted it hosted on a robot.
The <code>tb-set-node-os</code> command sets the image to be loaded on the node
- we'll cover that in the next section.
If you want to get a specific mote, use the <code>tb-fix-node</code> to fix the
mote's host. For example, if we wanted to put <code>inkyhost</code> on the
emote named <code>em1</code>, we would use <code>tb-fix-node $inkyhost em1</code>.
<li> <a NAME="PROGRAMMING"></a>
<h3>Programming Motes</h3>
Uploading your own code to run on the motes is easy. Just build your TinyOS app
normally (ie. '<code>make mica2</code>'). Then, upload the binary that gets
placed in <code>build/mica2/main.srec</code> to our
<a href="<?php echo $TBBASE ?>/newimageid_ez.php3?nodetype=mote">mote image
creation page</a>. This page will ask you for a 'descriptor'. This
descriptor can then be used in <code>tb-set-node-os</code> lines in your
NS files, and your app will be automatically loaded on the appropriate mote(s).
At this time, we don't have a TinyOS installation on the Emulab servers, so
you'll need to have a TinyOS installation to build from on your desktop
machine, or some other machine you control. We hope to provide a way for you
build TinyOS apps on Emulab in the near future. Also, at the current time, all
of our motes have radios in the 900MHz band, so see the TinyOS
<a href="">CC1000
radio document</a> to make sure you're tuning the radios to the right band.
When you inevitably make changes to your code, you can simply place the new
kernel in the path that was automatically constructed for you by the image
creation page; the next time you use that OS in an NS file, the new version
will be loaded. If you'd like to load your node code onto your motes without
starting a new experiment, you have two options:
<li> <code>os_load</code> allows you to load an kernel that has already been
defined as an image, as above. You give it the image descriptor with its
<code>-i</code> argument, and you can either give the physical names of all
motes you want to reload, or a <code>-e pid,eid</code> argument to reload
all nodes in the given experiment.
<li> <code>tbuisp</code> allows you to load a file directly onto your motes
without having to register it as an image. This can be a quick way to do
development/debugging. Just pass it the operation <code>upload</code>, the
path to the file you wish to load, and the physical names of your motes.
Both of these are commands in /usr/testbed/bin on They are
also available through our
<a href="<?php echo $TBBASE ?>/xmlrpcapi.php3">XML-RPC interface</a>, so you
can run them from your desktop machine to save time - the file given as an
argument to tbuisp is sent with the XML-RPC, so you don't need to copy it onto
our servers.
<li> <a NAME="SERIAL"></a>
<h3>Serial Consoles</h3>
The serial consoles on your motes can be reached by connecting to TCP port
10002 of the E-Mote. You can do this, for example, with <code>telnet</code>, or
with the TinyOS SerialForwarder program. The E-Mote is configured to talk to
the mote at 57600 baud.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment