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. The I2C access is controlled by an arbiter. The platform specific implementation needs to wire the I2CPacket interface to the platform specific I2C bus (including wiring the Resource to the arbiter). 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 (it is an 8 channel chip).
    • 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.
    • The code has not been thoroughly tested.

• MICAz Implementation - Provides a generic configuration that passes through the channels and connects I2CPacket and Resource to the I2C bus on the MICAz. The atm128 microprocessor has the I2C protocol implemented in hardware. The Atm128I2CMasterC uses the hardware implementation of the I2C protocol.

• MTS420 Implementation - The sensorboard specific implementation needs to have a component available called HplAdg715C which is generic and passes through all 8 channels (named Channel* where * is a number 1 through 8) from adg715ControlC and wires the platform specific I2C code. See the MICAz for an example.

MTS420CA/CB GPS

Using the MTS420 GPS unit involves the code that interfaces with the Leadtek GPS-9546 chip and also the supporting code (SyncUartStream interface and implementation and the NMEA code).

Leadtek GPS-9546

The Leadtek GPS-9546 specific code is fairly simple because the chip itself is mostly self contained. The documentation for the chip hints that programming of the gps chip itself is possible. But out of the box on the MTS420 sensorboard all that is needed is to turn on the chip and listen on the UART for bytes to come in.

• Independent Chip Code - Currently there is no independent chip code. If there is code written to program the gps chip there may be a need for independent chip code but currently the functionality needed is self contained in the chip.

• MICAz Implementation - The MICAz implementation wires the SyncUartStream interface and provides the StdControl interface to encapsulate the platform specific method of turning on and configuring the UART to 4800 baud.

• • ATM128 Implementation - The ATM128 on the MICAz platform had a couple problems that need to be fixed:
    1. The UART code had a bug in the implementation that was fixed by Rincon.I am not sure of the details of the fix. Try a diff to see what is different.
    2. There was no configuration interface so that was added.
    3. There was no access to UART1 so I copied the UART0 code and changed it to UART1 and it worked.
    4. The UartStream interface is async which is difficult to debug. 4800 baud is slow enough to justify a synchronous UartStream, hence the SyncUartStream interface.

• MTS420 Implementation - The chip code in the MTS420 only coordinates connecting the wires (via the ADG715 channels) and starting the UART (via the platform specific code -- see MICAz implementation for an example).

SyncUartStream

The SyncUartStream was chosen to simplify and speed the development of the driver for the gps. The baud rate is 4800 baud (by NMEA standard definition) which is much slower than the clock rate on the MICAz platform.

• Limitation - If the processor is too busy to process bytes coming in at 4800 baud then bytes will be dropped and information will not come in as fast from the gps (or not at all if the processor is extremely busy).

NMEA Code

Warning: The NMEA code was developed without the official standard and thorough testing is yet to be done. One known bug is the NMEA GGA code is not written platform independent using th nx_* types.

The NMEA code can be found in the TinyOS Sourceforge CVS repository in the tinyos-2.x-contribs/rincon/tos/lib/Nmea/ directory. The NmeaRawReceive interface is located there which is provided by the MTS420 code. The NmeaGgaC.nc has calls that require a nmea_raw_t message from the NmeaRawReceive interface to parse the packet. The NmeaPacket interface allows for the specification of type because as more NMEA packet types get support they can still use the same parsing interface.

See the readme.txt in the Nmea directory for more information.

See tinyos-2.x-contribs/rincon/apps/tests/TestMts420Gps/ for an example of using the gps driver.

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 (is it possible with the current hardware configuration?)
  • Controlling GPS (sending commands to 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.

Alternative implementation

An alternative independent implementation is available on the TinyOS Sourceforge CVS repository under tinyos-2.x-contrib/mts4x0/, it supports the gps driver with leadtek 9546.