SDS 1202 X-E I2C triggering bug

[17_29bis]

Hello,

I just got  a new SDS 1202X-E oscilloscope (OS) and I think I found  a bug in the I2C triggering system. I wonder what other users of this particular OS think about this problem.

My OS runs v.5.1.3.13  firmware and has 0c-01 hardware version. I want to trigger on "7 bit Address& Data". I properly set up the triggering on "Start" condition and can observe, decode and examine the data exchange between i2c master (AVR, hardware i2c)  and slave  (LCD display, addr 0x3F). The data exchange is 99% constant, always start from writing 0x8C into the slave device:



I change the triggering mode from "Start" to "7 bit Address& Data" and set the I2C address to 0x3F and any data (0xXX)- trigger works fine:




Now I set the I2C address to 0x3F and the fist byte to 0x8C -trigger does not work:



But at the same time if I set the first byte to 0 the trigger starts working:



and this is wrong.

PS: this is my first post so please forgive me for not inserting the images right in the message body since it would be much easier to read the post - I simply could not figure out how to do that because the image tag could not display the images (in png format) stored on the remote ftp.

Regarding the spikes on the SDA line - you can safely ignore them.

Thanks!

[tautech]

Hello,

I just got  a new SDS 1202X-E oscilloscope (OS) and I think I found  a bug in the I2C triggering system. I wonder what other users of this particular OS think about this problem.

My OS runs v.5.1.3.13  firmware and has 0c-01 hardware version. I want to trigger on "7 bit Address& Data". I properly set up the triggering on "Start" condition and can observe, decode and examine the data exchange between i2c master (AVR, hardware i2c)  and slave  (LCD display, addr 0x3F). The data exchange is 99% constant, always start from writing 0x8C into the slave device:

SDS00003.png


I change the triggering mode from "Start" to "7 bit Address& Data" and set the I2C address to 0x3F and any data (0xXX)- trigger works fine:

SDS00005.png

Now I set the I2C address to 0x3F and the fist byte to 0x8C -trigger does not work:

SDS00008.png

But at the same time if I set the first byte to 0 the trigger starts working:

SDS00009.png

and this is wrong.


Regarding the spikes on the SDA line - you can safely ignore them.

Thanks!

Welcome to the forum.

Can you be sure about the spikes ? Did you set the thresholds above them ?

PS: this is my first post so please forgive me for not inserting the images right in the message body since it would be much easier to read the post - I simply could not figure out how to do that because the image tag could not display the images (in png format) stored on the remote ftp.

I embedded one to show you how.
Copy the image URL after posting, then Use Modify post and paste it within your text.  Highlight it and use the Insert Image icon on the posting page.
Study the syntax used by Quoting this post.

[17_29bis]

Can you be sure about the spikes ? Did you set the thresholds above them ?

Yes, I am sure. I set the threshold for SDA line above and below the spike and  it did not make any difference in triggering and decoding. Why? Because those spikes occur when SCL is low and therefore they don't matter in this case. I zoomed at the spike you can see that for yourself:

Copy the image URL after posting, then Use Modify post and paste it within your text.  Highlight it and use the Insert Image icon on the posting page.

Interesting approach, no wonder I could not figure that out. Thanks for the hint.

BTW, is there any place where I can check for firmware updates for this o-scope? I heard about Facebook but I don't have an account and don't want to create one. I checked Siglent website and could not find any firmware updates for this device  at all.

[17_29bis]

I decided to use a standalone logic analyzer (threshold level - 1.8V), this is addition info about the spikes:

[tautech]

BTW, is there any place where I can check for firmware updates for this o-scope? I heard about Facebook but I don't have an account and don't want to create one. I checked Siglent website and could not find any firmware updates for this device  at all.

There's been one since release but you've got the latest which came out last July. The last units I got just before Xmas had the same version.
The US site is in a bit of a mess ATM and doesn't display the full list like the Chinese and Hamburg sites do.
http://siglenteu.com/gjjrj.aspx?id=15&page=1


I've shown a a few posts of I2C decoding but only while using the Siglent STB3 test board.
The Decode functionality has been mentioned as 'not quite right' in this thread for the 4ch X-E.
https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/
Since the 2ch version is very similar it might be afflicted with a similar problem that I don't see using the Siglent test board.
For both the 2 and 4ch X-E's, we expect some of these reported issues to be sorted in new firmware shortly.


I still have a nagging suspicion that the spikes are some of the cause of the problem but others smarter than I might have a better idea. 

[17_29bis]

I think I found the webpage with firmware updates for this o-scope:

http://www.siglent.com/ENs/prodcut-gjjrj.aspx?id=1909&tid=1&T=2

What is really confusing is that Siglent says "SDS1000X-E " and means "SDS1202X-E"  - those numbers dont match.

[tautech]

I think I found the webpage with firmware updates for this o-scope:

http://www.siglent.com/ENs/prodcut-gjjrj.aspx?id=1909&tid=1&T=2

What is really confusing is that Siglent says "SDS1000X-E " and means "SDS1202X-E"  - those numbers dont match.

The SDS1202X-E update was released before the 4ch X-E models were released and they're all of the same SDS1000X-E  series BUT the 4ch firmware when it comes along is a totally different beast and the firmware for SDS1202X-E and 4 ch X-E versions will have to be boldly identified as very different. This I've checked on with the X-E product manager.
I hope Siglent migrate the 2 firmware's into one as it will negate the chance of installing the wrong one.

So you have the current version, period.

Give this thread a bit, member Performa01 will enlighten us to the current I2C bug situation and no doubt he's reported this one.....he don't miss much. 

[Performa01]

Give this thread a bit, member Performa01 will enlighten us to the current I2C bug situation and no doubt he's reported this one.....he don't miss much. 

I have never looked into the SDS1202X-E serial decoding, because I have had little spare time back when this scope came out. Later on I figured there was no need for excessive testing of the serial decoders, as any obvious bugs would have been discovered by the many users in the meantime anyway.

I am looking deeply into the SDS1x04X-E scopes though, but have not done a proper review of the serial decoding yet, as there are some issues that I hope will be sorted with the next firmware release that should be available soon.

What I can say right now is that the before mentioned issues are mostly for LIN, SPI and UART, whereas I2C and CAN work pretty good even with the current firmware.

I happen to have a screenshot from my initial evaluation for I2C, where I can demonstrate the serial trigger working just fine.


SDS1104X-E_Serial_IIC_Trig_7Addr+Data
 

[17_29bis]

What I can say right now is that the before mentioned issues are mostly for LIN, SPI and UART, whereas I2C and CAN work pretty good even with the current firmware.
I happen to have a screenshot from my initial evaluation for I2C, where I can demonstrate the serial trigger working just fine.

Thanks for the screenshot. There are many factors which may affect the result i.e. why it worked for you and does not work for me. For example the version of the used firmware (mine is the latest), different hardware and such.
The I2C setup is pretty simple on this o-scope so I am 100% sure everything is done correctly during my test.

Looking at your screenshot I am curios what those "~A" characters at the of each data string means. I don't see them on my screenshots. But assuming that "A" stands for acknowledgement the situation is even more weird. Some theory first (sorry, no offense I simply  dont know how much you know about I2C but want to make sure that we are on the same page).

What is acknowledgement?



Now let look at my screenshot (this is writing the byte 0x8C to the device with 0x3F address and count the SCL impulses looking at the ninth clock - ack is there (low level):



This is the zoomed version of the same screenshot showing the second "ninth clock":





PS: I am not sure why I see on your screenshot the first record in the table with decoded data: your trigger is set up to trigger on writing bytes 0x89 & 0x9A to a slave with address 0x2. First record means reading from the slave with address 0x4 several bytes which have nothing to do with  0x89 & 0x9A.  Should the decoding start from the line 2  ?

[tautech]

Should the decoding start from the line 2  ?

Line 2, the highlighted one is the first after trigger conditions have been met. The clue to this is the time of the event/decode in the Time column.
Even though it might seem the Line 2 time is before the event, the Trigger conditions that the scope has met are after the start of the packet.

[Performa01]

Thanks for the screenshot. There are many factors which may affect the result i.e. why it worked for you and does not work for me. For example the version of the used firmware (mine is the latest), different hardware and such.
The I2C setup is pretty simple on this o-scope so I am 100% sure everything is done correctly during my test.

Looking at your screenshot I am curios what those "~A" characters at the of each data string means. I don't see them on my screenshots. But assuming that "A" stands for acknowledgement the situation is even more weird.

...

PS: I am not sure why I see on your screenshot the first record in the table with decoded data: your trigger is set up to trigger on writing bytes 0x89 & 0x9A to a slave with address 0x2. First record means reading from the slave with address 0x4 several bytes which have nothing to do with  0x89 & 0x9A.  Should the decoding start from the line 2  ?

My screenshot is from the latest (currently one and only) firmware V7.6.1.12 – this information doesn’t help much as the firmware for SDS1x04X-E has lots of additional features, hence version numbers are quite different to the SDS1202X-E. Nevertheless, the I2C decoder shouldn’t be very different for the latest firmware versions for both scopes.

The “~A” character at the end of the decoded data strings actually means No Acknowledge. However, the current I2C decoder has a known bug; it might misinterpret the last acknowledgement at the end of a longer message as “no acknowledge”. We haven’t seen this bug with single byte messages yet and your decoding looks as it should. The acknowledgement in your messages is indeed correctly recognized by the scope.

A serial trigger can only fire after analyzing the address (and first up to two data bytes, depending on the trigger type and settings) of a message, which in turn means it has to receive this part of the message first. So it comes as no surprise that the triggered message starts before the trigger point, hence gets a negative timestamp (timestamps in the list are always relative to the trigger position).

It depends on the trigger position how many messages you see before the trigger event. As you can see, I have set the trigger position rather far to the left of the screen (68ms delay) so that I get only one additional message before the triggered one.

Apart from all that, I have no idea why the data trigger appears to fail in your setup. Maybe there actually is a bug in the SDS1202X-E that has been corrected for the SDS1x04X-E already. I would check that for you, but can do that only at the weekend, as I have no access to my lab during the week.

[17_29bis]

Apart from all that, I have no idea why the data trigger appears to fail in your setup. Maybe there actually is a bug in the SDS1202X-E that has been corrected for the SDS1x04X-E already. I would check that for you, but can do that only at the weekend, as I have no access to my lab during the week.

I took a different couple of master/slave devices and to my surprise  I2C decoding and triggering on "7 bit Address&Data" works. The major difference is in the size of the payload - during the failed test  the length of the payload was 1 data byte, in the second test the length of the payload varied from 4 to X bytes. Sorry, if I am asking a dumb question but how does one scroll horizontally  to examine the long array of data bytes in the table of the decoded I2C data? I could not figure out that yet. So, later when I have time I will probably write a small program that will generate different number of data bytes in the I2C payload to see how its affects the triggering in "7 bit Address&Data" mode.

Triggering on 0x00 0xB1 data bytes (the  second data exchange):

The “~A” character at the end of the decoded data strings actually means No Acknowledge. However, the current I2C decoder has a known bug; it might misinterpret the last acknowledgement at the end of a longer message as “no acknowledge”. We haven’t seen this bug with single byte messages yet and your decoding looks as it should. The acknowledgement in your messages is indeed correctly recognized by the scope.

Regarding acknowledge / no acknowledge. Triggering on  "no acknowledge" works just fine, I wrote a small program that scans I2C bus for addresses 0-127 to find all present devices and I could see  that o-scope would trigger right at the rising edge of SCL impulse for  "no acknowledge" signal on SDA line. So this is the good news. At the same time the decoder did no show any info (and I dod't know if this is by design) although in ideal world it could show the probed address and “~A” that you mentioned above.   

No acknowledge case:

It depends on the trigger position how many messages

Thanks, I immediately figured that out after the serial trigger began to work. This is another screenshot showing the triggering on a different data byte and the relative time shift.
Triggering on  0x00 0xB0 data bytes (the  first data exchange):




Another moment that puzzles me a lot is the triggering on data length. So far I could not make it work - at all.

My screenshot is from the latest (currently one and only) firmware V7.6.1.12 – this information doesn’t help much as the firmware for SDS1x04X-E has lots of additional features, hence version numbers are quite different to the SDS1202X-E.

That's really sad news, because I assumed that there was no much difference (other than the number of channels) between 1204X-E and 1202X-E. The 1202X-E was in stock and I ordered one. Knowing now that 1204X-E is more advanced I should have ordered it instead of 1202X-E.  As I can see 1204X-E has lower input capacitance (15 vs 18 pF). I am curious if it has 50 om input impedance , averaging triggering mode (1202X-E does not) and the missing capacitors issue....

[17_29bis]

The last part.  First of all, there is a bug indeed. if the length of the payload is 1  byte then the i2C trigger on "7 Addr&Data" does not work as expected. Any attempt to set DATA1 or DATA2 to the value of  the payload will lead to the trigger failure. But if DATA1 is set to 0 then the trigger will be activated on _any_ 1 byte long payload, i.e it can be 0x80 or 0x81 - it does not matter because the value of  the payload itself is ignored.

Example1:


Zoomed version:




Example2:



Zoomed version:




It is important to note that in this case the trigger activates at the rise edge of the 9th clock after the first data byte (in this case the length of the payload is 1 byte)i.e  on the rise edge of ACK. I will show later how it changes depending on the way how the i2C trigger is set.

[17_29bis]

Secondly. Looks like SDS1202X-E does not discard incomplete bytes in the payload although they are easily detectable. How do those incomplete data bytes occur? The data bytes may become incomplete due to too small capture time.

Example: 



There is no 0x00 byte at the end of the payload, the actual value is 0X0F as seen here:



Therefore if you see "~A" (which seems to mean "no acknowledge") at the end of the payload  make sure that your payload is not truncated (because the last byte may be wrong) or just increase the capture time. Not a big deal but still should be taken into account.

[Performa01]

Well, looks like the I2C trigger/decoder has a few bugs, maybe even more than in the current SDS1004X-E firmware. I have already pointed Siglent to this thread so they can investigate and see if there’s anything new that they aren’t already aware of.

There are never dumb questions - only dumb answers…

And my dumb answer regarding the list view simply is that I don't know either. I can only speculate … maybe Siglent engineers thought that a few data bytes should be enough because I2C is mostly used for controlling peripherals where rather short messages are common.

Basically not a big issue though, as there would be an easy work-around utilizing the decoding line at the bottom of the screen. For this we'd need to zoom into the waveform so that the decoded data becomes readable. Then we can scroll through the entire message by changing the horizontal position.

There are two options:

1.   Just stop the acquisition by hitting the Run/stop Button. In Stop mode, you can set any timebase you want and use the horizontal position control to navigate through the entire record.
2.   While in Run, you can enter Zoom mode by pushing the horizontal time/div control. Once again, you can navigate by lowering the timebase and using the horizontal position control.

The SDS1000X-E will keep the decoder list for the entire record and automatically scroll the data that matches the signal trace into view. This allows you to examine the signal trace that belongs to a certain part of the message and also to see all the data bytes that are cut off in the list view. Currently this can be rather slow, especially with long records, so for the time being I generally recommend limiting the max. memory depth to 700kPts when serial decoding is used.

A device not answering doesn't generate any data either, this is probably why there also is no “No Acknowledge” notification. But I'll make sure Siglent reads this and maybe your suggestion will be picked up. I personally will support your request and cannot think of a reason why this should be hard to implement. So maybe this will make it into one of the future updates.

Data Length Trigger works with the length of Address and Data in bits. It is somewhat strange that the trigger fires on 10 bit data with my test stream – quite obviously there is some misinterpreting going on, at least when signals with certain timings are used. Apart from that, I cannot think of a useful application for this trigger in most standard scenarios. Since your messages are all the same, the scope will only trigger in this mode if you set the address to 7 bits and the data to 8 bits (or whatever number of bits has to be set because of the flawed interpretation) - but then, it will trigger on each and every message. This trigger obviously is only useful in a system with mixed message formats, where you want to trigger any messages that fit the format you've set for the decoder. Not sure how often this will see use in real applications - at least I for one have never seen let alone designed such a mixed format system on a single bus. This makes only sense for a multi-master system, which I've always tried to avoid at all costs.

Regarding the differences between SDS1202X-E and SDS1x04X-E you might want to have a look here:

https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/

But your specific questions are not explicitly answered there, so here is what I can tell:
A lower input capacitance is always nice of course, but 15pF vs. 18pF really doesn't make a noticeable difference in practical terms.

SDS1x04X-E scopes never had missing caps, because that problem was discovered before the first production units of this scope have left the factory.

The "E" in X-E stands for Economy. These are entry level scopes - albeit rather capable ones. But they don't feature an internal 50 ohm termination like the 1000X (without the “-E”) and 2000X do. In my review I have closely examined the input impedance of the SDS1104X-E with external termination.

Not sure what you mean by "averaging trigger mode". But whatever it is, the trigger system is the same for all SDS1000X-E models, except for the Ext and Ext/5 trigger sources, which are missing on the 4 channel models.

[17_29bis]

The last bit. I think I understand the reason why the I2C trigger condition  "7 bit Address&Data" does not work when  the payload contains only a  single byte.  The documentation is very scarce, so I decided to add some explanations, may be it will save some times to other users of this device (may be I am just not savvy enough).

Looks like the idea behind I2C trigger condition  "7 bit Address&Data" is to have a fixed length, 2 byte floating window/mask  which applies to the decoded data (those 2 "DATA1 & DATA2 values).   0xXX value is used to indicate that this particular data byte will be ignored/can be ANY.

The o-scope manual says: "If the data's value is 0xXX any value data will be matched". But in this particular case ANY does not mean  NONE and this is important.

So if you want the o-scope to trigger  on the byte 0x33 (i.e. not the first and no the last byte)  the trig. condition  can be defined as:

a) 0x33  0xXX
b) 0xXX  0x33

The only difference is the time when the triggering occurs:
a) 0x33  0xXX

b) 0xXX  0x33


if you want the o-scope to trigger  on the last byte 0x0F  the trig. condition  should be defined as:  0xXX 0x0F (a) . If the condition is defined as 0xF  0xXX (b)  the o-scope will  not trigger at all because the data byte corresponding to 0xXX does not exist in the payload.

a)  0xXX 0x0F

b) 0xF  0xXX


if you want the o-scope to trigger  on the first byte 0x13  the trig. condition  should be defined as:  0x13 0xXX . If the condition is defined as 0xXX 0x13 the os-cope will  not trigger at all because the first byte (defined as 0xXX) does not exist in the payload.


And finally is you set the mask 0x01 0x0x0F the trigger will  not work because those data bytes are supposed to be adjacent while in this particular example they are separated by the byte 0x33.

[17_29bis]

Not sure what you mean by "averaging trigger mode".

Was it me? Then sorry, I am not sure what I meant, I don't know what "averaging trigger mode" is.

Data Length Trigger works with the length of Address and Data in bits. This trigger obviously is only useful in a system with mixed message formats, where you want to trigger any messages that fit the format you've set for the decoder. Not sure how often this will see use in real applications - at least I for one have never seen let alone designed such a mixed format system on a single bus. This makes only sense for a multi-master system, which I've always tried to avoid at all costs.

I have never seen such config either - 2 different sets of devices using 7/10 bit addr. sharing the same bus and was just curios how it can be used. But my career of the embedded hardware/software engineer ended 25 years ago therefore my knowledge is outdated, the terminology is rusty.

Regarding the differences between SDS1202X-E and SDS1x04X-E you might want to have a look here:
https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/
But your specific questions are not explicitly answered there, so here is what I can tell:
A lower input capacitance is always nice of course, but 15pF vs. 18pF really doesn't make a noticeable difference in practical terms.
SDS1x04X-E scopes never had missing caps, because that problem was discovered before the first production units of this scope have left the factory.
The "E" in X-E stands for Economy. These are entry level scopes - albeit rather capable ones. But they don't feature an internal 50 ohm termination like the 1000X (without the “-E”) and 2000X do. In my review I have closely examined the input impedance of the SDS1104X-E with external termination.

I have already returned SDS1202X-E and waiting for an answer from the seller regarding availability of 1204X-E, they have to contact Siglent first. I would say that SDS1202X-E fits my hobbyist's needs almost perfectly but I do want to have 4 channels ( I will also get wifi adapter and the software  to control the device from PC)  -I realized that only now.  I have a standalone logic analyzer but after playing with serial decoding on 1202X-E I decided that it has its own merits - I think there will be times when I use the oscilloscope rather than the logic analyzer for decoding those protocols (but not always). That is why I decided to upgrade.  I am also considering 2204X since its nice to have higher time sampling rate (2 vs 1 GSa/s) and more memory but in Canadian dollars it is around 3K while  SDS1202X-E is 1K CAD.
 

The "E" in X-E stands for Economy.

Yes, I noticed that when I was running the built-in keypad test  (you press a button and check its response on the o-scope screen) - on my 1202X-E some buttons required multiple presses. One of those buttons was single trigger and it was kind of annoying. But like you said "E" stands for economy  . Other than that - I really liked this o-scope!

[tautech]

I have already returned SDS1202X-E and waiting for an answer from the seller regarding availability of 1204X-E, they have to contact Siglent first.

If your seller has no stock of the 4ch models there's unfortunately a wait right now for production to match demand.

I would say that SDS1202X-E fits my hobbyist's needs almost perfectly but I do want to have 4 channels ( I will also get wifi adapter and the software  to control the device from PC)  -I realized that only now.

The WiFi dongle is a TP Link TL-WN725N, gold version and more cheaply available from other sources than Siglent. You'll still need the 'WiFi software enable' option: SDS1000X-E WIFI

No software is needed for PC control as the scopes inbuilt web server only needs a free LAN IP address for connectivity and operation.
Use an 'ipconfig' command in a DOS box to get one close to your PC and use that.
Open a browser window and input the scope's assigned address and hey presto, connection.

If you liked the 1202X-E you'll be impressed with the 4ch models.

[rf-loop]

Yes, I noticed that when I was running the built-in keypad test  (you press a button and check its response on the o-scope screen) - on my 1202X-E some buttons required multiple presses. One of those buttons was single trigger and it was kind of annoying. But like you said "E" stands for economy  . Other than that - I really liked this o-scope!

This is not at all normal.
I have never seen this in any X-E model what I have checked. (Normally I check every unit before end user).

Only one single problem I have meet it was in my own very early production X-E (my own demo unit) where one encoder was bit bad. Perhaps damaged in factory or shipping. This one encoder works kind of bit randomly some times. After then contact with Siglent and new front panel board solve problem.

This your individual unit need repair. This kind of problem is not acceptable at all. E do not mean C (Crap).
There is warranty. Use it. This is only way to teach Siglent about quality control.  It is also expensive way to teach hands washing and learn the use of clean gloves and the importance of general cleanliness in the assembly of equipment.

Others want to learn and develop themselves. Others should be taught. There is a difference between the Western and Chinese industries. The top-down command system is not the best possible development environment. From the floor cleaners to the top management, each one should be one motive - the desire to learn and bear responsibility for quality - each assembly worker should think that quality is just my responsibility and I want to do quality. How can this idea be exported to China?

(as you can read I may quess what is problen in your front panel. It is not normal but some times some worker may break rules and eat example chicken toes and then... asssemble next front panel..)

[Performa01]

I have already returned SDS1202X-E and waiting for an answer from the seller regarding availability of 1204X-E, they have to contact Siglent first. I would say that SDS1202X-E fits my hobbyist's needs almost perfectly but I do want to have 4 channels ( I will also get wifi adapter and the software  to control the device from PC)  -I realized that only now.  I have a standalone logic analyzer but after playing with serial decoding on 1202X-E I decided that it has its own merits - I think there will be times when I use the oscilloscope rather than the logic analyzer for decoding those protocols (but not always). That is why I decided to upgrade.  I am also considering 2204X since its nice to have higher time sampling rate (2 vs 1 GSa/s) and more memory but in Canadian dollars it is around 3K while  SDS1202X-E is 1K CAD.

Be aware that WiFi is an option (I’ve not tried it yet). In my review I have demonstrated the use of the web server (using a wired LAN connection) and its limitations.

Regarding DSO/MSO vs. LA it is good to meet someone who knows to use the proper tool for a specific task. Serial decoders are just an add-on for a DSO/MSO and are not meant to replace a dedicated protocol analyzer. But a MSO with serial decoding capabilities can be a great tool for low level signal integrity checks and fault finding, especially when the time relation between Analog and digital signals as well as bus telegrams needs to be examined, which is what a MSO should be used for in the first place.
High level communication monitoring/debugging on the other hand is a task for an LA/protocol analyzer.

The SDS2204X serial decoders are limited to what’s currently visible on the screen. For example, after zooming into a long record, the list view will get shortened accordingly and context to the entire data record is lost. Especially for I2C, decoding may stop working as soon as the start condition of a message has been scrolled outside the visible screen area. Generally, these scopes have less processing power, so automatic measurements only use up to 70/140kpts of the acquired data (still vastly better than many other DSOs!) and FFT is limited to 16kpts.

Still, an SDS2kX series DSO/MSO is a great tool for analog work and also mixed signal with the MSO option. It has a larger screen and despite the lower processing power, its user interface is still snappier than on the SDS1000X-E and the max. waveform update rates (both standard and sequence mode) are faster. Of course it also has some higher class features like internal 50 ohm termination, automatic probe sensing and gold plated input connectors.

I would say, if you can live with 1GSa/s and 200MHz nominal bandwidth (more like 240MHz in practice), the SDS1204X-E is a clear price/performance winner.

Yes, I noticed that when I was running the built-in keypad test  (you press a button and check its response on the o-scope screen) - on my 1202X-E some buttons required multiple presses. One of those buttons was single trigger and it was kind of annoying. But like you said "E" stands for economy  . Other than that - I really liked this o-scope!

The sometimes unresponsive buttons and controls are certainly not a “feature” of the “-E” models. Vertical and horizontal encoders sometimes miss a notch, but this simply is a firmware bug which should be sorted eventually. I haven’t experience unresponsive buttons though, so this might be a specific issue of your unit. As you’ve already returned it, you should make your supplier aware of the issue, so they don’t pass on a defective unit to the next customer.

If you liked the SDS1202X-E, you will most probably like the 1204X-E even more – a lot more. It still has bugs in some areas, but they will get fixed sooner or later.

[17_29bis]

The WiFi dongle is a TP Link TL-WN725N, gold version and more cheaply available from other sources than Siglent. You'll still need the 'WiFi software enable' option: SDS1000X-E WIFI

Yes, indeed - TP-Link TL-WN725N Wireless N Nano USB Adapter, 150Mbps  at amazon.ca is  just 13$ and this is way less than 65$. But after reading the excellent 8 part review of SDS1104X-E written by Performa01 I am a bit disappointed by how little this software provides and I am not even sure that I will get the WifFi adapter.

https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/

What a great review! Believe you or not but you answered 99% of all my questions. I was wondering about  Lissajous figures, differential voltage measurement on this DSO, difference between different types of 50 om terminators, how SDS1202X-E handles square waves and a lot of other information.
I was searching for the info about SDS 1202X-E and I am pretty much sure many other people did that too - I found very little and did not find Performa01's review in particular. But it never occurred to me than when you say "sds1104" you mean more than just one model. I am pretty much sure that every potential buyer of SDS 1XXX device would greatly benefit from reading the documents in question.

[tautech]

The WiFi dongle is a TP Link TL-WN725N, gold version and more cheaply available from other sources than Siglent. You'll still need the 'WiFi software enable' option: SDS1000X-E WIFI

Yes, indeed - TP-Link TL-WN725N Wireless N Nano USB Adapter, 150Mbps  at amazon.ca is  just 13$ and this is way less than 65$. But after reading the excellent 8 part review of SDS1104X-E written by Performa01 I am a bit disappointed by how little this software provides and I am not even sure that I will get the WifFi adapter.

All options work free for a trial period in which you can decide if you want one or not and of course any can be made permanent later if you wish.
The WiFi just adds convenience and portability over hard wired LAN and the same functionality of the inbuilt webserver is available in/with either remote connection type.

When I was beta testing a SDS1104X-E I used a laptop and WiFi that I actually found a lot more convenient to be away from my normal work space and the email and online distractions like EEVblog. Using direct WiFi connection was a little more troublesome than through a WiFi access point as there's no DCHP to help with simple connection and each time you closed connection (shutdowns) you'd have to reassign IP's rather than save them and just turn ON the WiFi and be back where you finished.
It was a bit of a PITA to do it that way, but entirely possible if needed/required.

[17_29bis]

Still have not heard back from my seller regarding SDS1204X-E and I am slowly getting impatient.
I see that right now SDS2204X is on sale -1.5K USD + some extra. It gets really attractive. I am curious - the manual says "max. sampl. rate 2GSa/s". How many ADC  does  SDS2204X have and what the actual sampling rate if all 4 channels are in use? Will it be 2GSa/s per channel or what?

[Performa01]

For the SDS2204X It’s exactly the same as with the SDS1000X(-E), just twice the sample rate. So for the four channel models you get two ADCs and in case of the SDS2kX this provides 2 x 140Mpts @ 2GSa/s or 4 x 70Mpts @ 1Gsa/s. Average and Eres as well as X/Y are generally limited to 7/14kpts though.

[tautech]

This issue appears to be dealt with in the latest SDS10004X-E firmware:
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg1420112/#msg1420112

7.Fixed a bug in the I2C triggering system of 7 bit Address& Data

There's been a firmware release for SDS1202X-E too but it's not listed in the changelog for the 2ch version. 
Maybe someone can check....
http://siglenteu.com/gjjrj-xq.aspx?id=4072&tid=15