My point was that you are comparing apples to oranges. DSO display results are never the proper way to measure analog bandwidth for all the reasons already posted in this thread. Looking forward to your findings when you do open it up, as validation of HugeMan’s findings.
Thanks
Slimfish; Ok, so everything you say is correct and I with my unlimited misconceptions, stand corrected.
I finally found time to research this topic some more. There appears to be a mistake in your calculations here. The first and subsequent odd harmonics for a 1Mhz square wave would be 3,5,7,9,11,13,15,17,19,21,23,25 and 27Mhz to pass the 13th odd order harmonic.
Anything over the sixth odd harmonic of this 1Mhz square wave will be at or greater than -3db attenuation due to the 15Mhz DSO Quad analog bandwidth, so a poor waveform is to be expected because of analog bandwidth limiting.
Another assertion claimed by you and others is that the Nyquist theory only requires 2x of the signal for a sampling rate. You failed to include the rest of that definition which says “a signal must be sampled at least twice as fast as it’s highest frequency component.” With the square wave this would require many odd order harmonics, so in your example above, to include the 13th odd harmonic, then you would require a sample rate of 54MSa/s to reproduce that 1Mhz square wave waveform accurately.
So even if the analog bandwidth could pass the 27Mhz harmonic (and it apparently can’t), then the sample rate would still be destroyed according to Nyquist while using a 36MSa/s sample rate.
If you fall back and say, OK, lets just use a signal generator that can only output the 5th odd harmonic and we know that we will have a slower rise time (less than 10%) source signal waveform because of this harmonic limit. The fifth order odd harmonic of 1Mhz is 11Mhz so the DSO Quad bandwidth can pass this harmonic. According to Nyquist, with fifth harmonic (11Mhz) being the highest frequency component, then 22MSa/s should accurately reproduce the poor quality input signal square wave, and the DSO Quad will reproduce that signal with its 36MSa/s capability.
So, in the end you will get a poor display of a 5th order odd harmonic limited signal input because of the signal itself, and you will also get a poor display of the perfect square wave input because of DSO Quad limitations as described above. As I had mentioned in my earlier posts, my poor quality function generator square wave signal looked pretty good on the DSO Quad because it didn’t have enough odd harmonics present to add the DSO artifacts when the DSO Quad capability is exceeded. When I said it looked reasonable, it did look nearly as good as the input signal with some limited sampling artifacts which resulted in narrowed alternations (10% narrowing at the alternation tops). In the same write up, I also stated that the DSO Quad signal generator signal looked terrible, and now this can be attributed to my other statement about the generator signal looking like a very good square wave up to 8Mhz (which means it has lots of odd harmonics present) on a more expensive o’scope.
The attachments further clarify the above paragraph. You can see that the rise time for the 2nd odd harmonic waveform is about 6% (less than 10% rise time). So we will limit ourselves to the 2nd odd harmonic. This is 5 x 3.5Mhz = 17.5Mhz so it should get through the 15Mhz DSO Quad bandwidth with some amplitude fall off. I also mentioned in previous posts about some drooping of the tops and bottoms and this would indicate some kind of amplitude fall-off. According to Nyquist, the required sample rate would be 17.5Mhz x 2 = 35MSa/s. These numbers clearly show that I could in fact see the 10% rise time 3.5Mhz signal on the DSO Quad (with some amplitude distortion which I never measured).
Now lets look at a 3.5Mhz perfect square wave by your definition (13th odd harmonic is present). 3.5Mhz x 27 = 94.5Mhz analog bandwidth requirement and will not do well with a 15Mhz DSO Quad bandwidth limit. For the same perfect square wave, the Nyquist sampling rate would be 94.5Mhz x 2 = 189MSa/s so that wont happen either. This is why you can’t look at the DSO Quad generator 2Mhz or 4Mhz square wave outputs on the DSO Quad display. It has nothing to do with the DSO Quad being defective, but is simply the result of the DSO signal sampling process while sampling a short rise time square wave.
In summary, in my first post in this thread I stated what I had observed but failed to talk about rise time as a factor for display results. Then Venarim in his first post stated that he didn’t believe that I saw that. And then the thread just rambled on. It is my intention that this post will set the record straight and also explain the reason for differing observations between Venarim and myself.
It also might be pointed out here in the bandwidth discussion, that if the DSO Quad design had a hardware trigger circuit (and it does not) then for repeating waveforms, the firmware could be designed for equivalent time sampling with a magnitude order increase in the maximum observable waveform frequency. That would have made a tremendous improvement to the DSO Quad, but that approach was never taken during the design leap from the Nano to the Quad.
My reference for this post is cbtricks.com/miscellaneous/t … mpling.pdf which is a Tektronics application note for Sampling Oscilloscopes.
hi, i promise my hardware is the same as the one in your hand.
Hi Lygra,
sorry, but you’re mistaken here. The n-th armonic of a wave is defined as: f_n-th = f * n-th, where f is the fundamental frequency of the wave and n-th is the harmonic. So for a 1kHz square wave, its 5th armonic will be 5 kHz. And zero harmonic is the DC component. It’s true that perfectly square waves doesn’t have even harmonics (and you counted to the n-th position of a odd harmonic), but that’s another tale.
I would say not only, but at least. Difference is significant.
A perfectly square wave has infinite odd harmonics, and hence can’t be perfectly sampled (also produced). With the corrected calculations you will require 30 Msps (15 Mhz x 2). With the arguments you gave in the previous messages… why not sampling 13th harmonic with 20x? So now its enough with 2x?. You are mixing theory and practise, and that’s quite difficult without a solid ground. That was the point to stress.
Although wikipedia says exactly what you posted before, in reality the signal has to be sampled with at least twice its bandwidth to be perfectly reconstructed.
I don’t know how you know this since FPGA is closed source 
. But i can bet my mother (only speaking, don’t take me too serious 
) that trigger is hardware (obviously is not an analog one, but digital). So QUAD can use equivalent time sampling for sure.
I’d like this thread not to diverge into sampling theory, because its large and complex. So for me, the theory discussion is over.
@HugeMan: I will check the analog bandwidth by open my Quad, as soon I have spare time to do it.
@lygra: I appreciate your effort to demonstrate (better: trying to do it) with tons of theories, but I guess that you are mixing many concepts together.
A square wave is yes composed by odd harmonics (I agree with slimfish about the numbering), but the shapes you drawn could never be what the analog section outputs. You missed a VERY important parameter: the phase!
Remembers that here, for simplicity, we are talking about the modulus of a signal (i.e. a square), but we MUST take in account the phase-shift caused by the analog section. We “should” take in account the phase-shift introduced by the sampling also, but…never mind.
Just take a simple square-wave generator and a R-C lowpass filter. Assuming the time-constant similar to the period, what do you expect to see on a scope?
The input is a square-wave, composed of an infinite number of odd-harmonics. The output cuts them at -6db/oct.
That would be having an output shaped as you drawn?..Yes, if only the filter won’t shift the phase, smoothly from 0 to -90 degrees.
Of course, by scoping the output signal you will see an exponential fragment, repeated on each period. Exactly the same as having a switch charging then discharging the capacitor, via the resistor.
All that only for a simple R-C filter, being just-one-pole complex function. Imagine what would be having a 10+ poles network!
Cheers
I never talked about the fifth harmonic, I only referred to the 5th odd harmonic, not the same. If the first harmonic is even (2Mhz) then the pattern after the fundamental would be 2nd=even, 3rd=odd,4th=even,5th=odd; so the fifth harmonic would be odd and is 5Mhz, but I was referring to the second odd harmonic (which is the actually the 4th harmonic if you count the none existent even harmonics too) when I said 5x, so once again you are mistaken. As you have already said, the even harmonics don’t exist, so they can not be counted.
See previous response.
My reference was not Wikipedia, my reference was a professional application note produced by Tektronix engineers. If you would bother to read this reference then you may become more informed. As you have already said, the odd harmonics are part of the square wave, and hence the sample rate must be twice the highest odd harmonic expected, unless Nyquist is wrong and you are right.
This is a fool’s bet for someone who doesn’t know the FPGA source code. But that FPGA source code may not be necessary if you look at the STM source code and find it’s triggers source.
I believe that it was you that started with the equivalent time sampling theory, not myself. Sampling theory is not that complex and is explained quite well in the Tektronix reference that I provided in my earlier post. If you look at the Nano post viewtopic.php?f=12&t=1793&start=80 on page 9, BenF fully explains in his May 8th post just exactly how the Nano firmware trigger detection works without a hardware trigger. That discussion is also not very complex. You can also read my Tektronix reference, that also explain exactly how equivalent time sampling works. So I don’t see anything here that is overly large and complex.
The only thing I find complex is trying to determine a hardware trigger within the FPGA, without first looking at the STM source code (which is available) to see if a software trigger is present. An even simpler approach would be to point out the Quad menu choice which provides enabling of this fictional equivalent sampling mode. If the Quad were in continuous equivalent sampling mode, then you could not look at non-repeating signals, but guess what; you can look at non-repeating signals with the Quad. Therefore if you assertion is true, then there must be a Quad menu choice to switch back and forth between equivalent sampling mode and real-time sampling mode. Please be so kind as to point out this menu choice, or stop wasting everyone’s time with your non-validated theories.
What a relief that is. 
Look, my goal here is not to constantly criticize you, my only goal is to provide factual enlightenment for those looking for same. If you agree to stop spewing theory, then I will agree not to be critical in return. Do some research on your own as I have done, and present those research findings that support your claims.
Have you measured this phase shift when a 1Mhz square wave passes through the Quad front-end circuits? If so, how much phase shift did you measure for the fundamental, 1st odd harmonic and the 2nd odd harmonic?
When I present a theory, I always use a “maybe” or “might be” during that theory. The rest is not theory but common knowledge of the trade. If you haven’t measured the above phase shift, then it is yourself that is now presenting not tons but ounces of theory.
Thanks
My input into all of this is really quite simple.
It requires no degree in mathematics or foundation courses in laplacian and fourier calculations and transforms for calculating the nth harmonic of a fundamental 
, buffer sizes, sampling rates, time divs, ADCs, unity gain op-amps, low impedance signal path, parasitics and finally disembowelling 
my quad to fiddle with its innards.
My question is simple.
Have we been mis sold a device that, from what I can see and extrapolate from all the theory, is only good for about 5Meg bandwidth when is said quite clearly 27Meg when it was sold to me.
This is not half, not a quarter, not even one fifth of what I paid good money for.
My question is how are Seeedstudio going to address this issue of mis selling and then saying nothing to their customers apart from …
Well this is my comment and I leave it to you to decide on the action
Ohhh and BTW before the flaming starts … this is not a serous post I just wanted to lighten the mood a little 
To be honest firmware issue aside i quite like it and once the niggles are ironed out and my confidence in its abilities is a little higher it will have pride of place on my hobby bench.
Cheers Pete.
If you want to count only odd armonics to fade your mistake is up to you. But fifth armonic of a 1 kHz wave is 5 kHz. And venarim was refering to that.
Your reference is a manual (a.k.a. tutorial - simplify things) which by the way i’ve read. Also i’ve read more than “a couple” of books that support what i’m saying. Even i built a radio (which works by the way which samples @ 1.5 times the carrier frequency. I suppose at this time our world as we know it is collapsing . And by the way, Nyquist is STILL correct (because the signal bandwidth is 3 kHz).
A fool’s bet. Yeah. I did look into STM the code, did you? Of course not, because you are wrong again. Look @ BIOS.h, process.c (__set function) and you will understand (i hope so). And again, what would be the purpose of sampling at 72 Msps when you can not trigger with a precision of more than 1us (in case internal ADC would be used)?.
Of course, the sampling theory is very simple. Read a manual and that’s it. Shannon and Nyquist would commited suicide if they could read you.
I’ve never said that equivalent time sampling is implemented in QUAD. I said it is POSSIBLE for sure. Excuse me but you know we have to wait until Benf took the source code disaster of DSO Nano and made a pretty decent firmware… not expected for seeed programmers to evolve so fast.
Huh, that’s funny. I’m a professional researcher/university teacher (+20 years in real electronic design). I’m proud of being always open to criticism. As Bainesbunch have said, this have gone too far. I’m glad you finally have some relief.
The Last word is all yours. Enjoy it.
The story is always funnier than expected.
I have done some measurements right now.
As HugeMan/lygra suggested, I feed the ch-A input (without any probe) directly with the signal generator. BTW: the instrumentation is still exactly the same.
I checked the signal either on the Quad display and with the LeCroy scope on U5 pin13.
The amplitude of the input was constant at 2Vpp.
Sine wave test.
A manual sweep from 1 to 15MHz (step by 1MHz) clearly shown that the band is NOT constant (ref U5 pin 13).
Assuming 100% at 1MHz, the amp will decrease briefly to 50% (-6dB) at about 3MHz. Still remain at 50% until you reach about 7-8MHz, then raises to about 75% around 10MHz. Hereinafter will raise even more: at 15MHz (the max I can test) is about 200%.
So, at 10MHz the attenuation is about 75% (i.e. -3dB)…that’s the way HugeMan says the bandwidth is 10MHz…but FOR ME the bandwidth has to be taken as the VERY FIRST POINT where the attenuation falls to -3dB…once again the point is around 2MHz.
Square wave test.
Just a simpler test than before: always scoping the pin 13 U5.
At 1MHz the wave has the rising edge clearly rounded. The displayed wave on Quad looks pretty the same as the LeCroy’s one.
Going higher with the freq, 3MHz, the square is almost a triangle/sine, with a well-visible spike just before the falling edge.
Above 4-5MHz the wave on the LeCroy scope looks as sine.
The spike is clearly due to the unexpected amplitude above 10MHz.
My conclusion:
the analog section has a bandwidth of 2-3MHz;
the “supposed” bandpass is very far to be flat (as should be);
the analog switching strategy is faulty: if the signal cannot be shown as it is, the Quad should constrain the user’s selection;
as the current analog section hardware, this Quad is good for signals under 100-200KHz.
I will leave my Quad in the lab, if someone of you is asking for any additional test.
Cheers
PS: suggestion to HugeMan.
I would think about an external box, embedding a good analog section, that can feed a good bandpass and a reliable way to display signals.
I am not so happy about this toy.
My last word is in line with Bainsbunch, in that I apologize to you for my being an ass at times 
Thanks for providing these very necessary measurements.
Neither you nor HugeMan have specified which range scale you are using for these measurements. As long as the range scale is not changed, then I would suspect that calibration of that range scale would not be a factor. On the other hand, the probe compensation adjustments for that channel could have very dramatic affect.
U5 pin “Y”, is that what you are measuring? The pin numbering seems to be inconsistent on the schematic. It appears that U5 “Y” is the input to the op-amp U-7, and U5 “X” is the output of the op-amp U-7. If so, then U5 “X” will be the low impedence signal into the ADC, and that is where the measurement should take place.
I am still awaiting my replacement Quad. Maybe you could upgrade to the latest firmware, conduct the new probe compensation procedures provided by HugeMan, and then repeat your test to see if the results are different. Hopefully the probe compensation procedure will help to flatten this bandwidth. It may be robbing Peter (2-3Mhz) to pay Paul (15Mhz). If this is true then the bandwidth will probably end up being more than 15Mhz.
Thanks for sharing this info.
Ok, I revisited the code that you suggested. I can not find your reference, please tell me where this file is located. App-Bios.h only defines terms and parameters. It also defines some routine headers and that is to be expected, but even in the routine headers, there is no mention of trigger detection routines here.
If you visit the App-process.c, there appear to be three routines relevant to trigger detection. Those routines are “Update Trigger”, “Synchro”, and “Process”. Now my Chinese is a little rusty (actually non-existent), but it appears to me that the “Update Trigger” routine is setting the trigger levels to look for, the “Synchro” process determines what kind of trigger to look for, and then “Synchro” uses the “Process” process to go and scan the various channel capture buffers looking for those trigger conditions. Of course, “Process” is also looking for many other parameters at the same time.
Now I don’t claim to be as knowledgeable as yourself in “C-language”, so maybe you could point out which lines in the App-process.c files indicate that my observations here are incorrect.
Thanks
I was planning to order DSO Quad, but I think I will wait until this product become better.
One idea based on vernarm’s “Wed May 11, 2011 8:52 pm” measurements. It looks like bandwidth could be about 20Mhz (I guess) if seeedstudio correct this by appropriate software digital filter. I guess this is possible, because problem is in the middle of bandwidth and not so big (50% of nominal level?), and not at the end of bandwidth (which could be critical for filters). As I suggested for DSO Nano, the sampling rate need to be always maximum possible, in this case to make the best possible digital filter.
Hi,
i don’t have much time now, so i have to be very brief.
In process.h (APP code) is where the function Update_trig (trigger update) is. In the very first lines, __Set function is used to set parameters… how?, in BIOS.h are the definitions. At some point in the file, you could see that some parameters are used to reset FPGA, etc. I also don’t speak Chinese 
.
Following that trail, you have to find _set function (which is in SYS code, BIOS.c file). It’s a giant switch used to set parameters both in the ARM and in the FPGA. For simplicity’s sake, look for TRIGG_MODE, V_THRESHOLD… etc. These parameters call Set_param() which is also in the same file. Looking at Set_param() there is a call to Sendbyte()… which sends a byte to the FPGA. I think the rest is self explanatory…
Venarim, your measurements could indicate that there is possibly a phase inversion (OPAMP instability). Or at least thats what i think.
And Dejan (are you the Nokia one?), although a equalizer is a very good idea, Venarim only have tested discrete frequency steps. It could be possible that the bandpass line would be not so easy to equalize (very small gains @ specific freqs.). Also it would draw more current (15 stage FIR filter @ 72 Msps -> switching loses). But definitely a nice one.
So the problem now is that somebody with a spectrum analizer has to do some sweeps in order to verify that “line”.
I think we should conduct the simplest test first, and that is to do the front-end compensation alignment as provided by HugeMan. If that does not flatten out Venarim’s test results, then go to the next level and consider a spectral analysis to identify what is happening here.
Some new threads have mentioned improvements with the latest firmware updates, so it is very important that we all apply these updates before more testing is continued.
I was told that my Quad is shipping so I can lend some help with testing as soon as it arrives.
Thanks everybody.
About the opamp instability, I could agree but the enhancement is not so great. It reach about +6dB, so…
I don’t agree the digital filtering equalization.
The ADC is 8bit, so its dynamics is about 46dB.
Also the sampling rate is 72Ms/s, so -to avoid aliasing- we should be able to keep the signal as low as -46dB at fc/2=36MHz.
This is a constraint for the correct sampling: it is useless any further consideration if the ADC sampled signal is noisy. Any digital processing couldn’t repair/equalize that.
Assuming a nominal 15MHz of bandwidth (what’s HugeMan is supposed to obtain), it means that we should be able to have an analog section capable to cut in just one octave over 43dB!
This is not impossible, of course, but it is very hard to obtain (it is a over-16 poles lowpass filter), by keeping a decent flatness within the bandpass.
My deal is having a GOOD analog section, having a flat bandpass from 0 to 10MHz. As “flat” I mean less than -/+1dB.
Anyone of you knows how the analog section switches are closed upon the various settings?
That’s would be comfortable to simulate on a PC before touching any hardware part.
Cheers
I must agree with you now that I have found the SYS source code, that APP_Process.c “Update Trigger” function takes the trigger changes provided by the user interface, passes them to the SYS_Bios.c “SET” function who then uses its “SET_PARAM” function to call its “SendByte” function to pass those new trigger parameters to the FPGA via the I2C serial data bus.
The APP_Process.c “Synchro” function now becomes less clear. It definitely refreshes the LCD screen with the previous captured waveform and it appears to search for min/max values. What is confusing to me is the use of trigger conditions prior to looking a a FIFO buffer input. Maybe you could shed some knowledge on this aspect of that routine.
So at this juncture, we can not tell if the FPGA uses a hardware trigger circuit or if it just runs firmware that scans the captured data similar to the Nano. I will search the Internet for consideration of using an FPGA to form hardware trigger circuits. It is reasonable to expect that Bure had some reference application note for his trigger detection method.
After several hours of research, my initial findings support the following operations, and this seems reasonable to me.
The ADC data sheet has no trigger capabilities defined. One thing I did discover here is that there is an interleave mode where both ADC channels can be connected to the same clock, with one channel having inverted ADC output. It would seem that the single clock approach would have been better (less chance for jitter), with the errant channel’s output simply being 2’s complimented before storage to its Dual-port FIFO buffer.
The FPGA data sheet reveals no comparators either digital nor analog, so a true hardware trigger is unlikely. Most likely the STM ships the trigger parameters to the FPGA, and the FPGA uses look-up tables to find the trigger condition, much the same as a firmware implementation would do, but without lost CPU cycles.
It also appears that when the STM is signaled that the Dual port FIFO buffer is ready, the STM reads the FIFO buffer until it is empty. The ADC is awaiting an empty condition of the Dual-port FIFO buffer and when it finds the buffer empty, then new acquisition captures are commenced in this circular buffer until a trigger is detected. When trigger is found (by the FPGA), then the ADC captures FIFO/2 more bytes and stops sampling. This forces the trigger into the middle of the captured buffer data (FIFO). These methods are not conclusive to the Quad FPGA, but these concepts do reflect the related info I could find on the Internet. These methods allow the STM to use a slower clock to fetch the acquired data from from the Dual-port FIFO. This is done between acquisitions. This method also allows the ADC to stuff the same (but empty) Dual-port FIFO with high speed samples during acquisition. What is neat is that this is done asynchronously with no handshaking between the ADC and the STM.
Another thing I found in this data sheet is that each Dual-port FIFO memory cell is 4K-bits and not 4K-bytes as was the Nano ADC buffer. So it is likely that Bure has joined multiple memory cells to achieve the desired 4K-byte buffers, if that is possible.