"Disseminate news and technical information about the use of smart interfaces for sensors and actuators."
Welcome to the inaugural issue of the "Smart Interfaces for Sensors" newsletter. Sponsored by Sensor Synergy, Inc., this newsletter provides news and descriptive information about smart interfaces, smart sensors, smart sensor standards, and related developments.
In addition to news and information about new technologies being developed to support smart interfaces for sensors, this newsletter presents helpful technical hints about sensor interfaces and smart sensor technology.
This newsletter is published monthly. For a free subscription, send your request and e-mail address to firstname.lastname@example.org
. In the subject line of the e-mail, enter "Free Newsletter Subscription Request".
To submit an article to this newsletter, contact the editor, James Wiczer PhD, via e-mail at email@example.com
, or via standard surface mail at "Sensor Synergy, 1000 Hart Rd, Suite 220, Barrington, IL 60010". Finally, the editor may also be reached at via phone at 847-353-8200 or FAX at 847-353-8232.
Smart Interfaces and Smart Sensors
Many claim that smart sensors will some day provide users with a wide array of special functions from network-ready sensor data to electronic data sheets.
Connecting sensor data to networks - like the World Wide Web - allows multiple interested individuals to view and capture data from physically separate locations. These network-ready, smart sensors will make sensor data available to all interested individuals with network access and the proper password. This enhances the value of the sensor by empowering a broader distribution of the sensor data and decreases the delay between data acquisition and data viewing for remote viewers.
Smart sensor technology can also provide electronic versions of data sheets often referred to as TEDS - Transducer Electronic Data Sheets. These electronic data sheets are available "on demand" through the same network used to collect and view smart sensor data. These data sheets provide an electronic representation of information about the smart sensor including prior sensor readings, sensor location, sensor use, sensor calibration data, sensor model number, and a free form web log with various details about the specific sensor being viewed.
In contrast to simple stand-alone sensor devices providing analog electronic signals related to the physical quantity being sensed, networked smart sensors provide a wide array of information to pertinent individuals, enhancing the value and availability of the sensor data by orders of magnitude.
Unfortunately very few integrated smart sensors are available today to provide these enhanced functions. Although international research and development efforts continue to provide some of these features on a limited number of sensors, the complexity of electronic intelligence and the wide variety of available sensors devices makes the widespread availability of smart sensors into a future vision. Today, smart sensor devices are practical only for a few types of high-volume sensors that can be fabricated with silicon micro-machining technology.
For the rest of the world, "Smart Interfaces" (such as Sensor Synergy's NEEM #112) may provide these enhanced features without waiting for your favorite sensor to be transformed into a futuristic smart sensor.
What is a smart interface and how is that different from a smart sensor?
The IEEE (Institute of Electrical and Electronic Engineers) defines a smart sensor as "a sensor that provides functions beyond those necessary to generate a correct representation of the sensed quantity. This functionality typically simplifies the integration of the sensor into applications in a networked environment."
This is a lengthy and precise statement attempting to capture the essence of all devices labeled as "smart sensors". However, in practice, probably more than 95% of smart sensors are highly integrated, monolithic silicon die that contain a silicon-based sensing element combined with additional silicon circuit elements to perform high-level interface, processing, and memory functions. Typically, smart sensors are fabricated with conventional silicon integrated circuit technology combined with MEMS (micro-electro-mechanical) fabrication techniques. This results in monolithically integrated devices containing sensors and additional electronic intelligence functions that are collectively referred to as smart sensors.
These electronic intelligence functions may include signal processing (amplification, filtering, clipping), analog-to-digital conversion, interfacing, data storage memory arrays, and data communication circuits.
There are many examples of these types of "smart sensors" in the market place from accelerometers used to trigger airbags during automobile collisions to blood pressure monitors used by the healthcare industry to monitor human patients.
Smart interfaces for sensors refer to the technology that provides features of smart sensors by using external circuits added to the sensing element device. This allows the user to benefit from smart sensor features while using their existing off-the-shelf sensor technology.
One benefit of smart interfaces is that sensor devices can be transformed into a virtual smart sensor without waiting for sensor component manufacturers to provide integrated "smart" versions of each sensor in their catalog. These smart interfaces enable the use of one's favorite, existing sensor component in applications that benefit from the use of "smart", networked sensors.
Smart Sensor Limitations - Cost and Technology Compatibility Issues:
In fact, many sensor component technologies are not compatible with higher levels of functional integration and may never become monolithic integrated smart sensors. That is, existing fabrication technology may not support the inclusion of signal processing, electronic data sheets, data memory, and networking circuits into the same package as your favorite sensor component. For example, certain types of chemical sensors use materials and processes that are incompatible with silicon integrated circuit manufacturing.
It should also be noted that in certain operational environments (such as ambient temperatures greater than 200 C), sensor components may operate correctly but "intelligent" silicon-based electronic circuits may not survive. For example, many thermocouples can operate without difficulty at temperatures that cause intelligent silicon circuits to become molten pools of liquid silicon.
Smart Interface Uses:
Monolithic integration of sensing elements with microelectronics intelligence onto a single silicon die may be an expensive and, in some situations, technically inappropriate approach to provide the features of smart sensors. In many instances, due to low projected smart sensor quantities and process technology hurdles it may not be economically feasible to perform die-level electronic integration of smart sensor devices. The best approach for implementing some smart sensor features for these situations may be to use external microcontroller, memory, and data conversion circuits.
In fact, even in many situations in which monolithic integration of silicon-based sensors with silicon-based signal processing circuits is technologically feasible, using "off-chip" signal processing and intelligence functions still reduces costs and enhances design flexibility. This is in part due to the volume sensitive cost aspect of custom integrated circuits and in part due to the difficulty (i.e. cost enhancements) of integrating sensitive analog functions with digital functions on the same die.
Instead of tightly integrated, monolithic smart sensor silicon devices, virtual smart sensor solutions developed with "smart interface" external components may result in less expensive solutions that are faster to the marketplace.
It should be noted that there are currently some highly integrated, smart sensor technologies that provide cost-effective solutions. Devices such as vibration sensors, accelerometers, pressure sensors and moderate-environment, temperature sensors are examples of successful smart sensors. But for others applications, it may be necessary to use adaptable smart interfaces that combine the functionality of signal processing circuits, interface circuits, electronic datasheets, measured data storage memory, and network circuits into a single smart sensor interface that serves as the intermediary to connect networks to sensors.
There are now available smart transducer interface units that provide many of the more useful features of standards such as the IEEE 1451.2 and include adaptable features that make these interface units able to connect to a broad array of sensor types. One example of this technology is Sensor Synergy's NEEM-112 product. This approach provides for some of the key features of smart sensor technologies such as ease of use, quick configuration, sensor-specific electronic data sheets, and self-identification capabilities without requiring sensor manufacturers to re-work their product offerings.
For example, a smart interface, like the NEEM-112, when combined with a discrete sensor component, can network enable your sensor data for Web access or access on your local area network with minimal effort and no programming. This solution can also make your sensor data directly available to remote Excel spreadsheets through Active X controls accompanying the smart interface. This solution can even send an e-mail notification to your cell phone when your sensor reading exceeds a threshold value!
In summary, smart sensor interfaces can transform simple "brain dead" sensors into virtual smart sensors complete with all of the features expected from tightly integrated smart sensors but without the custom IC development.
PC Based vs Web-Based Sensor Data Acquisition
Consider the issue of selecting the most appropriate sensor data acquisition approach for your application. Two possible approaches are considered here:
- PC-based solutions using conventional PCs, plug-in hardware boards, and programmable software tool kits.
- Web-based solutions using miniature, embedded elements and fixed-feature, pre-programmed software solutions.
PC-based Sensor Data Acquisition
For this type of Sensor Data Acquisition approach, the required key elements include -
This approach uses general purpose computing hardware combined with supplemental data acquisition hardware and data acquisition software tools to acquire data, process data, display data and, if required, serve data to remote users via network connections.
- A PC platform with network interface capabilities
- Sensor interface hardware - typically a analog-to- digital conversion plug-in interface electronics board
- Software tools to acquire the data and process the data as needed
- Software to display the data locally.
- Software to serve data to web clients as needed.
Strengths of PC-based Sensor Data Acquisition:
PC-based systems leverage inexpensive, highly capable computing hardware with some specialized data acquisition hardware and highly customizable software tools. PC-based solutions can result in sensor data acquisition systems precisely tailored to satisfy exact application requirements; elaborate software and hardware customization can be achieved with a wide variety of tools. Highly complex, fully programmable control algorithms used in fast-response, closed-loop control applications may benefit from PC-based solutions.
Weaknesses of PC-based Sensor Data Acquisition:
Software tools require high skill-level custom or semi-custom programming. Initial installation, integration and setup of all elements may be time consuming (including PC setup, software upload, hardware configuration). Total system acquisition costs and elapsed time required for installation, setup, custom programming and validation may be an issue for some applications. Hardware ruggedness, maintenance, footprint, power, and (physical) access control of PC may also be issues for some applications.
Web-based Sensor Data Acquisition
For this type of Sensor Data Acquisition approach the required key elements include -
This approach uses specialized embedded computing and data acquisition hardware coupled to microweb server technology to acquire, process and serve data to web-based remote users. Dedicated software is used to control these hardware elements and serve data.
- Dedicated analog-to-digital conversion hardware and controlling software.
- Micro-web server hardware to perform network interface operations
- Software to interface ADC hardware with network server and software tools for initial configuration.
- Web-based computing resources (web-browser) to process and/or view the data as needed.
Strengths of Web-based Sensor Data Acquisition:
Dedicated data acquisition software, customized for hardware configuration, makes setup easy and quick. Total system acquisition costs and minimal setup time can result in a low-cost, rapid solution to providing live sensor data to the web. Authorized, remote web-based users can access data as needed. Remote users can process, store and integrate data as required. Small footprint, low-power requirements, low maintenance, rugged enclosure, and easier physical access control may enhance the value of the Web-based solution in some applications.
Weaknesses of Web-based Sensor Data Acquisition:
Limited local computing resources may require additional web-based computing resources for extensive post-acquisition processing. Limited programmability may limit suitability for certain specialized applications. Highly complex control algorithms used in fast-response, closed-loop control applications may require PC-based solutions.
Analysis of PC-based and Web-based Approaches to Sensor Data Acquisition
(The following statements are broad-brush generalizations and therefore an ample number of exceptions can be found for each statement.)
A Web-based approach frequently uses embedded microcontrollers with "light weight" computation resources but these computing resources are adequate for many limited bandwidth, limited sampling rate sensors. PC-based approach frequently uses "state-of-the-art" CPUs because these computation resources are standard in generally available Commercial-Off-The-Shelf (COTS) PC units.
PC-based solutions may be preferred for certain applications that require intensive raw data processing before meaningful sensor data can be inferred. For example, high-speed image processing applications searching for subtle 2-D or 3-D changes from a nominal image will benefit from extensive PC-based CPU and memory resources.
However, many sensor data acquisition applications require moderate to low-bandwidth capabilities and very limited CPU resources. For these solutions, the embedded CPUs used in Web-based solutions are completely adequate. For example, many types of commonly used sensors make relatively modest processing and bandwidth demands on connected data acquisition systems. These include temperature sensors (thermocouples, thermistors, semiconductor thermometers, etc. ) pressure sensors, level sensors, flow sensors, distance sensors, event counters, presence detectors, chemical sensors, strain gages and many others. These sensors inherently require relatively modest sampling rates since the physical processes being monitored often can only change at a relatively slow rate.
Solution costs can drive many decisions. A comparison of the costs of a PC-based sensor data acquisition system with a Web-based sensor data acquisition system involves common cost features, including quantity of deployed systems, time to develop and deploy a solution, complexity of required solution, quality/ robustness of solution, and sensitivity of the resulting system to variances.
In addition to these standard cost issues, other features may also be pertinent in analyzing costs - specifically tolerance to variations in requirement specifications. By analogy, this might be compared to the classic make vs. build trade-off. If a system is made to the exact customer requirements, it will do exactly what the customer requested in the manner requested by the customer. The "buy" off the shelf system may not provide the exact features requested by the customer but may solve the main problems for 10% to as little as 0.1% of the cost of the custom solution. In the office automation world, one might consider the cost of a custom accounting system vs a commercial-off-the-shelf (COTS) system (e.g. QuickBooks). Although the COTS accounting system may require some small changes in business practices, the cost differential between the COTS solution and the custom solution could be a factor of 1,000!
For the case of acquiring sensor data and making this data available on the Web, custom programmed PC-based solutions will satisfy all of the system requirements for most applications; however, a COTS Web-based solutions can provide acceptable capabilities for many sensor needs for a small fraction of the cost of the custom solution. The stated requirements for many sensor data acquisition needs may be modified as an engineering trade-off when significant cost or elapsed time advantages are present. This trade-off can make fixed feature Web-based solutions more desirable due to cost and solution implementation time advantages. Custom programming a PC-based solution creates the precise set of requested features but can add significant programming costs and elapsed time before a solution is available.
In assessing PC-based vs. Web-based sensor data acquisition solutions, quantity becomes a more complex issue. If Web-based data processing and data storage is acceptable, the use of a single Web-based PC that can access many local, smaller, lower power, lower cost Web-enabled, embedded installations may result in very significant cost savings. These savings are apparent when comparing the small Web-based sensor data acquisition, data storage, and data processing solution to the installation of many local PC-based solutions in close proximity to each sensor. In addition, for most sensor acquisition solutions, PC-based hardware costs may not benefit from further quantity dependent cost reductions since PCs already experience significant cost benefits from the large quantity of PCs used in other applications. Embedded Web-based solutions will significantly benefit from quantity dependent cost reductions.
For low quantity applications, the cost analysis is much more straightforward. The common trade-off of custom versus COTS can be applied so that fixed feature sets in Web-based solutions are compared with the feature flexibility of custom solutions. Fixed feature Web-based solutions will be less expensive since costly, labor-intensive, custom programming and validation testing will not be required. In contrast, custom solutions will contain all of the required features specified for the particular application under consideration.
Helpful Hint: Using Inexpensive LEDs as Optical Detectors
For some applications, an inexpensive, readily- available, LED can be used as an optical detector. Although not generally touted as optical detectors, most LEDs can be used as detectors without harming the device in any manner. In fact, most LEDs can perform double-duty in the same circuit without changing the LEDs physical or electrical connections.
The trick is to electrically bias the LED in the proper current-voltage (I-V) quadrant for operation as a detector and to detect an appropriate range of wavelengths.
The LED, as the name (Light Emitting Diode) implies, is electrically a diode and can be used as a detection device similar to a photodiode. LEDs are first cousins to photodiodes and have some similar optical and electrical properties.
Rule of thumb #1: LEDs will not respond as rapidly to optical rise and fall times and PN or PIN photodiodes.
A properly biased, good quality photodiode will have sub-nanosecond time response and be able to detect the rise and fall time of light pulses shorter than 1 nanosecond in duration, an LED used as a photodiode may only be able to detect 100 microsecond optical rise times and may not do well in detecting pulses shorter than a millisecond. However, if you are trying to detect if the room lights were turned on or if an outside door was opened during the day, this might be the ticket to an inexpensive, readily available optical detector.
Rule of thumb #2: LEDs will only detect light of wavelength shorter than the wavelength of light that the LED would emit if it was put in a circuit that forward biased the LED.
For example, a red LED will detect light emitted by a yellow LED and a yellow LED will detect light emitted by a green LED but a green LED will not detect light emitted by a red or yellow LED. All three LEDs will detect "white" light or light from a blue LED. White light contains a blue light component which can be detected by the green LED. Recall that visible light wavelengths can be listed from longest wavelength to shortest wavelength as Red, Orange, Yellow, Green, Blue, Indigo, Violet (remember the mnemonic "Roy G. Biv"). Violet is the shortest wavelength light with the most energetic photons and red has the longest wavelength light with the least energetic photons of all of the visible colors of light.
Rule of thumb #3:To use the LED as an optical detector, do not forward bias the LED into quadrant # 1 of the current-voltage (I-V). (Quadrant 1 is when the operating voltage and current are both positive.) Allow the LED to operate in the solar cell mode, quadrant #4 (operating voltage is positive, current is negative), or in the photodiode mode quadrant #3 (operating voltage is positive, current is negative).
Photodiodes are typically operated in quadrant 3 of their I-V characteristics. In this mode, a small reverse bias voltage is applied to the device and the incident light linearly increases the leakage current proportional to the intensity (actually the number of above bandgap photons) of light falling on the photodiode die. Although LEDs are not intended to experience large reverse bias voltages, most can be reverse biased by a few volts (3v to 7v) and operate in the photodiode mode. Make sure you limit the magnitude of the reverse current so that you do not damage the LED. The photodiode mode will give the best time response and the most linear sensitivity to light. You can expect sensitivities of a few tenths of a microamp of current for each microwatt of optical power directed at the LED (or photodiode die).
In the solar cell mode, no applied bias voltage is used. The solar cell (or LED in this case) generates its own current and voltage.
To make the LED act as a current generating device proportional to the magnitude of light incident on the LED die, use the "short circuit mode". External circuit conditions and the amount of light incident on the LED die determines the current-voltage operating point of the device. If you keep the generated voltage across the LED low by using circuit techniques to effectively put a short circuit across the LED, the generated current will be approximately linearly related to the amount of light incident on the LED. This becomes similar to the photodiode mode. The simplest approach to this circuit is to put a relatively small (know value) resistor across the two terminals of the LED and measure the small voltage generated by the current flowing through your known resistor. Experiment with the size of the resistor; the best value will depend on the amount of light you are detecting and the optical arrangement to capture this light onto your LED. Try 100 ohms, 1,000 ohms and 10,000 ohms. If you are using the NEEM-112 to detect this signal, use one of the +/- 2.5 volt channels for 16 bit sensitivity (approximately 75 microvolts resolution).
To make the LED act as a voltage generating device, operate in the open-circuit mode by connecting either no load resistor or as large a resistive load to the LED terminals as possible. In the no load resistor mode, the voltage measuring instrument will serve as the load. If the input impedance of the measuring instrument is high enough, the circuit conditions attached to the LED will appear as an open circuit condition. If you are using the NEEM-112 to detect this signal, use any of the voltage sensing channels including either of the 0 to 5 volt channel, either of the +/- 2.5 volt channels, or the +/- 10 volt input channel. In this voltage generating, open circuit mode, the LED will generate an open circuit voltage between 0.0 volts and approximately 1.6 volts - depending on the amount of light incident on the LED die and the color of the LED selected for this measurement. Remember, in the open circuit mode, the magnitude of the voltage is NOT linearly related to the amount of light incident on the LED die.