Data Acquisition Unit

The Data Acquisition Unit (DAU) was conceived as a tool for data capture over long periods of time. Commercial data acquisition units are available at a cost. They are normally oriented towards laboratories, industrial plants or field work, the latter two being ruggedized and quite expensive.

A number of possible applications for this unit are envisioned, ranging from high speed data capture (storage oscilloscope style) to field data capture. This immediately makes the project unreasonably large, so it has been narrowed down to something relatively simple that can be developed as a pilot project. The measurement of voltage and current over time in a photovoltaic solar electric system is an excellent starting point as it involves only very low frequencies and moderate accuracies. Even this however turns out to be quite a major undertaking. In presenting this here I hope to demonstrate how a number of design difficulties were overcome.

My interest is in embedded microcontroller applications. It is well known that (almost) any electronic project requires an embedded microcontroller, therefore I turned to the Atmel AVR series of microcontrollers. As mentioned in other pages, these are very inexpensive, easy to use off-the-shelf, with simple interfaces for programming and a wealth of free and opensource development tools. Programming can be done through an interface that can be provided on any PC with a parallel port and an old printer cable.

The DAU is developed as a set of modules. The microcontroller module controls the acquisition process and communication with a PC. This can be common to a number of different signal processing modules. As such the development of the software and interface protocols were done with generality in mind.

As the DAU is controlled internally by a microcontroller it can be classified as a STIM - smart transducer interface unit. It should be able to perform data capture independently to a degree limited by its internal memory.

Standards

The first thing to determine before beginning the design is whether there are any standards relating to STIMs and their interfaces. It is important to try to make use of standards as far as possible, even defacto standards, so that software development may have access to reusable modules, and be compatible with existing packages. In the field of Data Acquisition, a survey of standards yielded quite disappointing results. Most equipment used proprietary interconnection hardware and protocols. Standards that exist are diverse and conflicting and most are not accessible for perusal.

Communication protocols should follow the ISO layered protocol model to maximize access to standard equipment and infrastructure. In small devices such as STIMs it would be impossible to attempt to incorporate the full extent of this model, however there is much that can be done in the spirit of the model. Standard physical layer protocols that would be useable for example would be RS-232, RS-485, I²C, ethernet and CAN. On top of that would be built a datalink layer (already incorporated in Ethernet and CAN). The datalink layer would deal with addressing of devices in a multidrop system, which is quite likely to be needed in a data acquisition and control system. These form what is known as a fieldbus network, for which there are a number of existing standards [ref 4]. On top of the fieldbus would be built a messaging interface incorporating the network layer and transport layers much simplified. CANopen is one such system that incorporates device profiles that form an application layer.

Our interest is in providing an application level messaging protocol that will run over various network support structures such as those mentioned above.

MODBUS

This is a defacto standard used extensively for data acquisition and control. It is defined for command-response communications betwen PC and smart transducer on top of serial and TCP/IP supports. The standard is considered by some to be obsolete but others are pressing for its continuanc [ref 3]. One advantage of Modbus is that the standards and some software are freely available, making it aceible to opensource developers. Another advantage is its simplicity and ability to support small microcontrollers. However its binary serial message format makes use of specific timing to distinguish between messages, which is not compatible with normal UART usage, and places strict timing demands on devices. An ASCII serial message format is available but is less efficient.

IEEE 1451

One interface standard that does exist and seems to be still under development is IEEE 1451 [ref 1]. This defines an interface for smart sensors to communicate with processing machines. The physical interface that was defined was not common to any other physical interface. The standard has so far failed to excite much interest. A recent development seeks to define RS-232 and other more common interface standards as an alternative physical interface, which hopefully will result IEEE 1451 becoming more acceptable.There is an Open1451 project in Sourceforge that provides some software, however documentation is substantially lacking and there does not seem to even be a home page for the project.

Architecture

In order to develop the concept and to provide an achievable goal, the DAU was limited to low frequency voltage (or current) measurements. It uses readily available electronic components wherever possible, except where it is absolutely essential. The DAU was developed with the following broad features:

• Differential preamplifiers for input signal conditioning. This uses 1% precision metal film resistors for temperature stability and unfortunately uses relatively uncommon ICs to minimize the component count, which otherwise would be unreasonably high.

• AVR microcontroller with A/D inputs. Many of the ATMega series have multiplexed 10-bit converters, allowing a conversion accuracy of 0.1% FSD (3 digit conversion). These devices run at 8MHz or more.

• Serial communications over an RS-232 interface to a PC for storage and display of data.

Implementation Documentation

• Proposal Document
  

• PC interface protocol

• Microcontroller Module

• Sensor Conditioning Modules

  • Differential Voltmeter module

• AVR Software

• PC Control Software (User Manual and software).
  

• PC Test Software

References:

1. IEEE 1451
2. JDDAC Java Distributed Data Acquisition and Control software modules based on IEE1451.
3. MODBUS
4. Fieldbus
   
5. CANopen
6. Profibus