Sensors - Sensor Signal Chain - Overview - EdsCave

Go to content

Main menu

Sensors - Sensor Signal Chain - Overview


26 Dec 2017

To understand how to design sensors into larger systems, one must understand what kinds of transformations need to occur between the phenomenon being sensed, the transducer and the sensor output which reports the measurement to the larger system of which the sensor is a part.  Although there are many types of transducers, which operate based on an equally wide range of physical principals,  we will not be spending too much time on this aspect of sensing. This series of articles will focus more on the commonalities in the electrical interface to such devices, and the subsequent means of deriving a useful measurement.

While the terms sensor and transducer are often used somewhat interchangeably, for the purpose of these discussions, we will define the transducer as the physical device that converts the sensed phenomenon to an electrical property, and the sensor as the system that contains the transducer and whatever electronic and software functions are required to deliver a report of the sensed quantity. In some cases, the transducer is the sensor – for example, a temperature transducer such as a thermocouple  converts temperature directly into a measurable (but very small) voltage, and can also be considered a complete sensor – although it becomes more useful when electronics are added to provide amplification and other signal processing functions.

There is an enormous range of transducers and ways of implementing sensors with them – far too many to ever cover comprehensively in any work.  One tool, however,  that can be useful for bringing a bit of structure to this menagerie is the signal chain.   

Most electronic systems of any complexity have two properties which can help both in  the design process, and subsequent understanding of that design:

Hierarchical structure.  Even moderately complex electronic systems are typically not designed as monolithic random collections of parts – when one is, it is often a sign either of bad engineering or an engineer looking for 'job security'.  In most designs, components that implement a  distinct  function are usually clustered together into a 'functional block', with clearly defined inputs and outputs. Even a relatively simple design  will often comprise a number of these functional blocks. More complex designs will often comprise a number of larger, more functional blocks, each of which may be repeatedly broken down into simpler blocks until you reach the component level.    The primary reason for designing this way is to manage complexity – and it does not take much unmanaged complexity to make a system incomprehensible.  A hierarchical design approach allows you to hide the details of the system in contexts in which they are not immediately relevant. For example, being able to define an amplifier as a 'block' which has a specified gain and bandwidth allows you to design that amplification function into the system without immediately having to perform the transistor-level design of the amplifier circuit.

Figure - When systems are constructed from many parts, it is common to organize them hierachically to make the design process easier to manage and the system more understandable

Explicit Causality – While there are circuits which contain hidden feedback loops which may blur the issue of what causes what. design at the level of functional blocks relies heavily on explicit and well-defined causality.  At this level, the system will be designed so that both energy and information flow in a specified direction.  Inputs are defined as ports into which information or power flows into (enters) a functional block, and outputs are defined as ports from which information or  power are delivered by (exits) the functional block.

The 'signal chain' representation of an electronic system is based on the use of both hierarchical abstraction and explicit causality.  A signal chain defines a system as a  group of top-level functional blocks, each with defined input and outputs, as well as the interconnections between those blocks.

Figure - In a 'Signal Chain', functional blocks are defined that perform well-defined functions

Figure - Although many interactions between functional blaocks are actaullay 'two-way', the signal chain focuses on the major ones, which are defined as unidirectional transfers of energy and/or information

While there are many possible ways of realizing an electronic interface to a transducer, at a very high level, there are a couple of functions that are commonly used, illustrated by the sensor signal chain shown below.

Figure - Generic 'Sensor Signal Chain' of functions needed to use a 'transducer' as a 'sensor'

Excitation. While some transducers convert some of the energy available in the sensed phenomenon into electrical voltage or current, many do not. In these latter types of devices, an electrical excitation source (voltage or current) is needed to make the transducer operate and output a detectable signal.

Front-end Detection and Amplification – The transducer will produce a voltage or current signal. Even in cases where the transducer 'outputs' some other quantity, for example capacitance, this is detectable only because it results in some kind of current or voltage output signal.  Some types of transducers will produce a sufficiently large voltage or current or voltage that it can be readily measured. In many other cases, the transducer will output only a tiny signal – and this may need to be amplified significantly before any subsequent processing may be performed on it.  

Filtering and Bandwidth Narrowing. While a transducer's output will hopefully contain the signal you are interested in measuring, it will also to some degree contain signals that you don't care about, and would rather not see.  These extraneous  signals include components resulting from both external interference sources and intrinsic noise sources. If these extraneous signals are of comparable magnitude to (or larger than) the signal of interest, this can make it difficult to accurately measure the true transducer signal. As Lewis Branscomb famously noted, "God loves the noise as much as the signal" [Branscomb 1985] – meaning that  nature's indifference between the two can make fishing the signal out of the noise one of the  more challenging aspects of sensor system design.

Signal Processing. Once you have a signal that is of usable magnitude and reasonably noise-free, the job is not necessarily finished.  While the signals produced by some types of sensors (e.g. Resistive bridges) directly represent a measured quantity (temperature, strain, etc..) through their magnitude, the signals produced by other types of transducers may require additional interpretation.  The classical example of this is a transducer that produces a frequency signal as its output. In this case, although you may have a large (order-of-volts) AC signal to work with, the actual measurement it conveys only becomes apparent upon measuring its frequency.
In addition, in some systems,  you may need to 'massage' the signal to get a meaningful measurement. For example, thermistors (a type of temperature transducer) have a very non-linear response to temperature. To get a signal which has a linear correspondence to temperature requires some type of linearization operation.

Reporting – Does a sensor that does not report its measurement really sense?  We are not going to leave this one to the philosophers, but flatly state that if a device does not report some kind of measurement, it may be something (a piece of modern art?) , but it isn't a sensor.  A sensor needs some means of transmitting its measurement to the outside world, or at least to the larger system of which it is a part.

Digitization – This 'block' performs the function of converting a continuous analog signal into a discretized digital signal – a numeric value -  and is often implemented using an Analog-to-Digital Converter (ADC).  Depending on the system, digitization  can occur at many different points. In a system in which the  transducer produces a sufficiently large signal, digitizing that signal right out of the transducer might make sense.  In the case where the signal is small and needs additional amplification and analog processing, it may make sense to perform the digitization further downstream. Note that it is possible to have a sensor that performs all of its signal processing in the analog domain and reports its measurement as an analog (voltage or current) signal -  and does not include digitization.  As the cost of good ADC's and digital processing power continues to drop, however, and the value provided by digital processing increases,  the inclusion of digitization, and subsequent digital processing will even more common in sensors.

Note that the sensor signal chain presented here is more of a conceptual guide to thinking about what things need to be done in order to use a transducer than an iron-clad design template. Any given realization of a sensor signal processing system may omit some of the functions,  rearrange their order, or combine them. As an example of omission, if a system is not especially noisy, an explicit filtering stage may not be used.   In other systems, the filtering function may be placed before the detection stage, or even tightly combined as an integral part of the detection stage circuit. Since it is a cliché to say that the possibilities are endless, I won't – and merely state that there are a lot of possible ways to implement these kinds of systems, even in the case of a single type of transducer.

Back to content | Back to main menu