Chapter VI. Token Passing Example

Table of Contents

1. Introduction
2. Example description and execution
3. Debugging a distributed application

1. Introduction

This example shows how to start a mixed simulation using WSim for node simulation and WSNet for radio propagation and interferences. It consists of three sensor nodes (again, simulating the WSN430 hardware platform). The nodes are communicating with one another by passing a token around the network.

2. Example description and execution

Nodes are numbered from 1 to 3 and can identify themselves through the DS2411 unique Id number chip. Node Id are given at simulation startup using the --ds2411=0a:00:00:00:00:00:01:01. Node Ids must be given with the right CRC value (a valid CRC is calculated at simulation startup). The --node-id parameter is used by WSim for packet exchanges with WSNet. This node Id cannot be used by the embedded software running on the node hardware. The demo application is a single token passing application. Each node listens the radio medium and waits for a packet that contains its node-Id. Once a packet is received with the correct id number, the corresponding node bla bla bla.

To compile this example, simply run the make command. To execute it, the following procedure must be followed:

Launch three WConsole instances (each node will print its feedback in these serial consoles) in separate shells.
Launch WSNet the network simulator. You must either launch it from the directory containing the example or provide the path of this directory to it as an option (see WSNet Tutorial for more details). This is needed for the configuration of the network simulator (environment, physical layer, MAC layer etc).
Launch the three WSim nodes. To do so, use the script provided with the example: demo.sh. For regular execution (time mode, 10 seconds), use the script with the following arguments:
```
[wsn430-token]$ ./demo.sh p3 /dev/pts/7 /dev/pts/8 /dev/pts/9
```

Figure VI.1, “Snapshot of the execution of the token passing example” shows the console output of the 3 nodes. Console duplicated messages are one of the effects of the distributed simulation mechanims. WSNet keeps track of global simulation time but does not impose a tight synchronisation with WSim instances. Time synchronisation is done among nodes using an optimistic behaviour that lets processes work at full speed, only requiring time synchronisation when uncoherent events are detected. Correct distributed events ordering is ensured by backtracking nodes that are in advance compared to others. Only WSim processes are backtracked but WConsoles do not go back in time, hence the duplicated messages on consoles output.

Figure VI.1. Snapshot of the execution of the token passing example

3. Debugging a distributed application

WSim allows debugging even for distributed applications. It is possible to place one node from the network in debug mode and the entire application (including other nodes and WSNet) will follow the node being debugged.

To launch this example in debug mode, follow the same steps as above, with a slight modification at the third step:

To place Node 1 in debug mode and the other two in regular execution, execute the script with the following arguments:
```
[wsn430-token]$ ./demo.sh d31 /dev/pts/7 /dev/pts/8 /dev/pts/9
```
To place Node 2 in debug mode and the other two in regular execution, execute the script with the following arguments:
```
[wsn430-token]$ ./demo.sh d32 /dev/pts/7 /dev/pts/8 /dev/pts/9
```

Once the simulators are launched, you can connect GDB/Insight to the node placed in debug mode in the same way as presented in Chapter III, LEDs Example.

Figure VI.2. Snapshot of the debugging of the token passing example

Figure VI.2, “Snapshot of the debugging of the token passing example” gives an idea of how the debugging of this example should look like.


Chapter V. Serial Port Example		Chapter VII. Credits