Testing Details:
We provide you with a number of components that allow us to test and modify certain parameters. Your application will need to wire these components. However, to lower the burden on you application, we have implemented these components so that they require minimal changes to your application.
TestDesyncC
First, we need to be able to test the accuracy of your desynchronization. We provide TestDesyncC component that your application needs to wire (see TestDesyncAppC for an example of such wiring). TestDesyncC component assumes that you use setAlarm() command provided by SysTimeC.SysTime64 interface. This is important - if you don't wire TestDesyncC or don't use setAlarm() command we won't be able to test your code!
Short description of how TestDesyncC works: it wires GenericComm to receive desyncQuery messages from the base station. Since all motes are physically co-located, all nodes receive the query message at the same time. So when TestDesyncC component receives the query message, it records the current time as well as the time when the alarm will fire next time (through SysTime64.getAlarm() command). Both these times are reported back to the base station. This allows us to calculate the Desync offset of the current mote (knowing the Desync period T).
RadioWrapperC
The second part of your assignment requires you to implement Desync algorithm over multiple hops. We cannot simply move motes far apart from each other, because we wouldn't be able to test Desync accuracy as described in the previous paragraph. Therefore, we will simulate multi-hop networks in software. We provide a RadioWrapperC component for this purpose. Instead of using GenericComm as you were used to from the warmup project, you'll use RadioWrapperC to broadcast your desync radio messages. Additionally, you'll need to program your motes with IDs between 0 and 7. Unfortunately, ID assignment for imote2 has not been fine-tuned yet - so each time you want to change nodeID, e.g. to 1, you need to recompile the application using 'PFLAGS+=-DMY_ADDRESS=1'. or simply typing 'ADDRESS=1 make imote2 debug' when using the Makefile in MainProject.zip. Your tinyos application can access this nodeID by reading TOS_LOCAL_ADDRESS constant.
Short description of how RadioWrapperC works: it wires GenericComm commands for both receiving and transmitting Desync messages (which are just empty messages in the original paper). When transmitting a Desync message, it appends the local ID to the end of the message. Therfore, the receiver drops the message if it comes from a node with which it has no radio link. The receiver decides this using 'neighborsMask' where i-th bit specifies if it has connection to the node with ID=i. It is initialized to 0xFF, so that all nodes talk to each other. We can change this mask online by broadcasting a 'settings_t' message.
The code for the main project can be downloaded (here)