This lesson discusses the use of simple Java tools to inject packets from a PC into the sensor network, as well as the use of a simple multi-hop broadcast protocol.

Injecting packets

We first demonstrate a simple application that receives "command" packets from the radio and interprets them to perform a number of actions, such as turning the LEDs on and off. Program one mote with the apps/SimpleCmd application, and another with apps/TOSBase. Next connect the programming board to the serial port of the computer. The mote programmed with apps/TOSBase should remain on the programming board. TOSBase will act as the base station; a gateway allowing radio communication between the PC and motes programmed with SimpleCmd.

Now run the SerialForwarder as in Lesson 6 using

    java net.tinyos.sf.SerialForwarder -comm serial@COM1

The Java application tools/java/net/tinyos/tools/BcastInject is used to inject a command packet into the sensor network from the PC. You can run it using

  java net.tinyos.tools.BcastInject <group_id> <command>

• led_on - Turn on the yellow LED
• led_off - Turn off the yellow LED
• radio_louder - Increase radio power
• radio_quieter - Decrease radio power

• In SimpleCmd.nc, wire the Sounder component into the application.
• In SimpleCmdM.nc, initialize the sounder and add a new command action that will turn the sounder on and off.
• In SimpleCmdMsg.h add a new command type for turning the sounder on and off
• In BcastInject.java, add the sounder on/off command to the set of supported command types. Be sure to use the same command type codes as in SimpleCmdMsg.h.

In this part of the lesson, we extend the SimpleCmd application and cause it to forward command messages that it receives to other motes in the network. This is accomplished by re-broadcasting the command message once it has been processed. In this way we can form a simple multi-hop routing network, extending the motes' communication range.

This code is in apps/SimpleCmd/BcastM.nc. In addition to processing the command contained within each received message, it re-broadcasts the message if it has not been seen before. Note that in order to install the Bcast application you need to edit apps/SimpleCmd/Makefile and change the line

  COMPONENT=SimpleCmd

  COMPONENT=Bcast

  event TOS_MsgPtr ReceiveCmdMsg.receive(TOS_MsgPtr pmsg){
    TOS_MsgPtr ret = msg;
    result_t retval;
    struct SimpleCmdMsg *data= (struct SimpleCmdMsg *)pmsg->data;

    // Check if this is a new broadcast message
    call Leds.greenToggle();
    if (is_new_msg(data)) {
      remember_msg(data);
      retval = call ProcessCmd.execute(pmsg) ;

      // Return a message buffer to the lower levels, and hold on to the
      // current buffer
      ret = msg;
      msg = pmsg;

    }
    return ret;
  }

To determine whether a given command message has been seen before, the BcastM component tracks the sequence number contained in the message. If the sequence number of the current message is within 127 of the current message, the command is accepted, processed, and forwarded. Otherwise, it's dropped.

Note that the BcastInject program maintains its sequence number across invocations (saving it in a file called tools/java/bcast.properties). If you remove this file the sequence number generated by BcastInject will be reset to 1. You will need to power-cycle the motes if you do this in order for them to interpret subsequent messages as "new".

Accepting messages with a wide range of sequence numbers (rather than just the previous sequence number plus 1) allows for cases where messages are dropped by the radio stack, for example, due to corruption. This is a fairly crude mechanism, of course, and in a real application you might want to do something more involved, such as packet acknowledgments.

Exercises

1. Look at SimpleCmdM.nc again - notice that the green and red LEDs are used to indicate the "hop count" of the message - that is, the number of times that message has been forwarded through a mote. Set up two motes running Bcast (from the apps/SimpleCmd directory) and place them so that one mote gets command messages with a hop count of 1, and another gets messages with a hop count of 2.
2. As written, the broadcast protocol is fairly fragile: it depends on a property that the sequence number on the BcastInject and the sequence number on the mote differ by less that 127. A better way to distinguish between the messages would be to create an index of a few (say 5) most recently seen messages. If the message currently received is not in that index, then the node should forward it. BcastInject can then run unmodified, or it could send out messages with random message numbers.