Requirements on the users' side

Requesting for an account on the Testbed

A request for an account can be made here.

Compiling TinyOS code

Compile as usual: make telosb

Creating a job to be run on the Testbed

  1. Before jumping into the details of creating a job, let us spend sometime on the details of what constitutes a job. A job is a combination of application's exe image (usually, the file "build/telosb/main.exe") and MIG generated Java class files that defines the structure of messages that application dumps to the USB port.
  2. Please note that you can monitor an application executing on the Testbed by having the application to dump data to the USB port. The dumped data is presented to the user on the completion of the job. However, an user can also monitor in real-time by accessing mote's serialForwarder through a TCP connection. The address of the motes' serialForwarders has been specified on the "status" menu-item. Another way to access to the data in real-time is through Mysql connection and its details have been discussed on the menu-item "user-info" and this menu-item is visible only after you login using your account name and password.
  3. Login using your account information.
  4. Clicking on the link "create job" in the menubar leads to the main page for creating a job. The main page requests some general information regarding application to be created. The next step is to specify and associate the application's exe image and MIG generated class files. Finally, you can individually select motes on which you desire to execute your application. Moreover, the interface also incorporates support for executing diffrent exe-images on different motes thereby allowing multiple images to be executed in single scheduled session.
  5. Following is a sample application that periodically sends a test packet to the USB port: SendToUART.tgz.

    Note: While using multiple debugging messages, please make sure that AM IDs of those messages differ. This is a basic requirement in TinyOS framework to diffrentiate between diffrent message types.

Scheduling the created job

The "schedule" menu-item directs to the corresponding page. An user is allowed to schedule his/her job for desired amount of duration that is less than the maximum quota that he/she has been allocated with. The drop-menu "Run" on the page shows all your applications.

Note: Please note that when you submit a job, not all the motes are programmed exactly at the same time and please do not make such an assumption while dealing with inter-mote synchronization.

On the completion of the job

The user's home page allows to download all the data dumped by the application.

My job ran on Testbed 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 Testbed will automatically parse and log, and this is the first thing you should check.

  2. Testbed 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 Testbed 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 Testbed, then feel free to email for help.