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 wiht apps/GenericBase (leaving GenericBase plugged into the PC serial port as before). Be sure to start up SerialForward as well.

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

By running BcastInject with the appropriate arguments you should be able to turn the yellow LED on and off. Looking at the code for SimpleCmdM.nc, you can see that the application simply waits for incoming messages to arrive and interprets one field of the message as the command type. Note that BcastInject and SimpleCmd have to agree on what the command types mean.

Exercise

Add commands that will allow SimpleCmd to turn its sounder on and off. You'll need to perform the following modifications:

• In SimpleCmd.nc, wire the Sounder component into the application.
• In SimpleCmdM.nc, initialize the sounder and add a new command type that will turn 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 SimpleCmdM.nc.

Multihop broadcast

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

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