The open-source software stack of VirtualSense is based on a modified version of Darjeeling java-compatible VM running on top of Contiki operating system.

The VirtualSense Run-time is tightly integrated with the Contiki OS in order to make it possible for a Java programmer to fully exploit the low-power states of the underlying micro-controller unit (the TI MSP430F5418a).

VirtualSense exports to the application layer several Application Programming Interfaces (API) to allows the programmer to interact with the  hardware. The complete software stack source code can be downloaded from




Programming Model

In VirtualSense an application consists of one or more java files containing at least a class implementing the entry-point method the signature of which is public static void motemain(). Byte-code verification and transformation is done off-line by a tool called Infuser, which takes in input multiple class files and statically links them in loadable modules called infusions.
The infusion file is ready to be transferred, installed, and executed on the target nodes. Multiple applications (i.e., infusion files) can be simultaneously installed and executed on the same node. Any application instance running on top of the VirtualSense VM is called Task.

The multitasking support provided by VirtualSense allows multiple tasks to execute concurrently and share the CPU time. Once the applications are installed on the target nodes, the commands provide a remote interface to load, launch, stop, and unload them.

Preemptive scheduler

VirtualSense schedules its running tasks by means of a preemptive time-sliced Round-Robin policy (RR). Preemption is performed by the VM by interrupting the execution of a task after a fixed number of byte-codes. The number of byte-codes determines the average frequency of preemption points.
At each preemption points the state of the current task is saved and a new scheduling decision is taken which can lead to a context-switch.

Network Stack

VirtualSense communication relies on Contiki MAC layer, which provides a simple duty cycling mechanism to reduce the power consumption of the radio module by keeping it turned off for most of the time without impairing the capability of the node to take part in network communication. This is done by periodically waking up the radio module to sense the channel and wait for incoming packets. In order to relax synchronization constraints, unicast packets are iteratively sent until an ack is received, while broadcast packets are repeatedly sent in a time window large enough to guarantee that they are sensed and received by all the nodes in range.

On top of Contiki MAC layer a java communication library has been implemented which makes available event-driven send and receive primitives to achieve two goals: to provide the generality required to enable the implementation of advanced communication protocols in Java, and to make it possible for a Java thread to react to incoming messages without keeping the MCU busy while waiting.