Opinions on GW Instek Scopes?

[MrAl]

Hello,

Any opinions on GW Instek scopes as to how good or bad they are?
Hardware decent, software decent, etc. ?

I am still looking around and came across this brand and noticed they are like 100 dollars (USD) cheaper than Rigol.
I dont want to spend too much on a new scope because it will only be needed occasionally.  Maybe a few times a month.

Also as a side note, is the Tequipment discount still valid and around 6 percent?

Thanks a bunch, and if i do get one or another brand i would be happy to do a decent review on it right here in this forum to help other possible buyers decide.

[iainwhite]

There is a thread HERE that may be helpful.

[MrAl]

Hi,

Oh yes thanks, that looks like a good thread too with lots of information.

[Fungus]

I am still looking around and came across this brand and noticed they are like 100 dollars (USD) cheaper than Rigol.
I dont want to spend too much on a new scope because it will only be needed occasionally.  Maybe a few times a month.

Price-wise they're competitive with Rigol, yes.

But... Rigols are easily hackable to unlock a load of extra features. GW-Instek are not.

In reality this means Rigols have double the bandwidth of the equivalent-price GW-Instek, lots more memory, serial decoders, fancy triggers, etc.

[MrW0lf]

Looking at saturation's test here seems that 1054B has 100MHz-like-bw even without hacking:
https://www.eevblog.com/forum/testgear/a-review-of-the-gwinstek-1054b/msg1114831/#msg1114831
"The 3B point of the 1054B is about 120 MHz versus my prior conservative test."

Memory is 10Mpts per channel so 40Mpts in total, Rigol only 24Mpts (6Mpts all ch on). Some spec total mem (Rigol), some per channel (Tek, GWI), a bit of mess...

Not sure about sampling rate, does it drop to 250MSa/s with 4ch on like Rigol?

So overall if 4ch are really needed and work is more in analog domain then GW seems very good for money.

Edit: Looking at the spec here:
http://www.gwinstek.com/en-global/root/Oscilloscopes/Digital_Storage_Oscilloscopes/GDS-1000B
Offset Position Range
1mV/div : ±1.25V
2mV/div ~ 100mV/div : ±2.5V
200mV/div ~ 10V/div : ±125V
Seems they really made effort with analog frontend...

[JPortici]

Which scope are you looking at?

1) Wolfie rightly said that bandwidth is much higher than advertised... not sure about risetime though (i tend to find that to be more important)
But do you really NEED 100 MHz bandwidth?
2) Fungus rightly said that you can't hack the GDS but you don't need to! the "options" on these scopes are called Apps and they are freely available on their site.. but read number 3.
3) While having a nicer FFT, better math and i think hardware pass/fail (someone correct me if needed) and even thought it's an overall more modern and faster scope in terms of responsiveness, the GDS-1054B series DOES NOT HAVE serial decode and triggering. the GDS 2104E series has it, but it's in a different category (i'd call it upper low range)

do you NEED serial decoding? (though i find them to be a joke on the rigol, i spend more time setting them up than looking at the actual signal, i often decode by hand or use different tools when available)
if not i'd vouch for the GWI

[Fungus]

Looking at saturation's test here seems that 1054B has 100MHz-like-bw even without hacking:
https://www.eevblog.com/forum/testgear/a-review-of-the-gwinstek-1054b/msg1114831/#msg1114831
"The 3B point of the 1054B is about 120 MHz versus my prior conservative test."

So? An unhacked Rigol DS1054Z has a measured 3dB bandwidth of 278MHz:

https://www.eevblog.com/forum/testgear/rigol-ds1054z-bandwidth/msg1095201/#msg1095201

This other guy measured 250MHz bandwidth on his unhacked DS1054Z:

https://hackaday.com/2016/10/05/choosing-a-scope-examining-bandwidth/

Why aren't these 'scopes being sold as 100MHz (GW-Instek) and 200MHz (Rigol) oscilloscopes? 

do you NEED serial decoding? (though i find them to be a joke on the rigol

That's just your opinion. Other people (eg. me) find them very useful, especially for Arduino work.

No, you can't decode massive I2C data dumps with a Rigol (although you can see very long RS232 strings).

Yes, you can use one to see if the serial comms is working or not. If it's working you can use printf() for the big data dumps. If it's not working you'll be able to see why. That's useful. 

[MrW0lf]

So? An unhacked Rigol DS1054Z has a measured 3dB bandwidth of 216MHz:

Actually it is just what it draws with (non-standard) Sin(x)/x function (unhacked or not). This gives impression of high bandwidth, but messes up amplitudes. Perhaps saturation could do little checking Sin(x)/x ON vs OFF on 1054B? If ON/OFF gives same signal amplitude then bandwidth is real, otherwise it is artificially boosted. I checked this also on scope with standard Sinc implementation (Pico) and amplitude diff was ~zero just like it should be.

Hacked Rigol test I once did is here. Short summary (dotted line is actual input amplitude on scope BNC measured with 950MHz demodulator probe):

[ebastler]

No, you can't decode massive I2C data dumps with a Rigol (although you can see very long RS232 strings).

Yes, you can use one to see if the serial comms is working or not. If it's working you can use printf() for the big data dumps. If it's not working you'll be able to see why. That's useful. 

I still like my two-year-old DS1054Z; don't regret buying it and have no intention to replace it anytime soon. That being said, the serial decoding functionality is unnecessarily limited in my view. In my experience:

As decoding is only based on the on-screen data, the individual bits have to be resolved on screen. Hence you typically have to zoom in to a faster timebase (and hence shorter segment visible on the screen) than you really want. Also, if the trace on the screen begins with a fragment of one byte or frame, that will typically derail the decoder, often for multiple bytes to follow. Annoying, as the bytes before the screen window are typically available in the full memory.

You mention that you can decode and see very long RS-232 strings. How do you go about that? Maybe I can learn a trick I have overlooked? Or maybe the firmware has been improved at some point and I didn't notice?

(I don't even want to start fantasizing about a decoder which would auto-detect the right polarity, baud rate, maybe even clock & signal assignment on the channels. An "auto set" button for decoding seems quite feasible; but I am not sure whether it is common in higher-end scopes?)

[JPortici]

and i don't like mine, it will be replaced as soon as possible (probably with the new keysight, if it doesn't come out to be a disaster like the new tek tbs)
*also i need canbus on the home bench, another reason to toss out the rigol but let's not digress

infact i said I find them to be a joke. i know plenty of people that are happy with the rigol. having spent more time with better tools i am not one of them but YMMV

Auto set is implemented just fine in a picoscope, an example without having to go crazy high with the price. auto baud detection doesn't work 100% of the time though, especially with CAN, and you still have to select the polarity but 99% of the time you select the trace and click ok, just fine

My problem with the rigol decoder is that as with almost everything else in the scope it tries to decode with screen data, which is decimated. have a full 24M trace? you're out of luck. you have to zoom in enough that the effective sample rate permits the decode to work or you have wrong/missing results so to find an event you have to zoom in and scan the whole trace manually. with a picoscope, a gds-2000e and other, better tools decoding is done on the whole sample memory, regardless of the zoom.

the rigol behaviour slows me down to a painful point, but for other people is fine

[MrAl]

Hello again,

I dont need serial decode or RS232 decode but i probably have to be able to see a 10ns pulse for example.  There may be times when it is repetitive (reoccurring at a certain rate), but i would like it to be able to catch a single pulse as well.

So it sounds like there are some memory spanning/useage issues with some scopes.  I had a feeling that might be the case as a friend has a PC scope that does not allow moving the screen view left or right even though it has the typical scroll indicator at the top of the screen.  I think they should all be able to do operations on the entire memory.  It could be that during testing they found out it would be too slow so instead of telling people that they just limit the useage to a shorter section of memory.  Just a guess though.

[Fungus]

My problem with the rigol decoder is that as with almost everything else in the scope it tries to decode with screen data, which is decimated. have a full 24M trace? you're out of luck. you have to zoom in enough that the effective sample rate permits the decode to work or you have wrong/missing results so to find an event you have to zoom in and scan the whole trace manually. with a picoscope, a gds-2000e and other, better tools decoding is done on the whole sample memory, regardless of the zoom.

Of course USB devices have an advantage here. That's the point I was making earlier: Mouse, keyboard and a "find" dialog are the way to deal with software problems in long serial transmissions, not an oscilloscope. The oscilloscope is there to see if the electrical signals look OK, if the baud rate is correct, etc.

Plus: If I'm going to have a PC on the workbench I might as well get one of those $10 logic analyzers or a Bus Pirate and do it with that. No need to spend a fortune on a fancy oscilloscope to do it.

[Fungus]

I dont need serial decode or RS232 decode but i probably have to be able to see a 10ns pulse for example.

...the sort of info that should have been in the initial post. 

I don't have the manuals with me but I'm sure somebody will oblige with the minimum pulse width on both (which will be very similar).

I'd say the 100MHz bandwidth of the Rigol will be an advantage for looking at those sort of signals though.

[MrW0lf]

i probably have to be able to see a 10ns pulse for example.

Looking "peak detect" spec DS1000Z is 4ns min, 1054B is 2ns min.

[ovnr]

I've got a somewhat old GDS-2104 scope, which is pretty darn terrible. Would not buy a GW Instek again, mostly because they don't seem to give a shit about supporting their products. The scope has a number of software bugs, and IIRC they never released any new firmware for it. At all.

But tbh I wouldn't buy a Rigol either; I have better things to do than deal with the idiotic bugs in cheap scopes.

[nctnico]

I've got a somewhat old GDS-2104 scope, which is pretty darn terrible. Would not buy a GW Instek again, mostly because they don't seem to give a shit about supporting their products. The scope has a number of software bugs, and IIRC they never released any new firmware for it. At all.

It seems they released a new firmware version for your scope last year:
http://www.gwinstek.com/en-global/products/Discontinued_Products/Discontinued_Oscilloscope/GDS-2000
Is that the version you are using?

[ovnr]

It seems they released a new firmware version for your scope last year:
http://www.gwinstek.com/en-global/products/Discontinued_Products/Discontinued_Oscilloscope/GDS-2000
Is that the version you are using?

Hah, I've gone around and been annoyed about it for 5+ years. And now they get it out. Thanks, nctnico - I'd given up on even checking.

(Wouldn't have killed them to have a changelog tho...)

[ebastler]

My problem with the rigol decoder is that as with almost everything else in the scope it tries to decode with screen data, which is decimated. have a full 24M trace? you're out of luck. you have to zoom in enough that the effective sample rate permits the decode to work or you have wrong/missing results so to find an event you have to zoom in and scan the whole trace manually. with a picoscope, a gds-2000e and other, better tools decoding is done on the whole sample memory, regardless of the zoom.

Of course USB devices have an advantage here. That's the point I was making earlier: Mouse, keyboard and a "find" dialog are the way to deal with software problems in long serial transmissions, not an oscilloscope.

Hmm, but I don't think that's the point JPortici (and I, in the post before) was making. This is not about the user interface, i.e. knobs and buttons vs. mouse and keyboard. This is about the unfortunate limitation that only data in the screen buffer are used for decoding, missing out on the deeper time resolution available in full memory, and on the information about frames outside the display area.

That's not a conceptual limitation of the oscilloscope user interface, but a design decision that was made to cut corners. And the design decision has annoying implications. Still, it's much better than having no decoding at all, and I have used both serial and SPI decoding on the DS1054Z, with only minor grinding of teeth. 

[Fungus]

That's not a conceptual limitation of the oscilloscope user interface, but a design decision that was made to cut corners. And the design decision has annoying implications.

Sure, but it only really has bad effects on long I2C packets.

Still, it's much better than having no decoding at all, and I have used both serial and SPI decoding on the DS1054Z, with only minor grinding of teeth. 

For SPI&serial you can zoom in on the 24mB of memory and scroll the display left/right. The data on screen will sort itself out every eight bits. You can usually see where the start of each byte is on screen just by looking at it. No it's not ideal, yes is IS useful in spite of that.

[Gabri74]

I've got a somewhat old GDS-2104 scope, which is pretty darn terrible. Would not buy a GW Instek again, mostly because they don't seem to give a shit about supporting their products. The scope has a number of software bugs, and IIRC they never released any new firmware for it. At all.

But tbh I wouldn't buy a Rigol either; I have better things to do than deal with the idiotic bugs in cheap scopes.

This... I've got a GDS-2204 and can confirm the software was full of bug and the never released (unitl now! Thanks nctnico for the update!) any update.
I've also checked they new scopes at Electronica 2016 in Munich and I must say that the UI is a mess. They use a really counterintuitive color coded button system (at least for me) to navigate all the options... took me several minutes to found the serial decoder.

[MrAl]

i probably have to be able to see a 10ns pulse for example.

Looking "peak detect" spec DS1000Z is 4ns min, 1054B is 2ns min.

Hi,

Well i didnt realize that i should post every possible use i could come up with that i might need when i posted my first post, it was sort of a fishing trip where i would hopefully get to see what others where thinking about this brand.  After i read some replies it dawned on me that there were certain things that i would like to be able to do with the scope and certain things that other people were doing that i would probably not have to do.
Back when i did do RS232 for example i used asm for the coding so the timing just had to be right with very little doubt, and in Microchip's MPLab i was able to test the timing right down to the microsecond with their simulator, so i never actually had to look at the output.  I guess something could go wrong, but it always worked so i never needed to see the RS232 stream.
For some MOSFETs though i would like to be able to verify the drive signal is what i want it to be and also the drain timing, and for that i have to be able to see nanosecond resolution, at least ideally.  Granted 2ns resolution might work too, but i would not want it too much worse than that.  I am hoping a 100MHz DSO can do that and am hoping the GW Instek can handle it.

BTW, thanks for the reply.  Any info can be helpful here as i am so new to these kinds of scopes.

[nctnico]

Time resolution only depends on the minimum time/div setting so check that in the datasheet. If you want to look at a 1 nanosecond difference that will be easier on a scope with 1ns/div then one with 10ns/div as a minimum. You have to be aware though that using cables with a different length or slightly misaligned probes can result in a different delay between the signals in the circuit and when they arrive in the oscilloscope. The picture below shows this effect:

On the GW Instek GDS2000E series you can compensate this delay for easier reading but I don't know if that is also possible on the GDS1000B series. Either way you need to check the delay difference between two probes or cables before measuring nanosecond (or less) time differences using the scope's calibrator output.

[MrAl]

Time resolution only depends on the minimum time/div setting so check that in the datasheet. If you want to look at a 1 nanosecond difference that will be easier on a scope with 1ns/div then one with 10ns/div as a minimum. You have to be aware though that using cables with a different length or slightly misaligned probes can result in a different delay between the signals in the circuit and when they arrive in the oscilloscope. The picture below shows this effect:

On the GW Instek GDS2000E series you can compensate this delay for easier reading but I don't know if that is also possible on the GDS1000B series. Either way you need to check the delay difference between two probes or cables before measuring nanosecond (or less) time differences using the scope's calibrator output.

Hi,

Thanks for the info i'll make sure to check that.
BTW how is that scope shot you posted making such a nice wave at 100MHz when the sampling is 1GSPS?
I guess they do an interpolation between points, or is that using that 25GSPS recursive function?
Still trying to become familiar with these new scopes.

[videobruce]

I didn't see anyone mention "service" (or lack of). I can only speak about Spectrum Analyzers, but I would steer clear of Instek.

First off, unless something has changed radically, recently, nothing is serviced here.
Second, YOU have to pay for shipping to China both ways by CHECK, credit cards not accepted. (again, unless something has changed)
Third, At least as far as their SA's, they are years behind the competition, performance wise. (probably why you almost never see any)

The above was from 1st hand experience. 

[nctnico]

Time resolution only depends on the minimum time/div setting so check that in the datasheet. If you want to look at a 1 nanosecond difference that will be easier on a scope with 1ns/div then one with 10ns/div as a minimum. You have to be aware though that using cables with a different length or slightly misaligned probes can result in a different delay between the signals in the circuit and when they arrive in the oscilloscope. The picture below shows this effect:

On the GW Instek GDS2000E series you can compensate this delay for easier reading but I don't know if that is also possible on the GDS1000B series. Either way you need to check the delay difference between two probes or cables before measuring nanosecond (or less) time differences using the scope's calibrator output.

Thanks for the info i'll make sure to check that.
BTW how is that scope shot you posted making such a nice wave at 100MHz when the sampling is 1GSPS?
I guess they do an interpolation between points, or is that using that 25GSPS recursive function?

This is sin(x)/x interpolation between the samples which is commonly used on any DSO to reconstruct the signal so we humans can recognise it as such.

@videobruce: from my own experience and judging from other threads GW Instek's support (and bug fixes for oscilloscopes) is quite active to solve issues. OTOH I have not needed to send something in for repair yet so I have no idea how that goes. I agree though with your remark about GW Instek spectrum analysers. They are not interesting at all when you compare price versus performance.