Gw Instek GDS2204E (200MHz 4 channel DSO) review

[JPortici]

after just one year? a scope ain't no smartphone

(they did release the mso version a couple of months ago though)

[dfnr2]

The most recent version is 1.27 (30 Jan 2017). You have to create a login in order to see the download on GW Instek's website. I know:  and 

Yep.  I downloaded 1.28 (25 apr 2017), and indeed, the baud rate menu is easier to use, allows more different "standard" settings, and once selected, allows fine tuning of the baud rate.  Much, much better.

As a second scope for portable use, this is a really nifty one, and for a new scope, pretty good bang for the buck.

BTW, it looks like they do have a newer offering.  It doesn't seem to be a new iteration, but rather it offers the MSO and signal generator options. 

[nctnico]

Hmmm they released a new version. With 2.7 they already made a lot of input easier if you press the select button again. Today I needed a 1 second trigger hold-off and that was much easier to do with the list of presets than spinning the variable knob ad nauseam.

[thanasisk]

Considering to buy the 70mhz version for audio preamp/opamp etc work.

However the manual lists the fft horiz scaling as 10khz/div minimum, which would mean that audio freq response would be squashed within 2 horizontal divisions! Making fft unusable for audio frequencies..

Is this true or am I interpreting this wrong?

[nctnico]

Considering to buy the 70mhz version for audio preamp/opamp etc work.

However the manual lists the fft horiz scaling as 10khz/div minimum, which would mean that audio freq response would be squashed within 2 horizontal divisions! Making fft unusable for audio frequencies..

Is this true or am I interpreting this wrong?

I just tried and it is wrong. The minimum frequency depends on the samplerate so you can go down to less than 1Hz/div on long time/div settings.

[CC555]

Hello,

I bought this oscilloscope (GDS-2204e 1050€ on tme.eu) to try to solve some rs232 issues, I like it but I don't know if rs232 decoder is working properly (firmware version 1.32).

I connect the GDS-2204e and a DS1054Z to the same signals and I get different decoder results.

I am triggering the oscilloscopes at yellow signal's rising edge and capturing an uart communication (57600 8N1).




When I look at the same communication packets on the oscilloscopes I see different decoder results:

Rigol




GW




If I look at the first byte, I think rigol is decoding the signal right, at 57600 this is 02 (if I am not wrong  ):





Am I doing anything wrong with the GD-2204e or is it a bug?

If the GW doesn't decode the RS232 properly I will return it. Any good and cheap.. oscilloscope recommendation to work with serial buses (I2C, SPI, RS232 and full memory decoding)?.

Thank you and excuse my english.

[tautech]

You need to set a falling edge trigger on the GW.

[CC555]

Hello tautech,

thanks for your reply, setting a falling edge (channel 1) on both oscillocopes I get the same result.

[2N3055]

Try setting polarity normal (high = 0)..

[wraper]

As I remember someone wrote that he got wrong decoding on instek and fine on Rigol or maybe some other scope. Turned out that actual baud rate was off but Rigol was more tolerant to that. And after firmware update instek became more tolerant to inaccurate baud rate.

[tautech]

Hello tautech,

thanks for your reply, setting a falling edge (channel 1) on both oscillocopes I get the same result.

You need to take a step back, reset to defaults and set up again with thought and not fast button bashing.
Use only the channels needed and keep the channels and Trigger position on the display.
As 2N3055 mentions the idle setting for the data stream must also be set correctly.
Take screenshots in a way to show us as much info as possible for members to best help you.

[CC555]

Yes, polarity may be wrong specifying the start bit  , thanks for your help, I am going to try.

[nctnico]

As I remember someone wrote that he got wrong decoding on instek and fine on Rigol or maybe some other scope. Turned out that actual baud rate was off but Rigol was more tolerant to that. And after firmware update instek became more tolerant to inaccurate baud rate.

First make sure to have the latest firmware. Secondly the decoding thresholds must also be adjusted to match the signal (for each channel). Triggering doesn't matter at all.

[CC555]

Latest firmware V1.32.

I have to trigger with channel 1 because I want to look the communication at that event.

Default polarity on both scopes (start bit at falling edge, 0 = high) triggering with yellow signal.




Rigol decodes right (0xFD should be)


GW


At 57600 bps (57600 8N1): 1 bit = 17.36 us, so 0xFE is wrong, the 0 (logic 1) begins at 34.2 us.


The baudrate is ok, 17.36 us * 9 (start bit + 8 data bits) = 156.24 us


the start bit is at the rising edge instead the falling edge.

1V threshold levels, what am I doing wrong?

Thanks

[nctnico]

First of all set the polarity back to 'inverted (h=1)'.

[CC555]

Yes, that was my initial setting. The result is the same.

[2N3055]

I agree with nctnico, set polarity back..
Values in the first photos with original polarity on GW instek are shifted to left ....

hex 1 -> hex 2
hex 2 -> hex 4
hex 19 -> hex 32

you must check if both are exactly 1 start bit, 8 data , no parity and 1 stop bit... 10 bits total.
It seems GW Instek is stuffing additional bit in the beginning  (LSB)

[CC555]

Settings are ok: 57600 8 N, I have not found the stop bit option, there is an end of packet option (00 NULL by default).

[nctnico]

I did some testing and I've found the problem. At 2Ms/s your samplerate is too low. I was able to reproduce the problem but it went away at samplerates of 10Ms/s or more.

[2N3055]

Good info Nctnico.. 

[CC555]

Thanks for your help, I am going to try with a bigger sample rate, I thought 2Ms/s was enough for 57600 bps, Rigol is sampling at 1Ms/s

[CC555]

nctnico is right, It was a sampling problem:




10M per channel but you can only capture 1 second of the signal for a 57600 bps rs232, a DS1054Z can capture several seconds.

GW instek advertises it in its datasheet like "Serial bus design and debugging" and I may be a bit disappointed with this point after this test

I like the oscilloscope (what I have seen in two days) but I don't know what to do, if keep it or to look for another one.

Thanks for your help, my doubts with this issue have been solved.

[nctnico]

I'm a bit surprised too. From my initial testing it seemed the GDS2000E series need 13 times oversampling for UART decoding. Needing 10Ms/s for 57600 is more like 173 times. Maybe some optimisation in the decoding in later firmware versions doesn't quite pan out. I've contacted GW Instek technical support about this issue.

[rhb]

Gad!

The Rigol has a crap FFT, but decodes UART well.  The Instek is just the opposite.  Whatever is a person to do?

The really maddening part is given source code, I know how to fix this sort of thing.  But despite the GPL, OEMs are not complying. So one does not have  even the parts they did not write.

[digsys]

The Rigol has a crap FFT, but decodes UART well.  The Instek is just the opposite.  Whatever is a person to do? 

I'd chose FFT ability over RS232+ decode any day of the week. There are plenty of far more powerful stand-alone data decoders out there,
for very cheap prices. Nothing to stop you connecting both the DSO and a data decoder together, if you need to look for signal faults as well.