5
$\begingroup$

With regards to multirate processing, what are the benefits of having a 'slower' sampled signal?

Let's say I have a continuous signal

$$x(t) = \cos(2\pi\cdot3t) + \cos(2\pi\cdot 7t)$$

and it is sampled at $10\textrm{ kHz}$. Obviously the sample rate is overkill for the underlying signal. I've started reading into multirate processing, and it often states that the usefulness of resampling (decimation or interpolation) can come in the form of lower processing requirements.

  • What would be the benefits if we subsampled this $10\textrm{ kHz}$ sampled signal?

  • So my question:

    • How exactly do we save processing effort?
    • Is it simply due to the fact that we can subsample a discrete signal, obtain a new signal with lower time resolution (but still adequate frequency resolution and range), and then only have to perform operations on a smaller set of data?
  • Also, do the benefits of multirate processing differ depending on whether or not we're doing realtime or offline processing? It seems like in the case of real time processing, subsampling would allow you to use DSPs that operate at slower frequencies.

Please feel free to offer any insight to the topic!

$\endgroup$
  • $\begingroup$ SE.DSP wishes you a happy new year 2017, with a kind reminder that your question and its answers may require some action (update, votes, acceptance, etc.) $\endgroup$ – Laurent Duval Dec 31 '16 at 18:19
2
$\begingroup$

In addition to what hotpaw2 said, it's important to understand that sample rate reduction is the corner stone of actual applicability in many systems.

Software Defined Radio frontends nowadays produce hundreds of complex-valued Megasamples per second – if you don't reduce that amount of data, no commonly available PC can deal with that.

Also, many devices that you meet nowadays actually have software-programmable DSP embedded very deeply. The average mobile phone baseband IC, i.e. what handles the signal, is digital and very broadband, to "get" the whole bandwidth that e.g. LTE demands they can capture; however, at a single time, only a fraction of that bandwidth might be relevant. So isolating/extracting that bandwidth is crucial to functionality.

Not reducing the sample rate in that situation would not only be a pure waste of power – it would render the following steps, such as equalization and synchronization, totally impractical in the telephone form factor.

A movie camera might take up to let's say 16 Million pixels – which are, in the end, nothing but samples of a twodimensional signal! If the producing camera didn't remove that sample rate (i.e. the picture's resolution), there's no way that the resulting movie data would fit through the terrestrial TV channel; no way that a cheap TV might decode it, and no way you could by such a movie on a cheap optical disc at current capacities.

So, this, by far, is not a "historical" problem. It is a very current problem – not being able to handle the full sampling rate that ADC/DAC hardware offers is the core technological problem of pushing communication further.

Now, 10 kHz really isn't something you'd normally worry about – that's something that most algorithms could deal with on the cheapest microcontroller. But think more in the terms of a SDR frontend (e.g. this one) that has 200 MHz of sampling rate per single complex ADC; that means that you can't even get the two channels of that device into whatever computer you attach at the native sampling rate, because $2\cdot200 \cdot 10^6 \frac {\text S}{\text s} \cdot \frac{16 \text{ b [I]} +16 \text{ b [I]} }{\text S} = 12.8 \frac{\text{Gb}}{\text s} > 10 \frac{\text{Gb}}{\text s} $, which is the datacenter-grade 10GbitEthernet interface's data rate that usually totally flattens out even the most powerful quad-core PC CPUs, without them even doing any DSP, just shuffling the data into RAM. Now, you realize that for almost all applications, it's very desirable that the device internally reduces the sampling rate of the observed signal as far as possible to correctly represent that signal, for computers to even be able to cope with the raw amount of data. The device does that, by applying cascaded multirate filters internally. The ability to, nevertheless, observe the whole bandwidth at once and "select" any part of these 200 MHz at random is very crucial to designing things like wideband transceivers or frequency-hopping standards; so the ability to use the minimum viable sampling rate is very central to progress in research, application development and implementation, as soon as you're not considering 10 kHz systems any more.

$\endgroup$
1
$\begingroup$

Once upon a time, when a lot of DSP algorithms were being developed, expensive DSP processors were a thousand to maybe a million times slower than a current budget smart phone. Same issue with memory prices. So anything that reduces CPU cycles or KBytes of memory required were considered important techniques. Even today on modern hardware, reducing sample rates helps with battery life and/or data cache hit rates.

$\endgroup$
1
$\begingroup$

Not only is there less data to process, but also the required length of finite impulse response (FIR) filters is shortened by the same proportion. The amount of work in time domain convolution is proportional to both of those and is thus reduced to a fraction that is a square of the downsampling ratio, as compared to naive FIR filtering at the original rate.

$\endgroup$
1
$\begingroup$

"Multirate" has multiple acceptations. The main ideas is that data is composed of different components that each different dynamics or rates (your two sines for instance). The standard approach is "he who can do more can do less": one adapts to the fastest rate. The multirate approach is a divide and conquer process: somehow, you can use different (and slower) rates for some (if not all) of the components, at your own benefit. And still, be able to reproduce exactly, or with sufficient precision (with an appropriate measure), the outcome of the standard approach. Subsampling is only one way to obtain the result. It can be combined with many other techniques.

Such an approach could be called Cartesian: "Divide each difficulty into as many parts as is feasible and necessary to resolve it."

The benefits can be multifold (for your question What would be the benefits), and does not always lead to less operations (not only saving processing effort), but less pain to some extend. Here are generic benefits, with signal processing examples:

  • simplify the data into simpler sub-data chunks, for further processing: multirate-based compression, from mp3 to JPEG,
  • lighten processing or interpretation requirements: reduce filter length,
  • enhance the performance: super-resolution from low-fidelity sensors
  • reduce the requirement of involved tools: baseband processing in RADAR systems,
  • capture parsimony: obtain several separate models whose summed complexity is lower than the complexity of an overall model,
  • reduce the requirement of involved tools: process on multi-core platforms or GPU units,
  • reuse cheaper or older equipment instead of buying novels ones, save energy.

For the other questions:

  • How exactly do we save processing effort? By using "models" of data: allowing filtering in subbands, extrapolation, completion to reduce rates
  • Is it simply due to the fact that we can subsample a discrete signal, obtain a new signal with lower time resolution, and then only have to perform operations on a smaller set of data? Not only, as stated above
  • Do the benefits of multirate processing differ depending on whether or not we're doing realtime or offline processing? Yes, because building models only form the past, or constrained to predefined rates/software/hardware, restricts the number of efficient models you can use.

The above contribution is related to a recent work I have been involved in, combining requirements for real-time co-simulation of multirate complex systems via model splitting, signal filtering and polynomial extrapolation (for those interested, we called it CHOPtrey).

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.