Oscilloscope Zoom Out Quirk

[tautech]

Now that the whole world has discovered the scope, his pros and cons, Siglent will release a corrective firmware.
Everyone will be amazed by Siglent, the speed of the brand to take into account demands from its customers and they will not be able to manufacture enough.

Where have you been ? 
They can't produce enough of these already as members here will attest by sourcing any they could find from all over the world.
It's price point, feature set and core specs identified it was to be a strong contender in the DSO market even before release.

The only worry is how any zoom out feature might be implemented for those having trouble to adapt the existing tool set as it could possible impact on the features already available. We don't want that.

Why i keep saying it should just be a saved option setting to make it run in the mode you want.. they already got a large established universe so that would make no sense to make it default

There's good reason why Run mode memory depth is managed, to retain high throughput and reduce blind time.

Stop/captures are different and to enable larger captures the memory needed may have to be reassigned from other features......and maybe to their detriment. 
Accommodations should only be made if datasheet specifications will not be impacted upon.

...................
Sorry I was too busy setting my scope mem depth manually and play with horizontal window all day long 
...............

Navigate can help with that. 

[Elasia]

There's good reason why Run mode memory depth is managed, to retain high throughput and reduce blind time.

Stop/captures are different and to enable larger captures the memory needed may have to be reassigned from other features......and maybe to their detriment. 
Accommodations should only be made if datasheet specifications will not be impacted upon.

Step back a minute and think about it... what is the scope doing when you are in split screen zoom mode? You have the zoom area at your target resolution and its buffering the rest of the data so you can zoom out and see more if you choose

Now... what is wanted is the ability to be at your target resolution but be able to change your timebase to zoom out but without actually 'activating' zoom mode.  How do you do this? Activate zoom mode and hide the horizontal scroll bar, remove other zoom UI components.  Now what happens when someone changes to a higher timebase? it zooms out because it has the buffered data from someone saying they want more memdepth at a lower timebase...

Like i keep saying.. this is all UI illusion bits now with just how people want to use it.. it already has the power to do it because... IT ALREADY DOES IT!  Less for some weird reason that wouldn't work? I cant think of one anyway to fret over so really its just waiting for someone to prioritize such a thing and build the UI out for it as a second layout for zoom mode

[nctnico]

Why i keep saying it should just be a saved option setting to make it run in the mode you want.. they already got a large established universe so that would make no sense to make it default

There's good reason why Run mode memory depth is managed, to retain high throughput and reduce blind time.

But that isn't always needed and deep memory is much more helpful to get certain measurements done. Waveforms/s doesn't matter if there is 5 minutes between a trigger anyway. I don't get why people keep obsessing over waveforms/s and blind time. For many kinds of measurements these don't even matter.

And added to what Elasia says: what if you want full memory depth and view a signals at 2 different points / using 2 different time/div settings? If you need to use the zoom window for force full memory you are losing the function zoom mode is intended for. In which world is that an improvement?

[tautech]

There's good reason why Run mode memory depth is managed, to retain high throughput and reduce blind time.

Stop/captures are different and to enable larger captures the memory needed may have to be reassigned from other features......and maybe to their detriment. 
Accommodations should only be made if datasheet specifications will not be impacted upon.

Step back a minute and think about it... what is the scope doing when you are in split screen zoom mode? You have the zoom area at your target resolution and its buffering the rest of the data so you can zoom out and see more if you choose

Now... what is wanted is the ability to be at your target resolution but be able to change your timebase to zoom out but without actually 'activating' zoom mode.  How do you do this? Activate zoom mode and hide the horizontal scroll bar, remove other zoom UI components.  Now what happens when someone changes to a higher timebase? it zooms out because it has the buffered data from someone saying they want more memdepth at a lower timebase...

Like i keep saying.. this is all UI illusion bits now with just how people want to use it.. it already has the power to do it because... IT ALREADY DOES IT!  Less for some weird reason that wouldn't work? I cant think of one anyway to fret over so really its just waiting for someone to prioritize such a thing and build the UI out for it as a second layout for zoom mode

Way ahead of you on this.......any capture first needs available memory .......but it's already assigned for post trigger History !
Zoom out capture memory depth requirements cannot grab memory from thin air...it's already being used...post trigger !
So to implement capture zoom out another memory management strategy need be developed and this is being discussed privately.

Got a clever plan, we're all ears. 

[maginnovision]

I guess we can thank Dave, might have standard memory management and options on siglents newer scopes at some point. God knows the salesman who was telling us we don't know how to use oscilloscopes didn't make anything happen.

I'm also not sure what's supposed to be so difficult with implementation. You already have a buffer for the waveform of variable(based on sample rate and capture time) size, you just need to implement it with a fixed, user selectable, size. Seems like something you could hack together pretty quick. How is x segments of y size any different than having x segments of y size?

[nctnico]

Got a clever plan, we're all ears. 

The clever plan is: look at how GW Instek, Keysight, MicSig, Owon, Rigol, R&S, Tektronix and Yokogawa deal with the acquisition memory. Dealing with the acquisition memory is not rocket science. Siglent doesn't need to come up with anything new here. It has been developed long before Siglent even thought of making a DSO. Just copy & paste like Siglent has done so many times before.

[SilverSolder]

If Siglent is going to go through the trouble of fixing this, they should pull out all the stops and add something that the competitors don't have!

For example -  make the protocol decoding software start at an arbitrary point in the captured data, which you set by moving a cursor to the point where you want it to start (and optionally, a second cursor where you want it to stop!).

While you're at it, add a "zoom to cursor range" function, which - as the name implies - zooms to the horizontal/time window between two cursors that you set manually (optionally, from cursor to trigger point from the left, and trigger point to cursor on the right).

[nctnico]

If Siglent is going to go through the trouble of fixing this, they should pull out all the stops and make something that the competitors don't have!

For example -  make the protocol decoding software start at an arbitrary point in the captured data, which you set by moving a cursor to the point where you want it to start (and optionally, a second cursor where you want it to stop!).

Or a user selectable samplerate (Lecroy may have this already).

[tautech]

If Siglent is going to go through the trouble of fixing this, they should pull out all the stops and add something that the competitors don't have!

That might also be part of the plan but right now the focus is on bugs, additional features will be added later.

While you're at it, add a "zoom to cursor range" function, which - as the name implies - zooms to the horizontal/time window between two cursors that you set manually (optionally, from cursor to trigger point from the left, and trigger point to cursor on the right).

Already can do this easily with touch, see here:

https://youtu.be/5Gl1O8YHUso

[rf-loop]

There's good reason why Run mode memory depth is managed, to retain high throughput and reduce blind time.


Step back a minute and think about it... what is the scope doing when you are in split screen zoom mode? You have the zoom area at your target resolution and its buffering the rest of the data so you can zoom out and see more if you choose

Now... what is wanted is the ability to be at your target resolution but be able to change your timebase to zoom out but without actually 'activating' zoom mode.  How do you do this? Activate zoom mode and hide the horizontal scroll bar, remove other zoom UI components.  Now what happens when someone changes to a higher timebase? it zooms out because it has the buffered data from someone saying they want more memdepth at a lower timebase...

Like i keep saying.. this is all UI illusion bits now with just how people want to use it.. it already has the power to do it because... IT ALREADY DOES IT!  Less for some weird reason that wouldn't work? I cant think of one anyway to fret over so really its just waiting for someone to prioritize such a thing and build the UI out for it as a second layout for zoom mode

Omg    


Whole solution need only one toggle push button without even need add any more HW buttons.
In "normal" split window zoom mode just push this button and zoomed window is full screen and next back to split screen  zoom display push again this button.

Again, simplest solution can solve it least as baseline solution and whole mess and <censored> around this thing is gone....

Siglent: Do It! Now! Or better - yesterday.

--------------------------------------------------------------------


Common sidenote to wfm history buffer:
Btw there seems live some rumors that when it do short acquisitions using faster timebases then it use rest of acquisition buffer memory for normal runtime history. No, it is not limited to amount of acquisition memory length least in some Siglent models. Example in some SDS1000 models maximum history buffer can have over 100M data points when max acq memory length is specified for 14M or example 4x7M. Same for fast sequence mode aka "segmented memory acquisition". Why it is not called using this historical name - because it is not limited to divide normal acq. memory to segments as in historical some scopes. So it is just sequence mode. (it can use also more slow internal free memory than just fast acquisition memory because there is time to push these "segments" to other free memory places what memory places are not at all usable to max continuous acquisition memory length. 
I do not remember how this same thing is arranged in R&S some RTO models who is or have been perhaps one leader in this - runtime always background working history buffer principle - but no dogs are barking.

Who can check what is max amount of history buffer data in Siglent 2000X Plus
Something like in this table what I made time ago,  not need whole table but even with some different settings so we can see do it still exceed normal acq. memory max length. Of course better place for this is other thread about this Siglent model.



Just wish to Siglent. Do NOT change this principle how it is now, continue Siglents own road - when dogs are barking they know they get food (mediabusiness is...)!

But "side" features you can ADD as example just said, based to @elasia comment, solution and it can also develop and implement so it works nice and robust. How solution can be so simple... just behind corner.  (do it so that also mediabusiness peoples can understand it when they do DTFTLIE method) - simple solution and it works and you get two bird using one shot.
(DTFTLIE = Do (Test || Things) First and Think Later If Ever)

[tautech]

Who can check what is max amount of history buffer data in Siglent 2000X Plus

https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg2786800/#msg2786800
And discussion just beforehand. 

[EEVblog]

Got a clever plan, we're all ears. 

When the user manually selects a memory size then you damn well obey that and set that memory size, at any timebase, just like every other scope on the market. If there is any memory left over feel free to use for auto history mode.
Not rocket science.

[EEVblog]

The only worry is how any zoom out feature might be implemented for those having trouble to adapt the existing tool set as it could possible impact on the features already available. We don't want that.

This has nothing to do with zoom out, and everything to do with the inability and downright refusal of the scope to use the memory depth the user manually specifies.

[nfmax]

The only worry is how any zoom out feature might be implemented for those having trouble to adapt the existing tool set as it could possible impact on the features already available. We don't want that.

This has nothing to do with zoom out, and everything to do with the inability and downright refusal of the scope to use the memory depth the user manually specifies.

I suspect the amount of memory that can be used varies with timebase speed, in which case the menu entries for memory size selection would have to change appropriately. If the firmware uses fixed string lists for menu entry definition, this may be difficult (but not impossible).

[tv84]

When the user manually selects a memory size then you damn well obey that and set that memory size, at any timebase, just like every other scope on the market. If there is any memory left over feel free to use for auto history mode.

This basically sums it all up.

Talking about "auto history mode": when I select manual gear I don't expect the car to switch to auto just because ...

[Elasia]

Way ahead of you on this.......any capture first needs available memory .......but it's already assigned for post trigger History !
Zoom out capture memory depth requirements cannot grab memory from thin air...it's already being used...post trigger !
So to implement capture zoom out another memory management strategy need be developed and this is being discussed privately.

Got a clever plan, we're all ears. 

When the user manually selects a memory size then you damn well obey that and set that memory size, at any timebase, just like every other scope on the market. If there is any memory left over feel free to use for auto history mode.

This basically sums it all up.

Talking about "auto history mode": when I select manual gear I don't expect the car to switch to auto just because ...

+1

And yes it needs memory... so where is it getting that memory in zoom mode? It was already assigned to buffering.. because the user said they wanted zoom mode.. this is zoom mode without all the fancy UI..  hell.. use the zoom button for it and just make a right side UI control panel for it.. aka another zoom ui if hiding the other parts.. then let the user default that mode if they choose

[tautech]

The only worry is how any zoom out feature might be implemented for those having trouble to adapt the existing tool set as it could possible impact on the features already available. We don't want that.

This has nothing to do with zoom out, and everything to do with the inability and downright refusal of the scope to use the memory depth the user manually specifies.

RTFM
P 81.

[tautech]

The only worry is how any zoom out feature might be implemented for those having trouble to adapt the existing tool set as it could possible impact on the features already available. We don't want that.

This has nothing to do with zoom out, and everything to do with the inability and downright refusal of the scope to use the memory depth the user manually specifies.

I suspect the amount of memory that can be used varies with timebase speed, in which case the menu entries for memory size selection would have to change appropriately. If the firmware uses fixed string lists for menu entry definition, this may be difficult (but not impossible).

And you worked that out without RTFM. 

[tautech]

Way ahead of you on this.......any capture first needs available memory .......but it's already assigned for post trigger History !
Zoom out capture memory depth requirements cannot grab memory from thin air...it's already being used...post trigger !
So to implement capture zoom out another memory management strategy need be developed and this is being discussed privately.

Got a clever plan, we're all ears. 

And yes it needs memory... so where is it getting that memory in zoom mode? It was already assigned to buffering.. because the user said they wanted zoom mode.. this is zoom mode without all the fancy UI..  hell.. use the zoom button for it and just make a right side UI control panel for it.. aka another zoom ui if hiding the other parts.. then let the user default that mode if they choose

Seems I missed the full meaning of you earlier post but rf-loop didn't and it seems a very valid solution. 

[Fungus]

when I select manual gear I don't expect the car to switch to auto just because ...

Yet another argument solved by an automotive analogy... 

[nctnico]

Way ahead of you on this.......any capture first needs available memory .......but it's already assigned for post trigger History !
Zoom out capture memory depth requirements cannot grab memory from thin air...it's already being used...post trigger !
So to implement capture zoom out another memory management strategy need be developed and this is being discussed privately.

Got a clever plan, we're all ears. 

And yes it needs memory... so where is it getting that memory in zoom mode? It was already assigned to buffering.. because the user said they wanted zoom mode.. this is zoom mode without all the fancy UI..  hell.. use the zoom button for it and just make a right side UI control panel for it.. aka another zoom ui if hiding the other parts.. then let the user default that mode if they choose

Seems I missed the full meaning of you earlier post but rf-loop didn't and it seems a very valid solution. 

No. Just like you rf-loop doesn't even understand the actual problem at hand. With rf-loop's solution you still lose the zoom function for it's intended purpose. Dave did mis-name this thread by calling the behaviour a quirk; the zoom-out feature actually is there by design in other oscilloscopes. Before making any other comments take the time to study user manuals and watch videos on how oscilloscope's from the competition work and try to understand why they work that way. Or just wait until Siglent fixes the firmware. You'll see there will be zero impact on existing functionality. I really don't understand why you are so opposed on improving the product you are selling. 

[tautech]

Way ahead of you on this.......any capture first needs available memory .......but it's already assigned for post trigger History !
Zoom out capture memory depth requirements cannot grab memory from thin air...it's already being used...post trigger !
So to implement capture zoom out another memory management strategy need be developed and this is being discussed privately.

Got a clever plan, we're all ears. 

And yes it needs memory... so where is it getting that memory in zoom mode? It was already assigned to buffering.. because the user said they wanted zoom mode.. this is zoom mode without all the fancy UI..  hell.. use the zoom button for it and just make a right side UI control panel for it.. aka another zoom ui if hiding the other parts.. then let the user default that mode if they choose

Seems I missed the full meaning of you earlier post but rf-loop didn't and it seems a very valid solution. 

No. Just like you rf-loop doesn't even understand the actual problem at hand. With rf-loop's solution you still lose the zoom function for it's intended purpose. Before making any other comments take the time to study user manuals and watch videos on how oscilloscope's from the competition work and try to understand why they work that way. Or just wait until Siglent fixes their scopes. You'll see there will be zero impact on existing functionality. I really don't understand why you are so opposed on improving the product you are selling. 

FFS, I think we know the functional workings of the products we sell much better than you !
Go away and RTFM ! Come back when it's understood.


Elasia's solution I believe is to use the primary timebase of the Zoom mode framework but hidden as the basis for capture zoom out.
Max memory depth selected for ordinary Zoom mode would work as normal but could be toggled to a hidden Zoom UI and then provide capture zoom out capability from the full mem depth the user has set.

Is that right Elasia ?

[nctnico]

No. Just like you rf-loop doesn't even understand the actual problem at hand. With rf-loop's solution you still lose the zoom function for it's intended purpose. Before making any other comments take the time to study user manuals and watch videos on how oscilloscope's from the competition work and try to understand why they work that way. Or just wait until Siglent fixes their scopes. You'll see there will be zero impact on existing functionality. I really don't understand why you are so opposed on improving the product you are selling. 

FFS, I think we know the functional workings of the products we sell much better than you !

I strongly doubt that. Have you ever designed a digital oscilloscope or data acquisition system? I have (and one of them is staring you right into the face; I've used one of the prototype designs as my avatar picture). You OTOH don't seem to have a good grasp on how an oscilloscope actually should work. Otherwise you wouldn't be sticking to bad ideas and crutches.

[tautech]

No. Just like you rf-loop doesn't even understand the actual problem at hand. With rf-loop's solution you still lose the zoom function for it's intended purpose. Before making any other comments take the time to study user manuals and watch videos on how oscilloscope's from the competition work and try to understand why they work that way. Or just wait until Siglent fixes their scopes. You'll see there will be zero impact on existing functionality. I really don't understand why you are so opposed on improving the product you are selling. 

FFS, I think we know the functional workings of the products we sell much better than you !

I strongly doubt that. Have you ever designed a digital oscilloscope or data acquisition system? I have (and one of them is staring you right into the face; I've used one of the prototype designs as my avatar picture). You OTOH don't seem to have a good grasp on how an oscilloscope actually should work. Otherwise you wouldn't be sticking to bad ideas and crutches.

I might say: 'fuck off and read up on a Siglent user manual' but I won't.
Still, you might just learn something.

[Martin72]

Gentlemen, keep calm...