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 get access to the MoteLab source?

MoteLab is part of the SYRAH (Systems Research at Harvard) Sourceforge Project. The package name is motelab. For example, to download the source using CVS:

cvs -d:pserver:anonymous@syrah.cvs.sourceforge.net:/cvsroot/syrah/ co motelab

The current version supports moteiv.com TMote Sky motes connected through TMote Connect backchannel boards. At some point we'll package up the last working version that supported the Crossbow Mica2 and MicaZ platforms.

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.

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

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

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

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

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