SDS800X HD Bug Reports + Firmware

[2N3055]

I just want to post my top list about the bugs/issues i found. Feel free to discuss (in a professional way, with the right questions), but also feel free to ignore this, and please consider only asking questions about bugs that you are really interested in!
I will (try) to keep this, the links, and the linked posts updated.

(Issue number is my number, and not the number of bugs/issues.)

Issue 1: Ghost traces: (They do trigger the mask test!)
https://www.eevblog.com/forum/testgear/sds800x-hd-featureimprovment-disscusions/msg5470300/#msg5470300

Issue 2: Cursor measures screenborder
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5766285/#msg5766285

Issue 3: Moving gate A, changes gate B unintentionally.
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5523604/#msg5523604

Issue 4: Changing sample rate changes timebase:
Decreasing sample rate (fixed setting) changes timebase, but does not set the timebase back to the previous value, after setting the sample rate to its previous setting.
(1us/div goes up to 500ms/div, but only back to 5ms/div)

Issue 5: Persistence traces dissappear when selecting only a channel to display its scale:
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5760405/#msg5760405

Issue 61: Measurement measures wrong edge:
https://www.eevblog.com/forum/testgear/sds800x-hd-featureimprovment-disscusions/msg5470300/#msg5470300

Issue 63: Measurement on less points than acquired (presumably), is not indicated.
https://www.eevblog.com/forum/testgear/sds800x-hd-bug-reports-firmware/msg5527156/#msg5527156

Issue 24: Trigger interval decreases when sample rate is decreased.
ALSO in sequence mode!

(Yes, i spend too much time with this scope.)

And all of it is something nobody else managed to reproduce...

You spend too much time blaming other people for your problems..

[eTobey]

Changing the source channel of a reference waveform changes the source of ALL reference channels:
First i thought it might be wanted, but then i was curions about how it would behave, when changing it via SCPI (it cant be changed). But  since there are specific querys for every reference to get the source of it (in the programming manual - RTFM), it more looks like a bug. Full of features. Full of subtle bugs that lead to confusion...

Description:
Open at least 2 reference waveforms, and change the source of one. Observe, how the source of the other reference has changed as well.

[AndyC_772]

I don't know about the others, but #2 (Cursor measures screenborder) is absolutely reproducible, and it borders on being a show-stopper for me.

If it's a deliberate design decision then it's an idiotic one, there's no possible use case for wanting to measure time between a point on a waveform and the edge of the screen. It simply doesn't mean anything.

Fortunately my local distributor (Telonic - UK) does understand this and has, I'm assured, reported it back to Siglent as a bug.

[tautech]

I don't know about the others, but #2 (Cursor measures screenborder) is absolutely reproducible, and it borders on being a show-stopper for me.

If it's a deliberate design decision then it's an idiotic one, there's no possible use case for wanting to measure time between a point on a waveform and the edge of the screen. It simply doesn't mean anything.

Fortunately my local distributor (Telonic - UK) does understand this and has, I'm assured, reported it back to Siglent as a bug.

Experiment with Zoom mode. 

[AndyC_772]

Sorry, but that's akin to Apple's famous "you're holding it wrong" comment.

I know you sell these scopes, and have a vested interest in trying to control the narrative surrounding them if you can, but I don't understand the defensiveness. Either the cursor feature is deliberate, or it's a bug.

If it's deliberate, then there must be a use case for which it's the best design choice - but nobody has been able to suggest what that case might be.

Or, it's a bug, in which case it just needs reporting and fixing.

[tautech]

Sorry, but that's akin to Apple's famous "you're holding it wrong" comment.

I know you sell these scopes, and have a vested interest in trying to control the narrative surrounding them if you can, but I don't understand the defensiveness. Either the cursor feature is deliberate, or it's a bug.

If it's deliberate, then there must be a use case for which it's the best design choice - but nobody has been able to suggest what that case might be.

Or, it's a bug, in which case it just needs reporting and fixing.

Take a step back and give this some thought.

Why would you expect measurement of something that's not within the display ?
The display border is the hard limitation !

There are other ways to accomplish such measurements. 

[AndyC_772]

[Edit] I'm just going to facepalm and log off now.

[tautech]

The data is there in memory. Turning the horizontal position control pans across the entire stored waveform, which is of course much wider than just the screen. The screen is just a window onto what's stored in memory - that's what deep memory is for!

The cursors can be positioned precisely on said waveform, and their positions remain fixed and correct if (but only if) they happen to be on screen. There is no reason to arbitrarily clip the cursor position to the edge of the display, and there is a good reason to simply keep each one at the time it's been carefully and deliberately set to.

This suggestion that the edge of the screen is somehow significant just boggles my mind. Other scopes manage this perfectly fine.

The display buffer from where measurements are taken is NOT memory.

Use this scope more to understand this......
Engage Statistics then change a scope setting....everything returns to zero to begin counting again.

[BillyO]

I just want to post my top list about the bugs/issues i found. Feel free to discuss (in a professional way, with the right questions).
I will (try) to keep this, the links, and the linked posts updated.

You have already admitted elsewhere on this site that you are new to all this.  Isn't it just possible this is a case of "I really don't understand how this works"  rather than "Nothing works on this scope!"

The strange thing to me that points to the former is that there are lots and lots of folks on here that have been using scopes for decades.  All sorts of scope, from different eras and different manufacturers yet these very experienced people do not see your "BUGS!!" as problems.  Strange, isn't it?

Maybe you should create a new thread called "Help eTobey understand  " and ask the admins to move all your posts over there.

[2N3055]

I don't know about the others, but #2 (Cursor measures screenborder) is absolutely reproducible, and it borders on being a show-stopper for me.

If it's a deliberate design decision then it's an idiotic one, there's no possible use case for wanting to measure time between a point on a waveform and the edge of the screen. It simply doesn't mean anything.

Fortunately my local distributor (Telonic - UK) does understand this and has, I'm assured, reported it back to Siglent as a bug.

It is a deliberate design decision.
And to me it is weird to measure some two random positions that are somewhere in the buffer that I cannot see.
How do you position cursor in a right place?
Just use zoom, it will show you complete event and you can also move across complete event and also position it accurately.

Scope just work that way and there is a technique that works. Learn it. Or not.

But it is not a bug. Bug is a violation of what scope is supposed to do based on how it is supposed to work. Like when you say you have a Bode plot but it does not work.

We already have few users that use word "bug" as a tool that they try to use to blackmail manufacturers to change their products to their own private, selfish likings...
Like "this stupid scope decodes only 5000 packets, that is a bug, it should decode 50000" because I want that.
Or people that say "it is stupid design decision that 800 series scopes don't use 12" screens with 4K resolution"..

All devices are made as they are. All of them will have specific idiosyncrasies, that will shape how they are supposed to be used.
And all of them will need some adjustment of user to device, to get best results.

Adapt and overcome. Or bitch and suffer... Users choice..

[shapirus]

We already have few users that use word "bug" as a tool that they try to use to blackmail manufacturers to change their products to their own private, selfish likings...
Like "this stupid scope decodes only 5000 packets, that is a bug, it should decode 50000" because I want that.
Or people that say "it is stupid design decision that 800 series scopes don't use 12" screens with 4K resolution"..

Second statement is technically correct, because it doesn't say that it's a bug. Everyone has the right to consider a certain design decision stupid, of course that'll be a subjective evaluation.

[2N3055]

I don't know about the others, but #2 (Cursor measures screenborder) is absolutely reproducible, and it borders on being a show-stopper for me.

If it's a deliberate design decision then it's an idiotic one, there's no possible use case for wanting to measure time between a point on a waveform and the edge of the screen. It simply doesn't mean anything.

Fortunately my local distributor (Telonic - UK) does understand this and has, I'm assured, reported it back to Siglent as a bug.

It is a deliberate design decision.
And to me it is weird to measure some two random positions that are somewhere in the buffer that I cannot see.
How do you position cursor in a right place?
Just use zoom, it will show you complete event and you can also move across complete event and also position it accurately.

Scope just work that way and there is a technique that works. Learn it. Or not.

But it is not a bug. Bug is a violation of what scope is supposed to do based on how it is supposed to work. Like when you say you have a Bode plot but it does not work.
....................................................................

Just a data point so people can see how sometimes some requests are just random...

I plugged in my Keysight MSO-X3104T.

I captured something (1MHz 100 period burst, repetition rate 1 ms).
It was Single captured at 200µs/div.

Cursors were set at 0 s (trigger point) and 1ms (second burst).

Then timebase was changed in such way that cursor X2 was outside screen. Original data is still in scope memory.
Measurements for X2 cursors disappeared, together with delta measurements.
If I then change horizontal position in such way that cursor X1 is also outside the screen, then all cursor measurements are gone.
If I reset position and timebase to original ones, cursor data gets back.

So for cursor measurements it definitely uses screen as a boundary where measurements are done. Nothing outside the screen is taken into account. despite being in the scope memory.
Guess what, same is for measurements.

And it makes sense. Scope is an instrument where we are looking into waveforms on screen and want measurements for what we are looking at.
We don't want for measurements to take into account unknown data outside the screen. We literally don't know what is that we don't see.

To achieve looking at the detail while still measuring long event, on Keysight you use zoom in a same way as on Siglent.

I think Keysight missed the memo they are stupid too....

[mawyatt]

So for cursor measurements it definitely uses screen as a boundary where measurements are done. Nothing outside the screen is taken into account. despite being in the scope memory.
Guess what, same is for measurements.

And it makes sense. Scope is an instrument where we are looking into waveforms on screen and want measurements for what we are looking at.
We don't want for measurements to take into account unknown data outside the screen. We literally don't know what is that we don't see.

The old analog scopes didn't have cursors that went beyond the displayed screen and the DSO must behave this way also, as there are so many use cases where having the cursors working outside the visible display area could cause significant misunderstandings by the user. Same goes for waveform measurements, almost all use cases need to show the results of what's on screen.

One must remember the DSO is an instrument to "Show (Read Display) the User what's Happening with the Waveform Under Study", not "Blind" instruments like a DMM or Frequency Counter. Even with "Measurements" this generally must represent what's on the visible display.

Happy New Year,

Best

[2N3055]

Happy New Year,

Best

Happy New Year !!

[eTobey]

The display buffer from where measurements are taken is NOT memory.

And bringing out that information took 3 posts?

Even if so, then the cursors should not show wrong measurements. Yes, the measurement to the screenborder is correct, but i am usually not interested in screenborders for measurement. 
Its just the same as here (among other occasions i found):
youtu.be/8iE28oGtayQ?t=216


But this seems a bit wrong to me:
I consider a display buffer to be as long as the display is wide, but then measurements couldnt be that accurate. Its more like a general "measure and display buffer"?

I cant find nothing to a buffer in the manual... But this would be a very important information! I guess this is also the reason, why decoding fails at bigger scales.

[electr_peter]

I don't know about the others, but #2 (Cursor measures screenborder) is absolutely reproducible, and it borders on being a show-stopper for me.

If it's a deliberate design decision then it's an idiotic one, there's no possible use case for wanting to measure time between a point on a waveform and the edge of the screen. It simply doesn't mean anything.

Fortunately my local distributor (Telonic - UK) does understand this and has, I'm assured, reported it back to Siglent as a bug.

It is a deliberate design decision.

Yes, 100% this. Different scopes implement cursors differently (there are many ways to skin the cat) and there are no bugs as such.

Scenario - in capture buffer there are 2 short (~1-10us duration) events (pulses) A&B separated by 1-10ms and we want to measure (without doing data export to csv or manual calculation):
a) time difference between A&B accurately
b) some measure, say average slope dy/dx from A to B
For time difference, "manual" cursors can be used. For slope, "track waveform" cursors can be used. I think everyone will agree that with 100us-500us/div display both time difference and slope estimates would be inaccurate with just cursors.

Let's see how 3 different scopes deal with this task:

• Micsig STO1104E Plus - horizontal cursors cannot go beyond the screen no matter what (zoom or no zoom). Thus, when A&B events are not clearly visible on display, cursors cannot be set accurately (limited resolution), time difference is inaccurate and slope is inaccurate.
• Siglent SDS824X HD - horizontal cursors cannot be put outside the display (similar to Micsig) unless you enter zoom mode. In zoom mode, "manual" horizontal cursors can set accurately anywhere in capture memory on A&B to measure time difference. However, accurate slope measurement is not possible because both "tracked" cursors must be be inside zoomed window, thus you cannot set both cursors on A&B at once.
• Keysight MSO-X3104T - manual horizontal cursors can be put anywhere in capture memory (i.e. outside display) both in zoom (like Siglent) and regular pan/scroll mode (unlike Siglent). Thus, time difference A-B is always accurate. "track waveform" cursors work on display data only (similar to Siglent) and slope measurement will be less accurate.

And to me it is weird to measure some two random positions that are somewhere in the buffer that I cannot see. How do you position cursor in a right place? Just use zoom, it will show you complete event and you can also move across complete event and also position it accurately.

Keysight and Siglent treats display/memory/zoom thing differently. IMO, Keysight implementation of cursors is more flexible, while Siglent forces you to always use zoom mode (some find this annoying, some find this fine, YMMW). This is related to zoom-in/zoom-out design thing, but let's leave it for other topic.
Also, it depends if only time position is measured (then KS has a slight edge), or measure (e.g., slope) is calculated with cursors (then KS & Siglent are equivalent). Micsig cursors are hopeless (maybe Micsig improved newer models )

[electr_peter]

I plugged in my Keysight MSO-X3104T.
I captured something (1MHz 100 period burst, repetition rate 1 ms).
It was Single captured at 200µs/div.
Cursors were set at 0 s (trigger point) and 1ms (second burst).
Then timebase was changed in such way that cursor X2 was outside screen. Original data is still in scope memory.
Measurements for X2 cursors disappeared, together with delta measurements.
If I then change horizontal position in such way that cursor X1 is also outside the screen, then all cursor measurements are gone.
If I reset position and timebase to original ones, cursor data gets back.

So for cursor measurements it definitely uses screen as a boundary where measurements are done. Nothing outside the screen is taken into account. despite being in the scope memory.
Guess what, same is for measurements.

Tested your example, results depend on what is "cursor measurements" and what type of cursors are used.

For regular cursors and time offsets, KS always shows time offsets of X1/X2 and delta X independent of whether cursors are on display or outside display.
For "track waveform" cursors, time offsets X1/X2 and delta X are always showed properly, but values of waveform at X1 or X2 are only valid when X1 cursor is on display or X2 is on display. For calculation of a slope, both cursors should be on display to show a result.

So all depends on what equipment is capable and what user needs to measure.

[eTobey]

Anyway the position of the cursor is known, so it would be no problem whatsover, to show the right values. Showing misleading values in a field that is complicated enough, is quite a bad thing, and just on the level of the cheapest scope available.   

[Furna]

[...]
Showing fake values
[...]

It doesn't show fake values ... it simply shows a different thing than the one you desperately want.

[2N3055]

• Keysight MSO-X3104T - manual horizontal cursors can be put anywhere in capture memory (i.e. outside display) both in zoom (like Siglent) and regular pan/scroll mode (unlike Siglent). Thus, time difference A-B is always accurate. "track waveform" cursors work on display data only (similar to Siglent) and slope measurement will be less accurate.

And to me it is weird to measure some two random positions that are somewhere in the buffer that I cannot see. How do you position cursor in a right place? Just use zoom, it will show you complete event and you can also move across complete event and also position it accurately.

Keysight and Siglent treats display/memory/zoom thing differently. IMO, Keysight implementation of cursors is more flexible, while Siglent forces you to always use zoom mode (some find this annoying, some find this fine, YMMW). This is related to zoom-in/zoom-out design thing, but let's leave it for other topic.
Also, it depends if only time position is measured (then KS has a slight edge), or measure (e.g., slope) is calculated with cursors (then KS & Siglent are equivalent). Micsig cursors are hopeless (maybe Micsig improved newer models )

Did you not read my post?

I have MSOX3104T.

It does exactly the same thing as  Siglent.. Once cursor is out of screen, cursor value is not show anymore....
You have to use ZOOM same as Siglent.

For standard X cursors, they are where you put them... They don't measure anything, they are just there. As are Siglent ones. If they are outside the visible screen they have no useful application then.  Siglent ones will return where you put them as soon as you return timebase to where you can see that position, same as Keysight ones....

Both work equally well for me.[/list]

[eTobey]

I throroughly set up labels of the references, but then the scope was like "You can set up anything you want, but this is what you get ..." 



If i would be a beta tester, i would say: "I cant see all the labels. That surely needs improvement". I wonder, if actually this issue has been reported, but prioities are somewhere else.

Yes its just a small issue, but its one of MANY. If you examine the screenshot carefully, you see another issue, which is quite obvious.

[tautech]

I throroughly set up labels of the references, but then the scope was like "You can set up anything you want, but this is what you get ..." 

(Attachment Link)

If i would be a beta tester, i would say: "I cant see all the labels. That surely needs improvement". I wonder, if actually this issue has been reported, but prioities are somewhere else.

Yes its just a small issue, but its one of MANY. If you examine the screenshot carefully, you see another issue, which is quite obvious.

Is addressed in next firmware.
Support movable channel label

[eTobey]

Is addressed in next firmware.
Support movable channel label

It would be good, if they would automatically appear (of course unstacked), where the trace appeares first. And when they are at it: Do the same with the "C1" labels (not the level indicators), by the means of just separating them.

[tautech]

Is addressed in next firmware.
Support movable channel label

It would be good, if they would automatically appear, where the trace appeares first. And when they are at it: Do the same with the "C1" labels (not the level indicators), by the means of just separating them.

Who doesn't separate their channels and in doing so channel labels will separated be too.....if they're set to ON.

[eTobey]

Is addressed in next firmware.
Support movable channel label

It would be good, if they would automatically appear, where the trace appeares first. And when they are at it: Do the same with the "C1" labels (not the level indicators), by the means of just separating them.

Who doesn't separate their channels and in doing so channel labels will separated be too.....if they're set to ON.

Everybody, that wants to compare levels efficiently, or with a single screenshot. Because when one wants to compare levels, it hase to be done like this, because only the scale of one channel is visible!