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.
  • Answer: 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 December, 2007.
  
  
  
• 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 choice.
    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:
    1. Your .avrora file, if it exists.
    2. The file specified in the -config option.
    3. 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 different nodes?
  • 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.