DSO Quad bandwidth

Moderators: lily.li, violet, salmanfarisvp, jeremy882, crail.lyu969

vernarim
Pre-kindergarten
Pre-kindergarten
Posts: 14
Joined: Fri Apr 15, 2011 12:55 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: DSO Quad bandwidth

Post by vernarim » Wed Apr 27, 2011 10:27 pm

I have done some other test.
I am sorry but I can't made any picture, so you should believe what I write...
Generator: HP33120A
Reference scope: LeCroy LC358 1GHz
I have placed a 50 Ohms load on the generator output, then a 2-feet coaxial cable toward a T-plug. One side is for the LeCroy scope (with its probe), and the other for the DSO (with its probe).
Nothing else.
Hereinafter I will not mention what on the reference scope I see, because I have checked that is always as on the generator has been set. On the reference scope the square wave has a 20ns rise time, as well a 20ns falling time. This is constant over the various test below. The shape of the square wave is almost perfect, at a glance.
The waves outputted from the generator are perfectly balanced on zero Volts, that is a 1 Vpp sine looks like a Sin(t) function, having an amplitude of 500 mV.

On the DSO is always use only the channel A, the others are disconnected (without any probe). The channel B is hidden, but trying to enable it I didn't notice any significative modification of the A track.
Over the tests, I have kept the DSO with DC coupling; also switching to AC no noticeable change of behavior/shape.
The triggering I have tested is NORM or AUTO, always using a rising (i.e. positive) slope.
I have also noticed that the amplitude measured with DSO is slightly less than the real one: it shows about 90% of the reference scope. That for low frequencies, so there is not any bandwidth limitation.

Test #1: 100KHz square wave @ 1Vpp
The DSO shows a well-shaped square and pretty stable. With NORM triggering it seems working well, although you have to serach carefully the stability level. That is strange because the wave is tall enough to find the voltage step. It seems there is no problem even switching the timebase to 100ns/div.
By using the AUTO triggering, the things are gettings worser: from 1us/div and above it seems working okay, but under 1us/div the wave is getting crazy: unstable and heavily deformed, not recognizable as a square. It looks much more a digital message, instead of a perfect wave. However, by adjusting the triggering level you may find a stability point. What the level does in AUTO mode?
When the square wave is stable, at 100ns/div, the rising/falling step of the wave is measurable: let's say around 200ns, maybe slightly less.

Test #2: 500KHz square wave @ 1Vpp
Same as above. The wave displayed begins to be "rounded", because of the rising/falling time. However not a bad shape.

Test #3: 1MHz square wave @ 1Vpp
Same as above.

Test #4: 2MHz square wave @ 1Vpp
Same as above.

Test #5: 3.5MHz square wave @ 1Vpp
Same as above. The wave period is shorter than the rising+falling time and the wave looks much more a sine than a square. The trigger ability to catch the signal seems begin faulting: it is always more hard to find the right point to keep the wave stable.

Test #6: 100KHz sine wave @ 1Vpp
The sine looks perfect.

Test #7: 1MHz sine wave @ 1Vpp
The sine still looks perfect.

Test #8: 5MHz sine wave @ 1Vpp
The sine still looks like a sine, but its aplitude is about 700mVpp. No matter what t/div you choose. It is also valid all the considerations for the trigger modes and their instability, as seen for the square wave.

Test #9: 10MHz sine wave @ 1Vpp
The sine is step-shaped, but it is absolutely normal because of the sampling. At 100ns/div you may easiliy count 7 steps for each sine period. Every step is really well shaped, that is the track-and-hold section is performing its task very well.
The amplitude of the wave is almost 400mVpp, that is less than an half of the real input. The funniest thing is that the DSO is set at 200mV/div, but it seems that is not possibile to magnify. By trying to set 100mV/div or less, the wave (i.e. the scope) don't care at all. There is not any perceivable magnification. This strange bahavior is firing me a suspect: will the actual amplitude read by the ADC about 400mVpp or less? Ya, because if I switch to 50mV/div, the wave displayed is still about 2 divs...so it is almost 400mV or almost 100mV???

Test #10: elevating the generator amplitude
It seems there is no significative way to get better performance, even by feeding a 5Vpp signal on input.

That's all.
I hope that clarify some doubt about the analog section of the DSO.

jnd
Pre-kindergarten
Pre-kindergarten
Posts: 9
Joined: Thu Apr 14, 2011 6:13 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: DSO Quad bandwidth

Post by jnd » Thu Apr 28, 2011 3:00 am

I made some measurements today with unfortunately broken Rohde & Schwarz sine wave generator but it was checked at other two scopes for accuracy. I made more than 20 screen captures and will upload them somewhere soon with comments.

In summary, the hardware should be capable to display good waveforms at the usual standard 10 samples per period but there are many bugs or firmware limitations which make it less useful. As of now when you turn on both analog channels, it seems to sample at 72 Msps, which was still OK at my 7 MHz test measurement. The wave is crude but for information display it's good. For me it the 0.5 V/DIV or greater resolution was working well.

I forgot to add I'm using latest firmware SYS 1.34 and APP 2.33.

lygra
Elementary-3
Elementary-3
Posts: 318
Joined: Mon Nov 15, 2010 11:56 pm

Re: DSO Quad bandwidth

Post by lygra » Thu Apr 28, 2011 6:48 am

vernarim wrote:I have done some other test. I am sorry but I can't made any picture, so you should believe what I write... Generator: HP33120A Reference scope: LeCroy LC358 1GHz I have placed a 50 Ohms load on the generator output, then a 2-feet coaxial cable toward a T-plug. One side is for the LeCroy scope (with its probe), and the other for the DSO (with its probe). That's all. I hope that clarify some doubt about the analog section of the DSO.
Thank you for expending the time and effort to conduct that valid and productive test. Only four additional parameters could make this post better, the T/Div for each test result, your SYS version number, T/Div sweep for each test, and your final conclusions.

I have learned that if you sweep the T/Div several steps smaller and the waveform amplitude does not change, then display amplitude roll-off due to time compression and display sample averaging is not a factor, and instead band-width limiting may very well be the culprit. Maybe you could provide those four parameters to your very informative post.

If you like you could add the additional info as an edit to your original post to keep all the results within the same post for continuity.

In test #9, did you try to increase the V/Div to see if the amplitude halved? This could prove noteworthy to see if the T/Div front-end circuit calibration is causing the same error on other higher V/Div steps. Of course the whole front-end calibration procedure is not well documented at this time and such non-calibration may be involved in the test result errors. But that is a whole separate topic.

In your test #5, the rise time will cause the sample to miss the top of the rise time and instead fall on the next sample time, and that would account for the narrowed square wave alternations. I have added another attachment to more clearly show how the rise time adds to the square wave distortion by missing a sample interval. I considered this when I called it a reasonable square wave display, but it does change the wave shape as shown in my attached drawing.

Once again I would like to thank you for taking the extra time and effort to help clarify this DSO Quad issue of band-width and display accuracy. You have done a good thing here. :D

Thanks
Attachments
dso example2.jpg
dso example2.jpg (42.33 KiB) Viewed 8414 times

lygra
Elementary-3
Elementary-3
Posts: 318
Joined: Mon Nov 15, 2010 11:56 pm

Re: DSO Quad bandwidth

Post by lygra » Thu Apr 28, 2011 7:53 am

jnd wrote:I made some measurements today with unfortunately broken Rohde & Schwarz sine wave generator but it was checked at other two scopes for accuracy. In summary, the hardware should be capable to display good waveforms at the usual standard 10 samples per period but there are many bugs or firmware limitations which make it less useful.
This is very true and the capture buffer routines are less than adequate. The single sweep routines are almost useless for a signal that requires triggering to view, I know because I tried to capture an auto ignition waveform without success. I don't yet know if they do averaged display bins (300 bins across the display) or not. I also agree that the hardware should perform adequately if the firmware is fixed.

Seeed Studio has already admitted that the firmware needs improvement, I just don't know who is going to step forward and fix the convoluted methods devised by the current author, Bure. It is unreasonable to expect someone like BenF to fix this because they have not released all the source code, and have made some of it propriatary.

I don't mean to sound unappreciative for all the Bure effort thus far, but none of the enhanced features developed on the Nano have been incorporated here in the Quad. I am talking about improved data capture and trigger routines for example, not to mention file I/O. I also don't understand why they abandoned the reliable and perfectly good update system of the Nano for this haphazard update system adopted for the Quad. It can't be to get the FPGA upgrades in place, because the memory chip is connected to the STM and not the FPGA. I just know that the results are less than satisfactory for all concerned. Unless these basic firmware problems are fixed, the DSO Quad is doomed. Sorry Seeed Studio, but that is the way I see it.

thanh
Pre-kindergarten
Pre-kindergarten
Posts: 6
Joined: Fri Apr 29, 2011 1:07 am
Are you a staff member of seeedstudio?: yes
Which products/projects are your favorite?: DSO nano, DSO quad, OSL

Re: DSO Quad bandwidth

Post by thanh » Sun May 01, 2011 4:41 pm

lygra wrote:...You absolutely must optimized the T/Div for the highest sample rate as described in a previous post. When you have a more costly scope with a larger capture buffer and much faster sample rate (1GS/s) then you can be sloppy with your T/Div selections. :o
Hello Lygra & Slimfish & everyone here,

I'm trying to learn / understanding what you guys are talking about in this thread. So please bare with me.
I'm interested in how to change the T/Div?

On my DSO quad with sys 1.34, I'm using the square wave generator of the quad to test the quad itself.
With 4Mhz square wave, and with the time div 0.5us, and with the voltage div of 0.5v the signal looks like a lot of stepped sine wave. (Please excuse me if my terminologies are not correct. I'm not an EE). The peak to peak voltage of the signal reported by the DSO is 1.52v
Image

Any bigger time div (5uS) for example, the wave appears to be square pulses, but it's not detailed enough and probably is useless. What do you think?
Image


With 2MHz wave, the signal looks like this:
Image

It looks better, but still like sine.

So how do I set the T/div to make it look square? Thanks very much!
Slimfish wrote:...
I know that average & T/Divs make signals appear bad sometimes (specially with T/divs over 1us), but if you have a 1Mhz signal (sampling @ 36Msps) and gets 1Vpp and for a 2MHz signal you get 0.75Vpp then the input stage (analog) bandwidth is 2MHz (-3dB)....
Now base on the voltages I got: Vpp = 2.58v @ 2MHz vs Vpp = 1.30v @ 4MHz, what do I make of the bandwidth?

Thanks

-Thanh

ps. I saw this link last year when I first heard about the DSO Quad, and I was searching for what 36Mhz sample rate can measure:
http://www.emcsociety.org/Presentations ... 0Radar.pdf

It looks like the effective bandwidth is about 36Mhz / 5 =~ 6Mhz?

Now if the effective rate is down to 15MHz, then am I right that we can only measure around 2.5Mhz?
Attachments
2Mhz_05us_05v.jpg
2MHz square wave measured with time div of 0.5us and Vdiv of 0.5v
2Mhz_05us_05v.jpg (94.1 KiB) Viewed 8376 times
4MHz_5us_05v.jpg
4MHz square wave measured with time div of 5us and Vdiv of 0.5v
4MHz_5us_05v.jpg (86.81 KiB) Viewed 8376 times
4Mz_05us_05v.jpg
4MHz square wave measured with time div of 0.5us and Vdiv of 0.5v
4Mz_05us_05v.jpg (94.16 KiB) Viewed 8376 times

lygra
Elementary-3
Elementary-3
Posts: 318
Joined: Mon Nov 15, 2010 11:56 pm

Re: DSO Quad bandwidth

Post by lygra » Sun May 01, 2011 11:47 pm

:o The length of these posts demonstrates the complexity of these discussions.
lygra wrote:...You absolutely must optimized the T/Div for the highest sample rate as described in a previous post. When you have a more costly scope with a larger capture buffer and much faster sample rate (1GS/s) then you can be sloppy with your T/Div selections.
I was implying that less than fastest T/Div selections could result in less than maximum samples-per-second of data capture resolution. This will be further explained in this post. It is very strange that I have NOT been able to find the fastest T/Div capability of the DSO Quad in the specs. Could someone look at their Quad and tell me the fasted T/Div setting available?
thanh wrote:Hello Lygra & Slimfish & everyone here, I'm trying to learn / understanding what you guys are talking about in this thread. So please bare with me. I'm interested in how to change the T/Div?
We are all trying to learn what we are talking about too! :D We are trying to apply our collective limited knowledge to understand, so welcome to the club. In your scope pictures you have 0.5us selected. That is your T/Div = 0.5us selection item in the menu system. What you can't see is that the T/Div selection may reduce the sample rate. This is because the firmware reduces sample rate (automatically) as you increase T/Div. This is done by the firmware to prevent sample buffer overrun because of too many samples (there is only buffer ram space for 4K samples with both analog channels activated).

As the time per division display of captured data increases (resulting in more time for more samples), then so must the sample rate decrease to prevent capture buffer overrun during that acquisition event. For your benefit an acquisition is simply the accumulation of those 4K sample data points for each trigger event. Each acquisition takes time and this time is mostly based upon the T/Div selection. Once this data capture is completed, then the rest of this acquisition is devoted to very quickly updating the display with the new acquisition data results (new waveform display) for that capture interval, and preparing for the next trigger condition that will stimulate the next acquisition.
thanh wrote:On my DSO quad with sys 1.34, I'm using the square wave generator of the quad to test the quad itself.
With 4Mhz square wave, and with the time div 0.5us, and with the voltage div of 0.5v the signal looks like a lot of stepped sine wave. The peak to peak voltage of the signal reported by the DSO is 1.52v
Thanks for providing those good screen shots. I must say that this signal is lousy by my standards, and on my engineering model (prior to v2.6 circuit board, that I no longer have) my 3.5Mhz signal was much better looking (an actual square wave was displayed (with some sampling error)). Item (4) below may explain the difference.

I also want to thank you for that link http://www.emcsociety.org/Presentations ... 0Radar.pdf (first 26 pages) and I will explain why that link is so important.

1. All your waveforms are taken with channel "B" hidden which is reasonable to get the maximum sample rate. The rub is that according to this link, and reports from other Forum threads, the Quad has an ADC interleave problem.

2. I had not considered a clock phase shift problem as a source of the Quad's interleave problem. I was leaning towards front end ground level and gain differences, but it could also be based upon clock signal propagation phase shift between the FPGA (also within the FPGA) and the ADC chip clock lines. The ADC is physically very close to the FPGA so that is a good start. We don't have access to the FPGA source code so we don't know the phase shift relationship of clock signals out on pins 100 and 81. I think it would have been smarter to have used complimentary output pins to eliminate FPGA substrate phase shifts, and they may have; I just can't tell at this time.

Even with no phasing errors of the two clocks leaving the FPGA, there is still the issue of propagation delay due to circuit board trace parameters. Because we don't have the board design parameters, then we can't be sure of the circuit board trace impedences and trace lengths being the same for both clocks. If they are different then that could also cause the ADC interleave problem. The clock signal of 144Mhz requires some serious circuit board trace layout considerations to prevent unexpected propagation delays and reflections.

3. If we want to discuss band-width issues, then the faulty ADC interleave must be removed from the displayed results and this discussion. So keep both channels A & B enabled for all band-with testing until the interleave problem has been corrected.

4. Another interesting link contribution addresses how the rise time of the measured signal influences the DSO results. I seem to recall back when I had the engineering model Quad, that the nice square wave from the signal generator looked terrible on the display but my function generator signal of same amplitude and frequency looked much better. Now I know why: the rise time of the function generator was most likely much longer and this according to the link would result in a better looking DSO display. This is what caused the large difference of my test results versus "Vernarim" test results while using a square wave signal. I hope you are reading this "Vernarim" because that means we were both right about what we saw on the display. :oops:

5. Another interesting link contribution on page 7/88 demonstrates how 5x sample rate is barely acceptable while 10x and 20x are much better. 2x sample rate is simply inadequate.

In summary, that link (first 26 pages only, the remaining pages deal with time-domain reflectometry) cleared up a lot of issues for me, and I now have a better DSO understanding because of that link.
thanh wrote:
Slimfish wrote:... I know that average & T/Divs make signals appear bad sometimes (specially with T/divs over 1us), but if you have a 1Mhz signal (sampling @ 36Msps) and gets 1Vpp and for a 2MHz signal you get 0.75Vpp then the input stage (analog) bandwidth is 2MHz (-3dB)....
Now base on the voltages I got: Vpp = 2.58v @ 2MHz vs Vpp = 1.30v @ 4MHz, what do I make of the bandwidth?
To make your measurements complete, you must also provide the amplitude output of the Quad signal generator (using a separate scope) for each frequency just to make sure that the signal generator output is stable in amplitude. Remember, you are only looking at sample points connected with straight lines on the Quad display, so if your sample points never coincide with the peak signal value, then you will never see the peak signal value displayed. This may be the source of the displayed amplitude errors and not representative of analog band-width.

I realize that you were using square waves but we know that a square wave consists of the fundamental sine wave plus all its odd order harmonic sine waves. The attachment to this post is an animated gif that came from an unknown internet source and I modified it in size and slowed it down for the fundamental, 3rd harmonic and 5th harmonic so you can see how peak sample points could easily be missed. Notice how the rise time gets steeper as more odd harmonics are applied to the square wave.

That flat top of the square wave is virtual and composed of a cluster of frequencies (harmonics) so what are the odds that you are sampling on all the peak points? Remember, the trigger condition sets the relationship of the samples phasing with regard to the input signal. If you move the trigger level you should see different waveform results, because the sample phasing of the input signal will change and the odds of sampling a waveform peak also change.

If you look back at my original sine wave drawings, you can see how the amplitude is reduced when the sample is at less than peak position of the input signal, and nearly all the sample points missed the sine wave peaks. With fewer samples per waveform, then these missed peak amplitude samples become more likely. These are the reasons I can't definitively answer your question. What are the odds that your samples are occurring at the waveform peaks? The answer is probably slim to none with reduced amplitude results. You could ask BenF how the measured peak values are determined by the DSO Nano because that may be how the DSO Quad measures Vpp.

In closing, I expended several hours in researching and writing this post, and I hope that others will take the time to read and understand what I have said here. Is it absolute? Probably not, but it is a good collection of issues that must be considered before determining the analog band-width capabilities of the DSO Quad by using it's displayed output.

It is unfortunate that several different threads are skirting around in these issues without considering the other threads with similar issues. Maybe this post will help others to recognize all the interactions that can affect the displayed results on the DSO Quad.
Attachments
SquareWaveSmall2.gif
SquareWaveSmall2.gif (106.97 KiB) Viewed 8360 times

vernarim
Pre-kindergarten
Pre-kindergarten
Posts: 14
Joined: Fri Apr 15, 2011 12:55 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: DSO Quad bandwidth

Post by vernarim » Mon May 02, 2011 1:37 am

Hi lygra.
I read the latest posts right now, but I am not sure to understand everything well..Okay, I am actually tired too.

I was not able to perform any other test because I am very busy at the moment. The instrumentation is in the lab, while at home I can only try with simple circuits.
Anyway, I would like to create a simple circuit using HCMOS logic, that is performing very well even at tens of MHz. That will allow me to test something at home.
I understand that many users has no good wave reference, but the internal wave generator of the DSO shouldn't used as a reference to test the scope itself.
To tell the truth, I didn't check it at all, because that is a section not so interesting for me.
I will do...

Considerations?
I think that the current version of DSO has several failures: the problem is *NOT* just one.
Pros:
  • the idea is valuable and the price is good;
    the circuitry is using good components, that perform very well (anyway I'd used a faster+powerful MCU);
    (if will be) the ability to interface with a PC;
Cons:
  • (overall) the DSO has been designed too in-a-hurry: that is the most evident fault at-a-glance;
    the box should have been bigger: the display is OK, but the buttons are very hard to push/slide;
    the analog section is likely under the real possibilities of the ADC/logic;
    the trigger algorithm is faulty/buggy;
    it should have been an analog trigger detection also: the digital seems not enough smart even for signals relatively "easy" to trigger;
    by using a better MCU several functions could have been easier to implement and/or expand.
I would love to explore the circuit of the DSO, with the instrumentation. I'd like to make many tests better and deeper, as well to try to improve the analog section.
The problem is the usual: I have no time!
I can't promise anything, but I will try to do it in the near future.
Cheers

thanh
Pre-kindergarten
Pre-kindergarten
Posts: 6
Joined: Fri Apr 29, 2011 1:07 am
Are you a staff member of seeedstudio?: yes
Which products/projects are your favorite?: DSO nano, DSO quad, OSL

Re: DSO Quad bandwidth

Post by thanh » Wed May 04, 2011 4:57 pm

Hi Lygra!

Thanks very much for your help. I'm digesting what you wrote in your long post. Hopefully get some bits of them.
lygra wrote:I was implying that less than fastest T/Div selections could result in less than maximum samples-per-second of data capture resolution. This will be further explained in this post. It is very strange that I have NOT been able to find the fastest T/Div capability of the DSO Quad in the specs. Could someone look at their Quad and tell me the fasted T/Div setting available?
On my DSO quad, the fastest TDiv is 0.1us. The quad software has bug in this Tdiv settings. It doesn't refresh the screen properly when the signal changes frequency.
lygra wrote: ... In your scope pictures you have 0.5us selected. That is your T/Div = 0.5us selection item in the menu system. What you can't see is that the T/Div selection may reduce the sample rate. This is because the firmware reduces sample rate (automatically) as you increase T/Div. This is done by the firmware to prevent sample buffer overrun because of too many samples (there is only buffer ram space for 4K samples with both analog channels activated).

As the time per division display of captured data increases (resulting in more time for more samples), then so must the sample rate decrease to prevent capture buffer overrun during that acquisition event. For your benefit an acquisition is simply the accumulation of those 4K sample data points for each trigger event. Each acquisition takes time and this time is mostly based upon the T/Div selection. Once this data capture is completed, then the rest of this acquisition is devoted to very quickly updating the display with the new acquisition data results (new waveform display) for that capture interval, and preparing for the next trigger condition that will stimulate the next acquisition.
Why do they have to reduce the sample rate when they increase the time div?
Assume the buffer can store 4000 samples. When they reduce the time div (or increase the sample rate), they can still capture 4000 samples, and only need to display these 4000 samples. Obviously, this 4000 samples can only capture a shorter length of the signal, but on the screen we also has to display less because of smaller t div. Correct?
lygra wrote: 1. All your waveforms are taken with channel "B" hidden which is reasonable to get the maximum sample rate. The rub is that according to this link, and reports from other Forum threads, the Quad has an ADC interleave problem.
when I re-enabled channel B, the wave still looks sine, but now it has 16 steps or more instead of 8 steps. The wave immediately looks better right after enabling channel B. Could you explain what this ADC interleave is? Is it the ADC taken sequentially between each channels and not at the same time?
lygra wrote: 2. I had not considered a clock phase shift problem as a source of the Quad's interleave problem. I was leaning towards front end ground level and gain differences, but it could also be based upon clock signal propagation phase shift between the FPGA (also within the FPGA) and the ADC chip clock lines. The ADC is physically very close to the FPGA so that is a good start. We don't have access to the FPGA source code so we don't know the phase shift relationship of clock signals out on pins 100 and 81. I think it would have been smarter to have used complimentary output pins to eliminate FPGA substrate phase shifts, and they may have; I just can't tell at this time.
Can we use an external scope and look at this?
lygra wrote: 4. Another interesting link contribution addresses how the rise time of the measured signal influences the DSO results. I seem to recall back when I had the engineering model Quad, that the nice square wave from the signal generator looked terrible on the display but my function generator signal of same amplitude and frequency looked much better. Now I know why: the rise time of the function generator was most likely much longer and this according to the link would result in a better looking DSO display. This is what caused the large difference of my test results versus "Vernarim" test results while using a square wave signal. I hope you are reading this "Vernarim" because that means we were both right about what we saw on the display. :oops:
Maybe I should try using a signal generated from another better scope :).

lygra wrote: 5. Another interesting link contribution on page 7/88 demonstrates how 5x sample rate is barely acceptable while 10x and 20x are much better. 2x sample rate is simply inadequate.
If we use 10x sample rate as standard, then 3.6MHz should be the bandwidth? or is it 1/10 of 15MHz that Hugeman was mentioning?

lygra wrote: To make your measurements complete, you must also provide the amplitude output of the Quad signal generator (using a separate scope) for each frequency just to make sure that the signal generator output is stable in amplitude. Remember, you are only looking at sample points connected with straight lines on the Quad display, so if your sample points never coincide with the peak signal value, then you will never see the peak signal value displayed. This may be the source of the displayed amplitude errors and not representative of analog band-width.
Thanks. Yeah, using the quad to test itself shouldn't be trusted.

lygra wrote: I realize that you were using square waves but we know that a square wave consists of the fundamental sine wave plus all its odd order harmonic sine waves. The attachment to this post is an animated gif that came from an unknown internet source and I modified it in size and slowed it down for the fundamental, 3rd harmonic and 5th harmonic so you can see how peak sample points could easily be missed. Notice how the rise time gets steeper as more odd harmonics are applied to the square wave.

That flat top of the square wave is virtual and composed of a cluster of frequencies (harmonics) so what are the odds that you are sampling on all the peak points? Remember, the trigger condition sets the relationship of the samples phasing with regard to the input signal. If you move the trigger level you should see different waveform results, because the sample phasing of the input signal will change and the odds of sampling a waveform peak also change.
This is interesting. I've never seen it before and would never understood it. It's not that I'm understanding it clearly now, but it's something new I learn from you. I'm wondering if the ADC input has some sort of low pass filters then we see only the low frequency harmonics, right?

The odd of the ADC sampling only on the peak points would be great if the sample rate is low. So when the frequency of the signal we want to measure getting close to the sample rate, then yeah, we don't know, and we can't reproduce an exact wave form either. I mean we just don't know what we see is true or not.

Thanks Lygra

-Thanh

lygra
Elementary-3
Elementary-3
Posts: 318
Joined: Mon Nov 15, 2010 11:56 pm

Re: DSO Quad bandwidth

Post by lygra » Thu May 05, 2011 1:38 am

thanh wrote:Why do they have to reduce the sample rate when they increase the time div?
Assume the buffer can store 4000 samples. When they reduce the time div (or increase the sample rate), they can still capture 4000 samples, and only need to display these 4000 samples. Obviously, this 4000 samples can only capture a shorter length of the signal, but on the screen we also has to display less because of smaller t div. Correct?
I am not qualified to provide an exact correct answer for this complex question. The attached JPG file is an excerpt from BenF's "Nano User's Guide" that demonstrates what I have said. Although the actual sample rate numbers are different, the sample rate decreases will be similar. It is clear here that as T/Div increases, then Samples/sec are decreased. Maybe you can get BenF to provide further explanation.
thanh wrote:when I re-enabled channel B, the wave still looks sine, but now it has 16 steps or more instead of 8 steps. The wave immediately looks better right after enabling channel B. Could you explain what this ADC interleave is? Is it the ADC taken sequentially between each channels and not at the same time?
Just what you have said, first one ADC takes a sample and then the other ADC takes a sample. Each ADC places it's sample into the common capture buffer (I guess, unless two separate buffers are merged at the end of that acquisition cycle).
thanh wrote:Can we use an external scope and look at this?
Only if your external scope is very fast with very stable trigger circuits. Looking at the phase comparison and/or phase jitter of two 75Mhz clock signals is certainly no walk in the park.
thanh wrote:If we use 10x sample rate as standard, then 3.6MHz should be the bandwidth? or is it 1/10 of 15MHz that Hugeman was mentioning?
Original 36Mhz ADC clock would display a 3.6Mhz square wave with some distortion, and I would compare this to the spec statement by Seeed Studio as analog-sampling-bandwidth. This would mean that a little bit of square wave sampling distortion would be expected and would be similar to 3-db amplitude roll-off distortion for any true analog band-width. I am NOT using the term analog-band-width.

With the overclocking of the ADCs, then 75MSa/s and 144MSa/s would result in analog-sampling-band-widths of 7.5Mhz and 14.4 Mhz respectively, which approaches 15Mhz number represented by Hugeman.
thanh wrote:This is interesting. I've never seen it before and would never understood it. It's not that I'm understanding it clearly now, but it's something new I learn from you. I'm wondering if the ADC input has some sort of low pass filters then we see only the low frequency harmonics, right?
There is no intentional low-pass filter at the ADC. As shown in the animated square wave creation file, with 15Mhz DSO input limit, then to get just the first 3 odd harmonics (fundamental, 1st, 3rd, 5th harmonics) would require an analog band-pass of 75Mhz and the edges would still not be very sharp and the tops would not be flat. Sampling of this 3 harmonic input would result in a poorly shaped square wave on the Quad Nano display.

User avatar
slimfish675
Kindergarten
Kindergarten
Posts: 56
Joined: Thu Nov 19, 2009 5:14 pm
Location: Spain

Re: DSO Quad bandwidth

Post by slimfish675 » Fri May 06, 2011 3:59 pm

Hi thanh & lygra,
thanh wrote:Why do they have to reduce the sample rate when they increase the time div?
Assume the buffer can store 4000 samples. When they reduce the time div (or increase the sample rate), they can still capture 4000 samples, and only need to display these 4000 samples. Obviously, this 4000 samples can only capture a shorter length of the signal, but on the screen we also has to display less because of smaller t div. Correct?
The buffer is used to compute avg, rms, dc, ac, frequency, period.... If your buffer is filled always at same sampling rate you'll lose a lot of precisión in those calculations. Besides, going from 0.1us/div to 1us/div and your buffer samples are just in the limit to fill the screen.
thanh wrote:If we use 10x sample rate as standard, then 3.6MHz should be the bandwidth? or is it 1/10 of 15MHz that Hugeman was mentioning?
Analog bandwidth and sampling rate should not be mixed. Analog bandwidth is constant for all T/divs (the exact quantity is unknown to me, but about 2MHz -see previous posts-) at least in this scope. It defines the frequency at which the signal is attenuated by 3 dB. It works like a low pass filter.

Obviously the signal has to be sampled adequately in order to display the signal properly. A 20x oversampled signal looks much better than a x10 one. But that has nothing to do with analog bandwidth. Benf has already shown that with a 1 Msps (DSO V1), controlling the sampling interval and trigger, you could have higher signal resolution (equivalent sampling speeds higher than ADC maximum). All of this is possible if signal has some periodic pattern.

Hope it helps

Post Reply