Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Emotes


Motes on E-Motes

Motes on E-Motes


he mobile wireless testbed includes two static nodes hosted on E-Mote Ethernet gateways. This document describes how these devices fit into the larger Emulab system.


The static motes in Utah's emulab are hosted on E-Motes. E-Motes (also known as the MIB600CA) from Crossbow provide three key features:

  1. 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.
  2. 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.
  3. 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.

The overall goal of the second two features for us is to provide something analogous to our PCs' control network.

Specification in NS Files

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:

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 inky, and places it on a host called inkyhost. By giving the generic type motehost, 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 emote, or garcia if we wanted it hosted on a robot. The tb-set-node-os 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 tb-fix-node to fix the mote's host. For example, if we wanted to put inkyhost on the emote named em1, we would use tb-fix-node $inkyhost em1.

Programming Mote

Uploading your own code to run on the motes is easy. Just build your TinyOS app normally (ie. 'make mica2'). Then, upload the binary that gets placed in build/mica2/main.srec to our mote image creation page. This page will ask you for a 'descriptor'. This descriptor can then be used in tb-set-node-os 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 CC1000 radio document 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:

  • os_load allows you to load an kernel that has already been defined as an image, as above. You give it the image descriptor with its -i argument, and you can either give the physical names of all motes you want to reload, or a -e pid,eid argument to reload all nodes in the given experiment.
  • tbuisp 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 upload, 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 XML-RPC interface, 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.

Serial Consoles

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 telnet, or with the TinyOS SerialForwarder program. The E-Mote is configured to talk to the mote at 57600 baud.