Siglent Technical Support join in EEVblog

[tautech]

The best approach is to save setups, then load them before starting work.  Unless you have an excellent memory there are bound to be things set differently than you recall, so starting from a 'clean slate' with a known state is the safest approach.

boggis, there's alternatives to saving setups with the X-E.
The factory Default setup can be now user defined to current settings or returned to factory as you wish.
Some explanation here:
https://www.eevblog.com/forum/testgear/new-siglent-sds1000x-e-oscilloscope-based-on-xilinx-zynq-7000-soc-architecture/msg1196101/#msg1196101

[boggis the cat]

Yes, I am aware of that.  It makes more sense to me to save setups for particular usage, but if you always want to start with particular settings it is useful to be able to modify the 'default' setup.

This instrument does seem fairly well thought out in this area.

It would be useful to have more control over the display of measurements (particularly the text size being quite small); and it seems dubious to present known-bad measurements, due to out of range issues -- I can't think of a reason to do this.  If anything, it would be sensible to go the other way and use the frequency counter to warn users of potential aliasing issues with timebase and signal frequency mismatches.

I haven't had much time fiddling with this as yet, though, and hadn't come across most of the bugs reported so far.

[klaff]

Blank zoom bug on SDS1202X-E.

Here I captured both channels at 2 ms/div, 7 Mpts, and zoomed in. At zoom of 500 ns/div the zoom window goes blank. It is fine at longer or shorter zoom settings, only blank at this one, and only in the first and last 25% of the capture.

[klaff]

SDS1202X-E Cursor Track Mode in Zoom bug
Cursors used in track mode in the zoom window use the main timebase scale, not the zoom scale, giving very incorrect values. Compare the deltaX for each of the attached.

[tautech]

Blank zoom bug on SDS1202X-E.

Here I captured both channels at 2 ms/div, 7 Mpts, and zoomed in. At zoom of 500 ns/div the zoom window goes blank. It is fine at longer or shorter zoom settings, only blank at this one, and only in the first and last 25% of the capture.

Only when Stop'ed right ? No problem when free running ?

[tautech]

SDS1202X-E Cursor Track Mode in Zoom bug
Cursors used in track mode in the zoom window use the main timebase scale, not the zoom scale, giving very incorrect values. Compare the deltaX for each of the attached.

Look at the Cursor colours, you have one image set for Ch 1 cursors and the other image set for Ch 2.
Kindly check them again please.

[klaff]

Blank zoom bug on SDS1202X-E.

Here I captured both channels at 2 ms/div, 7 Mpts, and zoomed in. At zoom of 500 ns/div the zoom window goes blank. It is fine at longer or shorter zoom settings, only blank at this one, and only in the first and last 25% of the capture.

Only when Stop'ed right ? No problem when free running ?

Yes, only when stopped. I hadn't noticed that as I was using Single mode for this work.

[klaff]

SDS1202X-E Cursor Track Mode in Zoom bug
Cursors used in track mode in the zoom window use the main timebase scale, not the zoom scale, giving very incorrect values. Compare the deltaX for each of the attached.

Look at the Cursor colours, you have one image set for Ch 1 cursors and the other image set for Ch 2.
Kindly check them again please.

It is true that I had one example on Ch1 and one example on Ch2 but I don't understand how that matters. When the cursors are in track mode, the deltaX calculation (and also the frequency or 1/deltaX) is wrong, regardless of which channel is selected.  Look at the screen copy showing Track Mode (...E31.png). The cursors are set to almost 5 divisions apart at 100ns/div and so the deltaX should be a little less than 500 ns. Instead, it shows 9.360 ms, which would be correct if the cursors were almost 5 divisions apart on the main timebase view of 2 ms/div. I showed the manual mode cursor screen shot just to show the approximately correct value of 468 ns.  Does that make sense?  Thanks.

[boggis the cat]

Probable bug

Setup to recreate:

• No signal applied
• [Default]
• Ch 1 [V/div] to 500 uV/div (must choose a low setting, as hard to notice at 2 mV/div and greater)
• [Acquire] > Average 16
• [Measure] > Clear, then add Type > Mean
• [Menu On/Off]
• [Clear Sweeps]

Note 'spike' at zero on timebase

[Trigger Setup]
Change from Edge, back through to Edge (not important what is selected, or even if a different trigger type is selected)


Spurious 'spike' is now gone.


Question about this behaviour

After pressing [Run/Stop] to halt acquisition, the display seems to change to the last waveform, rather than maintain the averaged waveform.


While Running


After Stop

This seems to not be what you'd want to occur.  Is this a bug?

[tautech]

Memo from Siglent tech support tells me they have looked at and are addressing items identified in replies
#699, 703, 704, and 709. Plus some others in other threads that have been reported also.
Thanks all, let's hope you can get a quick fix for these bugs.

The word is soon, sorry I can't be more precise as to when.

[boggis the cat]

Easier way to reproduce this bug.

• Must allow warm up.
• Bug only seems to affect Ch 1.

Probable bug

Setup to recreate:

• No signal applied
• [Default]
• Ch 1 [V/div] to 500 uV/div (must choose a low setting, as hard to notice at 2 mV/div and greater)
• Set Horizontal to 5 ns/div

Note the odd trace behaviour at zero on timebase

Press [Trigger Setup] (no other action needed).


Trace now as expected.

Edit:

Both channels, same settings, offset +2 and -2 div for clarity.

Ch 2 not affected, Ch1 has the bug.

Press the [Trigger Setup] button...

Then the bug scuttles away.  (Yes, I'm impatient.  Now you know why Rigol 'scopes drive me nuts.)

Edit 2:

Behaviour is linked to the trigger channel.  If you change the trigger channel to 2 then the bug appears on the channel 2 trace, and channel 1 looks correct.

[klaff]

Memo from Siglent tech support tells me they have looked at and are addressing items identified in replies
#699, 703, 704, and 709. Plus some others in other threads that have been reported also.
Thanks all, let's hope you can get a quick fix for these bugs.

The word is soon, sorry I can't be more precise as to when.

Awesome! Do you know if they are fixing the issue in which serial decoding isn't done for history frames other than the last?

[ebastler]

Easier way to reproduce this bug.

• Must allow warm up.
• Bug only seems to affect Ch 1.

Probable bug

Behaviour is linked to the trigger channel.  If you change the trigger channel to 2 then the bug appears on the channel 2 trace, and channel 1 looks correct.

Hi boggis, isn't that "bug" called "triggering"? 

You are looking at noise, and asking the scope to trigger at a positive edge of a certain level. So the scope will always show you traces which have a positive edge (and hence a little peak) at the position of the trigger time point. That's what is supposed to happen. Or did I misunderstand your description of the issue?

[boggis the cat]

Hi boggis, isn't that "bug" called "triggering"? 

You are looking at noise, and asking the scope to trigger at a positive edge of a certain level. So the scope will always show you traces which have a positive edge (and hence a little peak) at the position of the trigger time point. That's what is supposed to happen. Or did I misunderstand your description of the issue?

If this is the case, then I don't understand why simply 'waking up' the trigger fixes the issue.

This produces a discrepancy (small, but it is there) depending upon whether you have gone into the [Trigger Setup] menu or not.  Note that you don't have to actually change the trigger.

Edit:

Or breaks the correct behaviour, I suppose.  My thinking is that the noise shouldn't produce a slope like that shown up-thread.

This is the same signal in 'Dot' mode (shorter time base, at 2 ns/div):


Then after selecting the [Trigger Setup] then [Type Edge] (but not adjusting it):


Channel 1 or Channel 2 selected as trigger source:




So your explanation would be correct (maybe) if simply going into the trigger [Type] settings didn't cause the behaviour to suddenly change.  You can't get it to switch back, except through reloading the Default setup.

It just seems odd.  Does it not realise that there is no viable trigger until you enter the [Type] menu? 

Edit 2:

You can mess about with the false triggering, too.

Level at zero:


Level at 200 uV:


Level at -380 uV, falling:


[Type] touched, fun over:

 

[boggis the cat]

Another trigger bug (may already be known).

• Auto triger mode.

This is the signal:


Here it is at a shorter time base (roll mode off), rising edge trigger (as before):


Select falling edge, and it loses the plot...


...until you 'touch' the [Type] menu again

(Note that there is a short pulse in the middle, which is what it is correctly triggering on.)

Set it back to rising, loses the plot...


...until the [Type] menu gets a nudge.

[StillTrying]

Edit. Others have said the same, but after all this work I'll post it anyway!

I don't think boggis's Probable bug spike in Reply#709 is a bug. With 16X average on all the random noise would average to 0, except at the positive trigger position. Similar with the CH1 kink in Reply#711

On his STOPping of an averaging waveform Reply#709 the CML+ does something awkwardly similar on LongMem, in fact it doesn't stop on the last showning waveform it goes and gets another - while STOPped! which is not the one you wanted. Described here.

Reply#703 describes an X TB expansion not being part of the waveform, the CML+ can do that as well! either in Delay/Zoom TB mode or just an expansion of a STOPped waveform. It appears to be something to do with the X trigger position being well away from the center X position.

Just not to be left out it can also do the moving 0V marker when there's a lot of the waveform off the screen/out of range, Reply#693.. That might be normal (whatever that is) for such large overloads, 27Vpp on the 1V/Div. range. Probe and scope on X10 might help.

Deja vu.

[boggis the cat]

I don't think boggis's Probable bug spike in Reply#709 is a bug. With 16X average on all the random noise would average to 0, except at the positive trigger position. Similar with the CH1 kink in Reply#711

If this were the explanation, I don't see why just opening the trigger menu would make the trace change.

Refer to my 'easy method' to get this glitch / bug to appear.

[ebastler]

If this is the case, then I don't understand why simply 'waking up' the trigger fixes the issue.

This produces a discrepancy (small, but it is there) depending upon whether you have gone into the [Trigger Setup] menu or not.  Note that you don't have to actually change the trigger.

Edit:

Or breaks the correct behaviour, I suppose.  My thinking is that the noise shouldn't produce a slope like that shown up-thread.

In my view, the "bump" at the trigger position is actually the correct behavior. The triggering selects traces which have that bump, from the random input signal. Note that the trigger indicator in the upper left always shows "trigg'd" when the bump is visible-

When you enter trigger setup menu, something seems to change. The scope is no longer triggering; the indicator in the upper left shows "auto". No idea why that is the case, and that might indeed be a bug? Does the scope reset or change some trigger setting as soon as yo uenter the menu?

[boggis the cat]

In my view, the "bump" at the trigger position is actually the correct behavior. The triggering selects traces which have that bump, from the random input signal. Note that the trigger indicator in the upper left always shows "trigg'd" when the bump is visible-

I would expect it to not trigger consistently when in the noise floor, so it seems that the post-menu activation behaviour is 'correct'.  (Although it is debatable' I guess.)

This 'scope has a 'digital triggering system' (or words to that effect) -- i.e. the triggering is software driven -- so it is down to how it interprets the data stream as it processes it.

When you enter trigger setup menu, something seems to change. The scope is no longer triggering; the indicator in the upper left shows "auto". No idea why that is the case, and that might indeed be a bug? Does the scope reset or change some trigger setting as soon as yo uenter the menu?

That is my assumption.  The [Default] operation is not setting the trigger behaviour correctly, then when you open that menu it refreshes the trigger immediately and clears the problem.

So, if this is a bug, the work around is to open that menu, or otherwise 'activate' that code.

Once it is in that post-menu behaviour you can't get the initial behaviour back, so it seems that this is the true intended 'default' behaviour for the trigger.

[StillTrying]

I don't think boggis's Probable bug spike in Reply#709 is a bug. With 16X average on all the random noise would average to 0, except at the positive trigger position. Similar with the CH1 kink in Reply#711

If this were the explanation, I don't see why just opening the trigger menu would make the trace change.

I agree there seems to be something odd going on, but I don't think 400uV of noise at 30MHz would be the best place to test it, much of that noise will be from the scope itself and would vary a bit depending on its settings, and even depending on what's on the LCD.

Your Another trigger bug Reply#715 also looks odd, turning peak detect mode on should show at least some of the very narrow transitions. With such a low frequency, slow timebase speed, and large memory are you sure it's not sticking in the pre- and post- trigger data gathering times.

[ebastler]

I would expect it to not trigger consistently when in the noise floor, so it seems that the post-menu activation behaviour is 'correct'.  (Although it is debatable' I guess.)

We are not on the same page here. The scope should trigger "consistently" whenever the signal crosses the trigger threshold, going positive.

If you look at where the 0V trigger threshold is shown on the screen, and where the signal is, there seems to be a small negative offset on the signal. Hence, the trigger will "pick out" slightly higher, positive-going peaks on the signal. And the scope will consistently show these peaks at the horizontal trigger position.

[tautech]

Do you know if they are fixing the issue in which serial decoding isn't done for history frames other than the last?

AFAIK none of Siglent DSO's do this yet. I tried some time back with 1kX and 2kX of which the UI is very similar.

I'll ask if there are plans to implement it.

[boggis the cat]

I would expect it to not trigger consistently when in the noise floor, so it seems that the post-menu activation behaviour is 'correct'.  (Although it is debatable' I guess.)

We are not on the same page here. The scope should trigger "consistently" whenever the signal crosses the trigger threshold, going positive.

This seems to be what is happening, initially.  If you look at the 'dot' display screen-grabs, there is an obvious rectangle where negative signal is absent, to the right of the triggering point.

However, as soon as the trigger is refreshed, this behaviour changes.  Then it maintains this behaviour until you perform a reset (using the [Default] button, with factory settings in my case).

If you look at where the 0V trigger threshold is shown on the screen, and where the signal is, there seems to be a small negative offset on the signal. Hence, the trigger will "pick out" slightly higher, positive-going peaks on the signal. And the scope will consistently show these peaks at the horizontal trigger position.

But this isn't consistent.  As soon as the Trigger [Type] menu is opened (you needn't actually alter the setting, just open that menu) it changes behaviour, and maintains the new behaviour from then on.

The new behaviour is as I'd expect, where it doesn't trigger because there is nothing to trigger on.  (I haven't seen the initial behaviour in any 'scope before.  It is quite a common part of calibration practice to have a ground setting when testing the vertical gain accuracy, and generally with the averaging function set.  That is why the 'spike' got my attention -- it isn't normal to see that, and it certainly isn't normal for it to then vanish because the instrument changes it's mind...)

So either this is a 'feature' that disappears as soon as you go near the triggering, or it's a bug.  I think it's a bug.

(Not a major bug in itself -- but what does it point to in terms of how the 'scope is being initially set up?  I suspect there are errors in that process, leading to this initial behaviour.)

[StillTrying]

"The new behaviour is as I'd expect, where it doesn't trigger because there is nothing to trigger on."

How can you say there's nothing to trigger on when we can see the nearly 1 division high sine waves are still there, as in Replies #711 and #714. If you've carefully set the trigger level to get a view of the noise, you shouldn't loose that ability for no apparent reason.

I agree with ebastler that being able to trigger on the noise is the normal behavior, we've been doing it for years! after all, how do you know if it is random noise or a small signal, until you trigger on it.

Normal trigger is usually better than Auto trigger, although it's also a pain to use when the amplitudes are very low.

Quite unlikely random wild guess:
When opening the trig menu it checks it's on the 500uV range, realises an amplitude of 0.8 Div. is likely to be just noise, so doesn't bother triggering on anything less than 1 Div high.

Someone else with a SDS1202X-E ?  should try to reproduce it.

[kvd]

Hi,

I think I have found another small bug in the SDS1202X-E software. It is about using a tracking cursor on FFT in split screen mode:

1. Open up FFT in exclusive screen mode
2. create a cursor on the MATH channel
3. set the cursor mode to TRACK
4. on the MATH channel, set the display mode to ‘Split Screen’

Now you will see that the cursor on the FFT is still visible, but in the wrong window. It is visible in the signal trace in the top window, not in the FFT window on the bottom. See the attached picture.

Note that this only happens on a tracking cursor. On a manual (either X or Y) it works fine.

Koen

Software Version 5.1.3.8
FPGA version: 2017-03-21
Hardware version: 00-01
Product Type: SDS1202X-E