MTS420 Progress

Completed Work

The documentation of progress should include some main features including, but not limited to:

• Implementation details
• Discussion on decisions made
• Limitations
• Suggested Improvements
• Feel free to include more information as well

Code Organization

The code for a sensorboard consists of multiple layers. This section describes how those layers are organized in the tos directory structure.

• Independent Chip Code - The sensorboard will be an assembly of different chips. Some of those chips will be complicated enough to merit platform independent code and should be located in tos/chips/<chipname> directory.
• Sensorboard Dependent Chip Code - Some chips will require code specific to the physical connections made on the sensorboard and the code should be located in tos/sensorboards/<boardname>/chips/<chipname> directory.
• Platform Dependent Sensorboard Code - Some code will depend on the specific platform it is being connected to (for example, anything that uses buses controlled by the platform). That code should be located in tos/platforms/<platformname>/sensorboards/<boardname>/ and organized in a similar chips/<chipname> sub directory as appropriate.
• Independent Helper Code - Code that can be written to be independent of the sensorboard should be added in an appropriate tos/lib/<name> directory.
• Dependent Helper Code - Code that exposes useful features of the sensorboard and is specific to the sensorboard should be located in the tos/sensorboards/<boardname>/ directory and any appropriate sub directories if required.

Power and Communication Connections

Power to and communication with the sensors located on the MTS420 sensorboard is controlled by two Analog ADG715 serially controlled octal switches. Those switches are controlled by an I2C bus. The ADG715 manual describes the protocol and calls it a two wire interface (TWI) but it is essentially the I2C Protocol.

• Independent Chip Code - The independent chip code for the ADG715 is written generically so that it can be instantiated for each specific chip on a given hardware platform. There is some error checking but it is by no means exhaustive.
  • Limitations
    • adg715ControlP provides a parameterized Channel interface but the values are limited from 1 to 8 inclusive, by ADG715_CH_MIN and ADG715_CH_MAX in adg715.h.
    • Constants are declared as enums without a check to see if they have already been defined because they are parameters that are fixed for the hardware this was designed for.
    • Reading the value (isOpen()) of a channel really only checks a cached copy of the state. The state is never actually checked to verify it was set properly.
    • adg715ControlC was designed for an I2C bus with an arbiter, hence the Resource interface requirement. If exclusive access is wanted, slight modifications would be needed.
    • The code has not been thoroughly tested.

MTS420CA/CB GPS

TODO

Remaining Work

• Documentation and Code for all sensors except the GPS on the MTS420CA
• Documentation for the GPS 420CA
• Documentation for supporting code
• Refining and Testing GPS Code
  • SiRF packet reception
  • Controlling GPS
  • Test Power (does GPS_ENA need to be high? what does GPS_PWR do?)
• How To documentation
  • How to use the code
  • File List

Where to find the code

The code is located in the TinyOS Sourceforge CVS repository. The \tinyos-2.x-contrib\rincon\tos\sensorboards\mts420\ directory contains the code that glues all the dependencies together. The .sensor file contains a list of all the dependencies that are also needed.

A simple example is located in \tinyos-2.x-contrib\rincon\apps\tests\TestMts420Gps\. It forwards NMEA GGA messages from the GPS over the radio where a mote running the base station app can receive the information. The NMEA parsing code is incomplete--users beware.