SDS800X HD - Issue disscusions - is it me, or the scope?

[2N3055]

I have setup a qualified trigger that does not trigger at all on a 100mv/div scale. The edge trigger does trigger on this signal down to 5mv. Signal is from ~0 - 2.7V

Let's see, analyse and think:

At 100mv/div full scale is ± 400mV.
Signal is 2.7V P-P, but if it is not centered on the screen with offset it has 2.7 V peak value.

That means that signal is 3-6,5x larger than dynamic range of scope. You are overdriving inputs and ADC.
For scope functions to work properly signal has to fit on screen of the scope.
That is basic thing.

Since Edge trigger only looks for a slope in vicinity (close to) trigger level it usually works even in this situation of completely overdriven signal.

But other trigger types (or any other function of the scope to that matter) that relies on state, and previous states, it might not work.  If it has no valid data.
It might work but it doesn't have to.

That being said, on my scope, it seems to (miraculously) work.

I start wondering if my scope hase some issues itself, but then many other issues were confirmed by others...

What was also confirmed by many others are many false alarms and errors you made and then blamed scope . That is why we say a methodical approach is needed and good detailed explanations are needed.

For instance, you NEVER write what FW you are running at the time you encountered something that is suspicious behaviour or bug.

So in few weeks from now, when stuff is fixed nobody in the world will know if all the stuff you reported is still suspicious or that was some old initial FW that is not relevant anymore.

Like I said before but it fell on deaf ears.
You can stop writing about bugs, looking for them, or investigate them at this moment.
You are wasting your time (and ours if we decide to read).
There is imminent FW release being tested, as we speak.

Wait for a bit until new FW comes out.  Then start first with all the stuff that was reported in release notes that will come with it, then all the stuff that was reported and you don't see them in release notes.

This is my advice to you. You don't have to listen, of course.

[tautech]

Let's see, analyse and think: ............

Wait for a bit until new FW comes out.  Then start first with all the stuff that was reported in release notes that will come with it, then all the stuff that was reported and you don't see them in release notes.

This is my advice to you. You don't have to listen, of course.

We are blue in the face from telling such, so much so I think ears must be just painted on.

[ebastler]

What was also confirmed by many others are many false alarms and errors you made and then blamed scope . That is why we say a methodical approach is needed and good detailed explanations are needed.

For instance, you NEVER write what FW you are running at the time you encountered something that is suspicious behaviour or bug.

So in few weeks from now, when stuff is fixed nobody in the world will know if all the stuff you reported is still suspicious or that was some old initial FW that is not relevant anymore.

Like I said before but it fell on deaf ears.
You can stop writing about bugs, looking for them, or investigate them at this moment.
You are wasting your time (and ours if we decide to read).
There is imminent FW release being tested, as we speak.

Wait for a bit until new FW comes out.  Then start first with all the stuff that was reported in release notes that will come with it, then all the stuff that was reported and you don't see them in release notes.

This is my advice to you. You don't have to listen, of course.

You are too harsh with eTobey, I think. Yes, there have been "false alerts", but a surprising number of actual bug findings too. And this thread is titled "is it me or the scope?", so what's wrong about bringing up potential issues where one is confused and wants to ask others for help to clarify the situation?

Firmware version is 1.1.3.3. throughout -- what else would it be for mere mortal users?   But I do agree with you that a bit more detail about the signals and settings would be helpful in many reports.

Regarding the upcoming firmware, you are quite bullish in your advice that "it's likely to change everything, you can stop looking for bugs for the time being". Have you tried with the two three most recent bugs (#14 to #16) which eTobey found over the past two days, and which electronics hobbyist has added in the SDS800X HD bug thread?

[ebastler]

We are blue in the face from telling such, so much so I think ears must be just painted on.

How is this type of comment supposed to be helpful? It's only stoking up controversy. Please bite your tongue and refrain from posting such insults.

[electronics hobbyist]

Yes, we only discuss technical issues. If the problem is easy to reproduce, the manufacturer can solve the problem quickly. @eTobey You can attach two pictures, one picture where we can see the complete signal, and the other picture when there is a problem.  And explain the configuration of qualified, can also use pictures.

[2N3055]

What was also confirmed by many others are many false alarms and errors you made and then blamed scope . That is why we say a methodical approach is needed and good detailed explanations are needed.

For instance, you NEVER write what FW you are running at the time you encountered something that is suspicious behaviour or bug.

So in few weeks from now, when stuff is fixed nobody in the world will know if all the stuff you reported is still suspicious or that was some old initial FW that is not relevant anymore.

Like I said before but it fell on deaf ears.
You can stop writing about bugs, looking for them, or investigate them at this moment.
You are wasting your time (and ours if we decide to read).
There is imminent FW release being tested, as we speak.

Wait for a bit until new FW comes out.  Then start first with all the stuff that was reported in release notes that will come with it, then all the stuff that was reported and you don't see them in release notes.

This is my advice to you. You don't have to listen, of course.

You are too harsh with eTobey, I think. Yes, there have been "false alerts", but a surprising number of actual bug findings too. And this thread is titled "is it me or the scope?", so what's wrong about bringing up potential issues where one is confused and wants to ask others for help to clarify the situation?

Firmware version is 1.1.3.3. throughout -- what elese would it be for mere mortal users?   But I do agree with you that a bit more detail about the signals and settings would be helpful in many reports.

Regarding the upcoming firmware, you are quite bullish in your advice that "it's likely to change everything, you can stop looking for bugs for the time being". Have you tried with the two most recent bugs (#14 and #15) which eTobey found over the past two days, and which electronics hobbyist has added in the SDS800X HD bug thread?

I'm not to harsh with anybody. Just stating facts. 530+ posts and 4-5 bugs from him.
He had more repetitive reports and false alarms than real findings..
We have a proverb that loosely translated means "you have to bake bread before it is good to eat..".

I'm not saying all he says is wrong because he did find some real problems but he is very eager to write something so he's trigger happy. That is why I still read and answer to his posts. I took seriously (on probation) his apology post, so I approach him as someone a bit clumsy instead of malevolent.

But wrong is still wrong, facts are still facts.

As for being bullish, I'am not. Just saying.
Why waste time for detailed review of Golf8  2 weeks before Golf9 is released? It is a waste of time.

Yes, when new FW is released, list of all of reported bugs is formally invalid.

It remains as a reminder, a shortcut, what to check again in a new version.

In which case it is either not existent anymore (fixed), not fixed (not addressed, deferred for later), fixed partially (it was addressed but fix was only partially successful), or was fixed but new defects were introduced (it was addressed but by mistake some other error was introduced).

In addition to that maybe new defects could be introduced ( by regresion or in new functions added in meantime).

So any bug list lives only in that FW revision.

Any bugs in old FW found postmortem after new FW is available are either fixed already (sometimes one bug triggers a revision of part of design, that reveals some errors in common parts, so one fix fixes several bugs).  Bugs that were not fixed will be discovered in new one anyways.
So doing a work twice instead of once.

I'm not at liberty to discuss details, but can help friendly people with generalized advice not to waste their time.
As I said, not ordering anyone anything. A friendly notice.. If you don't care, your prerogative.

Best,

[ebastler]

530+ posts and 4-5 bugs from him.

Why distort the facts? The list of acknowledged bugs has 9 entries attributed to eTobey, and two more attributed to me (since I established the details) but originally found by him. It seems that these findings have provided useful input to Siglent for the upcoming firmware release.

I think we have a working set of threads now -- one for bugs, one for feature/improvement suggestions, and the present one for discussing unexpected observations which may or may not point to a bug. If we manage to use them as intended, I don't see a fundamental problem.

Any bugs in old FW found postmortem after new FW is available are either fixed already (sometimes one bug triggers a revision of part of design, that reveals some errors in common parts, so one fix fixes several bugs).  Bugs that were not fixed will be discovered in new one anyways.

So can we assume that the new firmware's scope is frozen, and that any bugs discovered now will not be addressed in the upcoming release?

That would be mixed news: It suggests that the new firmware release is imminent, after final beta testing. But it also suggests that further bugs might only be fixed significantly later -- I would guess that the Siglent software team needs to focus on other products for a while before they turn their attention back to the SDS800 series.

In any case, it's clear that a cut has to be made at some point. Siglent can't keep adding additional bug fixes and pushing out the firmware release date forever. I am looking forward to the new release!

[eTobey]

How about keeping the noise down, and trying to be professional? 
I dont see anything to discuss here at the moment. Except if you have found an issue that i have missed...

[eTobey]

Some new issue:
While the issue with the mask loading, that changes the settings of channels, is not a big problem (easy to undo - but still annoying), when triying to use the mask feature on the zoom window, i then was not able to get the zoom window back to the state where it was before setting up the mask (see picture - green signal). Also setting up the mask is very hard, since the zoomed view of the waveform dissappears then.

Its really nice to have many nice features, but i would have rather have "a few" features, that work flawless.

[ebastler]

when triying to use the mask feature on the zoom window, i then was not able to get the zoom window back to the state where it was before setting up the mask (see picture).

But what problem does the picture show?? 

The arrow in the picture points to the trigger threshold, which you were apparently setting at the time of taking the screenshot. That seems like normal behaviour? And what does the name of the picture ("would help to see channel") refer to? I see waveforms for CH1 and CH3, and I see the details in the respective info boxes -- so what is missing?

When posting such findings, please do take a step back before you click "Post", and review whether the description is sufficient for a reader who has not been sitting in front of your scope with you.

Edit: Did you attach the wrong picture maybe?

[eTobey]

when triying to use the mask feature on the zoom window, i then was not able to get the zoom window back to the state where it was before setting up the mask (see picture).

Edit: Did you attach the wrong picture maybe?

Yes it was indeed the wrong picture. Since i had the same issues again with a strong indication, that this is not just an issue, i moved over to the bug topic.

Yes, i have to take a step back and analyse more and not ton confuse others. But at the same time i would like to encourage others to be a bit more playful in trying things out that i wrote. Because some might find what i missed. As 2N3055 might have found nothing wrong, he could have tried other things too, like creating a mask by hand, which is probably the difference with this issue. (This sentence has truely only an objective meaning)

[2N3055]

when triying to use the mask feature on the zoom window, i then was not able to get the zoom window back to the state where it was before setting up the mask (see picture).

Edit: Did you attach the wrong picture maybe?

Yes it was indeed the wrong picture. Since i had the same issues again with a strong indication, that this is not just an issue, i moved over to the bug topic.

Yes, i have to take a step back and analyse more and not ton confuse others. But at the same time i would like to encourage others to be a bit more playful in trying things out that i wrote. Because some might find what i missed. As 2N3055 might have found nothing wrong, he could have tried other things too, like creating a mask by hand, which is probably the difference with this issue. (This sentence has truely only an objective meaning)

Can I ask why are you multiple posting same issues in several different topics?
You started now double spamming.

And as people already said to you multiple times: I'm not going to put in ANY work because you are too lazy to do proper write up.

With bugs you don't accuse and let other side defend themselves.

It is quite the opposite: Unless you can prove a repeatable method to replicate error and demonstrate it step by step,then probably you made a mistake or misunderstand grossly how things work.

[ebastler]

Can I ask why are you multiple posting same issues in several different topics?

That seems like the natural course of things if a topic starts in the "is it me or the scope" thread, and then is confirmed to be a bug. In that case it should be raised in the bug thread next, I'd say.

Whether we are at that stage regarding the mask & zoom issue is another matter. eTobey might have tried something "pathological" of no practical relevance -- although even in that case it would still be nice if the scope did not get confused regarding the time window it shows in zoom mode.

But in any case, I would have preferred to use the present thread to clarify whether "it's the scope or me", before potentially moving things over to the bug thread. It's not good style to ignore the request for clarification here, but post in another thread in parallel.

[eTobey]

when triying to use the mask feature on the zoom window, i then was not able to get the zoom window back to the state where it was before setting up the mask (see picture).

Edit: Did you attach the wrong picture maybe?

Yes it was indeed the wrong picture. Since i had the same issues again with a strong indication, that this is not just an issue, i moved over to the bug topic.

Yes, i have to take a step back and analyse more and not ton confuse others. But at the same time i would like to encourage others to be a bit more playful in trying things out that i wrote. Because some might find what i missed. As 2N3055 might have found nothing wrong, he could have tried other things too, like creating a mask by hand, which is probably the difference with this issue. (This sentence has truely only an objective meaning)

Can I ask why are you multiple posting same issues in several different topics?
You started now double spamming.

And as people already said to you multiple times: I'm not going to put in ANY work because you are too lazy to do proper write up.

With bugs you don't accuse and let other side defend themselves.

It is quite the opposite: Unless you can prove a repeatable method to replicate error and demonstrate it step by step,then probably you made a mistake or misunderstand grossly how things work.

This whole page is full of noise that contributes to nothing but aggravation. Would you please stop this? Get over it! I dont double post, i moved OVER. People suggested having different topics... 

BTW:
What we just did together was actually teamwork, as we discovered quite an important detail. Think about this!

[eTobey]

Another issue:
When missing the "+" or the button for resetting statistics, the measure menu opens. It is already too hard, to hit the resetting button. 
 

See picture.

[eTobey]

New issue:
Wrong measurement:
X2 of the measurement should be, where the arrow points to (last rising edge). When i move gate "B" just a tiny bit to the left, then the measurement is rendered invalid. The measurement is also rendered invalid, if i put the upper level of C3 above high level of C4 (slightly under it).

To me it looks like a bug.

[eTobey]

When loading the reference waveform, it does not scale, if i have a different timebase.
Is there a way to achieve this? The manual did not give details about this, only vertical adjustment.

[tautech]

Some hints of proper use of Reference waveforms are here:
https://www.eevblog.com/forum/testgear/probe-into-probes-whats-up/msg4678768/#msg4678768

[eTobey]

Some hints of proper use of Reference waveforms are here:
https://www.eevblog.com/forum/testgear/probe-into-probes-whats-up/msg4678768/#msg4678768

I cant find the hints that would help me. Maybe wrong link?

[gitm]

This is a follow up to post I made in this thread about 2 months back, IIRC.

I had just assembled a test board with the same rail splitter design and was using the SDS800X again to measure noise, droop, and current limiting.  First day was fine, no issues and powered off normally.  Other than turning on the scope and pressing the Auto Setup button, there was, literally, no manual configuration whatsoever.   No FFTs were run, attenuation was 1X.  However, today — the very next day -- the DC offset issue returned immediately on power up.

With nothing attached to any input and the scope fresh from power up, the 100mV/ vertical showed ~ -21mV DC offset.  That -21mV offset scaled linearly with the vertical setting (-44mV @ 200mV/, -107.7mv @ 500mV/, and -218.6mV @ 1.00V/).  For the “PICS or it didn’t happen” incredulous amongst you, I’ve attached the screenshots.

So it is a real problem, and it’s associated to auto setup and saving state calibration data at power off.  Now before anyone gets it all twisted, I purposely DID NOT update to the latest firmware yet just to see if the problem ever returned.  And now we know.  I’ll update to the latest firmware and report back when I build my next board design.

Self cal did remove the offset (for the most part, it’s showing ~ 1mV offset on 1.00V/ scale, but uV’s below that).

Has anyone else turned on their SDS800X to find a fixed DC offset (~700 mV) on CH1 and CH1 only?

This has happened twice to mine immediately at power-on on two different days.  CH2, CH3, and CH4 all had no offset (i.e. 0) as expected.  Nothing was connected to any of the inputs.  Selecting the vertical position rotor and pushing to return CH1 trace to 0 had no effect and in the CH1 “box” (bottom left of screen) showed, IIRC, 0 mV.  Scrolling the position down to place the trace on 0 would then show a negative offset.  Setting the vertical position explicitly in the CH1 position entry box to 0 would position the trace to 0+~700mV. 

Shutdown, disconnect power, reboot, and set to default had no effect (something bad stored?). In each case to get the scope back to powering on with DC offset of 0, I set the scope to default and then ran selfcal after warming up for 30 minutes.  Once the selfcal completed the offset was now at 0.   I rebooted the scope and the offset was still gone.  Rebooting a few more times and the offset did not reappear.  So I continued my actual testing for the day.

After a couple of days not being used, I turned on the scope yesterday and the offset returned for a second time.  Same investigation and results as the above paragraph.  I then again continued my actual testing for the day.

I turned the SDS800X on today and the offset remains at 0.   

I will say that “testing for the day” was looking at a 5V/12V rail-splitter with DC coupling and using the vertical position offsets at -2.5V and -6.0V to see what ripple, noise, and droop were present under differing loads, 10X attenuation and 10mV/, and running FFTs.  Maybe this is related.  But then it didn’t reappear this morning. 

Anyone else seen this?

[tautech]

This is a follow up to post I made in this thread about 2 months back, IIRC.

I had just assembled a test board with the same rail splitter design and was using the SDS800X again to measure noise, droop, and current limiting.  First day was fine, no issues and powered off normally.  Other than turning on the scope and pressing the Auto Setup button, there was, literally, no manual configuration whatsoever.   No FFTs were run, attenuation was 1X.  However, today — the very next day -- the DC offset issue returned immediately on power up.

With nothing attached to any input and the scope fresh from power up, the 100mV/ vertical showed ~ -21mV DC offset.  That -21mV offset scaled linearly with the vertical setting (-44mV @ 200mV/, -107.7mv @ 500mV/, and -218.6mV @ 1.00V/).  For the “PICS or it didn’t happen” incredulous amongst you, I’ve attached the screenshots.

So it is a real problem, and it’s associated to auto setup and saving state calibration data at power off.  Now before anyone gets it all twisted, I purposely DID NOT update to the latest firmware yet just to see if the problem ever returned.  And now we know.  I’ll update to the latest firmware and report back when I build my next board design.

Please install very recently released firmware, retest and report back.