Archives for category: WSN

Installing TinyOS seems to be not so easy with Lion / Mountain Lion / Mavericks OS and the xcode. The following worked for me (using telosb / msp430):

Update Sep 2014: As TinyOS is pushing to next release, there have been numerous fixes to settle the Mac OSX issues that I list below. Thus, some issues might be obsolete by now.

Update October 2014: You find hints on OSX 10.10 Yosemite in the comments below.

1. Actually, I am not sure if one really needs this first step, I just did it along the way while figuring a way to make it all work. Install gcc 4.6 and gcc_select from macports and select gcc as default compiler for macports via “sudo port select gcc mp-gcc46”. When you are done with installing TinyOS, nesc etc you can disable this again by calling “sudo port select gcc none”. Update: based on the feedback of others: It seems this step is necessary.

2. Install msp430-gcc and msp430-libc via mac ports. At the time of writing of this post the gcc version was 4.6.3-20120406. Update: based on the comments, it seems that newer versions of gcc such as 4.6.4 or 4.7 do not work (yet?).

3. Load TinyOS from google code GitHub and put it somewhere. Set this path in and source it from your bash configuration as both are described on the TinyOS documentation pages. Update: TinyOs is now on GitHub, and seems not be included anymore. Thus, you can set the paths by hand or use

4. Load nesc from cvs head (neither nesc 1.3.3 from macports nor the tar ball from soureforge worked for me, while both compiled and installed fine they lead to errors when trying to compile TinyOS applications: “nesC: Internal error. Please send a bug report to the nesC bug mailing list”. But 1.3.4 should be out soon, hopefully this allows to install from macports/tarrball again). Compile and install as described in the readme for cvs installation (the readme says you need emacs and some other stuff, it worked fine for me without). Update: 1.3.4 has been released, and you can download it from the project website ( and follow the install instructions. Update: If “make install” fails, make sure you run “./configure”, “make”, “sudo make install”. Update: NesC 1.3.4 and the latest code from github ( seem to work just fine (as long as you compile them with gcc — see step 1 — and not the default llvm-gcc of Mac OS X).

5. Install TinyOS tools: in the tinyos download, go to tools and run ./bootstrap, ./configure, make, sudo make install etc. (as described in the install instructions). You might have to fix the following on the way: In tos_locate_jre I had to set xcode_jdk=/System/Library/Frameworks/JavaVM.framework/Headers and in NativeSerial_darwin.cpp I added #include <string.h> and #include <stdlib.h>.
Upate: new paths for JVM:
Update: Hint: Also here you should make sure that you compile things with gcc — see step 1 — and not the default llvm-gcc of Mac OS X.

6. Install FTDI drivers: Interestingly, 2.2.17 lead to some errors during programming (BSLException: Bootstrap loader synchronization error). I took 2.2.16 ( instead and it works fine.

7. Check that everything works: go to Blink and try “make telosb” and “make micaz sim”; connect some nodes and run motelist; install something (if it fails during programming noting that no module serial is availble in python, you might have to install pyserial via “sudo easy_install pyserial”).


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

After some fixing (thanks to Joakim and Fredrik here at SICS) Cooja and MspSim now run TinyOS fine once again: Timers do not do funny stuff anymore and serial communication (via socket) now passes the CRC check of the TinyOS tool chain.

Listening to the SigComm talks, I realized that there are two playgrounds where people can apply tons of clean slate research to today’s networks and (still) do everything new and shinny : Data centers and Wireless Sensor Networks…

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: