motelab.eecs.harvard.edu/faq.php

Harvard Sensor Network Testbed

home

faq

signup

about

status

maps

Can I get an account on Harvard's MoteLab?

Yes, accounts are available for academic use only. You can request an account here.

How do I control my MoteLab job?

We now offer a single point of control through a "master" serial forwarer running on motelab.eecs.harvard.edu on port 20000. Every packet sent by every mote running on the lab will be routed through this port, and any packet sent to this port with the destination field in the header set properly will be routed to the correct MoteLab node.

Where do I get the Python code to communicate with the Serial Forwarder multiplexer running MoteLab?

To simply the process of communicating with your MoteLab job we have implemented a Serial Forwarder multiplexer. It runs on port 20000 during your job, and speaks a variant of the TinyOS 2.x Serial Forwarder protocol with an extra addressing bit determining which MoteLab node to route the message to.

Using this requires a modified version of the TinyOS 2.x Python toolchain available here:

    % svn export http://senseless.eecs.harvard.edu/repos/motelab/trunk/python/

Once you download our MoteLabMoteIF.py, it serves as a drop in replacement for MoteIF.py:

    import MoteLabMoteIF
    ...
    self.mif = MoteLabMoteIF.MoteLabMoteIF()

We have defined a special motelab@<host>:<port> source which you need to use to connect to the Serial Forwarder multiplexer:

    self.mif.addSource("motelab@motelab.eecs.harvard.edu")

You can also add the standard moteif source as well. Communicating with this is similar to what you are used to, with the addition of selecting the MoteLab node at send time:

    # Rather than:
    # self.mif.sendMsg(<source>, <dest>, <type>, <gid>, <message>)
    # we provide:
    self.mif.sendMsg(<source>, <dest>, <type>, <gid>, <message>, <motelab_dest>)

The difference between the dest and motelab_dest fields in the example above is that the motelab_dest field is used to route to the node on MoteLab, and is stripped on arrival. The dest field is used to set the destination field in the AM message itself. This divergence is needed to, for example, send a message to MoteLab Node 5 to send to node 6 (using BaseStation for example):

    self.mif.sendMsg(self.source, 0x6, m.get_amType(), 0xFF, m, 0x5)

The sample code below has more examples of how to use the MoteLab Python support.

Also note that the old Serial Forwarder instances running on motelab.eecs.harvard.edu:<20000 + Node ID> are still enabled.

Do you have an example of how to use MoteLab?

Glad you asked! Take a look at some sample code we ginned up. We have two sample applications: TestSerial simply sends at a fixed rate to the serial port. You can get it here:

    % svn export http://senseless.eecs.harvard.edu/repos/motelab/trunk/apps/TestSerial

The second application illustrates two-way communication with the motes.

    % svn export http://senseless.eecs.harvard.edu/repos/motelab/trunk/apps/TestMultiSF

There is a README file in the directory and the code there should show you how to:

Write a MoteLab application that dumps data to the serial port.
Write a Python driver script that controls the job while it's running on the lab.
Write a Python script that takes the pickled Python output and interprets it properly.

Note that we are using Python in these examples. You can do similar things using the Java TinyOS support, but we like Python and hopefully you do too. Hope this helps.

How do I get access to the MoteLab source?

Access to the MoteLab source is available through Subversion. You can checkout or export (anonymous users do not have write access) the sources here:

    % svn [co,export] http://senseless.eecs.harvard.edu/repos/motelab/trunk

If you are interested in contributing to MoteLab development we can provide you with your own development branch. Please email motelab-admin AT eecs DOT harvard DOT edu.

The current version supports moteiv.com TMote Sky motes connected through TMote Connect backchannel boards. Older versions are available that support Mica2 and MicaZ platforms. Ask us.

What's up with the MoteLab maps?

Data displayed on the maps is collected periodically by a connectivity program consisting of mote binaries and a driver script. The locations of the nodes are fixed and the assignment between node ID and location should also not change.

Why can't I upload my executable to MoteLab?

Probably because it wasn't properly compiled. To upload your executable to MoteLab, ensure that:

It was compiled for the tmote or telosb platforms:
```
  % make telosb
```
It was compiled against TinyOS 2.x:
```
  % echo $TOSDIR
  /home/werner/tinyos/tinyos-2.1/tos
```
Or something akin to that.
It was compiled without using TOSBOOT. This used to be the default on earlier version of TinyOS 2.x but was removed later. In any case, if our checker is still complaining and you are following the above two steps, try:
```
  % TINYOS_NP= make telosb
```

My job ran on MoteLab but the files I downloaded don't contain any data. What gives?

There are a number of reasons that this can happen, including but not limited to:

Your application doesn't actually send any packets to the serial port. These are the only packets that MoteLab will automatically parse and log, and this is the first thing you should check.
MoteLab couldn't understand the MIG-generated class file you uploaded. Maybe this is because it wasn't actually a MIG-generated class file? We include several files in your download archive that should allow you to debug these problems. To tell whether MoteLab successfully parsed the classfile you uploaded look at the file named DBLOGGER.CLASSES in your download archive. It should look something like:
```
    EXTRACTED MESSAGE CLASSES:
      CLASS 1.
        CLASSNAME: ReceiverMsgT
        AM ID: 132
        FIELD 1.
          NAME: sourceaddr
          INDEX: 1
          ISARRAY: false
          TYPE: int
          SIZE: 2
    ...
```
You should check this output to make sure that it matches the format of the class files that you uploaded and the messages that your application sends to the serial port.

The download archive also contains a file named DBLOGGERS.ERRORS which lists error produces by the database logger during its operation, which may help you identify motes that it could not connect to or class files that it was unable to parse.
The packets that you're application is sending don't match the MIG-generated class file you uploaded. In this case, look at the dblogger.log file described above and make sure the format of the packets looks correct.

The easiest way to get past this problem is to debug locally. Once you can get it working on your desktop, double-check that all the executables and class files that you are using successfully are the ones you've uploaded to MoteLab, then feel free to email for help.

Note that we now try to catch these sorts of errors when you upload your class file, meaning that hopefully if MoteLab allows you to upload a class file it should work with your database logger.

The connectivity maps you draw for MoteLab look cool. Can I get access to the raw data used to create the graphics?

Yes. Periodically we run a small experiment that aims to record an aggregate connectivity level between each pair of nodes on MoteLab. The experiment runs for as long as an hour and as briefly as five minutes, depending on system availability. The way that this is done is we cycle through the network one node at a time and have it send a packet. Nodes that receive the packet record that fact and the RSSI level associated with the reception. Choosing one node at a time minimizes the internal interference since no other nodes should be transmitting, however other sources of interference typical to an indoor office environment (802.11 traffic, monitor radiation, etc.) are present at levels that vary throughout the day.

All data from each connectivity experiment is logged and can be retrieved by MoteLab users through the database instance running on motelab.eecs.harvard.edu. Account holders have access to this database, and read-only access to the table auth.connectivity, which holds the raw information logged during each connectivity experiment.

The format of the table is that each run of the experiment that measures connectivity is grouped by the groupno field, so selecting the highest-numbered set will retrieve the latest run. The rest should be self explanatory. Each row in the set has a tomote field, a frommote field, and records the number of samples sent from the tomote to the frommote (elided rows can be assumed to have numheard=0), and also records the total summed RSSI.

Is there a way to collect power profile information on MoteLab?

Yes! We have a Keithley Digital Multimeter hooked up to Mote 118. If you check the box on the "Options" panel during job creation or editing, it will enable the Keithley during your jobs run. A file called "powerManage.log" will be included in the archive provided when your job ends, and contains current readings taken by this device.

Where can I get more information about TinyOS?

Try tinyos.net. We are unable to assist you with TinyOS debugging. Sorry.