DSO Quad bandwidth

Products & Technology DSO Quad
#56

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.

#57

After several hours of research, my initial findings support the following operations, and this seems reasonable to me.

  1. 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.

  2. 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.

  3. 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.

  1. This acquisition and trigger process described above seems to be in agreement with the published firmware code listings for the STM.
#58

Slimfish: I’m not the Nokia guy. :slight_smile:

I agree with concerns with digital filters. But it is cheaper then fixing the hardware (which is the only real solution). Depending of freq ch., maybe filer could not be so big to make problem with performance, power constipation and additional noise. Also, need to be tested if frequency characteristic does not depend on temperature or chosen TD (resistance on transistor switches on input).

But, if the quad works similar as Nano, MAYBE it could be problem with mixing high and low frequencies depending on TD (no LP sampling filter), …, plus maybe missing trigger signals (I’m not sure about that, this is just assumption). I put some comments for Nano. Maybe they could be helpful for Quad: viewtopic.php?f=12&t=1793&p=7157#p7157
But, based on some comments above, maybe Quad works better then Nano. I’m not sure.

#59

Hi lygra,

Briefly:

  1. ADC has no trigger. As far as i know, none of them have (in the sense of start a conversion when reaching a predefined limit).
  2. A FPGA is a very complex device. It’s advantage comes from its versatility in implementing digital logic which can run to 100’s of MHz. It can implement comparators (useful for triggers), adders, multipliers, filters, counters, registers… the list is endless.
  3. Memory: this FPGA has 80 kbit memory (divided in 20 blocks which can be grouped). So this is enough space to fit 2x4096 buffers (analog - 8 bit) and 2x8192 buffers (digital - 1bit). But i don’t know the exact buffer size.

How the scope works (or should work - i don’t want to analyze the code in deep). Again based on my experience:
-STM controls display, periferics & commands to FPGA
-FPGA controls ADC sampling, buffering & trigger.

  1. FPGA is commanded with a trigger mode, threshold, sampling speed, etc. ADC is continuosly sampling and samples are stored in a circular buffer. Once a sample activates the trigger, the FPGA completes the buffer (based on settings) and signal that to STM uC.
  2. uC transfers the buffer to process it locally (compute amplitudes, frequencies, etc) and displays it.
  3. Command FPGA to look for the next trigger.

Maybe i explained everything too simple for you. If i offended you by oversimplifiying, excuse me in advance. It was not my intention for sure.

#60

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.

#61

:astonished:

ROFLMAO please tell me you ment to say “power consumption”

Cheers Pete

#62

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.

#63

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.

#64

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:

  1. Loads the current firmware
  2. Performs the published compensation adjustments
  3. 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.

#65

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.

#66

For Bainesbunch: yes, my English is horrible, plus auto correct option => funny sentiences :slight_smile:

I mean to say that digital filters require more CPU work, so CPU uses more current (power consumption) which reduces battery life.

#67

See my May 14 post at viewtopic.php?f=22&t=2003

#68

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.

#69

Ok, I decided to model the front end of the analog channels, which was done on Multisim.
DSOQ_FE_Schematic.jpg

Here are the results:

DSOQ_FE_F_Response.jpg
DSOQ_FE_Phase.jpg

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.

#70

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.

DSOQ_FE_Schematic_Single_Stage_Optimized.jpg

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.

DSOQ_FE_F_Response_Single_Stage_Optimized.jpg
DSOQ_FE_Phase_Single_Stage_Optimized.jpg

#71

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…
DSOQ_FE_Schematic_Dual_Stage_Optimized.jpg
DSOQ_FE_F_Response_Dual_Stage_Optimized.jpg
DSOQ_FE_Phase_Dual_Stage_Optimized.jpg

#72

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)

#73

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.

#74

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.

#75

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. :wink: