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.
enter the required delay in the time field of the Navigate functionBut how often do we actually know the required delay? I guess not so often?
That lagging in the zoom function currently renders it kinda usless (its pretty bad sometimes). Have you encountered this behaviour?
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?
enter the required delay in the time field of the Navigate functionBut 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.
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.
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.
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?
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.
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.
In case of Siglent it is just plain decimating (keeping every n-th sample).
I do not think that there is any filtering involved.
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.
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?).
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.
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.
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?
Why not let the user decide if the trigger should follow only active / hidden (not off) channels?
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.
- 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.
- 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.