Testbed Software for NSLU2


The JHU testbed software is developed to help users install, use, maintain their testbeds easy. This software is following the HiNRG copyrights written in every source code. This page only tells you about the installation process and how to use it. For more details, please download the documentation [click] ( If you have any questions or find bugs, please send an email to  This e-mail address is being protected from spambots. You need JavaScript enabled to view it )

0. Information

1. Development

If you want to add or change current testbed software, you should install Kamikaze OS in your computer. Follow the instruction given in this link. If you are using kamikaze > 8.09, the program may not work as well. To cope with the cases, please compile our source code in your kamikaze directory, as in this link.

2. Installation Process

2.1. Server

The server program we provide is named 'MIB.py'. This is a Python script so that no installation is necessary. Simply run this program. However, it is a good practice to run this program within screenscreen is a tool within which you run your program. The best part is that you can detach your program outputs from your terminal session. The related commands are as follows:

 >> screen 
 >> ./MIB.py 
 >> ctrl + a + d (to get out of the screen) 
 >> screen -r -d (to get into the screen again)

2.2. Client

There are two ways to install the client program: 1) install with NSLU2 images or 2) with precompiled packages.

2.2.1 Install with binary image.
One advantage of this method is that the image file includes everything you need to run the client software. This process delete everything in your machine and reinstall the OS image. This is a complete image file (.bin) including every packages that you need to run client program. To do this, NSLU2 project provides a program, called upslug. Please follow the instruction on the page. After the installation, all related programs will be running automatically.

2.2.2 Install with pre-compiled packages
A user may not want to replace his or her OS with ours. Instead, you can install all packages that you need one by one. The package that include our client program is tinyos-telos-monitor_2.1-1_armeb.ipk. Copying, sshing, and installing the program is as follows:

 >> scp tinyos-telos-monitor_2.1-1_armeb.ipk [your machine]
 >> ssh [your NSLU2 box]
 >> ipkg -i tinyos-telos-monitor_2.1-1_armeb.ipk

The other package you need to install is the cppbsl. This program compiles the mote connected to a USB port. Installation process is the same as above. The name of the package is tinyos-cppbsl_2.1-1_armeb.ipk

On top of this, you may need to install the one more package if your system does not have it. It is kmod-usb-serial-ftdi_2.6.26.8-ixp4xx-1_armeb.ipk. This is the case only when your device(mote) uses FTDI chips for serial communication. Be default, FTDI module is not installed in NSLU2. Thus, to install this, follow the same procedure as above.

3. How to use testbed

3.0. Conventions
The followings are the conventions defined by tos.py. Suppose you want communicate(i.e. read and write data) with a mote and the name of your python program is user.py. Then, we can communicate with a remote mote by specifying the server name and TCP port number.

>> ./user.py 
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it

In new testbed convention, the last three digits of TCP port implies TOS_NODE_ID of a mote. With the example being the case, by 003 means TOS_NODE_ID 3. To be able to use it, though, two more prerequisites in your script are necessary: 1) import tos.py 2) instantiating AM class as in am = tos.AM()

Suppose the mote's TOS_NODE_ID you want to read data from is 3. Then, by executing the following command, we will be able to read data from the mote 3: ./user.py This e-mail address is being protected from spambots. You need JavaScript enabled to view it :17003, where user.py would have the following statements for read operation.

While True:
    p = am.read()
    print p.data

3.2. Write a data to a mote
For writing data to a mote, a user first needs to build a packet formatted in a serial ActiveMessage(called AM packet for short) We assume that a user has built an AM packet using tos.Packet provided by tos.py. We call the user's packet as \textbf{ampacket}. If this is the case, the user script will contain the following line:

if am.write(ampacket, 238) == True:

   print 'ack received'

With this command executed, tos.py sends ampacket to a mote 3 with AM ID 238, and waits for an acknowledgement. If ack is received successfully, the write function returns True.

3.3. Recompiling motes
To be able to recompile motes, you need to prepare two things: burn script(burn.all) and all file. The two file are located in home directory of magma server (if logging with wpt) Copy the burn script to the directory in which your application program is located. And copy the all file to your home directory. Then, simply execute it with command ./burn.all. Currently, the burn script assumes that the all file is in your home directory. If you want to change the location of all file, you can modify the burn script.

3.4. Remote resetting motes
As testbed motes are all around our building, manual reset would be painful. The reset.all script (which is also located in magma's home directory) reads all (the same file used for recompiling) and resets corresponding motes described in all file. It can be located anywhere in your local computer (because it is not reading any image file as in recompiling). Simply, run with ./reset.all

3.5. all file and scripts
We maintain two scripts (burn.all and reset.all) and all (MAC addresses and TOS_NODE_ID mapping file). The most up-to-date files are always kept in the home directory of magma server (login ID: wpt)