SDS800X HD Wanted Features

[eTobey]

Issue triggerlevel:
I find quite often, that the trigger level is set at 0V, after switching the trigger (channel, type - not quite sure exactly when), when i dont set it to this value.

Has anyone else observed this?

[2N3055]

Bug (IMHO): A user setting of a probe multiplier is not restored between sessions. It does remember what you used last when you select user, but then the vertical scaling is off until you change that.

I'd really like it to just remember and restore the setting between sessions as it's a pain to keep setting it for the hvdp channel.

I just tried.

Set Ch1 custom probe 1 to 11x and custom probe 2 to 13x.
Selected custom probe 2.
Rebooted.
Scope came back with custom probe 2 (13x) selected.
I also checked that C.P.1 was still 11x

Did that also for all 4 ch.
Worked well.
I couldn't reproduce.

You will need to better explain what your problem is.
Start with reporting FW version.
Then exactly explain steps to reproduce.

[Performa01]

enter the required delay in the time field of the Navigate function

But how often do we actually know the required delay? I guess not so often?

As long as you have an idea where you want to go, a quick look at the main window will tell you the required delay. But of course, this are mostly outdated methods, since a simple double-touch/click on the desired position in the main window is the fastest method to position the zoom window nowadays.

That lagging in the zoom function currently renders it kinda usless (its pretty bad sometimes). Have you encountered this behaviour?

I was inclined to say "absolutely no", but then actually experienced a moment of confusion this morning, when I played with the zoom. Positioning the zoom window worked fine, yet any signal change exhibited a pretty bad delay. The word "unusable" actually came to mind in this situation.

I was about filing an error report, but thankfully took a closer look and noticed that the scope did not trigger continuously. Only when I doublechecked the trigger settings, I realized that I had accidentally left the trigger holdoff at 30 seconds after some test yesterday evening.

After disabling holdoff I can state without any doubt that the zoom function absolutely doesn't exhibit any lag within the usual working conditions. Only at 100 Mpts record length (and a rather extreme zoom ratio of 2 million: 10 ms/div main, 5 ns/div zoom), there was some noticeable lag, yet far from “unusable”.

With a max. record length of 10 Mpts, there’s absolutely no lag. And even with 40 Mpts it is still barely noticeable. Only 100 Mpts slows down considerably.


Maybe I should take the opportunity to put a friendly reminder for all those who might not be aware:

No deep memory DSO/MSO will do its processing (math, measurements, protocol decoding…) on the full memory, even less so in this class of instruments. In any case, the data gets decimated internally when the record length exceeds a certain limit, and this is not reflected by the sample rate display (for the Siglent it’s in the Timebase tab).

An extreme example would be the once popular Rigol DS1000Z which only processed the screen buffer (~1000 points).

For the SDS800X HD, this limit is 10 Mpts. This means that the effective sample rate for measurements, decoding etc. drops to e.g. 1/10 of what is displayed in the Timebase tab whenever the max. record length of 100 Mpts is utilized. Not only does this compromise measurement accuracy and decoding results, but it also takes additional time for the decimation of the massive amount of data.

In order to be able to rely on the displayed sample rate for math, measurements and decoding, everyone should limit the “Max Mem Depth” (actually it should read “Max Rec Length”) to 10 Mpts in the Acquire menu, whenever accurate signal processing or analysis is to be accomplished. The longer memory settings are for less demanding tasks like just viewing and maybe old-fashioned cursor measurements.

And the ones who might try to tell me that this is a bug – or at least a bad thing – should go and buy a Keysight, LeCroy, R&S, Tek or any other serious brand DSO. Oh, wait, that might prove difficult – for the price of an SDS800X HD they might not even get a Can decoder license from these brands.

Just to put the performance of the SDS800X HD into perspective: for the very successful and well regarded Keysight Megazoom series, the before mentioned limit of undecimated analysis capability is 32 kpts (in some situations up to 62 kpts) – and even if they’d process the entire memory, this wouldn’t help either, since their max. record length cannot even come close to 10 Mpts.

[tautech]

Issue triggerlevel:
I find quite often, that the trigger level is set at 0V, after switching the trigger (channel, type - not quite sure exactly when), when i dont set it to this value.

Has anyone else observed this?

Of any oscilloscope their trigger and all its functionality is the scopes and your most powerful tool.
While trigger settings can be quite complex but for simple tasks it is made easy and fast with the Set to 50% feature.

No need to reinvent the wheel when convenient and adequate features already exist. 

[eTobey]

enter the required delay in the time field of the Navigate function

But how often do we actually know the required delay? I guess not so often?

As long as you have an idea where you want to go, a quick look at the main window will tell you the required delay. But of course, this are mostly outdated methods, since a simple double-touch/click on the desired position in the main window is the fastest method to position the zoom window nowadays.

Not quite yet: You have to tap the zoom window (the lower one) before you can fine adjust. It might not be always the case, but these are all those little things that will keep you busy, while sometimes investigating difficult issues. And yet another thing: the movement of the waveform if inverted, if you click on the lower window. Yet another little thing that can add to confusion.

(Yes, i only give negative feedback) 

Regarding the lag:
I have holdoff set to "none", and no acquiring is running. Yet, the problem still exists.

It seems that while moving the window, the whole (somewhat) memory is beeing tried to read, but that does take time. Its not a new technique to render less points while moving/zooming in software development. And that should be in place already. But i might be completely wrong, and this is of another source.

I would not consider to set my memory that low, because then zooming will become useless. Just like zooming in on a 640x480 picture...

[eTobey]

Of any oscilloscope their trigger and all its functionality is the scopes and your most powerful tool.
While trigger settings can be quite complex but for simple tasks it is made easy and fast with the Set to 50% feature.

No need to reinvent the wheel when convenient and adequate features already exist. 

It is just very annoying and confusing, when you would think that the trigger level stays at 50%, but it actually does not in some cases. Its already hard enough to investigate your prototype when it does stuff that you dont anticipate, but when your scope does this.... oh boy, that evening is getting late. 

[ebastler]

I find quite often, that the trigger level is set at 0V, after switching the trigger (channel, type - not quite sure exactly when), when i dont set it to this value.

Could you give a specific example of a sequence of steps which makes that happen? I just tried Edge and Pulse trigger in CH1 and CH2, alternating between these in all combinations. The trigger thresholds were always rembered; I did not see the threshold drop back to 0V.

[gf]

No deep memory DSO/MSO will do its processing (math, measurements, protocol decoding…) on the full memory, even less so in this class of instruments. In any case, the data gets decimated internally when the record length exceeds a certain limit, and this is not reflected by the sample rate display (for the Siglent it’s in the Timebase tab).

Do you mean decimated (with filtering), or just downsampled?

Does the same strategy also apply to the FFT sample rate?
IOW, is the FFT sample rate only lower than the acquisition sample rate if the record length is > 10Mpoints?

[Martin72]

Hi,
See pic below.

[Performa01]

Do you mean decimated (with filtering), or just downsampled?

I think that depends on the manufacturer. In case of Siglent it is just plain decimating (keeping every n-th sample).
I do not think that there is any filtering involved.
 

Does the same strategy also apply to the FFT sample rate?
IOW, is the FFT sample rate only lower than the acquisition sample rate if the record length is > 10Mpoints?

The FFT has its own max. length setting in the FFT menu. The maximum that can be set there for the SDS800X HD is 2 Mpts.

Because of the mismatch between binary FFT length, e.g. 2Mpts = 2097152 points versus decimal record length (2Mpts = 2000000 points), records up to 4 Mpts don't get decimated, but the FFT is calculated only on the first 52.43% of the record data.

If the record is even longer, then it gets decimated. Once again the classic keeping every n-th sample method.

[eTobey]

Could you give a specific example of a sequence of steps which makes that happen? I just tried Edge and Pulse trigger in CH1 and CH2, alternating between these in all combinations. The trigger thresholds were always rembered; I did not see the threshold drop back to 0V.

I did a lot of auto/normal/single triggers, also used the sequence feature. Zooming and moving the waveform.

Just a lot of things that makes it difficult to figure out when it happens.

I think i found the cause:
After restart (plug pulled), the trigger level for the "not activated" channel is not remembered. For edge and dropout at least!

[ebastler]

After restart (plug pulled), the trigger level for the "not activated" channel is not remembered. For edge and dropout at least!

Oh, you had not mentioned that rebooting was involved. Indeed, only the threshold for the trigger channel currently in use seems to be remembered (for edge trigger, the only one I just tried). The other thresholds are reset to 0V.

Very minor in my opinion, but yes, it is inconsistent with the behaviour of e.g. the serial triggers, which remember their threshold settings during a reboot even when they are not in use.

[eTobey]

Oh, you had not mentioned that rebooting was involved. Indeed, only the threshold for the trigger channel currently in use seems to be remembered (for edge trigger, the only one I just tried). The other thresholds are reset to 0V.

Very minor in my opinion, but yes, it is inconsistent with the behaviour of e.g. the serial triggers, which remember their threshold settings during a reboot even when they are not in use.

I think i wrote, that i was not quite sure when? I just realised and confirmed this cause. It would be nice, if other users could verify this, and investigate some more details of it.

This could be added to "suggestion" list No. 28. But to me its importance is big enough to put it on the bug list: I can live with things that are a bit inconvenient, but not things that will mess up your measures, just because there is a little detail that you had overlooked/forgot, because of inconsistency.

When the inconsistence (trigger levels are save for each channel on each trigger, but not the other settings) becomes inconsistent (some of the trigger levels are not saved during reboot/plug pulling), it can not get any more confusing. Even the confusion is confused

[newbrain]

In case of Siglent it is just plain decimating (keeping every n-th sample).
I do not think that there is any filtering involved.

As a simple demonstration that only decimation is applied, instead of full downsampling with filtering to remove aliasing, here are the FFTs for a 100 MHz signal generated by a TinySA.

In the first screenshot, the FFT is already downsampled by 4, from 2 GSa/s to 500MSa/s, to maintain the max 2²¹ FFT points over a 10 Mpts buffer; that is still OK to correctly capture, in addition to the fundamental at 100 MHz, also the second harmonic at 200 MHz.


In the second screenshot, the timebase has been doubled. The decimation is still 4 to 1, but since the scope sample rate is now 1 GSa/s, the FFT sample rate is now 250 MSa/s: note the 50 MHz signal, resulting from aliasing of the 200 MHz second harmonic.



If downsampling (e.g. FIR/decimate or CIC based) had been applied, the 50 MHz signal would not be there.

[hallkbrdz]

Bug (IMHO): A user setting of a probe multiplier is not restored between sessions. It does remember what you used last when you select user, but then the vertical scaling is off until you change that.

I'd really like it to just remember and restore the setting between sessions as it's a pain to keep setting it for the hvdp channel.

I just tried.

Set Ch1 custom probe 1 to 11x and custom probe 2 to 13x.
Selected custom probe 2.
Rebooted.
Scope came back with custom probe 2 (13x) selected.
I also checked that C.P.1 was still 11x

Did that also for all 4 ch.
Worked well.
I couldn't reproduce.

You will need to better explain what your problem is.
Start with reporting FW version.
Then exactly explain steps to reproduce.

Thank you. I hadn't realized there had been a firmware update released right after I set it up. 1.1.3.3 even specifically says as one of the 3 bugs fixed "Solve the problem that user probe coefficient are not restored after reboot".

Fixed now, and it even remembers the trigger point properly. 

[hallkbrdz]

Another suggestion:
When only one channel is activated, let the trigger source automatically be  this one. (Remember the old trigger source, and switch back to it, when the corresponding channel is activated again?).

I'll second that it should default to the active channel if only one is active.

I generally have probes on 1 (LV) and 3 (HV), and switch between the two with only one active at a time. Now why isn't it syncing... Oh yeah. 

[2N3055]

Another suggestion:
When only one channel is activated, let the trigger source automatically be  this one. (Remember the old trigger source, and switch back to it, when the corresponding channel is activated again?).

I'll second that it should default to the active channel if only one is active.

I generally have probes on 1 (LV) and 3 (HV), and switch between the two with only one active at a time. Now why isn't it syncing... Oh yeah. 

Automagical changing of trigger is BAD idea. !!!

This is not a toy. It is serious instrument.

What happens when you have channel hidden? You can have that option, you know?

Triggering system has to be DETERMINISTIC, meaning it has to follow strict rules that are always the same so no stupid corner cases exist.

I agree that it would be logical to remember all the settings in same manner. Exactly because that way it is easy to remember rules.

If we start adding rules like "It should always trigger from odd channel if more than one channel is enabled, but only in the afternoon , and when Mars is in retrograde"... God help us.

NO scope in the world does that and for a reason.

On Keysight it will keep triggering from a defined channel even if channel is "OFF". Because that is what user wanted, only necessary channels a shown on the screen to decrease clutter but you hid waveform from trigger channel because you don't care to look at it, you only want it as a trigger source.
Also on this particular scope you don't have external trigger input. But on all other ones from the family you do. Software platform is same and have to stay same for basic functions.
What would you guys want the scope with external trigger IN to automatically trigger on?

I keep repeating. There can not be automatic anything for triggers. Remembering previously set values I agree with. That is not bad idea and harms nobody. I personally check every value all the time so I don't care either way. So if it helps somebody and is good for everybody, that is good suggestion.

For automatic setup there is AUTO button. If something auto is needed, that is the button to load it on. Effort for auto stuff should end up there.

[eTobey]

What happens when you have channel hidden? You can have that option, you know?

Terminology... "active" is different from "hidden". If you consider this, then this question would not arise.

[ebastler]

Terminology... "active" is different from "hidden". If you consider this, then this question would not arise.

Terminology... an "active" channel, according to the user manual, is one which is selected to be controlled by the vertical front panel controls. What you probably meant is called "turning an channel on/off", both in the screen dialog and in the manual.

I can see both viewpoints here: (a) Why should one be able to set the scope to a non-working configuration? Or (b) It can be confusing if the scope auto-changes the trigger channel -- maybe the user's next planned step is to turn that channel on? If in doubt, keeping the existing behaviour should win in my opinion, because it has the added benefit of not breaking user habits.

[hallkbrdz]

Automagical changing of trigger is BAD idea. !!!

This is not a toy. It is serious instrument.

What happens when you have channel hidden? You can have that option, you know?

Isn't there is a big difference between hidden (not displayed) and OFF? Shouldn't OFF not do anything, where as hidden is ON but just not currently displayed?

Sorry that I'm just a hobbyist who doesn't have these other expensive scopes with this (as I see it) odd behavior, but I can't see any value in having the trigger stay with something that is OFF. The hobbyist / education market is what this model family is mainly aimed at - is it not?

Why not let the user decide if the trigger should follow only active / hidden (not off) channels? If there are more than one that is not OFF, of course you would need to select it manually (prompt on change?), no argument there. The excuse that one software model has to be used for everything and because other models have external triggers to negate this falls flat when you know the firmware is compiled for a certain model family and can simply use conditional flags to enable or disable certain code at compile time. That's certainly a normal practice for anything I've worked on.

I will agree to disagree with your point as it is from my different "user friendly" perspective.

[ebastler]

Why not let the user decide if the trigger should follow only active / hidden (not off) channels?

Please let's not introduce yet another option switch in the UI! Giving switchable options for every feature on which different people have different opinions may look like a great solution at first, to keep everyone happy. But it results in a software with a total mess of switches, with many undesirable effects:

- Users will need to find and understand all the settings.
- Users will struggle to communicate with each other about scope operation, since they are always assuming and talking about different modes.
- Multiple users sharing a scope will drive each other nuts with every-changing unexpected scope modes.
- Software testing will become a nightmare, having to test everything in all combinations of option settings.

So please, let's not go there...   

[2N3055]

Automagical changing of trigger is BAD idea. !!!

This is not a toy. It is serious instrument.

What happens when you have channel hidden? You can have that option, you know?

Isn't there is a big difference between hidden (not displayed) and OFF? Shouldn't OFF not do anything, where as hidden is ON but just not currently displayed?

Sorry that I'm just a hobbyist who doesn't have these other expensive scopes with this (as I see it) odd behavior, but I can't see any value in having the trigger stay with something that is OFF. The hobbyist / education market is what this model family is mainly aimed at - is it not?

Why not let the user decide if the trigger should follow only active / hidden (not off) channels? If there are more than one that is not OFF, of course you would need to select it manually (prompt on change?), no argument there. The excuse that one software model has to be used for everything and because other models have external triggers to negate this falls flat when you know the firmware is compiled for a certain model family and can simply use conditional flags to enable or disable certain code at compile time. That's certainly a normal practice for anything I've worked on.

I will agree to disagree with your point as it is from my different "user friendly" perspective.

I want world peace, no war, no hunger, decent life to all human beings and no cruelty to animals... 

But let us not confuse "user friendly" with "user lazy" perspective. 

Scope is sophisticated device. At one point you just have to learn how to use it.
I am afraid this is one of those "can you explain me Quantum physics, but simply". Err.. nooo?..

And also exactly because of users wanting it to be as simple to use it as possible, you have to stop adding features instead of adding dozens of new ones.
"As simple as possible but not simpler"
I'm trying to respectfully explain that fact that you or anybody else doesn't understand something is exactly what disqualifies you to have educated opinion about it.
It is not an insult, but statement of fact and logic. If you don't understand something how are you qualified to judge it?

Like I said few days ago, there is a huge irony in people demanding more new features because they find device hard to use because of so many features...

And to further explain why not, here are some explanations:
Software for these scopes is a platform. It is deliberately made to have least possible differences between models. "Smaller" models are subset of "larger" models. You erase features but what is common is really common. If you have Edge trigger, it is exactly the same on smallest and most powerful scope. And no manufacturer (ever, anywhere) will start adding features to smallest one that doesn't fit whole combination of models/types. Nor they will make smallest model to be significantly different in behaviour, ways of using or something like that.
That defeats the whole purpose of platform and erases all the benefits for users and manufacturer.

Why would anybody do that, it is lose-lose proposition.
If someone here gives some good idea, that is good, innovative idea that makes sense even on SDS6000, that has a chance of being considered for implementation. If someone does that, you bet Siglent will listen and consider it.
The reason that such a powerful scope is even possible at this price point is fact that it "borrows" from a large effort on a whole platform.

But thinking that manufacturers will just simply change the device just because "someone on the internet thinks it should be done xyz..." that is just ridiculous.
There are 7+billion people on the planet and every single one has an opinion. Mostly different one.
And that is fine.
I'm not trying to stop people to have opinion, or to deny their right to speak. It is just that they have to understand how realistic is what they want.

[eTobey]

- Users will need to find and understand all the settings.
- Users will struggle to communicate with each other about scope operation, since they are always assuming and talking about different modes.
- Multiple users sharing a scope will drive each other nuts with every-changing unexpected scope modes.
- Software testing will become a nightmare, having to test everything in all combinations of option settings.

Short valid arguments without much  .

I agree, but the trigger settings topic really needs a consistency.

[2N3055]

- Users will need to find and understand all the settings.
- Users will struggle to communicate with each other about scope operation, since they are always assuming and talking about different modes.
- Multiple users sharing a scope will drive each other nuts with every-changing unexpected scope modes.
- Software testing will become a nightmare, having to test everything in all combinations of option settings.

Short valid arguments without much  .

I agree, but the trigger settings topic really needs a consistency.

Hereby I apologize to you. I was under impression that you are deliberately provoking and insulting me, but I now realized you are a comedian...

Silly me. Sorry for not being nice to you.

[eTobey]

Isnt the auto trigger supposed to trigger "all the time" even when there are no changes in the level, when there is no holdoff set up?

My auto trigger does not even trigger when there are pulses... It does for a few moments, then freezes. The frequency reading is reading something.

Just realized, that the normal trigger does this too!

Short pulses every 2.5us and some longer in between.

When i move the trigger, it starts to work again for a few seconds.

WTF? This scope starts to get annoying! Only started to use it this morning. 

Edit:
Issue confirmed on pulse trigger mode too! Does happen with 3ms holdoff. The thresshold when it happens is about 885us holdoff.
It seems that there is a general holdoff bug, that is not only related to edge trigger???