Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[roberthh]

Maybe a bug, maybe something one simply should not do

 When the resolution is set to 10 bit, serial decoding fails.

Edit: It might be that the issue is also related to a menu vs. actual setting inconsistence. Using the same test set-up again and deliberately adjusting the threshold for SCL and SDA again, there is not difference between 8 and 10 bit mode. I can however set the threshold for SDA to an value, where 8 bit decodes fine, but 10 bit not. That value is here about 2.5V.

[Martin72]

Interesting, I'll recreate this later in the evening with my STB-3 board.

[roberthh]

I should add: sds2104x+, Firmware 1.3.5R10

Here an example of a wrong decode. The trigger on address 0x28 works right, and the decoded information should be: Address 0x28 read, first data byte 0x20

[roberthh]

sds2104x+, Firmware 1.3.5R10

topic: unwieldy settings setup of trigger mode parameters

In all trigger modes which requuire the entry of levels, two menus have to be openened separately:
a) the trigger menu, b) a little window for the vertical levels.
This seems confusing to me, and in fact it required some time to find the level settings window (I had to read the instructions). It would be consistent to have all settings for a certain trigger mode in one dialog element.

Note: I recall faintly that there was a level setting in the trigger menu with the previous firmware 1.3.5R7.

[Cobra514]

SPI Decode Issue (or idiosyncrasy):

Hoping this is on the user side of the screen, as they say....

I can only get a reliable SPI decode when the timescale is above a particular threshold (appears decode-size dependent).
I need to be >=100uS/div (for 8 ,16 bit) and >=200uS/div (for 32-bit) for reliable decoding.

Configuration:

SDS2104X Plus
Firmware 1.3.5R10
8-bit (or 10-bit) Vertical Scale mode
CS, CLK, MOSI thresholds all set to 2.0V (MISO inactive)
Analog channels used for inputs
CLK rising edge, CS active low
Signals driven directly from Total Phase SPI generator (no PCB or other circuits involved)
Issue repeated with:
  8-bit, 16-bit, and 32-bit messages
  Every possible acquisition length
  Both SPI triggering and edge triggering (on CS)

Failure always occurs on last nibble or byte.
Also appears to fail with odd values and not even values.
It is not intermittent.  It either works every time or fails every time, based on timescale.

The only valid decodes are with such large timescales that the signals are visually impossible to recognize.

My inexpensive "brand" name scope at work does not have this decode limitation.

Now, if this is really the scope (and not me), maybe somebody could explain the technical reason why this is so.

It is very counter-intuitive actually.  I would expect more horizontal resolution to equate to a better measurement.
Most definitely (at least vertically), I've seen more accurate automatic voltage measurements with greater vertical resolution (on other 'scopes anyway).

Maybe the worst aspect of this "issue?" is that the scope does not alert one of the bad data.  If it is simply a function of timescale, then the firmware should not present any data at all - which would just serve to mislead the user.  It should display a message that decoding is not possible at the current resolution (or something to that effect).

This is not for a hobby and I'm terrified of taking bad data for a customer.

I've attached good and bad plots at 8, 16, and 32-bit decodes (those ending in "00" are bad).
Just look at the last byte decoded in each - and look at the timescale.

Anybody else see this?  Please tell me this is not normal operation and that I have a setting incorrect.
I don't see any mention in the user manual of timescale dependent decoding (but I may have overlooked it - in which case my apologies for posting).

[roberthh]

Same scope type & firmware version.

I can confirm that I get no decoding wit a timebase < 200µs/div. What I did not see are error in the last byte. I tested with a BME680 sensor, at which due to sampling noise the value of the last byte varies, so I have odd and even numbers.
It triggers fine on e.g. MOSI data, but it shows not the decoded data. If I capture at say 200µs/div and then expand the view to lets say 50µs/div, the data is shown fine.
It's independent from the aquisition memory size. And decodes well  both in 8 and 10 bit mode.
If it decodes data, I can expand it in the zoom window, and that works most of the time.

[roberthh]

It seems it depends on the CS transition to be in the capture window. If that is given, I can go to smaller time base values, like 50µs/div shown below.

Edit: Using clk-timeout as CS, I can go beyond that limit. See the second screen shot.

Edit2: Nevertheless, it looks as if the oscilloscope is not the preferred instrument for logic protocols. That's more the job for a logic analyzer. Even a 10 USD Saleae clone is easier to use, left alone the size of the probes.

[kev_in_cornwall]

I just recieved this scope and am checking out its features (still learnng) but I wanted to check whether this is a bug or a fault . I get large gliches on channels 1 and 2 when i use 10 bit mode (channels 3 and 4 doesn't seem to suffer). It's fine in 8 bit mode and I've looked and it does iindeed increase the resolution (based on zooming in as discribed in another part of this forum (which is awesome. by the way)). The rise time also seems slow and suggests a 100kHz (not 100MHz) BW but I guess that is just the scope probe test waveform.
[ Specified attachment is not available ]
(I seem to be having problems attaching images and can't get a preview so appologies if these images are rubbish (I'm new to this forum).
SW is 1.3.5R7 so maybe I been to update?

[roberthh]

The spikes should not be there. It looks like a fault. The 1KHz probe calibration output has a slow rise/fall time. You can use the AWG for faster signals. You should have a 30 days test period with a new device.

b.t.w.: Which firmware version is installed? I do not expect the spikes to be firmware related, but the information might help. You get that via Utility->System Setting->System Status.

[TK]

10-bit mode is a software enhancement, so if it is working in 8-bit mode, it should be bug in the firmware, but I did not see anyone reporting a similar effect...

or it could be a bad chunk of memory that is used in 10-bit mode filtering

[kev_in_cornwall]

Thanks for the rapid response. FW is 1.3.5R7.
I guessed it was probably a fault as it only affects Ch1 and 2.
I tries the AWG and the TC now looks more like 30ns.
I guess I'll have to send it back

[kev_in_cornwall]

Maybe I should try updating the firmware first?
 I couldn't find any reference to 1.3.5R7 (only R5 amd R10) so maybe nobody else uses it (so  might be an unreported bug)? Upgrading FW won't invalidate any warranty (in the UK) will it?

[roberthh]

I had version 1.3.5R7 initially too, but not such spikes. But updating the FW should not hurt.

[TK]

Thanks for the rapid response. FW is 1.3.5R7.
I guessed it was probably a fault as it only affects Ch1 and 2.
I tries the AWG and the TC now looks more like 30ns.
I guess I'll have to send it back

Yes, it looks like a faulty unit

[kev_in_cornwall]

Upgrading the FW to R10 made no difference. still faulty

[thinkfat]

Last resort: try running a self calibration. But I don't expect it to help much.

[tautech]

Upgrading the FW to R10 made no difference. still faulty

Don't discount it could be local RFI.
Seen this before with other new Siglent DSO's and customers have contacted me believing their scope was faulty.
10 bit res will only exacerbate the problem.
Try a BNC cable connection for better shielding to the AWG and see if the spikes are still present at the same amplitude and if they are start turning OFF any possible local RFI sources. Anything SMPS based should be considered prime candidates as the culprit. Even LED ceiling downlights can be an issue or a phone charger in another room.
Happy hunting Sherlock ! 

[roberthh]

Upgrading the FW to R10 made no difference. still faulty

Don't discount it could be local RFI.

The poster changed to CH3/4, where he did not see the issue. Still he could have changed something else in between.

[Orange]

If this would be RFI, the spikes would appear centered around the trace, which they are not.

If you have an other scope check the calibration signal....

Almost sure a faulty unit, I had similar faults on a Rigol DS2000.

[roberthh]

SDS2104x+, 1.3.5R10

Continued my testing with UART decoding. As with SPI it is very inconvenient, that for a serial trigger all settings (RX, TX, baud rate, ..) has to be repeated. But that may be unavoidable, since trigger is independent from decoding.(yes: copy to trigger!)

What seems strange is the display of the decoded data. if:

- some decoded data is displayed and
- then a new event captures new data

a) The decoded date shown is erratic. It shows some unrelated decoding. b) if I move the horizontal position, decoding disappears, until c) I push the trigger setup and then the decode button again.  see the three screenshots for the three steps.

This looks like a bug.

Edit: At step c) pushing a channel button also forces the display of decoded data

[tautech]

Upgrading the FW to R10 made no difference. still faulty

Don't discount it could be local RFI.

The poster changed to CH3/4, where he did not see the issue. Still he could have changed something else in between.

Yes exactly and as Kev has just got this scope he is still finding his way around it.
When in doubt press the Default button and reset the scope then if the problem persists investigate why.
Sometimes the probes reference lead forms the perfect RF loop and it need be removed to check it has no influence on the displayed waveform....easy if only connected to the 1 KHz probe compensation output.
Screenshots to USB using the Print button with menus visible are required to see what settings might be can always help us.

[tautech]

roberthh
Look at your trigger positions WRT the zoom window.
Align these and I believe your results will be better.

Hint
Press the H Pos control to set trigger to 0s

[roberthh]

roberthh
Look at your trigger positions WRT the zoom window.
Align these and I believe your results will be better.

Hint
Press the H Pos control to set trigger to 0s

Kind of. After triggering, it shows indeed the data at the trigger position. If the Zoom window is at the trigger position, not only the zero position, the trigger data point is indeed at the  trigger point, but it does very often not match the signal pattern. And when I move the zoom window, the decoded data completely disappears. Until I push for instance a channel button.

Below is a screen shot immediately after the trigger. Trigger point is at 0 for both windows. The trigger is at the trigger data (0x34), but the decoded data and the trace do not match. Therefore is added the cursors. It shows that the trace data block is 22 characters (115200 baud, 8 + 1+ 1 bit), the decoded data string has 17 bytes.

I can't help but for me this inconsistency in display is at least confusing.

[tautech]

roberthh
Look at your trigger positions WRT the zoom window.
Align these and I believe your results will be better.

Hint
Press the H Pos control to set trigger to 0s

Kind of. After triggering, it shows indeed the data at the trigger position. If the Zoom window is at the trigger position, not only the zero position, the trigger data point is indeed at the  trigger point, but it does very often not match the signal pattern. And when I move the zoom window, the decoded data completely disappears. Until I push for instance a channel button.

Below is a screen shot immediately after the trigger. Trigger point is at 0 for both windows. The trigger is at the trigger data (0x34), but the decoded data and the trace do not match. Therefore is added the cursors. It shows that the trace data block is 22 characters (115200 baud, 8 + 1+ 1 bit), the decoded data string has 17 bytes.

I can't help but for me this inconsistency in display is at least confusing.

Much better. 
See where H Pos pointer in unzoomed window is after the start of the packet which is consistent with the UART trigger setting. If the selected UART trigger bit doesn't match the zoom window H Pos trigger position bit then indeed it is a bug. Magnify the zoomed window further for confirmation of the result.

[roberthh]

See where H Pos pointer in unzoomed window is after the start of the packet which is consistent with the UART trigger setting. If the selected UART trigger bit doesn't match the zoom window H Pos trigger position bit then indeed it is a bug. Magnify the zoomed window further for confirmation of the result.

Not really. The data it triggers on is not at the start of the packet. And the data at the trigger point there is indeed the intended data. But the trace and the decoded data do not match. It's just that the final screen update of the decoded data is missing. As soon as I expand the zoom or push e.g. a track button, the decoded data is updated and displayed fine. Another example below.