My work is done here in this thread until I get a Quad in my hand for my own bandwidth testing. Too many people here have strayed from scientific observation to conjecture. This includes myself, so I will stop until my test results can be observed and presented to this thread.
ROFLMAO please tell me you ment to say “power consumption”
Cheers Pete
The worst part of this situation is the almost total silence about the Company.
It’s a silence making lot of rumor…
HugeMan, would you explain what will be the future of (our) Quads (at least of mine)?
For anyone is reading at this message: I’ll sell my Quad for a discounted price (having few weeks). Contact me privately.
Bye.
Actually if i recall correctly they (Seeed) offered to change our quads (Beta versions) for production versions once they had ironed all the faults out for the cost of the postage and price difference. Considering the debacle that this has turned out to be i would have thought that they (Seeed) would be trying very hard to do some damage limitation public relations by at least offer to change them free of charge once the are fixed.
They (Seeed) have after all mis sold us a device under the description and sale of goods acts where the item is clearly not as described.
Furthermore if you had bought one to measure signals over 10 meg then it is also not fit for purpose.
COME ON SEEED LET’S SEE SOME RESPONSE TO THESE PROBLEMS !!!
Cheers Pete.
Although I will refrain from further analog bandwidth discussions until I can conduct my own tests, I will not bad mouth the Quad analog bandwidth quality, until someone performs the following:
- Loads the current firmware
- Performs the published compensation adjustments
- Repeats the sinewave bandwidth tests with at least 1Mhz steps, while looking at the ADC input with a high quality scope.
I will do this when I get my replacement Quad. Until someone does all these things, the Quad analog bandwidth is still undefined.
Beta hardware replacement discussions are only valid once it has been determined that the firmware and adjustment procedures can not fix the problems. I don’t think we are there yet. Most things “beta” carry some level of frustration, so why should this be any different? Patience is a virtue that is hard to manage, yet necessary when dealing with “beta” products.
Bainsbunch has a previous post about “lightening up”, and I have to agree with that concept, even though it now appears that “lightening up” appears to have become road kill. Seeed Studio does not control those folks who write the firmware changes, so Seeed certainly can not expedite those updates. It would be most helpful though, if Seeed would confirm when forum issues and concerns have been presented to the manufacturer for action.
By the way, all the above is just my opinion, not factual representation, and is therefore not subject to argument.
Whilst I am not qualified to make any technical input into this debate I have to say that Seeed have been conspicuously quiet on the subject.
I understand the risks of beta systems but when I signed up for the trials by investing my money I have, I believe, a reasonable expectation to see some response from the people who took my money.
One of the reasons for beta testing is to iron out issues like the ones being discussed in this thread and others issues in another thread about firmware improvements which incidentally are getting a response
This thread moved into a technical debate into the theory of what and how to test the units but has not addressed the post that started it all off and that was Seeed telling us that the unit was not coming up to specification.
All I am asking for is a statement from Seeed as to what , if anything, they are doing to address the issue they themselves brought to our attention.
“Lightening” the debate does not mean staying quiet and hopping that seeed will eventually speak up and say something.
Cheers Pete.
For Bainesbunch: yes, my English is horrible, plus auto correct option => funny sentiences 
I mean to say that digital filters require more CPU work, so CPU uses more current (power consumption) which reduces battery life.
I want to correct a previous post which is in error. Further examination of the FPGA (U6) caps C21 and C22, finds that I was mistaken when I thought both caps were 22ufd. Instead, both caps are connected in parallel and C22 is a 105 cap which will provide the necessary decoupling. I think my eyes crossed on that one.
Ok, I decided to model the front end of the analog channels, which was done on Multisim.
Here are the results:
The 3dB point for signal 1 about 700kHz and for signal 2 is about 200kHz.Looking at these large resistors in the front end the results do not surprise me actually – the RC constants are far stretch from minimized. The resistances in the op-amps feedback loops are also way too large to expect overall wide BW. Realistically the front end should be have been buffered and then scaled and sampled.
Keeping in mind that this simulation is assuming perfect conditions (no stray capacitance at the very least) I’d say that the front end needs some work, but this is just my 2c.
If the gain resistors are reduced and front end optimized as is then theoretically one can get up to 10MHz overall flat response @ G=10 according to the OPA2354 datasheet which makes sense. The corrected circuit is shown below. The C9 and C11 10pF caps should be lifted as well as C7A. Feedback resistors should be reduced as much as possible while maintaining the necessary gain.
According to the plots these changes shift the 3dB point for both signals up to 12MHz which in reality is overly optimistic. I’d say 10MHz BW is more realistic but still hard to achieve as it is highly dependent on the PWB layout.
In order to achieve higher BW multiple smaller gain stages are needed. The example below shifts the cutoff to about 27MHz. I think I will try the first solution as it is fairly straight forward given the parts are not something smaller than 0805…
Hi,
i also did the same simulation (i wasn’t aware of geshsoft ones) as geshsoft but with TINA-TI (Texas Instruments). And looking at the simulations i came with the same conclusions. Getting rid of C9, C11 & C73 (or at least use lower capacities) will improve the circuit performance. Also the use of small valued resistors (i.e. 2,7k instead of 27k and keeping the same ratio for others) will also improve bandwith (but that’s a few small resistors -16- to solder).
That said, the only fact that disturbs me from simulation is that i didn’t find the strange channel behaviour venarim described. I suppose this is due to the stray capacitances not modelled in simulator. Sooo, it would be interesting to know how accurate are this simple simulations in order to tweak the circuit.
I leave the circuit as an attachment just in case someone wants to play with it.
QUAD.zip (7.86 KB)
Unfortunately simulators don’t tell the truth at these gain and frequency levels. The biggest problem would be getting stability and I suspect that C9 C11 and C73 were added later to acheive stability. Removing them is probably not an option. PCB layout is everything and having gain switching really makes the layout difficult because the + and - input nodes of the op amps need to be as short as possible. It should be possible to get 15nS rise time with the 27MHz circuit above but it will be difficult. Might be an idea to build up a simple fixed gain circuit first.
Thanks for pointing out that the circuit board traces have resistance, inductance, and capacitance that can greatly affect these circuits. I also suspect that those caps were added through trial and error.
Is there any way to quickly determine if there is a ground plane layer on this board?
It would be interesting if we could find a v2.2 schematic to compare any differences in the front-end circuits.
Yes, pick a powerfull light source and put the PCB in between the light and you. If you could not see through the PCB, then there is probably (could be a VCC one or other - but it’s very unlikely at best) a ground plane. 
I just tried removing C73 (33pF) and it made a remarkable difference to bandwidth on the 0.5v range of ch.A I am now getting -3dB sinewave response to 10MHz. I then used a good quality scope to check the squarewave response at U6, AIN and there was slight overshoot but no instability or ringing.
I have noticed that my DSO Quad will not trigger on timebase ranges of 0.2uS and 0.1uS when set for channel A only (ie. with all other channels in HIDE) Has anyone else seen this?
Yes I agree with the fact that the simulation is just a rough approximate of the real world performance which is not accommodating for parasitics, and I did state so. The gerber files would be something I’d definitely want to see.
I opened up the scope yesterday and the R and C are definitely smaller than 0805, so I will order the parts I need to tweak the front end soon enough. I am planning on running a frequency sweep on the front end only and monitoring with my Tektronix - this way i won’t be limited by any firmware / software faults to properly determine what are its actual capabilities.
As far as slight overshoot - C37 is killing AC performance at higher frequencies just like C9, C11, C10 and C12 do. Removing the capacitors opens up the BW so the op-amp will perform closer to its specs which do show slight overshoot at the falling edge on the step response plot. The behavior is slightly worsened probably by parasitics. As bielec pointed out these capacitors were there as an afterthought or maybe even planned as space holders as compensation network which is fine. I have the feeling that the final values placed in our units did not get tested before hand however. In other words some fine tuning needs to be done to get the max benefit from this very simplified front end.
Like bielec I also noticed the triggering problem at 0.1us and 0.2us. Actually the signal fails to reconstruct properly on the screen once I exceed 2.3MHz or so. I will need to rerun all this once the analog BW is opened up.
I removed C9 and C11. This allowed much better bandwidth but overshoot was present and it varied depending on the input voltage setting. So what is needed is a different overshoot trimming capacitor across each gain setting resistor. That is 6 capacitors for channel A across each of R13,R17,R21,R11,R15,R19. These could be soldered on top of the resistors when proper values are determined.
For the sake of the experiment, I made capacitors from two short lengths of thin teflon coated wire, twisted together and fitted these across the R’s. I acheived acceptable compensation on all ranges and got bandwidth up to about 10MHz with good pulse response enabling me to easily display a 100nS pulse with 20nS edges.
A note on the probe compensating capacitors is in order. For ch A. the influence of C3A and C5A interact depending on voltage setting, making setting up difficult. The method I used was to inject a 10KHz squarewave and adjust for best shape while switching between the 0.5v and 1v ranges.
i am not so skillfull about the circirt , but i think, maybe you stimulation lacks a inportant item, the cpc1017 , which is not a wire when shorted, it contains a C about 30pF between the 2 legs in circuit , and also C between the 2 legs with the ground. that is what the designer (bure) told me, these C make the whole story different…