Data Acquisition Unit
February 2014. This is no longer under development. It was to be a
development board oriented to data acquisition projects but
advances in microcontroller technology have now provided much of
the functionality on-chip. Parts of the software may be used in a later project.
The Data Acquisition Unit (DAU) was conceived as a tool for unattended 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.
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, I2C, 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.
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.
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.
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:
Contact: My email address can be constructed from the username "ksarkies" and the ISP DNS address internode.on.net in the usual way.
created 26 October 2004
Last Modified 15 February 2014
© Ken Sarkies 2006