New GW Instek GDS-2000E oscilloscope released

[ali80]

I have bought this oscilloscope recently, GDS-2074E to be exact,
As a digital storage oscilloscope, its functionality is not that bad and the software has improved a lot over GDS-2000A series but there are still a few bugs and I think this model is actually slower than the previous model (GDS-2000A) at least in some of the settings, for example if you turn all channels on and set the memory depth to 10MPts the display update rates gets below 1Hz! I have also worked with GDS-2000A series and that's not the case at all.
As the logic analyzer functionality goes this model is pretty much useless, nothing works right, believe me I have tested UART, CAN and SPI and its just awful, full of bugs and not at a working condition. I mean the options are good but I wish they worked!
I have the latest version of firmware at the moment (Version 1.2) and I hope they fix their bugs cause I have payed a lot more to get the analyzer functionality and its just useless at the moment.
If you don't want the logic analyzer functionality go with GDS-2000B series, they have almost the same functionality and a lot cheaper.
If you want logic analyzer functionality go buy something else...

p.s. I updated the device firmware twice as suggested by nctnico, the blanks screen which was driving me nuts seems to be fixed, also the CAN decoding problem was duo to 5% baud rate error and my fault,it actually decodes and triggers very well. The SPI mandatory CS pin which is annoying is also reasonable because how can the SPI detect the beginning of the packet.(although they could simply add a timeout, not too fancy, even a user settable timeout on SPI would have been better than having a mandatory CS pin)

[nctnico]

Sure you got the thresholds and samplerate right? I recently played with a GDS-2204E (200MHz model) for a couple of hours and the CAN (500kbit/s) and I2C protocol decoding / triggering works fine with firmware version 1.2. Decoding 10Mpts is going to be slow because it is all done in software but at least it decodes the entire memory so you can zoom in on partial messages to look at each bit. There is only so much processing power you can get for this price.

[ali80]

Sure you got the thresholds and samplerate right? I recently played with a GDS-2204E (200MHz model) for a couple of hours and the CAN (500kbit/s) and I2C protocol decoding / triggering works fine with firmware version 1.2. Decoding 10Mpts is going to be slow because it is all done in software but at least it decodes the entire memory so you can zoom in on partial messages to look at each bit. There is only so much processing power you can get for this price.

Yeah, I'm pretty sure I got the settings right.
I tried SPI and it didnt work without CS pin, even a stupid 8-bit microcontroller can decode SPI wihtout CS pin, all you need is data and clock, in many of my designs I dont use CS pin and even if  I did, I dont have three hands to hold the probes
I tried UART and it had occasional wrong decodings, I tested it with my logic analyzer and everything was fine,
I tried CAN, It didnt decode the ID right and sometimes the 8th packet was missing!
if you decode in 10Mpts, it is very very slow, Ok I will try single shot and using the event table to see the packet, as soon as I enable the table the device gives me blank screen and you need to manually restart the device 
 

[nctnico]

Did you upload the firmware twice as the firmware update manual says? Maybe there is a combination of old and new firmware in your scope.

I just tried CAN decoding on mine (I decided to keep/buy the GDS2204E) and it works just fine. I can decode 500kbit/s CAN with 2MS/s or higher samplerates. UART seems to need much more oversampling. At 38400 baud I needed to use at least 500ks/s (13x) for the decoding to work. I agree the SPI decoding needing the CS line is a bit of a bummer.

[ali80]

Did you upload the firmware twice as the firmware update manual says? Maybe there is a combination of old and new firmware in your scope.

I just tried CAN decoding on mine (I decided to keep/buy the GDS2204E) and it works just fine. I can decode 500kbit/s CAN with 2MS/s or higher samplerates. UART seems to need much more oversampling. At 38400 baud I needed to use at least 500ks/s (13x) for the decoding to work. I agree the SPI decoding needing the CS line is a bit of a bummer.

The twice fimware upgrade thing is for gds-3000 series,
well decoding on CAN works partially, I see some of the data but the can ID isn't decoded properly, do you have any screenshot of you decoding?
also can you turn on the event table when the record length is 10Mpts? if I do so the device gives me blank screen!

[nctnico]

Regarding the firmware: I did some updates and I have the distinct feeling the firmware also needs to be loaded twice on the GDS2000E series.

I only get a blank event table if I set the time/div so the samplerate is below 100Ms/s with a 10Mpts record length. In my setup (continous stream of repeated messages) it seems there is not enough memory to decode all the messages. I attached some screendumps.

Edit: the missing ack was due to the CAN interface to the PC being off. In the last 2 screendumps it is on so the messages get an acknowledge.

[nctnico]

By the way: I think the GDS2000E is a pretty good scope for it's price and certainly better than Rigol's or Siglent's offerings becuase it actually works. There are still some issues with the version 1.20 firmware but I have received a beta firmware version from Gw Instek which already solved most of them. When I get a final firmware version I'll write up a more detailed review (I did a lot of testing before deciding to keep it).

[ebastler]

By the way: I think the GDS2000E is a pretty good scope for it's price and certainly better than Rigol's or Siglent's offerings becuase it actually works.

Your impression from reading the forum may be somewhat distorted. The more popular a scope is, the more people will use it and will come across issues (or will just keep talking about the same issues). For me the Rigol DS1000Z certainly "actually works".

I have never used a GW Instek scope, but the issues mentioned in this thread alone -- despite the much smaller user base -- do not give me a warm fuzzy feeling about it...

[nctnico]

Which issues are you referring to? Decoding works fine on the one I have so it must be some kind of firmware update gone wrong on ali80's scope or I'm doing something different.

Sure there are differences in features between the various oscilloscopes but there is a big difference between features working as advertised or not at all. Just look at the list of problems in the Rigol 1000Z! I used to own a Siglent SDS2204 myself and compared to the GDS2204E the Siglent SDS2204 is a total piece of crap!

Having learned from mistakes I have tested the GDS2204E thouroughly by going through a test plan with about 20 items before committing to buying it. Currently I'm waiting for GwInstek to fix one last minor issue. Feature wise it actually has some very strong points compared to my Agilent DSO7104A! It doesn't mean it will replace my DSO7104A but it does mean I'll use the GDS2204E for certain measurements because it is better equiped for the circumstances. For example: the GDS2204E has a much better math function, longer memory (especially with 4 channels enabled), longer FFT (1Mpts versus 128k), signal filtering, reference traces which can be moved,zoomed & scaled afterwards, etc. BTW I wanted an extra oscilloscope to bring along to customers which is why I ended up with the GDS2204E.

Edit: I agree about being sceptic about GwInstek. They have been in business for a long time but this oscilloscope is the first piece of GwInstek gear I own and probably used. They where also the last manufacturer I looked at because I could not find anything which fitted the budget and requirements from the other manufacturers.

[ali80]

I somehow agree with nctnico that gds-2000e has a lot of potential.
A lot of good and new features, I have also worked with rigol 2000 and agilent 2000 series and agree that it could beat rigol 2000 or even agilent 2000 series but only If they fix the bugs, some of the bugs you can deal with until the hopefully get fixed but some of them especially in decoding made the device unusable for me in that department.
I had previously worked with gds-2000A from gwinstek and that was a solid device and I dont remember any bugs or problems with that device, so I went ahead and bought this new gds-2000e model and wasn't expecting these type of bugs,
I think they rushed the product to the market and if they fix the bugs this could be a really good buy for the money,
I'll try to update the firmware twice and see if it fixes some of the issues.

[Mark_O]

I think they rushed the product to the market...

Hasn't this been out now for almost a year?  That doesn't sound like a "rush" to me. 

Or perhaps you're saying they rushed it out a year ago, and just haven't "gotten around to" fixing the problems yet?

[nctnico]

I think they rushed the product to the market...

Hasn't this been out now for almost a year?  That doesn't sound like a "rush" to me. 

Or perhaps you're saying they rushed it out a year ago, and just haven't "gotten around to" fixing the problems yet?

Yes and no. The firmware seems to be a generic one they probably use as a base for all their oscilloscopes so I think most of the firmware as seen a lot testing, feedback and bug fixing. The bugs I have found are more likely to be oversights when adapting the firmware to the new scope. GwInstek is from Taiwan (do they still call themselves Republic Of China?) after all.

[ali80]

I think they rushed the product to the market...

Hasn't this been out now for almost a year?  That doesn't sound like a "rush" to me. 

Or perhaps you're saying they rushed it out a year ago, and just haven't "gotten around to" fixing the problems yet?

I don't know, I'm somehow leaned toward the second one , I just hope that they would be at least trying to fix the bugs,
I updated the firmware for the second time, decoding still doesn't work properly at least on CAN, but I haven't seen the blank screen yet!
The CAN decoding sometimes work and sometimes doesn't work, in the last picture it couldn't decode the first packet but it decoded the second packet correct!
I think when the CAN packets are near each other it cant decode correctly!

[nctnico]

Hmmm. Your CAN signal looks different compared to mine. I'm measuring the CAN-HI wire. Where are you measuring and how did you setup the input?

[ali80]

Hmmm. Your CAN signal looks different compared to mine. I'm measuring the CAN-HI wire. Where are you measuring and how did you setup the input?

CAN_RX, from a can transceiver like mcp2551, its actually better because it removes common mode noise. CANH should also give the same result, only different voltage level

[nctnico]

I can't test using CAN RX but it seems CAN-HI is low when idle and CAN RX is high when idle. That looks suspicious to me however I don't know whether it should be that way or not. Can you test again using the CAN-HI signal?

[ali80]

I can't test using CAN RX but it seems CAN-HI is low when idle and CAN RX is high when idle. That looks suspicious to me however I don't know whether it should be that way or not. Can you test again using the CAN-HI signal?

Its OK, I have tested it with Saleae logic analyzer, the signal is allright, also the oscilloscope sometimes decodes the packets right, it has the option to get CAN_RX.

[Mark_O]

The CAN decoding sometimes work and sometimes doesn't work, in the last picture it couldn't decode the first packet but it decoded the second packet correct!
I think when the CAN packets are near each other it cant decode correctly!

I'd find it hard to understand why proximity would play any role.  Especially when it failed on the first.  I'm wondering if you just changed the time-base, to spread those two packets out a bit more, if the decode would correct itself.  I.e., is it decoding from the screen buffer, or the data buffer?  Any decoder doing the former will run into problems as things get squeezed.

[Mark_O]

Hmmm. Your CAN signal looks different compared to mine. I'm measuring the CAN-HI wire. Where are you measuring and how did you setup the input?

CAN_RX, from a can transceiver like mcp2551, its actually better because it removes common mode noise. CANH should also give the same result, only different voltage level

There's nothing wrong with that, if that's what you're looking for. 

However, my preference, since I'm taking the time to sample with an analog device, is to not only source my signal from the bus that the other devices share (as Nico has), but also to use two channels, to capture both CAN-H and CAN-L, and provide both those signals to the decoder.  Then, if an anomaly appears, I can examine both signals that contribute, in the analog domain.  If I had no interest in that level, I'd just use my USBeeSX logic analyzer (similar to your Saleae) in the first place.  Or the digital channels on my WaveRunner MSO, if I needed correlation with other signals.

[nctnico]

I did some further experimenting with 1Mbit/s but that decodes just fine even with back-to-back messages. However when I set the decoding to 800kbit/s then I get erratic decoding as well and with tweaking my CAN adapter to non-standard bitrates I can reproduce Al80's screendumps. Perhaps the timing of Ali80's CAN bus and the oscilloscope don't match too well. I think he should check the bitrate on the scope using the cursors to see if the scope shows a bitrate which is off.

[ali80]

The CAN decoding sometimes work and sometimes doesn't work, in the last picture it couldn't decode the first packet but it decoded the second packet correct!
I think when the CAN packets are near each other it cant decode correctly!

I'd find it hard to understand why proximity would play any role.  Especially when it failed on the first.  I'm wondering if you just changed the time-base, to spread those two packets out a bit more, if the decode would correct itself.  I.e., is it decoding from the screen buffer, or the data buffer?  Any decoder doing the former will run into problems as things get squeezed.

Tried it, if you zoom out or in it wont decode the second packet either way,
I'm pretty sure if you saturate the CAN bus it can't decode, for example in my first test CAN automatic retrasmission was on so if the receiver couldn't get the ack, it would send the same packet indefinitely, the decoder couldnt decode anything in this case although SALEAE decoded the packets correctly.

[ali80]

I did some further experimenting with 1Mbit/s but that decodes just fine even with back-to-back messages. However when I set the decoding to 800kbit/s then I get erratic decoding as well and with tweaking my CAN adapter to non-standard bitrates I can reproduce Al80's screendumps. Perhaps the timing of Ali80's CAN bus and the oscilloscope don't match too well. I think he should check the bitrate on the scope using the cursors to see if the scope shows a bitrate which is off.

I dont think my CAN baud rate is off since I have tested it with 2 other decoders (Saleae and Rigol 2000 series decoder), and also I never had problems in my CAN communication between my boards.
The scope's oscillator is also spot on, this only leaves me with software bug on the scope's side.

[nctnico]

Please check the CAN bus bitrate with the oscilloscope to be absolutely sure! It could be the other decoders are more forgiving when the bitrate is slightly off; either way it helps to know how where the problem is so GwInstek can fix it.
BTW My GDS2204 decodes a saturated CAN bus in a similar situation (no ACK) just fine although there is a limit on the number of packets which can be stored. The bus decoding will show 'overflow' when that happens.

[ali80]

Please check the CAN bus bitrate with the oscilloscope to be absolutely sure! It could be the other decoders are more forgiving when the bitrate is slightly off; either way it helps to know how where the problem is so GwInstek can fix it.
BTW My GDS2204 decodes a saturated CAN bus in a similar situation (no ACK) just fine although there is a limit on the number of packets which can be stored. The bus decoding will show 'overflow' when that happens.

Seems that you are right and I was wrong , I tested it on a different board and everything decoded right, I investigated the first board and the baud rate was off by 5%, so as you said all the other board and decoders that were decoding the packet right were more forgiving and the problem were on my side and not the scopes fault,
After my second update I haven't seen the blank screen yet, so that seems to be fixed too also by your suggestion, so double thanks to you nctnico.
Since my major problems with this device are fixed (giving blank screen and decoder not working), I'm now beginning to really like this scope, I think this scope deserves much more attention and I highly recommend this device,
There is still some bugs and problems I am wondering if there is anywhere to inform GWInstek for example,
1. My device gives me audible (between 1k~10k Hz) noise that changes with scopes operating condition (apart from fan noise which is typical and not bad), I am not sure if that is a power supply noise or anything else , the amplitude of the noise is not that much but if you are in a quite room, it is annoying, how to reproduce it: turn all channels on, connect channel one to scopes 1khz calibration output, go to 1us time division and change record length to see the audible noise change, It is audible in other settings but its amplitude may be less.
2. The scope doesn't show the waveform right! how to reproduce it: same settings as above just change time base to 500ns and record length to 100k, and you see the 1khz calibration signal jumping around although the trigger settings are right.

[nctnico]

Mine also has the whining noise; the problem is likely poor regulation / feedback stabilisation in the PSU. Maybe I'll hack that some day when the warranty has expired. The beta version in my scope has some fixes for signal display problems. I'll test what you describe with my scope in a few days.