- A new release has been made today (4/8/2011) that is compatible with OMNeT 4.2.
This page discusses installation issues, usage, bugs and other topics related to NesCT. If you are new to this package, see the NesCT home page.
There may be bugs in your NesCT distribution. Please check Bugfix Pages.
Limitations and FAQ
What is so special about NesCT, why should i use it ?
- TOSSIM's debugging aid tools are inadequate and you'll lose a lot of time inspecting log files.
- OMNeT++ has better GUI support, you can slow down or increase the speed of simulation at runtime. Even you can run your simulation until an event occurs or until some simulation time. This is very handy while debugging.
- You can see the overall view of the network, while the messages are being transmitted. With this, you get better grip of what you are doing.
- OMNeT++ is faster than TOSSIM, you may run your simulations for hours instead of minutes.
- You can mix different applications into same simulation. While one node may run CntToLedsAndRfm, the other may run TOSBase,RfmToLeds or Surge. Assumption of a homogoneous network is dangerous for real life applications.
- With the integration of MF, you can run your simulations in a mobile testbed. You can assign some of the nodes to have mobility using a mobility model from various flavors.
- MF incorporates more accurate physical layer than TOSSIM. However, the radio included is an 802.11 radio. You can tune the parameters such as transmission range, speed, delay etc. so that it can model your existing WSN radio.
- NesCT encourages you to write your code in NesC using TinyOS components and still make use of functionality from OMNeT++ and MF. The advantage of this is you write your code for actual hardware. You can test your implementation using a hardware with small modifications.
How do you compare NesCT + TinyOS 1.x with TinyOS 2.0 + TOSSIM ?
I know that TinyOS 2.0 is around for a while, but i really did not look into it. My latest information about TOSSIM includes the addition of a scripting language written in Python. You can trace the variables during simulation runtime with this feature. Luckily, OMNeT++ already has this feature. We don't need to worry about this.
TinyOS 2.0 also brings multiple instantiation of a single component. Suppose you have a nesC file with some implementation. Just like the relationship between a class and object, you can have multiple copies of same nesC component in memory.
How can i simulate a sensing phenomenon?
At the moment, when you make a call to any of the sensing interfaces; NesCT would return a random value. You can see this behavior in get_adc_data function of HPLADCC. To simulate sensing phenomenon, this function could be modified to return 0 for the time interval that phenomenon is expected to happen and return 1 when the sensing interface is polled during phenomenon execution.
Here is an example. If the simulation time is between 5 and 10, and node_id is 0 or 5 then a phenomenon occurred, else return nil. You need to check return value of ADC.dataReady at your application against 1 or 0.
if (simTime()<10 && 5<simTime())
{
int node_id = TOS_LOCAL_ADDRESS;
switch (node_id)
{
case 0:
case 5:
return 1;
default:
return 0;
};
}
else
{
return 0;
}
All things work fine except the node graphics show question mark (?) what's going wrong ?
I did not look into graphical issues too much and it's not such a big
problem. If you have installed OMNeT++ to some other directory, you need
to edit omnetpp.ini file in tictoc and modify it. It should point to bitmaps directory of your OMNeT++ distribution.
[Tkenv]
bitmap-path="c:/OMNeT++/bitmaps"
Why doesn't my protocol woth with NesCT & OMNeT++ even though it compiles to an executable?
This is usually caused by the usage of uninitialized variables. GCC fills all the memory with 0 before starting an application; whereas, MS compilers fill the memory with 0xCD.
In this case, your variables will have the value of 0xcd or 0xcdcd depending on the type of variable. The solution for this is not to depend on compiler for variable initializations and do custom initialization inside your init functions. Another strategy would be to assign 0 to all variables you declare. Then, NesCT would also initialize them during class construction.
How would you use your own application with TinyOS with NesCT?
- Copy all of your TinyOS components to components folder
- Copy your header files to include_tos folder.
- Use your starter component as Application.nc and follow the regular process
- Generate source code using NesCT
- Create a makefile
- Compile
- Run
What is the rest lines in the txc1.cc for? why they are there? Should I leave them for all other application I want to test.
Finish function is called at the end of the simulation and is there as
an example. This example collects statistics about the number of
messages sent and received. When you end the simulation, you'll see the
results coming from this function. It's up to you to remove it or not.
You need to leave handleMessage and HandleMessage functions there. These
are the functions which input the incoming messages to tinyos modules
and vice versa.
Compilation errors regarding variable initializations
NesCT translates your nesC code to C++ classes. In C++ world, it is not possible to initialize a variable directly inside class definition. Therefore, NesCT moves all variable initializations to the class constructor. When there is a global variable of array type, using nesC you would initialize the array with curly braces. Unfortunately, it is not possible to initialize an array with this style in a constructor. Hence, you need to change the initialization method. Often, Stdcontrol.init function is used for this purpose. Try to initialize the variable in a method before using and remove direct array initializations.
NesCT delivers all the messages, how can i simulate the radio ?
You have two options here: either use MF (Mobility Framework) or change your ned file. NesCT assumes that you are going to start developing from scratch. Therefore, it is important that your algorithm works in a lossless environment before enabling radio loss. Here is an example on how to change your ned file to include channel loss.
Define SensorComm at the beginning of your ned file. Tune the parameters according to your needs .
channel SensorComm
delay 0.060 // sec
error 5e-3
datarate 12800 // bit/sec
endchannel
Finally, replace the connections from :
tic[0].out++ --> tic[1].in++;
to
tic[0].out++ --> SensorComm --> tic[1].in++;
for all of your connections
Compilation errors with MinGW
NesCt may be compiled using. If you are using MingW, you'll need to add the following new lines to
gram.tab.c by yourself.
yyerrlab1:
#if !defined(__MINGW32__) // new line
#if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
__attribute__ ((__unused__))
#endif
#endif // new line
Compilation of example project fails with file unknown.
When you run NesCT over an example, it generates all the relevant source code in gen directory. To add the generated files into the compilation, another file, usually with the name of the example project (Relay.cc), is generated in example directory.
Here is an error example:
Relay.cc:19:31: error: gen/cRelay_Relay.cc: No such file or directory
Relay.cc:20:30: error: gen/cRelay_AODV.cc: No such file or directory
Relay.cc:21:32: error: gen/cRelay_RelayM.cc: No such file or directory
Relay.cc:22:30: error: gen/cRelay_Main.cc: No such file or directory
Relay.cc:23:31: error: gen/cRelay_LedsC.cc: No such file or directory
Relay.cc:24:37: error: gen/cRelay_AODV_Tables.cc: No such file or directory
Relay.cc:25:38: error: gen/cRelay_SimpleQueueM.cc: No such file or directory
Relay.cc:26:35: error: gen/cRelay_AODV_Core.cc: No such file or directory
Relay.cc:27:42: error: gen/cRelay_SingleHopManager.cc: No such file or
For this example, NesCT has been run over Relay.nc file and NesCT has generated source codes in gen directory. The files in gen directory were somehow deleted, but Relay.cc file still resides in example directory. Therefore, when you run make it still tries to compile relay.cc file. Either you need to run NesCT again to generate these source codes again or remove relay.cc file from the example directory and run opp_makemake/ opp_nmakemake again to change dependencies.
Why does my simulation terminates in xxx seconds?
The number of seconds that your simulation is expected to run is specified in omnetpp.ini file. The name of the parameter is sim-time-limit. If you comment out this line completely, then your simulation runs indefinitely.
I get linker error as multiple defined definitions, why?
Do not put your functions in your header files. NesCT makes your header files global and these header files will be included in many modules. This will in the end lead to multiple function definitions inside the executable
I get connection refused messages, why ?
If you start serialforwarder, you'll encounter these messages. Connection refused messages are quite normal. Serialforwarder repeatedly tries to establish connection to the application. You'll receive these messages, until the application is started and a connection is made between serialforwarder and your application.
Simulation terminates with assertion failed at findmodule function, why?
Do not hook up two generic interfaces such as "AMPromiscous and AMStandard" or "GenericComm and GenericCommPromioscous" into the same application. Normally, you need to choose one of them and make use of all around the application. However, there are TinyOS examples such as DSDV around that uses both. We modified DSDV to use only one of them. Under normal circumstances, TinyOS first tries to deliver message with the promioscous version if delivery fails, it tries it again with Standard delivery. NesCT does not have this functionality and expects you to use only one of them.
How should a beginner start playing with NesCT ?
For the first time beginners, you may leave MF aside and start playing with NesCT. When you feel that you are confident with NesCT, you can move to the MF integration. I'd suggest you to remove your existing nesct and tictoc directory, then install it according to http://nesct.sourceforge.net/install.html and try the examples at usage section: http://nesct.sourceforge.net/usage.html . Sometime later integrate MF according to http://nesct.sourceforge.net/mf.html .
Examples are working, but how do i develop my own protocol?
You have two options here. Either you modify the existing protocols according to your needs or create your own application. If you did not play with NesC before see Getting started with TinyOS here http://www.tinyos.net/tinyos-1.x/doc/tutorial/lesson1.html
Compilation error: > txc1.cc:11:47: error: gen/cCntToLedsAndRfm_TinyOSModule.h: No such file or directory
As far as i see, you get this error because you did not run nesct twice, one for CntToLedsAndRfm and one for RfmToLeds. You need to generate code for both applications. This is a multiapplication simulation. Therefore,
1. copy CntToLedsAndRfm.nc file over Application.nc, "cp components/CntToLedsAndRfm.nc Application.nc"
2. run nesct, "nesct.exe Application.nc"
3. copy RfmToLeds.nc file over Application.nc,"cp components/RfmToLeds.nc Application.nc"
4. run nesct, "nesct.exe Application.nc"
5. generate a makefile,"opp_makemake -c config -f"
6. make clean
7. make
make: /opt/omnetpp-3.2/bin/nedtool: Command not found
NesCT assumes that your omnetpp installation is in /opt/omnetpp-3.2 for linux and in c:\OMNeT++ for windows. If you have some other directory, you may consider renaming it or changing the configuration files accordingly. Besides, you may receive this error because you may have forgoten to include "/opt/omnetpp-3.2/bin" in your PATH environment variable. You also need to add "/opt/omnetpp-3.2/lib" to your ld.so.conf file in /etc directory. This is an OMNeT++ installation specific problem. Windows installation does this automatically for you.
The simulation crashes during startup after the integration of MF 2.0p2
Note that, for linux operating system the version of g++ seems to be very important. You may consider upgrading your compiler before starting if yours is not supported. With buggy versions of the compilers, your simulation will crash with segmentation fault at basicmodule.h line 105. I tested this using Fedora core 5 and g++ version of
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib
enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile
enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi
with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)
permission problem
chmod 777 temp/
./nesct.exe Application.nc
Write failed
Abort
NesCT uses temp directory for intermediary output. Make sure that NesCT has write access to temp folder and NesCT itself is executable. Use "chmod 755 nesct.exe" to make it executable. You may consider removing temp directory and allowing NesCT to create one for itself.
I am current having some issues with installing nesct using Linux.
I have been using windows recently and windows has changed the permissions for configure.
first make configure executable
chmod 755 configure
./configure
make clean
make
Compilation fails with file XXX not found
opp_makemake (opp_nmakemake for windows) command normally searches for any c files in the current directory, creates dependency files and a makefile. When we carry the software from windows, or when we run another simulation example than we intend to, opp_makemake asks for files left over. You need to run
opp_makemake -c config -f
twice to solve this problem. If there is still the same problem, run opp_makemake, then make clean and run opp_makemake again. if the problem persists, remove the redundant files from directory and run opp_makemake again.
Is NesCT compatibly with TinyOS 2.0
NesCT is only compatible 1.1x series of TinyOS. If you do not need java support tools, NesCT examples include modified and minimal set of TinyOS components. You are free to use existing components as well as use the ones from TinyOS. Beware that TinyOS components are not directly compatible with NesCT components. They may need small modifications.
Do i have to wait 10 seconds everytime i start the simulator ?
If your simulation does not interact with external tools, you can turn off wait-for-sf option in omnetpp.ini.
I get compilation errors trying to simulate XXX
Try to avoid same typedef and struct names across module implementations. Otherwise, you'll receive already defined error from the compiler. NesCT makes all struct and typedefs global. nesct compiles your c code with c++. there are several type checks that are not made with c. You'll need to clean them yourself.
Limits with # of prototypes,typedefs and structs
There are limits to the maximum number of prototypes, typedefs and structs that you may define in your code. Unfortunately, these limits are not tested. Therefore, if you get a segmentation fault during translation process, you may want to increase these numbers in main.h file. I have got this limitation while translating MNP code to OMNeT++. The limit of 25 per module was not enough.
MAC Layer
No MAC layer Instead of using the MAC layer transmission provided by Tossim, we use packet level transmissions from Tossim. The idea is to introduce some probabilistic fault code into the system. For the reason that tossim MAC layer has been written very much dependent onto the tossim simulation environment, we could not extract MAC layer functionality. We rely on mobilty framework and EYES Simulation Framework for the MAC layer.
MAC and Phy Layer
I read something about NesCT trusting on external OMNeT++ simulator constructs to simulate the MAC and PHY network layers. Is this true? Did TOSSIM have this limitation as well?
It is true that NesCT relies on other available simulation frameworks for physical and mac layers. There are two problems here that we need to discuss. First, implementing physical layer at NesCT would create needless efforts since the main focus of NesCT is to reuse TinyOS components with the available frameworks. Besides, i am working on this project alone and i do not have enough time to implement those details.
About TOSSIM, TOSSIM has some basic MAC layer built into the simulation environment. It is a basic CSMA protocol which is used in old mica nodes. Recently, i heart that they have also implemented the mac protocol of mica2 into the simulation. When i tested, old mica stack with the simulation, it was very very buggy and ineffective. People at Berkeley has seen this problem and put packet level simulation support into the simulation. This is until where i do the conversion. I make the conversion into OMNeT++ and borrow packet level simulation facilities from TOSSIM. This means that at the lowest layer i have a packet instead of bits. I feed the whole packet into mobility framework.
I read a document that said that you cannot receive messages, only send. Is this true?
nope, it used to be true in the old days, by the time i was starting.
Why shouldn't you join TOSBase and Your application into a single application ?
If you want to include TOSBase in your simulation environment, it needs to be a seperate application because TOSBase uses GenericCommPromiscous component to collect all the incoming messages regardless of the destination address.
Normal applications compile with GenericComm or Multihop routing component. This enables other applications to use your protocol with a simple configuration.
If you join these two applications into a single application, as nesct indicates in the warnings only one of the GenericCommPromiscous and GenericComm components will receive the message and the other will not. For this reason, your protocol will not work. I have tried the same issue with TOSSIM and got the same response.
In real life examples, usually node 0 is programmed with TOSBase and rest of the nodes with your application. TOSBase is going to deliver whatever packet it hears from the radio to the PC.
Have a look at Psfq example. It is possible to combine different number of appications into the simulation framework. Psfq example uses TosBase for node 0 and rest of the nodes run PsfqM.
How to send data to UART ?
Do not try to send data directly to UART using HPLUART. Nesct does not handle byte level communication. NesCT intercepts the simulation logic at the packet level boundaries. For this reason, i modified the original UARTNoCRCPacketM.nc from TinyOS to forward incoming messages to OMNeT++ instead.
You do not need to include HPLUART in your configuration. GenericComm directs the messages to UART if it is going for the destination address of TOS_UART_ADDRESS. Just include GenericComm and instead of sending it to the neighbors or broadcast (TOS_BCAST_ADDR) address in msg->addr, set it to TOS_UART_ADDRESS.
How fast is OMNeT++ & NesCT compared to TOSSIM ?
See the figures below. Reason: OMNeT++ is single threaded; whereas, TOSSIM is multithreaded.
Test Environment: p4 2.8 GHz, 512 MB, Fedora Core 5, TinyOS 1.15, gcc 3.2.3
Test Script:
#!/bin/bash
for i in `seq 1 20`;
do
time ./tictoc
done
Test Application: MnpBlink
NesCT + OMNeT++ TOSSIM
real user sys real user sys
0m0.408s 0m0.276s 0m0.020s 0m8.741s 0m4.510s 0m4.192s
0m0.411s 0m0.284s 0m0.016s 0m8.789s 0m4.468s 0m4.284s
0m0.333s 0m0.288s 0m0.008s 0m8.738s 0m4.404s 0m4.296s
0m0.337s 0m0.280s 0m0.020s 0m8.788s 0m4.556s 0m4.196s
0m0.337s 0m0.288s 0m0.016s 0m8.742s 0m4.600s 0m4.104s
How would you create random topologies ?
Here is an example. Replace your ned file with this and recompile your example. This example generates a random topology for the number of nodes and connectedness parameter specified.
simple Txc1
gates:
in: in[]; // declare in[] and out[] to be vector gates
out: out[];
endsimple
module RandomGraph
parameters:
count,
connectedness; // 0.0<x<1.0
submodules:
node: Txc1[count]
gatesizes: in[count], out[count];
display: "i=block/app2_s;";
connections nocheck:
for i=0..count-1, j=0..count-1 do
node[i].out++ --> node[j].in++ if i!=j && uniform(0,1) < connectedness;
endfor;
endmodule
network tictoc1 : RandomGraph
parameters:
count =input(4, "Number of nodes in the network:"),
connectedness = input(1,"Enter connectedness of the network:");
endnetwork
Note that, by default, the 01/10/06 release assumes that all nodes are connected. If you change the connectedness parameter, then you'll see your simulation crash during transmission. You need to edit SysIface.h file and add an if statement above line 54 as below:
if (parentMod->gate("out",i)->isConnected())
parentMod->send(nmsg_dup,"out",i);
Link Error: -lxml2 not found
> g++ tictoc1_n.o TinyOSPkt_m.o Blink.o cback.o csocketrtscheduler.o
> cTinyOSMain.o debug.o tossim.o txc1.o util.o -g -L/home/roberto/omnetpp-
> 3.2p1/lib -lenvir -ltkenv -L/usr/X11R6/lib -lX11 -ltk8.4 -ltcl8.4 -lsim_std
> -lnedxml -lxml2 -ldl -lstdc++ -lpthread -o tictoc
> /usr/bin/ld: cannot find -lxml2
This happens when you do not have xml2 library installed to your linux
distribution. Could you please check if your /usr/lib directory contains
libxml2.so.1 files or so ?
Usually, it is advised by OMNeT++ to be installed to the system. There is,
however, one other altnernative to xml2 and it is expat.
You may either try installing xml2, rebuild omnet++ and nesct or use expat
instead. To try, edit your config file and replace -lxml2 with -lexpat. If
this does not work, i suggest you to install xml2 library to your system,
rebuild omnet++ and nesct.
How to access simulation methods and config parameters from nesC code ?
here is an example on how to access the paremeters in omnetpp.ini
bool waitforgui = ev.config()->getAsBool( "General", "wait-for-sf", false );
you can access the parentmod first and then to omnetpp modules as follows
inside nesc code:
example:
parentMod->scheduleAt(simTime() + interval,msg);
Is it possible to run the Surge app with mobility framework in nesct?
Yes, it is possible to run surge application with mobility framework. Check this out:
http://nesct.sourceforge.net/mf.html
Once you have got an example working with mobility framework, the rest of the procedure is same
with other examples. The only difference is that previously index() function denotes node
number. Now, parentModule()->index() gives this information.
Why doesn't the omnet GUI simulation correspond to what's happening in the TinyOS dbg output when running Surge?
When I run the simulation, the omnet GUI only displays broadcast packets sent between the nodes, but the dbg output displays that Surge is sending data packets (i.e. packets with ADC info) and routing information.
The messages that are seen on console window come from TinyOS; whereas, the events
in TK GUI belong to OMNeT++ itself. That's the difference. You can of course export the routing table to OMNeT++, but this requires some mapping between TinyOS routing table and OMNeT++ GUI which is not there yet.
How can i introduce packet loss to my simulation ?
if you want to introduct loss, then you need to change the ned file. There are examples in ned directory.
Bit error rate is the parameter and is assigned to each communication channel by omnet++
Where does packet transmission occur ?
The part with M_SEND_REQUEST in txc1.cc is the old version of packet transmission. At some moment in development, i needed to collect system dependent functions into a class. If you have a look at mfw directory, there is another sysiface.h. This way, we achieve portability.
If you are porting nesct to a framework, you just need to write your own sysiface.h
In which application does M_LOGGER, M_FLASH and M_ADC get triggered ?
Normally, sensor nodes have a flash memory for saving ADC readings. If you want to utilize this capability, it is possible to simulate it. These kinds are set in components directory. If you search in components directory, you'll find them. M_LOGGER and M_FLASH is for saving purposes. M_ADC is set for every sensor reading request. M_TIMEOUT is the timer of tinyos. M_RECEIVE is for packet reception.
How would you use blackboard item while using mobility framework
Instead of,
bool TinyOSApplLayer::blackboardItemChanged(BBItemRef item){...}
bool TinyOSApplLayer::blackboardItemPublished(BBItemRef item){...}
bool TinyOSApplLayer::blackboardItemWithdrawn(BBItemRef item){...}
I have used,
void TinyOSApplLayer::receiveBBItem(int category, const BBItem *details,
int scopeModuleId){
Enter_Method_Silent();
BasicApplLayer::receiveBBItem(category, details, scopeModuleId);
...
}
to find out about updates.
What is the reason packet sent counters are not increasing ?
Message transmission path has been changed recently in order to increase portability. All system dependent functions including message transmission have been collected at SysIface.h. The section of txc1.cc, where packet transmission is counted, is no longer valid. To fix this two modifications need to be done.
First, set up a self scheduling message at sendNetworkMessage function of SysIface.h and add an handler for it at txc1.cc. Here are the modifications for each step respectively.
1) Add the following on top of sendNetworkMessage function in SysIface.h
{
cMessage *tx_msg = new cMessage;
tx_msg->addPar("kind") = "M_TX_DONE_STATS";
parentMod->scheduleAt(simulation.simTime(), tx_msg);
}
2) add the following code on top of "else if(strcmp(msg->par("kind"),"M_TASK_POST")==0)" at HandleMessage function in txc1.cc
else if(strcmp(msg->par("kind"),"M_TX_DONE_STATS")==0)
{
numRadioSent++;
RadioSentVector.record(numRadioSent);
RadioSentStats.collect(numRadioSent);
consumeRadioTx(MSG_DATA_SIZE);
delete msg;
}
Why does my application crash when I try to make multiple runs ?
I have been using bash scripts for multiple simulation runs in the past. Luckily, omnetpp already supports multiple runs with different parameters. However, the code that I borrows from Andras creates an exception.
Edit csocketrtscheduler.cc file in tictoc directory. comment out lines between 62 and 65
//~ if (module)
//~ throw new cRuntimeError("cSocketRTScheduler: setInterfaceModule() already called");
//~ if (!mod)
//~ throw new cRuntimeError("cSocketRTScheduler: setInterfaceModule(): arguments must be non-NULL");
What should you do if nesct fails to convert your code ?
I have removed some of these limitations from the code in the past, but some of them still remain. One thing you should know is that nesct is not compatible with tinyos 2.0 features. Therefore, if you are using such new options, it will not convert your code. In order to simplify your problem, you could start with an empty source with only function bodies. Try to see if there is any problem. If not, add your source into function bodies one by one until you hit a problem. That would be the safest approach. You can mix any of your sources with available components from NesC. They are there as a reference implementation. Maybe it is better to rename your components with a prefix or suffix so that your components will not get mixed with other people's code.
