Bandwidth and sample rate

I don’t properly understand how the bandwidth of the power trace signal affects signal trace capture.
I have read a few pages, such as electronic-products-design.c … ample-rate, but do not fully get it.
I have written below my understanding of the related areas, please let me know where my current understanding is wrong:

The OpenADC can sample up to 105MSPS.
I understand this as a max samplerate of 105MHz at 10bits per sample.
So this 105MHz frequency is just the max rate at which it can capture a value between 0 and 1024.
This 1024 range is based off the offset from the reference voltage, so 512 sample divisions either side of vref.
So if the amplifier was set such that each sample division was the equivalent of 1mV, and the reference voltage was 3.3V, then the ADC would (effectively) capture values between 3.3V +/- 512mV.
ie values between 2.788V to 3.812V

I understand bandwidth to be the frequency range of a signal.
So a bandwidth of 50MHz might the range of frequencies from 0 to 50MHz, or from 100MHz to 150MHz.

I think my above understanding is correct, it is the following that I am unsure of.
The OpenADC datasheet ( mentions on page 1 that the transformer has an analog bandwidth of 400MHz and the amplifier has an analog bandwidth of 40MHz.

How do these bandwidth values relate to getting power traces?

For example lets say I am trying to capture power traces from a microcontroller that is running at 25MHz.
I would have thought it would just be a matter of setting the ADC to capture at 25MSPS in order to capture the power trace for each clock cycle of the microcontroller. Isn’t the point to just capture the discreet power usage values at moments in time corresponding to the clock rate of the device under test? In which case isn’t the frequency we are interested in 25MHz? So a bandwidth of 40MHz or 400MHz is fine for this?

If the microcontroller was running at 50MHz, then the 40MHz analog bandwidth sounds like it would not be enough to capture it. However the pages I have read mention that the bandwidth value is the max frequency of the signal that can pass through the analog front end, while retaining an amplitude of at least 70.7% of the input amplitude (a 3dB loss). So I guess from this point of view, it may retain less than 70.7% of the input amplitude, however it may still retain enough to be a usable signal. Say for example that it still retains 60% of the input amplitude, this would probably still be a usable signal.

Based off the following pages: … te.645585/

It seems that the sample rate needs to be a little bit over twice the bandwidth in order to accurately capture/reproduce a signal. This suggests toy me that a power trace could be captured at max 40MHz using the OpenADC. So a microcontroller running at 40MHz processed by the OpenADC amp at 40MHz and captured by the OpenADCs ADC at 80MSPS (80MHz).

Reading yet more pages brought me to this page, which perhaps begins to bring some light onto my understanding:
Specifically they differentiate between “analog/repetitive signal bandwidth” and “real time/one shot bandwidth”.

So it seems to me that the bandwidth we are interested in, the real-time/one shot bandwidth?
Hm. The power signal trace we get would be repetitive each time it occurs, ie after each trigger.
But the trace itself would be non-repetitive. ie the trace itself isn’t a sine wave or square wave or something.

Hm again, now that page goes on to suggest that multiple captures after a trigger can be used for equivalent time sampling. Would this be the case however if we are sampling synchronously? I would’ve thought that if we are sampling synchronously then we would just be getting the same bits each time (and missing the same bits each time). Unless we used the phase offset of the OpenADC to change our offset and therefore capture different bits (and miss different bits) after a trigger event.

I hope I have explained well enough what it is that I don’t understand here so that someone can help fix my understanding. It seems that others also have issues with this understanding based off the number of pages on the subject, however even after reading these pages I still am not getting it :stuck_out_tongue:

I am now reading: … ial_01.pdf

page 1 suggests that the effective bandwidth is sample rate / 2.5 (for sinusoidal signals)
So for OpenADC this would be 105/2.5 = 42MHz.

page 2 confuses me too however, i think they are cheating :stuck_out_tongue:
It is trying to say that sample rate is affected by memory length?!
However it seems they are cheating here since they are taking the length of time you are capturing over into consideration. If you want to capture over a long period of time, then of course you need more sample memory.
Is this correct?

page 5 I think answers my questions about “repetitive signal sampling” which they refer to “equivalent time sampling”. It shows that indeed the sampling gets offset by a little bit for other extra sample they do in order to piece together a higher resolution capture. While the OpenADC phase offset could adjust the offset by small amounts, the total adjustment value is only around 5ns. I would expect that the offset would need to be adjustable over the period of the samplerate in order to get a full capture at the higher sample rate. Since even a 40MHz would have a 25ns period, this is only only going to cover 1/5 of the period.

page 6 this is basically what the OpenADC does, extends the sample bit resolution by doing multiple samples.


The bandwidth issue is confusing to start with, and not made easier by some special considerations for side channel analysis. A good reference to start with is some various refs to bandwidth of an oscilloscope, see … h-matters/ for example.

For the OpenADC, there is no explicit filter on the input. This gives it a much higher bandwidth than expected, but it comes at a cost…

As you mentioned, there is an issue where you should sample at 2x the highest frequency. This assumes you want to recreate the signal in the frequency domain, which we actually don’t need to do. Because the OpenADC is sampling synchronously, it can even work with ‘undersampling’, where we sample at 1/2 the clock rate of the device for example. This is not something you could do in general - we can only get away with it because we have known sampling points relative to the device clock!

I don’t actually use the multiple sample trick in this case, although it’s possible to do in the analysis software by applying a low-pass filter. But the idea of sampling with a known offset is similar to how this works…