Table of Contents

1. Introduction
2. Example description and execution
3. Debugging a distributed application
4. Radio packets log

1. Introduction

This example shows how to start a mixed simulation using WSim for node simulation and WSNet1. 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.

For more information on WSNet1 and WSNet2 installation, configuration and usage, please have a look to WSNet tutorial. By default the script provided with this example uses WSNet1, but you can modify it to use WSNet2 (by setting WSNET_MODE variable to --wsnet2).

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 --wsnet1 option allows to use the WSNet1 interface of WSim (if not specified and if the --node-id parameter is present, WSim use WSNet1 by default).

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, launch the script provided with the example

[wsn430-token]$ ./

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.

Snapshot of the execution of the token passing example

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]$ ./ dbg 1

  • To place Node 2 in debug mode and the other two in regular execution, execute the script with the following arguments:

    [wsn430-token]$ ./ dbg 2

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.

Snapshot of the debugging of the token passing 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.

4. Radio packets log

WSim allows to write into a custom file (by default wsim-pkt.log) full frames received and sent by the platform interfaces. It takes care about backtrack, so the log reflects exactly real RX and TX.

2 options refer to this functionality, --logpkt and --logpktfile. Setting one on command line, enables packets log.

--logpkt=[rx | tx | rxtx]

  • rx: only RX are logged.
  • tx: only TX are logged.
  • rxtx: both RX and TX are logged (by default).


  • filename: Name of file where packets log will be stored..

[Note]Options parameters

--logpkt option parameters are optional. --logpktfile option parameter is mandatory.

In the token exemple, you can see radio packets log in the n1-pkt.log, n2-pkt.log and n3-pkt.log files. For instance n2-pkt.log :

== Radios packets log ==

Note : rx and tx packets contains preamble, sync word and data
Note : rx packets are logged before crc replacement
Note : time interval syntax -> [tx or rx start; tx or rx end]

Log mode: RX and TX
Interface cc1100 registered

******* cc1100: RX packet (n°0) [526739197ns; 528763697ns] *******

******* cc1100: TX packet (n°0) [1526671947ns; 1528682197ns] *******

******* cc1100: RX packet (n°1) [2526724697ns; 2528749197ns] *******

******* cc1100: RX packet (n°2) [3526738572ns; 3528763072ns] *******

******* cc1100: TX packet (n°1) [4526671947ns; 4528682197ns] *******

******* cc1100: RX packet (n°3) [5526724197ns; 5528748697ns] *******

******* cc1100: RX packet (n°4) [6526738572ns; 6528763072ns] *******

******* cc1100: TX packet (n°2) [7526671947ns; 7528682197ns] *******

******* cc1100: RX packet (n°5) [8526724197ns; 8528748697ns] *******