Siglent SDS1104X-E and SDS1204X-E Mixed Signal Oscilloscopes

[tautech]

Hi, I'm facing a few problems with the 1000X–E I2C decoding capabilities. Maybe I'm doing something wrong, but when monitoring the SCL and SDA channels, I only get partial data segments. I'm watching I2C communication between an Arduino UNO R3 and an I2C LCD on the address 0x27. The trigger I use is for Serial / I2C 2.5V thresholds on both channels and triggering on the 7bit data type with an explicit address of 0x27 and Write bit.

The Arduino refreshes the screen in every 1s, cycling through data, and the scope triggers in every second as intended. It shows the right amount of messages, but the data payload does not seem to be alright. If I use Hex type outputs, it only shows one byte like 0x09, the ASCII corresponds to it as well, but the data does not seem to match the display itself.

(Attachment Link)
(Attachment Link)

One other issue is with the triggering. Even if I trigger at the 0x27 address, sometimes, with bigger sample rates, I get all kinds of data and it does not use the triggers. Also attached a picture of this state, where it clearly shows an address 0x48, what is clearly should be out of scope.

(Attachment Link)

What am I doing wrong? Is it a limitation/bug with the scope?

Welcome to the forum.

IMO it's high time you learnt how to take screenshots to USB using the blue Print button and normally we would have a menu showing that tells us something about scope settings, not a channel menu as we can see all we need in the channel tab.

You might get a few tips from another recent thread:
https://www.eevblog.com/forum/beginners/sds1104x-e-review-decode-section/

If later today I get time I'll try and replicate your 0x27 triggering on a STB-3 Siglent test board.

[inzekt]

Welcome to the forum.

IMO it's high time you learnt how to take screenshots to USB using the blue Print button and normally we would have a menu showing that tells us something about scope settings, not a channel menu as we can see all we need in the channel tab.

You might get a few tips from another recent thread:
https://www.eevblog.com/forum/beginners/sds1104x-e-review-decode-section/

If later today I get time I'll try and replicate your 0x27 triggering on a STB-3 Siglent test board.

Hi, thanks, sorry, I took a few screen grabs from the web interface.

There is a good state, and there is a false trigger also. You can see the trigger menu also on the bottom. I will run through the decode thread, maybe there is some evident error on my side.

[tautech]

Hi, thanks, sorry, I took a few screen grabs from the web interface.

There is a good state, and there is a false trigger also. You can see the trigger menu also on the bottom. I will run through the decode thread, maybe there is some evident error on my side.

First thing noticed is trigger position is off screen to the left. Pres the H Pos encoder to return it to 0s, the middle of the display and then set it left again but keeping it on the display.

Oh and about that, P4 in Utility has a setting for Ref position, set Hor to fixed which will fix the H Pos in one place regardless of timebase setting.

[inzekt]

First thing noticed is trigger position is off screen to the left. Pres the H Pos encoder to return it to 0s, the middle of the display and then set it left again but keeping it on the display.

Oh and about that, P4 in Utility has a setting for Ref position, set Hor to fixed which will fix the H Pos in one place regardless of timebase setting.

Yeah, I definitely played with the Horizontal position in the utilities, and also the horizontal trigger position, forgot to zero it back. Did revert the change in the utilities and moved around the trigger also a bit, but now, I'm constantly getting the 0x48 address.

If I go down to around 2.8M sample points, it triggers well. Also attached that

[inzekt]

I just put hours into testing out the decoding feature. Went back to basics to eliminate, if my previous code had any issue and just wrote an simple one, what counts to 999 and prints it on the LCD in every 500ms. In addition to that, it writes to a fictive address 0x1E two times. First 5 bytes, then 1 byte. So in every half second, there should be a three writes, one with an integer to the 0x27 address, and two to the non working 0x1E.

The code works, the display refreshes, and I can even see that there is communication towards 0x1E also on the scope.

But, even if I only trigger on the 0x27 address, it gives me the 0x1E every time, and the communication to the LCD is gibberish on the scope too.

It should be multi-byte transmissions, with just numbers in it, but it is always showing the same one byte: 9, =, ], Y and a few other characters, but it isn't consistent and can't get it work to show the real data with different horizontal scales, sampling points, trigger voltage thresholds, etc.

The 0x1E data is empty, even if it should contain 5+1 bytes.

Not to mention the triggering issue, what is a huge one, if there is a lot of chatter to other addresses as well, like my previous code. It's just not usable to show data in a predictable way.

I tried using different Arduino boards, different wiring, pull–up resistors with multiple values (1k, ~5k, 10k), tried different voltages as an input, or just USB, it's all the same.

[Performa01]

I don't know if it helps, but I found some old review content regarding serial decode, also including I2C.

Browsing my old data, I realised that I've never published the serial decode tests. Now even though they are most likely a little outdated by now, I still though I'd add them to the existing content (SDS1104X-E Review 2_174-201.pdf):

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

[Neutrion]

Performa01:
Did Siglent otimized the ERES in the meantime? Or are they planning to? You mentioned in your review that it is a low priority task but it would still be a great thing to get somehow some more bits. Or whatever was possible to optimize.
If you would happen to have some spare time, to explain what would be possible actually, it would be great to know! 

[inzekt]

I don't know if it helps, but I found some old review content regarding serial decode, also including I2C.

Browsing my old data, I realised that I've never published the serial decode tests. Now even though they are most likely a little outdated by now, I still though I'd add them to the existing content (SDS1104X-E Review 2_174-201.pdf):

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

Thank you very much, it is a great overview. I noticed in your I2C section, the last two screenshots (showing the triggers), it also included non–triggered events in the list view. Even if you were triggering on the address of 0x47, it also shows 0x53 also, and with the EEPROM Data1 trigger with 0x94, it also shows another message not matching that. Why is that?

[2N3055]

I don't know if it helps, but I found some old review content regarding serial decode, also including I2C.

Browsing my old data, I realised that I've never published the serial decode tests. Now even though they are most likely a little outdated by now, I still though I'd add them to the existing content (SDS1104X-E Review 2_174-201.pdf):

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

Thank you very much, it is a great overview. I noticed in your I2C section, the last two screenshots (showing the triggers), it also included non–triggered events in the list view. Even if you were triggering on the address of 0x47, it also shows 0x53 also, and with the EEPROM Data1 trigger with 0x94, it also shows another message not matching that. Why is that?

Trigger takes care of when and where the capture will start. If you capture 10 (or 50) messages, it will decode all of them.. But it will start on the one trigger was set for...

[inzekt]

I don't know if it helps, but I found some old review content regarding serial decode, also including I2C.

Browsing my old data, I realised that I've never published the serial decode tests. Now even though they are most likely a little outdated by now, I still though I'd add them to the existing content (SDS1104X-E Review 2_174-201.pdf):

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

Thank you very much, it is a great overview. I noticed in your I2C section, the last two screenshots (showing the triggers), it also included non–triggered events in the list view. Even if you were triggering on the address of 0x47, it also shows 0x53 also, and with the EEPROM Data1 trigger with 0x94, it also shows another message not matching that. Why is that?

Trigger takes care of when and where the capture will start. If you capture 10 (or 50) messages, it will decode all of them.. But it will start on the one trigger was set for...

Ohh, that makes sense, thanks!

[Performa01]

Performa01:
Did Siglent otimized the ERES in the meantime? Or are they planning to? You mentioned in your review that it is a low priority task but it would still be a great thing to get somehow some more bits. Or whatever was possible to optimize.
If you would happen to have some spare time, to explain what would be possible actually, it would be great to know! 

They did: the first DSO with a 16-bit display interface was the SDS2000X Plus, so it could take advantage not only on the Avg. and ERES functions, but also its 10-bit acquisition mode.

It's been a long time that I last did anything with an SDS1000X-E, but I'm afraid these cheap entry level machines did not get that update. Maybe it would require too many resources - after all it's quite some effort to widen the data path all the way from sample memory to the display from 8 to 16 bits...

[Neutrion]

Performa01:
Did Siglent otimized the ERES in the meantime? Or are they planning to? You mentioned in your review that it is a low priority task but it would still be a great thing to get somehow some more bits. Or whatever was possible to optimize.
If you would happen to have some spare time, to explain what would be possible actually, it would be great to know! 

They did: the first DSO with a 16-bit display interface was the SDS2000X Plus, so it could take advantage not only on the Avg. and ERES functions, but also its 10-bit acquisition mode.

It's been a long time that I last did anything with an SDS1000X-E, but I'm afraid these cheap entry level machines did not get that update. Maybe it would require too many resources - after all it's quite some effort to widen the data path all the way from sample memory to the display from 8 to 16 bits...

But would that be possible with the current hardware with the x-e scopes? Because when you mentioned the possible optimization, I suppose you didn't mean any HW modification.
I know that there are now the HD scopes aviable, but in the cheap segment that limited 1-2 extra bit would still be world beater, and way more useful because of the low noise frontend than what other scopes could do with similar processors. (And the 1000 HD series have such a low sample rate, that I would not consider it being a full step up in every aspect from the x-e's.)

[2N3055]

Performa01:
Did Siglent otimized the ERES in the meantime? Or are they planning to? You mentioned in your review that it is a low priority task but it would still be a great thing to get somehow some more bits. Or whatever was possible to optimize.
If you would happen to have some spare time, to explain what would be possible actually, it would be great to know! 

They did: the first DSO with a 16-bit display interface was the SDS2000X Plus, so it could take advantage not only on the Avg. and ERES functions, but also its 10-bit acquisition mode.

It's been a long time that I last did anything with an SDS1000X-E, but I'm afraid these cheap entry level machines did not get that update. Maybe it would require too many resources - after all it's quite some effort to widen the data path all the way from sample memory to the display from 8 to 16 bits...

But would that be possible with the current hardware with the x-e scopes? Because when you mentioned the possible optimization, I suppose you didn't mean any HW modification.
I know that there are now the HD scopes aviable, but in the cheap segment that limited 1-2 extra bit would still be world beater, and way more useful because of the low noise frontend than what other scopes could do with similar processors. (And the 1000 HD series have such a low sample rate, that I would not consider it being a full step up in every aspect from the x-e's.)

When he said "resources" would not be enough he didn't mean human effort at manufacturer, but capabilities of hardware of the scope....
As in: not enough memory, CPU, FGA fabric etc....

And what you mean by "did Siglent optimize ERES ?" question. In what way do you mean that?

[Performa01]

Performa01:
Did Siglent otimized the ERES in the meantime? Or are they planning to? You mentioned in your review that it is a low priority task but it would still be a great thing to get somehow some more bits. Or whatever was possible to optimize.
If you would happen to have some spare time, to explain what would be possible actually, it would be great to know! 

They did: the first DSO with a 16-bit display interface was the SDS2000X Plus, so it could take advantage not only on the Avg. and ERES functions, but also its 10-bit acquisition mode.

It's been a long time that I last did anything with an SDS1000X-E, but I'm afraid these cheap entry level machines did not get that update. Maybe it would require too many resources - after all it's quite some effort to widen the data path all the way from sample memory to the display from 8 to 16 bits...

But would that be possible with the current hardware with the x-e scopes? Because when you mentioned the possible optimization, I suppose you didn't mean any HW modification.
I know that there are now the HD scopes aviable, but in the cheap segment that limited 1-2 extra bit would still be world beater, and way more useful because of the low noise frontend than what other scopes could do with similar processors. (And the 1000 HD series have such a low sample rate, that I would not consider it being a full step up in every aspect from the x-e's.)

I do not know it particularly for the SDS1000X-E series. But from my tests, I can tell that the HW-resources are limited. Originally, even XY-mode was done in software - only later Siglent have managed to cram this functionality into the FPGA, speedint it up substantially but giving up on supporting channels 3 and 4 for XY at the same time.

Siglent often let advanced features (like Bode Plot II)  trickle down to the entry level models, or even implemented new features (like the data recorder) - as long as it was possible, i.e. sufficient HW resources. The fact that we did not get it up to now is indicative that the SDS1000X-E HW isn't up for the task to handle 16-bit data throughout.

[Neutrion]

When he said "resources" would not be enough he didn't mean human effort at manufacturer, but capabilities of hardware of the scope....
As in: not enough memory, CPU, FGA fabric etc....

And what you mean by "did Siglent optimize ERES ?" question. In what way do you mean that?

In his review at the eres section at the end Performa01 wrote this:
"Beware that for the time being, Eres mode provides no true resolution enhancement. This is mainly
because of the display interface which is still limited to 8 bits. Siglent have promised to change this at
some point in the future, but this is treated as a low priority task, so it may take a while."

So I supposed it is possible to do something here with the current HW.

I do not know it particularly for the SDS1000X-E series. But from my tests, I can tell that the HW-resources are limited. Originally, even XY-mode was done in software - only later Siglent have managed to cram this functionality into the FPGA, speedint it up substantially but giving up on supporting channels 3 and 4 for XY at the same time.

Siglent often let advanced features (like Bode Plot II)  trickle down to the entry level models, or even implemented new features (like the data recorder) - as long as it was possible, i.e. sufficient HW resources. The fact that we did not get it up to now is indicative that the SDS1000X-E HW isn't up for the task to handle 16-bit data throughout.

So it might would be possible but with very slow display update, or some similar constraint? Because even in that case in some situation it is still better than nothing.

[tautech]

Sounding X-E owners out with our customer feature request before presenting it to Siglent:

Single shot trigger
When trigger conditions are met and the scope goes to STOP mode short buzzer activation is enabled with a new user ON/OFF buzzer capability.
Buzzer activation is for a period different to all other notifications, say 2s.

Buzzer control needs be added into the Trigger menu.

Reason: to provide audible alert to users when single shot trigger conditions are met.

Worthy feature request ?

[BillyO]

I've never had a case where I might need that, but I can see if I was waiting a considerable time for an event to occur it might be handy.  What other features are they trying to decide between, or is this all by itself?

[tautech]

I've never had a case where I might need that, but I can see if I was waiting a considerable time for an event to occur it might be handy.  What other features are they trying to decide between, or is this all by itself?

By itself Bill in that it's a single and new feature request planned to put in front of Siglent.
Looking for support and discussion before I do.

Now get this, our customer 70+ years and with first DSO put this to me in a phone chat this morning.
Whom said you can't teach an old dog new tricks.....and he thinks he found a bug too !
Waiting for his detailed report by email.......

[Neutrion]

Sounding X-E owners out with our customer feature request before presenting it to Siglent:

Single shot trigger
When trigger conditions are met and the scope goes to STOP mode short buzzer activation is enabled with a new user ON/OFF buzzer capability.
Buzzer activation is for a period different to all other notifications, say 2s.

Buzzer control needs be added into the Trigger menu.

Reason: to provide audible alert to users when single shot trigger conditions are met.

Worthy feature request ?

It can be useful sometimes, why not? But the 2 second long "buzzing" maybe a tad long and annoying. Is there a chance to have options on it? (Like 10th, half, one and two second.)

And if we are talking about requests,I would like to mention again the ERES discussion above. So if having the extra bits only would mean some very low response time or similar thing (not sure what but keen to know) only in that particular mode, it would be still great to have sometimes.
The 10 bit mode in the 2000plus, have of course longer mem to work with, but in the 1000X-E there are also not visible bit parts out of the display, not sure whether those could be utilized somehow, even with the normal sampling speed/BW.

[Martin72]

Today I was too lazy to take my HD for measuring, so I took the 1104X-E...Boy, it´s loud...
I took this for a simple measurement, let it display the pk-pk voltage of ch1 and ch2.
Ch1 is 10x and 1V/div.
Look at the signal on ch1, it´s slightly more than 3 divisions = 3V ( it´s a 3.2...3.3V source).
And it measures the double ? Why?
Ch2 is "correct" displaying the value.

Martin

[BillyO]

Today I was too lazy to take my HD for measuring, so I took the 1104X-E...Boy, it´s loud...
I took this for a simple measurement, let it display the pk-pk voltage of ch1 and ch2.
Ch1 is 10x and 1V/div.
Look at the signal on ch1, it´s slightly more than 3 divisions = 3V ( it´s a 3.2...3.3V source).
And it measures the double ? Why?
Ch2 is "correct" displaying the value.

Martin

Expand it out to see if there are any very short spikes (overshoot/undershoot).

[Martin72]

Hi Billy,

First thanks and you´re right.
Following for the ones who will have the same "problem":
I did expand it and saw nothing..
Playing with timebase and so on...nothing changed.
Then I add minimum and maximum....Aha...a negative voltage will be measured but I can´t see it...Couldn´t be so.
Finally I switched off channel 2 and then bingo...
Ch2 "covered" the negative spike of ch1...
But respect to the little 1104 for "finding" it.

Martin

[three_jeeps]

Web Interface not working properly - guidance please?
I've connected my sds1104x-e (new, out of box)  to my LAN and the scope acquired a network address successfully.  Go to my browser, set the scope address and get the webserver - all OK. When I go to Instrument Control only the scope display is shown, the control buttons & knobs are missing.
I discovered the little icon arrow to display the controls and when I select it, the display is huge and the only way to see the entire scope (display + control panel) is to have the browser in full screen mode.   There does not seem to be a zoom out capability.


Any suggestions on how to zoom out and resize the display + control panel so I don't have to use full screen all the time??
If helpful: Sw Ver: 6.1.37R8,  OS version 8.3
Thanks
J

[BillyO]

Web Interface not working properly - guidance please?
I've connected my sds1104x-e (new, out of box)  to my LAN and the scope acquired a network address successfully.  Go to my browser, set the scope address and get the webserver - all OK. When I go to Instrument Control only the scope display is shown, the control buttons & knobs are missing.  I repeated the connection using the TPLink WiFI dongle with the same results.  Tried 3 different browsers with both Wifi and LAN connections, no joy.
IP addresses for both types of connections are static. 

The only thing I can think of is port forwarding but I've been casting around the net and have found nothing discussed, one way or another.  The user manual is useless on this point.

Any suggestions on how to make this work correctly?
If helpful: Sw Ver: 6.1.37R8,  OS version 8.3
Thanks
J

Look at the far upper right of the scope display.  The should be a little grey/silver box with and arrow head pointing right.  Click on that.

[three_jeeps]

Thanks, I *finally* found that but the display + control panel is huge...no way to zoom out?