Archives for posts with tag: tinyos 2.x

A little HowTo on running TinyOS applications in the Cooja emulation / simulation environment.

  1. Cooja is included in the Contiki CVS Git. Hence, make sure you have a recent cvs checkout git clone / checkout / branch /… of Contiki on your system. See for installation instructions.
    2011-03-27: update: contiki is now on Git.
  2. Compile your tinyos application with “make telosb”
  3. In your Contiki installation, go to tools/cooja/ and run “ant”. This requires you to have java and ant installed. After compilation it will greet you with an empty simulation environment.
  4. Hit File –> New Simulation to configure your simulation run.
  5. Press create and you will see your initial setup.
  6. Now it is time to add some sensor nodes. Hit mote types –> create mote type –> sky mote type and select the image (main.exe) of your tinyos application by hitting browse.
  7. Hit open and create and next specify the number of sensor nodes you need with that application image. You can add other application by repeating the steps 6 and 7. Hit create and add to make the sensor nodes appear.
  8. Play with select visualizer skins to customize the sensor visualizations. I prefer mote ids, leds, and radio traffic.
  9. Activate the radio logger (Plugins –> radio logger) and place all windows conveniently on the screen.
  10. Press start to see the action. Check the timeline to see packets sent and received and also the Leds. Check the loggers to see radio packets and serial communication.
  11. Cooja has many other features such as serial sockets, debugging, etc. I will leave it to you to explore them. Please keep in mind that some functionality in Cooja is specific for Contiki and will not work (or only partially) with TinyOS.

RandomC (in lib) and UniqueSendC (in chips/cc2420/unique) are both wired the MainC.SoftwareInit. On my system it seems that that UniqueSendC is initialized first and hence without a seeded random number generator. As a result, all nodes have the same initial DSN. This leads to funny effects when nodes start to transmit simultaneously, as 802.15.4 ACKs are bound to the DSN only.

Contacting tinyos-devel on this, Phil proposed the following fix: “The trivial change is to have init() post a task that initializes the sequence number”. Now, this is really a nice and simple fix (and I tried it: it works).

TOSSIM live is cool to run TOSSIM experiments in real-time and connect to them via the TinyOS serial forwarder.

However, due to the following bug, it crashes immediately on my system: In the current version messages are freed before they are forwarded into the simulator. Others have found this bug, too and proposed the following work around:

Be aware: While this work around works good for most simulations, it makes the following assumption without being able to enforce it: This patch frees a message after it has been processed by the simulator. Hence, buffer swapping etc. is not possible.

update: After a quick email to Phil, he fixed the bug. Thanks!

Last week, I ran a number of experiments on motelab, the telosb testbed in Harvard. During the experiments, some radio messages could not be delivered.

Digging into the details, the following problem showed up: Normally, the motelab installer sets TOS_NODE_ID and AMAddress of the sensor node. However, end of last year TinyOS changed the variable and function name separators from “$” to “__”. However, motelab still seems to run the old programming tools that expect dollars instead of underscores. As a result, motelab cannot set the AMaddress of the sensor node, it stays as one (1). Hence, the node does not receive the messages intended for it…

Quick fixes (next to changing the scripts at motelab), are:

1. Set AMaddress to TOS_NODE_ID during bootup (wiring to ActiveMessageAddressC):

call ActiveMessageAddress.setAddress
(call ActiveMessageAddress.amGroup(), TOS_NODE_ID);

2. You should be also be able default to the old seperatpors via:

PFLAGS += -fnesc-separator=$

However, be careful when using locally connected sensor notes in this case:  “msp.rules” seems to hardcode

AMADDR = ActiveMessageAddressC__addr.

This problem has also been mentioned on the mailing list: