Frequently Asked Questions
This page provides a list of questions that many users have when starting out
with Avrora. If you don't find an answer to your question here, please contact
the mailing list.
Questions and Answers
- Q: My simulation doesn't seem to work correctly with Beta 1.6.0.
There are a number of issues with the Beta 1.6.0 release that have been corrected
in the development branch (1.7.x) that is only available via CVS
or on the JARs archive page.
You should use the 1.7.x branch until Beta 1.8.0 is released, which is expected by
- Q: Avrora's default colors cause problems with my terminal.
- Answer: Avrora uses terminal characters for colorized output.
These may not be supported by all shells or may be unreadable for terminals with a light
colored background. To disable colors altogether, you can pass the
-colors=false option to the command line or put it in your
.avrora file in your home directory. To set the foreground
color to a value other than light gray, you can pass the
-foreground-color=color option with the particular color of your
The problem with light backgrounds has been corrected in the 1.5.x series and will not
occur in Beta 1.6.0.
- Q: My command line is getting long and redundant! Is there a way
to store repeated options in a configuration file?
- Answer: Yes. Beta 1.4.0 introduced the
-config option which accepts a filename that contains a
list of options and their values. It uses the same format that all Java properties files
do (i.e. name : value or name = value
each on its own line). Also, if you put a .avrora file in
your home directory, this file will be loaded each time Avrora starts. The order of parsing
options is as follows:
- Your .avrora file, if it exists.
- The file specified in the -config option.
- Command line arguments.
- Q: The LEDs are not blinking on my sensor program. What is wrong?
- Answer: First, check that you are targetting the right platform.
The mica2 platform is accessed with -platform=mica2.
Mica2 is the default for sensor network simulations, but not for single node simulations.
Second, check that your program has not gotten stuck in some infinite loop before initialization.
You might try -verbose=all to see what is happening in each device
or -monitors=calls to enable tracing of the call/return behavior.
Third, you might try -monitors=packet to see what packets (if any)
the program is sending over the radio. You can also try to set timeouts or breakpoints in the
simulation so that it stops at a particular time or location.
- Q: Avrora is having trouble loading my executable file.
- Answer: Avrora relies on avr-objdump to
disassemble binaries before they can be loaded, and it is (at the moment) very picky about
what input it will accept. Please see the page on objdump and
follow the instructions step by step. If you are still having trouble, contact the
mailing list. We are hoping to improve this part of Avrora soon.
The objdump loading support has been improved considerably in the 1.5.x
series. You should expect much fewer problems in Beta 1.6.0.
- Q The output of my program comes out much faster than real time. Is it
possible to slow it down?
- Answer: Yes. Introduced in Beta 1.2.0, the -real-time
option will slow the simulation down so that it does not exceed real time. This can be useful for programs
that are mostly idle and simulate quickly.
- Q: How do I run a multiple node simulation with different programs on
- Answer: You can use the -nodecount option
which accepts a list of integers. The numbers in the list correspond to the number of nodes
that should be instantiated with each program passed on the command line. For example,
if -nodecount=2,1 is passed and the arguments are
CntToRfm.od RfmToleds.od, then two nodes will be instantiated with
the CntToRfm application and one node with the RfmToLeds program.
- Q: In my simulation, all the nodes are synchronized because they start
at exactly the same time. Is there a way to "unsynchronize" the start times?
- Answer: Yes. The multiple node simulation supports two options
that perturb the starting time of each node. The -random-start
option accepts an interval in clock cycles. When specified, each node's start time will
be delayed by a pseudo-randomly chosen number of cycles in this interval. For example,
if -random-start=[0,1000] is specified, each node will be
started at a random time between 0 and 999 clock cycles, inclusive. The numbers are
chosen in a pseudo-random fashion; to specify a seed to the random number generator
(for repeatable simulation results), specify the -random-seed
option. Also, you can use the stagger-start that will stagger
the start times of the nodes by the number of clock cycles specified. For example, if
-stagger-start=100 is passed, the first node will start at time
0, the second at time 100, the third at time 200, and so on.
- Q: Is there any way to make the simulator output the time for each event
in seconds rather than clock cycles?
- Answer: Yes. The -report-seconds option
will cause the simulator to report the time for each event in seconds rather than clock
cycles, which is more readable for long-running simulations. Also, the
-seconds-precision option will set the number of decimal places
reported for each time in seconds.