The microserver runs nesC code emulated by the EmStar environment. NesC code and EmStar are used for the microserver applications to share as much code as possible with the motes. EmStar is also used to create socket servers to communication over a TCP socket with other networked computers and device files used to communicate data with applications outside EmStar running on the same local computer. EmStar is also a good environment for debugging not only microserver code but mote code as well.

Unpacketizer

In general, UnpacketizerM is the SampleSet entry point for microserver VanGo applications. All packets received by the microserver are forwarded to UnpacketizerM where they are de-marshaled in the exact opposite order as marshaling in PacketizerM. The de-marshaling takes place in the SampleSetM library. SampleSet first creates a new SampleSet and fills the SampleSet with values extracted from the packet. SampleSet then reads the send_mask from the received TinyOS packet; send_mask is the very first value in a SampleSet data structure and hence the very first value in the resulting packet created from a SampleSet. The SampleSet reads the send_mask and extracts data out of the packet only if the data is present. After the SampleSet data structure is filled with all the header values, the attributes are extracted followed by the data. The resulting SampleSet is pushed into the microservers filter chain.

DataSocket

DataSocketM is responsible for making all SampleSets processed by the microserver available on a TCP socket for remote applications to use. DataSocketM uses the EmTOS SocketServer module to create a socket that listens for connections on the default port 8003. The DataSocket takes all SampleSets pushed in to it and converts them into the equivalent sample_set_hdr_t data structures. The new data structure is an expanded form of a SampleSet; data and all attributes are saved as elements of the structure as opposed to pointers to memory. This is also a marshaling process used to convert SampleSets into data structures that are easier to send over sockets or device files and easier for remote applications to understand.

...
typedef struct sample_set_hdr_s {
  uint16_t send_mask; // which fields get transmitted
  addr_t src;
  uint8_t modality;
  uint8_t channels;
  uint8_t version;
  uint8_t format;
  uint16_t rate;
  uint16_t mean;
  uint16_t md;
  uint16_t duty_cycle;
  timestamp_t timestamp;
  uint32_t sample_number; // first sample number in set
  length_t sample_count;  // number of samples in set
  uint16_t flags;
  gate_info_t gate_info;
  zerocrossing_info_t zerocrossing_info;
  //spike_info_t spike_info;
  uint8_t data[0];
} __attribute__ ((packed)) sample_set_hdr_t;
...

The marshaling is very simple. A sample_set_hdr_t buffer is allocated; all SampleSet structure values are copied over to a sample_set_hdr_t. Next, the attributes that are handled by the sample_set_hdr_t (mainly gate_info_t and zerocrossing_info_t) are copied over followed by the data. The resulting buffer is pushed into a EmSocketServerI module where the data is made available to all connected clients.

FilterChainEnd

FilterChainEndM is responcible for dealocating the SampleSet as soon as it is not needed. FilterChainEndM is placed at the end of a filter chain.

ControlSocket

ControlSocketM has already been discussed above. It is responsible for interpreting commands received over port 8000 and sending the resulting commands to the motes.

Debugging

EmStar also provides a method by which a mote can be emulated on a PC (including the radio connection) and mote code can be debugged to a certain degree using log statements. (Certain degree because the emulation is not very accurate and cannot substitute for debugging using live motes.)