TinyOS is an event based operating environment designed for use with
embedded networked sensors. More specifically, it is designed to support the concurrency
intensive operations required by networked sensors with minimal hardware
requirements. There are hundreds of TinyOS projects throughout the world. See the Related Work page for a fraction of them (and
if you'd like to send a link to other related work, send it to email@example.com.
The programming language of TinyOS is stylized C that uses a custom compiler 'NesC'.
The source for NesC as well as TinyOS are available on SourceForge.
TinyOS was initially developed by the U.C. Berkeley EECS Department, and is distributed under the disclaimer below.
We have support for "offline simulation", i.e. running virtual motes on your computer.
Though it may work on other platforms, the supported platforms are Linux RedHat 9.0, Windows 2000,
and Windows XP.
The software that you will need to develop and run TinyOS is included in the Linux RPMs or
Windows Installshield Wizard for TinyOS. You can find pointers to the respective installation
packages at http://webs.cs.berkeley.edu/tos/download.html.
You need a parallel and a serial port on your machine to be able to communicate and program the motes. There is an ethernet programming board and other new
communications options currently (12/03) in development. Check with Crossbow, the manufacturer of the Berkeley Mote hardware, to see what are the latest and greatest options available.
The concurrency concept requires some effort to get used to but it's
essentially C. Proficiency and/or experience with GNU development
tools is a plus, but not mandatory.
You can download the most recent version of Tiny OS
Moteiv Telos/TMote: Moteiv Support Page . Look for "Quick Start Guide".
Crossbow Mica*: Crossbow Manuals . Look for "Getting Started Guide" under the 'Wireless' section.
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO
PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
The most recent major release is 1.1.0 released September 29,
2003, for the 'mica2' hardware platforms. The previous release was
version 1.0, released October 11, 2002, for the 'mica' and 'mica2'
platforms. 0.6.1, released May 10, 2002, was for the 'mica', 'rene',
and 'rene2' hardware platforms.
The most recent snapshot release is 1.1.15 which is a CVS snapshot released July 29, 2005. Please see the Download page for the differences between
snapshot and major releases. Hardware platforms presently supported include telos, telosb, tmote and micaz as well as the mica and mica2 platforms.
Tinyos 2.0.0 Beta Release was released on February 10, 2006. You can find more
information on tinyos.net: TinyOS 2.0 Beta Release .
The various TinyOS-related lists can be found
linked off the
TinyOS support page.
The reason is probably that the address that you're sending from is slightly different from the email address that you joined with. For example, if I'm joined as 'firstname.lastname@example.org' and I send mail as 'email@example.com', the Mailman list management software can't tell that both email addresses belong to the same person. Or perhaps you've joined with your work email address, yet you're trying to send email from your home email address.
There are two approaches you can take: first, you can be sure to always send from the address that you're joined with. This option, however, isn't always practical given the number of email addresses people have these days. A more flexible solution is to subscribe using several email addresses and set all but one of those subscriptions to not receive mail.
To take the latter approach, first join tinyos-help with all of the addresses
that you might use. (You can join from the tinyos-help info page -- see below.)
Next, configure all but one of these subscriptions to not receive mail. To set a subscription to not receive mail, go to the tinyos-help list's info page:
. Scroll down to the bottom of the page where you'll see a text field next to a button that says 'Unsubscribe or Edit Options'. Follow the directions and put the email address that you'd like to configure to receive no mail and click the button. On the configure page, set the Mail Delivery to 'Disabled' by checking the 'Disabled' checkbox. To make this change permanent, click the "Submit My Changes" button at the bottom of the page.
This information applies to all the tinyos mailing lists.
We use a bugs database on SourceForge. Enter bugs or suggestions there. Here is the URL: http://sourceforge.net/tracker/?group_id=28656&atid=393934
You can also email information/suggestions to
. Lastly, you can also email suggestions to any
of the appropriate TinyOS mailing lists off
support page .
You can find the installation instructions off the download page:
You can find the tinyos tree at /opt/tinyos-1.x (provided that you didn't relocate it to someplace else with a prefix= option in Unix).
The setup looks for the file called JAVAHOME/lib/javax.comm.properties where JAVAHOME is defined by the registry key HKEY_LOCAL_MACHINE/JavaSoft/Java Development Kit/1.4/JavaHome. While JAVAHOME/lib works, a better location is 'JAVAHOME/jre/lib' and yours may be there.
This is really a bug in the Installshield setup as we also recommend putting javax.comm.properties in JAVAHOME/jre/lib. The upshot is that you can ignore that warning if you're certain you have a JAVACOMM 2.0 installation.
In a cygwin shell, cd to the directory that your tinyos-1.x tree is in (usually /opt), do this:
$ chmod -R a+rw tinyos-1.x
The above will make the tinyos-1.x directory and all the files in it accessible for reading and writing for all users. You can adapt the permissions to your security policy. See 'info chmod' for more information on the chmod command.
You might have a HOME environment variable defined that points to the old location. Check and, if you do, remove it. (See the related FAQ entry for how to modify environment variables.)
RPM is a package management system. RPM installs and uninstalls
software. A .rpm file is an individual package. For example,
mysoftware-1.2-1.rpm would install version 1.2, release 1 of the
TinyOS uses RPMs to distribute TinyOS and it's subcomponents and tools for several reasons:
For convenience, we offer an Installshield setup for the Windows
platform. The IS setup automates the installation process as much as
possible but under the covers the same RPMs are installed.
- It is a standard installation tool for the Unix platform and,
thus, it is already familiar to many in the TinyOS community.
- RPMs can be used on both Linux and cygwin/Windows. Though we
officially only test and support RedHat 9.0, you might find that the
RPMs work on other linux variants.
- It allows us to package and, therefore, distribute each component
in the TinyOS development environment individually. This makes it
possible to release just the RPMs that have changed.
If you'd like to find out more about RPMs, please see www.redhat.com and search for 'rpm
As administrator, do this in cygwin:
InstallShield requires the Microsoft Installer on your machine.
If the installation wizard does not
find it on your machine, it attempts to download
it from Microsoft. If the file cannot be downloaded
from Microsoft, you are asked to supply the location
of the file.
- $ cd tools/src/uisp/src
- $ make; make install
- $ cd tools/src/uisp/kernel/win32
- $ make; make install
We have put this and another file that you may need, isscript.msi, online:
these two files into the same directory that the
TinyOS installation file resides in. Run instmsiw.exe, run isscript.msi, and then run the TinyOS installation
As you proceed, you'll notice that there are two kinds of environment variables: System or User. When editing TinyOS-related variables, it's safest to make them system variables.
See the file tinyos-1.x/doc/uninstall.html . An online copy can be found at
It's a known installation problem with that package of gcc. If you use the Cygwin setup.exe program to reinstall gcc and it's related packages, the problem will be fixed.
- Right Click on My Computer (usually an icon on the Desktop)
- Select Properties
- Select Advanced tab
- Click on Environment Variables
- If the environment variable already exists, select Edit; If the variable doesn't exist, select New
- Proceed to edit or create in the standard Windows UI way
To reinstall gcc, click on the setup.exe that you used to upgrade Cygwin,go through the screens until you can choose packages to keep, upgrade, install. Find gcc and click on the 'Keep' until it says 'Reinstall'.
One problem could simply be the CVS version you're working with. Please look at this page for more information: http://webs.cs.berkeley.edu/tos/anonymous.html
TinyDB does not compile with more recent
versions of TinyOS, though there has been discussion of updating the code. The last known-working combination was TinyDB 1.1.3 with TinyOS 1.1.7 (both released in July 2004). Users have reported, however, that TinyDB 1.1.3 did work with TinyOS 1.1.10 but required NesC 1.1.2a rather than NesC 1.1.2b. NesC 1.1.2a, TinyDB 1.1.3 and all 1.1.x versions of TinyOS are available in the TinyOS software distribution tree:
This was a bug in the environment in 1.1.11 that has been fixed. You can safely ignore the error if you do have '.' (that is, a reference to the current directory) in your CLASSPATH environment variable.
Recent versions of TinyOS depend on NesC version 1.1.1 or greater. The most recent version of NesC
is 1.1.2b. You can download and install the 1.1.2b NesC rpm from
http://www.tinyos.net/dist-1.1.0/tinyos/. If you
have a linux environment, click on the linux link;
if you have a windows environment, click on the windows link.
If you do not want to upgrade NesC, you could install the rpm using the --nodeps argument but
we do not recommend that.
TinyOS requires a patch to the assembler so that NesC can use dollarsigns within object names in intermediate code representations. This patched assembler was included and installed in versions of NesC prior to NesC version 1.2.
NesC 1.2 and beyond, however, does not install this patched assembler for you. Instead, the patched assembler can be found in the binutils RPM available for your platform. You can find these binutils RPMS for the MSP430, AVR, and xscale platforms here:
http://www.tinyos.net/dist-1.2.0/tools/. To ensure compatibility within compiler toolsets, you should upgrade all of your compiler tools (gcc,binutils,libc) with the rpms found in the above source repository. They are named by platform.
If you are not using a MIB500, which is programming board for the Mica family that programs motes via the parallel port, you need to ensure that (1) your MAKERULES environment variable is pointing to $TOSROOT/tinyos-1.x/tools/make/Makerules and that (2) you're using the correct make flags.
The correct make command should look like this:
See your manufacturer's Getting Started Guide and tools/make/README for more on make flags.
- mica2 example:MIB510=/dev/ttyS3 make mica2 reinstall,mib510
- telos example:make telos install,2 bsl,3
If you are using a MIB500, this could be caused by a number of things, most of which relate to the use of the parallel port to program the mote. First, be sure that the mote is connected to the parallel port as you expect; that is, be sure it's firmly seated in the port/cable and, if using a cable, be sure the cable is firmly seated in the port. You might try removing the parallel cable from your setup to see if the cable is causing the problem.
Next, peruse the following document for hints on how to fix the problem
UISP, Mote Programming and Mote Fuse or buy the MIB510 board from Crossbow that uses the serial port. Our understanding from Crossbow is that the MIB510 price for low quantities for domestic users is $95.
These flash errors can also be a symptom of a condition whereby the atmel128 (the mote's chip) fuses can become incorrectly programmed. If you have already received these errors and then find
that you're receiving the error "...Probably the wiring is incorrect or target
might be damaged...", you can
read, check, and set your fuses properly with a JTAG board and AVR
Studio. If you don't own a JTAG board and AVR Studio and you think
that your fuses may have become compromised while programming the
mote unsuccessfully, contact Crossbow for advice.
The NesC compiler program, ncc, cannot find the TinyOS libraries which are stored under tinyos-1.x/tos. You can specify the location with the ncc option -tosdir=dir or by defining the TOSDIR environment variable. Here is an example of how to define TOSDIR in the bash shell:
$ export TOSDIR=/home/kwright/src/tinyos-1.x/tos
You can check what ncc thinks is the tosdir by using the -print-tosdir option. See the nesc documentation in doc/nesc for mocomm jar file is installed in the correct spot, the JDK should find it automatically with no CLASSPATH modifications. If that's not happening, you might want to append your CLASSPATH might need to include the comm.jar library -- something like this:
The way you've specified the class on the command line does not match what the class itself thinks it is called. The compiled java class might include a path in its name. For example, the class defined in
The wiring could be wrong, but probably not. Check these things:
tools/net/tinyos/oscilloscope/oscilloscope.java has the classname tools/net/tinyos/oscilloscope/oscilloscope. For example, to run the oscilloscope tool, you can cd to tools/java and type
java net/tinyos/oscilloscope/oscilloscope .
If you have recently received many flash errors while
programming your mote, it is possible for the mote's fuses to become incorrectly
programmed. This error can be a symptom of messed-up fuses. See this related FAQ.
This message could be caused by a number of things:
isn't powered by its own supply or via the adapter connected to the
programming board. Even though the light on the programming board is
on, you may not have the necessary power supply to program and verify
the mote successfully. You can check for this if the red LED on the
programming board is flashing durning the "Uploading: flash" state of
the "make install" target.
Those are actually macros. You can find the definitions in tos/platform/platform where platform is something like mica or mica2. Specifically, look in the file hardware.h. For the avr platforms, you can find further definitions in tos/platform/avrmote/avrhardware.h.
- Ensure that the mote is firmly seated in the right slot.
- Ensure that the mote hasn't fallen to the floor off the cable/slot
- Ensure that you haven't connected your printer to the mote's slot since your last install
Hint: Just look at the definitions for a while and it will all make sense.
When an event occurs at the hardware
layer, an associated interrupt handler routine is called. If the interrupt handler routine is defined as TOSH_INTERRUPT (e.g. see tos/platform/mica/HPLClock.nc) then interrupts are enabled, if it's defined as TOSH_SIGNAL then interrupts are disabled. So let's say your event A is the clock firing, and event B is you receiving a message. Event A is defined as
TOSH_INTERRUPT which means it can be
interrupted and event B (the reception of a message) is defined as TOSH_SIGNAL, which means it cannot be interrupted.
Previous versions of TOS sent a serial mese to the length of the message.
CC1000 (used in the Mica2 and Mica2dot platforms)
Bug fixes and tweaks aside, there are two versions of the MAC for the
Mica2 and Mica2dot's CC1000 radio: one version found on stacks before
1.1.3 and a version called B-MAC found on stacks from 1.1.3 on. Both
are CSMA. You can find comparisons of the two versions here:
Code for the CC1000 radio stack can be found in this TinyOS directory:
1.1.0 version (also in 1.1.1 and 1.1.2)
1.1.3 and beyond:
- fixed noise floor
- if RSSI reading less than floor then transmit
The version of B-MAC mentioned in
Versatile Low Power Media Access for
Wireless Sensor Networks is in contrib/ucb/tos/CC1000Pulse but not
stress tested. You can find the contrib directory in the tinyos-contrib rpm
package or in the TinyOS CVS repository at SourceForge.
- called B-MAC
- includes AGC: an algorithm to adjust the noise floor dynamically
- includes improvements to reduce preamble length
- collisions reduced, increased bandwidth over 1.1.0 version above
CC2420 (used in the MicaZ and Telos platforms)
One of the goals of the Zigbee Alliance is to defining the network,
security and application software layers for wireless networks for
monitoring and control products. The lowest level of the
communications stack defined by Zigbee is the networking
level. Therefore, it is not a replacement for but rather compatible
with TinyOS. That is, a Zigbee protocol could be written in
TinyOS; indeed, there are several efforts for creating such a network
layer on top of existing TinyOS MAC protocols.
Support for the CC2420 radio was introduced in TinyOS 1.1.7. The
CC2420 uses B-MAC. However, the CC2420 radio does not have the Low
Power Listening functionality; it does have the MacControl and
MacBackoff interfaces but, again, the underlying functionality is not
The Zigbee standards are only available to Zigbee Alliance members; that is,
they are not open-source.
Zigbee is not a MAC protocol, an operating system, or a hardware platform.
Here is the Zigbee Alliance website:
802.15.4 is an IEEE standard that defines a MAC and PHY layer targeted
to wireless sensor networks. Some radios have hardware that supports
the 802.15.4 standard. Among these radios is the Chipcon CC2420. You
can find a CC2420 radio stack in TinyOS in tos/lib/CC2420. The Telos
and MicaZ platforms both use the CC2420 radio stack.
The CC2420 radio stack does not support the full IEEE 802.15.4
standard; instead it provided B-MAC primitives and sends
802.15.4-compliant packets, but does not implement the 802.15.4 MAC
The IEEE 802.15.4 (formally called "IEEE 802.15.4 WPAN Task Group 4")
web site is here:
The Zigbee Alliance's standards assume an underlying 802.15.4 layer.
It is usually possible to go right to the manufacturer's page and get specs. There are
design diagrams of all the TinyOS platforms
off the TinyOS design page . Atmel has manuals and specifications online for the chips at
Here's an example of how you might go about finding information about the microphone on the
Wire to the CC1000Control interface in CC1000RadioC. Call CC1000Control.setRFPower(char value) with the desired power level as per the CC1000 datasheet on page 29. The output power dB changes with frequency, so check the table on page 29 to pick your desired output RF power.
- Browsing through the
hardware page , you look at the table at the top of the page and happen upon
a listing of parts for the Mica Sensorboard .
- Looking through the excel spreadsheet, you
see that the microphone is a Panasonic WM-62A.
- Using 'Panasonic WM-62A specifications' as
a search string at Google yields the as the
Panasonic Omnidirectional Back Electret Condenser
Microphone Cartridge .
Your user directory doesn't exist on the sourceforge cvs server
until you ssh directly into it. Once you ssh into the server directly,
your directory will be created and then you can check out source.
Try something like this:
ssh -l cvs.tinyos.sourceforge.net
Enter your sourceforge password when asked. Because of the restricted
shell, you'll be logged out of cvs.tinyos.sourceforge.net immediately,
but the directory will still have been created.
Note that this does not apply to using the 'anonymous' username to check-out files.
Your source tree might have files left from a make for a different
hardware version (mica instead of rene, for example). Try 'make clean'
and then remake and reinstall. Be sure to specify the version of
hardware for your mote in your make commands.
This means either you are reading from the wrong port, or that the
correct port is currently being used by another
application. Check to see if some other software is
currently occupying the port (your Palm desktop software,
If you're using Linux make sure that your current user
has read/write access to the port.
Oscilloscope.java is currently hard-wired to read from serial
port 1. If your mote is connected to serial port 3, you need
to change the setup and recompile oscilloscope.java.
Yes for Mica2; kind-of for Mica.
strength field (
TOS_Msg->strength) of the TOS_Msg structure is filled in with data from the radio's Received Signal Strength Indicator (RSSI) pin. The RSSI data is inversely proportional to the signal's strength. You can find out exactly how to interpret the RSSI data by looking at the RSSI Output section of the Chipcon CC1000 radio's datasheet:
Mica: It is possible to get the signal strength field on the Mica's RFM radio, but the code in the tree does not support that functionality; the code in the tree leaves the strength field equal to 0. However, there are implementations out there that do support the strength field though they're for older versions of code. For an example, see this archived help
and the RFM TR1000's datasheet:
We welcome and encourage outside contributions to the TinyOS source -- whether it's in the form of bug fixes or new code. Please see How To Contribute page.
Crossbow uses alphanumeric partnames to identify the motes, programming boards, and sensors to ease inventory control. They have a product guide that maps their product names to the more commonly used names called the
Crossbow Product Information Guide.
Please see the appropriate platform-specific antenna information off the hardware page:
Several people have gotten USB-to-serial adapters to work. (If you have other
information, I'd appreciate your information so I can post it -- send to firstname.lastname@example.org).
Thanks to Mads Bondo Dydensborg, Eric Haux, Murat Arabaci, and Matt Miller for this information.
We have ordered 51-pin cables from a company called Meritec and the item is called a "51pin flat flex cable".
With windows and Mica2 motes, we have successful reports for the Belkin F5U109 and the Targus PA088.
We have had a report that the
Keyspan USA-19QW model worked with RH9 and Debian Linux. With this particular adapter, the user specified -dspeed=115200. Note that the Mica2 works at 57600 by default, but this worked in this instance.
Another report said that the Keyspan USA-19HS does not work and recommends the ATEN UC-232A USB-Serial converter.
- With Mandrake Linux, an unknown :) $20 model adapter was purchased, plugged in and worked thanks to the Linux Hot Plug service. The only modification necessary was to specify to uisp this argument: