Editor’s Note: It’s a classic architectural decision: which functions to implement in hardware and which to implement in software. Part 1 of this two-part series looked at design considerations and tradeoffs using comparators as an example. Here in Part 2, we will use peak detectors as the example.
As noted in Part 1 of this two-part series, it’s often assumed that software is the easy way to implement core functions, even though hardware-based solutions are often the better approach.
Getting to the “best” answer in a given situation requires designers to consider the tradeoffs among many design factors and performance objectives. This article will explore the hardware versus software decision tree from the point of view of the peak detector, while providing some examples.
Defining the peak detector function
Like comparators, peak detectors are a basic circuit building block for many real-world signal processing applications. Peak detection determines that a signal has passed its peak value and signals the system to indicate this occurrence. They can be used to mark the presence of valid pulses within a continuous stream, capture radar signal returns, monitor heart pulses, or to indicate a new maximum such as in data from oscillations (buildings swaying due to an earthquake).
Before designing a peak detector, it’s important to be very clear about the objectives of the project, as there is some overlap and ambiguity in terminology. First, there’s a maximum signal detector, which captures the maximum value of a signal indefinitely, until a new maximum occurs (Figure 1).
An example might be a sensor that is tracking the maximum shock to which a package in transit is subjected. The lesser shocks are not of interest; only that maximum is of concern.
Figure 1: In many real-world signal processing applications, determining the presence of a new maximum is a needed function; here we see both positive and negative peaks. (Image source: Spectrum Software)
There’s also peak detection that is a follow-up function to maximum detection. A peak is defined as a signal maximum followed by a decline in signal value (mathematically, the second derivative of the signal changes sign). Some applications look for the global absolute peak, such as the single peak signal among a stream of signals.
Many other applications, however, look for local peaks, such as an electrocardiogram (EKG or ECG), where each peak represents a heartbeat waveform (Figure 2). By measuring the time between these peaks, the pulse rate is determined, even as the value of each of these peaks differs somewhat from its neighbors.
Figure 2: The ongoing signal and the peaks from an EKG are needed to measure the heartbeat parameters. The cycle-to-cycle waveforms are not identical but differ significantly from their neighbors, but that is not of interest for this application. (Image source: Scientific Research/scirp.org)
Finally, there are cases where the “smaller”, very local peaks near larger ones are also of interest, such as in the EKG waveform of a single heartbeat (Figure 3). For this situation, those smaller peaks and their relation to the larger peak are medically informative and must be signaled.
Figure 3: The smaller peaks (positive and negative) of a single heartbeat pulse are also of interest for some medical analysis, and so their occurrence must be flagged. (Image source: HyperPhysics/Georgia State University)
In summary, it’s important to decide if the application requires determining the value of the maximum, or seeking the occurrence of a global peak, or of local peaks.
It seems straightforward, but it’s important to keep in mind that the existence of any peak, whether global or local, cannot be determined until after it has occurred; that is, when the signal value starts to decrease. This is still very different from collecting data, then reviewing it, and saying, “This is where the peak value was, and here is its value.” Instead, it’s primarily a matter of determining, in real time, that a peak has actually occurred. In some cases (but not all) the actual value of the peak is not of primary interest.
The challenge now becomes deciding how much of a decrease in signal magnitude constitutes a valid peak, and the answer is again a function of the application, as well as the anticipated characteristics of the waveform, including noise, small perturbations, and other aspects.
Once the role of the peak detector has been defined, it’s time to design it.
Peak detection using hardware
A basic all-analog peak detector can be built with an op amp, a diode and a capacitor (Figure 4). The input signal charges the capacitor, and as the signal decreases from its value, the diode prevents the capacitor from discharging. The peak value is thus retained by the capacitor.
Figure 4: A basic peak detector requires only a few passive components and a single op amp to drive the voltage storage capacitor. (Image source: Electronics Tutorial)
Although this is a positive going peak design, the circuit can be re-arranged to handle negative peaks, or even be used in a dual configuration to detect both positive and negative peaks. The classic AM radio “envelope detector” used for demodulation is a simple version of a peak detector.
A high-performance peak detector design would require an op amp such as Texas Instruments’ OPA111 (Figure 5). This op amp has a very low input bias current of 1 picoamp (pA) max, and thus does not drain any of the charge stored on the low-leakage capacitor, but presents that voltage to the remaining circuitry.
Figure 5: The low input bias current of the OPA111 makes it a good choice for buffering the voltage on the polystyrene capacitor (lower right). (Image source: Texas Instruments)
The 3507J op amp buffers the input signal to prevent the capacitor’s low input impedance from loading that input.
While this circuit holds the peak value, it does not implement a complete peak detection function. That requires adding a comparator to compare the held peak value to the present, real-time value of the input signal. When the present value is lower than the already held peak value, the comparator output indicates that a peak has occurred.
Design tradeoffs: speed and capacitance
One of the tradeoffs with any peak detector is precision versus speed of detection. If the threshold difference between the held peak value and the present value is very low, such as a few millivolts (mV) or a few percent of full-scale, the peak will be identified quickly. However, there may also be false peaks due to signal noise.
Conversely, if the difference is made larger, such as several hundred mV or tens of percent, the false tripping will be minimized, but the signaling of a peak will be delayed.
An all-analog peak detector can operate on signals from near DC to megahertz (MHz) and even into the gigahertz (GHz) range, as long as suitable op amps are used. The circuit is straightforward in its operation, but the user must decide on the value of the capacitor. There is a tradeoff between using a small capacitor that can quickly follow the input, versus a larger value one that can hold the captured input for a longer period, with the downside that it reacts more slowly as it tries to follow the input signal.
The speed factor is important in applications such as wireless links, where high-speed peak detection is critical. The LTC5564 IC from Linear Technology Corp. (now part of Analog Devices) is a precision RF power detector that operates from 600 MHz to 15 GHz with input signals from -24 dBm to +16 dBm (Figure 6). It includes a temperature compensated Schottky diode peak detector, a gain selectable op amp, and a fast comparator in a 16-lead 3 mm × 3 mm QFN package.
Figure 6: The LTC5564 from Linear Technology provides a nearly complete peak-detection function for RF signals from 600 MHz to 15 GHz, along with internal temperature compensation for consistent, stable performance over a wide operating range. (Image source: Linear Technology Corp.)
Within the LTC5564, an RF input signal is peak detected, and then sensed by both a comparator and an amplifier. The comparator provides a very fast 9 nanosecond (ns) response time to input levels which exceed the threshold reference voltage VREF, and also includes a peak latch enable/disable function. The schematic diagram of the device in an actual application shows additional components – resistors and small value capacitors, but no inductors (Figure 7). Adding inductors, and perhaps fine-tuning their values, is part of the reality of RF circuit design at 15 GHz.
Figure 7: A complete peak-detection circuit using the LTC5564 at 15 GHz requires additional small-value passive components, to optimize performance for specific signal characteristics. (Image source: Linear Technology Corp.)
The analog circuit imposes minimal burden on the system’s resources, requiring it only to respond to the indication that a peak has been detected. In many implementations, the processor then responds with a signal that goes to a small circuit that resets the peak detection function by momentarily shorting out the capacitor and setting its voltage to zero.
Peak detection in software as an alternative
While a peak detector is simple in concept, there are many flow charts that can be used to describe its characteristics depending on the application and its requirements (Figure 8).
Figure 8: This flowchart for a peak detector is one of the many versions possible, each having decision variations to accommodate the specifics of the application and its definition of absolute peak, local peak, global peak, and issues of noise sensitivity. (Image source: Researchgate.net)
The flow chart shown begins with a running average of digitized input values. It then comes to a seemingly simple decision: is the new value less than the previous value? If yes, then signal a peak and clear the register (or flag); if not, repeat the process.
Of course, any real-world code must deal with additional issues. First, by how much of a decline should the “yes” peak decision be made? Using a minimal 1 least significant bit (LSB) value is very prone to noise and false triggering. Instead, some threshold will have to be established, either as a binary count equivalent to a voltage difference, or as a percent of full scale. The value used depends on the application specifics, as it does in the hardware-based version.
Similarly, if the input signal has a global peak as well as smaller localized ones, the code must accommodate the application specific peak criteria. This defines if only the global peak is to be recognized, or local ones need to be cited as well.
A major virtue of the software-based approach is that the peak determination criteria can be flexible, and even dynamically changed by the software as needed. This can be useful when noise levels change, or when the nature of a received signal changes, among other possible conditions.
The algorithm can even be enhanced to look at both the difference in magnitude between a first peak and a smaller second peak, and also look at how close in time they occur. It can then decide if there was just one true peak followed by an “echo”, “shadow”, or uninteresting peak which should be ignored, or if there were two or more independent peaks. In many systems, these are important decisions to system performance requirements.
Note that the ability to dynamically modify decision factors has a related precedent. Many weigh scales include a dual-rate low-pass filter (in hardware alone, or done digitally in software) to handle the impulse that occurs when a package is placed on the scale. First, a broadband fast response filter is used to get within range for an approximate reading, then it is replaced by a narrowband, slower response filter which focuses on the last LSB to provide the final value.
In contrast, it’s not practical to vary the peak-detection parameters of the circuitry-based version, once the components are in place. Even though it is possible in theory to switch to components with different values, at higher speeds the circuitry becomes complex, a smart controller function would need to be added, and the subtle circuitry errors, drifts, and tolerances issues would soon outweigh the benefits.
Hardware or software?
Despite the virtues of the software-based solution with respect to circuitry simplicity and flexibility, it is not a viable option in many cases. For wider bandwidth signals, software requires a high-speed, high-resolution analog-to-digital converter (ADC) for the raw signal. These are relatively costly, have high power dissipation, and require careful board layout. It also places large resource demands on the system processor to ensure that the peak detection code can loop at a fast enough rate.
Both hardware and software solutions are options for basic peak functions. The primary determining factor is signal frequency. If the signals being compared or peak detected are relatively slow, such as under a few hundred kHz, it is almost always a better choice to use software. The required circuitry is minimal and is likely already in the design for other reasons. Applications that can use software-based approaches usually involve temperature, mechanical signals, liquid flow, and other real-world based phenomena.
At the other end of the speed range, as the signal reaches into the tens of MHz and higher, a hardware-based solution is likely the only practical choice, for two reasons. The first is that with software, a high-speed, high-resolution ADC is again needed, along with its interfaces. Second, the burden of executing a looped code segment at high speed, even a fairly short one, can be an unacceptable additional demand on processor resources. Even in RF systems that already have a high-speed converter, such as a software defined radio, the ADC’s output may not have the needed resolution, and the processor (usually an FPGA) is likely already stretched to its limits.
The difficult choice is in the middle range from several hundred kHz to low tens of MHz. There, the tradeoffs include up front hardware cost, board space and layout, performance flexibility, and power consumption, versus the need to ensure that the ADC has specifications suitable for the comparator/peak detection function, and processor burden. An additional consideration is if that if any flexibility in operating parameters is required, the decision leans toward a software-based approach.
Conclusion
Both all-hardware, analog-based designs, as well as software-based implementations for comparators and peak detectors are viable options. At lower speeds, the software method is usually more cost, power, and space effective, but in the RF range, the hardware approach becomes a better choice.
Regardless of the approach used, peak detectors are simple in concept but have subtleties and design issues which must be carefully considered before final commitment to a design or code. Careful planning, testing, evaluation, and debugging using representative input is critical to ensuring success with the signal type being compared or assessed.
