DSO Quad suggestion and bugs.

The features I need the most on the DSO Quad are time domain measurements. Frequency, duty cycle, etc.

Thanks.

as i tested ,the channel A/B can trace the I2C signals well , what do you mean by “a badly slewed wave that was all but useless to read”, would you please take a picture?

yes, as i think, the threshold on the trigger for C/D may not needed. i will sent your suggestion to the designer…thanks

The trigger exhibits some strange behaviour. For example…

In SINGLE at 20uS timebase, two trigger events are required to cause a displayed waveform. The first event displays HOLD but no waveform is displayed. The second event updates the waveform display while HOLD continues to be shown.

In NORMAL at 20uS, the unit does not trigger on every event but does so occasionally every few events and when it does, the display is only held for a half second or so. If the HOLD button is pressed while in NORMAL - the display will actually refresh on the first trigger event after the HOLD is pressed. ie. it does not actually hold the current display.

[quote="HugeManas i tested ,the channel A/B can trace the I2C signals well , what do you mean by “a badly slewed wave that was all but useless to read”, would you please take a picture?
[/quote]
Sure no problem, but i am out of the country for a week i will do it when i get back. But what i meant was that the wave was far from having vertical edges on the transitions and had apparent rise and fall on the logic high and low levels giving the impression of a saw tooth wave, although not quite as extreme

Cheers Pete.

i have tested, i use 200k signal ,20us, SINGLE, and it can be triggered …also the the NORMAL works well…
would you tell me what the frequency of your signal?

Sure no problem, but i am out of the country for a week i will do it when i get back. But what i meant was that the wave was far from having vertical edges on the transitions and had apparent rise and fall on the logic high and low levels giving the impression of a saw tooth wave, although not quite as extreme

Cheers Pete.
[/quote]
i got your meaning . but i think as the I2C signla (<100K), Quad should trigger the signal well.you should:

  1. conpensate the probe, you can download the maunu"how to adjust the C to calibrate probe " at viewtopic.php?f=22&t=1929
  2. maybe you can check the signal with aother oscilloscope, to check if the signal does what it looks like in the quad.
    thanks

HugeMan wrote…

“i have tested, i use 200k signal ,20us, SINGLE, and it can be triggered …also the the NORMAL works well…
would you tell me what the frequency of your signal?”

My signal was a 5v 1mS pulse repeated once per second. So the frequency was 1Hz.

You will not see this effect if you use a 200KHz continuous waveform because the second triggering will occur immediately.

This becomes an issue when you want to capture eg. the next serial byte from an RS232 port. You set the scope to SINGLE, send the data byte (by hitting a key in Hyperteminal for example) the scope should trigger and hold the byte after it is transmitted. The Quad actually triggers and holds the second key you hit.

I hope this clarifies rather than confuses

Perhaps I should state what I consider to be NORMAL triggering mode.

NORMAL mode should wait until a trigger event then update the display waveform. This waveform should then be held indefinately until a new trigger event occurs. When a new event does occur, the display should be updated. The Quad seems to hold it only for a half second or so. This is how all Tektronix scopes work. (industry leaders)

I agree with your definition and after thinking about this for a while I now wonder:

With multiple traces, how do you accomplish asynchronous trace updates for multiple traces? The big question here is how do you clear one trace without affecting the other traces, especially if someone has the traces overlapping. Vertical positioning makes the trace real estate unknown the firmware considers min and max + vert offset to know which pixels to clear.

Maybe another approach is to delay asynchronous display updates and do them all together at the expense of waveform update rate.

Maybe another approach would be to redraw the old waveform with the pixels turned off, then load the display buffer with the new waveform and then draw the new waveform. Does anyone know how this works on th Quad?

The single trace Nano v3.62 works just as you have described, but the factory version 2.5e did not work that way. Once again the BenF User Guide explains the differences on the Nano.

I got my Quad yesterday, but haven’t had time for extensive testing yet. What I did notice was that the displayed 2Mhz from the Quad generator was completely unrecognizable. Yet a 3.5Mhz squarewave from my function generator looked fairly good with rounded leading edges indicating front end compensation issues. I have not yet tried to compensate the Quad.

This may be somewhat of a digression given the thread topic, but how this is handled has a significant impact on performance and for those with above average interest here is how it’s implemented in the BenF firmware:

On the Nano, this code was a big mess (and still is in the stock firmware) leading to low performance and occasional stuck pixels. The simple solution of course is to redraw everything for every refresh cycle. Unfortunately, a full screen refresh is so time-consuming that frame rate would be severely limited (read-on to see how much slower).

In the BenF firmware, every trace (main waveform, reference waveform, grid lines and cursors) have an identifier embedded as part of its color. That is, color is chosen such that a unique bit is present for each type of trace. So by looking at a single pixel, I can determine from its color code, all waveforms traced through this pixel. From this information it is simple and efficient to remove one trace and leave the others untouched. That is a new vector can be retraced without impacting traces it overlaps.

A waveform is a 300+ point vector whereas the full screen is 300x200 or 60,000 pixels. Reading before writing a pixel doubles processing requirements compared to write only (as would be the case with full refresh), but this is still only a doubling (300+ becomes 600+ pixel operations). Compared to rewriting 60,000 pixels however this is faster by approximately two orders of magnitude (a factor of 100) and so makes a big difference.

Still this issue seems trivial compared to the remaining challenges.

Today I attempted to do some Quad measurements (fresh out of the box sys 1.31, app 2.30. fpga?? (I wanted a base-line before I changed anything)) but I ran into a couple of snags:

All my waveform displays appear to be 1/10 of the sine wave input signal. Where do you set the 1x or 10x probe type? I can’t find a menu choice for that in the Quad Manual 0.91b. Is there a 10x probe selection option?

that is strange , i have tested it before i sent it to you . and , i have told by the designer the Quad do not have the set of 1X or 10X. it recongnize the probe as 1X only .
maybe you need check your peobe again, ensure it is 1X.

Thanks, I just wanted to make sure that there is no probe setting such as in the Nano. Just do the math in your head for 10x probes, OK, but …

There is an obvious mistake in your probe calibration (probe compensation) procedures because you ignore C1A and C2A for 1x probe compensation, yet those caps are always in the circuit and need to be considered. This is especially true if the Quad does not know when a 10x probe is attached. This needs to be sorted out and the probe compensation procedures revised accordingly.

As I said, I used a direct BNC cable, no probe involved. I also tested the MCX to BNC adapter and found zero ohms on the center conductor, so no attenuation there.

I suspect that the calibration is way off because on another scale the display is 1/3rd the input signal.

Apparently you did not test for amplitude on the two scales that I am using, 50mv/Div and 0.5v/Div.

I will calibrate these input ranges and then repeat the tests.

ok, i suggest you upgrage the app,sys and FPGA firmware first and then go on your testing . thanks for your testing reports and i will put your finding to the designer to seek improving the system.
i am now repeat your testing,especilly your finding on applitude error . with app 2.35 sys 1.34 and fpga 2.5

i tested all the V/div of the Quad in my hand, and found it is ok. have you done the channelA and B calibration before your testing?

No, as I said previously, I was first trying out of the box testing with no changes as a base-line. I will calibrate the scales and then repeat the tests before changing software, and then repeating the tests again with the latest software.

I ordered up MCX to BNC adapters (Not from Seeed, got fed up with waiting for them to come up with the goods) with a 90 deg plug and it won’t push far enough into the quad to make contact

… Ho hum another design flaw with this product to add to the bugs and suggestions list. I also bought some Garmin extension cables with … you guessed it 90 deg plugs on them … they don’t push far enough into the unit either. So aside from wasting my money on a useless lump of plastic with a pretty screen on it I also now have a box full of cables that don’t fit it anyway

… Am I beginning to sound a little annoyed … that could be because I am. We have a considerable number of talented people in these forums demonstrating faults and more importantly how to rectify them but SILENCE as to how they propose to implement these findings from Seeed.

We also seem to have an ever growing list of bugs and suggestions … To the best of my knowledge this is nothing more than that, a list, and is serving , if anything, to put potential new clients off and to further add to the frustration of the existing customers watching a list that is growing and never seemingly being addressed.

Ohh and i am also getting fed up with waiting for my digital probes.

Cheers Pete.

Thanks, Pete. I contacted the eBay seller and got this reply,

very sorry about this, as a responsible seller, we will give you refund now

  • just_for_survive

AND they actually refunded my money! I ordered Seeed’s adapter today and in just a few short WEEKS for shipping I’ll be able to let you know if it works.

SEEED! - WHERE ARE OUR DIGITAL PROBES???

Hey Seeed,

Loving my quad. It does just what I expected it to.

Just thought I’d say thank you.

  • tgo

:astonished: :astonished: the digital probes are ready , have you ordered with you coupon?