EEVblog #475 - GW Instek GDS-2000A Oscilloscope Teardown

[EEVblog]

Datasheet links:
http://www.ti.com/lit/gpn/adc08d500
http://www.ti.com/lit/gpn/lmh6518
http://www.analog.com/static/imported-files/data_sheets/ADCMP567.pdf
http://www.analog.com/static/imported-files/data_sheets/AD8370.pdf
http://www.analog.com/static/imported-files/data_sheets/AD8009.pdf
http://www.analog.com/static/imported-files/data_sheets/AD8000.pdf
http://www.analog.com/static/imported-files/data_sheets/AD9834.pdf
http://pdf1.alldatasheet.com/datasheet-pdf/view/151684/GSI/GS88036BGT-333I.html

[marmad]

They have to be overclocking the ADCs - otherwise they'd only have 500MSa/s with all 4 channels on. Or is that what it does? I had thought it was 2GSa/1GSa/s per 2 channels.

Edit: I can't actually find details in the specifications about sample rate with 4 channels active. It just says, "1CH: 2GSa/s; 2CH: 1GSa/s" in the manual.

And thanks for the teardown, Dave 

[Hydrawerk]

Probably they overclock the ADC08D500. http://www.ti.com/lit/ds/symlink/adc08d500.pdf
Well, I am not a Rigol DS2000 fan, but DS2000 has definitely a more powerful hardware. (They should come up with a mixed signal scope, too.)
GDS-2000A's crippled intensity gradation is not because of a bad firmware.

[Hydrawerk]

Anyway, what's the custom ADC used in Rigol DS2000?
http://farm9.staticflickr.com/8449/8022102149_eee53ee85d_h.jpg
I expect that it's a real 2×1GSa/s ADC, isn't it?

[marmad]

Dave - the strange stuttering of the display updating that happened during your first video might well support your theory that the display is being driven directly by the AD Blackfin.

[EEVblog]

Anyway, what's the custom ADC used in Rigol DS2000?

It's not custom. I recall someone worked it out based on the pinout, and was likely the same or similar chip.

[EEVblog]

They have to be overclocking the ADCs - otherwise they'd only have 500MSa/s with all 4 channels on. Or is that what it does? I had thought it was 2GSa/1GSa/s per 2 channels.

I cam confirm that it says 1GSPS when all 4 channels are turned on. With only 4 x 500MSPS converters...

[EEVblog]

Dave - the strange stuttering of the display updating that happened during your first video might well support your theory that the display is being driven directly by the AD Blackfin.

That is most likely.

[grego]

Dave - the strange stuttering of the display updating that happened during your first video might well support your theory that the display is being driven directly by the AD Blackfin.

That is most likely.

I've emailed the InstekUSA folks to see if they can get an answer.  If/when I get a reply I'll post it.

[marmad]

It's not custom. I recall someone worked it out based on the pinout, and was likely the same or similar chip.

Branadic (in the DS2000 Teardown thread) claimed the Rigol-rebadged ADC pinouts matched the TI ADC08DL502 - which is similar - and would also be overclocked.

From the TI literature:
Quote: "...Although the ADC08DL502 is tested and its performance is guaranteed with a differential 1 GHz clock, it typically will function well with input clock frequencies indicated in the Converter Electrical Characteristics.... Operation up to the sample rates indicated in the Converter Electrical Characteristics is typically possible if the maximum ambient temperatures indicated are not exceeded. Operating at higher sample rates than indicated for the given ambient temperature may result in reduced device reliability and product lifetime. This is because of the higher power consumption and die temperatures at high sample rates. Important also for reliability is proper thermal management..."

I would assume the ADC08D500 has similar specs - and Instek has heatsinked the ADCs and has the fan blowing almost directly onto them.

[Hydrawerk]

Operating at higher sample rates than indicated for the given ambient temperature may result in reduced device reliability and product lifetime.

I wonder how critical it might be. We see that the ADC is still the most expensive part of a scope... Only in DSOX2000 you get real 2×1GSa/s ADC and thus maybe (?) longer lifetime. But you only get that funny 100kpoints memory... 

[EEVblog]

Only in DSOX2000 you get real 2×1GSa/s ADC and thus maybe (?) longer lifetime. But you only get that funny 100kpoints memory... 

Agilent have the benefit of their own custom ASIC for the both the ADC and the main chip. The benefits of being a huge company like that with an extensive R&D history.
This is why the "big three" (HP/Agilent, Tek, and Lecroy) were the only companies that could offer GSPS class scopes until Rigol came along with their 5000 series and did it with off the shelf chips.
AFAIK, the "big three" are still the only ones that roll their own silicon.

[marmad]

Operating at higher sample rates than indicated for the given ambient temperature may result in reduced device reliability and product lifetime.

I wonder how critical it might be. We see that the ADC is still the most expensive part of a scope...

That's why I'm fairly certain Instek is making sure to operate them within whatever the given temperature is for the higher sample rate. I wouldn't worry about it - DSO makers have been overclocking ADCs for years now - and there doesn't seem to have been massive amounts of ADC failures because of it.

[marmad]

Only in DSOX2000 you get real 2×1GSa/s ADC and thus maybe (?) longer lifetime.

There's no conclusive evidence that this is true. Although Branadic hypothesized that Rigol was using an overclocked TI chip, I suspected instead that Rigol may be using the MXT2001 Chinese ADC that is 2 x 1GSa/s (same one that has been used successfully for the last 2 years in the higher BW Owon SDS models). The fact that Rigol didn't heatsink the ADC would tend to support my theory - although I suppose you might be able to figure it out by simply measuring the heat of the chip while it's running.

[EEVblog]

That's why I'm fairly certain Instek is making sure to operate them within whatever the given temperature is for the higher sample rate. I wouldn't worry about it - DSO makers have been overclocking ADCs for years now - and there doesn't seem to have been massive amounts of ADC failures because of it.

I concur. I'm sure Instek have done their homework on it.

[BravoV]

Saw a coin cell battery in the main board, is that for cal memory backup or just for rtc ?

[tinhead]

They have to be overclocking the ADCs - otherwise they'd only have 500MSa/s with all 4 channels on. Or is that what it does? I had thought it was 2GSa/1GSa/s per 2 channels.

I cam confirm that it says 1GSPS when all 4 channels are turned on. With only 4 x 500MSPS converters...

oh well, what the firmware is showing is one thing, you probably don't have 250MHz+ signal generator to check if the DSO can still sample it properly,
but i'm sure you can build simply source in a minute. Another way is to measure ADC clock in, it must be 1GHz clock when 4ch enabled and they really overclock.
But somehow i don't think so, i think this is firmware bug showing 1GS/s where only 500MS/s are availabe, if they were overclokcing, why they not used then
"2GS/s on 2 channels and 4GS/s on one channel" announcement? Nobody would overclock only for 4ch mode, but even if (i would really wonder) than without
announcement must be higly unstable and they hoping that users not using 4ch that often? No, not Instek. So i would say, bug in what firmware is diplaying.

[tinhead]

Well, I am not a Rigol DS2000 fan, but DS2000 has definitely a more powerful hardware. (They should come up with a mixed signal scope, too.)
GDS-2000A's crippled intensity gradation is not because of a bad firmware.

crippled can be only something when there could be not crippled as well. But there is no international standard how deep intensity gradation need to be.

One can use properly implemented 16 steps (like VPO color grading), other bad implemented up to 256 steps (Rigol missing color grading).
It is always point of view, so being more specific when describing things could be more accurate.

[tinhead]

Branadic (in the DS2000 Teardown thread) claimed the Rigol-rebadged ADC pinouts matched the TI ADC08DL502 - which is similar - and would also be overclocked.

There's no conclusive evidence that this is true. Although Branadic hypothesized that Rigol was using an overclocked TI chip,
I suspected instead that Rigol may be using the MXT2001 Chinese ADC that is 2 x 1GSa/s

and you right, what Branadic didn't saw is the missing mux unit in ADC08DL502. I do have here ADC08D502 (which is nothing else than not-low power version),
there is as well no mux inside. I've tested by using is as it would be ADC08D500, but no chance, i don't got expected results.

Btw, you can overclock these ADCs, no big deal, but i haven't managed to get that high as they would req. in Rigol DS2k.

From the TI literature:

TI did simply copy/paste without chaning important things in the datasheet. This is actually why i ordered ADC08D502 and tried to enable mux,
in the datasheet the part of specs is still there, so i thought "ohh, maybe it is there".

(same one that has been used successfully for the last 2 years in the higher BW Owon SDS models).

not anymore, they using now "original" ADCs from AD, probably Rigol bought so many that Owon didn't had any chance as to change supplier.

[sg-o]

I think the g13 #119 is? a LM119 High Speed Dual Comparator. But thats only a guess.

[EEVblog]

Saw a coin cell battery in the main board, is that for cal memory backup or just for rtc ?

Presumably just RTC. No one does volatile cal values any more.

[tinhead]

I think the g13 #119 is? a LM119 High Speed Dual Comparator. But thats only a guess.

giving the fact that on the other side of the cable MC10H125 has been used (with diff ECL signals) and no channel offset circuit available
in LA module (but in the POD) i would say they are ECL comparators like ADCMP580 (which have G12 branding btw.), however dual channel version.

[EEVblog]

giving the fact that on the other side of the cable MC10H125 has been used (with diff ECL signals) and no channel offset circuit available
in LA module (but in the POD) i would say they are ECL comparators like ADCMP580 (which have G12 branding btw.), however dual channel version.

Here is the LA module:


The input go to MECL-TTL translators: http://www.onsemi.com/pub_link/Collateral/MC10H125-D.PDF

So no other circuitry in the module to do programmable threshold. So it must be in those head chips.

[MysteryBunny]

This is a bit long, but these are my thoughts on the FPGA and MCU choice:

Blackfin always gets picked because of high MMAC which is like 400-2000 cycles ( other MCU's don't have it @ 400-600mhz which is the sweet spot... Upper end for ARM MCU is around 500-1ghz. People rarely buy above 1GHZ, and often stay at around 400-700mhz... These are cheaper than TI's sitara line, also doesn't have the multiply-accumulate blocks, so Blackfin is #1 )... Also almost all these low end MCUs have video controllers, most designers do not use them because it's more power draw/disruption/routing ( I'm not going to lie. I agree that you can be one sided and say it's laughable @ 700mW-1W range of MCU. Mostly because this isn't battery-powered )...

Altera FPGA w/ 30K LUT 4/6 ( cyclone), which is above average and more expensive than buying a popular FPGA ( sign of a mistake) $25-50 depending on volume. ( vs $10-25 for 10-22k -> most common cyclone IV ) You'd need a spartan 45LXT to outdo that, which is getting to be pricey/specialized... They must've wanted the gate count badly ( Don't they use LX 25s in rigol scopes? I see it in everything, it's SOO cheap )... The crutch is they can pass DSP between the blackfin and the cyclone IV-E... Cyclone usually has better dsp ( more hard IP for it ) than spartan, but the mid-range on xilinx FPGAs is the winner (ie. Artix or better)... Expensive enough to be near SoC-type FPGA price range. Altera boasts so much about systems integration ( the newer series than this has an SoC line with hard-IP dualcore A9 MCUs, so you can tell what altera wants to sell to it's customers )

The one thing I felt weird about was how many filter caps are in that PSU... That molex isn't even the choice one from their catalog. It must be hard to balance ( Analog devices has a video on why you should keep the power planes as close as possible to the A/D)... I think you should really have the A/D and the FPGA near the front end, and then the MCU behind that, especially because an MCU can't handle multiplexing...

Everything seems confused and vaguely artsy, which attempting an art piece is foolish... The front of it is so stupid looking. It's not really ugly, it's just poorly thought-out and rushed... A lot of those knobs/buttons don't need to be there... In the end the design was rushed with the cheap MAX II Z here which is actually SRAM cell FPGA with flash hiding as a CPLD...( Think of lattice semiconductor FPGAs, or an atmel )... DDS is not the first choice compared to a true synth ( DDS is also hated for high-speed microwave signals too. It's a bad choice beyond 2GHZ ), but I guess it's fine as long as you have proper amplification/filtering...

We aren't in the 1990s, but ALSO I can't say that so fast because... The pin capacitance from using those HUGE and stupid PCB headers on the function-gen probably means none of this stuff winning speed and bandwidth records... I've seen sockets like that where you can do that, but that's for PCI-X and you need at least four 2.x-3.x pericom switches in an array just to deal with all the channels ( Around $7 a switch )... This looks like it doesn't even matter to them LOL...

[marmad]

Nobody would overclock only for 4ch mode, but even if (i would really wonder) than without announcement must be higly unstable and they hoping that users not using 4ch that often? No, not Instek. So i would say, bug in what firmware is diplaying.

Why would you think they're only overclocking in 4ch mode? They make 2 and 4 channel versions of the scope - the two groups of channels are separate from each other (they each have their own bank of 2M memory which is not shared).  I would assume that one of the ADC spots is unpopulated in the 4ch version (spend an extra ~$125 in BOM costs for an ADC on an $800 DSO which is not needed?). The fact that the ADCs are heatsinked and that the fan is installed to blow directly on to them makes me think it's more likely that they are overclocked than that there's a bug in the firmware. According to the specs, these ADCs should do 1GSa/s as long as there is correct thermal management.

[MysteryBunny]

Nobody would overclock only for 4ch mode, but even if (i would really wonder) than without announcement must be higly unstable and they hoping that users not using 4ch that often? No, not Instek. So i would say, bug in what firmware is diplaying.

Why would you think they're only overclocking in 4ch mode? They make 2 and 4 channel versions of the scope - the two groups of channels are separate from each other (they each have their own bank of 2M memory which is not shared).  I would assume that one of the ADC spots is unpopulated in the 4ch version (spend an extra ~$125 in BOM costs for an ADC on an $800 DSO which is not needed?). The fact that the ADCs are heatsinked and that the fan is installed to blow directly on to them makes me think it's more likely that they are overclocked than that there's a bug in the firmware. According to the specs, these ADCs should do 1GSa/s as long as there is correct thermal management.

Here's the answer: Page 25 of the manual:

Dual-Edge Sampling
The DES mode allows one of the ADC08D500's inputs (I or Q Channel) to be sampled by both ADCs. One ADC
samples the input on the positive edge of the input clock and the other ADC samples the same input on the other
edge of the input clock. A single input is thus sampled twice per clock cycle, resulting in an overall sample rate of
twice the input clock frequency, or 1 GSPS with a 500 MHz clock.

In this mode the outputs are interleaved such that the data is effectively demultiplexed 1:4. Since the sample rate
is doubled, each of the 4 output buses have a 250 MSPS output rate with a 500 MHz input clock. All data is
available in parallel.

**************
Note: You also can overclock this too... Page 19-22 has the results of doing so...

Look at the graph on FG 19. (Page 20) FG. 29 (Page 22)... You'll see that it's great at 500mhz, pretty bad accuracy at 1GHZ (even 800mhz sucks), and horrible at 2GHZ... This is also 8-bit sampler, it isn't a 14-16 bit precision one either... I can't imagine how terrible it would be at 2GHZ. It's funny to imagine though...

This one is older too, 1.4mW and from 2005... I am guessing 90nm gate pitch? Anyways all the new A/D converters for this range are around 700mw - 1 watt... Ti thinks that the A/D for battery powered oscilloscopes should be 300mW. I'm sure you can get away with even a 700mW one ( even the low-end ones are 500-750 MSPS and more features than this vs a 250MSPS 300mW one... Practically double the performance if you look at the specs, but way more power cost, almost better to just buy more than one )...

Also this thing has SDR and DDR output, which is maybe why they wanted the Cyclone IV @ 100mhz... Cyclone always gets picked for low end smoke and magic DSP/memory stuff... It always prefers SDR or HDR clocks ( they have videos on using DDR3 with the 100mhz FPGA internal clock ) ...I've also seen a pericom IC for cyclone IVs to use PCI-X 3.0 lanes... As strange as that sounds.

[EEVblog]

Dual-Edge Sampling
The DES mode allows one of the ADC08D500's inputs (I or Q Channel) to be sampled by both ADCs. One ADC
samples the input on the positive edge of the input clock and the other ADC samples the same input on the other
edge of the input clock. A single input is thus sampled twice per clock cycle, resulting in an overall sample rate of
twice the input clock frequency, or 1 GSPS with a 500 MHz clock.

That still doesn't explain how they get 2GSPS. To do that without "overclocking" would require both of the chips (4 converters) + switch circuitry for one channel.
But the system firmware still claims 2GS/s is maintained when channels 1 and 3 are on, so it can't possibly be doing that, it must be using 2 converters max per channel.
So the ADC's must be clocked at 1GHz.

[marmad]

One can use properly implemented 16 steps (like VPO color grading),

I see we're back to the same 'discussion'.    While I would agree that 16 vs 256 colors is less important in color grading than intensity grading (see attached images of color graded square wave sweep with 16 and 256 colors), I would still like to think that I live in the present time - and not back in the 4-bit game days. 

[MysteryBunny]

Dual-Edge Sampling
The DES mode allows one of the ADC08D500's inputs (I or Q Channel) to be sampled by both ADCs. One ADC
samples the input on the positive edge of the input clock and the other ADC samples the same input on the other
edge of the input clock. A single input is thus sampled twice per clock cycle, resulting in an overall sample rate of
twice the input clock frequency, or 1 GSPS with a 500 MHz clock.

That still doesn't explain how they get 2GSPS. To do that without "overclocking" would require both of the chips (4 converters) + switch circuitry for one channel.
But the system firmware still claims 2GS/s is maintained when channels 1 and 3 are on, so it can't possibly be doing that, it must be using 2 converters max per channel.
So the ADC's must be clocked at 1GHz.

They blanked out the maximum for both, which I guess in those amplification and noise solutions are up to the designer...

In fact it even says for DES mode 900mhz is "typical" @ PG. 9

They say a "typical" for non-DES is 1.7ghz @ PG. 8

2GHZ @ +/- 7 DB loss... @ page FG 29. Page 22 of the A/D manual

So You can easily push this to 1GHZ with +/- 3 DB loss... WHILE in DES mode I am guessing?

**************
Note: You also can overclock this too... Page 19-22 has the results of doing so...

Look at the graph on FG 19. (Page 20) FG. 29 (Page 22)... You'll see that it's great at 500mhz, pretty bad accuracy at 1GHZ (even 800mhz sucks), and horrible at 2GHZ... This is also 8-bit sampler, it isn't a 14-16 bit precision one either... I can't imagine how terrible it would be at 2GHZ. It's funny to imagine though....

[MysteryBunny]

One can use properly implemented 16 steps (like VPO color grading),

I see we're back to the same 'discussion'.    While I would agree that 16 vs 256 colors is less important in color grading than intensity grading (see attached images of color graded square wave sweep with 16 and 256 colors), I would still like to think that I live in the present time - and not back in the 4-bit game days. 

Around 20 years ago ( when I was a child ) I remember programming linear 320x200 @ 4-bit -> 16 color...

Honestly though it's much better to have 8-bit (256), not to mention an 8-bit video controller has a lot more direct-writes which attribute it's speed vs linear video memory fills... You could even have an 8-24 bit VESA card, which those at best use like 4MB of video memory... Today that can even be done on a cheap FPGA with just leftover SRAM...

I feel really attached to old monochrome green CRTs... I mean I'm even fine with monochrome stuff sometimes... I felt really amazing when I had a monochrome adapter I scored with 2MB of video memory !!!! It was INTENSE! It blew away the 640KB on my VGA card!!! I remember even having terrible CGA with cyan/magenta/white/black... MIGHT AS WELL GO BACK TO CGA LMFAO!!! Hahaha god awful, but it's so funny! I Had to say it!! YES to CGA oscilloscopes then....

[madires]

No gold plated BNC center pin? Or have I got that wrong?

[marmad]

One can use properly implemented 16 steps (like VPO color grading), other bad implemented up to 256 steps (Rigol missing color grading).

Honestly though, I think the grading implementation on ALL of these current models is somewhat lacking. The difference between mapping a number directly as intensity - or using it as a pointer to a color lookup table for color grading - is minimal in terms of code - and very easy to implement. And even if looking up colors is a bit slower, you can just accept the hit in performance if doing it (as opposed to normal intensity). IMO, all of the current grading DSOs should allow both - and more so, they should allow you to load your own color tables - then you could have, for example, 2-color gradients and other helpful tools for visualization of data.

[tinhead]

I live in the present time

honestly, not even i can recognize the difference bewteen 2 of 256 neighborhood colors when the screen is flickering with 50Hz^^,
but marketing ppl telling us since years that we need 100Mpix cam and 20bil. color led tv, yeah i know.

I see we're back to the same 'discussion'

i was talking about the use of word "crippled", here is nothing crippled as there is no standard what un-crippled grading have to be.
And depending of your need and point of view you might see missing color grading on Rigol as crippled implementation, where
Instek (even when only 16 colors) did it properly ... Seriously, i would sugest to focus on other things than the amount of colors,
some ppl would prefer or even better recognize color changes than intensity changes in single color.

EDIT: i see you posted something right now, i agree to that "the grading implementation on ALL of these current models is somewhat lacking...."

[tinhead]

Altera FPGA w/ 30K LUT 4/6 ( cyclone), which is above average and more expensive than buying a popular FPGA ( sign of a mistake) $25-50 depending on volume. ( vs $10-25 for 10-22k -> most common cyclone IV ) You'd need a spartan 45LXT to outdo that, which is getting to be pricey/specialized... They must've wanted the gate count badly ( Don't they use LX 25s in rigol scopes? I see it in everything, it's SOO cheap )...

regardless of other things (like more PLLs in Cyclone) check the pincount, you need (as Rigol did) to use two Spartan 6 (LX 25) to get the amount of pins on Cyclone (532 user i/o).
So yes, they could use two Spartans 6 to connect the "same" amount of memory, or single Cyclone FPGA with high pin count. The amount of SRAM memory is the same
(4 x GSI or 2 x Cypress SRAM), they not using DDR (as they don't haev the looooong record capability as Rigol is having), so 256Mb DRAM is enough - together with high pincount
they saved one FPGA.

I think you should really have the A/D and the FPGA near the front end, and then the MCU behind that, especially because an MCU can't handle multiplexing...

on what images are you looking? i see good placement, everything stright forward from input to ADC, then to FPGA. The total distance didn't matter here.

In the end the design was rushed with the cheap MAX II Z here which is actually SRAM cell FPGA with flash hiding as a CPLD

afaik MAX II is necessary to map memory, this is due the DSP they using.

In fact it even says for DES mode 900mhz is "typical" @ PG. 9
They say a "typical" for non-DES is 1.7ghz @ PG. 8
2GHZ @ +/- 7 DB loss... @ page FG 29. Page 22 of the A/D manual
So You can easily push this to 1GHZ with +/- 3 DB loss... WHILE in DES mode I am guessing?

Look at the graph on FG 19. (Page 20) FG. 29 (Page 22)... You'll see that it's great at 500mhz, pretty bad accuracy at 1GHZ (even 800mhz sucks), and horrible at 2GHZ...

you mixing so many things, really. SNR, signal gain or FPBW have nothing to do with max. sample rate.

This is also 8-bit sampler, it isn't a 14-16 bit precision one either... I can't imagine how terrible it would be at 2GHZ. It's funny to imagine though...

  ? i don't think you know what you talking about, really. This ARE 8 bit DSOs, and again FPBW is not sampling rate.

That still doesn't explain how they get 2GSPS. To do that without "overclocking" would require both of the chips (4 converters) + switch circuitry for one channel.
But the system firmware still claims 2GS/s is maintained when channels 1 and 3 are on, so it can't possibly be doing that, it must be using 2 converters max per channel.
So the ADC's must be clocked at 1GHz.

Good point Dave, there is nothing what could mux to get 2GS/s per channel.

As said above, you can overclock ADC08D502 to ~700MHz (which is nothing else than ADC08D500 with no Q/I mux and clock inverter), however i haven't managed to more here
(yeah, i haven't used any active cooling, that could be the secret). So it seems (haha, and what if these DSOs can really only 500MS/s per channel when 4 enabled? No, bad joke)
they really overclocked. Instek was already in the past "the pionier" in AD9288 overclocking (they found that 125MHz for even 40MHz AD9288 are possible), so i assume they did
it again very smart.

[Hydrawerk]

There's no conclusive evidence that this is true. Although Branadic hypothesized that Rigol was using an overclocked TI chip, I suspected instead that Rigol may be using the MXT2001 Chinese ADC that is 2 x 1GSa/s (same one that has been used successfully for the last 2 years in the higher BW Owon SDS models). The fact that Rigol didn't heatsink the ADC would tend to support my theory - although I suppose you might be able to figure it out by simply measuring the heat of the chip while it's running.

Rigol guys are clever, so they camouflaged their ADC...
And GW Instek is good at overclocking ADCs. You've probably seen this review. http://welecw2000a.sourceforge.net/docs/Hardware/GW_Instek_GDS-1152A.pdf

[marmad]

I see we're back to the same 'discussion'

i was talking about the use of word "crippled", here is nothing crippled as there is no standard what un-crippled grading have to be.

I knew what you meant and I agreed with you - that comment was a joke - thus the  which you removed.

honestly, not even i can recognize the difference bewteen 2 of 256 neighborhood colors when the screen is flickering with 50Hz^^,

So two levels of gradation would be enough for you?

Seriously though, the purpose of a DSO with grading is to get as much discrete sample information to the screen as possible with each refresh. The number of levels (up to a point) - whether doing intensity of color grading - affects that. The question then becomes, what is the level at which information saturation (the inability to distinguish more information) occurs? Since research tends to indicate that we can't really distinguish between more than about 100 levels of brightness, 6 or 7 bits of intensity gradation would probably suffice. This is more then might be necessary with color grading, since the eye is more likely to register a change of hue then variations of the brightness within that hue. But since color indexing is generally done with nibbles - and since 4-bits seems too few to do adequate intensity grading (i.e. the most information possible), it makes sense to me to want, ideally, a DSO which uses 8-bits of discrete levels - which I can chose to map to intensity or a color table of my own choosing.

So to sum up (IMO):
GW-Instek has the right idea about types of grading - but the wrong idea about the number of levels.
Rigol and Agilent have the right idea about the number of levels (more or less) - but the wrong idea about types of grading.
They all have the wrong idea when it comes to letting the user define their own table for gradation.

[tinhead]

So two levels of gradation would be enough for you?

noo .. of course not, what i meant was single color gradiation is like yellow and bit dark yellow

So to sum up (IMO):
GW-Instek has the right idea about types of grading - but the wrong idea about the number of levels.
Rigol and Agilent have the right idea about the number of levels (more or less) - but the wrong idea about types of grading.
They all have the wrong idea when it comes to letting the user define their own table for gradation.

agree

[tom66]

The FPGA looks to be handling the display at least partially, because it has SRAM (for the sample data) and DRAM (for some video memory.) I think it is probably handing the 80,000 wfm/s.

To get intensity grading it is actually a fairly simple process. Capture one screenful (512/1024 samples) of the waveform and sum it onto an X/Y grid. Repeat for as many times as necessary. Divide to get scale from 0-N (64? 128? 256?). I expect it stores the resultant image in the DRAM.

What it then does is either send 20~60 frames/sec to the Blackfin, or the Blackfin sends the OSD data to the FPGA, which then draws the screen, but no situation requires 80kwfm/s to be handled by the Blackfin.

I have prototyped a DPO oscilloscope controller on a rather wimpy Cyclone III (in simulation.) It worked quite well, with 64 levels of intensity at 60 frames/second (~4kwfms/s) and external RAM for the 320x240 display.

Also, it would appear if there's no point in going beyond say 256 levels, then anything higher than 256 x 60 frames/sec (for typical LCD panel) ~ 16kwfms/s, unless the controller makes exception for single sample events (count of one on the pixel grid) and ensures they are visible.

[marmad]

To get intensity grading it is actually a fairly simple process. Capture one screenful (512/1024 samples) of the waveform and sum it onto an X/Y grid. Repeat for as many times as necessary.

DSO makers have invented different techniques to do the intensity grading since it's often combined with sample decimation; there isn't just one way you can do it.

Divide to get scale from 0-N (64? 128? 256?)

16...  I guess you haven't been following the conversation? 

...but no situation requires 80kwfm/s to be handled by the Blackfin.

But who implied that it did? The question was always about display updating - never about acquisition. On the Agilent and Rigol, display updating is handled by an ASIC/FPGA - on the Instek it appears that the Blackfin does it.

Also, it would appear if there's no point in going beyond say 256 levels, then anything higher than 256 x 60 frames/sec (for typical LCD panel) ~ 16kwfms/s, unless the controller makes exception for single sample events (count of one on the pixel grid) and ensures they are visible.

There's no point in going beyond 256 levels (or possibly even 128) because we can't perceive smaller differentiations. It has nothing to do with the refresh rate since intensity grading can persist beyond individual refreshes.

[tom66]

TL;DR this thread -- I was just mostly replying to Dave's comment in the video that the Blackfin would have to handle 80kwfms/s. I haven't yet thought about how intensity grading would persist across frames; I thought that was just known as persistence and typically done by storing several LCD images in memory and summing them together at a later time, usually by the CPU (a bit complicated to try and add all that logic onto the FPGA.)

[mikeselectricstuff]

But who implied that it did? The question was always about display updating - never about acquisition. On the Agilent and Rigol, display updating is handled by an ASIC/FPGA - on the Instek it appears that the Blackfin does it.

I don't think there is any evidence for that other than slighly closer proximity of LCD connector, but there's stuff in the way of it being any closer to the FPGA

There's no point in going beyond 256 levels (or possibly even 128) because we can't perceive smaller differentiations. It has nothing to do with the refresh rate since intensity grading can persist beyond individual refreshes.

There is potentially a point in acquiring more than 256 as you can adjust intensity after acquisition, so you can augment the 256 displayable intensitoes with the range of the user intensity control - even during acquisition there would be benefits in a user-twiddleable non-linear mapping of, say, 12 bits of intensity to 256 visible levels.

 

[MysteryBunny]

Altera FPGA w/ 30K LUT 4/6 ( cyclone), which is above average and more expensive than buying a popular FPGA ( sign of a mistake) $25-50 depending on volume. ( vs $10-25 for 10-22k -> most common cyclone IV ) You'd need a spartan 45LXT to outdo that, which is getting to be pricey/specialized... They must've wanted the gate count badly ( Don't they use LX 25s in rigol scopes? I see it in everything, it's SOO cheap )...

1.) regardless of other things (like more PLLs in Cyclone) check the pincount, you need (as Rigol did) to use two Spartan 6 (LX 25) to get the amount of pins on Cyclone (532 user i/o).
So yes, they could use two Spartans 6 to connect the "same" amount of memory, or single Cyclone FPGA with high pin count. The amount of SRAM memory is the same
(4 x GSI or 2 x Cypress SRAM), they not using DDR (as they don't haev the looooong record capability as Rigol is having), so 256Mb DRAM is enough - together with high pincount
they saved one FPGA.

I think you should really have the A/D and the FPGA near the front end, and then the MCU behind that, especially because an MCU can't handle multiplexing...

2.) on what images are you looking? i see good placement, everything stright forward from input to ADC, then to FPGA. The total distance didn't matter here.

In the end the design was rushed with the cheap MAX II Z here which is actually SRAM cell FPGA with flash hiding as a CPLD

3.)afaik MAX II is necessary to map memory, this is due the DSP they using.

In fact it even says for DES mode 900mhz is "typical" @ PG. 9
They say a "typical" for non-DES is 1.7ghz @ PG. 8
2GHZ @ +/- 7 DB loss... @ page FG 29. Page 22 of the A/D manual
So You can easily push this to 1GHZ with +/- 3 DB loss... WHILE in DES mode I am guessing?

Look at the graph on FG 19. (Page 20) FG. 29 (Page 22)... You'll see that it's great at 500mhz, pretty bad accuracy at 1GHZ (even 800mhz sucks), and horrible at 2GHZ...

4.) you mixing so many things, really. SNR, signal gain or FPBW have nothing to do with max. sample rate.

This is also 8-bit sampler, it isn't a 14-16 bit precision one either... I can't imagine how terrible it would be at 2GHZ. It's funny to imagine though...

5.) ? i don't think you know what you talking about, really. This ARE 8 bit DSOs, and again FPBW is not sampling rate.

That still doesn't explain how they get 2GSPS. To do that without "overclocking" would require both of the chips (4 converters) + switch circuitry for one channel.
But the system firmware still claims 2GS/s is maintained when channels 1 and 3 are on, so it can't possibly be doing that, it must be using 2 converters max per channel.
So the ADC's must be clocked at 1GHz.

Good point Dave, there is nothing what could mux to get 2GS/s per channel.

As said above, you can overclock ADC08D502 to ~700MHz (which is nothing else than ADC08D500 with no Q/I mux and clock inverter), however i haven't managed to more here
(yeah, i haven't used any active cooling, that could be the secret). So it seems (haha, and what if these DSOs can really only 500MS/s per channel when 4 enabled? No, bad joke)
they really overclocked. Instek was already in the past "the pionier" in AD9288 overclocking (they found that 125MHz for even 40MHz AD9288 are possible), so i assume they did
it again very smart.

1.) Cheaper to use other FPGAs like I said, but english is not your strength. I am sorry for the confusion my friend! I love the detail in this blog and english is my native language, no offense to you...

2.) I was simply rambling on why the FPGA is always a good choice near the front end... I was not criticising it, it's a common practice, and I'm using that type of setup for my front end in my current project... This is an education blog! I'm very sorry you thought I meant it was an attack on it LOL? I think it's the inevitable and a good lesson in proper design....

3.) If your english was better ( no offense ) you'd see I was joking about how cheap the max II Z is... ( It's actually an FPGA hiding as a CPLD w/flash ) ...You can judge the quality of the module just by that.

4.) SnR/attenuation changes with the clock frequency, which people were asking what happens when you overclock it... It's meaningless yes you can see that... If you know how the A/D steps through in a delta-sigma converter, you will know that noise creates poor samples, but that's really just a filtering/attenuation issue... I had to post that even in the manual it says a 3db loss which isn't a big deal but I guess no one had noticed that and was still speculating about it... Obviously it overclocks to 1GHZ, it can even do 2GHZ ( with problems )...

5.) I was making a joke about 14-bit precision non-sampling A/D converters. And this is a sampling one... Apples to oranges, you'd never see the 14-16 bit in many scopes really... So the accuracy obviously isn't a huge deal here since you can just amplify for your signal loss when you overclock... I'm implying a lot of things here.

[tinhead]

you moron, you still didn't got what SNR vs Input Freq means? Or FPBW vs input freq? That's the both figures (19, 29)
from datasheet (the both you talk about), and they don't have anything to do with sample rate.

You can perfectly sample with 250MHz a 2Ghz signal, but probably this is too complex to understand as my english is too bad?

If i were you, i would say "ohh shit, you right" and not try to make someone stupid by pointing out the language.

[marmad]

I don't think there is any evidence for that other than slighly closer proximity of LCD connector, but there's stuff in the way of it being any closer to the FPGA

Sure there was, although it was only circumstantial evidence: the strange, repetitious, freezing of the display updating that happened during Dave's previous video. I don't know about your Agilent, but I've never seen that behavior on my Rigol under any circumstance.

There is potentially a point in acquiring more than 256 as you can adjust intensity after acquisition, so you can augment the 256 displayable intensitoes with the range of the user intensity control - even during acquisition there would be benefits in a user-twiddleable non-linear mapping of, say, 12 bits of intensity to 256 visible levels.

I suppose, although after acquisition there is no grading (i.e. three-dimensional data); it's just the last waveform captured in sample memory displayed with a single intensity - unless you have access to the 'digital phosphor' buffer as you do on some DSOs, but I certainly don't have that on the Rigol.

But I can imagine some circumstances where having more levels might prove to be useful - but considering what manufacturers are offering currently - I'd be happy with a well-implemented 256.

[MysteryBunny]

you moron, you still didn't got what SNR vs Input Freq means? Or FPBW vs input freq? That's the both figures (19, 29)
from datasheet (the both you talk about), and they don't have anything to do with sample rate.

You can perfectly sample with 250MHz a 2Ghz signal, but probably this is too complex to understand as my english is too bad?

If i were you, i would say "ohh shit, you right" and not try to make someone stupid by pointing out the language.

No offense to your english once again! I used to speak some french and other languages! I hope you understand I respect that... I don't understand where you are trying to go with this? I am talking about the accuracy of using beyond 500mhz sweeps... I posted earlier that when you chain the ADCs you can get double the amount of sweeps in DES mode, but the latency limits them ( this was confirmed too obviously, in the manual also )... You can also overclock too. But once again I like to comment about noise, because noise is part of my world so much...

Maybe this is easier to read: The noise is going to be very high from overclocking... I'm not sure what you do with your A/D converters, but for me NOISE IS VERY BAD... 250mhz can sample 2GHZ yes... Best accuracy, best performance? No... You must understand that the clock is directly related to the bandwidth for performance... I could sit there and only sample at 1MHZ even such as the A/D on the arduino ( Which I think only has a few KHZ as the actual bandwidth ), but I'd miss a lot of sweeps, and my decimator stage wouldn't be accurate... I don't know how you would even get by in RF domains without needing to know that! This is a test and measurement piece of equipment?

But how many sample points do you think you'll have in X amount of time with each step before it's digitized? How accurate is that going to be to your standards? Good enough for you? But is it good enough for me? I prefer high bandwidth, high sample rate, even though I might only get a few moments with even that ( My needs are different than yours ) TLDR: At higher bandwidth, this A/D will do a larger sweep with MORE steps, at the cost of being inaccurate... That is why there is an SNR chart. Aliasing is not fun...

http://www.analog.com/en/data-conversion-knowledge-resource/conversions/index.html

Edit: Also I really like german music like NDH bands... I see you are from germany!

[tinhead]

...

when you wish to talk about accuracy, you need first to check ENOB by given input frequency and check if ENOB is changing when the clock goes from 500MHz to 1GHz. However this data didn't exist for ADC08D500, so all you can do is to take data from ADC08D1000 (which was the big brother of D500), e.g. figure 20 D1000 vs. figure 16 D500.We can only guess that the silicon is the same or at least similar, on the other side for these DSOs 500MHz input signal is the max. of interesst (and at 500MHz
input signal the SNR look best, but again, for 500MHz clock. A quick compare to D1000 shows that there is not even half dB more noise between 500MHz and 1GHz clocks).

The both figures (which of you talk about) are for this thread therefore pointless (on the other side they not showing anything relevant to ENOB vs Sample rate).Sure, when you wish to speak generally (or for your special needs) about overclocking of these ADCs, then of course it make sense to check first what is your input frequency range, then clock frequeency and then your needs (and double check if you can meet them).

Back to datasheet; the figure 20 from D1000 datasheet is missing in D500 datasheet, as well in D/DL502 datasheet. I've asked TI twice, no answer on that. I assume the silicon is the same as in D1000, so they don't want to answer. It might be of course that the responsible person from NS got fired after the merger.

Just a side note, D500/D502/DL502 datasheets contains so many errors (as a result of bad copy/paste habit) , that it really make sense to read the whole
datasheet twice and think a bit "what's wrong here". You can find non existing mux, non existing DES, wrong values in FPBW, THD, etc. I've notified TI about
them as well, let's hope they will fix datasheets befoe these ADC get NRND.

At higher bandwidth, this A/D will do a larger sweep with MORE steps, at the cost of being inaccurate... That is why there is an SNR chart.

and it's generally pointless for this thread or the question "are they overclocked?".

[MysteryBunny]

At higher bandwidth, this A/D will do a larger sweep with MORE steps, at the cost of being inaccurate... That is why there is an SNR chart.

and it's generally pointless for this thread or the question "are they overclocked?".

Not even remotely pointless... I recall I was confirming DES for a user named MARMAD @ 1GSPS @ default 500mhz... Not overclocked yet... As I stated overclocking creates noise issues though as we can see below after I answer your ENOB question... This is also a test instrument...

ENOB doesn't change when you overclock... You can't also judge this DAC/ADC by ENOB... You can GUESS what type of A/D it is though with ENOB only matters at decimation stage, so you will need the datasheet.... ENOB is just the digitizing "part" of the A/D... Almost all sampling ones are 8-bit... Typically 14-32 bit are "precision" ( they could be even 8-bit but the decimator stage just chooses the format )... When you are looking at pricing and bandwidth, the best way to characterize your DAC before you purchase is this. I just wrote this right now ( Which this was after looking at over 10,000 DACs on digikey for what I wanted, sometime last year. )

1.) Power envelope (2.) Sample Rate (3.) ENOB (4.) Full Power Bandwidth (5.) Channels (6.) A/D type - I prefer to use this term vs saying DAC/ADC (7.) SnR

*****************************
For #6 ( A/D type ) we need a table outlining them...
---------------------------------------------------------------------------------------------------------
----------------------------------------Strengths--------------------------------------------------Weaknesses
Flash (half-flash also) ADC         FASTEST available                                                  Crazy Power Draw and Size ( not efficient )
Successive Approximation ADC  Consistent speed                                                   Bigger size/more power because of searching and not step counting...
tracker - (counting) ADC            Fewer clocks with signals that don't change fast   Slow Conversion Speed ( rare/old/not used - note#2)   
Dual slope (Integrating) ADC    Integrator eliminates noise                                     Slow Conversion Speed       
sigma-delta ADC                        High-Accuracy/Resolution(note#1)                         Oversampling 4-10x requires fast clocks + DSP chip...
----------------------------------------Strengths---------------------------------------------------Weaknesses

note#1 - Faster clock on sigma-delta = higher resolution

Fastest to slowest ADCs) Flash > Successive Approximation > Sigma-Delta > Integrating
Best ENOB for each ADC) Sigma-delta > Dual-Slope > Successive Approximation > Flash

note#2 - Tracking not mentioned because of rarity...

*****************************

These are both priced at $36... And a good comparison to the one in this scope... Notice how the bandwidth is halfed, because the sweep is shorter ( 500mhz sweep vs 1GHZ sweep... This is more proof of why my earlier comment about DES being linked to completing a sweep for x type of bandwidth can much faster... )

AD9484 (1.) 670mW (2.) 500MSPS (3.) 8-bit (4.) 1GHz      (5.) 1 (6.) Flash (7.) 47
AD9286 (1.) 315mW (2.) 500MSPS (3.) 8-bit (4.) 500mhz  (5.) 2 (6.) Flash (7.) 49.3


ENOB is just the last stage of choosing which information is useful... ENOB could even be 64 bit, but would that be useful? Probably not.... A crappy ADC could have the same decimator but obviously it wouldn't get the same result... Look at the difference, same ENOB, different accuracy... Notice the pin package and power differences, obviously flash is inefficient...

"High speed, high resolution ADCs are sensitive to the quality of the clock input. " ... "Treat the clock input as an analog signal in cases where aperture
jitter may affect the dynamic range of the AD9484. Separate the power supplies for clock drivers from the ADC output driver
supplies to avoid modulating the clock signal with digital noise"

( Page 16: http://www.analog.com/static/imported-files/data_sheets/AD9484.pdf"

Frequency selection curve on page 3...

"Much of the energy is distributed close to the desired frequency, although much is also contained
in the wide bandwidth. Because phase noise can often extend to very high frequencies, and since the ADC
encode pin typically has a bandwidth much higher than the converter sample rate, this noise will impact the converter performance."

REV. 0 REV. 0–2– AN-756 –3– AN-756 ( http://www.analog.com/static/imported-files/application_notes/5847948184484445938457260443675626756108420567021238941550065879349464383423509029308534504114752208671024345AN_756_0.pdf )


*************************************

SnR: Attenuation is compensated for by subsequent amplification, but amplifiers add their own inherent internally generated
random noise to the signal. Noise levels must always be less than the required signal, otherwise the required signal will be lost in noise. Some means must be provided to specify the level of the signal above noise.

SNR = Signal power ( DB ) / Noise Power ( DB )

Example: In practice, we require an S/N of 10–20 dB to distinguish speech, an S/N of 30 dB to hear
speech clearly, and an S/N of 40 dB or better for good television pictures.

( High frequency and microwave engineering -> ISBN-13: 978-0750650465 )

*******************
I hate tekktronix overpriced stuff, but here's a snippet from their site...

"Effective number of bits (ENOB) is the true resolution of the A/D once imperfections are included, such as non-linearities, gain errors, distortion, and noise. Just as the image above is a high-resolution representation of a low-resolution source, the same is true of an oscilloscope that has a high-resolution digitizer but other sources of error. If there is noise on the signal, that extra resolution is just extra bits of noise, and the waveform like the text in the sign above will remain blurry."

http://www.tek.com/blog/not-so-high-high-resolution

[tinhead]

...

i know what's SNR or (clock) aperture jitter and how to eat them.
For the rest fo the equation see below.

ENOB doesn't change when you overclock... You can't also judge this DAC/ADC by ENOB...

really? I prefer to read the manufacturer data, e.g. from the ADC08D1520 (which is the same ADC family as the used in DSO)

ENOB vs. Temp



ENOB vs. VCC



ENOB vs. Input signal frequency, what we need to see the max. ENOB for gives DSO bandwidth



and finally ENOB vs. (sampling) clock frequency, which is what we need to see overclocking influence.

[MysteryBunny]

...

i know what's SNR or (clock) aperture jitter and how to eat them.
For the rest fo the equation see below.

ENOB doesn't change when you overclock... You can't also judge this DAC/ADC by ENOB...

really? I prefer to read the manufacturer data, e.g. from the ADC08D1520 (which is the same ADC family as the used in DSO)
.....

I can't be mean because this is too cute! This kind of sounds like a bad chinese romantic date gone wrong... HAHAHAHAH! Make sure you eat all your (clock)... I can tell you are copy pasting! Maybe you just like to talk to people. I have a low post count and I am new... But I refuse to avoid helping you!!! I sure am a nice guy. I like to help people!!!

I need a small kitten to hop across my screen now with a fluffy pen to point at the right thing so you can see!!!

Those charts are talking about DIGITIZING the signal... That's what happens at the decimator phase once again... This ENOB here is a RATIO between which bits are noise, and which bits are useful signal... It's theoretically fixed at 8-bits... You cannot go above 8-bits without buying a DIFFERENT ADC...

Those are NOT equations below, those are ENOB performance conversion diagrams/charts, you will notice they depend on another value so they plot much like a timing diagram. Imagine that the ratio is moving based on the bottom one... HERE this instead:

IMAGINE the 8 bits as an apple... You cut up the apple, but you still have the whole apple... It's just in pieces now and the core you don't eat, and the slices are the ones you eat... ORM NOM NOM num num... NO EAT JITTER... NO EAT!!!!!!!!! NO! ONLY EAT GOOD APPLE... Signal is good! YUMMY! O:

If you overclock it will just change the speed of the sweep... And the accuracy will go down as noise increases... The difference between the ENOB chart and the SNR chart... IS SNR the front of the converter...And this ENOB PERFORMANCE chart is the BACK of the converter, after it's been processed...

Page #2 has what is called a "block diagram" showing 8-bits... FIXED value... Both of the ADCs in each part... Both manuals also...

I can tell you cannot read, so this should help... You try hard to learn. Most people who can't speak english don't even try this hard... I deeply respect that effort... ALSO I found this for you... This is audio. THIS SHOWS delicious apple theory:

http://dkc1.digikey.com/ca/en/tod/Texas_Instruments/DataConverters/DataConverters.html

Have a nice night <3333

-Mysterybunny

[tinhead]

EDIT: i'm nice guy, so i will explain what is your (and not my) problem:

The general quastion was - are these ADCs overclocked and if they are is it bad?
Most of your answer however are generic and have nothing to do with the question, this spefic ADC or what so ever topic related

In the end the design was rushed with the cheap MAX II

pointless, any CPLD would do the job as well. I would not say "design was rushed", others with similar hardware combination
did they same (Instek/Rigol/Atten/Siglent/UN-T , and that since years, no rush here)

Look at the graph on FG 19. (Page 20) FG. 29 (Page 22)... You'll see that it's great at 500mhz,
pretty bad accuracy at 1GHZ (even 800mhz sucks), and horrible at 2GHZ... [/i]

pointless, the same DSO with real ADC08D1000 would have still the same bandwidth.

In fact it even says for DES mode 900mhz is "typical" @ PG. 9
They say a "typical" for non-DES is 1.7ghz @ PG. 8
2GHZ @ +/- 7 DB loss... @ page FG 29. Page 22 of the A/D manual
So You can easily push this to 1GHZ with +/- 3 DB loss... WHILE in DES mode I am guessing?

pointless and mix of things, you can't push anything was already given by the hardware, FPBW have nothing
to do with overclocking, etc.

This is also 8-bit sampler, it isn't a 14-16 bit precision one either... I can't imagine how terrible it would
be at 2GHZ. It's funny to imagine though...

you don't need to imagine anything here as it is pointless for give topic/questions.

SnR/attenuation changes with the clock frequency, which people were asking what happens when you overclock it...

so far ok, but then  ...

Obviously it overclocks to 1GHZ, it can even do 2GHZ ( with problems )...

as answer to my comment to what you "saw" on SNR/Input frequency figure and not from SNR/Sample clock
(which as shown in below didn't exists for you).

I was making a joke about 14-bit precision non-sampling A/D converters

a joke, the only joke i see is you, but hey, let's continue.

But how many sample points do you think you'll have in X amount of time with each step before it's digitized?
How accurate is that going to be to your standards? Good enough for you?
But is it good enough for me? I prefer high bandwidth, high sample rate

as comment/answer to given question complettly pointless

ENOB doesn't change when you overclock
...
The noise is going to be very high from overclocking

You can easy convert ENOB to SINAD and calculate the SNR/THD values. So think back, when SNR is chaning while overclocking
the SINAD and ENOB will change as well. This is pure math (no, you don't need english to get that).

Therefore is your ENOB statement above wrong, but you even not recognized it as you posted about SNR, do you?

If you know how the A/D steps through in a delta-sigma converter, you will know that noise creates poor samples, but that's really just a filtering/attenuation issue... I had to post that even in the manual it says a 3db loss which isn't a big deal but ...

the question was not about "a sigma-delta converter" but this specific flash converter, but anyway, what you said agin?
Ahh, i see

... I guess no one had noticed that and was still speculating about it

exact, this seems to be your problem, and examples below confirms it:

IMAGINE ORM NOM NOM num num... NO EAT JITTER... NO EAT!!!!!!!!! NO! ONLY EAT GOOD APPLE... Signal is good! YUMMY!
...
HAHAHAHAH!
...
I need a small kitten to hop across my screen now with a fluffy pen to point at the right thing so you can see!!!

so really, you need to got to doctor and/or try to learn how to express oneself.

Most people who can't speak english

honestly i don't have issues with english.
Sure, it is not the best english on earth, but sufficient to communicate about technical and non-technical content.

The fact you can't understand or answer simple question makes me realize that the only problem here is you,
jumping from topic to topic, posting wired jokes (haha), using (without any reason) bold/italic/caps, etc.
is the best confirmation.

Maybe you just like to talk to people. I have a low post count and I am new

the count (of posts) didn't makes anybody better and to be honest i always try to combine answers to single reply.
It is maybe not the best from the readability point of view, but what i really hate are tons of short replies from
same person (who ever feel concerned, î didn't meant you ^^)

[mike1305]

Why don't you two get a room? 

[MysteryBunny]

exact, this seems to be your problem, and examples below confirms it:

IMAGINE ORM NOM NOM num num... NO EAT JITTER... NO EAT!!!!!!!!! NO! ONLY EAT GOOD APPLE... Signal is good! YUMMY!
...
HAHAHAHAH!
...
I need a small kitten to hop across my screen now with a fluffy pen to point at the right thing so you can see!!!

so really, you need to got to doctor and/or try to learn how to express oneself.

honestly i don't have issues with english.

The fact you can't understand or answer simple question makes me realize that the only problem here is you,
jumping from topic to topic, posting wired jokes (haha), using (without any reason) bold/italic/caps, etc.
is the best confirmation.

I thought we were having a fun discussion, now you think my jokes are WIRED?! Well ALRIGHT I need to go the doctor to learn how to express oneself! Thank you for the advice <333 I shall go to the doctor right away and not talk about ADCs any more!!!

Also right above us a kitten named mike1305 just posted with his fluffy pen. THAT IS THE BEST CONFIRMATION.

EDIT: i'm nice guy, so i will explain what is your (and not my) problem:

1.) The general quastion was - are these ADCs overclocked and if they are is it bad?
Most of your answer however are generic and have nothing to do with the question, this spefic ADC or what so ever topic related

In the end the design was rushed with the cheap MAX II

2.) pointless, any CPLD would do the job as well. I would not say "design was rushed", others with similar hardware combination
did they same (Instek/Rigol/Atten/Siglent/UN-T , and that since years, no rush here)

Look at the graph on FG 19. (Page 20) FG. 29 (Page 22)... You'll see that it's great at 500mhz,
pretty bad accuracy at 1GHZ (even 800mhz sucks), and horrible at 2GHZ... [/i]

3.) pointless, the same DSO with real ADC08D1000 would have still the same bandwidth.

In fact it even says for DES mode 900mhz is "typical" @ PG. 9
They say a "typical" for non-DES is 1.7ghz @ PG. 8
2GHZ @ +/- 7 DB loss... @ page FG 29. Page 22 of the A/D manual
So You can easily push this to 1GHZ with +/- 3 DB loss... WHILE in DES mode I am guessing?

4.) pointless and mix of things, you can't push anything was already given by the hardware, FPBW have nothing
to do with overclocking, etc.

This is also 8-bit sampler, it isn't a 14-16 bit precision one either... I can't imagine how terrible it would
be at 2GHZ. It's funny to imagine though...

5.) you don't need to imagine anything here as it is pointless for give topic/questions.

SnR/attenuation changes with the clock frequency, which people were asking what happens when you overclock it...

so far ok, but then  ...

Obviously it overclocks to 1GHZ, it can even do 2GHZ ( with problems )...

7.) as answer to my comment to what you "saw" on SNR/Input frequency figure and not from SNR/Sample clock
(which as shown in below didn't exists for you).

I was making a joke about 14-bit precision non-sampling A/D converters

a joke, the only joke i see is you, but hey, let's continue.

But how many sample points do you think you'll have in X amount of time with each step before it's digitized?
How accurate is that going to be to your standards? Good enough for you?
But is it good enough for me? I prefer high bandwidth, high sample rate

8.) as comment/answer to given question complettly pointless

ENOB doesn't change when you overclock
...
The noise is going to be very high from overclocking

9.) You can easy convert ENOB to SINAD and calculate the SNR/THD values. So think back, when SNR is chaning while overclocking
the SINAD and ENOB will change as well. This is pure math (no, you don't need english to get that).

Therefore is your ENOB statement above wrong, but you even not recognized it as you posted about SNR, do you?

If you know how the A/D steps through in a delta-sigma converter, you will know that noise creates poor samples, but that's really just a filtering/attenuation issue... I had to post that even in the manual it says a 3db loss which isn't a big deal but ...

10.) the question was not about "a sigma-delta converter" but this specific flash converter, but anyway, what you said agin?
Ahh, i see

(1.) Most of my answers are about performance issues with overclocking... (2.) A CPLD is slow and small. You do not know the differences between them and FPGAs... A PLD has a speed grade. This is not debatable...  (3.) This is a different device, you have not read either datasheet

(4.) The bandwidth is "where" the sample is taken. SnR, sample speed, all tie into it... If the bandwidth is bigger, you need to sample more to capture it correctly... A/D converters will step through each part of the waveform to capture it... (5.) There is a difference between a delta-sigma converter and a flash one, please refer to my table I created for this thread

(7.) In an A/D converter, the frequency will affect the entire device... Increasing clock frequency will make the A/D converter sample at more points, and more noise will appear... I wonder why I am even telling you this...

I have linked you the basics of an A/D converter. I can tell you cannot design with them yet... You also don't understand basic RC circuits and waveforms... I can tell you would also struggle with PLLs, as I mentioned the DDR output and it confused you...

(8.) This is most important question in choosing an ADC...

(9.) I was referring to the size of the buffer, which is 8-bits... ENOB RATIO is a NOISE RATIO for digital systems... SIGNAL-TO-NOISE-RATIO is a NOISE RATIO for analog systems... An digital waveform is electrically still analog... They are both noise ratios... So we call it a NOISE RATIO... ENOB in it's short term means PERFECT ENOB which is 7.5 or 8-bits. Perfect ENOB doesn't change... the SnR changes... Both are NOISE RATIOS, so we can settle them as DIFFERENCES BETWEEN THE NOISE AND THE SIGNAL... Please study basic RF design guidelines...

(10.) If you look at the chart, which I created myself, detailing A/D types.... You will see the delta-sigma is the HIGHEST PRECISION one. It has the most complicated decimator stage... In english we call this an "example"...  I created this table so others can follow. FLASH is the opposite. When you see two different examples in english which are opposite, you call them contrasting examples...

I am done educating you for today... I think I have settled every question you could possibly ask ( english questions too ) <333

Also do you like german music?!?!? I own a lot of german music... I see you are german... I like this particular song:

[Hydrawerk]

Well, how do they produce the demo signals in GDS-2000A?

[amyk]

I think the g13 #119 is? a LM119 High Speed Dual Comparator. But thats only a guess.

giving the fact that on the other side of the cable MC10H125 has been used (with diff ECL signals) and no channel offset circuit available
in LA module (but in the POD) i would say they are ECL comparators like ADCMP580 (which have G12 branding btw.), however dual channel version.

At first I thought it was the CLC2500 but given that everything else on the board is AD (there's an AD5339 DAC next to the opamp), maybe not... either way, not cheap parts at all.

Someone in China is selling an ADCMP583 which is only mentioned otherwise here: http://www.alfa-chip.com/files/presentation/Amps.pdf

[tinhead]

it is ADCMP563, datasheet menas G01 but there exists a list on chinese AD site with G13 marking:

http://ezchina.analog.com/servlet/JiveServlet/download/1659-1205/ADI.pdf

EDIT: seems to not work due chinese characters? anyway, EDN is having as well G13 listed

http://static.ednchina.com/Analog/2009/11/4/ee5ef4a9-e1ad-48fa-aec9-6334aedec844.pdf

[tinhead]

I've emailed the InstekUSA folks to see if they can get an answer.  If/when I get a reply I'll post it.

grego,

did you got anything back?

[marmad]

grego,

did you got anything back?

I'm not sure that we can expect them to say much more than what they've already told Dave. I doubt they're going to say directly that they overclock ADCs or that they use the processor to handle part of the display updating (or, conversely,  that the single FPGA can be slightly overloaded handling both acquisition and updating)

[grego]

grego,

did you got anything back?

I'm not sure that we can expect them to say much more than what they've already told Dave. I doubt they're going to say directly that they overclock ADCs or that they use the processor to handle part of the display updating (or, conversely,  that the single FPGA can be slightly overloaded handling both acquisition and updating)

This.

I am going to ask for clarification on short/auto memory though.

[marmad]

I am going to ask for clarification on short/auto memory though.

I suppose... although given that:
a) mike1305 already posted that the Short setting plus 500 ns/div time base gives a sample rate of 200 MSa/s.
b) Segments use 1k record lengths.
c) Short makes much more sense referring to 1k than to 1M.
...I think it's safe to assume it's just a 'misprint' in the manual, and that short = 1k / auto = 1M (or shorter, depending on other channels used, etc).

But you could see very easily yourself by just selecting Short and cycling through the time bases while watching the sample rate indicator. A 1k record length would produce the following rates:
1 - 50ns = 2GSa/s
100ns = 1GSa/s
200ns = 500MSa/s
500ns = 200MSa/s
1us = 100MSa/s
... and so on.

Actually, the Short record length = 1k samples;  it's confirmed in Dave's original video (#474) between 53:20 - 53:40.

And we had assumed that the Instek was doing 80k wfrm/s (and all of it's other fast rates) with a 1M record length. Instead, it appears that it's high speeds are with 1k, which means it's achieving the fastest rate (and some of the other fast rates) with reduced sample rates, thereby lowering it's effective bandwidth at those settings. I'd be curious to see NEW waveform update measurements made with an AUTO record length.

So yes, the GDS-2000A series is a 80k wfrm/s DSO when sampling at 200MSa/s. At the full 2GSa/s, it's not appreciably any faster than the Rigol or Agilent when using it's small 1k record length - and possibly much slower when using equivalent memory sizes.

I don't know... IMO, this verges perilously close to false advertising - especially given the 'misprint' in the manual.

[Hydrawerk]

Well, this GDS-2000A somehow resembles GDS-806C... This 2004's scope was not cheap, had crap 100MSa/s ADC, was not easy to use, had quite unergonomic front panel and I didn't like it at all.
https://plus.google.com/photos/106264218831814439783/albums/5852286961657081569
Much more I like the even older HP 54600 series, but OK, it has even worse 20MSa/s ADCs...

[marmad]

Well, this GDS-2000A somehow resembles GDS-806C...

I don't really see the comparison.

[Azhar]

Thanks Dave! I enjoyed the tear down as always! thanks for the awesome EEVBlog! 

[mamalala]

Maybe i am missing something, but for the life of me, i can't understand the fuzz about the grading/fading stuff for the display. I mean, what does real phosphor do on an analogue scope? The beam hits a spot, which in turn lights up. It the gradually fades out, unless the beam retraces that exact same spot again. Doing that digitally just means to set a pixel to a given value, and then decrease that value on each new capture, unless the captured value would "hit" that pixel again, in which case it gets set to the start value again.

I mean, just look at old computer demos, the "blob" effect basically does just that (yes, i know, not directly comparable, but the outcome is the same). Assuming a 640x480 display (just as an example), we have 640x480x3 = 921.600 bytes, x50 fp/s = 46.080.000 bytes per sec, so a 50MHz clock would be enough if the FPGA would "brute force" the grading for each display pixel in a linear fashion and only does 1 byte at once. Using 3 bytes at once improves that, limiting the color-space improves it even more. After all, it would just need a pixel=old_pixel-1 to do the fading, or in case of a "retrace" it would be a simple old_pixel=max_value.

The FPGA can readily prepare 8, 9 or 10 bits per pixel, as far as intensity is concerned. That would result (assuming a 50Hz display rate) in roundabout 15k, 30k or 60k waveforms per second. All it has to do is to sample the waveform 256, 512 or 1024 times and increase the values for the pixels that are "lit". That way the main controller already gets a shaded bitmap of the waveform. This is the used to be combined with whatever the main controller already has in its image memory with a way mentioned above. Heck, i can think of several ways to implement that stuff rather efficiently, especially if you have direct control of the address lines and stuff from the memory...

What am i missing?

Greetings,

Chris

Edit: Sorry, i meant the "shade-bob" effect.

[amyk]

What am i missing?

The fact that scope firmware programmers aren't from the demoscene?

[marmad]

What am i missing?

A lot of other stuff that happens. Forget for the moment the amount of data which just has be to shifted - from the ADC to sample memory (which stores a copy of the last waveform captured) and from sample memory to display memory - but apart from the intensity grading, there is decimation, other acquire modes (peak detect, high-res, etc), possible anti-aliasing, measurements, etc.

I'm not saying it's the most complicated thing in the world - but with current technology, it appears to require more than a single FPGA (or else special silicon like Agilent's ASIC) - in order to do it seamlessly.

[mamalala]

What am i missing?

The fact that scope firmware programmers aren't from the demoscene?

Uh, i know that already. My point was that fading/phosphor emulation shouldn't be that hard to implement since similar effects have been implemented decades ago on rather slow machines. Considering that FPGA's are quite fast and can do stuff in parallel rather nicely, it should be a rather simple thing to implement nowdays.

Greetings,

Chris

[mamalala]

What am i missing?

A lot of other stuff that happens. Forget for the moment the amount of data which just has be to shifted - from the ADC to sample memory (which stores a copy of the last waveform captured) and from sample memory to display memory - but apart from the intensity grading, there is decimation, other acquire modes (peak detect, high-res, etc), possible anti-aliasing, measurements, etc.

Sure, but wouldn't all that be done before the "displayable" waveform? My thinking is that the signal would be processed and then stored in memory. Without any grading, that would be the end of it and out to the display it goes. With grading, those results would "simply" be added to the existing data (either with or without first doing a "fade out" on the existing pixel), and after N repeats of all that goes to the display.

But then, what do i know At least something like that would be the way i would first try to implement it.

Greetings,

Chris

[marmad]

Sure, but wouldn't all that be done before the "displayable" waveform?

Hi Chris,

Some of it happens before - but some of it is often combined with the grading (like decimation for the display).

Here's a nice link showing some different methods DSOs manufacturers have come up with for implementing it. It's educational 

Best,

Mark

[marshallh]

What am i missing?

The fact that scope firmware programmers aren't from the demoscene?

Truth. If they gave a damn and were halfway competent they could do it proper.
Shadebobs on a pentium I...

[ResR]

Not a big news but from the video at 08:52? the lower two pins are shorted to the pins at the other side with "stiching", mate, that is how it is detected of being connected.

[andersm]

The Chinese sure love their DSPs, but I wonder who will be the first to try using a tablet CPU and crunch the graphics using OpenGL and shaders.