EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: Wuerstchenhund on May 08, 2020, 09:18:13 am
-
Wouldn't this make a nice topic for one of your videos? Maybe coupled with a comparison of the nctnico method vs everyone else's method? :-DD
What's his method again?, I must have missed that.
I just set the scopes max memory depth and a 1us timebase and STOP it. If it lets me zoom out to slower timebases and still show data then it passes.
Then repeat using a trigger signal just in case there is a difference between manual STOP mode and a trigger event capture.
Nico has used the example of an SPI frame where you are interested in a certain bit but also want to check the whole frame.
Nico's method (if I understand it correctly!) is this:
- Set the trigger to the data point of interest
- Set memory to max
- Set the time base so the specific data point fills the screen (i.e. max detail)
- Perform a single acquisition, then STOP
- Check out the data point
- Then zoom out to check out the rest of SPI frame
The method I know would be:
- Set the trigger to the data point of interest
- Set memory to max Not necessary as scopes will usually maximize the memory to an sufficient extend automatically
- Check what the length of that SPI frame is and set the timebase to capture the whole frame (say 100us)
- Perform a single acquisition Actually, I might not want to but prefer to look at life data, so I leave the scope on normal mode
- Check out the frame
- Zoom in to the datapoint of interest and check that out
The result is the same, it's just the opposite way of doing it. Nico's method is also perfectly valid, however won't be possible unless the scope allows him to zoom out (which many don't, especially on very short time bases). While the method I have described works on every DSO.
The other difference is that, when it comes setting up your scope and avoiding excessive acquisition time (keeping in mind that time saving was one of the arguments for his method!), Nico needs to know how much memory he needs to use, so he not only needs to establish what the frame lenght is but also how in how many points this translates in terms of sample memory. While the second method just requires knowledge of the frame length.
Keep in mind this is *not* "zooming out"as having your scope in normal mode and just changing the timebase so you can see more of the signal, which again works on every scope. It's really about if a scope can record beyond its screen on very short timebases when the memory is set accordingly, which is only visible in a single acquisition.
The contentious point was actually not about the methods itself (I just never heard of anyone doing it this way before) but if a scope should be expected to accommodate Nico's method and what the relevance of this is in real life.
-
Wouldn't this make a nice topic for one of your videos? Maybe coupled with a comparison of the nctnico method vs everyone else's method? :-DD
What's his method again?, I must have missed that.
I just set the scopes max memory depth and a 1us timebase and STOP it. If it lets me zoom out to slower timebases and still show data then it passes.
Then repeat using a trigger signal just in case there is a difference between manual STOP mode and a trigger event capture.
Nico has used the example of an SPI frame where you are interested in a certain bit but also want to check the whole frame.
Nico's method (if I understand it correctly!) is this:
- Set the trigger to the data point of interest
- Set memory to max
- Set the time base so the specific data point fills the screen (i.e. max detail)
- Perform a single acquisition, then STOP
- Check out the data point
- Then zoom out to check out the rest of SPI frame
The method I know would be:
- Set the trigger to the data point of interest
- Set memory to max Not necessary as scopes will usually maximize the memory to an sufficient extend automatically
- Check what the length of that SPI frame is and set the timebase to capture the whole frame (say 100us)
- Perform a single acquisition Actually, I might not want to but prefer to look at life data, so I leave the scope on normal mode
- Check out the frame
- Zoom in to the datapoint of interest and check that out
The result is the same, it's just the opposite way of doing it. Nico's method is also perfectly valid, however won't be possible unless the scope allows him to zoom out (which many don't, especially on very short time bases). While the method I have described works on every DSO.
The other difference is that, when it comes setting up your scope and avoiding excessive acquisition time (keeping in mind that time saving was one of the arguments for his method!), Nico needs to know how much memory he needs to use, so he not only needs to establish what the frame lenght is but also how in how many points this translates in terms of sample memory. While the second method just requires knowledge of the frame length.
Keep in mind this is *not* "zooming out"as having your scope in normal mode and just changing the timebase so you can see more of the signal, which again works on every scope. It's really about if a scope can record beyond its screen on very short timebases when the memory is set accordingly, which is only visible in a single acquisition.
The contentious point was actually not about the methods itself (I just never heard of anyone doing it this way before) but if a scope should be expected to accommodate Nico's method and what the relevance of this is in real life.
You are missing a few fine details:
- I'm not using single acquisition in most cases. I stop the oscilloscope when I see something of interest and in some cases I leave it in run mode because I have control over generating the trigger events somewhere else.
- I don't care about the time base setting and I'm not going to calculate how much memory I need. If it turns out to be not enough then I have to fallback to presetting the time base. The deeper the memory, the less this is necessary.
The key point to my method is that you don't need to worry about setting up the time/div and horizontal position of the scope properly before doing a measurement. Sometimes I forget to put the horizontal position back to the trigger point. With the oscilloscope recording outside the screen I can just scroll back to the trigger point. The benefits of my method are:
- Scope time/div setup is not critical to catch all data in many cases
- Least twiddling with knobs & settings
Keep in mind that this usage mostly happens during debugging interaction between software and hardware. In the end it saves time. I think I already mentioned this workflow in my review of the SDS2204 I did 5 or 6 years ago. I have not checked that yet.
-
Wouldn't this make a nice topic for one of your videos? Maybe coupled with a comparison of the nctnico method vs everyone else's method? :-DD
What's his method again?, I must have missed that.
I just set the scopes max memory depth and a 1us timebase and STOP it. If it lets me zoom out to slower timebases and still show data then it passes.
Then repeat using a trigger signal just in case there is a difference between manual STOP mode and a trigger event capture.
Nico has used the example of an SPI frame where you are interested in a certain bit but also want to check the whole frame.
Nico's method (if I understand it correctly!) is this:
- Set the trigger to the data point of interest
- Set memory to max
- Set the time base so the specific data point fills the screen (i.e. max detail)
- Perform a single acquisition, then STOP
- Check out the data point
- Then zoom out to check out the rest of SPI frame
Exactly the same as what I'm doing, except I couldn't be arsed to use any data ;D
You don't need the data, it's obvious when the samples run out as the trace stops at both ends.
The contentious point was actually not about the methods itself (I just never heard of anyone doing it this way before) but if a scope should be expected to accommodate Nico's method and what the relevance of this is in real life.
I don't see it as contentious, it has obvious use. It lets your trigger thing or interest and then say "gee I wonder what happened before or after that". If you have a scope that captures outside the display then you don't have to retrigger again at longer time base. This could actually be vital on something you can only trigger off intermittently for example.
-
Exactly the same as what I'm doing, except I couldn't be arsed to use any data ;D
You don't need the data, it's obvious when the samples run out as the trace stops at both ends.
It's the story of my life, the data I need are always just after the scope runs out of memory :(
-
Wouldn't this make a nice topic for one of your videos? Maybe coupled with a comparison of the nctnico method vs everyone else's method? :-DD
What's his method again?, I must have missed that.
I just set the scopes max memory depth and a 1us timebase and STOP it. If it lets me zoom out to slower timebases and still show data then it passes.
Then repeat using a trigger signal just in case there is a difference between manual STOP mode and a trigger event capture.
Nico has used the example of an SPI frame where you are interested in a certain bit but also want to check the whole frame.
Nico's method (if I understand it correctly!) is this:
- Set the trigger to the data point of interest
- Set memory to max
- Set the time base so the specific data point fills the screen (i.e. max detail)
- Perform a single acquisition, then STOP
- Check out the data point
- Then zoom out to check out the rest of SPI frame
The method I know would be:
- Set the trigger to the data point of interest
- Set memory to max Not necessary as scopes will usually maximize the memory to an sufficient extend automatically
- Check what the length of that SPI frame is and set the timebase to capture the whole frame (say 100us)
- Perform a single acquisition Actually, I might not want to but prefer to look at life data, so I leave the scope on normal mode
- Check out the frame
- Zoom in to the datapoint of interest and check that out
The result is the same, it's just the opposite way of doing it. Nico's method is also perfectly valid, however won't be possible unless the scope allows him to zoom out (which many don't, especially on very short time bases). While the method I have described works on every DSO.
The other difference is that, when it comes setting up your scope and avoiding excessive acquisition time (keeping in mind that time saving was one of the arguments for his method!), Nico needs to know how much memory he needs to use, so he not only needs to establish what the frame lenght is but also how in how many points this translates in terms of sample memory. While the second method just requires knowledge of the frame length.
Keep in mind this is *not* "zooming out"as having your scope in normal mode and just changing the timebase so you can see more of the signal, which again works on every scope. It's really about if a scope can record beyond its screen on very short timebases when the memory is set accordingly, which is only visible in a single acquisition.
The contentious point was actually not about the methods itself (I just never heard of anyone doing it this way before) but if a scope should be expected to accommodate Nico's method and what the relevance of this is in real life.
You are missing a few fine details:
- I'm not using single acquisition in most cases. I stop the oscilloscope when I see something of interest and in some cases I leave it in run mode because I have control over generating the trigger events somewhere else.
- I don't care about the time base setting and I'm not going to calculate how much memory I need. If it turns out to be not enough then I have to fallback to presetting the time base. The deeper the memory, the less this is necessary.
The key point to my method is that you don't need to worry about setting up the time/div and horizontal position of the scope properly before doing a measurement. Sometimes I forget to put the horizontal position back to the trigger point. With the oscilloscope recording outside the screen I can just scroll back to the trigger point. The benefits of my method are:
- Scope time/div setup is not critical to catch all data in many cases
- Least twiddling with knobs & settings
Keep in mind that this usage mostly happens during debugging interaction between software and hardware. In the end it saves time. I think I already mentioned this workflow in my review of the SDS2204 I did 5 or 6 years ago. I have not checked that yet.
But you do have lots of twiddling of knobs while you are looking at the data....
Like I said, what you do is runaround way doing same thing as I do simpler. I put Pico to 200 MS depth, set it to 200 ms, and let it rip..
Sometimes in run mode where I stop it and look around, or zoom in to a window ( On Picoscope zoom mode is still full screen, no loss of size) and keep looking at that time in run mode. Or I have a burst of something that I get in single mode and look at it.
I literally bought Picoscope for that purpose.... And many protocols, deep mem, and huge PC screens (plural) is much better for that than any standalone scope.
-
You are missing a few fine details:
That's entirely possible.
- I'm not using single acquisition in most cases. I stop the oscilloscope when I see something of interest and in some cases I leave it in run mode because I have control over generating the trigger events somewhere else.
I see, but if you use RUN mode then the discussion is mood, as any change in the time base (say to "zoom out") would be a normal change of the acquisition parameters and thereby completely unaffected if a scope allows capturing events outside the screen area or not. :-//
The problem (can you capture outside the screen or not) only affects single acquisition (or, on a InfiniVision scope, the last acquisition after pressing STOP).
- I don't care about the time base setting and I'm not going to calculate how much memory I need. If it turns out to be not enough then I have to fallback to presetting the time base. The deeper the memory, the less this is necessary.
I understand, but that would then run counter to your argument that your method saves time. Which it doesn't, as not caring about the memory means you are likely to use too much (i.e. unnecessarily extending the acquisition time), or to use too little (undersampling) and then need to re-adjust and repeat.
The key point to my method is that you don't need to worry about setting up the time/div and horizontal position of the scope properly before doing a measurement.
Well, you still need to twiddle the knobs until the screen shows what your want, right? It shouldn't really matter if you do that visually or parameter based (actually twiddling might even take longer than just setting the scope to a specific parameter).
Sometimes I forget to put the horizontal position back to the trigger point. With the oscilloscope recording outside the screen I can just scroll back to the trigger point.
I get the overall idea, but I still struggle to see it in practice.
The benefits of my method are:
- Scope time/div setup is not critical to catch all data in many cases
Well, to some extend it is, because you need to make sure your timebase setting isn't so low that the sample rate drops below what you want, and you need to make sure that your memory setting isn't too small (undersampling) or too excessive (increased acquisition time).
- Least twiddling with knobs & settings
This is what I don't see. To me your method, while valid, seems to be overly limiting (it only works on a few scopes if you want to use single acquisition), and while you may not have to calculate memory you still have to balance timebase and memory settings so you are capturing long enough at a high enough sample rate but not too much to avoid extended waiting times for the acquisition to finish.
The method I described on the other side works on every scope, in RUN or single acuisition, all I need to know is how long my sequence is (and you need to know that for being able to assess if the timing parameters of your signal are correct or not anyways) and use this one parameter to setup the timebase. That's it. I then see the whole sequence, and if I want to see a specific detail I just zoom in (i.e. pinch to zoom, drag a box around the point of interest, or use the zoom knob, depending on the scope). If I want to see more I can happily move around as I wish, all without ever having to touch the timebase knob (unless of course, the timebase know is also your zoom knob).
Keep in mind that this usage mostly happens during debugging interaction between software and hardware. In the end it saves time. I think I already mentioned this workflow in my review of the SDS2204 I did 5 or 6 years ago. I have not checked that yet.
I get the situation, and I can follow your line of intention, I just don't see the advantage (and I see a number of disadvantages).
As I said, I've never heard anyone doing it this way (i.e. trying to capture in single acquisition mode beyond the screen to zoom in) but I find your approach interesting. I just don't fully "see" it as practical.
-
Nico's method (if I understand it correctly!) is this:
- Set the trigger to the data point of interest
- Set memory to max
- Set the time base so the specific data point fills the screen (i.e. max detail)
- Perform a single acquisition, then STOP
- Check out the data point
- Then zoom out to check out the rest of SPI frame
Exactly the same as what I'm doing, except I couldn't be arsed to use any data ;D
You don't need the data, it's obvious when the samples run out as the trace stops at both ends.[/quote]
Well, if you want to zoom out then your scope must be capturing the complete sequence, so there must be enough memory to capture screen area plus the area of interest outside the screen.
So on a KS InfiniVision scope this only work in SINGLE or for the last acquisition in STOP mode as otherwise the scope will only capture enough for the period that's shown on the display. So it only works with a stopped acquisition.
For a Rigol scope you'd have to set the memory manually to something high to capture beyond the screen. Which, as with the KS, only makes sense in SINGLE or as the last acquisition after pressing STOP.
If you care about time then at least on the Rigol you'd also have to make sure the memory setting isn't excessive (capturing more than you need).
The contentious point was actually not about the methods itself (I just never heard of anyone doing it this way before) but if a scope should be expected to accommodate Nico's method and what the relevance of this is in real life.
I don't see it as contentious, it has obvious use. It lets your trigger thing or interest and then say "gee I wonder what happened before or after that". If you have a scope that captures outside the display then you don't have to retrigger again at longer time base. This could actually be vital on something you can only trigger off intermittently for example.
So where is the benefit over triggering to the same point of interest (i.e. same trigger) and just setting the timebase to show the whole sequence on the screen, and then just zoom in to a detail of interest? You'd still not have to retrigger, and it works on every scope. :-//
-
So on a KS InfiniVision scope this only work in SINGLE or for the last acquisition in STOP mode as otherwise the scope will only capture enough for the period that's shown on the display. So it only works with a stopped acquisition.
Nope, it worked on both stopped and triggerd aquisitions.
So where is the benefit over triggering to the same point of interest (i.e. same trigger) and just setting the timebase to show the whole sequence on the screen, and then just zoom in to a detail of interest? You'd still not have to retrigger, and it works on every scope. :-//
The point is you may not have been interested (or know) in the whole timebase length, you were just interested in the event so that's what you triggered from. But as I said, if then you think, see I wondered that happened before or after that, bingo, it's there for you to zoom out to see.
Could be very handy.
If that's not how you work then that's fine, but it's undeniable it could be an advantage to some.
-
The point is you may not have been interested (or know) in the whole timebase length, you were just interested in the event so that's what you triggered from. But as I said, if then you think, see I wondered that happened before or after that, bingo, it's there for you to zoom out to see.
Could be very handy.
If that's not how you work then that's fine, but it's undeniable it could be an advantage to some.
Absolutely agree with you, and as I said, it did come in handy few times. But I don't depend on it, and would not discard otherwise good scope because of it...
I mix using Keysight 3000T (that is like that) and Picoscopes (that are not) and see no problem using either.
My philosophy is that I will use some unforeseen advantage if I can, but I can't (and won't) depend on something that is not guaranteed.
-
So on a KS InfiniVision scope this only work in SINGLE or for the last acquisition in STOP mode as otherwise the scope will only capture enough for the period that's shown on the display. So it only works with a stopped acquisition.
Nope, it worked on both stopped and triggerd aquisitions.
It doesn't. Because all InfiniVision scopes only capture enough for the period displayed on screen and only use all the memory during the last acquisition when you press STOP (or on a single acquisition).
The only way you can "zoom out" during a in normal (continuous) mode is if you change the time base setting to something longer, after which the scope adjusts the memory usage to the new screen period and then performs the next acquisition with the new parameter. You're still not recording out of screen data.
So where is the benefit over triggering to the same point of interest (i.e. same trigger) and just setting the timebase to show the whole sequence on the screen, and then just zoom in to a detail of interest? You'd still not have to retrigger, and it works on every scope. :-//
The point is you may not have been interested (or know) in the whole timebase length, you were just interested in the event so that's what you triggered from. But as I said, if then you think, see I wondered that happened before or after that, bingo, it's there for you to zoom out to see.
Could be very handy.
True. But on the Rigol you still need to setup the memory (so you need to have some idea about the length of the overall sequence you want to watch) or you may end up with too little memory, and in the KS you can't really "zoom out" unless you're in STOP mode.
If that's not how you work then that's fine, but it's undeniable it could be an advantage to some.
And I just try to understand where that advantage is, and why would you require a scope to do that.
Doesn't seem to be a widely requested feature, though.
-
LeCroy scopes don't, and as Siglent follows LeCroy their scopes don't, either.
also Picoscope
-
So on a KS InfiniVision scope this only work in SINGLE or for the last acquisition in STOP mode as otherwise the scope will only capture enough for the period that's shown on the display. So it only works with a stopped acquisition.
Nope, it worked on both stopped and triggerd aquisitions.
It doesn't. Because all InfiniVision scopes only capture enough for the period displayed on screen and only use all the memory during the last acquisition when you press STOP (or on a single acquisition).
This depends on the version of InfiniVision scope you are using. The DSO7104A I used to own could record outside the screen in any mode. The newer models seem to only do this in single mode (if I interpret the user manual correctly).
-
So on a KS InfiniVision scope this only work in SINGLE or for the last acquisition in STOP mode as otherwise the scope will only capture enough for the period that's shown on the display. So it only works with a stopped acquisition.
Nope, it worked on both stopped and triggerd aquisitions.
It doesn't. Because all InfiniVision scopes only capture enough for the period displayed on screen and only use all the memory during the last acquisition when you press STOP (or on a single acquisition).
This depends on the version of InfiniVision scope you are using. The DSO7104A I used to own could record outside the screen in any mode. The newer models seem to only do this in single mode (if I interpret the user manual correctly).
You don't understand what Wuerstchenhund is saying.
When running Infiniivision captures only "screeen lenght". If you change timebase , it will change what it captures, and again, will capture only "screen length"every trigger.
But, if you press STOP, it will practically reconfigure engine for SINGLE mode ( with half of max mem) and will keep some data before first triggered frame, and will keep on capturing until it runs out of buffers.
So to you, it does look like it takes full mem, but it doesn't do that all the time but only on last capture when you stop.
When stopped it seems all the same to you, but Wuerstchenhund is right, while running it's not.
How we know that? Well, if you put 3000T to 50 ns/div (500 ns per screen) it will retrigger at rate of 980 kHz. Slightly more than 1 us per trigger event.
Then you stop it and voila, you get 400us of capture. 40 us before trigger point, and 360us after trigger point.
And as you go from 50ns/div to 20us/div, it will keep sample rate of 5GS/s, while running keeps taking only what is "screen lenght" worth in every trigger, and if you stop it you get, again, you get 400us of data. Than sample rate goes down.
What does it mean? Well, when you're on 1ns/div, you get 40000x length worth of data than what is on your screen (10ns to 400us) if you stop it. If you are at 20us/div you get only 2x (200us to 400us).
And from that point on sample rate goes down, and game repeats, changing ratio "screen/stopped capture length" all the time. I guess table could be compiled. It's just I couldn't care less.
I'm not going to base my work based on side-effects of sample engine architecture..
P.S to be exactly technically correct it doesn't always capture exactly screen length. Sometimes it will capture a bit more, depending on division ratios of time/sample rate/buffer size chunks. But on every trigger event it captures only smaller sub buffer (compared to what it returns when stopped), minimum size to fit screen full of data necessary.
-
Again (4th time I'm explaining this): Keysight has changed the behaviour on the more modern models!
-
Again (4th time I'm explaining this): Keysight has changed the behaviour on the more modern models!
Other people (other than you) started to think that 3000/4000 series behave the way you said. They don't.
Well, they do, sort of, but not in consistent and always useful way.
-
Well, this workflow (zooming out after a capture) is available on many DSOs. It is the standard (or at least configurable) on Tektronix, Rigol, GW Instek, R&S, the older Keysight scopes (DSO7000A / B series and derivatives), the original Siglent SDS2000 series and probably several others. However you have to realise that 'capture outside' the screen only works if there is memory left over after filling the screen. So it won't be the case at time/div settings where the maximum samplerate is dropped. I have been using DSOs like this forever. I strongly recall being very annoyed by the Siglent SDS2000 not remembering this setting in the early firmware.
Sorry, I stand corrected, I had a brain fart, you are right. Both Rigol (2000) and (modern Megazoom IV) Keysight do this, they will capture full memory depth and allow you to "zoom out" from a shorter time base trigger capture.
Siglent (5000X) however does not do this, it captures the screen and that's it, you can't "zoom out" either in STOP mode or single shot triggered mode.
The Siglent sampling architecture must be implemented very differently.
Indeed, it seems the Keysight InfiniVision scopes perform the last sample at full max memory independent on the timebase.
The Rigols seem to do it when memory is set manually (well, the memory management is pretty basic).
However, Keysight Infiniium scopes (at least for DSO8k and newer) don't.
LeCroy scopes don't, and as Siglent follows LeCroy their scopes don't, either.
Tek MDO3k & Co do through a trick (leaving the timebase longer and zooming in when selecting shorter ones), other ones don't (I can't remember so I have to rely on 3rd paty info here).
R&S I don't remember but I don't believe they do.
Through habit I guess I've just learned not to rely on this when capturing.
Now I'm curious to see a list of scopes that do this and those that don't. But this should have it's own thread.
Wouldn't this make a nice topic for one of your videos? Maybe coupled with a comparison of the nctnico method vs everyone else's method? :-DD
I would watch that :-+
Little late but it isn't just Nico's method, I've done this also. I typically generate my triggers onboard(cpld or fpga) then depending on how everything looks I may need to pull the timebase out to see more. If not great if so it saves me another capture. I can't see both things in one timebase easily since it's data and timing validation initially but if timing is good and data bad I have to see why. Waiting for another error could take time and slow down debugging as well.
-
Yes I did too. But that is not method. You were looking at stuff at wrong time base for that kind of analysis.
It is a lucky happenstance that scope, on it's own captured some more data than it was supposed to, so you could take a look at something else too..
And it worked in your favor. But it's not reliable all the time and on all time-bases. And different on every scope type.
I capture all in one long capture and can look at both slow and fast at will all the time.
That is how it's done if you were to use logic analyser for decoding. You capture the lot and zoom in into details..
-
Yes I did too. But that is not method. You were looking at stuff at wrong time base for that kind of analysis.
It is a lucky happenstance that scope, on it's own captured some more data than it was supposed to, so you could take a look at something else too..
Sorry but you are trying to reason a moot point here. If you want recording outside the screen then select a scope which does. If not then don't. It has nothing to do with luck so don't try to ridicule a working method which is very efficient in real use cases. If you don't see it then you don't see it. As they say: you can lead a horse to water but it has to start drinking by itself.
-
In my case that's not true. If I pulled out initially to always see everything I'd spend more time calculating the timing measurements of the different signals than I would simply viewing the waveforms. Another issue I've run into is some scopes changing measurement resolution based on timebase in a way I lose the resolution I needed. I don't use $20k - $50k scopes though, I only need and use general purpose scopes. Maybe some more expensive scopes are better about that.
Thank you for explaining. That makes sense.
Proper deep memory scope is made exactly to work around this. And this is why I bought Picoscope. It works on full (not decimated) buffer.
It will keep resolution. It is cheapest analytical scope you can get. And decodes tons of protocols. Only problem is no protocol triggers. But i use it for bulk captures anyway.
-
Yes I did too. But that is not method. You were looking at stuff at wrong time base for that kind of analysis.
It is a lucky happenstance that scope, on it's own captured some more data than it was supposed to, so you could take a look at something else too..
Sorry but you are trying to reason a moot point here. If you want recording outside the screen then select a scope which does. If not then don't. It has nothing to do with luck so don't try to ridicule a working method which is very efficient in real use cases. If you don't see it then you don't see it. As they say: you can lead a horse to water but it has to start drinking by itself.
If you want to capture outside screen, just don't. If you know what needs to be captured upfront, just do propper capture...
And leading a horse to water is a nice one. Thanks for that. It applies nice to you who writes this outside screen nonsense EVERY SINGLE TIME anybody on EEVBLOG mentions oscilloscope.
Over and out. I'm done here. I explained my opinion, explained how it applies to scopes I own and use. Rest is up to anybody else to form their own opinion.
And I don't want you to change what you believe and and contest what works for you. If you're happy with it, good for you.
All the best to all.
-
Which Picoscope model do you have 2N3055?
It seems interessting to investigate ;)
I have 3406D MSO. But they have few scopes that have more than 500 MS. Even 2000 series goes to 128 MS mem depth.
I also have 4262, a 16bit 2ch 5MHz scope that is excellent for low frequency low noise measurement
But to be honest, they are not very cheap, and are more of a specialized instrument.
To me they are great complement to Keysight 3000T.
Many people would not like having Picos as only scope, but you could make a combination of smaller cheaper scope (like Siglent SDS 1104X-E, MSO5000, or maybe Keysight 1000) for interactive work and Pico for analysis.
-
Is this the right forum for an argument?
To be honest, there is no right place for an argument. That's why I plan not to continue with it, all is already said and repetition is not productive. And I don't think Nico is asking for one either, just trying to stand by his opinion. Which is his right. We disagree on this topic. That's fine, We agree on many other things. That's fine too..
All the best,
-
Yes I did too. But that is not method. You were looking at stuff at wrong time base for that kind of analysis.
It is a lucky happenstance that scope, on it's own captured some more data than it was supposed to, so you could take a look at something else too..
Sorry but you are trying to reason a moot point here. If you want recording outside the screen then select a scope which does. If not then don't. It has nothing to do with luck so don't try to ridicule a working method which is very efficient in real use cases. If you don't see it then you don't see it. As they say: you can lead a horse to water but it has to start drinking by itself.
If you want to capture outside screen, just don't. If you know what needs to be captured upfront, just do propper capture...
And leading a horse to water is a nice one. Thanks for that. It applies nice to you who writes this outside screen nonsense EVERY SINGLE TIME anybody on EEVBLOG mentions oscilloscope.
Over and out. I'm done here. I explained my opinion, explained how it applies to scopes I own and use. Rest is up to anybody else to form their own opinion.
And I don't want you to change what you believe and and contest what works for you. If you're happy with it, good for you.
All the best to all.
Bingo !
Is this the right forum for an argument?
Argument ? :-//
This is a technical discussion of what's an appropriate usage style of the modern DSO based on the understanding of the acquisition HW design and the selection of tools at your disposal.
-
I was actually making a reference to the Monty Python argument sketch; the conversation is quite illuminating.
-
I was actually making a reference to the Monty Python argument sketch; the conversation is quite illuminating.
Darn, I'm losing it... Didn't catch it... Sorry!! Off I go for a refresher course... :-DD
-
I was actually making a reference to the Monty Python argument sketch; the conversation is quite illuminating.
Immediately, a good slapping with a wet fish for using a DSO in some obscure manner seems quite appropriate. :P
-
Off I go first thing in a morning, I'm gonna silly walk to fish market....
-
The confusion has kicked off once again.
nctnico talks about their way of working that has several things happening at the same time:
slow trigger rate
interesting detail at short time window
possibly interesting detail in the larger capture (but can't rely on another trigger arriving)
[<------- acquisition ------- [ < screen > ] -------------------- acquisition -----> ]
trigger rate is inherently limited, so on most scopes you have to specifically request this sort of mode rather than leaving a scope on auto memory depth.
Now, this makes no sense to 99% of other oscilloscope users, but nctnico insists on making lots of noise about it every chance they can (for some bizarre reason).
Everyone else does one of the following:
has plenty of triggers and captures another capture at the wider window
uses zoom to view the small time window and full acquisition at the same time
... has some entirely different application that has nothing to do with this extreme corner case use (yep, that'd be just about everyone)
So when nctnico says a scope can't do this very specific (and not fully explained) thing, just ignore it. Because with only a tiny change to any part of the application or acceptable solution, just about any scope will do the job.
-
So when nctnico says a scope can't do this very specific (and not fully explained) thing, just ignore it. Because with only a tiny change to any part of the application or acceptable solution, just about any scope will do the job.
Yeah, but he's not wrong.
It's an interesting and demonstrably potentially useful benefit.
-
What does it mean? Well, when you're on 1ns/div, you get 40000x length worth of data than what is on your screen (10ns to 400us) if you stop it. If you are at 20us/div you get only 2x (200us to 400us).
And from that point on sample rate goes down, and game repeats, changing ratio "screen/stopped capture length" all the time. I guess table could be compiled. It's just I couldn't care less.
I'm not going to base my work based on side-effects of sample engine architecture..
So if you captured something and then thought "gee I wonder what's either side of that, and you knew your scope worked like this, you'd actually rather re-capture instead of just changing the timebase?
That's kinda, well, silly.
If your answer is yes I would, then what happens if your capture was infrequent and wasn't easy to reproduce?
Sorry but I can't see a way to successfully argue this isn't a potentially useful feature.
It's so interesting it's probably worthy of a video.
-
Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.
To argue that non-standard DSO usage technique limits the convenience of examining captures in greater detail has never been where the industry has headed instead there is industry wide methodology for capturing events.
-
Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.
No. I'm talking about legitimately setting the timebase to capture the thing you wanted, no user error. Then perhaps you saw something unexpected and though "gee I wonder what happened before or after that".
-
I can't speak for Nico but when the situation arises I do it on purpose to save some time. It's not as if I set it to trigger on line and then single shot until I see what I'm looking for. It's also not the only way I use an oscilloscope, it's just one of the ways.
-
What does it mean? Well, when you're on 1ns/div, you get 40000x length worth of data than what is on your screen (10ns to 400us) if you stop it. If you are at 20us/div you get only 2x (200us to 400us).
And from that point on sample rate goes down, and game repeats, changing ratio "screen/stopped capture length" all the time. I guess table could be compiled. It's just I couldn't care less.
I'm not going to base my work based on side-effects of sample engine architecture..
So if you captured something and then thought "gee I wonder what's either side of that, and you knew your scope worked like this, you'd actually rather re-capture instead of just changing the timebase?
That's kinda, well, silly.
If your answer is yes I would, then what happens if your capture was infrequent and wasn't easy to reproduce?
Sorry but I can't see a way to successfully argue this isn't a potentially useful feature.
It's so interesting it's probably worthy of a video.
You probably didn't read through all the text, to see that I said that i occasionally use that when it's there. And, no I'm not idiot to deliberately recapture something if it's already there, out of some stupid "principle". I'm saying that if you adopt proper practice, you will rarely get into situation to depend on unspecified behaviour of scope (yes on Keysight 3000T it is unspecified. All numbers I wrote I had to measure and test myself). But I will make sure to think in terms "I want to capture long capture, so I'm going to capture a long time period, and then I will zoom into details at will" instead of "I want to capture long capture, so I'm going to set scope on long memory, put it to short timebase to see only trigger point, and then zoom out to see all other stuff that long memory got". It's just backwards way of thinking to me. And on the scope that works like my Keysight and Pico do, my way guarantees I will see everything. Nico's way might (or might not, depending on scope setting) give me more data outside screen on my Keysight 3000T, and on Pico (and Lecroy and Siglent) won't give me squat. And because of that, it is exactly wrong way to use on infrequent and not easy to reproduce events, for which I use method that guarantees I will get first time every time.
So, yes, my method (not really my method, but industry standard method) is better general purpose method to recommend to those that learn things.
People with experience will do whatever they do and have their own tricks.
I agree it's worthy of a video. And if you think about it a bit further, you will see that its one of those "you can do it this way too if planets are aligned..." but not really something to rely on.
-
Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.
No. I'm talking about legitimately setting the timebase to capture the thing you wanted, no user error. Then perhaps you saw something unexpected and though "gee I wonder what happened before or after that".
Right ::) again user error........oh hang on something that happened before the trigger caused something you didn't expect.....oh hell does this happen in the real world, of course it does and to not have a scope set to allow for and capture it is user error.
-
Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.
No. I'm talking about legitimately setting the timebase to capture the thing you wanted, no user error. Then perhaps you saw something unexpected and though "gee I wonder what happened before or after that".
I understand what are you saying, but when working on, say, CAN bus, what are the chances you will happen to capture exactly packet with error if you looking at single edge? You don't capture that way looking at that kind of data. You use larger time period, with hundreds of packets and then search and scroll and zoom in and out.
As I say, it is not something I would forbid on a scope. But I don't rely on it, and try to avoid to rely on it. Instead I simply try to capture larger deliberately and be sure I got the data. And you can have a detailed look at a detail both ways...
-
I agree it's worthy of a video. And if you think about it a bit further, you will see that its one of those "you can do it this way too if planets are aligned..." but not really something to rely on.
You do know it's entirely predictable, right? (based on timebase and memory depth) It's not some random quirk.
Even the Keysight has a new Digitizer mode that makes it entirely predictable.
-
Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.
No. I'm talking about legitimately setting the timebase to capture the thing you wanted, no user error. Then perhaps you saw something unexpected and though "gee I wonder what happened before or after that".
I understand what are you saying, but when working on, say, CAN bus, what are the chances you will happen to capture exactly packet with error if you looking at single edge? You don't capture that way looking at that kind of data. You use larger time period, with hundreds of packets and then search and scroll and zoom in and out.
You can't say you understand what I'm saying then immediately go into an example where it's not going to be of value. That is completely opposite to my point!
I'll repeat, there is no logical argument you can make to say that this isn't a potentially useful feature in some circumstances.
-
Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?
-
Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?
Yes, but for capturing events which occur at a relatively low rate that doesn't matter at all.
-
So when nctnico says a scope can't do this very specific (and not fully explained) thing, just ignore it. Because with only a tiny change to any part of the application or acceptable solution, just about any scope will do the job.
Yeah, but he's not wrong.
It's an interesting and demonstrably potentially useful benefit.
But nctnico is wrong to generalise it as something other scopes can't do, because they can but in subtly different ways. Its a very narrow (and poorly/not defined) example to try and push some point like the marketing "comparisons" people keep laughing at.
The case of slow and infrequent triggers allows that type of use, and impedes/prevents acquisition of more rapid events (or they get lost in the long capture). Its a simple tradeoff (or "trap" as you might embellish it) that is chosen for the specific setting.
The inflammatory nature of this discussion has been the refusal of nctnico to acknowledge either the narrow applicability of the use case, or that it can be achieved by using a zoom window/view, or other methods.
Its a massive blow up over different methods to set the memory depth (auto vs manual vs implicit vs explicit).
-
Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.
No. I'm talking about legitimately setting the timebase to capture the thing you wanted, no user error. Then perhaps you saw something unexpected and though "gee I wonder what happened before or after that".
I understand what are you saying, but when working on, say, CAN bus, what are the chances you will happen to capture exactly packet with error if you looking at single edge? You don't capture that way looking at that kind of data. You use larger time period, with hundreds of packets and then search and scroll and zoom in and out.
You can't say you understand what I'm saying then immediately go into an example where it's not going to be of value. That is completely opposite to my point!
I'll repeat, there is no logical argument you can make to say that this isn't a potentially useful feature in some circumstances.
Yes, but as these seem to keep coming back to:
Poster A says a scope is not worth considering because it can't do some very specific feature..... not mentioning how that feature might be useful or what situations might make it applicable.
Poster B points out the holes in their point and explains other comparable methods.
Poster A keeps narrowing the goalposts to be "right"
Time was wasted by all and a confusing mess is left behind. The generalised answer is there are many corner cases for test/measurement and they generally aren't applicable unless that matches the users application.
-
Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?
Yes, which is why "automatic" memory depth usually defaults to the shortest record that will fill the screen.
-
Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?
Yes, which is why "automatic" memory depth usually defaults to the shortest record that will fill the screen.
Not on the Keysight. Try it. Unless you are on a slow timebase like 100ms where all the memory is used to fit the screen and it doesn't have any more to give. On 10us or under (which is where it goes to the max 5GS/s), if you press stop and then zoom out it will give you the extra data outside the display window.
-
We generalise that the 0s trigger point might be in the middle of the display which of course is the most convenient for pre and post trigger capture inspection where in fact many might set the 0s point to the left of the display like a CRO.
A central display 0s setting gives us the greatest advantage of inspecting the largest amount of both pre and post trigger capture and a slow timebase for capture is the ideal allowing for the largest pre and post trigger record.
However we could set the 0s trigger point to the far right of the display if the pre trigger capture will be of greatest interest to us.
These are the very most basic features of a DSO, the power to capture and the power to zoom in on any detail of the capture and anyone ignoring these simple features is not using the tool in front of them to best effect and needs go back to scope school.
-
I feel like you're saying there is never any advantage ever in your life because siglent scopes can't do it. Like it or not I don't want to have a wide timebase to get a capture, zoom in and then zoom back out to catch all the details I want. We're not talking a game changer here, we're talking a shortcut.
-
I feel like you're saying there is never any advantage ever in your life because siglent scopes can't do it.
Oh FFS, do you actually think I've not used other DSO's ? Really ?
My first DSO had 2.5 Kpts memory/channel so to get the best from it you used it wisely.
Even the other 2 laterTeks I had were similarly pitiful.
What are we actually trying to do here, teach the reader some obscure scope usage method rather than proper well know methods that return universally predictable results from any DSO ?
-
Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?
Yes, which is why "automatic" memory depth usually defaults to the shortest record that will fill the screen.
Not on the Keysight. Try it. Unless you are on a slow timebase like 100ms where all the memory is used to fit the screen and it doesn't have any more to give. On 10us or under (which is where it goes to the max 5GS/s), if you press stop and then zoom out it will give you the extra data outside the display window.
Thats a "special" behaviour that is only on a minority of scopes. This has cropped up a few times:
https://www.eevblog.com/forum/testgear/new-keysight-scope-1st-march-2017/msg1125192/#msg1125192 (https://www.eevblog.com/forum/testgear/new-keysight-scope-1st-march-2017/msg1125192/#msg1125192)
https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1282227/#msg1282227 (https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1282227/#msg1282227)
and more recently:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg2895750/#msg2895750 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg2895750/#msg2895750)
Same old names blowing noise and adding FUD left right and centre.
-
I feel like you're saying there is never any advantage ever in your life because siglent scopes can't do it. Like it or not I don't want to have a wide timebase to get a capture, zoom in and then zoom back out to catch all the details I want. We're not talking a game changer here, we're talking a shortcut.
Agreed on both points.
Frankly I'm amazed so many people are so opposed to using a clever shortcut which yields results in the real world. :-//
But since we are here I can make a list with oscilloscope brands which support recording beyond the screen (or not):
GW Instek: yes
Keysight: older models: yes, newer models: single mode only
Lecroy: no
MicSig: yes
Rigol: yes
R&S: yes
Siglent: no
Tektronix: yes
Yokogawa: ?
Edit: added R&S
-
I agree it's worthy of a video. And if you think about it a bit further, you will see that its one of those "you can do it this way too if planets are aligned..." but not really something to rely on.
You do know it's entirely predictable, right? (based on timebase and memory depth) It's not some random quirk.
Even the Keysight has a new Digitizer mode that makes it entirely predictable.
Well, I don't have R&S RTM3000 to try but I believe what Nico say that it WILL be predictable. An as long as you keep it on same (max)sampling rate it will stay the same.
On Keysight 3000T not so much. It has much smaller memory, and will drop sampling rate fast. Full mem in full sample rate in RUN mode is 400 us.
Also digitizer mode has some limits. When you set digitizer mode, if you set scope to sample at max 5GS and have max 4MS (1ch), scope won't let you set time base to slower than 40us/div. Basically, it starts sampling at that fixed speed and memory buffer. It's not setting sampling speed anymore to allow you to go slower. It behaves as digitizer not GP scope.
But that helps little, because result is the same as in normal mode, if you pay attention and not go slower than 40 us/div in run mode.
-
Yet it's arguably DSO user error when any capture is required that an appropriate timebase was not previously selected.
No. I'm talking about legitimately setting the timebase to capture the thing you wanted, no user error. Then perhaps you saw something unexpected and though "gee I wonder what happened before or after that".
I understand what are you saying, but when working on, say, CAN bus, what are the chances you will happen to capture exactly packet with error if you looking at single edge? You don't capture that way looking at that kind of data. You use larger time period, with hundreds of packets and then search and scroll and zoom in and out.
You can't say you understand what I'm saying then immediately go into an example where it's not going to be of value. That is completely opposite to my point!
I'll repeat, there is no logical argument you can make to say that this isn't a potentially useful feature in some circumstances.
I wasn't trying to nullify your point, but as an reply to your hypothetical scenario, i simply gave you real scenario that is source of my opinion. I apologize if it came out as adversarial, it was not meant to be... I'm passionate about things, same as you, and sometimes it gets better of me.
I will also repeat (i understand you cannot read everything) that I repeated few times that I can see how it can be useful and that I even do that on occasion. But I don't rely on it as a important technique.
I'm not against it per se, but I don't think it's a big deal...
-
Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?
Yes, which is why "automatic" memory depth usually defaults to the shortest record that will fill the screen.
Not on the Keysight. Try it. Unless you are on a slow timebase like 100ms where all the memory is used to fit the screen and it doesn't have any more to give. On 10us or under (which is where it goes to the max 5GS/s), if you press stop and then zoom out it will give you the extra data outside the display window.
True. If you stop it will give you exactly 40 us before trigger point, and 360 us after trigger point at 5 GS/s sample rate.
-
So when nctnico says a scope can't do this very specific (and not fully explained) thing, just ignore it. Because with only a tiny change to any part of the application or acceptable solution, just about any scope will do the job.
Yeah, but he's not wrong.
It's an interesting and demonstrably potentially useful benefit.
But nctnico is wrong to generalise it as something other scopes can't do, because they can but in subtly different ways. Its a very narrow (and poorly/not defined) example to try and push some point like the marketing "comparisons" people keep laughing at.
The case of slow and infrequent triggers allows that type of use, and impedes/prevents acquisition of more rapid events (or they get lost in the long capture). Its a simple tradeoff (or "trap" as you might embellish it) that is chosen for the specific setting.
The inflammatory nature of this discussion has been the refusal of nctnico to acknowledge either the narrow applicability of the use case, or that it can be achieved by using a zoom window/view, or other methods.
Its a massive blow up over different methods to set the memory depth (auto vs manual vs implicit vs explicit).
At one previous discussion, he actually admitted that it is same result as using proper time base/ zoom, but that he does this because he dislikes zoom and how it takes up screen real estate. What he does mimics "full screen zoom" and if manufacturers would make "full screen zoom" mode that would be it..
-
But since we are here I can make a list with oscilloscope brands which support recording beyond the screen (or not):
GW Instek: yes
Keysight: older models: yes, newer models: single mode only
The Keysight Megazoom IV does it in both STOP and single shot mode.
-
I'm not against it per se, but I don't think it's a big deal...
I agree, it's not a big deal, and I certainly wouldn't make a purchase decision based on it. It's just an interesting "feature".
Probably video worthy!
-
I vaguely recall that this whole subject started (and then got carved off to a new thread by Dave) because a poster said something to the effect - "this scope doesn't work the way I expect it to and therefore nobody should buy one" - and that was (rightfully IMHO) jumped upon as being unreasonable.
What has followed has been a (somewhat heated) discussion that has given me valuable information in that some scopes actually capture more data than you would actually expect and it's useful to know that when you're looking for obscure data or glitches.
I brought up the (Monty Python) argument reference because, at some point in the sketch one of the men says "An argument is a connected series of statements intended to establish a proposition" which seemed apposite at the time but, in this case, there's no clear right or wrong answer.
It seems to me that different scope manufacturers approach data capture in subtlety different ways and that leaves some people surprised (or irate) when they try out a new brand/model of scope and find that it doesn't work the way they expect it to.
Thanks to all here who've gone to such great lengths to explain in detail how data capture and memory filling actually works and how to leverage it to our advantage.
-
Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?
Yes, which is why "automatic" memory depth usually defaults to the shortest record that will fill the screen.
Not on the Keysight. Try it. Unless you are on a slow timebase like 100ms where all the memory is used to fit the screen and it doesn't have any more to give. On 10us or under (which is where it goes to the max 5GS/s), if you press stop and then zoom out it will give you the extra data outside the display window.
Thats a "special" behaviour that is only on a minority of scopes.
Minority?
Surely it's the same on all Megazzom IV ASIC scopes?
1000, 2000, 3000, and 4000 series (maybe more?)
I've only tried my 3000T
-
What does it mean? Well, when you're on 1ns/div, you get 40000x length worth of data than what is on your screen (10ns to 400us) if you stop it. If you are at 20us/div you get only 2x (200us to 400us).
And from that point on sample rate goes down, and game repeats, changing ratio "screen/stopped capture length" all the time. I guess table could be compiled. It's just I couldn't care less.
I'm not going to base my work based on side-effects of sample engine architecture..
So if you captured something and then thought "gee I wonder what's either side of that, and you knew your scope worked like this, you'd actually rather re-capture instead of just changing the timebase?
That's kinda, well, silly.
If your answer is yes I would, then what happens if your capture was infrequent and wasn't easy to reproduce?
Sorry but I can't see a way to successfully argue this isn't a potentially useful feature.
The thing is that if recording beyond your screen on short timebases was really such a useful feature then the question for me would be why this isn't a standard feature in scopes? It's not difficult to implement after all. Rigol has done it, although I'm sure it probably down to just using a simplistic system of managing memory than to actual intention. But they not even use it for marketing. In fact, I can't remember that any scope manufacturer has ever promoted being able to "zoom out" as one their core features. While even current marketing material still bangs on about being able to "zoom in" on details. And this when all manufacturers are looking for ways to differentiate themselves from the competition. An oversight?
I don't believe so. As I said, I've never came across of any engineer even asking for this feature - aside Nico of course.
It's so interesting it's probably worthy of a video.
II believe it is. Because while I can see where it comes from I still fail to see any advantage to this method, so a video might help. :-+
But since we are here I can make a list with oscilloscope brands which support recording beyond the screen (or not):
GW Instek: yes
Keysight: older models: yes, newer models: single mode only
Lecroy: no
MicSig: yes
Rigol: yes
Siglent: no
Tektronix: yes
Yokogawa: ?
Why don't you list specific models instead? This would make much more sense than a vague list of manufacturers of which most have had decades of different products which may or may not all behave the same.
Because if it's by manufacturers only then I guess Siglent would need a "yes" because if I remember right the very early models (CL? CML?) could be set to record beyond the screen when set to long memory (which, as with Rigol, very likely down to the primitive memory management and not really intentional).
Same thing goes for Tek, because as far as I am aware (well I'm at home now and can't check) it's only the scope models which have Auto-Magnify which fully support your method, which if I remember right is limited to the MDO Series (although the old DPO2k/3k may also have had it). Outside that, I think that there are also some models which run a full length acquisition only on the last acquisition after pressing STOP or in SINGLE, like the Keysight scopes.
And which Keysight "older models" are supposed to support this outside SINGLE mode/STOP? And what about the different Infiniiums? Or the 54700 Series?
And no mention of R&S? Can't check but I don't think they let you sample beyond the screen on short timebases either. Is it supported by the RTM1000? RTM2000? RTM3000? What about the two generations of RTO? I vaguely remember trying once to capture beyond the screen on the RTM1054 and it failed.
Since there doesn't seem to be many who specifically ask for that feature in a scope it would help if you could list some actual *models* that support it (which I'm sure you know it appears you wouldn't buy a scope which doesn't). Because my gut feeling is (can't say for sure because we don't usually test for that kind of thing, simply because no-one has ever asked for it) you will find that this is not widely supported.
-
So when nctnico says a scope can't do this very specific (and not fully explained) thing, just ignore it. Because with only a tiny change to any part of the application or acceptable solution, just about any scope will do the job.
Yeah, but he's not wrong.
It's an interesting and demonstrably potentially useful benefit.
But nctnico is wrong to generalise it as something other scopes can't do, because they can but in subtly different ways. Its a very narrow (and poorly/not defined) example to try and push some point like the marketing "comparisons" people keep laughing at.
The case of slow and infrequent triggers allows that type of use, and impedes/prevents acquisition of more rapid events (or they get lost in the long capture). Its a simple tradeoff (or "trap" as you might embellish it) that is chosen for the specific setting.
The inflammatory nature of this discussion has been the refusal of nctnico to acknowledge either the narrow applicability of the use case, or that it can be achieved by using a zoom window/view, or other methods.
Its a massive blow up over different methods to set the memory depth (auto vs manual vs implicit vs explicit).
At one previous discussion, he actually admitted that it is same result as using proper time base/ zoom, but that he does this because he dislikes zoom and how it takes up screen real estate. What he does mimics "full screen zoom" and if manufacturers would make "full screen zoom" mode that would be it..
Here is the "seed" for this event:
To the OP: Regarding the Siglent: one thing to watch out for is that it uses a different memory management compared to the Tektronix you are used to; Siglent typically cuts the memory short to have just enough samples to fit the screen. This has to match your usage. For me this kind of memory management is a hard fail. All in all it still is a good idea to compare several scopes yourself.
Given the OP had another Siglent scope and had mentioned using an MDO3000 in the past its possibly a bit alarmist. Nothing in there about it being a very specific workflow for a corner case and other ways to do the same thing.
-
Nothing in there about it being a very specific workflow for a corner case and other ways to do the same thing.
Add, universally....that works will all DSO's.
Heavens, what are we attempting to teach future engineers......walk into most any EE establishment and tell them they should be zooming out captures as part of their workflow.....expect to get laughed out of the place !
-
But since we are here I can make a list with oscilloscope brands which support recording beyond the screen (or not):
GW Instek: yes
Keysight: older models: yes, newer models: single mode only
Lecroy: no
MicSig: yes
Rigol: yes
Siglent: no
Tektronix: yes
Yokogawa: ?
Why don't you list specific models instead? This would make much more sense than a vague list of manufacturers of which most have had decades of different products which may or may not all behave the same.
Because if it's by manufacturers only then I guess Siglent would need a "yes" because if I remember right the very early models (CL? CML?) could be set to record beyond the screen when set to long memory (which, as with Rigol, very likely down to the primitive memory management and not really intentional).
Same thing goes for Tek, because as far as I am aware (well I'm at home now and can't check) it's only the scope models which have Auto-Magnify which fully support your method, which if I remember right is limited to the MDO Series (although the old DPO2k/3k may also have had it). Outside that, I think that there are also some models which run a full length acquisition only on the last acquisition after pressing STOP or in SINGLE, like the Keysight scopes.
And which Keysight "older models" are supposed to support this outside SINGLE mode/STOP? And what about the different Infiniiums? Or the 54700 Series?
And no mention of R&S? Can't check but I don't think they let you sample beyond the screen on short timebases either. Is it supported by the RTM1000? RTM2000? RTM3000? What about the two generations of RTO? I vaguely remember trying once to capture beyond the screen on the RTM1054 and it failed.
Recent R&S scopes have an auto memory depth setting, they may well be able to capture around the visible window and don't explicitly mention that the record length will be reduced for short timebases (a few forum goers have them so hopefully one checks it).
Tek DPO4000 certainly kept all the memory around the visible window. Which meant having to play around with the memory depth setting (lacked an auto mode?).
-
Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?
Yes, which is why "automatic" memory depth usually defaults to the shortest record that will fill the screen.
Not on the Keysight. Try it. Unless you are on a slow timebase like 100ms where all the memory is used to fit the screen and it doesn't have any more to give. On 10us or under (which is where it goes to the max 5GS/s), if you press stop and then zoom out it will give you the extra data outside the display window.
Thats a "special" behaviour that is only on a minority of scopes. This has cropped up a few times:
https://www.eevblog.com/forum/testgear/new-keysight-scope-1st-march-2017/msg1125192/#msg1125192 (https://www.eevblog.com/forum/testgear/new-keysight-scope-1st-march-2017/msg1125192/#msg1125192)
https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1282227/#msg1282227 (https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1282227/#msg1282227)
and more recently:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg2895750/#msg2895750 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg2895750/#msg2895750)
Minority?
Surely it's the same on all Megazzom IV ASIC scopes?
1000, 2000, 3000, and 4000 series (maybe more?)
I've only tried my 3000T
There are many more scopes on the market than Keysight Megazoom units. But the point is that you don't magically get the full memory depth around a trigger, unless that happens to be a repetitive trigger falling within some (surprisingly narrow) circumstances. Rather than typing out the rather long explanation needed to explain when/how it happens I linked back to the existing posts.
For all megazoom "just works" automatic choices, some people see that as confusing or hard to force it to do exactly what they want, while others see it as eliminating unnecessary detail/traps. The memory depths are all over the place in different modes/channels/overlays. But they're always as long as practically possible, only overflowing the visible window under those "special" circumstances or by using single shot capture. As mentioned before I don't ever worry about the exact number of memory points, just check the sample rate and horizontal time will be sufficient to capture what I'm trying to look at.
-
Bumping around a couple of different manufacturers manuals, something looked rather similar....
guess the two brands!
-
Stuck with just three scopes at home ;) I just tried to capture off screen with my Rigol DS1054z (firmware 00.04.04SP4) and guess what?
It doesn't let me go beyond the screen.
So it appears at least for the DS1000z the question if Nico's method would be possible should be answered with 'no'.
-
There are many more scopes on the market than Keysight Megazoom units.
Megazoom is the entirety of Keysights range under maybe $20k or more, so it's safe to say that a Megazoom scope is the Keysight scope that most people will buy.
-
Recent R&S scopes have an auto memory depth setting, they may well be able to capture around the visible window and don't explicitly mention that the record length will be reduced for short timebases (a few forum goers have them so hopefully one checks it).
That could well be the case. Would be interesting to get some feedback from a few R&S scope owners.
Tek DPO4000 certainly kept all the memory around the visible window. Which meant having to play around with the memory depth setting (lacked an auto mode?).
I'm not surprised, the MDO is, after all, just a pimped up DPO.
It could really be interesting (even just from a point of curiosity) if people could check their scopes and post the results here. I'm sure we could assemble a quite comprehensive list.
-
It doesn't let me go beyond the screen.
I´m not really sure ( as a former rigol owner), but the "bigger" MSO5000 couldn´t do that too.
Maybe a actual owner could test and report it here.
-
There are many more scopes on the market than Keysight Megazoom units.
Megazoom is the entirety of Keysights range under maybe $20k or more, so it's safe to say that a Megazoom scope is the Keysight scope that most people will buy.
And now you're the one taking a general question, and narrowing it down just to highlight some specific brand/feature.... go back to the full quote tower and look at the question:
Doesn't capturing data outside the display window => more time to capture data => less waveform updates per second?
Yes, which is why "automatic" memory depth usually defaults to the shortest record that will fill the screen.
Not on the Keysight. Try it. Unless you are on a slow timebase like 100ms where all the memory is used to fit the screen and it doesn't have any more to give. On 10us or under (which is where it goes to the max 5GS/s), if you press stop and then zoom out it will give you the extra data outside the display window.
Thats a "special" behaviour that is only on a minority of scopes. This has cropped up a few times:
https://www.eevblog.com/forum/testgear/new-keysight-scope-1st-march-2017/msg1125192/#msg1125192 (https://www.eevblog.com/forum/testgear/new-keysight-scope-1st-march-2017/msg1125192/#msg1125192)
https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1282227/#msg1282227 (https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1282227/#msg1282227)
and more recently:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg2895750/#msg2895750 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg2895750/#msg2895750)
Minority?
Surely it's the same on all Megazzom IV ASIC scopes?
1000, 2000, 3000, and 4000 series (maybe more?)
I've only tried my 3000T
There are many more scopes on the market than Keysight Megazoom units. But the point is that you don't magically get the full memory depth around a trigger, unless that happens to be a repetitive trigger falling within some (surprisingly narrow) circumstances. Rather than typing out the rather long explanation needed to explain when/how it happens I linked back to the existing posts.
For all megazoom "just works" automatic choices, some people see that as confusing or hard to force it to do exactly what they want, while others see it as eliminating unnecessary detail/traps. The memory depths are all over the place in different modes/channels/overlays. But they're always as long as practically possible, only overflowing the visible window under those "special" circumstances or by using single shot capture. As mentioned before I don't ever worry about the exact number of memory points, just check the sample rate and horizontal time will be sufficient to capture what I'm trying to look at.
Megazoom is the entirety of Keysights range under maybe $20k or more, so it's safe to say that a Megazoom scope is the Keysight scope that most people will buy.
Capturing samples outside the visible window reduces the theoretically achievable update rate, on scopes that let you control that its measurable and quite significant (https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038 (https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038)). The Keysight megazoom scopes do not capture all the data around the window, they only do a magic capture from run -> stop mode under quite specific circumstances.....
After pressing stop, another trigger must arrive within the next 100mS or so, but not before the several mS or so it takes to fill the pre trigger and overheads (varies depending on scope, mode, etc). Otherwise there is only the current visible window (plus a little extra margin sometimes). So many specifics and details, all of which may or may not apply to any particular use. Confusing! Not even specified or warranted behaviour. Certainly not:
Unless you are on a slow timebase like 100ms where all the memory is used to fit the screen and it doesn't have any more to give. On 10us or under (which is where it goes to the max 5GS/s), if you press stop and then zoom out it will give you the extra data outside the display window.
-
Stuck with just three scopes at home ;) I just tried to capture off screen with my Rigol DS1054z (firmware 00.04.04SP4) and guess what?
It doesn't let me go beyond the screen.
So it appears at least for the DS1000z the question if Nico's method would be possible should be answered with 'no'.
How bizarre, I was able to have that type of setup on an 1104Z:
https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038 (https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038)
-
It doesn't let me go beyond the screen.
I´m not really sure ( as a former rigol owner), but the "bigger" MSO5000 couldn´t do that too.
Maybe a actual owner could test and report it here.
Stuck with just three scopes at home ;) I just tried to capture off screen with my Rigol DS1054z (firmware 00.04.04SP4) and guess what?
It doesn't let me go beyond the screen.
So it appears at least for the DS1000z the question if Nico's method would be possible should be answered with 'no'.
DS1000z behaves differently if you set it to AUTO or if you manually fix acquisition length. One more thing to add to confusion.
But if you set to 24 MS length (1ch) it will get 24 MS every time, even if you set timebase to 5 ns/div. But your retrigger rate will be the same as if you set timebase to 2ms/div (12divs, 24ms full screen).
Detail will be the same too, and it will do both at 1GS/s. And with DS1000z , you don't even have to go into zoom mode. Timebase knob works even when stopped. So you capture at any timebase from 5ns/div to 2ms/div and get the same memory content and look at it with timebase knob and horizontal pos knob. Or you can use zoom if you like that.
-
Stuck with just three scopes at home ;) I just tried to capture off screen with my Rigol DS1054z (firmware 00.04.04SP4) and guess what?
It doesn't let me go beyond the screen.
So it appears at least for the DS1000z the question if Nico's method would be possible should be answered with 'no'.
How bizarre, I was able to have that type of setup on an 1104Z:
https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038 (https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038)
Maybe it was fixed (broken? ;) ) in one of the recent firmware updates.
-
Stuck with just three scopes at home ;) I just tried to capture off screen with my Rigol DS1054z (firmware 00.04.04SP4) and guess what?
It doesn't let me go beyond the screen.
So it appears at least for the DS1000z the question if Nico's method would be possible should be answered with 'no'.
How bizarre, I was able to have that type of setup on an 1104Z:
https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038 (https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038)
Maybe it was fixed (broken? ;) ) in one of the recent firmware updates.
Unfortunately, I don't have DS1000Z anymore to check... But what I remember it did behave like Someone says..
-
DS1000z behaves differently if you set it to AUTO or if you manually fix acquisition length.
I tried both, didn't made a difference. I could not zoom out beyond the screen data.
One more thing to add to confusion.
But if you set to 24 MS length (1ch) it will get 24 MS every time, even if you set timebase to 5 ns/div. But your retrigger rate will be the same as if you set timebase to 2ms/div (12divs, 24ms full screen).
Detail will be the same too, and it will do both at 1GS/s. And with DS1000z , you don't even have to go into zoom mode. Timebase knob works even when stopped. So you capture at any timebase from 5ns/div to 2ms/div and get the same memory content and look at it with timebase knob and horizontal pos knob. Or you can use zoom if you like that.
Maybe that's it, I used the zoom function.
I'll try later with just going to STOP and just twiddling the timebase knob.
Update: I tried just changing the timebase, and with the memory set to manual it did indeed show the full 24Mpts. I did note some artifacts which aren't in the signal, though, so I'm not sure if this behavior is intentional
-
I didn't realize this was so contentious? - on my old Agilent 54622D megazoom, I take it completely for granted that you can zoom both in and out (provided the horizontal speed is high enough) and I use it all the time when exploring new waveforms where it is hard to say what is going to be the best timebase - I thought this is just one of the many awesome convenience advantages of a digital scope! :D
-
I didn't realize this was so contentious? - on my old Agilent 54622D megazoom, I take it completely for granted that you can zoom both in and out (provided the horizontal speed is high enough) and I use it all the time when exploring new waveforms where it is hard to say what is going to be the best timebase - I thought this is just one of the many awesome convenience advantages of a digital scope! :D
I no longer have a 54622D but I don't think it worked any different than all the InfiniVision scopes - they only use the max available memory on short timebases if you're either in SINGLE or on the last acquisition after pressing STOP.
It's *not* about just changing the timebase to change the time period displayed on screen.
-
It doesn't let me go beyond the screen.
I´m not really sure ( as a former rigol owner), but the "bigger" MSO5000 couldn´t do that too.
Maybe a actual owner could test and report it here.
The MSO7000 can. It would be surprising if MSO5000 can't.
-
Give me a specific test to try and I'll run it on my MSO5074
-
I vaguely recall that this whole subject started (and then got carved off to a new thread by Dave) because a poster said something to the effect - "this scope doesn't work the way I expect it to and therefore nobody should buy one" - and that was (rightfully IMHO) jumped upon as being unreasonable.
Just for clarity: I wrote that for me (personally) it is a hard fail.
-
Since there doesn't seem to be many who specifically ask for that feature in a scope it would help if you could list some actual *models* that support it (which I'm sure you know it appears you wouldn't buy a scope which doesn't). Because my gut feeling is (can't say for sure because we don't usually test for that kind of thing, simply because no-one has ever asked for it) you will find that this is not widely supported.
Well, the majority of the major brands seem to bring out scopes which support recording beyond the screen. Since architectural choices are likely to be constant I don't quite follow how you still come to the conclusion it is not widely supported. All the evidence points in the other direction! Sure there will be some models which behave differently so it is wise to check a particular model during the test drive but in general the list with brands is a good starting point. We could go through the effort of listing specific models but that will likely need to start at listing platforms / series.
BTW: I edited my posting and added R&S to the list (marked with yes).
-
Give me a specific test to try and I'll run it on my MSO5074
Set the oscilloscope to 100ns / division, set the memory depth to the maximum number, connect the probe to the calibrator output, set the trigger level to trigger on the signal, set the scope to run mode, disconnect the probe (so no more trigger events; do not press stop!), turn the time/div knob to 200ns/ division. If you get more signal then your scope supports recording beyond the screen.
-
I feel like you're saying there is never any advantage ever in your life because siglent scopes can't do it.
Oh FFS, do you actually think I've not used other DSO's ? Really ?
My first DSO had 2.5 Kpts memory/channel so to get the best from it you used it wisely.
Even the other 2 laterTeks I had were similarly pitiful.
What are we actually trying to do here, teach the reader some obscure scope usage method rather than proper well know methods that return universally predictable results from any DSO ?
No, I think you've used other scopes. Your argument seems to be not every scope can do it so people shouldn't do it or talk about it? I'm really confused about people being vehemently against this when it's just another way to use the tool. Plenty of scopes can do things my scopes can't but I'm not telling them they don't know how to use a DSO because they use those available features.
Some people don't see the point in doing it and that's fine but it's still another method to do a job regardless your feelings. It's literally capture and zoom out(or scroll to the point of interest) OR capture and zoom in, then zoom back out again(or scroll to the point of interest). One of these is the shortcut.
-
Set the oscilloscope to 100ns / division, set the memory depth to the maximum number, connect the probe to the calibrator output, set the trigger level to trigger on the signal, set the scope to run mode, disconnect the probe (so no more trigger events; do not press stop!), turn the time/div knob to 200ns/ division. If you get more signal then your scope supports recording beyond the screen.
Shouldn´t be the trigger set to "manual" in this case ?
-
Set the oscilloscope to 100ns / division, set the memory depth to the maximum number, connect the probe to the calibrator output, set the trigger level to trigger on the signal, set the scope to run mode, disconnect the probe (so no more trigger events; do not press stop!), turn the time/div knob to 200ns/ division. If you get more signal then your scope supports recording beyond the screen.
Shouldn´t be the trigger set to "manual" in this case ?
Good point. I forgot to mention the trigger mode should be set to 'normal'. Not single, not automatic.
-
A 1khz Signal and then 100ns ?
Nevertheless, I´ve just tried it out on the sds2104x+ and the signal disappear.
Now it´s your turn, Gandalf_Sr….
-
Give me a specific test to try and I'll run it on my MSO5074
Set the oscilloscope to 100ns / division, set the memory depth to the maximum number, connect the probe to the calibrator output, set the trigger level to trigger on the signal, set the scope to run mode, disconnect the probe (so no more trigger events; do not press stop!), turn the time/div knob to 200ns/ division. If you get more signal then your scope supports recording beyond the screen.
I did this simple test. To clarify, the scope has to be in 'normal' mode or it will retrigger itself after the probe is removed from the calibrator output.
Anyway, after the probe was disconnected, I could wind the horizontal axis all the way out to 10 mS/div and still see valid waveform so it looks like the MSO5000 does capture outside the visible screen area.
-
Actually, I need to clarify. After the capture is done, turning the horizontal time control to zoom out shows the captured memory area in the little zoom window top center. At some point, 5 mS/div, it clearly runs out of displayable data and the picture doesn't change even though the indication of the x axis time does - which seems like a bug to me as you could end up looking at a display where the x axis time shown isn't correct for the displayed trace.
-
Give me a specific test to try and I'll run it on my MSO5074
Set the oscilloscope to 100ns / division, set the memory depth to the maximum number, connect the probe to the calibrator output, set the trigger level to trigger on the signal, set the scope to run mode, disconnect the probe (so no more trigger events; do not press stop!), turn the time/div knob to 200ns/ division. If you get more signal then your scope supports recording beyond the screen.
In that case, if that is criteria (not pressing STOP) Keysight 3000T doesn't capture anything outside screen in normal mode.
Only when set to digitizer mode, in which case it becomes little wierd to setup, and is not really how you want it for normal interactive mode....
Set to 100ns / division, burst from siggen, trigger set to normal, waiting for next trigger in RUN mode, STOP not pressed:
[attachimg=1]
Still waiting for next trigger, timebase expanded to 200ns / division
[attachimg=2]
This shows what I'we been explaining. 3000T is capturing only screen full of data from trigger to trigger. It is only when you press stop that it will reassemble some data before begin of the screen, and it will keep capturing until it runs after memory. What I suspect is that it literally goes from RUN to STOP, by capturing one SINGLE capture on next trigger after you press STOP (Just with half of the buffer because of state of capture engine at the time, the ping-pong buffers).
I presume it behaves like that, because, if press stop now, while it's waiting for next trigger, it doesn't get any additional data:
[attachimg=3]
So Keysight 3000T can't be used that way, unless it is in DIGITIZER mode, that makes using scope weird for interactive use, negating all user friendliness and ease of use Keysight is famous for.
I would presume all current generation Infiniivision scopes will have same behaviour (chipset related).
If anybody needs any other test, let me know.
Regards,
-
A further test...
1. Set up a decoder for RS232 at 230,400 Baud on Ch1 with correct polarity and threshold level.
2. Press the mode button until (Normal) appears on the screen briefly
3. Press [Acquire] and set memory depth to max (200M in my case)
3. Monitor RS232 signal with probe and then disconnect to see data frozen on screen with decode data shown below trace
4. start zooming out and notice that top center zoom window (if that's what it's called) is mostly white (that white represents captured data) and there's a small black area that moves as you scroll left and right. It gets bigger as you zoom out and it's indicating the area that's shown on the main screen.
5. In this test I was able to see oodles of data before and after the trigger point and it was all decoded as I looked at it on the main screen
That was fun :D
-
..and I can do the same in Auto mode or if I press Stop, or if I do a single trigger. There is a boat load of data captured and it's either side of the trigger point.
[EDIT] But it only does this if I manually set the memory depth to max; if the memory depth is set to 'Auto' then the behavior is just like the pictures posted by 2N3055
-
Hello,
some pictures from RTA4004.
If you want samples outside of the windows you can use a fix memory size.
If you use auto it can be samples outside windows but not in all cases.
Best regards
egonotto
-
Yea, I've noticed(on the rtb) it's not uncommon to have data outside of the window even in auto memory.
-
Yea, I've noticed(on the rtb) it's not uncommon to have data outside of the window even in auto memory.
I think R&S is using one of the fixed memory length selections and not an arbitrary length in auto memory mode.
-
So the rule seems to be that, in Auto setting, the scopes (usually) only capture what fits on the screen.
-
Hello,
nctnico wrote:
"I think R&S is using one of the fixed memory length selections and not an arbitrary length in auto memory mode"
But the memory size in auto mode can differ from the selection of fix memory size. (for example 1.26KSa)
Best regards
egonotto
-
Yea, I've noticed(on the rtb) it's not uncommon to have data outside of the window even in auto memory.
I think R&S is using one of the fixed memory length selections and not an arbitrary length in auto memory mode.
It's possible they have steps in auto, I have seen odd numbers like 19.7M though. Also like egonotto most of the smaller memory sizes aren't user selectable. It seems like perhaps the auto selections are optimized for history/segmented memory modes.
-
Yea, I've noticed(on the rtb) it's not uncommon to have data outside of the window even in auto memory.
I think R&S is using one of the fixed memory length selections and not an arbitrary length in auto memory mode.
It's possible they have steps in auto, I have seen odd numbers like 19.7M though. Also like egonotto most of the smaller memory sizes aren't user selectable. It seems like perhaps the auto selections are optimized for history/segmented memory modes.
That seems more likely indeed.
-
I didn't realize this was so contentious? - on my old Agilent 54622D megazoom, I take it completely for granted that you can zoom both in and out (provided the horizontal speed is high enough) and I use it all the time when exploring new waveforms where it is hard to say what is going to be the best timebase - I thought this is just one of the many awesome convenience advantages of a digital scope! :D
I no longer have a 54622D but I don't think it worked any different than all the InfiniVision scopes - they only use the max available memory on short timebases if you're either in SINGLE or on the last acquisition after pressing STOP.
It's *not* about just changing the timebase to change the time period displayed on screen.
Agreed, you have to press STOP to catch the last triggered event of a running signal, or do a single shot. Then, zooming out works. (It doesn't work with signals triggered in NORMAL mode.)
The timebase has to be <=1ms on this particular scope or there is no extra data outside the screen area. I guess the reason for that is that at 2ms, the entire memory is filled just by what is displayed on the screen. (20ms * 200mSamples/sec = 4 Mbytes... surprisingly, exactly the amount of RAM the scope has for analog acquisition!)
With two channels turned on... the amount of memory is halved, effectively, so now there is no "unseen data" unless the timebase is <=2ms, instead of <=1ms.
-
I have used this in the past, and IIRC the old TDS3054 couldn't do it due to the puny memory it had. However I vaguely recall my old DS1102E doing a scrolling/zooming only on slower timebases, but my current DS4014 with its vast 140MS memory does that easily.
-
I didn't realize this was so contentious? - on my old Agilent 54622D megazoom, I take it completely for granted that you can zoom both in and out (provided the horizontal speed is high enough) and I use it all the time when exploring new waveforms where it is hard to say what is going to be the best timebase - I thought this is just one of the many awesome convenience advantages of a digital scope! :D
As a side note: it could be I have picked up this trick when using the 54622D or the (I think earlier) 54645D at one of my employers.
-
DS1000z behaves differently if you set it to AUTO or if you manually fix acquisition length.
I tried both, didn't made a difference. I could not zoom out beyond the screen data.
One more thing to add to confusion.
But if you set to 24 MS length (1ch) it will get 24 MS every time, even if you set timebase to 5 ns/div. But your retrigger rate will be the same as if you set timebase to 2ms/div (12divs, 24ms full screen).
Detail will be the same too, and it will do both at 1GS/s. And with DS1000z , you don't even have to go into zoom mode. Timebase knob works even when stopped. So you capture at any timebase from 5ns/div to 2ms/div and get the same memory content and look at it with timebase knob and horizontal pos knob. Or you can use zoom if you like that.
Maybe that's it, I used the zoom function.
I'll try later with just going to STOP and just twiddling the timebase knob.
Update: I tried just changing the timebase, and with the memory set to manual it did indeed show the full 24Mpts. I did note some artifacts which aren't in the signal, though, so I'm not sure if this behavior is intentional
Yep, another of the corners for nctnico's atypical use case, rejection of zoom mode. You went with the obvious/logical use case!
Zoom mode adds one very important control that is missing when letting the scope expand around the visible window: you gain control of where the trigger is located within the full capture depth.
-
Well you learn something every day :)
-
So what we know now is, that some scopes can do the "nico way", others don´t.
Does it bother me ? No.
Apart from this I wonder, what siglent will do with it´s waste amount of memory ( 200MP/250MP SDS 2K+/SDS5K) when only could used in lower timebases.
-
So what we know now is, that some scopes can do the "nico way", others don´t.
Does it bother me ? No.
Apart from this I wonder, what siglent will do with it´s waste amount of memory ( 200MP/250MP SDS 2K+/SDS5K) when only could used in lower timebases.
Use it for always running history mode that is very useful. Or segmented (sequential in Siglent parlance) acquisitions.
-
So what we know now is, that some scopes can do the "nico way", others don´t.
Does it bother me ? No.
Apart from this I wonder, what siglent will do with it´s waste amount of memory ( 200MP/250MP SDS 2K+/SDS5K) when only could used in lower timebases.
Use it for always running history mode that is very useful. Or segmented (sequential in Siglent parlance) acquisitions.
Fast realtime update rates + a circular segmented/history buffer is a great combination.
-
Zoom mode adds one very important control that is missing when letting the scope expand around the visible window: you gain control of where the trigger is located within the full capture depth.
Basically you are trying to argue that you always should use an automatic transmission (of a car) in manual mode so you have full control without even questioning whether you actually need full control. To make the car analogy complete: you can use an automatic transmission in manual mode but you can't use a manual transmission in automatic mode. It should be obvious that a car with an automatic transmission needs less intervention from the driver to select the right gear.
-
Zoom mode adds one very important control that is missing when letting the scope expand around the visible window: you gain control of where the trigger is located within the full capture depth.
Basically you are trying to argue that you always should use an automatic transmission (of a car) in manual mode so you have full control without even questioning whether you actually need full control. To make a car analogy: you can use an automatic transmission in manual mode but you can't use a manual transmission in automatic mode.
Its much more like you so strongly prefer the manual shift pattern with reverse above 1st that you bring up "workflow" issues when anyone mentions a vehicle using anything else.
P.S. Relying on symmetric (undefined?) expansion around the window is having less control over the trigger position.... less control. Ideally a scope would have all those parameters broken out separately, but I don't know of any that do as its such an unusual use case.
-
Perhaps you should read more careful... there are at least 3 others which use an oscilloscope the same way.
And there is no less control over the trigger position; triggering works just fine. I don't care about how much data there is exactly at either sides of the trigger point as long as it is enough. The more memory an oscilloscope can use the lower the chance that it isn't enough. Just like an automatic gearbox. As long as the car is moving the way I want it to move I don't care about the gear and engine RPM. I might want to go to manual mode to overtake quickly but after that back to full automatic.
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.
-
Or we could just start the car in gear because pressing of the clutch is just another further unnecessary operation ! :horse:
An old fuddy duddy down the road never liked going up through the box so instead would ring the hell out of the engine in 1st so to be able to next drop it into 4th. ::)
Talking of gear shift patterns, ever driven a Road Ranger box where the creeper gear is directly above reverse ?
-
Or we could just start the car in gear because pressing of the clutch is just another further unnecessary operation ! :horse:
That is another advantage of an automatic gearbox; you don't have to press the clutch pedal. Good point!
-
Or we could just start the car in gear because pressing of the clutch is just another further unnecessary operation ! :horse:
That is another advantage of an automatic gearbox; you don't have to press the clutch pedal. Good point!
::)
Another thing you haven't properly thought through.
You can't start an auto in gear and once started you need to select D after pressing the foot brake and the guy that started the manual in gear is already way off down the road !
-
Or we could just start the car in gear because pressing of the clutch is just another further unnecessary operation ! :horse:
That is another advantage of an automatic gearbox; you don't have to press the clutch pedal. Good point!
::)
Another thing you haven't properly thought through.
You can't start an auto in gear and once started you need to select D after pressing the foot brake and the guy that started the manual in gear is already way off down the road !
But you don't need your left foot at all. But let's stop discussing car gears.
The point is that it makes no sense trying to argue that less is somehow more. In the real world less is just less. Use your time to point Siglent to this thread and add this feature. Likely it is 3 lines of extra code. Maybe they can beat Dave to making a video showing how it doesn't work on Siglent scopes but it does work on Rigol's 8)
-
Use your time to point Siglent to this thread and add this feature. Likely it is 3 lines of extra code.
If it were that simple, why not.
Having is better than needing.
But there must be a reason why they haven´t done this so far.
-
So, after all, if Siglent introduces "nico's way" all is settled? :phew: Finally I'm starting to see the light! :D
Thanks guys.
-
Keep in mind this is *not* "zooming out"as having your scope in normal mode and just changing the timebase so you can see more of the signal, which again works on every scope. It's really about if a scope can record beyond its screen on very short timebases when the memory is set accordingly, which is only visible in a single acquisition.
Older DSOs used to behave like this. I just checked using the first DSO I ever bought with my own money - an Agilent DSO1014A (actually made by Rigol, but that's not relevant). It has a stunning 20,000 points of memory per channel (in 2-channel mode) and a 2Gsps ADC (again in 2 channel mode). Furthermore, it has the Tek-inspired memory-use display above the main window. This shows what is on the screen as a fraction of the whole memory. NewFile0.png shows the situation for X scales of 500ns/div and longer. Data is captured beyond the screen limits, and in Single or Stop mode you can increase the X scale by just less than two ranges, i.e. you get a full screen trace at 1us/div but only 8 divisions' worth at 2us/div.
If the X scale is reduced to 50ns/div you get the situation shown in NewFile1. The screen occupies a smaller fraction of the total memory, and you can now increase the X scale to 500ns/div while maintaining a full display.
On entry-level DSOs of this era and before, there is no way of varying the amount of memory used, as it was so small to begin with. Waveform update rate is limited by the acquisition engine (to 400 wfm/s), not by the number samples captured at each trigger. At higher price points, the amount of memory increased, but the ADC rate not so much. Hence, for shorter X scales (limited by the ADC sample rate), the amount of 'off-screen' memory may also be increased. At longer X scales (= 'slower timebases') the increased memory is used instead to increase the ADC sample rate. Thus short X scales allow you to zoom out more than you can zoom in, and the other way round for long X scales
It was perhaps using a scope from this era (like, e.g. the Agilent 54645) that @nctnico developed his 'zooming out' technique. It worked because, fortuitously, the X scale setting needed to show the details of the data frame was in the 'zooming out' optimised range.
The subsequent increases in ADC sample rate, and more particularly the waveform update rate wars, changed this situation again. With user-controlled memory depth, the oscilloscope designer still has to choose between using additional allocated memory to increase the ADC sample rate, thereby allowing more levels of zooming in, or to increase the off-screen capture length, allowing more levels of zooming out. Because the latter option also reduces the headline waveform update rate (because each waveform is longer), it tended to lose out. Maybe this is why @nctnico so disparages waveform update rate as a parameter - because it goes against his way of using the scope?
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides.
It's only relevant if designing in this feature was done at the sacrifice of update rate in the design.
Obviously with Keysight having the fastest update rate and having this feature, that's obviously not a trade off that needs to be made in basic scope design.
-
And there is no less control over the trigger position; triggering works just fine. I don't care about how much data there is exactly at either sides of the trigger point as long as it is enough. The more memory an oscilloscope can use the lower the chance that it isn't enough.
When letting the memory depth define the size of the acquisition around the window and viewing the fast edge/information at the trigger point which you have insisted is so important to this corner case workflow, yes you have almost no control over the positioning of that extra memory.
[<------- acquisition ------- [ ---- trigger -----]------- acquisition ------->]
The trigger (while still being visible) can only be within the viewing window (not drawn to scale), roughly in the middle of the complete acquisition. If instead you use a zoomed window then the trigger can be placed anywhere within the acquisition depth while still keeping the trigger point visible:
[<-[ trigger ---------] ----------------------------- acquisition ----------->]
or
[<-------------- acquisition ----------------------------[--------- trigger]->]
etc
For someone who has gone on and on about certain scopes having less memory under different modes etc, potentially throwing away half your memory and claiming its completely under control is hypocrisy.
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.
Waveform update rate is limited by letting the acquisition length expand around the visible window, to claim there is no downside in doing so is plainly ridiculous. You like having manual control of memory depth and it expanding around the screen, we keep hearing this and get it, but your justifications are nonsense, and you throw it out as some big issue when it really isn't.
Perhaps you should read more careful... there are at least 3 others which use an oscilloscope the same way.
Enjoy your confirmation bias, perhaps you'd find solace with the flat earthers: https://forum.tfes.org
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides.
It's only relevant if designing in this feature was done at the sacrifice of update rate in the design.
Obviously with Keysight having the fastest update rate and having this feature, that's obviously not a trade off that needs to be made in basic scope design.
But that only works because when you press Stop, the Keysight scopes make one last acquisition using the maximum available memory (providing a trigger arrives in time). It's a neat trick, and it does work.
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides.
It's only relevant if designing in this feature was done at the sacrifice of update rate in the design.
Obviously with Keysight having the fastest update rate and having this feature, that's obviously not a trade off that needs to be made in basic scope design.
Unless they patented it.
This kind of thing is the USPTO's bread and butter. "We claim: 1. A digital oscilloscope that doesn't suck."
-
This shows what I'we been explaining. 3000T is capturing only screen full of data from trigger to trigger. It is only when you press stop that it will reassemble some data before begin of the screen, and it will keep capturing until it runs after memory. What I suspect is that it literally goes from RUN to STOP, by capturing one SINGLE capture on next trigger after you press STOP (Just with half of the buffer because of state of capture engine at the time, the ping-pong buffers).
I presume it behaves like that, because, if press stop now, while it's waiting for next trigger, it doesn't get any additional data:
(Attachment Link)
That sounds right. It's doing just the screen worth in Normal or Auto mode because it needs the fastest update rate possible. There is no point capturing continuous updating data outside the screen if the user can't see it.
So yes, doesn't surprise me that this only works in STOP or Single mode, because these modes are, practically by their usage definition, analysis modes were you may want to expand the timebase to view that extra data. So when the scope has been instructed perform STOP or Single mode it makes sense to then capture the entire available memory length regardless of what the user has set, because update rate no longer has any relevance.
Come to think of it this way now, there should be absolutely no reason why the likes of Siglent could not implement this easily with a firmware update. The likely reason they haven't is because they just haven't thought of it before.
To summarise, I think STOP mode or Single Mode should ultislise all available hardware memory regardless of current memory setting and at the fastest sample rate. This is clearly what Keysight have opted to do.
And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides.
It's only relevant if designing in this feature was done at the sacrifice of update rate in the design.
Obviously with Keysight having the fastest update rate and having this feature, that's obviously not a trade off that needs to be made in basic scope design.
Except they are mutually exclusive, the bonus full length capture of the megazoom scopes only occurs when there is another trigger after pressing stop. If you're trying to capture long record lengths of short bursts between infrequent events, pressing stop won't help.
All that extra memory around the aquisition window kills waveform update rates (a tradeoff which is completely acceptable for some uses). Here is the plot from a Tek DPO4000:
(https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/?action=dlattach;attach=342639;image)
Extending the acquisition buffer each side of the trigger outside the window on the screen is shown with dotted lines toward the right. It knocks orders of magnitude off the update rate.
Although there are more intelligent memory management options, scopes are rather simple/dumb. They won't redraw/paint another trigger until the full memory depth is filled. So at 5GS/s and 10M memory depth, even a perfect zero overhead, instant trigger will only run 500 updates/s.
-
Because the latter option also reduces the headline waveform update rate (because each waveform is longer), it tended to lose out. Maybe this is why @nctnico so disparages waveform update rate as a parameter - because it goes against his way of using the scope?
No. In some case having lots of waveforms/s is useful; setting the memory length shorter either manually or automatically gets you the highest waveform update. You can have the best of everything no matter what.
My beef with waveforms/s is that it is a number used purely for marketing wankery because the maximum number is only achieved in very specific use cases which don't represent actual use cases. The number of waveforms/s is highest with the least number of points, where the trigger dead-time versus acquisition time is at an optimum and (usually) in dot mode only. This means that you'll be looking at a screen with a whole bunch of dots instead of a signal in some cases.
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides.
It's only relevant if designing in this feature was done at the sacrifice of update rate in the design.
Obviously with Keysight having the fastest update rate and having this feature, that's obviously not a trade off that needs to be made in basic scope design.
But that only works because when you press Stop, the Keysight scopes make one last acquisition using the maximum available memory (providing a trigger arrives in time). It's a neat trick, and it does work.
Ah, you just came to the same conclusion I did in my post above!
That's exactly what Keysight have elected to do, and I think it's smart.
-
Or we could just start the car in gear because pressing of the clutch is just another further unnecessary operation ! :horse:
That is another advantage of an automatic gearbox; you don't have to press the clutch pedal. Good point!
::)
Another thing you haven't properly thought through.
You can't start an auto in gear and once started you need to select D after pressing the foot brake and the guy that started the manual in gear is already way off down the road !
But you don't need your left foot at all. But let's stop discussing car gears.
The point is that it makes no sense trying to argue that less is somehow more. In the real world less is just less. Use your time to point Siglent to this thread and add this feature. Likely it is 3 lines of extra code. Maybe they can beat Dave to making a video showing how it doesn't work on Siglent scopes but it does work on Rigol's 8)
Exactly. In real world less is less.
You keep forgetting to warn people that what you do makes scope retrigger at a very, very slow rate (few times per second). So you are looking at some edge at nanosecond scale, but your screen refreshes few times per second or slower. What you are proposing is good for events that are sparse, and where things happen so slow, you actually have time to literally see something weird on screen, mentally have time to recognize it as weird and make a decisions to stop, and then have time for you to move hand and manually stop acquisitions.
Segmented acquisitions are literally invented for those kinds of events... So to work on that kind problems, you use segmented mode. On LeCroy, Siglent, Pic and some R&S scopes (I know of those if there are more please let me know)you have history mode, that is sort of always running segmented mode, with no penalties to normal running.
For that kind of events, I put Pico to slow timescale with deep memory so I keep high acquisition rate, and capture 100 ms at a time, and keep getting those captures to memory, 100s of them if needed.
Then I use built in search to scour trough captures..I also use DeepMeasure to search for analog anomalies across all of those (edges, P-P, pulse widths). I export DeepMeasure to Excel, and make statistics and histograms of all those prameters, to catch outliers and get a feeling of distribution... Or I put my 3000T or Pico to segmented mode and just capture those bursts of data, ignoring "eons" of pause in between. Pico 3406D has retrigger time in segmented mode even faster that 3000T (Trigger rearm time < 0.7 µs at 1 GS/s sampling rate, )
When looking at normal scope stuff, I like that my 3000T uses auto memory management, so it can reach up to 1.2 MHz retrigger rate. It makes it feel like "real scope".
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides.
It's only relevant if designing in this feature was done at the sacrifice of update rate in the design.
Obviously with Keysight having the fastest update rate and having this feature, that's obviously not a trade off that needs to be made in basic scope design.
Except they are mutually exclusive, the bonus full length capture of the megazoom scopes only occurs when there is another trigger after pressing stop. If you're trying to capture long record lengths of short bursts between infrequent events, pressing stop won't help.
You should use Single mode in that case
-
Apart from this I wonder, what siglent will do with it´s waste amount of memory ( 200MP/250MP SDS 2K+/SDS5K) when only could used in lower timebases.
:-//
It's YOUR memory to know how to use wisely......again yours !
Lower timebases, bah humbug. :P
Study the dot mode screenshot below.....left at that timebase setting for understanding but 1 dot/div (1 memory point) is available at 200ps/div.
Total of 500 MPts with 2 channels on alternative ADC's.
(https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/?action=dlattach;attach=988054)
-
To summarise, I think STOP mode or Single Mode should ultislise all available hardware memory regardless of current memory setting and at the fastest sample rate. This is clearly what Keysight have opted to do.
And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".
nctnico's corner case is when there isn't a repetitive trigger to create that larger capture. That "magic" capture when pressing stop only happens under specific circumstances so it can't be relied upon in regular use.
The argument against always having full memory depth for single captures is what do you do when the pre trigger buffer isn't full yet, but the user pressed single? Throw away possibly the only trigger?
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.
Waveform update rate is limited by letting the acquisition length expand around the visible window, to claim there is no downside in doing so is plainly ridiculous. You like having manual control of memory depth and it expanding around the screen, we keep hearing this and get it, but your justifications are nonsense, and you throw it out as some big issue when it really isn't.
It seems your understanding of how an oscilloscope works is severely lacking. If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.
-
All that extra memory around the aquisition window kills waveform update rates (a tradeoff which is completely acceptable for some uses). Here is the plot from a Tek DPO4000:
(https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/?action=dlattach;attach=342639;image)
Extending the acquisition buffer each side of the trigger outside the window on the screen is shown with dotted lines toward the right. It knocks orders of magnitude off the update rate.
Although there are more intelligent memory management options, scopes are rather simple/dumb. They won't redraw/paint another trigger until the full memory depth is filled. So at 5GS/s and 10M memory depth, even a perfect zero overhead, instant trigger will only run 500 updates/s.
This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"
-
This shows what I'we been explaining. 3000T is capturing only screen full of data from trigger to trigger. It is only when you press stop that it will reassemble some data before begin of the screen, and it will keep capturing until it runs after memory. What I suspect is that it literally goes from RUN to STOP, by capturing one SINGLE capture on next trigger after you press STOP (Just with half of the buffer because of state of capture engine at the time, the ping-pong buffers).
I presume it behaves like that, because, if press stop now, while it's waiting for next trigger, it doesn't get any additional data:
(Attachment Link)
That sounds right. It's doing just the screen worth in Normal or Auto mode because it needs the fastest update rate possible. There is no point capturing continuous updating data outside the screen if the user can't see it.
So yes, doesn't surprise me that this only works in STOP or Single mode, because these modes are, practically by their usage definition, analysis modes were you may want to expand the timebase to view that extra data. So when the scope has been instructed perform STOP or Single mode it makes sense to then capture the entire available memory length regardless of what the user has set, because update rate no longer has any relevance.
Come to think of it this way now, there should be absolutely no reason why the likes of Siglent could not implement this easily with a firmware update. The likely reason they haven't is because they just haven't thought of it before.
To summarise, I think STOP mode or Single Mode should ultislise all available hardware memory regardless of current memory setting and at the fastest sample rate. This is clearly what Keysight have opted to do.
I absolutely agree. Keysight made a very nice trick here, and I would like it to be on all scopes. But history mode (to keep hundreds of previous triggers automatically) is also very nice (i have it on Pico).
Ideally, it should be user's choice.
And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".
That is very good observation, very on point.
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides.
It's only relevant if designing in this feature was done at the sacrifice of update rate in the design.
Obviously with Keysight having the fastest update rate and having this feature, that's obviously not a trade off that needs to be made in basic scope design.
Except they are mutually exclusive, the bonus full length capture of the megazoom scopes only occurs when there is another trigger after pressing stop. If you're trying to capture long record lengths of short bursts between infrequent events, pressing stop won't help.
You should use Single mode in that case
NO SHIT SHERLOCK! Or use a zoom window on the full length acquisition window so you can see it all at once without having to zoom in and out.
Can you not see the noise building way above the signal at this point of the thread?
-
Exactly. In real world less is less.
You keep forgetting to warn people that what you do makes scope retrigger at a very, very slow rate (few times per second). So you are looking at some edge at nanosecond scale, but your screen refreshes few times per second or slower.
Again; that trade-off isn't there. Just set the memory shorter (or let the oscilloscope set it by itself). For example: the R&S RTM3004 can do it all.
And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".
No, because that only applies to Keysight. So far only Lecroy and Siglent scopes can't record outside the screen. Don't be fooled by people who try to make capturing beyond the screen is something special. Most DSO do it except it seems very few people realise they (can) work that way.
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.
Waveform update rate is limited by letting the acquisition length expand around the visible window, to claim there is no downside in doing so is plainly ridiculous. You like having manual control of memory depth and it expanding around the screen, we keep hearing this and get it, but your justifications are nonsense, and you throw it out as some big issue when it really isn't.
It seems your understanding of how an oscilloscope works is severely lacking. If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.
Hmm...
I think maybe just having a choice of how much acquisition memory to use is not enough. You need also to tell the scope if it should allocate memory to increasing the sample rate (for zooming in) or increasing the record length (for zooming out), and this should be independent of the X scale setting. I think the Digitizer mode of the X3000T works like this, though I have never explored it.
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.
Waveform update rate is limited by letting the acquisition length expand around the visible window, to claim there is no downside in doing so is plainly ridiculous. You like having manual control of memory depth and it expanding around the screen, we keep hearing this and get it, but your justifications are nonsense, and you throw it out as some big issue when it really isn't.
It seems your understanding of how an oscilloscope works is severely lacking. If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.
You can have the choice, more memory and fewer updates, or less memory and more updates. I have that choice too.
But you keep squeezing down the discussion to nonsense points:
capturing beyond the screen has no downsides.
It has a bunch of downsides! But you keep distracting people and adding noise rather than just presenting that as a tradeoff.
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides.
It's only relevant if designing in this feature was done at the sacrifice of update rate in the design.
Obviously with Keysight having the fastest update rate and having this feature, that's obviously not a trade off that needs to be made in basic scope design.
Except they are mutually exclusive, the bonus full length capture of the megazoom scopes only occurs when there is another trigger after pressing stop. If you're trying to capture long record lengths of short bursts between infrequent events, pressing stop won't help.
You should use Single mode in that case
That is exactly the point. It is already invented, it's called SINGLE mode. No need to achieve it trough side effects.
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.
Waveform update rate is limited by letting the acquisition length expand around the visible window, to claim there is no downside in doing so is plainly ridiculous. You like having manual control of memory depth and it expanding around the screen, we keep hearing this and get it, but your justifications are nonsense, and you throw it out as some big issue when it really isn't.
It seems your understanding of how an oscilloscope works is severely lacking. If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.
I think maybe just having a choice of how much acquisition memory to use is not enough. You need also to tell the scope if it should allocate memory to increasing the sample rate (for zooming in) or increasing the record length (for zooming out), and this should be independent of the X scale setting.
For that some oscilloscopes have an 'automatic memory length' setting. That way it will tailor the amount of acquisition memory and samplerate depending on things like zoom mode. These aren't new problems; this has been solved decades ago.
-
The argument against always having full memory depth for single captures is what do you do when the pre trigger buffer isn't full yet, but the user pressed single? Throw away possibly the only trigger?
Ah, THAT'S the magic in the capture architecture design!
This just triggered my memory! (pun of the week, surely?)
I independently solved this in my DSOA Mk3 design back in 1998 with 7200 FIFO's.
https://alternatezone.com/electronics/files/dsoamk3.txt
-
And I don't get how fast waveform updates suddenly become relevant in this thread; capturing beyond the screen has no downsides. Just set the memory shorter one way or another and you have more waveforms/s and/or history / segmented recording.
Waveform update rate is limited by letting the acquisition length expand around the visible window, to claim there is no downside in doing so is plainly ridiculous. You like having manual control of memory depth and it expanding around the screen, we keep hearing this and get it, but your justifications are nonsense, and you throw it out as some big issue when it really isn't.
It seems your understanding of how an oscilloscope works is severely lacking. If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.
Hmm...
I think maybe just having a choice of how much acquisition memory to use is not enough. You need also to tell the scope if it should allocate memory to increasing the sample rate (for zooming in) or increasing the record length (for zooming out), and this should be independent of the X scale setting. I think the Digitizer mode of the X3000T works like this, though I have never explored it.
Digizer mode FIXES capture rate AND memory depth. With both at max, for instance, you get 400us of data on every trigger. Retrigger rate drops to 2500 trig/sec.
No Peak detect mode, no Hires, no averaging.
With timebase knob you cannot control anything except a window what are you looking at. It is not very useful or intuitive for G.P. interactive work. I presume it was introduced for data processing over SCPI.
-
And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".
No, because that only applies to Keysight. So far only Lecroy and Siglent scopes can't record outside the screen.
Err, wouldn't it apply to every scope brand that does this?, not just Keysight.
How else would it be achieved whilst keeping any resemblance of half way decent update rate?
-
This just triggered my memory! (pun of the week, surely?)
:-DD
-
The argument against always having full memory depth for single captures is what do you do when the pre trigger buffer isn't full yet, but the user pressed single? Throw away possibly the only trigger?
Ah, THAT'S the magic in the capture architecture design!
This just triggered my memory! (pun of the week, surely?)
I independently solved this in my DSOA Mk3 design back in 1998 with 7200 FIFO's.
https://alternatezone.com/electronics/files/dsoamk3.txt
Not sure you solved it:
The RAM FILL period is required in order to allow the RAM to be at least half
filled with data. This is to ensure that the data the PC reads back will
always contain half pre-trigger information and half post-trigger
information. If a trigger was to occur before the RAM is half filled, then we
would have an indeterminable number of pre-trigger samples (if any at all).
Thats the same problem of what to do when the pre-trigger buffer isn't filled yet. With modern scopes having Mpts and Gpts of memory the pretirgger period can be substantial if you always have to fill it even when you are on a shorter timebase/memory setting.
There are many intelligent things scopes could be doing to better manage their memory, improve update rates, and retain more data for review. But that will go against the manual control of everything users that are making so much noise here.
-
The argument against always having full memory depth for single captures is what do you do when the pre trigger buffer isn't full yet, but the user pressed single? Throw away possibly the only trigger?
Ah, THAT'S the magic in the capture architecture design!
This just triggered my memory! (pun of the week, surely?)
I independently solved this in my DSOA Mk3 design back in 1998 with 7200 FIFO's.
https://alternatezone.com/electronics/files/dsoamk3.txt
That is how all DSOs work however not using a FIFO but a circular buffer. After all you never know when a trigger arrives. A couple of years ago I have designed a distributed data acquisition system (for a customer) which triggers on input signals to define the start of a measurement. It nearly is a DSO except for the display and knobs. When an acquisition starts it just fills the memory continously as a circular buffer. But a trigger will only be accepted once there is enough data to meet the pre-trigger requirement. If a trigger occurs during the pre-fill time then it will be lost. The pre-fill time can be avoided by setting the trigger point before the start of the acquisition (which is also something the system I designed supports).
And perhaps that's a better description of this issue, "Capture memory depth in STOP/Single mode".
No, because that only applies to Keysight. So far only Lecroy and Siglent scopes can't record outside the screen.
Err, wouldn't it apply to every scope brand that does this?, not just Keysight.
No. Not at all. See my earlier list.
How else would it be achieved whilst keeping any resemblance of half way decent update rate?
Why is update rate so important? In many cases it just isn't and using all the memory is far more useful. If you still have an R&S scope you can see you can set the memory to auto or use a pre-defined depth. On the R&S (for example) you can have either a short memory depth to achieve a high update rate OR select deep memory. Ofcourse deep memory will slow the acquisition rate but that isn't a problem. A lot of the work I do is in embedded firmware / hardware interaction where messages pass by at a rate of a couple of hundred per second at most.
-
If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.
If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains.
I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity
-
If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.
If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains.
I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity
Actually not. AFAIK Even Siglent and Lecroy already have the option to set a fixed memory depth. It is only that they choose not to actually use full memory if that results in more sample points necessary to fill the screen. In a way you could even argue that those oscilloscopes don't do what you tell them to. >:D
-
If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.
If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains.
I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity
Fewer samples at a lower ADC sample rate can increase the waveform update rate (no scope is completely ideal with zero trigger re-arm and zero processing time), see the huge graph of a DPO4000 above doing exactly that.
The UI control for memory depth isn't too complex, usually just a box in the horizontal settings. Whats annoying is not having an auto setting alongside the manual choices. And as I keep having to bring up, even if the scope doesn't have explicit manual control of memory depth, there are ways to control it with zoom windows etc. Which for many scopes is fewer button presses and/or dedicated controls, but uses the screen real-estate differently (could be better or worse depending on your particular application).
-
This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"
(Disclaimer: I'm in no position to argue this theme with all the gurus here but, having said that,...)
If that is what KS does, and others don't, I don't understand why. :-// We're talking STOP and SINGLE modes, right? So the scope has all the time in the world to process whatever it has to do after trigger and present results to the user. It seems it would be the way I would implement it!
BUT, I see a problem, the result will be ALWAYS like this:
[<-[ trigger ---------] ----------------------------- acquisition ----------->]
Right?
With this implementation/mode of operation, you'll never be able to do this:
[<------- acquisition ------- [ ---- trigger -----]------- acquisition ------->]
or this:
[<-------------- acquisition ----------------------------[--------- trigger]->]
Am I correct?
(just a fact check to see if I'm understanding you all...)
-
This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"
(Disclaimer: I'm in no position to argue this theme with all the gurus here but, having said that,...)
If that is what KS does, and others don't, I don't understand why. :-// We're talking STOP and SINGLE modes, right? So the scope has all the time in the world to process whatever it has to do after trigger and present results to the user. It seems it would be the way I would implement it!
BUT, I see a problem, the result will be ALWAYS like this:
[<-[ trigger ---------] ----------------------------- acquisition ----------->]
Right?
With this implementation/mode of operation, you'll never be able to do this:
[<------- acquisition ------- [ ---- trigger -----]------- acquisition ------->]
or this:
[<-------------- acquisition ----------------------------[--------- trigger]->]
Am I correct?
(just a fact check to see if I'm understanding you all...)
The expansion around the screen is mostly (entirely?) symmetric on the mega zoom "bonus" capture, like the middle example. There is no control over where the extra memory is allocated, either for this, or nctnico's case where they manually set the acquisition memory depth wider than the visible window.
So, as mentioned above, the "bonus" full length capture requires a trigger to arrive at just the right time or it doesn't capture the extra acquisition and just keeps the last regular sized one.
-
If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.
If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains.
I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity
Fewer samples at a lower ADC sample rate can increase the waveform update rate (no scope is completely ideal with zero trigger re-arm and zero processing time), see the huge graph of a DPO4000 above doing exactly that.
Point taken - but then it is a Tek ;)
The UI control for memory depth isn't too complex, usually just a box in the horizontal settings. Whats annoying is not having an auto setting alongside the manual choices. And as I keep having to bring up, even if the scope doesn't have implicit manual control of memory depth, there are ways to control it with zoom windows etc. Which for many scopes is fewer button presses and/or dedicated controls, but uses the screen real-estate differently (could be better or worse depending on your particular application).
The Megazoom scopes I am familiar with have only recently introduced manual control of the acquisition memory. I think zoom windows are a bit of a distraction here. It's really only a different way of modifying the X scale: one that only lets you zoom in, not out, but shows both the zoomed and full time record. The full time record is exactly the same as a normal capture with no off-screen memory at all
-
This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"
(Disclaimer: I'm in no position to argue this theme with all the gurus here but, having said that,...)
If that is what KS does, and others don't, I don't understand why. :-// We're talking STOP and SINGLE modes, right? So the scope has all the time in the world to process whatever it has to do after trigger and present results to the user. It seems it would be the way I would implement it!
BUT, I see a problem, the result will be ALWAYS like this:
[<-[ trigger ---------] ----------------------------- acquisition ----------->]
Right?
With this implementation/mode of operation, you'll never be able to do this:
[<------- acquisition ------- [ ---- trigger -----]------- acquisition ------->]
or this:
[<-------------- acquisition ----------------------------[--------- trigger]->]
Am I correct?
(just a fact check to see if I'm understanding you all...)
When you press STOP, 3000T seems to reconfigure and capture one SINGLE capture on a separate trigger, together with pre trigger time. On highest sampling rate, you always get 40us pre and 360us post trigger.
EDIT: Actually it depends on the where is trigger reference point set. If you set hor.ref point left, than it is -40us/+360us. BUT, if you set hor.ref point to center, than captured buffer is -200us/+200us arround trigger point. Respectively, if you set hor.ref point to right you get -360us/+40us
-
Well you learn something every day :)
Indeed :)
Yep, another of the corners for nctnico's atypical use case, rejection of zoom mode. You went with the obvious/logical use case!
Well, I start to see why Nico is doing it the way he does, probably because this is a reflection of his general approach to a measurement problem. I still remember similar discussions we had about the importance (or not) of Peak Detect, another feature he seems to consider crucial ;). I guess this is just his way of doing stuff, and if it works for him then I'm not going to tell him to do anything else.
But while I believe I understand (to some extend) why *he* does it this way, I still fail to see why any real-world advantage of this method (and even less so where the claimed increase in efficiency or time savings should come from). The fact alone that this only works on some scopes (of which most only do this with a single acquisition) while the standard "capture long and then zoom in" methodology (for which deep memory scopes were designed for) works on every scope makes it impractical in a professional setting where you have to work with various different scope models.
Personally, it also doesn't fit me because it sounds a bit arbitrary (like blindly poking around in some circuitry), as I tend to think about what I want to measure and what I expect to see, and then setup the scope accordingly. But that's just me (although most of our engineers are the same "think before you do" types). But hey, whatever fits you best.
The problem I see is that this method is still rather niche, and due to it's various limitations over the standard "capture long and zoom in" method which is widely used it's really not a relevant criteria for a scope unless the user specifically asks for it, and it should not be treated this way.
Zoom mode adds one very important control that is missing when letting the scope expand around the visible window: you gain control of where the trigger is located within the full capture depth.
Not only that. Because there is also the problem that the excess data that even some of the scopes record is not always available.
Take the Rigol DS1000z. We now established that, if you set the memory to manual then it will always record the full selected memory size, no matter what. Great, right? :-+
But here's the thing: on the DS1000z at least, you can't always access that data. In RUN mode, if you switch to zoom mode, you can still only zoom *in* on the signal on screen, but not zoom *out* to look at off-screen data.
You can, of course, change the timebase, but that just means the screen will show the new timebase length after the next acquisition (i.e. the data of the previous acquisition are gone).
You can, of course, also setup a trigger to a specific event, and then after the capture change the timebase to effectively "zoom out". However, for this to work there must be no subsequent acquisitions, or the data you want to look at is overwritten (and if that happens after the change of timebase then in effect it's no different to a normal timebase change on any scope).
The test Nico described is essentially this, trigger to a specific event, then stop the trigger and then "zoom out".
Which, consequentially, means that you can *only* look at off-screen data if the scope is no longer acquiring. It doesn't matter here if this is because this was the last in a series of acquisitions (with no subsequent acquisitions following), or if the scope was in SINGLE mode.
In contrast, the standard method of "capture long then zoom in" works irrespective if the scope is halted or still acquiring. With zoom, I can watch live data, jump to a different part of the signal and watch other live data. With Nico's method, I have to acquire, then make sure the scope is not re-triggered and then "zoom out".
With the standard method, on better scopes, I can even have multiple zoom windows, each showing a different segment of the signal. Single or continuous, doesn't matter :)
Now, let's look at Nico's example of the SPI frame:
He's setting the scope to max memory, set the trigger to the interesting data segment and set the timebase so that data bit is full screen.
Now if the trigger event is rare or unique (say, the data segment has to reach a specific value) then after capturing the acquisition will essentially stop (waiting for the next trigger). If it's a common event then the scope then the acquisition must be stopped manually as otherwise the outside display data would be inaccessible.
OK, let's say we have looked at the data segment, and now want to see the rest of the frame (which is outside the screen). So we change the timebase setting to the full frame length (whatever that is) and yes, we can see the data that before was off-screen. :-+
But the thing is that, at this point, our scope is now set to *exactly* the same timebase setting that we would have set it to with the common "capture long and zoom in" method |O. Just that the latter would have also allowed us to see both the whole frame as well as a detailed view of the data segment of interest without stopping the scope, i.e. we could observe live behavior. Something which, at least on the DS1000z, isn't possible with Nico's method.
So in the end, Nico's method seems to be a convoluted way to avoid using the scope's zoom function while achieve the same which can be achieved with the standard method.
It's not just with the DS1000z. I suspect all Rigol scopes behave the same (i.e. don't let you zoom outside the screen unless the scope is halted). HPAK's MegaZoom based scopes (InfiniVision and 546xx) for sure do.
Can the R&S scopes "zoom out" to off-screen data in RUN mode, or does it need to be stopped? I don't know (maybe someone else can try) :-//
In any case, Nico's method sounds more like a pain in the ass than a solution to a problem which actually exists.
-
If you set the memory to a shorter depth then acquisitions take less time so you can achieve higher waveforms/s. I just want to have the choice between many waveforms/s OR using the full memory. I don't get why not having that choice is somehow better.
If the scope chooses to reduce the ADC sample rate when you allocate less memory, the waveform update rate won't change. What is important is the duration of the time record, not how many samples it contains.
I agree, it would be useful to have the choice, though there is an inevitable penalty to pay in terms of UI complexity
Fewer samples at a lower ADC sample rate can increase the waveform update rate (no scope is completely ideal with zero trigger re-arm and zero processing time), see the huge graph of a DPO4000 above doing exactly that.
Point taken - but then it is a Tek ;)
All scopes do it to some degree, even the vaunted megazoom ASICs. Again, all this is linked above for your reading...
The UI control for memory depth isn't too complex, usually just a box in the horizontal settings. Whats annoying is not having an auto setting alongside the manual choices. And as I keep having to bring up, even if the scope doesn't have implicit manual control of memory depth, there are ways to control it with zoom windows etc. Which for many scopes is fewer button presses and/or dedicated controls, but uses the screen real-estate differently (could be better or worse depending on your particular application).
The Megazoom scopes I am familiar with have only recently introduced manual control of the acquisition memory. I think zoom windows are a bit of a distraction here. It's really only a different way of modifying the X scale: one that only lets you zoom in, not out, but shows both the zoomed and full time record. The full time record is exactly the same as a normal capture with no off-screen memory at all
Zoom windows are a way to set the size of the full acquisition, the trigger point within that full range, and still see some short timescale detail in realtime. It ticks all the boxes for nctnico's bizarre use case except they then added another constraint of "zoom takes up too much of the display" which sounds like a good excuse to consider scopes with better display management and higher resolutions.
-
This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"
(Disclaimer: I'm in no position to argue this theme with all the gurus here but, having said that,...)
If that is what KS does, and others don't, I don't understand why. :-// We're talking STOP and SINGLE modes, right? So the scope has all the time in
No. When using single mode you'd need to press the single button every time. In case of slow events (which can be generated manually) it is much easier to press stop when something of interest appears on the screen instead of having to bother with the oscilloscope all the time. And you only have two hands. Starting something on the DUT and holding a probe already needs 2 hands.
-
The expansion around the screen is mostly (entirely?) symmetric on the mega zoom "bonus" capture, like the middle example. There is no control over where the extra memory is allocated, either for this, or nctnico's case where they manually set the acquisition memory depth wider than the visible window.
When you press STOP, 3000T seems to reconfigure and capture one SINGLE capture on a separate trigger, together with pre trigger time. On highest sampling rate, you always get 40us pre and 360us post trigger.
Another inconsistency, you making me crazy...
EDIT: Actually it depends on the where is trigger reference point set. If you set hor.ref point left, than it is -40us/+360us. BUT, if you set hor.ref point to center, than captured buffer is -200us/+200us arround trigger point. Respectively, if you set hor.ref point to right you get -360us/+40us
Phew! I thought it was mostly symmetric (generally working with symmetric trigger setups), thanks for the extra details. Its far too fiddly to rely/plan on any of that, I just use a scope as it works.
-
Personally, it also doesn't fit me because it sounds a bit arbitrary (like blindly poking around in some circuitry), as I tend to think about what I want to measure and what I expect to see, and then setup the scope accordingly. But that's just me (although most of our engineers are the same "think before you do" types). But hey, whatever fits you best.
But you don't know what you don't know. If you are looking for a bug you start with a blank slate. So how are you going to setup your scope if you don't know what you are looking for? If you already know what a signal looks like there is no use measuring it. Often something interesting turns up which makes me want to see want came before and after. There is no way to know until there is something on screen. Maybe you'll capture it again after an hour. Same goes for design verification. Something odd may pop-up. It is nice if you don't have to recapture to see the rest but just zoom out. In some of my cases it can take several minutes to make a new measurement.
And there are also cases where it is just quicker to capture something visually rather than setting up a complex trigger condition. Remember my way of working stems from saving time & effort.
Come to think of it: it makes no sense needing to use zoom mode to have all the memory available. I already told the oscilloscope to use a certain amount of memory.
Anyway, it seems that you have a very narrow view of how an oscilloscope should be used and are unable to see beyond that to streamline operations. It reminds me of my chief when I was working in a chocolate factory: 'you must carry those trays with both hands because god gave you two hands'.
-
Zoom windows are a way to set the size of the full acquisition, the trigger point within that full range, and still see some short timescale detail in realtime.
Indeed.
The other thing is that zoom, after all, is actually just a math function ('window' function) over the acquired waveform, and on better scopes you're not limited to a single zoom mode but you can actually have multiple, each zooming into a different part of the signal, all showing live data if you want.
These zoom modes can then also be used as an input for further analysis.
Which means zoom mode is just more than just stretching the displayed signal segment.
It ticks all the boxes for nctnico's bizarre use case except they then added another constraint of "zoom takes up too much of the display" which sounds like a good excuse to consider scopes with better display management and higher resolutions.
I agree, this is just a case of a poor UI on a particular scope, not a problem that's inherent to zoom as a function.
-
Phew! I thought it was mostly symmetric (generally working with symmetric trigger setups), thanks for the extra details. Its far too fiddly to rely/plan on any of that, I just use a scope as it works.
Exactly my point.
-
Come to think of it: it makes no sense needing to use zoom mode to have all the memory available. I already told the oscilloscope to use a certain amount of memory.
You're contradicting yourself. You have to choose: fill all the memory or don't fill all the memory. If not, you'll be defending Siglent's way in a hurry...
-
Come to think of it: it makes no sense needing to use zoom mode to have all the memory available. I already told the oscilloscope to use a certain amount of memory.
You're contradicting yourself. You have to choose: fill all the memory or don't fill all the memory. If not, you'll be defending Siglent's way in a hurry...
I'm not contradicting myself. Needing to use zoom made in order to make the oscilloscope use the memory depth I set is making the same setting twice.
-
I agree, this is just a case of a poor UI on a particular scope, not a problem that's inherent to zoom as a function.
It is not; I'm using all DSOs like this. Like several others you are trying to argue less is somehow more while grasping at straws no thicker than a hair trying to ridcule me. Just give up.
-
The argument against always having full memory depth for single captures is what do you do when the pre trigger buffer isn't full yet, but the user pressed single? Throw away possibly the only trigger?
Ah, THAT'S the magic in the capture architecture design!
This just triggered my memory! (pun of the week, surely?)
I independently solved this in my DSOA Mk3 design back in 1998 with 7200 FIFO's.
https://alternatezone.com/electronics/files/dsoamk3.txt
Not sure you solved it:
The RAM FILL period is required in order to allow the RAM to be at least half
filled with data. This is to ensure that the data the PC reads back will
always contain half pre-trigger information and half post-trigger
information. If a trigger was to occur before the RAM is half filled, then we
would have an indeterminable number of pre-trigger samples (if any at all).
Thats the same problem of what to do when the pre-trigger buffer isn't filled yet. With modern scopes having Mpts and Gpts of memory the pretirgger period can be substantial if you always have to fill it even when you are on a shorter timebase/memory setting.
Yeah but you only have to pre-fill memory once after the uses presses the START button. In most usage cases and non-slow timebases that's practically an instant, and is actually the price you pay when you have defined the (default) horizontal trigger position to be center memory. There is no way around doing it once unless you copied your sample memory to display/plot memory and then continued to sample in the background. That would be a huge design trade-off for so little gain.
-
The argument against always having full memory depth for single captures is what do you do when the pre trigger buffer isn't full yet, but the user pressed single? Throw away possibly the only trigger?
Ah, THAT'S the magic in the capture architecture design!
This just triggered my memory! (pun of the week, surely?)
I independently solved this in my DSOA Mk3 design back in 1998 with 7200 FIFO's.
https://alternatezone.com/electronics/files/dsoamk3.txt
Not sure you solved it:
The RAM FILL period is required in order to allow the RAM to be at least half
filled with data. This is to ensure that the data the PC reads back will
always contain half pre-trigger information and half post-trigger
information. If a trigger was to occur before the RAM is half filled, then we
would have an indeterminable number of pre-trigger samples (if any at all).
Thats the same problem of what to do when the pre-trigger buffer isn't filled yet. With modern scopes having Mpts and Gpts of memory the pretirgger period can be substantial if you always have to fill it even when you are on a shorter timebase/memory setting.
Yeah but you only have to pre-fill memory once after the uses presses the START button. In most usage cases and non-slow timebases that's practically an instant, and is actually the price you pay when you have defined the (default) horizontal trigger position to be center memory. There is no way around doing it once unless you copied your sample memory to display/plot memory and then continued to sample in the background. That would be a huge design trade-off for so little gain.
Or use two swinging buffers, even in Single mode. But that halves your maximum record length, which seems like a poor choice.
-
I think zoom windows are a bit of a distraction here.
I agree. No need to complicate the operational understanding here.
-
Take the Rigol DS1000z. We now established that, if you set the memory to manual then it will always record the full selected memory size, no matter what. Great, right? :-+
But here's the thing: on the DS1000z at least, you can't always access that data. In RUN mode, if you switch to zoom mode, you can still only zoom *in* on the signal on screen, but not zoom *out* to look at off-screen data.
On the DSO1014A (a Rigol design), with Zoom off, in Run mode, but with no triggers happening, you can use the horizontal scale & position knobs to move the displayed trace around within the offscreen captured data, and change the displayed duration. If you then turn Zoom on, you get a zoomed view of the currently displayed part of the captured data, even if it was originally off screen. The horizontal scale & position knobs change mode to operate as zoom and pan within the displayed window. Turn off Zoom and you can move to a different part of the captured data, rinse & repeat.
This could actually be quite useful: I didn't know you could do this! Do the more recent Rigols work in the same way? I'll check the X3000T as well now, I'm intrigued.
-
Personally, it also doesn't fit me because it sounds a bit arbitrary (like blindly poking around in some circuitry), as I tend to think about what I want to measure and what I expect to see, and then setup the scope accordingly. But that's just me (although most of our engineers are the same "think before you do" types). But hey, whatever fits you best.
But you don't know what you don't know. If you are looking for a bug you start with a blank slate. So how are you going to setup your scope if you don't know what you are looking for?
You never start from a blank slate. For a start, you need to have some idea as to what the spectral content of the signal is, because that determines your scope BW.
You also need to have some idea as to the voltage levels, as you need this to select suitable probes and prevent damage to your scope and your human body.
Furthermore, you normally should have some rough idea what the UUT (i.e. a PCB) does, which gives you some hints as to what kind of signals (AC? DC? Discretes? Serial comms? Parallel comms?) you can expect to find. If you don't know then you have a closer look to get an idea what this thing actually is (although I believe it's pretty rare you're asked to probe something of which you don't know what it is).
Now when you identified what that thing on your bench does and you have an idea what kind of signals you expect, what the voltage levels are, and the approx frequency band, but still don't know what exactly the signal will be, you set your deep memory scope to a long timebase (as long as it makes sense, i.e. as long as the period of the slowest signal you could reasonably expect to see) and start capturing.
You'll quickly see if it's just DC, some AC, or if the signal looks more complex (like a Discrete or serial comms packet). If it's the latter then you can use zoom to look closer, get the different parameters for some of the level shifts, and if you don't already recognize a specific pattern then use the measurements to compare with the in-spec parameters for the type of signals that could reasonably be found on this UUT.
Or you try the serial decoders and see if they come up with sensible data.
In any case, a methodological, stepped investigative approach is usually the best approach.
Besides, I doubt it's very common for an engineer to get some UUT you really know nothing about and get told "measure something" ;)
But in any case, capturing long makes it easy to quickly assess different parts of the signal.
If you already know what a signal looks like there is no use measuring it.
So in your view things like interference or spec compliance (which usually needs to be demonstrated by measurements) doesn't exist?
There are many reasons why you want to measure signals, even if you know how it looks like.
And there are also cases where it is just quicker to capture something visually rather than setting up a complex trigger condition. Remember my way of working stems from saving time & effort.
You stated this repeatedly but I'm sorry it doesn't make sense (and as we already established, there is no difference in trigger config between your method and the standard äcquire long and zoom in" method). You're not saving time and effort, all you do is to go to extreme lengths to avoid using the zoom function, and as a result you make do with various limitations, all which can be avoided with the standard method.
The only "time saving" I could possible see is that, with your method, you don't spend time thinking about what you actually want to do, but which bites you in the backside later because of the additional things you need to do to when you find out that you ran into a dead end, and you have to reconfigure your tools to get the information you want, all which the standard method would very likely have given you anyways.
But at the end of the day, and from a professional angle, even if your method would save 10 button presses over the standard method, it wouldn't matter one bit. First of all, we don't sit next to our engineers with stop watches, so this isn't captured, and even if an engineer would have to to this 100x a day the impact on any timelines and schedules would be neglegible. Our engineers get the bucks to do engineering (i.e. to work on cutting edge technology), and how they do this is up to them (aside from standard and specs we don't dictate methodology engineers use for scoping, although there are regular exchanges to discuss test methodology to find out what we can do better). So far, no-one has ever asked for something like you describe. Go figure.
-
I agree, this is just a case of a poor UI on a particular scope, not a problem that's inherent to zoom as a function.
It is not; I'm using all DSOs like this.
You can't, because clearly not all scopes even allow you to use your method.
Like several others you are trying to argue less is somehow more while grasping at straws no thicker than a hair trying to ridcule me. Just give up.
So you're arguing that if the zoom window on a scope is too small that this is something other than a UX/screen size problem?
-
On the DSO1014A (a Rigol design), with Zoom off, in Run mode, but with no triggers happening, you can use the horizontal scale & position knobs to move the displayed trace around within the offscreen captured data, and change the displayed duration. If you then turn Zoom on, you get a zoomed view of the currently displayed part of the captured data, even if it was originally off screen.
Well, it's a work-around. You first change the actual timebase ("zoom out") which then becomes the new in-screen signal part, and then use zoom to "zoom in"to that new "in-screen" data.
What you are doing is essentially using the standard method ("capture long and zoom in") but add another step (capture short but also outside the screen, then change to a long timebase) which, essentially, adds nothing over if you just had captured long and then zoomed in in the first place :-DD
And your scope must still be on hold, i.e. not get re-triggered, or your method doesn't work.
The horizontal scale & position knobs change mode to operate as zoom and pan within the displayed window. Turn off Zoom and you can move to a different part of the captured data, rinse & repeat.
I think that would work on the DS1000z as well, but as I said it all adds up with extra steps with no actual benefit.
This could actually be quite useful: I didn't know you could do this! Do the more recent Rigols work in the same way? I'll check the X3000T as well now, I'm intrigued.
Again, it's not really useful ifyou think about it, but if you prefer this method why not ;)
-
This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"
I think what Dave concludes here sums all this thread very well. There is no justification to not filling up the whole memory (if it's not already filled) in order to have an after SINGLE/STOP zoom out.
The preferred way people use their scope is somewhat irrelevant (and something of a religion among the gurus here) to that fact.
Never crossed my mind that Siglent (and others) wouldn't implement it that way (like KS seems to do it). Maybe it is a simple change to correct that...
What is the point of having all that memory and not being able to take advantage of it? And if that's an unsurpassable obstacle, why the well do they allow the zoom out? Just to see blank screen? Or for us to validate that the scope doesn't have more samples?
-
So you're arguing that if the zoom window on a scope is too small that this is something other than a UX/screen size problem?
Not just that. Just less buttons to push. How hard is that to see? See my earlier analogy; you keep insisting to use an automatic gearbox in manual mode only. That is making life harder; not easier. And with 4 channels, some bus decoding, a few measurements and cursors active (not an a-typical use case for me) an oscilloscope screen gets crowded quickly no matter how big it is. Having to add a zoom window doesn't increase comfort so if you can get rid of the zoom window it is a good riddance. I shouldn't even have to point this out.
-
This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"
I think what Dave concludes here sums all this thread very well. There is no justification to not filling up the whole memory (if it's not already filled) in order to have an after SINGLE/STOP zoom out.
The preferred way people use their scope is somewhat irrelevant (and something of a religion among the gurus here) to that fact.
Never crossed my mind that Siglent (and others) wouldn't implement it that way (like KS seems to do it). Maybe it is a simple change to correct that...
What is the point of having all that memory and not being able to take advantage of it? And if that's an unsurpassable obstacle, why the well do they allow the zoom out? Just to see blank screen? Or for us to validate that the scope doesn't have more samples?
Well on Siglent it's not wasted to blank screen. Depending on mem depth, you can have thousands of previous triggers i history buffers. Siglent adopted LeCroy way of doing this. It basically always runs in segmented mode, except normally has screen updates that slow down retriggering, and when in dedicated segmented mode, display refresh is disabled and retrigger time is much faster.. With this you can do something also useful: You see something on the screen and than go back trough previous captures to see how it behaved before.. But, yes, I would like it would be user configurable.
-
On the DSO1014A (a Rigol design), with Zoom off, in Run mode, but with no triggers happening, you can use the horizontal scale & position knobs to move the displayed trace around within the offscreen captured data, and change the displayed duration. If you then turn Zoom on, you get a zoomed view of the currently displayed part of the captured data, even if it was originally off screen.
Well, it's a work-around. You first change the actual timebase ("zoom out") which then becomes the new in-screen signal part, and then use zoom to "zoom in"to that new "in-screen" data.
What you are doing is essentially using the standard method ("capture long and zoom in") but add another step (capture short but also outside the screen, then change to a long timebase) which, essentially, adds nothing over if you just had captured long and then zoomed in in the first place :-DD
And your scope must still be on hold, i.e. not get re-triggered, or your method doesn't work.
The horizontal scale & position knobs change mode to operate as zoom and pan within the displayed window. Turn off Zoom and you can move to a different part of the captured data, rinse & repeat.
I think that would work on the DS1000z as well, but as I said it all adds up with extra steps with no actual benefit.
This could actually be quite useful: I didn't know you could do this! Do the more recent Rigols work in the same way? I'll check the X3000T as well now, I'm intrigued.
Again, it's not really useful ifyou think about it, but if you prefer this method why not ;)
I'm not suggesting this as a better way to operate, rather that it overcomes the drawback that the ordinary Rigol 'zoom' mode doesn't let you zoom out from the initial displayed window. It's a kluge, but this 'zoom zoom' trick works.
-
But, yes, I would like it would be user configurable.
Damn, stop right there and we can all get back to sleep! :)
(Love this discussion. I've been learning quite a few things!)
-
Depending on mem depth, you can have thousands of previous triggers i history buffers. Siglent adopted LeCroy way of doing this. It basically always runs in segmented mode, except normally has screen updates that slow down retriggering, and when in dedicated segmented mode, display refresh is disabled and retrigger time is much faster.. With this you can do something also useful: You see something on the screen and than go back trough previous captures to see how it behaved before..
Ah, OK, also useful indeed. But, it's all software. In the end, you get what you pay for...
BUT, I should be able to have a final capture (to fill up memory) after the STOP/SINGLE if I'd choose so... no excuse. :)
-
So you're arguing that if the zoom window on a scope is too small that this is something other than a UX/screen size problem?
Not just that. Just less buttons to push. How hard is that to see?
I'm sorry I can't see it. Both your method and the standard method of "capture long and zoom in" are the same, the only difference is you start with a short timebase and then "zoom out", while the standard method is the other way around. On the scope this works, the number of button presses are the same (+/-1 if anything). :-//
See my earlier analogy; you keep insisting to use an automatic gearbox in manual mode only. That is making life harder; not easier.
Like most car analogies, it fails here, too. But staying with car analogies for the moment, if anything, it's *you* who want to use the automatic gearbox (memory management) in manual mode only, contrary to the principle deep memory scopes are designed for (which is to capture long sequences and zoom in on the detail). Because in effect, you are arguing that driving a powerful car with automatic transmission in manual mode because of the perceived better acceleration makes absolute sense while on the I-405 during rush hour :-DD
And with 4 channels, some bus decoding, a few measurements and cursors active (not an a-typical use case for me) an oscilloscope screen gets crowded quickly no matter how big it is.
That's not true. For example, we often have 8 or more traces plus decoding and measurements active, and it's never been an issue for any of our engineers to work with the data. Granted, the scopes we use are not the typical bottom-of-the barrel ones like a DS1054z, but still. For example, the new Keysight UXRs we got can easily display 10 or more different graphs (i.e. traces, math, FFT, whatever), each in their own window and with their own graticule, and it's not overloaded.
I may remember wrong but didn't you buy a LeCroy WavePro 7k some time ago? Even this (some 15+ year old) scope can comfortably display 8 traces + data, all in their separate graticule. If that 10.3" is still to small you can connect say a 24" monitor so you got an even larger screen with an even larger resolution.
Yes, the DS1054z screen is tiny, and while you can display four channels plus serial decode, it's rarely practical because there is only one graticule and it's all overlaid and so small it's barely usable (at least for a guy of my age). My Infiniium 8k isn't much better, the 8.4" screen is just way to small for the old HP GUI and the amount of information it can display (and it's way to small to use the touch functions sensibly). But that is down to the scope's small screen and cramped GUI.
The thing is that if your scope sux when displaying all this shit then it will suck no matter what method you use for performing your measurements. It's what it is.
So yes, your complaint about the zoom trace taking away screen estate is definitely an UX issue.
Having to add a zoom window doesn't increase comfort so if you can get rid of the zoom window it is a good riddance. I shouldn't even have to point this out.
I don't use a scope for "comfort", I use it to get data. The more data I can get less steps the better. The best approach to need less steps with complkex signals is usually to capture everything and zoom in on the details, often with multiple zoom windows each pointed to a different part of the signal.
At the end of the day, this is what DSOs where designed for, it's how every scope is sold, and it's how every engineer I worked with has been doing stuff.
Don't get me wrong, I'm not trying to do things differently, if it works for you be my guest. But so far I have seen no data which shows any benefit of your method over the standard way, and I don't believe the need of a scope to support such a (clearly very niche) methodology should be very high on a list of recommendations.
-
Take the Rigol DS1000z. We now established that, if you set the memory to manual then it will always record the full selected memory size, no matter what. Great, right? :-+
But here's the thing: on the DS1000z at least, you can't always access that data. In RUN mode, if you switch to zoom mode, you can still only zoom *in* on the signal on screen, but not zoom *out* to look at off-screen data.
On the DSO1014A (a Rigol design), with Zoom off, in Run mode, but with no triggers happening, you can use the horizontal scale & position knobs to move the displayed trace around within the offscreen captured data, and change the displayed duration. If you then turn Zoom on, you get a zoomed view of the currently displayed part of the captured data, even if it was originally off screen. The horizontal scale & position knobs change mode to operate as zoom and pan within the displayed window. Turn off Zoom and you can move to a different part of the captured data, rinse & repeat.
This could actually be quite useful: I didn't know you could do this! Do the more recent Rigols work in the same way? I'll check the X3000T as well now, I'm intrigued.
I can confirm the X3000T works in the same way, in Stop/Single mode. If there is off-screen captured data, you can use the horizontal controls in ordinary mode to bring it on screen, then use the zoom mode to zoom in on the displayed part.
One more wrinkle: you only get off-screen data from the 'magic' last capture in Stop/Single mode if the ADC sample rate is 5GHz (with one channel of each pair active). Presumably, if the sample rate is any lower, all the available memory is in use anyway.
-
Gentlemen, you are ALL talking the same language!
Nico starts with zoom in and likes to be able to zoom out. The others start with zoom out and like to be able to zoom in.
It's all the same, but in reverse order.
All the rest are just details (and personal preferences or lifelong habits)!
-
I'm with TV84 on this, it's 6 or one and half a dozen of the other.
To go back to the transmission analogy, I learned to drive on a manual and hated automatics as I always knew (thought) I could do better, even when I had an Audi A6, IMHO I did a better job than the transmission.
Now my 2.0 liter Ford Escape (Kuga) has a transmission that's basically a 6 speed manual operated by a computer, I have a manual mode but never use it as the transmission IS always in the right gear; the new 2020 models have an improved 8 speed version of mine and are reportedly even better.
-
One way is as good as the other, maybe, but DSOs are designed, primarily, around zooming in. Zooming out, you are going to find yourself going against the grain. Like a left-hand thread works just as well as a right-hand thread, but insisting on using left-hand thread screws everywhere may be a problem.
-
All true believers shall break their eggs at the convenient end.
-
One way is as good as the other, maybe, but DSOs are designed, primarily, around zooming in.
Says who? Nobody provided any evidence that zooming out is not the way an oscilloscope works. The fact it (recording beyond the screen) is possible on many oscilloscopes suggests that those are actually designed to work this way. It seems Keysight even went through the trouble to make single acquisition mode different compared to normal acquisition mode to support zooming out after a capture by recording beyond the screen. No, the problem is definitely that some seem to be stuck in the idea that you should always zoom in and use exact settings. Even when making those settings and zoom window adds zero benefit to solving the problem at hand.
-
Click this link (https://www.eevblog.com/forum/testgear/druck-unomat-trx/msg3060172/#msg3060172) to have an unlimited supply of reading material on this subject...
-
One way is as good as the other, maybe, but DSOs are designed, primarily, around zooming in.
Says who? Nobody provided any evidence that zooming out is not the way an oscilloscope works. The fact it (recording beyond the screen) is possible on many oscilloscopes suggests that those are actually designed to work this way. It seems Keysight event went through the trouble to make single acquisition mode different compared to normal acquisition mode to support zooming out after a capture by recording beyond the screen. No, the problem is definitely that some seem to be stuck in the idea that you should always zoom in and use exact settings. Even when making those settings and zoom window adds zero benefit to solving the problem at hand.
User tv84 nailed it in it´s last post here exactly, in my opinion.
-
One way is as good as the other, maybe, but DSOs are designed, primarily, around zooming in.
Says who? Nobody provided any evidence that zooming out is not the way an oscilloscope works. The fact it (recording beyond the screen) is possible on many oscilloscopes suggests that those are actually designed to work this way. It seems Keysight event went through the trouble to make single acquisition mode different compared to normal acquisition mode to support zooming out after a capture by recording beyond the screen. No, the problem is definitely that some seem to be stuck in the idea that you should always zoom in and use exact settings. Even if making those settings and zoom window adds zero benefit to solving the problem at hand.
You are now inventing that Keysight memory management was made the way it is "for the purpose of enabling zoom out" while presented with plenty of evidence that it doesn't even work that way when used in a scenario as explicitly designed by you.
You are confusing (at this point obviously intentionally, not wanting to admit the truth) that fact that something exists, is not a proof of intention. That kind of memory setting is probably there because it was easier for manufacturers to implement memory management, or for support for digitizer mode when using scope as digitizer. Or whatever. Only instrument designers know.
And zooming in and out provides same benefit as it provides same data for analysis. That was also proven several times by different people.
Once you capture data, both methods have same data and same analysis capabilities. I said that at the begining, tv84 said it very nicely (and more concise than I'm capable off.)
But, at this point you are insulting those that prefer to use proven techniques and use exact settings as being backwards.
They are stupid because they read manual. Nice.
Your only reason to insist on you way is that you refuse to learn how to use zoom mode. You simply hate it, for some reason.
So you devised method that you like better, that works on some scopes, and don't on others.
And you like it, and you find it useful. Good for you. I'm happy for you. And you shared it with us. Thank you for that. That was nice of you. Unfortunately, I couldn't find no merritts in it for me, for what I do, and how I do stuff. But thanks anyway. It was a gesture that counts.
-
This is why Keysight are clever in how they do it. They know that in trigger/Auto continuous update mode you don't care about extra data outside the screen, you just want the fastest update rate possible. Only when the user specifically requests STOP or Single mode does the scope then go "a-ha, I don't care about update rate any more, so I'm going to make one last capture using all my available memory, just in case the user wants to do a zoom outside the display window. And I pay no penalty do doing this! Ain't I clever!"
I think what Dave concludes here sums all this thread very well. There is no justification to not filling up the whole memory (if it's not already filled) in order to have an after SINGLE/STOP zoom out.
The preferred way people use their scope is somewhat irrelevant (and something of a religion among the gurus here) to that fact.
Never crossed my mind that Siglent (and others) wouldn't implement it that way (like KS seems to do it). Maybe it is a simple change to correct that...
What is the point of having all that memory and not being able to take advantage of it? And if that's an unsurpassable obstacle, why the well do they allow the zoom out? Just to see blank screen? Or for us to validate that the scope doesn't have more samples?
Trying to fill the entire XXXM/Gpts on every single acquisition or transition from run->stop is a bad idea, its limiting the ability to capture the triggers the scope is set to (preroll/pretrigger and post trigger filling). You would end up waiting for long periods, or having triggers lost in the preroll. Deep memory is better used when it is asked for, so the user knows they might need to run a search through the capture to find all the events. For nctnico's claiming they want control over the memory depth to exactly match their application, you're proposing having even less control.
-
Gentlemen, you are ALL talking the same language!
Nico starts with zoom in and likes to be able to zoom out. The others start with zoom out and like to be able to zoom in.
It's all the same, but in reverse order.
All the rest are just details (and personal preferences or lifelong habits)!
This is from nctnico's repeated alarmism any time they can drop this "hard fail" of a workflow. Claiming silly things like its impossible to see the fast edge and capture a deep acquisition, or that there are no downsides to having longer record lengths enabled.
-
One way is as good as the other, maybe, but DSOs are designed, primarily, around zooming in.
Says who? Nobody provided any evidence that zooming out is not the way an oscilloscope works. The fact it (recording beyond the screen) is possible on many oscilloscopes suggests that those are actually designed to work this way.
They can work that way, yes. But you keep insisting that other ways to achieve the same result are completely irrelevant and not to be considered. That may be for you, but you keep bringing this extremely narrow and unusual workflow up as some general advice when its completely your imaginary construction.
If you want to bring it up, then you'll need to actually put out the reasons, constraints, and benefits of your method. This thread is full of people completely not understanding why you keep talking about this the way you do. Smells like trolling.
When put in context its an obvious obscure corner case, it requires all these simultaneously:- slow/infrequent trigger rate (compared to the detail window being viewed)
- interesting detail at short time window
- possibly interesting detail in the larger capture (but can't rely on another trigger arriving)
- unwillingness to use a zoom window
You just draw out the discussion endlessly with distractions and nonsense. You've got a workflow that works for you, great. You'd like to see it available on more scopes, great, write to the manufacturers. But stop arguing that this workflow is somehow important for others to consider if you can't motivate us to its benefits.
-
One way is as good as the other, maybe, but DSOs are designed, primarily, around zooming in.
Says who?
Most of those that disagree with your backwards methodology of captured data analysis.
Nobody provided any evidence that zooming out is not the way an oscilloscope works. The fact it (recording beyond the screen) is possible on many oscilloscopes suggests that those are actually designed to work this way.
Says who ? Your presumption.
It seems Keysight event went through the trouble to make single acquisition mode different compared to normal acquisition mode to support zooming out after a capture by recording beyond the screen.
Actually designed that way ? I very much doubt this when it's a byproduct of the fast update rates made possible by the use of ASIC's when the majority of DSO's use ADC's and much larger memory than most ASIC based DSO's so managing the smaller capture memory in KS's is somewhat simpler to do.
The point is, zooming out is a crutch covering the far better methodology of zooming in.
While it is true many lost cost DSO's with Zoom mode only provide a 50/50 split of the display do indeed limit usability while upper entry level DSOs provide a much better split ratio where buyers of which are more accustomed to not needing so much visual reference of the primary timebase when in fact they want a larger zoomed timebase which is what they primarily work with.
No, the problem is definitely that some seem to be stuck in the idea that you should always zoom in and use exact settings.
Alternatively, others are stuck on zoom out methodology which severely limits the capability of the tool in front of you.
Even if making those settings and zoom window adds zero benefit to solving the problem at hand.
Take your blinkers off and embrace how all DSO's work.
While you entitled to work with a scope in another 'round about' way those that you may train will have a shock if they go to work for others where zooming in is the universally accepted methodology.
-
One way is as good as the other, maybe, but DSOs are designed, primarily, around zooming in. Zooming out, you are going to find yourself going against the grain. Like a left-hand thread works just as well as a right-hand thread, but insisting on using left-hand thread screws everywhere may be a problem.
The different ways to do this each have their own particular benefits, so any particular user can put their own narrow "goalposts" around that and insist one way is better. When they don't actually mention those goalposts it comes off poorly....
-
The point is, zooming out is a crutch covering the far better methodology of zooming in.
Err, they aren't mutually exclusive!
Every scope works by zooming in, but it seems like the likes of Keysight have thought about it and implemented it slightly different to give you a potential added benefit if you so desire it.
No, the problem is definitely that some seem to be stuck in the idea that you should always zoom in and use exact settings.
Alternatively, others are stuck on zoom out methodology which severely limits the capability of the tool in front of you.
He's just taking advantage of a feature of the scope that gives benefit to him in some cases. I don't see the problem with this and in publicising it.
I greatly doubt he uses it in every case, in fact that's not even possible.
While you entitled to work with a scope in another 'round about' way those that you may train will have a shock if they go to work for others where zooming in is the universally accepted methodology.
Why be so hostile about learning a new way to get something done?
Is it because you never knew about it before? Is it because your beloved Siglent's don't have it?
It's no different to learning say window triggering and then finding that feature isn't available on most of the scopes out there.
-
Its like some people aren't reading the whole thread and just jumping on small points, out of context.
He's just taking advantage of a feature of the scope that gives benefit to him in some cases. I don't see the problem with this and in publicising it.
I greatly doubt he uses it in every case, in fact that's not even possible.
While you entitled to work with a scope in another 'round about' way those that you may train will have a shock if they go to work for others where zooming in is the universally accepted methodology.
Why be so hostile about learning a new way to get something done?
Is it because you never knew about it before? Is it because your beloved Siglent's don't have it?
It's no different to learning say window triggering and then finding that feature isn't available on most of the scopes out there.
Because there is no substance to nctnico's endless arguments on this. Wuerstchenhund put it beautifully:
Don't get me wrong, I'm not trying to do things differently, if it works for you be my guest. But so far I have seen no data which shows any benefit of your method over the standard way, and I don't believe the need of a scope to support such a (clearly very niche) methodology should be very high on a list of recommendations.
We're waiting to have any explanation of why this method makes sense, not just some handwaving excuses around why alternatives are not fit for the overly specific and narrow use case.
-
Take the Rigol DS1000z. We now established that, if you set the memory to manual then it will always record the full selected memory size, no matter what. Great, right? :-+
But here's the thing: on the DS1000z at least, you can't always access that data. In RUN mode, if you switch to zoom mode, you can still only zoom *in* on the signal on screen, but not zoom *out* to look at off-screen data.
On the DSO1014A (a Rigol design), with Zoom off, in Run mode, but with no triggers happening, you can use the horizontal scale & position knobs to move the displayed trace around within the offscreen captured data, and change the displayed duration. If you then turn Zoom on, you get a zoomed view of the currently displayed part of the captured data, even if it was originally off screen. The horizontal scale & position knobs change mode to operate as zoom and pan within the displayed window. Turn off Zoom and you can move to a different part of the captured data, rinse & repeat.
This could actually be quite useful: I didn't know you could do this! Do the more recent Rigols work in the same way? I'll check the X3000T as well now, I'm intrigued.
I can confirm the X3000T works in the same way, in Stop/Single mode. If there is off-screen captured data, you can use the horizontal controls in ordinary mode to bring it on screen, then use the zoom mode to zoom in on the displayed part.
One more wrinkle: you only get off-screen data from the 'magic' last capture in Stop/Single mode if the ADC sample rate is 5GHz (with one channel of each pair active). Presumably, if the sample rate is any lower, all the available memory is in use anyway.
You might get "off screen data" again if you increase the horizontal speed by 1 step compared with using 1 channel. (That is how it works on the 54622D.)
-
We're waiting to have any explanation of why this method makes sense, not just some handwaving excuses around why alternatives are not fit for the overly specific and narrow use case.
Imagine a camera with a zoom lens. An experienced photographer does not start with the lens zoomed out to the max, and then only zooms in from that point. Instead, they start with the lens zoomed somewhere around where their experience tell them is the best zoom factor for the kind of picture they are taking, then they trim the zoom both in and out a little bit from that point while watching the model in the viewfinder, until he/she looks "just right". It is a fast and fluid way of working with a camera.
-
Because there is no substance to nctnico's endless arguments on this. Wuerstchenhund put it beautifully:
Don't get me wrong, I'm not trying to do things differently, if it works for you be my guest. But so far I have seen no data which shows any benefit of your method over the standard way, and I don't believe the need of a scope to support such a (clearly very niche) methodology should be very high on a list of recommendations.
We're waiting to have any explanation of why this method makes sense, not just some handwaving excuses around why alternatives are not fit for the overly specific and narrow use case.
I don't care about ntcnico's claims, he can defend them himself. But if you cannot see how having capture data outside of the display area could be potentially useful, then I don't know what else to say, apart from "surely the potential advantage is obvious to any experienced engineer." There is no need to give specific examples, use your imagination.
-
Obviously with Keysight having the fastest update rate and having this feature, that's obviously not a trade off that needs to be made in basic scope design.
Keysights usually have much less memory to process than the others.
-
We're waiting to have any explanation of why this method makes sense, not just some handwaving excuses around why alternatives are not fit for the overly specific and narrow use case.
Imagine a camera with a zoom lens. An experienced photographer does not start with the lens zoomed out to the max, and then only zooms in from that point. Instead, they start with the lens zoomed somewhere around where their experience tell them is the best zoom factor for the kind of picture they are taking, then they trim the zoom both in and out a little bit from that point while watching the model in the viewfinder, until he/she looks "just right". It is a fast and fluid way of working with a camera.
Again, analogies fall apart. The proposed "zoom out" is nctnico looking at an intentionally zoomed in view, with the expectation that interesting things will be captured in the larger acquisition which isn't being seen (from their prior knowledge of the scene). Nothing at all like you are describing.
Because there is no substance to nctnico's endless arguments on this. Wuerstchenhund put it beautifully:
Don't get me wrong, I'm not trying to do things differently, if it works for you be my guest. But so far I have seen no data which shows any benefit of your method over the standard way, and I don't believe the need of a scope to support such a (clearly very niche) methodology should be very high on a list of recommendations.
We're waiting to have any explanation of why this method makes sense, not just some handwaving excuses around why alternatives are not fit for the overly specific and narrow use case.
I don't care about ntcnico's claims, he can defend them himself. But if you cannot see how having capture data outside of the display area could be potentially useful, then I don't know what else to say, apart from "surely the potential advantage is obvious to any experienced engineer." There is no need to give specific examples, use your imagination.
I've tried to imagine a reason it could be better than using a zoom window, I can't see it. Having to manipulate the view is more button presses compared to having all that visible on the screen at the same time. I don't deny its useful in some circumstances, but the "arguments" for it are nonsense, and plainly untrue. So much confusion created for almost no benefit.
Just dropping "hard fail" without actually getting others to understand the reasons is the disruptive behaviour.
-
Having to manipulate the view is more button presses
That's exactly the point. When I do this I'm debugging something, usually real time systems where you can't alter the timing to debug. So verify one thing and check others away from the trigger after. In my case my triggers are generated by hardware. My other option would be long timebase capture, zoom in to verify item 1 and then zoom out and scroll more to check item 2. It's 1 less step. So one more step at beginning of debug session to set mem depth and then saving steps after. Timing is tight, data is slow.
-
Having to manipulate the view is more button presses
That's exactly the point. When I do this I'm debugging something, usually real time systems where you can't alter the timing to debug. So verify one thing and check others away from the trigger after. In my case my triggers are generated by hardware. My other option would be long timebase capture, zoom in to verify item 1 and then zoom out and scroll more to check item 2. It's 1 less step. So one more step at beginning of debug session to set mem depth and then saving steps after. Timing is tight, data is slow.
I'm not sure you're completely explaining the possibilities.
0) Set a wide view, zoom in later to see other things (button/knob pressing each time)
1) Set a memory depth manually, view the narrow point of interest with memory around the screen, zoom out later to see other things (slightly more setup, similar button/knob pressing each time)
2) Set a zoom view/window so both are visible at the same time on the screen (once-off setup)
....
option 185468783) use two scopes
Its a world of possibilities, none is always the best choice.
-
Take the Rigol DS1000z. We now established that, if you set the memory to manual then it will always record the full selected memory size, no matter what. Great, right? :-+
But here's the thing: on the DS1000z at least, you can't always access that data. In RUN mode, if you switch to zoom mode, you can still only zoom *in* on the signal on screen, but not zoom *out* to look at off-screen data.
On the DSO1014A (a Rigol design), with Zoom off, in Run mode, but with no triggers happening, you can use the horizontal scale & position knobs to move the displayed trace around within the offscreen captured data, and change the displayed duration. If you then turn Zoom on, you get a zoomed view of the currently displayed part of the captured data, even if it was originally off screen. The horizontal scale & position knobs change mode to operate as zoom and pan within the displayed window. Turn off Zoom and you can move to a different part of the captured data, rinse & repeat.
This could actually be quite useful: I didn't know you could do this! Do the more recent Rigols work in the same way? I'll check the X3000T as well now, I'm intrigued.
I can confirm the X3000T works in the same way, in Stop/Single mode. If there is off-screen captured data, you can use the horizontal controls in ordinary mode to bring it on screen, then use the zoom mode to zoom in on the displayed part.
One more wrinkle: you only get off-screen data from the 'magic' last capture in Stop/Single mode if the ADC sample rate is 5GHz (with one channel of each pair active). Presumably, if the sample rate is any lower, all the available memory is in use anyway.
You might get "off screen data" again if you increase the horizontal speed by 1 step compared with using 1 channel. (That is how it works on the 54622D.)
I didn't check but I think you are right, that is how Megazoom works. The guiding principles seem to be:
- Memory control is automatic, and the scope will always use as much of the available memory as it can, subject to not compromising the waveform update rate
- If memory is available, it is used first to provide the highest possible sample rate (this is what I mean by 'designed to zoom in')
- If the ADC is running at maximum speed, memory is used to provide off-screen capture (like it was in the very earliest days of DSOs with more than one screensworth of memory), but this only happens on transition to Stop/Single mode
You will only get off-screen capture at the faster X scale settings. The switchover point depends on the memory size & ADC speed. The MZ4 scopes like the X3000T have a relatively short memory and a fast ADC (4Mpoints/5gsps), so the switchover happens at much faster X scale than it did with the 54645D which @nctnico mentioned he was using when he developed his technique (1Mpoints/200Msps). With the latest MXR scope the balance is swinging back the other way - 400Mpoints/16Gsps. As soon as I can borrow one of these I will check its behaviour & report back ;).
However, instead of using 'spare' memory for off screen capture, I rather like the Siglent technique of keeping a history of previous acquisitions you can go back and look at - I'm always too slow pressing Stop when soemthing happens!
-
While it is true many lost cost DSO's with Zoom mode only provide a 50/50 split of the display do indeed limit usability while upper entry level DSOs provide a much better split ratio where buyers of which are more accustomed to not needing so much visual reference of the primary timebase when in fact they want a larger zoomed timebase which is what they primarily work with.
You don't need to use the zoom function (split window view) at all if you don't want to. In the absence of triggers, or in Stop/Single mode, the horizontal scale & position controls will let you zoom in & out to the full extent of the captured data.
-
While it is true many lost cost DSO's with Zoom mode only provide a 50/50 split of the display do indeed limit usability while upper entry level DSOs provide a much better split ratio where buyers of which are more accustomed to not needing so much visual reference of the primary timebase when in fact they want a larger zoomed timebase which is what they primarily work with.
You don't need to use the zoom function (split window view) at all if you don't want to. In the absence of triggers, or in Stop/Single mode, the horizontal scale & position controls will let you zoom in & out to the full extent of the captured data.
Yes, but using a zoom window you can see both long and short time details at the same time without having to adjust or move anything. If you have more flexibility in how to allocate traces and screen space to such windows then all the better.
Both useful approaches depending on the specific circumstances.
-
While it is true many lost cost DSO's with Zoom mode only provide a 50/50 split of the display do indeed limit usability while upper entry level DSOs provide a much better split ratio where buyers of which are more accustomed to not needing so much visual reference of the primary timebase when in fact they want a larger zoomed timebase which is what they primarily work with.
You don't need to use the zoom function (split window view) at all if you don't want to.
Of course not however it gives the fullest pre and post trigger capture which in the case of a deep memory DSO could be 100+ Mpts before and after the trigger.
-
While it is true many lost cost DSO's with Zoom mode only provide a 50/50 split of the display do indeed limit usability while upper entry level DSOs provide a much better split ratio where buyers of which are more accustomed to not needing so much visual reference of the primary timebase when in fact they want a larger zoomed timebase which is what they primarily work with.
You don't need to use the zoom function (split window view) at all if you don't want to.
Of course not however it gives the fullest pre and post trigger capture which in the case of a deep memory DSO could be 100+ Mpts before and after the trigger.
Maybe that is the case on Siglent scopes, but on InfiniVision scopes it is nothing more than a different view of the same data, after capture. You can always set the trigger delay to whatever you need, before or after the trigger event. The actual trigger event doesn't even have to be included in the capture at all, if that is what you want.
-
I've tried to imagine a reason it could be better than using a zoom window, I can't see it. Having to manipulate the view is more button presses compared to having all that visible on the screen at the same time. I don't deny its useful in some circumstances
Glad you agree.
-
Ultimately we all know what will start the third world war.
-
While it is true many lost cost DSO's with Zoom mode only provide a 50/50 split of the display do indeed limit usability while upper entry level DSOs provide a much better split ratio where buyers of which are more accustomed to not needing so much visual reference of the primary timebase when in fact they want a larger zoomed timebase which is what they primarily work with.
You don't need to use the zoom function (split window view) at all if you don't want to.
Of course not however it gives the fullest pre and post trigger capture which in the case of a deep memory DSO could be 100+ Mpts before and after the trigger.
Maybe that is the case on Siglent scopes, but on InfiniVision scopes it is nothing more than a different view of the same data, after capture. You can always set the trigger delay to whatever you need, before or after the trigger event. The actual trigger event doesn't even have to be included in the capture at all, if that is what you want.
On a DSO data is acquired around the point-of-origin (usually center) position on the screen. The trigger point is just a time offset from the point-of-origin.
-
While it is true many lost cost DSO's with Zoom mode only provide a 50/50 split of the display do indeed limit usability while upper entry level DSOs provide a much better split ratio where buyers of which are more accustomed to not needing so much visual reference of the primary timebase when in fact they want a larger zoomed timebase which is what they primarily work with.
You don't need to use the zoom function (split window view) at all if you don't want to.
Of course not however it gives the fullest pre and post trigger capture which in the case of a deep memory DSO could be 100+ Mpts before and after the trigger.
Maybe that is the case on Siglent scopes, but on InfiniVision scopes it is nothing more than a different view of the same data, after capture. You can always set the trigger delay to whatever you need, before or after the trigger event. The actual trigger event doesn't even have to be included in the capture at all, if that is what you want.
On a DSO data is acquired around the point-of-origin (usually center) position on the screen. The trigger point is just a time offset from the point-of-origin.
Absolutely incorrect in every way. Trigger point is THE reference point. Acquisition delay is specified from trigger point. All else is display presentation. Acquisition engine will decide how much pre-trigger and post-trigger data will get in part based on relation of trigger point position in relation to display reference position, and it's position on screen..
-
I don't care about ntcnico's claims, he can defend them himself. But if you cannot see how having capture data outside of the display area could be potentially useful, then I don't know what else to say, apart from "surely the potential advantage is obvious to any experienced engineer." There is no need to give specific examples, use your imagination.
I don't think anyone argues that data outside a window which shows a narrow view of a small part of a signal is not important, and I haven't seen any comment suggesting that.
In fact, the idea that surrounding data is important is the main idea behind deep memory scopes and the standard method of "capture long and zoom in". Because knowing that things outside the original point of interest may turn out very relevant, the reason why we have large memory in mopdern scopes is so we can capture the whole sequence right from the start, and then zoom in to the areas of interest (which there might be many).
So the question is not if data outside the (narrow) window is not important, but why is the scope set in a way that important data is outside the window in the first place.
The idea that one *needs* this "zoom out" capability one can make-do, under limited conditions, on some scopes, simply because the scope was set to show a very narrow part of the actual signal when one spontaneously decides to that the rest of the signal should be examined, too, suggests to me a lack of preparation. Because especially when you're bug hunting it shouldn't really come to a surprise that parts outside that initial narrow piece of interest will become relevant. Capturing long means having every part of the signal inside view and thereby quickly available for examination in a coherent manner.
And even if you got yourself in a situation where you found your original capture was too short, instead of make-do with "zoom out" it might make a lot more sense to finally set that timebase to capture long so you avoid finding yourself in the same predicament again a few minutes later.
So I fully agree with you, data outside that narrow screen is useful, more often than not. Which raises the question why is important data outside the screen area in the first place. This off-screen data being important is even more reason to make sure right from the start to capture everything in a long acquisition.
-
Imagine a camera with a zoom lens. An experienced photographer does not start with the lens zoomed out to the max, and then only zooms in from that point. Instead, they start with the lens zoomed somewhere around where their experience tell them is the best zoom factor for the kind of picture they are taking, then they trim the zoom both in and out a little bit from that point while watching the model in the viewfinder, until he/she looks "just right". It is a fast and fluid way of working with a camera.
Very bad analogy. Because optical zoom on a camera changes the resolution per scene area, so capturing pictures fully zoomed out will result in a loss of information when creating closer-ups from that 'acquisition'.
On deep memory scope however, capturing long and zooming in does not result in a loss of information, because neither the vertical resolution nor the sample rate changes over capturing short.
I can tell you that, if the loss of information (detail) wasn't a problem with zoom then many photographers would gladly capture fully zoomed out, because by capturing excess scenery they can later easily adjust the actual image size and position without having to go back to the place of scene and re-capture.
-
Gentlemen, you are ALL talking the same language!
Nico starts with zoom in and likes to be able to zoom out. The others start with zoom out and like to be able to zoom in.
It's all the same, but in reverse order.
All the rest are just details (and personal preferences or lifelong habits)!
Unfortunately, it's not the same.
"Zooming in" as in the standard method is done (you guessed it!) through the scope's zoom function. It provides references as for the position on the captured signal, can be displayed together with the full signal and works for single and continuous acquisitions.
As to "zooming out", most scopes don't allow zooming outside the scope area.
However, some scopes allow post-acquisition change of the timebase.
Nico's method uses this as a means to "zoom out". However, it's not really a zoom, it's a change of timebase post-acq. And because it's a change of timebase post-acq, it *only* works if the scope is halted (i.e. no new triggers) and you can't display it together with the "zoomed in" view (well, you could probably use waveform memory, but you'd lprobably ose the timing information).
So while the end result of both methods are the same in the cases where Nico's method works, they are *not* achieved the same way.
-
[...] However, instead of using 'spare' memory for off screen capture, I rather like the Siglent technique of keeping a history of previous acquisitions you can go back and look at [...]
Is that what "save to disk" or "save to usb" etc does?
-
To go back to the transmission analogy, I learned to drive on a manual and hated automatics as I always knew (thought) I could do better, even when I had an Audi A6, IMHO I did a better job than the transmission.
That's more down to Audi's habit of selling automatic vehicles in the U.S. (and some other markets) with a 'comfort oriented' (i.e. slow) transmission mapping.
I remember many years ago when I was still in Germany, someone did some test between automatic (using torque converter) and manual cars. That was probably 20 years ago, and even back then the auto beat the average (German) driver by a long shot. The bottom line was that, unless you're a professional racing driver, the auto is doing the better job :)
My first cars were manual but I never really liked it, and I find it particularly annoying in stop-and-go traffic. I'd probably take a manual over a car with one of these horrible CVTs, though.
So I'll stick with (torque converter) automatic until Ford comes up with the F-150 Electric , thank you very much! ;)
-
[...] However, instead of using 'spare' memory for off screen capture, I rather like the Siglent technique of keeping a history of previous acquisitions you can go back and look at [...]
Is that what "save to disk" or "save to usb" etc does?
No, scope memory is used in seamless segmented mode, meaning scope keeps hundreds of previous "screens" (trigger events) at all times, transparently. With no performance impact to normal use.
-
Imagine a camera with a zoom lens. An experienced photographer does not start with the lens zoomed out to the max, and then only zooms in from that point. Instead, they start with the lens zoomed somewhere around where their experience tell them is the best zoom factor for the kind of picture they are taking, then they trim the zoom both in and out a little bit from that point while watching the model in the viewfinder, until he/she looks "just right". It is a fast and fluid way of working with a camera.
Very bad analogy. Because optical zoom on a camera changes the resolution per scene area, so capturing pictures fully zoomed out will result in a loss of information when creating closer-ups from that 'acquisition'.
On deep memory scope however, capturing long and zooming in does not result in a loss of information, because neither the vertical resolution nor the sample rate changes over capturing short.
I can tell you that, if the loss of information (detail) wasn't a problem with zoom then many photographers would gladly capture fully zoomed out, because by capturing excess scenery they can later easily adjust the actual image size and position without having to go back to the place of scene and re-capture.
If you have enough RAM in the scope, of course I agree. But if you capture a "zoomed out" picture of a waveform on your scope of say, 10 seconds, just to pick an extreme, and your scope does not have enough RAM to capture that at full resolution, there is indeed a loss of quality compared to capturing a smaller time slice at a higher rate. That's my situation...
-
[...] However, instead of using 'spare' memory for off screen capture, I rather like the Siglent technique of keeping a history of previous acquisitions you can go back and look at [...]
Is that what "save to disk" or "save to usb" etc does?
No, scope memory is used in seamless segmented mode, meaning scope keeps hundreds of previous "screens" (trigger events) at all times, transparently. With no performance impact to normal use.
So you can scroll back and view previous events? - That does sound kind of cool.
-
Imagine a camera with a zoom lens. An experienced photographer does not start with the lens zoomed out to the max, and then only zooms in from that point. Instead, they start with the lens zoomed somewhere around where their experience tell them is the best zoom factor for the kind of picture they are taking, then they trim the zoom both in and out a little bit from that point while watching the model in the viewfinder, until he/she looks "just right". It is a fast and fluid way of working with a camera.
Very bad analogy. Because optical zoom on a camera changes the resolution per scene area, so capturing pictures fully zoomed out will result in a loss of information when creating closer-ups from that 'acquisition'.
On deep memory scope however, capturing long and zooming in does not result in a loss of information, because neither the vertical resolution nor the sample rate changes over capturing short.
I can tell you that, if the loss of information (detail) wasn't a problem with zoom then many photographers would gladly capture fully zoomed out, because by capturing excess scenery they can later easily adjust the actual image size and position without having to go back to the place of scene and re-capture.
If you have enough RAM in the scope, of course I agree. But if you capture a "zoomed out" picture of a waveform on your scope of say, 10 seconds, just to pick an extreme, and your scope does not have enough RAM to capture that at full resolution, there is indeed a loss of quality compared to capturing a smaller time slice at a higher rate. That's my situation...
If you have short memory scope there won't be any data "outside the screen" either..
-
Gentlemen, you are ALL talking the same language!
Nico starts with zoom in and likes to be able to zoom out. The others start with zoom out and like to be able to zoom in.
It's all the same, but in reverse order.
All the rest are just details (and personal preferences or lifelong habits)!
Unfortunately, it's not the same.
"Zooming in" as in the standard method is done (you guessed it!) through the scope's zoom function. It provides references as for the position on the captured signal, can be displayed together with the full signal and works for single and continuous acquisitions.
As to "zooming out", most scopes don't allow zooming outside the scope area.
However, some scopes allow post-acquisition change of the timebase.
Nico's method uses this as a means to "zoom out". However, it's not really a zoom, it's a change of timebase post-acq. And because it's a change of timebase post-acq, it *only* works if the scope is halted (i.e. no new triggers) and you can't display it together with the "zoomed in" view (well, you could probably use waveform memory, but you'd lprobably ose the timing information).
So while the end result of both methods are the same in the cases where Nico's method works, they are *not* achieved the same way.
There is only so much real estate on the screen. If you already have 2 analog channels plus a handful of digital ones, using the zoom window becomes a bit of a pain (uses too much space) compared to just altering the timebase "post facto". Those multi-channel captures are also the kinds of scenarios where you most often end up looking for things that happened "off screen", in my experience at least.
-
[...] However, instead of using 'spare' memory for off screen capture, I rather like the Siglent technique of keeping a history of previous acquisitions you can go back and look at [...]
Is that what "save to disk" or "save to usb" etc does?
No, scope memory is used in seamless segmented mode, meaning scope keeps hundreds of previous "screens" (trigger events) at all times, transparently. With no performance impact to normal use.
So you can scroll back and view previous events? - That does sound kind of cool.
Not only scroll. Search, measure, make histograms, create display persistence (overlap them all), decode protocols...etc...
-
Imagine a camera with a zoom lens. An experienced photographer does not start with the lens zoomed out to the max, and then only zooms in from that point. Instead, they start with the lens zoomed somewhere around where their experience tell them is the best zoom factor for the kind of picture they are taking, then they trim the zoom both in and out a little bit from that point while watching the model in the viewfinder, until he/she looks "just right". It is a fast and fluid way of working with a camera.
Very bad analogy. Because optical zoom on a camera changes the resolution per scene area, so capturing pictures fully zoomed out will result in a loss of information when creating closer-ups from that 'acquisition'.
On deep memory scope however, capturing long and zooming in does not result in a loss of information, because neither the vertical resolution nor the sample rate changes over capturing short.
I can tell you that, if the loss of information (detail) wasn't a problem with zoom then many photographers would gladly capture fully zoomed out, because by capturing excess scenery they can later easily adjust the actual image size and position without having to go back to the place of scene and re-capture.
If you have enough RAM in the scope, of course I agree. But if you capture a "zoomed out" picture of a waveform on your scope of say, 10 seconds, just to pick an extreme, and your scope does not have enough RAM to capture that at full resolution, there is indeed a loss of quality compared to capturing a smaller time slice at a higher rate. That's my situation...
If you have short memory scope there won't be any data "outside the screen" either..
There is off screen data as long as the timebase is running fast enough to use less RAM than what is required to display the image on the screen.
So basically, the more RAM the scope has, the slower the timebase setting that the Megazoom off-screen idea will be work with... bottom line, more RAM benefits all scopes?
-
Gentlemen, you are ALL talking the same language!
Nico starts with zoom in and likes to be able to zoom out. The others start with zoom out and like to be able to zoom in.
It's all the same, but in reverse order.
All the rest are just details (and personal preferences or lifelong habits)!
Unfortunately, it's not the same.
"Zooming in" as in the standard method is done (you guessed it!) through the scope's zoom function. It provides references as for the position on the captured signal, can be displayed together with the full signal and works for single and continuous acquisitions.
As to "zooming out", most scopes don't allow zooming outside the scope area.
However, some scopes allow post-acquisition change of the timebase.
Nico's method uses this as a means to "zoom out". However, it's not really a zoom, it's a change of timebase post-acq. And because it's a change of timebase post-acq, it *only* works if the scope is halted (i.e. no new triggers) and you can't display it together with the "zoomed in" view (well, you could probably use waveform memory, but you'd lprobably ose the timing information).
So while the end result of both methods are the same in the cases where Nico's method works, they are *not* achieved the same way.
There is only so much real estate on the screen. If you already have 2 analog channels plus a handful of digital ones, using the zoom window becomes a bit of a pain (uses too much space) compared to just altering the timebase "post facto". Those multi-channel captures are also the kinds of scenarios where you most often end up looking for things that happened "off screen", in my experience at least.
Well, on R&S RTM3000 you can actually resize it . On Pico, you create views and size them at will. On Lecroy you can move and resize....
My problem with zoom mode on many scopes is also that it takes too much space. But that could be solved easily if we complain to manufactures long and loud enough.
-
Once again, may I point out that the 'zoom window' display (the equivalent of a dual timebase on an analogue scope) is not needed to zoom & pan either in or out post acquisition: just use the ordinary horizontal scale & position controls!
-
There is off screen data as long as the timebase is running fast enough to use less RAM than what is required to display the image on the screen.
So basically, the more RAM the scope has, the slower the timebase setting that the Megazoom off-screen idea will be work with... bottom line, more RAM benefits all scopes?
I answered to your scenario: after you slow down enough you don't have enough memory for either one long timebase capture, or one short timebase capture with afterscreen data.
And yes, for these kinds of problems more memory is more. But if you want to use it all the time, it makes scope slow.
-
Once again, may I point out that the 'zoom window' display (the equivalent of a dual timebase on an analogue scope) is not needed to zoom & pan either in or out post acquisition: just use the ordinary horizontal scale & position controls!
To make sure, for 3000T and Rigol that is correct. I don't know about the others.
But I LIKE zoom mode. It gives me overview where in the buffer I am. Also on 3000T, I just use touch screen to move around... I just wish that zoom window could change size (to be little smaller if I want) when it get crowded.
But, that is mostly because screen on 3000T is not very big.
-
Once again, may I point out that the 'zoom window' display (the equivalent of a dual timebase on an analogue scope) is not needed to zoom & pan either in or out post acquisition: just use the ordinary horizontal scale & position controls!
To make sure, for 3000T and Rigol that is correct. I don't know about the others.
But I LIKE zoom mode. It gives me overview where in the buffer I am. Also on 3000T, I just use touch screen to move around... I just wish that zoom window could change size (to be little smaller if I want) when it get crowded.
But, that is mostly because screen on 3000T is not very big.
Interesting; the DS4014 has a handy top "entire buffer" view that does the same thing and uses almost zero screen realstate. (Unless you mean something else, of course)
-
Imagine a camera with a zoom lens. An experienced photographer does not start with the lens zoomed out to the max, and then only zooms in from that point. Instead, they start with the lens zoomed somewhere around where their experience tell them is the best zoom factor for the kind of picture they are taking, then they trim the zoom both in and out a little bit from that point while watching the model in the viewfinder, until he/she looks "just right". It is a fast and fluid way of working with a camera.
Very bad analogy. Because optical zoom on a camera changes the resolution per scene area, so capturing pictures fully zoomed out will result in a loss of information when creating closer-ups from that 'acquisition'.
On deep memory scope however, capturing long and zooming in does not result in a loss of information, because neither the vertical resolution nor the sample rate changes over capturing short.
I can tell you that, if the loss of information (detail) wasn't a problem with zoom then many photographers would gladly capture fully zoomed out, because by capturing excess scenery they can later easily adjust the actual image size and position without having to go back to the place of scene and re-capture.
If you have enough RAM in the scope, of course I agree.
I guess you mean sample memory, not RAM ;)
But if you capture a "zoomed out" picture of a waveform on your scope of say, 10 seconds, just to pick an extreme, and your scope does not have enough RAM to capture that at full resolution, there is indeed a loss of quality compared to capturing a smaller time slice at a higher rate. That's my situation...
That is true of course, however if your scope has insufficient memory to capture a full sequence of whatever you're dealing with then you either have to capture a shorter sequence or, if the signal properties permit, capture long but at reduced sample rate.
In any ase, if the memory is insufficient to "capture long" then it is also insufficient for Nico's method.
But quite often, signals with long periods are also low BW signals, so you might well be able to capture the whole sequence at a reduced sample rate that is still sufficiently high.
-
As for MCUs or like many others things, the best scope is the one that fit your needs of the one you know best.
I like zoom mode because I can see my data in context but I can see the same data with different methods, Im not a Nazi.
It depends on what I'm trying to measure, my progress in debugging or my mood of the day.
And I can do all of that because my scope is the best >:D
-
Once again, may I point out that the 'zoom window' display (the equivalent of a dual timebase on an analogue scope) is not needed to zoom & pan either in or out post acquisition: just use the ordinary horizontal scale & position controls!
But not all scopes will or can capture longer memory around the visible window.... the entire point of this discussion. So for those scopes zoom is a way to achieve the same thing. (loses some screen realestate, gains independent control of trigger/window/acquisition positioning)
-
Once again, may I point out that the 'zoom window' display (the equivalent of a dual timebase on an analogue scope) is not needed to zoom & pan either in or out post acquisition: just use the ordinary horizontal scale & position controls!
To make sure, for 3000T and Rigol that is correct. I don't know about the others.
But I LIKE zoom mode. It gives me overview where in the buffer I am. Also on 3000T, I just use touch screen to move around... I just wish that zoom window could change size (to be little smaller if I want) when it get crowded.
But, that is mostly because screen on 3000T is not very big.
Interesting; the DS4014 has a handy top "entire buffer" view that does the same thing and uses almost zero screen realstate. (Unless you mean something else, of course)
Pretty much something like that. Maybe a bit bigger, just to get a glimpse of shapes....
-
There is only so much real estate on the screen. If you already have 2 analog channels plus a handful of digital ones, using the zoom window becomes a bit of a pain (uses too much space) compared to just altering the timebase "post facto".
Nico made the same argument earlier on, and I have to say the same here: if your scope is so cramped that all the information you regularly need is difficult to read then that's a UX problem with that particular scope, and if you face this situation more often then I would seriously consider changing to a better scope.
Those multi-channel captures are also the kinds of scenarios where you most often end up looking for things that happened "off screen", in my experience at least.
As I said in my response to Dave's similar argument, this to me is more a case of bad preparation than anything else. If you think a bit about what you are going to do, what you expect to achieve and what you might encounter, it should be clear right from the start that you will very likely will need to look at signal segments other than the original point of interest.
And if you make it a habit to always capture as long as sensible/possible then you are unlikely to find yourself in the situation that you need to access data which isn't instantly available and without having to stop the scope.
-
This thread has been interesting and I have learned something useful about how my scopes work and how they differ in their approach to memory usage. However, we now seem to be going round and round the same point and are :horse:
You guys seem to be arguing over whose method of scope usage is "right" or "better".
How about of we all try to summarize our positions and then we can all get back to doing important stuff like playing Candy Crush?
-
This thread has been interesting and I have learned something useful about how my scopes work and how they differ in their approach to memory usage. However, we now seem to be going round and round the same point and are :horse:
You guys seem to be arguing over whose method of scope usage is "right" or "better".
How about of we all try to summarize our positions and then we can all get back to doing important stuff like playing Candy Crush?
You say that because you're the only one here who can't even see the data on your screen like you broke it during a pee break ;D
-
Once again, may I point out that the 'zoom window' display (the equivalent of a dual timebase on an analogue scope) is not needed to zoom & pan either in or out post acquisition: just use the ordinary horizontal scale & position controls!
To make sure, for 3000T and Rigol that is correct. I don't know about the others.
But I LIKE zoom mode. It gives me overview where in the buffer I am. Also on 3000T, I just use touch screen to move around... I just wish that zoom window could change size (to be little smaller if I want) when it get crowded.
But, that is mostly because screen on 3000T is not very big.
Interesting; the DS4014 has a handy top "entire buffer" view that does the same thing and uses almost zero screen realstate. (Unless you mean something else, of course)
Pretty much something like that. Maybe a bit bigger, just to get a glimpse of shapes....
Thanks. With all the discussion about the screen realstate and the impact that multiple views and waveforms have on the usability of the scope, I can't help but wonder how the manufacturers still don't seem to take advantage of multi-display feature that exists for so long in personal computers. Sure, the ability to use an external monitor is ok, but it only expands what is shown in the screen - far from having a real method of putting different views on each screen.
I was hopeful when the LeCroy guys came to do a demo of their products a few months ago and showed the nice interface, which could tile the different views and have a flexible arrangement on its large display, but only to find out not only the views couldn't be freely resized and rearranged (a feature present in any mainstream Windowed OS for the past 30 years) but also the lack of this more advanced "dual monitor" setup. Tek was the same thing, only with a much slower UI.
-
Thanks. With all the discussion about the screen realstate and the impact that multiple views and waveforms have on the usability of the scope, I can't help but wonder how the manufacturers still don't seem to take advantage of multi-display feature that exists for so long in personal computers. Sure, the ability to use an external monitor is ok, but it only expands what is shown in the screen - far from having a real method of putting different views on each screen.
I sometimes wondered the same, but one reason might be that, in my experience, most of the time people use the external monitor port it's because they want to replicate the internal display, be it for showing it to a larger group (i.e. bigger screen) or recording the output signal for documentation.
We have a few setups where the 2nd monitor isn't mirrored, but that is for displaying external applications which run on the scope (like the KS VSA software).
There's also the thing that, on simpler scopes, there isn't really *that* much to display, and more capable scopes already come with larger and higher resolution screens, sufficient to show lots of different information ergonomically.
I'm not sure the demand is there to justify making the scope application multi-head capable, even on high end scopes.
I was hopeful when the LeCroy guys came to do a demo of their products a few months ago and showed the nice interface, which could tile the different views and have a flexible arrangement on its large display, but only to find out not only the views couldn't be freely resized and rearranged (a feature present in any mainstream Windowed OS for the past 30 years) but also the lack of this more advanced "dual monitor" setup. Tek was the same thing, only with a much slower UI.
Well, with an external screen you can still get more screen area by using a higher resolution display, and if the display is touch capable then you can also retain touch functionality.
-
[...]
And if you make it a habit to always capture as long as sensible/possible then you are unlikely to find yourself in the situation that you need to access data which isn't instantly available and without having to stop the scope.
I guess that the Agilent/Keysight idea is to do that automatically, even if you have the scope set at a faster timebase. Can't really be argued that it is a harmful idea, and it is useful often enough that I noticed the behaviour and started using it.
-
Once again, may I point out that the 'zoom window' display (the equivalent of a dual timebase on an analogue scope) is not needed to zoom & pan either in or out post acquisition: just use the ordinary horizontal scale & position controls!
To make sure, for 3000T and Rigol that is correct. I don't know about the others.
But I LIKE zoom mode. It gives me overview where in the buffer I am. Also on 3000T, I just use touch screen to move around... I just wish that zoom window could change size (to be little smaller if I want) when it get crowded.
But, that is mostly because screen on 3000T is not very big.
Interesting; the DS4014 has a handy top "entire buffer" view that does the same thing and uses almost zero screen realstate. (Unless you mean something else, of course)
Pretty much something like that. Maybe a bit bigger, just to get a glimpse of shapes....
That mini view dates back to the earliest days of DSOs with more memory than would fit on screen: I think Tek originated it. It doesn't appear in the 1991 catalogue but by 1997 most DSO are shown with one. However, I think the 'wiggles' are a Rigol feature, Tek just used a flat line. And beware, the Rigol wiggles are just decoration, and have nothing to do with the actual captured waveform.
-
[...]
Those multi-channel captures are also the kinds of scenarios where you most often end up looking for things that happened "off screen", in my experience at least.
As I said in my response to Dave's similar argument, this to me is more a case of bad preparation than anything else. If you think a bit about what you are going to do, what you expect to achieve and what you might encounter, it should be clear right from the start that you will very likely will need to look at signal segments other than the original point of interest.
It seems a bit harsh, to tell the photographer that if he didn't get the zoom factor exactly right before looking in the viewfinder, he must be badly prepared... That isn't how everybody thinks.
Some people like "bump and feel" parking... if that was what we were talking about, I'd agree with you! - but using the zoom flexibly if the instrument supports it, seems to be just making good use of the tool.
Seems to me that just as cars all have different "personalities" that means they have to be driven slightly differently to get the best out of them, the same is true of scopes... so the real meaning of "preparation" is to understand what your particular scope can do, and make the best use of it?
-
Seems to me that just as cars all have different "personalities" that means they have to be driven slightly differently to get the best out of them, the same is true of scopes... so the real meaning of "preparation" is to understand what your particular scope can do, and make the best use of it?
Right on the money! Dave, or maybe even Shahriar, should do an in-depth video of the ins & outs of oscilloscope zooming, with specific examples. It would be instructive.
-
[...]
And if you make it a habit to always capture as long as sensible/possible then you are unlikely to find yourself in the situation that you need to access data which isn't instantly available and without having to stop the scope.
I guess that the Agilent/Keysight idea is to do that automatically, even if you have the scope set at a faster timebase. Can't really be argued that it is a harmful idea, and it is useful often enough that I noticed the behaviour and started using it.
Yes, 3000T doesn't really do it in RUN mode, and when you STOP, you get only 400us at full sample rate. If your problem domain is jumping between 2ns/div to 10us/div you're golden. I use it all the time on stopped acquisitions in that time scale. If you need to capture 10ms, you have to slow down.
None of that is supporting Nico's scenario: Capturing in constant RUN mode, with triggers happening every 10-20 seconds (or when he presses the button on DUT), he's looking at one SPI packet full screen (10 something micro seconds), and then if that SPI packet is not right, he pulls back to 100 ms around the trigger and looks at the state of some other inputs to figure out state of device at he moment.
And once he's happy with analysis, he presses the button on DUT for another go.. While staying in RUN mode all the time. No STOP or SINGLE.
To make sure he can do that, he keeps scope in manual memory mode, sets it to some large memory setting, so on every trigger event scope will get enough of data.
I do the same thing on Pico (3000T is not perfect for this). I set Pico to 100MS mem depth, set it to 10ms/div (100ms total) , zoom in to area arround trigger (or wherever the packet is in full capture), press RUN and off we go...At the bottom of screen, I will also have full decoded table of whole capture, where I can click and screen will zoom in and jump to that packet..When I'm ready to move forward I press button on DUT for next cycle.
I don't see how is what I do more complicated (in fact it's less steps and more intuitive), and result is the same.
-
It seems a bit harsh, to tell the photographer that if he didn't get the zoom factor exactly right before looking in the viewfinder, he must be badly prepared... That isn't how everybody thinks.
Then go and ask any professional photographer if he really prefers having to determine the exact position on scene with no way to change it later without a notable loss of quality, and if it the original decision turns out to be wrong to have to go back to the actual place of scene and re-take the shot, over just being able to capture some excess and then decide later in his lab on which segment he wants to have in the image (and being able to play with different sizes and individual objects on his computer). It's a no-brainer, really.
The *only* thing preventing this is the unavoidable loss of resolution (i.e. detail) that comes with taking a 'zoomed out' wide shot of the whole scenery and then 'cutting out' the interesting objects in separate images. WHich comes from the fact that the sensor resolution is fixed and when "zoomed out" that fixed resolution has to cover a larger scene area, thus resulting in a lower resolution per scene area than when zoomed in.
Some people like "bump and feel" parking... if that was what we were talking about, I'd agree with you! - but using the zoom flexibly if the instrument supports it, seems to be just making good use of the tool.
The thing is, he's *not* using the zoom, he's using post-acquisition timebase changes purely for the purpose to avoid using the zoom function, as it seems mostly because his scope (if I had to guess I'd say GWI) has a cramped UI.
You are right of course that some people like doing stuff differently. Some even believe that injecting Clorox into your veins is a good idea. And while people are free to do what they want (as long as it's not affecting others, that is), quite often these things are based on believe, prejudice and habits, and don't make much sense on a rational scale.
As to "making good use", despite this long thread I yet have to see *any* credible data demonstrating the claimed benefits of this method. On the contrary, because of this thread and people looking closer, we now have evidence that this non-standard method is, actually, severely limited, not just in support by scopes but also because it's need to having the scope halted for it to actually work.
I had the chance to quickly talk with some of our senior EEs about this during a telecon this morning, and let's just say that the feedback to this method hasn't been positive ('nuff said).
Seems to me that just as cars all have different "personalities" that means they have to be driven slightly differently to get the best out of them, the same is true of scopes...
No, really not. The fundamental concept of *any* digital scope is that it allows you to capture (more or less, depending on the memory) long sequences and then lets you zoom in to the details. That's what they are designed for. It's really as straight forward as that.
And we should really stop with car analogies, because they are as stupid here as they are in most other situations they are used. Even more so when a lot of stuff regardings cars plays at emotional levels, not at technical ones.
Scopes aren't cars, they are test instrument to perform specific measurements based on scientific principles, working after an established understanding. Yes, there are differences in functionality and implementation, specs and cost, but they don't change the fact that they all conform to same fundamental concept. So because they aren't cars, you should not treat them as such.
so the real meaning of "preparation" is to understand what your particular scope can do, and make the best use of it?
The meaning of preparation is to avoid jumping in blindsighted and then stumble at the first "ohh" moment when you realize you missed some crucial stuff (and yes, I am aware that this is exactly what many hobbyists do).
Testing doesn't mean just poking something with an instrument to see what's coming out. Testing properly means working methodologically, you have to spend some time thinking about what you have, what you want to achieve, what you ideally expect, what problems/issues you may encounter and how to address them, and then develop a test strategy which will give you the desired data in a reasonable amount of time and with reasonable effort. And then you go and execute your strategy. And if your strategy was sensible you get the data you need. If not, you re-strategize and execute again. Simples.
-
Testing doesn't mean just poking something with an instrument to see what's coming out. Testing properly means working methodologically, you have to spend some time thinking about what you have, what you want to achieve, what you ideally expect, what problems/issues you may encounter and how to address them, and then develop a test strategy which will give you the desired data in a reasonable amount of time and with reasonable effort. And then you go and execute your strategy.
And how does this tie in with the subject of this thread? You are still trying to convince people using half truths and straw man arguments an automatic gearbox should be used in manual mode only 'just because...'. Because of what?
So far your arguments seem to be:
- people who use recording beyond the screen are stupid and dumb
- an oscilloscope is not intended to do recording beyond the screen (I can show you a Tektronix manual which says otherwise but that wouldn't fit your Lecroy narrative)
All I'm seeing is someone who clearly isn't making his living using test equipment trying to tell real engineers how to do their job the right way as god intended. You just quoting randomly from the '10 Commandments of measuring' proves this.
-
The point is, zooming out is a crutch covering the far better methodology of zooming in.
Err, they aren't mutually exclusive!
Every scope works by zooming in, but it seems like the likes of Keysight have thought about it and implemented it slightly different to give you a potential added benefit if you so desire it.
No, the problem is definitely that some seem to be stuck in the idea that you should always zoom in and use exact settings.
Alternatively, others are stuck on zoom out methodology which severely limits the capability of the tool in front of you.
He's just taking advantage of a feature of the scope that gives benefit to him in some cases. I don't see the problem with this and in publicising it.
I greatly doubt he uses it in every case, in fact that's not even possible.
Then why promote an arse backwards modus operandi when the tool set in most modern scopes is many times more capable ?
While you are entitled to work with a scope in another 'round about' way those that you may train will have a shock if they go to work for others where zooming in is the universally accepted methodology.
Why be so hostile about learning a new way to get something done?
I'll offer you another memory trigger.
Certain members have used this arse backwards capture analysis MO to attack brands that don't support it and poisoned many threads over the years......if you need a further memory trigger, they have resulted in warnings and bans.
Is it because you never knew about it before?
::)
Is it because your beloved Siglent's don't have it?
Oh don't they ? Good, a brand that discourages arse backwards capture analysis.
But we need thank you Dave for pulling this discussion into its own thread where this weird capture analysis procedure gets some air and proper analysis of its own so it's clear that scopes, brands if you like and users each have their own toolset to undertake capture analysis albeit in some most unusual ways.
Now we have this thread I for one will be bookmarking it so further uncalled for poisonings of threads can be linked back here to let the reader decide what modus operandi are the universally accepted means of capture analysis and not some stabbing of buttons and twiddling of knobs but instead of a properly considered capture plan and a carefully set instrument.
-
M: An argument isn't just contradiction.
O: Well! it CAN be!
M: No it can't!
M: An argument is a connected series of statements intended to establish a proposition.
O: No it isn't!
M: Yes it is! 'tisn't just contradiction.
O: Look, if I *argue* with you, I must take up a contrary position!
M: Yes but it isn't just saying 'no it isn't'.
O: Yes it is!
M: No it isn't!
O: Yes it is!
M: No it isn't!
O: Yes it is!
M: No it ISN'T! Argument is an intellectual process. Contradiction is just the automatic gainsaying of anything the other person says.
O: It is NOT!
M: It is!
O: Not at all!
M: It is!
-
:-DD
-
[attachimg=1]
-
[...]
And if you make it a habit to always capture as long as sensible/possible then you are unlikely to find yourself in the situation that you need to access data which isn't instantly available and without having to stop the scope.
I guess that the Agilent/Keysight idea is to do that automatically, even if you have the scope set at a faster timebase. Can't really be argued that it is a harmful idea, and it is useful often enough that I noticed the behaviour and started using it.
Yes, 3000T doesn't really do it in RUN mode, and when you STOP, you get only 400us at full sample rate. If your problem domain is jumping between 2ns/div to 10us/div you're golden. I use it all the time on stopped acquisitions in that time scale. If you need to capture 10ms, you have to slow down.
None of that is supporting Nico's scenario: Capturing in constant RUN mode, with triggers happening every 10-20 seconds (or when he presses the button on DUT), he's looking at one SPI packet full screen (10 something micro seconds), and then if that SPI packet is not right, he pulls back to 100 ms around the trigger and looks at the state of some other inputs to figure out state of device at he moment.
And once he's happy with analysis, he presses the button on DUT for another go.. While staying in RUN mode all the time. No STOP or SINGLE.
To make sure he can do that, he keeps scope in manual memory mode, sets it to some large memory setting, so on every trigger event scope will get enough of data.
I do the same thing on Pico (3000T is not perfect for this). I set Pico to 100MS mem depth, set it to 10ms/div (100ms total) , zoom in to area arround trigger (or wherever the packet is in full capture), press RUN and off we go...At the bottom of screen, I will also have full decoded table of whole capture, where I can click and screen will zoom in and jump to that packet..When I'm ready to move forward I press button on DUT for next cycle.
I don't see how is what I do more complicated (in fact it's less steps and more intuitive), and result is the same.
When you set the scope in manual memory mode to capture more data, is the "punishment" then that you get less waveform updates per second?
-
[...]
Testing doesn't mean just poking something with an instrument to see what's coming out.
Well, most of the time that statement is accurate... but it seems very cut and dried unless you are in a controlled environment. Say you are repairing an unfamiliar and undocumented piece of equipment, you have absolutely no idea what is causing some obscure fault - so you are looking for clues. You might be following the "golden rule" of checking the supply voltages first, for example. So you might look for excessive noise on the lines. But at what frequency? Depends on the circuitry sipping the juice as much as the PSU, right? Could be 60Hz, 120Hz, or several megahertz. Taking a look around using different timebases suddenly seems more like a prudent strategy of elimination rather than random probing?
Testing properly means working methodologically, you have to spend some time thinking about what you have, what you want to achieve, what you ideally expect, what problems/issues you may encounter and how to address them, and then develop a test strategy which will give you the desired data in a reasonable amount of time and with reasonable effort. And then you go and execute your strategy. And if your strategy was sensible you get the data you need. If not, you re-strategize and execute again. Simples.
Sure, but that could describe playing chess or any other difficult activity... in other words, the description is not enough information to actually play the game well!
-
[...]
And if you make it a habit to always capture as long as sensible/possible then you are unlikely to find yourself in the situation that you need to access data which isn't instantly available and without having to stop the scope.
I guess that the Agilent/Keysight idea is to do that automatically, even if you have the scope set at a faster timebase. Can't really be argued that it is a harmful idea, and it is useful often enough that I noticed the behaviour and started using it.
Yes, 3000T doesn't really do it in RUN mode, and when you STOP, you get only 400us at full sample rate. If your problem domain is jumping between 2ns/div to 10us/div you're golden. I use it all the time on stopped acquisitions in that time scale. If you need to capture 10ms, you have to slow down.
None of that is supporting Nico's scenario: Capturing in constant RUN mode, with triggers happening every 10-20 seconds (or when he presses the button on DUT), he's looking at one SPI packet full screen (10 something micro seconds), and then if that SPI packet is not right, he pulls back to 100 ms around the trigger and looks at the state of some other inputs to figure out state of device at he moment.
And once he's happy with analysis, he presses the button on DUT for another go.. While staying in RUN mode all the time. No STOP or SINGLE.
To make sure he can do that, he keeps scope in manual memory mode, sets it to some large memory setting, so on every trigger event scope will get enough of data.
I do the same thing on Pico (3000T is not perfect for this). I set Pico to 100MS mem depth, set it to 10ms/div (100ms total) , zoom in to area arround trigger (or wherever the packet is in full capture), press RUN and off we go...At the bottom of screen, I will also have full decoded table of whole capture, where I can click and screen will zoom in and jump to that packet..When I'm ready to move forward I press button on DUT for next cycle.
I don't see how is what I do more complicated (in fact it's less steps and more intuitive), and result is the same.
When you set the scope in manual memory mode to capture more data, is the "punishment" then that you get less waveform updates per second?
If you set the scope to acquire 250ms worth of data every time it triggers, you get 4 triggers per second... It's that simple.
-
[...]
Certain members have used this arse backwards capture analysis MO to attack brands that don't support it
[...]
Which is of course silly, because any instrument has a large feature matrix of which this is only one item.
In the long run, most manufacturers end up having all the popular features implemented one way or another.
I know we shouldn't compare with cars, but since we love cars, it's hard not to... - if you are having an argument about which is best, standard or automatic gearbox, the answer inevitably depends on... who is driving the car.
-
When you set the scope in manual memory mode to capture more data, is the "punishment" then that you get less waveform updates per second?
If you set the scope to acquire 250ms worth of data every time it triggers, you get 4 triggers per second... It's that simple.
That also assumes the scope is completely "ideal" and has no processing limitations. At extremely slow timebases, some scopes can approach the theoretical rates but others don't come close (only a few %), recall that most of the "competitive" comparisons put the scopes in their best performing modes so its rare to see them compared at equal memory depths as shared above (or the famous dot mode use case that few people ever want). At the other extreme end with narrow timebases is where Mr W always drives the conversation to. There is a whole landscape of uses in-between with timebases in the KHz rates, performance at any particular timebase may not predict the performance elsewhere.
-
When you set the scope in manual memory mode to capture more data, is the "punishment" then that you get less waveform updates per second?
If you set the scope to acquire 250ms worth of data every time it triggers, you get 4 triggers per second... It's that simple.
That also assumes the scope is completely "ideal" and has no processing limitations. At extremely slow timebases, some scopes can approach the theoretical rates but others don't come close (only a few %), recall that most of the "competitive" comparisons put the scopes in their best performing modes so its rare to see them compared at equal memory depths as shared above (or the famous dot mode use case that few people ever want). At the other extreme end with narrow timebases is where Mr W always drives the conversation to. There is a whole landscape of uses in-between with timebases in the KHz rates, performance at any particular timebase may not predict the performance elsewhere.
You are correct, that is ideal case. You cannot get better than. I said it on purpose to show that even ideal case has consequences, there is no free lunch. Fixed manual memory management requires constant user effort. That is main reason many reason will pick Keysight scopes for interactive work, because they handle memory automatically. Rigol also has nice auto mode. Simply works.
-
[...] However, instead of using 'spare' memory for off screen capture, I rather like the Siglent technique of keeping a history of previous acquisitions you can go back and look at [...]
Is that what "save to disk" or "save to usb" etc does?
No, scope memory is used in seamless segmented mode, meaning scope keeps hundreds of previous "screens" (trigger events) at all times, transparently. With no performance impact to normal use.
So you can scroll back and view previous events? - That does sound kind of cool.
Not only scroll. Search, measure, make histograms, create display persistence (overlap them all), decode protocols...etc...
It looks like the new Keysight MXR has learned this trick as well:
- Standard history mode and segmented memory
Use the history mode to view previous trigger events over 1,024 acquired waveforms. The segmented memory enables the oscilloscope to capture over 5,000 future waveforms for analysis.
Source: https://www.keysight.com/gb/en/cmp/2020/introducing-the-world-s-first-8-channel-rtsa-oscilloscope.html (https://www.keysight.com/gb/en/cmp/2020/introducing-the-world-s-first-8-channel-rtsa-oscilloscope.html)
-
[...]
Testing doesn't mean just poking something with an instrument to see what's coming out.
Well, most of the time that statement is accurate... but it seems very cut and dried unless you are in a controlled environment. Say you are repairing an unfamiliar and undocumented piece of equipment, you have absolutely no idea what is causing some obscure fault - so you are looking for clues. You might be following the "golden rule" of checking the supply voltages first, for example. So you might look for excessive noise on the lines. But at what frequency? Depends on the circuitry sipping the juice as much as the PSU, right? Could be 60Hz, 120Hz, or several megahertz. Taking a look around using different timebases suddenly seems more like a prudent strategy of elimination rather than random probing?
It really doesn't matter if you're dealing with a familiar device or something new, really. Because there is always some basic information you will have. You may not be familiar with the UUT but you still must have some idea what it does, because if not then you wouldn't be able to determine what is faulty behavior and what not in the first place.
You always start from what you know, not from what you don't know. And the more you don't know about the UUT the more critical becomes proper preparation before you start probing.
In your noise example you wouldn't jump in with a scope. You'd first visually examine the device, check for visible damage, determine what kind of PSU it uses, how it seems to work and what voltages you expect to see where (which also are your first test points). You then might want to draw this out on a piece of paper and mark the points to test (and what voltage you'd expect at each point).
Right now you have already increased your knowledge about the UUT without even doing any measurements! But it's probably also as far as you can get visually with the amount of information you have, so to learn even more you need to start to gather additional data.
The first set of measurements should establish what the actual voltages are at the points you identified and if they are stable. Because knowing the voltages will help you to establish if your basic assumptions above about the PSU are correct. And the best tool to measure voltages isn't a scope, it's a DMM. Depending on the capabilities of your DMM you might also want to measure the AC component (low frequency noise, usually somewhere up to 1kHz) of DC voltages.
So you power up the device, measure the voltages and (for DC voltages also the AC components) at the test points and note them down in your drawing.
Then you go back to your paper which now has the new data, look at the test points and the expected and the measured voltages (and the measured AC component). If there are differences then you start examining the ciruitry which feeds the rail which shows the difference, deduct some schematics and calculate what the correct voltage and tolerable AC component would be. Maybe you determine you need additional data (i.e. the voltages over specific components), so add the additional test points to your drawing and perform another set of measurements which gives you even more data. Then you go back to your drawing to evaluate the data and find out if the results are as expected or not.
If so far everything has worked out then the point comes where you look at noise, and for that the scope is probably the best tool. But agin, you shouldn't just jump in, twiddling knobs until something appears on the screen. You spend some time thinking about what information you want (here: amplitude and frequency of noise if there's any) and what can you get, based on the limitations of your test equipment.
Let's for the moment assume all you have is a DS1054z, i.e. a basic scope with no power analysis or other advanced stuff, plus some passive x10 probes (say 250MHz). In single channel mode you get 1GSa/s and an analog BW of (hacked) around 130MHz. Therefore any noise you can find with your scope will be within a range of ]0Hz;130MHz]. Also, the noise amplitude needs to exceed the scope's + probe's internal noise, as otherwise it would get hidden in your test equipment's noise floor. So let's say (let's assume for the moment the DS1054z noise floor is at 800uV, or 8mV with an x10 probe). So clearly, you're not capturing very low noise levels (which still might shift the power rail outside spec) or noise components of more of approx 130MHz.
The DMM measurments already covered AC ripple up to 1kHz (if not then you'd want measurements specific for that). Which means the noise frequency you want to look at would be [1kHz;130MHz]. 1kHz means a period is 1ms long, and ideally you want to capture at least three of them. A DS1054z with 24Mpts will be able to capture 10 periods (10ms) at full 1GSa/s sample rate (using 10Mpts memory), so the scope should be set to a timebase of 1ms/div. Set trigger mode to AUTO, trigger level to say 10mV, enable Vpp and Vrms measurements, then start to probe. Connect to the test point and turn up the vertical div setting to increase the signal to cover as much screen space as possible without extruding from it. Enable zoom and zoom in to check various sizes of a signal segment for any visible AC content. In your example, lets assume that most PSU rails are OK but there is one with lots of noise. So you make sure the signal height is maximized as for screen height use without over-shooting, then enable FFT so look at the frequency components. Set FFT to cover the band from 1kHz (or zero) to 130MHz and then read out the individual peaks.
At this point you not only know which rail has the noise problem, you also know that the other rails are fine and for the failing rail you even know the noise frequency (which can help you find out where it comes from, if you, again, use a methodological approach).
No matter where you start, you always need to make sure first that you understand what you are testing before you can even think about making a determination if certain behavior is normal or a fault.
Learn to test, test to learn! :)
Testing properly means working methodologically, you have to spend some time thinking about what you have, what you want to achieve, what you ideally expect, what problems/issues you may encounter and how to address them, and then develop a test strategy which will give you the desired data in a reasonable amount of time and with reasonable effort. And then you go and execute your strategy. And if your strategy was sensible you get the data you need. If not, you re-strategize and execute again. Simples.
Sure, but that could describe playing chess or any other difficult activity... in other words, the description is not enough information to actually play the game well!
It is. Again, think about what you know, not what you don't know. A methodological approach gives you a way to get the missing, relevant data in shortest time and with the least amount of effort.
And yes, that same principle may well hold true for other unrelated activities. Chess, after all, is a game of strategy ;)
-
[...]
It looks like the new Keysight MXR has learned this trick as well:
- Standard history mode and segmented memory
Use the history mode to view previous trigger events over 1,024 acquired waveforms. The segmented memory enables the oscilloscope to capture over 5,000 future waveforms for analysis.
Source: https://www.keysight.com/gb/en/cmp/2020/introducing-the-world-s-first-8-channel-rtsa-oscilloscope.html (https://www.keysight.com/gb/en/cmp/2020/introducing-the-world-s-first-8-channel-rtsa-oscilloscope.html)
That is one tasty scope... 8 channels @ 6GHz would have been science fiction specs not that long ago!
-
[...]
It looks like the new Keysight MXR has learned this trick as well:
- Standard history mode and segmented memory
Use the history mode to view previous trigger events over 1,024 acquired waveforms. The segmented memory enables the oscilloscope to capture over 5,000 future waveforms for analysis.
Source: https://www.keysight.com/gb/en/cmp/2020/introducing-the-world-s-first-8-channel-rtsa-oscilloscope.html (https://www.keysight.com/gb/en/cmp/2020/introducing-the-world-s-first-8-channel-rtsa-oscilloscope.html)
That is one tasty scope...
Yes, very interesting. Apparently we already got one of the early MXR units but to SARS-CoV-2 it's out of reach for now :(
8 channels @ 6GHz would have been science fiction specs not that long ago!
Not within the last 6 years ;)
How about 80 channels @ 36Ghz, or 20 channels @ 100GHz? >:D
http://cdn.teledynelecroy.com/files/pdf/labmaster-10zi-a-datasheet.pdf (http://cdn.teledynelecroy.com/files/pdf/labmaster-10zi-a-datasheet.pdf)
-
[...]
How about 80 channels @ 36Ghz, or 20 channels @ 100GHz? >:D
http://cdn.teledynelecroy.com/files/pdf/labmaster-10zi-a-datasheet.pdf (http://cdn.teledynelecroy.com/files/pdf/labmaster-10zi-a-datasheet.pdf)
Looks like it might be adequate for working with an Arduino, or something! :D
-
[...]
Testing doesn't mean just poking something with an instrument to see what's coming out.
Well, most of the time that statement is accurate... but it seems very cut and dried unless you are in a controlled environment. Say you are repairing an unfamiliar and undocumented piece of equipment, you have absolutely no idea what is causing some obscure fault - so you are looking for clues. You might be following the "golden rule" of checking the supply voltages first, for example. So you might look for excessive noise on the lines. But at what frequency? Depends on the circuitry sipping the juice as much as the PSU, right? Could be 60Hz, 120Hz, or several megahertz. Taking a look around using different timebases suddenly seems more like a prudent strategy of elimination rather than random probing?
It really doesn't matter if you're dealing with a familiar device or something new, really. Because there is always some basic information you will have. You may not be familiar with the UUT but you still must have some idea what it does, because if not then you wouldn't be able to determine what is faulty behavior and what not in the first place.
You always start from what you know, not from what you don't know. And the more you don't know about the UUT the more critical becomes proper preparation before you start probing.
In your noise example you wouldn't jump in with a scope. You'd first visually examine the device, check for visible damage, determine what kind of PSU it uses, how it seems to work and what voltages you expect to see where (which also are your first test points). You then might want to draw this out on a piece of paper and mark the points to test (and what voltage you'd expect at each point).
Right now you have already increased your knowledge about the UUT without even doing any measurements! But it's probably also as far as you can get visually with the amount of information you have, so to learn even more you need to start to gather additional data.
The first set of measurements should establish what the actual voltages are at the points you identified and if they are stable. Because knowing the voltages will help you to establish if your basic assumptions above about the PSU are correct. And the best tool to measure voltages isn't a scope, it's a DMM. Depending on the capabilities of your DMM you might also want to measure the AC component (low frequency noise, usually somewhere up to 1kHz) of DC voltages.
So you power up the device, measure the voltages and (for DC voltages also the AC components) at the test points and note them down in your drawing.
Then you go back to your paper which now has the new data, look at the test points and the expected and the measured voltages (and the measured AC component). If there are differences then you start examining the ciruitry which feeds the rail which shows the difference, deduct some schematics and calculate what the correct voltage and tolerable AC component would be. Maybe you determine you need additional data (i.e. the voltages over specific components), so add the additional test points to your drawing and perform another set of measurements which gives you even more data. Then you go back to your drawing to evaluate the data and find out if the results are as expected or not.
If so far everything has worked out then the point comes where you look at noise, and for that the scope is probably the best tool. But agin, you shouldn't just jump in, twiddling knobs until something appears on the screen. You spend some time thinking about what information you want (here: amplitude and frequency of noise if there's any) and what can you get, based on the limitations of your test equipment.
Let's for the moment assume all you have is a DS1054z, i.e. a basic scope with no power analysis or other advanced stuff, plus some passive x10 probes (say 250MHz). In single channel mode you get 1GSa/s and an analog BW of (hacked) around 130MHz. Therefore any noise you can find with your scope will be within a range of ]0Hz;130MHz]. Also, the noise amplitude needs to exceed the scope's + probe's internal noise, as otherwise it would get hidden in your test equipment's noise floor. So let's say (let's assume for the moment the DS1054z noise floor is at 800uV, or 8mV with an x10 probe). So clearly, you're not capturing very low noise levels (which still might shift the power rail outside spec) or noise components of more of approx 130MHz.
The DMM measurments already covered AC ripple up to 1kHz (if not then you'd want measurements specific for that). Which means the noise frequency you want to look at would be [1kHz;130MHz]. 1kHz means a period is 1ms long, and ideally you want to capture at least three of them. A DS1054z with 24Mpts will be able to capture 10 periods (10ms) at full 1GSa/s sample rate (using 10Mpts memory), so the scope should be set to a timebase of 1ms/div. Set trigger mode to AUTO, trigger level to say 10mV, enable Vpp and Vrms measurements, then start to probe. Connect to the test point and turn up the vertical div setting to increase the signal to cover as much screen space as possible without extruding from it. Enable zoom and zoom in to check various sizes of a signal segment for any visible AC content. In your example, lets assume that most PSU rails are OK but there is one with lots of noise. So you make sure the signal height is maximized as for screen height use without over-shooting, then enable FFT so look at the frequency components. Set FFT to cover the band from 1kHz (or zero) to 130MHz and then read out the individual peaks.
At this point you not only know which rail has the noise problem, you also know that the other rails are fine and for the failing rail you even know the noise frequency (which can help you find out where it comes from, if you, again, use a methodological approach).
No matter where you start, you always need to make sure first that you understand what you are testing before you can even think about making a determination if certain behavior is normal or a fault.
Learn to test, test to learn! :)
Testing properly means working methodologically, you have to spend some time thinking about what you have, what you want to achieve, what you ideally expect, what problems/issues you may encounter and how to address them, and then develop a test strategy which will give you the desired data in a reasonable amount of time and with reasonable effort. And then you go and execute your strategy. And if your strategy was sensible you get the data you need. If not, you re-strategize and execute again. Simples.
Sure, but that could describe playing chess or any other difficult activity... in other words, the description is not enough information to actually play the game well!
It is. Again, think about what you know, not what you don't know. A methodological approach gives you a way to get the missing, relevant data in shortest time and with the least amount of effort.
And yes, that same principle may well hold true for other unrelated activities. Chess, after all, is a game of strategy ;)
I think that sounds a perfectly valid strategy and I do appreciate the logic. The strategies and "hunches" used to fault find could fill entire bookshelves.
But - is it downright wrong to just use the scope for the whole thing in this example? - after all, most digital scopes will give you the DC voltage, peak to peak & RMS noise, as well as a visual indication of any noise, and more, just by touching the probe to a rail once and doing a single shot (which you then zoom in/out, naturally, to get the full overview). In many repair situations, the boss will want FAST results... and a digital scope is surely one of the fastest and best tools ever for inspecting the overall behaviour or electronic circuits, even at the initial stages?
One of the huge advantages of multi-channel scopes is revealing connected behaviours between different parts of the circuit that would be difficult to see with a DMM or even a single channel scope. So for example, by scoping 2 rails and an output simultaneously you might see events that are connected between them, possibly giving you vital clues that you wouldn't otherwise have got?
-
(...)
One of the huge advantages of multi-channel scopes is revealing connected behaviours between different parts of the circuit that would be difficult to see with a DMM or even a single channel scope. So for example, by scoping 2 rails and an output simultaneously you might see events that are connected between them, possibly giving you vital clues that you wouldn't otherwise have got?
I don't know about you, but in the occasions I have to troubleshoot something, I rarely bring the 'scope in the first place - a meter tends to be more versatile and needs much less fiddling to get a reading - move the cursor to "V=" or "V~" or whatever and off you go.
Sure, having a meter with a wide bandwidth, decent AC decoupling and other specialties goes much further than a cheapie, especially when you suspect there is excessive ripple of some sorts over DC or need to do differential probing around on the circuit (where the 'scope GND can ruin your day easily). Getting some long and thin probe tips and some SMT or J grabbers are a great help (Keysight U1164A (https://www.keysight.com/en/pd-1191781-pn-U1164A/fine-tip-test-probes?nid=-31908.714199&cc=US&lc=eng) or Keysight U1163A (https://www.keysight.com/en/pd-1191778-pn-U1163A/smt-grabbers?nid=-31908.714197&cc=US&lc=eng)). With oscilloscope probes, finding a good ground place on the equipment under inspection sometimes is quite annoying, and depending on the distance between the GND and the measurement point you will see a lot of noise that may confuse at a first glance.
Anyways, that is my experience.
-
(...)
One of the huge advantages of multi-channel scopes is revealing connected behaviours between different parts of the circuit that would be difficult to see with a DMM or even a single channel scope. So for example, by scoping 2 rails and an output simultaneously you might see events that are connected between them, possibly giving you vital clues that you wouldn't otherwise have got?
I don't know about you, but in the occasions I have to troubleshoot something, I rarely bring the 'scope in the first place - a meter tends to be more versatile and needs much less fiddling to get a reading - move the cursor to "V=" or "V~" or whatever and off you go.
Sure, having a meter with a wide bandwidth, decent AC decoupling and other specialties goes much further than a cheapie, especially when you suspect there is excessive ripple of some sorts over DC or need to do differential probing around on the circuit (where the 'scope GND can ruin your day easily). Getting some long and thin probe tips and some SMT or J grabbers are a great help (Keysight U1164A (https://www.keysight.com/en/pd-1191781-pn-U1164A/fine-tip-test-probes?nid=-31908.714199&cc=US&lc=eng) or Keysight U1163A (https://www.keysight.com/en/pd-1191778-pn-U1163A/smt-grabbers?nid=-31908.714197&cc=US&lc=eng)). With oscilloscope probes, finding a good ground place on the equipment under inspection sometimes is quite annoying, and depending on the distance between the GND and the measurement point you will see a lot of noise that may confuse at a first glance.
Anyways, that is my experience.
My favourite "trick" for using the scope as a DMM is to set up a really slow "chart roll" mode (e.g. a minute for a screen full), then start probing - each measurement becomes a "pulse" on the chart. That way, you get a slowly moving history of the points you probed, which you can look closer at if necessary. You can probe dozens of points on a PCB and contrast and compare. Any problem areas stick out like a sore thumb.
-
Video coming out tomorrow:
https://www.youtube.com/watch?v=bVxDibdosdI (https://www.youtube.com/watch?v=bVxDibdosdI)
-
How about of we all try to summarize our positions and then we can all get back to doing important stuff like playing Candy Crush?
See my latest video.
- It could be handy in certain circumstances, but most of the time not needed.
- Certainly wouldn't base a buying decision on it (Siglent + Lecroy seems to to be the only ones without it)
- In several scopes you can enable or disable it by selecting manual memory length.
- In some scopes it's a trade off vs update rate.
-
How about of we all try to summarize our positions and then we can all get back to doing important stuff like playing Candy Crush?
See my latest video.
- It could be handy in certain circumstances, but most of the time not needed.
- Certainly wouldn't base a buying decision on it (Siglent + Lecroy seems to to be the only ones without it)
- In several scopes you can enable or disable it by selecting manual memory length.
- In some scopes it's a trade off vs update rate.
We look forward to your followup video Dave when you discover the capabilities of 2 obscure buttons on the Siglent front panel. ;) :popcorn:
-
Video coming out tomorrow:
https://www.youtube.com/watch?v=vHAsjblSmBQ (https://www.youtube.com/watch?v=vHAsjblSmBQ)
Someone is going to do something naughty in front of this video ;D
To be more serious, it is a very nice video, I don't know if the video comparing FFT is more popular than others but I love videos that allow you to compare a bunch of oscilloscopes on the same situations.
It is very useful to see how the user interface works compared to another or how this scope dehaves compared to another in general.
:-+
-
Thanks for the video Dave, it captures (no pun intended) the essence of what we've been discussing in this thread.
Next challenge is the associated decode problem that came up in this thread.
Say you've captured a load of data and can zoom out, slide sideways, and zoom back in; you can see the waveform but the decode of the data (this is the gripe) for an RS232 stream can look like garbage. Why? The answer seems to be that the decode is performed on what's on the screen so, unless the decode starts at a valid data block beginning, the entire rest of the decoded data can show as junk - at least it is on my Rigol MSO5074 - even though it's clear that there's good data in the capture. Given the trigger would have been somewhere in the center of the capture, zooming out/scrolling sideways puts us into a situation where we can't control where the data capture starts and the decode algorithms aren't smart enough to search and find the beginning of a valid data block.
Any ideas?
-
Unfortunately the only way out is to use zoom mode on Rigol.
-
Excellent video, Dave. Thanks for doing this. I only missed doing the exercise of differentiating the buffer size between the Run/Stop and the Single modes on the Tek, just like it was done on the Keysight.
Another interesting detail I haven't noticed is how annoying are the knobs on the Siglent: all have almost the same size. I suspect that would confuse the heck out of me.
We look forward to your followup video Dave when you discover the capabilities of 2 obscure buttons on the Siglent front panel. ;) :popcorn:
Tautech, why not show the steps to achieve this without cheekiness? Remember that people that come across this thread may be trying to make a purchase decision - since they will not have a Siglent in front of them to explore the mysterious buttons, they will go elsewhere.
-
Thanks for the video Dave, it captures (no pun intended) the essence of what we've been discussing in this thread.
Next challenge is the associated decode problem that came up in this thread.
Say you've captured a load of data and can zoom out, slide sideways, and zoom back in; you can see the waveform but the decode of the data (this is the gripe) for an RS232 stream can look like garbage. Why? The answer seems to be that the decode is performed on what's on the screen so, unless the decode starts at a valid data block beginning, the entire rest of the decoded data can show as junk - at least it is on my Rigol MSO5074 - even though it's clear that there's good data in the capture. Given the trigger would have been somewhere in the center of the capture, zooming out/scrolling sideways puts us into a situation where we can't control where the data capture starts and the decode algorithms aren't smart enough to search and find the beginning of a valid data block.
Any ideas?
Hummm Im pretty sure I have no problem on my MSO7000 so it is maybe a bug to address ?
I can zoom out and all the data now on screen are decoded in the event table.
If I zoom into a packet that was out the screen previously, the serial decode works with no problem.
-
Video was just updated. Shortened by a few minutes (just tighter editing), couple of overlay texts added.
-
Another interesting detail I haven't noticed is how annoying are the knobs on the Siglent: all have almost the same size. I suspect that would confuse the heck out of me.
I find that really annoying!
-
We look forward to your followup video Dave when you discover the capabilities of 2 obscure buttons on the Siglent front panel. ;) :popcorn:
If you have something to share that I missed then you'd better tell me right now, because I leave home in 30 minutes and the video gets auto published tomorrow while I'm sleeping.
If you are referring to Zoom mode, then nope, makes no difference in this instance.
-
We look forward to your followup video Dave when you discover the capabilities of 2 obscure buttons on the Siglent front panel. ;) :popcorn:
If you have something to share that I missed then you'd better tell me right now, because I leave home in 30 minutes and the video gets auto published tomorrow while I'm sleeping.
I think he is talking about zoom mode but it is a feature that all modern scopes have and there are downsides.
-
As to "zooming out", most scopes don't allow zooming outside the scope area.
Actually, most scopes do, see my video. On some you have to set manual memory size though. Keysight, Tek, Rigol, Uni-T, Owon, R&S, GW Instek all do it.
-
We look forward to your followup video Dave when you discover the capabilities of 2 obscure buttons on the Siglent front panel. ;) :popcorn:
If you have something to share that I missed then you'd better tell me right now, because I leave home in 30 minutes and the video gets auto published tomorrow while I'm sleeping.
I think he is talking about zoom mode but it is a feature that all modern scopes have and there are downsides.
Nope, doesn't work. As per my video, at 5us time base the Siglent in zoom mode only captures 100k points in 200M mmeory size mode and does not zoom out.
-
Another interesting detail I haven't noticed is how annoying are the knobs on the Siglent: all have almost the same size. I suspect that would confuse the heck out of me.
I find that really annoying!
Then paint them or add heatshrink to them until muscle memory develops.
They're nothing new and first seen on the SDS2000X models, then 5000X and now 2kX Plus.
We look forward to your followup video Dave when you discover the capabilities of 2 obscure buttons on the Siglent front panel. ;) :popcorn:
If you have something to share that I missed then you'd better tell me right now, because I leave home in 30 minutes and the video gets auto published tomorrow while I'm sleeping.
If you are referring to Zoom mode, then nope, makes no difference in this instance.
Publish it Dave as there is further discussion required as to why an operator cannot adapt to suit the tools at their disposal right at their fingertips.
Many could learn how easy it is to access the continually refreshed History buffer where the entire DSO's memory is available to inspect just as easily as using a timebase control without the obvious limitations your investigations revealed.
Dave MathCAD should do some work on History. :popcorn:
-
Publish it Dave as there is further discussion required as to why an operator cannot adapt to suit the tools at their disposal right at their fingertips.
There is no sense in doing that. You are trying to argue that a front-wheel drive car is suitable for driving on muddy dirt roads and it is the driver's fault when a car gets stuck. :palm: Sometimes the wrong tool simply is the wrong tool. Just go tell Siglent to turn their scopes into 4 wheel drive models; that would be actually useful. Suggesting history mode just goes to show that you really have no idea on what the actual use case is!
-
If you have something to share that I missed then you'd better tell me right now, because I leave home in 30 minutes and the video gets auto published tomorrow while I'm sleeping.
If you are referring to Zoom mode, then nope, makes no difference in this instance.
Publish it Dave as there is further discussion required as to why an operator cannot adapt to suit the tools at their disposal right at their fingertips.
Many could learn how easy it is to access the continually refreshed History buffer where the entire DSO's memory is available to inspect just as easily as using a timebase control without the obvious limitations your investigations revealed.
Dave MathCAD should do some work on History. :popcorn:
Err, history mode does NOT show you the data outside the display window, which is the entire point of this whole thing.
The Siglent might have continuous history mode, but it's limited to the screen and the 100k points at 5us/div.
And that continuous mode doesn't work in single shot mode anyway.
Your argument has absolutely nothing to do with this discussion.
-
Not to mention history isn't unique to Siglent. Not zooming out almost IS unique to Siglent.
-
I can confirm my Tek DSA602A will not zoom out. In case anyone was wondering. We will see if Tektronix puts out a firmware update. Fingers crossed. LOL
-
The question is "what does the scope do by default when it has extra memory beyond what's used by the configured acquisition." The three answers I've seen are "waste it," "extend the acquisition," and "hold on to past acquisitions." Wasting it is dumb, extending the acquisition is nice, but history is my favorite:
(https://thumbs.gfycat.com/ElderlyAltruisticBird.webp)
Maybe if I were doing a lot of serial decoding and running into partial packets my preference would flip. History (aka configured-by-default segmented memory) is still pretty nice for serial though. Of course, in both cases, it's just a default, and you can still configure the other behavior if you want. Personally I think widening the acquisition and activating a zoom window is slightly easier than configuring segmented memory, but only slightly.
-
https://www.youtube.com/watch?v=wLcdZjFuho0 (https://www.youtube.com/watch?v=wLcdZjFuho0)
-
I'd say the R&S has the best of both. Manual or auto mem depth and automatic history mode(it IS an option though). Although perhaps you'd say they're wasting memory as well which I'd agree with but luckily for me it's never been a limitation.
I noticed in the comments you said the segments wouldn't be time correlated(if sliding through time they'd show other segments), I THINK if you use list mode in history it'll tell where in time in relation to the final segment each segment was. The R&S do that.
-
I'd say the R&S has the best of both. Manual or auto mem depth and automatic history mode(it IS an option though). Although perhaps you'd say they're wasting memory as well which I'd agree with but luckily for me it's never been a limitation.
No I wouldn't say that if you can switch it off, it's done in auto mode.
But if you select a memory depth you should damn well get that memory depth.
-
Yea, that is a real difference. You get what you ask for. It's really odd setting a limit(and so few options too) for memory. May as well remove that entirely.
Just to clarify the history mode is a PAID option. You get whatever mem depth you ask for and however many segments(to a limit) it takes to fill available sample memory.
-
Yea, that is a real difference. You get what you ask for. It's really odd setting a limit(and so few options too) for memory. May as well remove that entirely.
Yes, on the Siglent you literally change the memory depth on the menu and the memory depth shown in the bottom sample window doesn't change. It's insane.
-
Just to clarify the history mode is a PAID option. You get whatever mem depth you ask for and however many segments(to a limit) it takes to fill available sample memory.
Not on the 2000X PLus it's not, no such option in the options screen.
https://int.siglent.com/products-ware/sds2000xp/
-
Just to clarify the history mode is a PAID option. You get whatever mem depth you ask for and however many segments(to a limit) it takes to fill available sample memory.
Not on the 2000X PLus it's not, no such option in the options screen.
Right, I'm talking about the RTB, RTM, RTA it's a paid option. I think it's standard on the 2kx+ but it'd better be since that kind of memory isn't as useful when you only actually get a small fraction of what's available during normal usage. Unless normally you need that kind of memory depth(100ms/div).
-
Tek DPO7k series don't zoom out, as the sample rate is locked together with sample depth, cannot set one without changing other :)
-
Right, I'm talking about the RTB, RTM, RTA it's a paid option.
Yuck. It's standard on the RTE, RTO, and RTP, though, and those models also have a third timebase knob to control memory depth. I really love that third knob, it makes it super convenient to trade off vertical resolution / sample rate and time / RBW for FFTs.
-
Yea, that is a real difference. You get what you ask for. It's really odd setting a limit(and so few options too) for memory. May as well remove that entirely.
Yes, on the Siglent you literally change the memory depth on the menu and the memory depth shown in the bottom sample window doesn't change. It's insane.
Dave.. your latest video just made me realize something..
It CAN zoomout! It's just not how you would think to do it...
To set it up, first set a timebase that will let you use the full 200M
UNDER the horizontal key press Zoom
THEN Zoom in to the actual display/timebase you want, you can zoom in just as a normal timebase change AND keep 200 Megapoints
when the event triggers you are interested in, just be on the bottom area and do the normal horizontal adjustment out OR use the top portion to drag it to one side or the other to the area you are interested in
The bottom area is the entire normal page but has been scaled down... i think this is why they make the menu bars also cause scaling of the main screen pixels
Try it out... and post another video :P
-
Right, I'm talking about the RTB, RTM, RTA it's a paid option.
Yuck. It's standard on the RTE, RTO, and RTP.
Doesn't bother me, I didn't pay for it anyway. I know you got yours for cheap but if you'd paid anywhere near msrp... You'd maybe not think it's so bad.
-
And a screenshot so it doesnt look like im a nutter lol
-
Right, I'm talking about the RTB, RTM, RTA it's a paid option.
Yuck. It's standard on the RTE, RTO, and RTP.
Doesn't bother me, I didn't pay for it anyway. I know you got yours for cheap but if you'd paid anywhere near msrp... You'd maybe not think it's so bad.
Very true.
-
Dave.. your latest video just made me realize something..
It CAN zoomout! It's just not how you would think to do it...
To set it up, first set a timebase that will let you use the full 200M
UNDER the horizontal key press Zoom
THEN Zoom in to the actual display/timebase you want, you can zoom in just as a normal timebase change AND keep 200 Megapoints
when the event triggers you are interested in, just be on the bottom area and do the normal horizontal adjustment out OR use the top portion to drag it to one side or the other to the area you are interested in
The bottom area is the entire normal page but has been scaled down... i think this is why they make the menu bars also cause scaling of the main screen pixels
Try it out... and post another video :P
Err, that's no different to just using a longer time base and pressing STOP or SINGLE, and then zooming in.
Using the dual screen zoom function whilst you do this makes no real difference.
This is NOT normal scope behavior and is not what is being discussed here.
The entire point of this is that you don't know you need the longer timebase until you do, so you couldn't have set it up like that to begin with.
Fact is on the Siglent the memory is not being set to the depth your specify, this is in inexcusable.
-
No its trigger mode and auto as well
-
Dave.. your latest video just made me realize something..
It CAN zoomout! It's just not how you would think to do it...
To set it up, first set a timebase that will let you use the full 200M
UNDER the horizontal key press Zoom
THEN Zoom in to the actual display/timebase you want, you can zoom in just as a normal timebase change AND keep 200 Megapoints
when the event triggers you are interested in, just be on the bottom area and do the normal horizontal adjustment out OR use the top portion to drag it to one side or the other to the area you are interested in
The bottom area is the entire normal page but has been scaled down... i think this is why they make the menu bars also cause scaling of the main screen pixels
Try it out... and post another video :P
Err, that's no different to just using a longer time base and pressing STOP or SINGLE, and then zooming in.
Using the dual screen zoom function whilst you do this makes no real difference.
This is NOT normal scope behavior and is not what is being discussed here.
The entire point of this is that you don't know you need the longer timebase until you do, so you couldn't have set it up like that to begin with.
Fact is on the Siglent the memory is not being set to the depth your specify, this is in inexcusable.
No its classic chinese out of the box thinking... you leave it like that in the first place and set your zoom in to where you want it.. works fine in all modes, stop, single, trigger, auto
-
One other bit.. the refresh rate is a bit slow.. its not a killer for sure but it gets the job done
Those screenshots are the equivalent of 200 megapoints but on 500us trigger and a view finder on top.. granted the way you go about it is ass backwards but it still is functionally equivalent
-
granted the way you go about it is ass backwards but it still is functionally equivalent
It's so arse backward no one is going to use it for regular use. Again, you are missing the entire point of this.
-
History (aka configured-by-default segmented memory) is still pretty nice for serial though.
Not really segmented mode but something like that (i've seen other scopes become completely unresponsive, minus the stop button, in order to maximise the sample rate.. somewhere else also called sequence)
But yeah, history mode is the best mode :)
-
Also the way LeCroy has always operated and the way Picoscopes have always operated.
Why do i have to keep telling people this?
That doesn't make it right.
Here is the thing. If you want to look at a short timebase signal then you'll set a short timebase, that's normal oscilloscope usage.
Even on a Siglent, Lecroy or Picoscope, you aren't going to go through to convoluted process of setting a slow timebase and then chosing the zoom mode and then setting the secondary timebase just for regular use.
The point is that when using the scope the normal way, you can't zoom out if you need to.
-
A few years back I struggled to understand why scopes don't allow this full use of sample memory, as trigger processing should not affect it (effectively wasting the memory). Slower update rate might be a point, but if you consider that the use of more channels will limit the amount of data before and after triggering greatly because the memory organization will be affected, the usefulness of zooming out would vary a lot for each timebase - or cripple the sample memory per channel.
Therefore I rather like the segmented memory approach.
-
A few years back I struggled to understand why scopes don't allow this full use of sample memory, as trigger processing should not affect it (effectively wasting the memory). Slower update rate might be a point, but if you consider that the use of more channels will limit the amount of data before and after triggering greatly because the memory organization will be affected, the usefulness of zooming out would vary a lot for each timebase - or cripple the sample memory per channel.
It doesn't matter at all. Sampling memory is per channel anyway and the memory is used as a circular buffer. There are no downsides.
-
The question is "what does the scope do by default when it has extra memory beyond what's used by the configured acquisition." The three answers I've seen are "waste it," "extend the acquisition," and "hold on to past acquisitions." Wasting it is dumb, extending the acquisition is nice, but history is my favorite:
Maybe if I were doing a lot of serial decoding and running into partial packets my preference would flip.
The latter is the point: it greatly depends on the use case. Depending on what you are doing history mode (aka circular segmented recording) can be a huge waste as well because the memory can be put to better use as 1 long record for a measurement. In the grand scheme of things I have need for all modes (history, long memory, short memory, segmented recording) so when I buy an oscilloscope I make sure it can do all.
-
The latter is the point: it greatly depends on the use case. Depending on what you are doing history mode (aka circular segmented recording) can be a huge waste as well because the memory can be put to better use as 1 long record for a measurement. In the grand scheme of things I have need for all modes (history, long memory, short memory, segmented recording) so when I buy an oscilloscope I make sure it can do all.
And that's the thing. For a scope not to offer the full memory for a single capture even when deliberately selected (without using a convoluted dual timebase system) is just silly.
The user needs to be able to chose how that memory is used, and Siglent/Lecroy/Picoscope are seemingly the only ones crippled in this regard.
-
A question for anyone with a scope that has the 'history' mode:
Does changing the settings between triggers, e.g. changing vertical or horizontal scale, or enabling an additional channel, clear the history buffer? If not, do such changes get reflected in the on-screen display of the settings, when reviewing history?
-
No its classic chinese out of the box thinking... you leave it like that in the first place and set your zoom in to where you want it.. works fine in all modes, stop, single, trigger, auto
If Rigol, Owon and Uni-T did the same, I would agree with you there, but to me it looks like a classic second Tier brand copying thinking. I suspect LeCroy did that originally and Siglent followed suit.
(of course, you can always argue that the opposite is true as well: the other brands copied the top tiers Tek or HPAK)
And that's the thing. For a scope not to offer the full memory for a single capture even when deliberately selected (without using a convoluted dual timebase system) is just silly.
The user needs to be able to chose how that memory is used, and Siglent/Lecroy/Picoscope are seemingly the only ones crippled in this regard.
I think that is exactly the crux of the matter. Since the manual memory depth setting is not translated to the capture itself, why have it in the first place? It seems a waste of memory when the user deliberately told the scope to use it.
BTW, the choice of doing the "Zoom In" approach does not immediately mean there is something wrong with it - after all, it is a design choice.
A question for anyone with a scope that has the 'history' mode:
Does changing the settings between triggers, e.g. changing vertical or horizontal scale, or enabling an additional channel, clear the history buffer? If not, do such changes get reflected in the on-screen display of the settings, when reviewing history?
If I understood it correctly, you mean in Run mode, right? If so, the buffer is discarded when enabling channels on the Rigol DS4014 and I would expect so, given the memory is split between pairs of channels.
In stop mode you can change the vertical and horizontal settings without a problem.
-
A question for anyone with a scope that has the 'history' mode:
Does changing the settings between triggers, e.g. changing vertical or horizontal scale, or enabling an additional channel, clear the history buffer? If not, do such changes get reflected in the on-screen display of the settings, when reviewing history?
If I understood it correctly, you mean in Run mode, right? If so, the buffer is discarded when enabling channels on the Rigol DS4014 and I would expect so, given the memory is split between pairs of channels.
In stop mode you can change the vertical and horizontal settings without a problem.
Presumably you have to be in Stop mode anyway to look at the history?
-
I think they had already developed the whole architecture when they decided to put a history button... :-DD
"Uhmm, what about putting a history button in this free space over here?"
Why if it's always in history mode? ? :palm: :palm:
Siglent's 200 Mpts: "We have plenty of storage space in this server. But it's all tapes..."
-
Also the way LeCroy has always operated and the way Picoscopes have always operated.
Why do i have to keep telling people this?
That doesn't make it right.
Here is the thing. If you want to look at a short timebase signal then you'll set a short timebase, that's normal oscilloscope usage.
Even on a Siglent, Lecroy or Picoscope, you aren't going to go through to convoluted process of setting a slow timebase and then chosing the zoom mode and then setting the secondary timebase just for regular use.
The point is that when using the scope the normal way, you can't zoom out if you need to.
I removed the message because i though about it twice and didn't want to have this argument again.
There is nothing wrong in one or the other. Both have edge cases. End of story.
It doesn't make it wrong either.
It doesn't make it some weird ass chinese blah blah (not sure if i have understood that post correctly though)
Granted i've been using scope for just 10 years and had the chance to use everything available with reasonable price, but i like the lecroy way better, about many things. Don't care about zoomout because i can always reproduce the shot (don't care about other what if i had zoom out bullshit, i can guarantee you that at some point you would have wanted more memory so the acquisition is useless) instead i care more about automatic history mode with LOTS of acquisitions
-
A question for anyone with a scope that has the 'history' mode:
Does changing the settings between triggers, e.g. changing vertical or horizontal scale, or enabling an additional channel, clear the history buffer? If not, do such changes get reflected in the on-screen display of the settings, when reviewing history?
Usually, yes. (Picoscope, Lecroy and siglent that i've used) It can be a pain but you get used to it. I think it depends on how the scope performs operations on the data (assumes current v/div for calculation, memory per channel and so on)
-
To me convoluted process is to set memory depth, mentally calculating what timescale it will be at target sample rate, mentally calculate how much of that I have to set as pretrigger to make sure I have enough pre trigger capture once I'm at the target timebase. Then I set target timebase, tightly set around trigger and then keep capturing until I find something interesting, and then, without any sense where exactly in the whole buffer I am i keep twiddling around with timebase looking at data searching for something interesting.
Problem is that Dave misunderstood (or ignored) original reason why Nico is such a proponent of this.
Nico uses it for slow, long samples, where he looks at long bursts of data on ,say, CAN bus. He keeps looking at one packet or event, and when that even happens he wants to know what happened around it. He doesn't stop captures, but works in RUN/Normal triggering mode (not Auto), from trigger to trigger event, and he initiates data transfers from equipment manually, or has them set up to occur slow enough that he has time to manually stop scope if needed.
It is very deliberate, he doesn't mind that scope needs 1 second per capture to process, and it IS NOT interactive scope work. You cannot have interactive scope work with 2 triggers per second.
As I already documented, Keysight scope DOESN'T work like that (Nico uses his R&S RTM3000 for this) in RUN mode. In RUN mode in between triggers, it has only screenfull of data available. Only after you STOP, it will gather all buffers and reassemble them. And if you are lucky that you are working in less 5 us/div, you will have data up to 20 us/div. If you are at 20 us/div and up (50us/div in single mode), there is NO data outside...
I had DS1074Z. I pretty much never used fixed memory length. I used AUTO mode pretty much exclusively. Setting scope to capture too long capture on every trigger makes scope slow. Every one. One of the reasons Tektronix get their bad reputation is manual memory settings. People put them to 20MS and then complaint how it non responsive.
Suddenly that is a good thing. It is not. That being said I DID USE IT from time to time. For instance to look at gated PSU startup. Set it for MAX mem, set timebase for switch on event, look at it and then if there was something wrong, pull out to see what was happening around it. But with Picoscope's excellent zoom implementation, it behaves exactly the same the other way around.
Siglent 2000X+ seems to work exactly as Picoscope. And it is not "badly implemented manual memory length", but a "auto memory management with maximum length" setting. It is there to control strategy to balance huge memory with how will sampling rate drop off as you go to slower timebases. Siglent should have better explained and/or named this option. Siglent doesn't have "fixed manual memory size"
Also, if it is possible, they should think of implementing Keysight like feature in user configurable option, that they give up history mode and do single shot captures in full length as set. That would make them almost exactly same as Keysight (same at slow timebases). They might even do "full Keysight" and set minimum sampled length. Whatever.
That being said, if customers think this is necessary, manufacturers should try to address it.
-
To me convoluted process is to set memory depth, mentally calculating what timescale it will be at target sample rate, mentally calculate how much of that I have to set as pretrigger to make sure I have enough pre trigger capture once I'm at the target timebase. Then I set target timebase, tightly set around trigger and then keep capturing until I find something interesting, and then, without any sense where exactly in the whole buffer I am i keep twiddling around with timebase looking at data searching for something interesting.
That is not how it works! If you don't get it then you don't get it but by riduculing other people's workflow you only make a fool out of yourself.
-
To me convoluted process is to set memory depth, mentally calculating what timescale it will be at target sample rate, mentally calculate how much of that I have to set as pretrigger to make sure I have enough pre trigger capture once I'm at the target timebase. Then I set target timebase, tightly set around trigger and then keep capturing until I find something interesting, and then, without any sense where exactly in the whole buffer I am i keep twiddling around with timebase looking at data searching for something interesting.
That is not how it works! If you don't get it then you don't get it but by riduculing other people's workflow you only make a fool out of yourself.
It is exactly how it works. Unlike you, I like to have a guarantee I will capture something before I start doing it. You are doing this not because it is smart thing to do it, but because it is the lazy way, and you hate zoom mode. So you do it this way. If it works for you , that's nice.
I do it in opposite direction and get same results and find that much easier.
But both you, and now Dave apparently, try to sell this as some panacea, and will do that without any negative impact. Which is not true. It has consequences.
In my mind it is not that Siglent manages memory wrong way, but that zoom mode should be implemented to be more user friendly. I LIKE how zoom mode has DETERMINISTIC dual time bases. They should shuffle windows differently and make them more configurable, but it is a display and user interface problem, not capture problem. This is exactly what R&S and Keysight does: it sets timebase (internaly) for long capture, and then shows you only part of captured waveform. It is just U/I that shows you part of waveform, using basically "virtual timebase".
And I get it. I read what you wrote on this topic before.
By the by, it is you who is proponent of idea that whoever is not agreeing with you is stupid. And this is not first topic you had that condescending tone..
As I said before, you are wonderful engineer with waste experience. I respect that. And I agreed and disagreed with you on many topics. And I will keep doing that at my own conscience.
-
To me convoluted process is to set memory depth, mentally calculating what timescale it will be at target sample rate, mentally calculate how much of that I have to set as pretrigger to make sure I have enough pre trigger capture once I'm at the target timebase. Then I set target timebase, tightly set around trigger and then keep capturing until I find something interesting, and then, without any sense where exactly in the whole buffer I am i keep twiddling around with timebase looking at data searching for something interesting.
That is not how it works! If you don't get it then you don't get it but by riduculing other people's workflow you only make a fool out of yourself.
It is exactly how it works. Unlike you, I like to have a guarantee I will capture something before I start doing it. You are doing this not because it is smart thing to do it, but because it is the lazy way, and you hate zoom mode. So you do it this way. If it works for you , that's nice.
I do it in opposite direction and get same results and find that much easier.
You are free to find a workflow easier. But it still means you go through way more steps to achieve that result than I do (which is also fine by me). The downsides you see is that you can not be 100% sure you capture an event due the limit of the captured time interval. I don't care about that (which some people may find weird or even offensive; I'm a 'the glass is half full' person). In some cases I have no idea of the time scale anyway. I could spend half an hour to try and look it up or spend 5 seconds to poke with a probe. If the event isn't there then the measurement at least showed the time scale of the signal and there are alternative ways available to capture a specific event so no worries and no time lost. But when the event is in the memory then it is a massive saving in time & effort because I did two steps in one: analyse the problem and found the cause. Or fixed the last bug and verified I introduced no new bugs in one go. For most of the stuff I work on 10Mpts of memory is deep enough to cover 9 out of 10 cases but more memory is always better. In the end the result counts; the journey not so much.
-
To me convoluted process is to set memory depth, mentally calculating what timescale it will be at target sample rate, mentally calculate how much of that I have to set as pretrigger to make sure I have enough pre trigger capture once I'm at the target timebase. Then I set target timebase, tightly set around trigger and then keep capturing until I find something interesting, and then, without any sense where exactly in the whole buffer I am i keep twiddling around with timebase looking at data searching for something interesting.
That is not how it works! If you don't get it then you don't get it but by riduculing other people's workflow you only make a fool out of yourself.
It is exactly how it works. Unlike you, I like to have a guarantee I will capture something before I start doing it. You are doing this not because it is smart thing to do it, but because it is the lazy way, and you hate zoom mode. So you do it this way. If it works for you , that's nice.
I do it in opposite direction and get same results and find that much easier.
But both you, and now Dave apparently, try to sell this as some panacea, and will do that without any negative impact. Which is not true. It has consequences.
In my mind it is not that Siglent manages memory wrong way, but that zoom mode should be implemented to be more user friendly. I LIKE how zoom mode has DETERMINISTIC dual time bases. They should shuffle windows differently and make them more configurable, but it is a display and user interface problem, not capture problem. This is exactly what R&S and Keysight does: it sets timebase (internaly) for long capture, and then shows you only part of captured waveform. It is just U/I that shows you part of waveform, using basically "virtual timebase".
And I get it. I read what you wrote on this topic before.
By the by, it is you who is proponent of idea that whoever is not agreeing with you is stupid. And this is not first topic you had that condescending tone..
As I said before, you are wonderful engineer with waste experience. I respect that. And I agreed and disagreed with you on many topics. And I will keep doing that at my own conscience.
I agree its just a UI problem for the siglent anyway now that i figured out how to use the thing lol
I do like the configurables but they need a couple more and a way to make it work in a more natural mode by just turning the knob out.. if you could hide the preview bar and they put the zoom timebase below with the other timebase data, who could tell the difference?
-
You are free to find a workflow easier. But it still means you go through way more steps to achieve that result than I do (which is also fine by me). ...
It's same amount of steps. You Zoom Out, I Zoom In.
And on Picoscope with big screen and mouse scroll wheel it is so intuitive I don't even think about it.
That is for debug work similar to what you explained in your original post.
For interactive work ( what I call "scoping around") I use Keysight and twiddle knobs all the time. I will twiddle timebase in and out, and will be in Auto mode. Working similar to how you would with analog scope. Then I will stumble upon a signal that has frequency of occurring slower than what auto mode is auto triggering and I want it to stay on screen between triggers so triggering is stable. It might be something interesting so I press Single for it to capture it to Stop so I can take a look at what it is. This is the point where I can :
1 Change timebase to be longer to make sure to capture all of it (twiddle knob)
2. Arm for single and wait for trigger (press button)
3. Change timebase and horizontal position to look at signal in detail (like a full screen zoom in/out)
Or I can do this:
1. Go into scope setting and set acquisition memory for this (enter number of keystrokes and twiddles for your scope)
2. Arm for single and wait for trigger (press button)
3. Change timebase and horizontal position to look at signal in detail (like a full screen zoom in/out)
4. Once you move form this point go into scope setting and set acquisition memory for general work.
There is no even need for zoom mode. Zoom mode will add one more step to first procedure, and it will use some screen. OTOH it will allow you to have overview over where in the buffer are you, which can be confusing when you have zoom factors of 10000x. So with zoom mode it is same number of steps..
-
Yes, on the Siglent you literally change the memory depth on the menu and the memory depth shown in the bottom sample window doesn't change. It's insane.
That´s not completely correct…
In the menu, you could change the memdepth to 10k, 100k, 100M and 200M, so far so good.
But it will ony change in real (bottom sample window) when the timebase is in "the range".
I had created a little table:
[attachimg=1]
So, when you are in a timebase that "allows" 200Mpts memory, you could choose want yout want and it will be used (and displayed).
For example, when you are in a timebase where only 40Mpts are "possible", you could choose 100K or 10K, but you got no effect when choosing 100Mpts or 200Mpts.
So in my opinion, the selectable memory size is "semi-manual"....
When it´s not a big deal to change it in the firmware, siglent could let the user decide to have always the full memory control or change to auto mode.
And all will be happy... ;)
-
I think we already established it's a very limited(4 or 5 options?) memory LIMIT. Not a depth selection.
-
Yes, on the Siglent you literally change the memory depth on the menu and the memory depth shown in the bottom sample window doesn't change. It's insane.
That´s not completely correct…
In the menu, you could change the memdepth to 10k, 100k, 100M and 200M, so far so good.
But it will ony change in real (bottom sample window) when the timebase is in "the range".
I had created a little table:
(Attachment Link)
So, when you are in a timebase that "allows" 200Mpts memory, you could choose want yout want and it will be used (and displayed).
For example, when you are in a timebase where only 40Mpts are "possible", you could choose 100K or 10K, but you got no effect when choosing 100Mpts or 200Mpts.
So in my opinion, the selectable memory size is "semi-manual"....
When it´s not a big deal to change it in the firmware, siglent could let the user decide to have always the full memory control or change to auto mode.
And all will be happy... ;)
Thanks for this Martin.
That confirms my statement the setting is "auto mode max memory setting", meaning it will autorange memory, trying to keep sample rate highest possible until timebase becomes slow enough that it will limit memory and start slowing down sampling. That is exactly how Pico handles memory.
I also agree that if possible Siglent should enable user sacrifice history mode, and use full length sampling if user for some reason wants that . Making existing History mode they did was more complicated than just making it simply stupidly sample fixed amount.
-
I think we already established it's a very limited(4 or 5 options?) memory LIMIT. Not a depth selection.
Sounds logically to me...
-
You are free to find a workflow easier. But it still means you go through way more steps to achieve that result than I do (which is also fine by me). ...
It's same amount of steps. You Zoom Out, I Zoom In.
And on Picoscope with big screen and mouse scroll wheel it is so intuitive I don't even think about it.
That is for debug work similar to what you explained in your original post.
For interactive work ( what I call "scoping around") I use Keysight and twiddle knobs all the time. I will twiddle timebase in and out, and will be in Auto mode. Working similar to how you would with analog scope. Then I will stumble upon a signal that has frequency of occurring slower than what auto mode is auto triggering and I want it to stay on screen between triggers so triggering is stable. It might be something interesting so I press Single for it to capture it to Stop so I can take a look at what it is. This is the point where I can :
1 Change timebase to be longer to make sure to capture all of it (twiddle knob)
2. Arm for single and wait for trigger (press button)
3. Change timebase and horizontal position to look at signal in detail (like a full screen zoom in/out)
Or I can do this:
1. Go into scope setting and set acquisition memory for this (enter number of keystrokes and twiddles for your scope)
2. Arm for single and wait for trigger (press button)
3. Change timebase and horizontal position to look at signal in detail (like a full screen zoom in/out)
4. Once you move form this point go into scope setting and set acquisition memory for general work.
There is no even need for zoom mode. Zoom mode will add one more step to first procedure, and it will use some screen. OTOH it will allow you to have overview over where in the buffer are you, which can be confusing when you have zoom factors of 10000x. So with zoom mode it is same number of steps..
No. A common procedure for me is to check a detail of a bus decoded message or trigger on a very specific part of a signal. When zoomed out too far, I won't be able to inspect the detail. Depending on the results I zoom out if necessary. That use case works much faster when the scope just uses the amount of memory I selected instead of needing zoom. Your method would require to reset the time base to a low time/div, do the acquisition, then zoom in to see the result and repeat again. Doing this 10 times in a row gets frustrating quickly and the scope gets in the way of being productive. With my method you can just leave the scope at whatever setting and zoom in/out without needing to reset. It really is easier because I only need to use two knobs on the scope: horizontal position and time base and their exact setting is less critical.
-
You are free to find a workflow easier. But it still means you go through way more steps to achieve that result than I do (which is also fine by me). ...
It's same amount of steps. You Zoom Out, I Zoom In.
And on Picoscope with big screen and mouse scroll wheel it is so intuitive I don't even think about it.
That is for debug work similar to what you explained in your original post.
For interactive work ( what I call "scoping around") I use Keysight and twiddle knobs all the time. I will twiddle timebase in and out, and will be in Auto mode. Working similar to how you would with analog scope. Then I will stumble upon a signal that has frequency of occurring slower than what auto mode is auto triggering and I want it to stay on screen between triggers so triggering is stable. It might be something interesting so I press Single for it to capture it to Stop so I can take a look at what it is. This is the point where I can :
1 Change timebase to be longer to make sure to capture all of it (twiddle knob)
2. Arm for single and wait for trigger (press button)
3. Change timebase and horizontal position to look at signal in detail (like a full screen zoom in/out)
Or I can do this:
1. Go into scope setting and set acquisition memory for this (enter number of keystrokes and twiddles for your scope)
2. Arm for single and wait for trigger (press button)
3. Change timebase and horizontal position to look at signal in detail (like a full screen zoom in/out)
4. Once you move form this point go into scope setting and set acquisition memory for general work.
There is no even need for zoom mode. Zoom mode will add one more step to first procedure, and it will use some screen. OTOH it will allow you to have overview over where in the buffer are you, which can be confusing when you have zoom factors of 10000x. So with zoom mode it is same number of steps..
No. A common procedure for me is to check a detail of a bus decoded message or trigger on a very specific part of a signal. When zoomed out too far, I won't be able to inspect the detail. Depending on the results I zoom out if necessary. That use case works much faster when the scope just uses the amount of memory I selected instead of needing zoom. Your method would require to reset the time base to a low time/div, do the acquisition, then zoom in to see the result and repeat again. Doing this 10 times in a row gets frustrating quickly and the scope gets in the way of being productive. With my method you can just leave the scope at whatever setting and zoom in/out without needing to reset. It really is easier because I only need to use two knobs on the scope: horizontal position and time base and their exact setting is less critical.
For that case I do exactly same: I set timebase to long, zoom in to detail and keep retigering. On each retrigger i see my detail and get full buffer.... List shows all decode from full buffer, detail shows detail decode underneath.
-
No. A common procedure for me is to check a detail of a bus decoded message or trigger on a very specific part of a signal. When zoomed out too far, I won't be able to inspect the detail. Depending on the results I zoom out if necessary. That use case works much faster when the scope just uses the amount of memory I selected instead of needing zoom. Your method would require to reset the time base to a low time/div, do the acquisition, then zoom in to see the result and repeat again. Doing this 10 times in a row gets frustrating quickly and the scope gets in the way of being productive. With my method you can just leave the scope at whatever setting and zoom in/out without needing to reset. It really is easier because I only need to use two knobs on the scope: horizontal position and time base and their exact setting is less critical.
This is exactly how the siglent works now when setup properly.. its pretty nice, i just let it sit there and auto trigger and it marches along
-
That confirms my statement the setting is "auto mode max memory setting", meaning it will autorange memory, trying to keep sample rate highest possible until timebase becomes slow enough that it will limit memory and start slowing down sampling. That is exactly how Pico handles memory.
Then damn well call it Auto then.
Most other scopes have Auto and manual, but it appears the Siglent only has Auto, and that "Auto" mode will never use maximum memory below a certain time base setting.
It's completely inflexible for no reason.
I also agree that if possible Siglent should enable user sacrifice history mode, and use full length sampling if user for some reason wants that . Making existing History mode they did was more complicated than just making it simply stupidly sample fixed amount.
Yes, they went to the effort to implement it this way, very deliberately sacrificing manual control over memory at a huge number of timebase settings. No excuse for this. There is zero downside to not allowing users to select the memory depth they want at all timebase settings.
-
We look forward to your followup video Dave when you discover the capabilities of 2 obscure buttons on the Siglent front panel. ;) :popcorn:
Tautech, why not show the steps to achieve this without cheekiness? Remember that people that come across this thread may be trying to make a purchase decision - since they will not have a Siglent in front of them to explore the mysterious buttons, they will go elsewhere.
I urge you refresh your memory with study of the first 3 pages in the SDS2kX Plus thread.
Maybe the reasoning behind Siglents acquisition strategy will become clear.
-
I urge you refresh your memory with study of the first 3 pages in the SDS2kX Plus thread.
Maybe the reasoning behind Siglents acquisition strategy will become clear.
Care to make a quick summary?
DSO is a toolbox, and having one more tool in the box (be it zooming out or something else) can become handy sometimes and can shorten the workflow even if you typically don't need it. Mostly in single mode, where hard to repeat signals are checked and where DSOs excel.
Although Dave captured one possible design point that influenced the current behaviour with the always on history mode but my feeling is that we're still probably far from understanding the depth of this choice (as I guess few people were involved in DSO design from here).
For example if you can zoom out what else you can do with the more data then just looking on it? Can you re-apply FFT (or generally math) or will there be a gated FFT (I don't know if it's even possible today apart from the implicit power of 2 gating)?
How does this work with DSOs that can zoom out (I guess there can be vastly different design choices and end results...) Is it only about that you can look the data and take measurements with it (which become gated if zoomed out or re-applied?) or do more as well?
OK, last few questions are mainly for those who can check how the zoom out mode works in those scopes that support it but still a lot of unexplored questions...
-
We look forward to your followup video Dave when you discover the capabilities of 2 obscure buttons on the Siglent front panel. ;) :popcorn:
Tautech, why not show the steps to achieve this without cheekiness? Remember that people that come across this thread may be trying to make a purchase decision - since they will not have a Siglent in front of them to explore the mysterious buttons, they will go elsewhere.
I urge you refresh your memory with study of the first 3 pages in the SDS2kX Plus thread.
Maybe the reasoning behind Siglents acquisition strategy will become clear.
He does have a point... I had no clue zoom worked like that even after reading that originally before i picked up the scope and then forgot about it. It's not automatically natural/instinctual to setup and thats why it flummoxes a number of people and to a large degree they have a valid point. The scope does indeed allow timebase expansion already even exactly how nctnico works and is fanatic about / how Dave expects it to work as well so there is no reason they cant also make it an option to default work in that manor if someone wants it to WITHOUT selecting zoom.. in fact i'd encourage you to give them that direct feedback as it is something i'd like to see as well even after mastering zooming.
The ability to do that is just a matter of hiding the zoom ui components and reduce all of it into a timebase/memory selector based on the same table Martin72 posted.. they dont need to get fancy about it and shouldnt take one of their programmers no more than a couple of hours to tinker around with the UI
This is only a UI interface problem and NOT with the base functions of the scope itself
-
I urge you refresh your memory with study of the first 3 pages in the SDS2kX Plus thread.
Maybe the reasoning behind Siglents acquisition strategy will become clear.
Care to make a quick summary?
DSO is a toolbox, and having one more tool in the box (be it zooming out or something else) can become handy sometimes and can shorten the workflow even if you typically don't need it. Mostly in single mode, where hard to repeat signals are checked and where DSOs excel.
Although Dave captured one possible design point that influenced the current behaviour with the always on history mode but my feeling is that we're still probably far from understanding the depth of this choice (as I guess few people were involved in DSO design from here).
For example if you can zoom out what else you can do with the more data then just looking on it? Can you re-apply FFT (or generally math) or will there be a gated FFT (I don't know if it's even possible today apart from the implicit power of 2 gating)?
How does this work with DSOs that can zoom out (I guess there can be vastly different design choices and end results...) Is it only about that you can look the data and take measurements with it (which become gated if zoomed out or re-applied?) or do more as well?
OK, last few questions are mainly for those who can check how the zoom out mode works in those scopes that support it but still a lot of unexplored questions...
In general FFT follows what is on screen or can be gated (R&S for example). Math and measurements usually follows the memory depth but it can be gated on some scopes where math can be based on actually acquired data (Tektronix for example) or decimated data (Keysigh and R&S for example).
See this video I recorded on a MicSig TO1000 for example where I scroll through a 14Mpt record with FFT and some measurements enabled (you have to click on it in order to view it on Flickr):
(https://live.staticflickr.com/2822/34283102786_58845da303_c.jpg) (https://flic.kr/p/UetS45)
-
Announcement from another thread:
Let's see how Siglent reacts to this video and the one showing the comparison to their competitors. Perhaps there has been a conversation between the CEO and the R&D department already:
CEO: Why are our oscilloscopes different compared to all of the competitors?
R&D: The people from Lecroy said...
CEO: Don't care about what Lecroy said. Dave made us look stupid! And dumb! And more stupid. How much time to fix?
R&D: A couple of hours tops I guess.
CEO: Make it so! New firmware by the end of the week!
R&D: OK boss.
Alternative:
~1 month ago resulting from beta tester emails:
CEO: We need allow for capture zoom out.
R&D: Why ? Pico and LeCroy don't support it.
CEO: Apparently some can't embrace the capture analysis tools we offer so we need to make it much easier for them.
R&D: OK we will look into it but we really should be fixing the few bugs already reported.
CEO: Yes, OK then get onto it when you can.
Yes you heard it here first !
ETA, unknown.
-
The beauty of dso is, you can change nearly everything in firmware.
So, in case of siglent, why don´t change the memory management, letting the user allow to choose for himself always the maximum memory - or choosing it to auto.
-
Announcement from another thread:
Let's see how Siglent reacts to this video and the one showing the comparison to their competitors. Perhaps there has been a conversation between the CEO and the R&D department already:
CEO: Why are our oscilloscopes different compared to all of the competitors?
R&D: The people from Lecroy said...
CEO: Don't care about what Lecroy said. Dave made us look stupid! And dumb! And more stupid. How much time to fix?
R&D: A couple of hours tops I guess.
CEO: Make it so! New firmware by the end of the week!
R&D: OK boss.
Alternative:
~1 month ago resulting from beta tester emails:
CEO: We need allow for capture zoom out.
R&D: Why ? Pico and LeCroy don't support it.
CEO: Apparently some can't embrace the capture analysis tools we offer so we need to make it much easier for them.
R&D: OK we will look into it but we really should be fixing the few bugs already reported.
CEO: Yes, OK then get onto it when you can.
Yes you heard it here first !
ETA, unknown.
Nice.. my own take on it is just wanting to be able to hide the view finder top bar for more real estate.. that said i wouldnt mind being able to hide the top and bottom bars as well and maybe say use a double tap of the touch button to bring them back or a double touch at the location they would have normally been
-
The beauty of dso is, you can change nearly everything in firmware.
So, in case of siglent, why don´t change the memory management, letting the user allow to choose for himself always the maximum memory - or choosing it to auto.
They do.. from their own workflow its fine as it is and even with my own now that i know how it works, its just that everyone else whom dont understand how to use the zoom control to control it.. and thats a great deal of people
-
Why don't they just let you resize the windows? The R&S scopes let you do that. When in zoom mode I can hide the zoom nav window or make it huge. Same with FFT and bode plot. Let the user decide what they want.
-
The beauty of dso is, you can change nearly everything in firmware.
So, in case of siglent, why don´t change the memory management, letting the user allow to choose for himself always the maximum memory - or choosing it to auto.
Memory management is already auto within the limits of the max memory depth we set.
Capture depth is the topic of this thread and that will change, not the automatic memory management otherwise the risk is that other 'important to some' specifications will suffer.
Memory management is the way it is for good reason so to get best ADC/FPGA throughput performance.
-
The beauty of dso is, you can change nearly everything in firmware.
So, in case of siglent, why don´t change the memory management, letting the user allow to choose for himself always the maximum memory - or choosing it to auto.
Memory management is already auto within the limits of the max memory depth we set.
Capture depth is the topic of this thread and that will change, not the automatic memory management otherwise the risk is that other 'important to some' specifications will suffer.
Memory management is the way it is for good reason so to get best ADC/FPGA throughput performance.
But the user has chosen to manually use X memory depth. Saying they can't have that because they know better than the user what they want is just idiotic.
-
We look forward to your followup video Dave when you discover the capabilities of 2 obscure buttons on the Siglent front panel. ;) :popcorn:
Tautech, why not show the steps to achieve this without cheekiness? Remember that people that come across this thread may be trying to make a purchase decision - since they will not have a Siglent in front of them to explore the mysterious buttons, they will go elsewhere.
I urge you refresh your memory with study of the first 3 pages in the SDS2kX Plus thread.
Maybe the reasoning behind Siglents acquisition strategy will become clear.
He does have a point... I had no clue zoom worked like that even after reading that originally before i picked up the scope and then forgot about it. It's not automatically natural/instinctual to setup and thats why it flummoxes a number of people and to a large degree they have a valid point. The scope does indeed allow timebase expansion already even exactly how nctnico works and is fanatic about / how Dave expects it to work as well so there is no reason they cant also make it an option to default work in that manor if someone wants it to WITHOUT selecting zoom.. in fact i'd encourage you to give them that direct feedback as it is something i'd like to see as well even after mastering zooming.
The ability to do that is just a matter of hiding the zoom ui components and reduce all of it into a timebase/memory selector based on the same table Martin72 posted.. they dont need to get fancy about it and shouldnt take one of their programmers no more than a couple of hours to tinker around with the UI
This is only a UI interface problem and NOT with the base functions of the scope itself
Forgetting about the zoom out feature entirely, why on earth can't a user who manually selected X memory depth get that memory depth at the timebase they want?
-
A question for anyone with a scope that has the 'history' mode:
Does changing the settings between triggers, e.g. changing vertical or horizontal scale, or enabling an additional channel, clear the history buffer? If not, do such changes get reflected in the on-screen display of the settings, when reviewing history?
If I understood it correctly, you mean in Run mode, right? If so, the buffer is discarded when enabling channels on the Rigol DS4014 and I would expect so, given the memory is split between pairs of channels.
In stop mode you can change the vertical and horizontal settings without a problem.
Presumably you have to be in Stop mode anyway to look at the history?
Yes, or otherwise it's being continually overwritten.
-
The beauty of dso is, you can change nearly everything in firmware.
So, in case of siglent, why don´t change the memory management, letting the user allow to choose for himself always the maximum memory - or choosing it to auto.
They do.. from their own workflow its fine as it is and even with my own now that i know how it works, its just that everyone else whom dont understand how to use the zoom control to control it.. and thats a great deal of people
Nonsense. Zoom mode just wastes precious space when you need to set it to the full memory depth in order to force an oscilloscope to use all the memory. There is no useful information in there to have it on screen with the full memory record. A crutch is a crutch. An indicator where you are in the memory record (which is standard on many oscilloscopes) takes less space. Search and (when decoding) the list with decoded packages are way more useful navigation tools. And using the decoded list view in turn requires to do full memory decoding and not decode just what is on screen.
-
The beauty of dso is, you can change nearly everything in firmware.
So, in case of siglent, why don´t change the memory management, letting the user allow to choose for himself always the maximum memory - or choosing it to auto.
They do.. from their own workflow its fine as it is and even with my own now that i know how it works, its just that everyone else whom dont understand how to use the zoom control to control it.. and thats a great deal of people
Nonsense. Zoom mode just wastes precious space when you need to set it to the full memory depth in order to force an oscilloscope to use all the memory. There is nu useful information in there to have it on screen. Search and (when decoding) the list with decoded packages are way more useful navigation tools. And using the decoded list view in turn requires to do full memory decoding and not just what is on screen.
Again you use wording that makes it look like you insist that people are stupid if they don't think like you.
Zoom is useful, and navigational clues and buffer position are crucial piece of it. You just dislike it. On your R&S with large screen and freely configurable zoom size, it well worth the screen space it uses. On Picoscope with excellent zoom implementation it doesn't even use additional screen space at all. It is very easy and intuitive to use.
Try using your web browser on pc without scroll bars... You think people invented dozens of navigation tools in GUIs because they are stupid?
You keep applying fact that "zoom out" is useful for a special case (long, slow triggering captures where you need to get long sequence but need to look at on short packet to know when to stop) and apply it as a general principle.
Get a grip. Zoom out can be useful. We all agree to that by now.
Is it necessary ? No it is not. Very few people use it in isolated situations, and you can as well accomplish same results using zoom mode and/or propper timebase settings. Comfort of any work procedure is highly individual thing.
Should Siglent add full manual control of acquisition memory like R&S has? Yes by all means, if they can. It is ALWAYS better to have more options. I still would like if they would make zoom mode more configurable to be able to use less screen space as I would rather use that. It is more logical and straightforward to me. And any user of Picoscope and LeCroy.
Would I refuse to buy LeCroy or Siglent scope because of that? No, not by a long shot. I bought Picoscopes despite that, because it is unimportant to me. I just use zoom mode when I need to capture long and look at short time. Period.
What bothers me a bit are these overblown overtones in how this, frankly, non issue, is presented here.
I have an urgent message to Siglent: Please issue urgent firmware update in which in all menus and user manuals you rename memory depth options so it is clear memory management is Auto with max length.
Because that is only mistake they made. Unclear terminology. Everything else is one man on a crusade, and a bit of clickbait titles on some videos.
If you guys want to give Siglent (or any other manufacturers) a grief, then please apply energy to get them to fix real problems, real bugs or add real, useful, features.
For instance Nico says his prefered method to navigate through capture when decoding is to use list or search.
So why he didn't write an write up how R&S RTM3000 (that is very expensive) doesn't have search on most basic I2C, SPI or UART protocols. After few years since it is released, still doesn't and not a peep from R&S they even have intention to do so.
NOW, that is a serious problem, and a reason I didn't buy RTM 3000 at the time . It was otherwise my first choice.
Try finding one packet in 10000 manually.
GW Instek has it, Keysight has it on 3000T series and up, Lecroy has it...
That is an example of real reason not to buy that scope, not some buffer management strategy that you might need in obscure workflow that is applicable only now and then.
And my reason why I didn't buy SDS5000X so far is the same. No search on decoded data. You want to give grief to Siglent, bug them about that.
And to make decoding to decode full buffer length, not only what is shown, with and without zoom mode. That is useful. I agree with you Nico on that. That is something Picoscope does right..
Best regards to all..
-
Get a grip. Zoom out can be useful. We all agree to that by now.
Is it necessary ? No it is not. Very few people use it in isolated situations, and you can as well accomplish same results using zoom mode and/or propper timebase settings. Comfort of any work procedure is highly individual thing.
Should Siglent add full manual control of acquisition memory like R&S has? Yes by all means, if they can. It is ALWAYS better to have more options. I still would like if they would make zoom mode more configurable to be able to use less screen space as I would rather use that. It is more logical and straightforward to me. And any user of Picoscope and LeCroy.
Would I refuse to buy LeCroy or Siglent scope because of that? No, not by a long shot. I bought Picoscopes despite that, because it is unimportant to me. I just use zoom mode when I need to capture long and look at short time. Period.
What bothers me a bit are these overblown overtones in how this, frankly, non issue, is presented here.
I have an urgent message to Siglent: Please issue urgent firmware update in which in all menus and user manuals you rename memory depth options so it is clear memory management is Auto with max length.
Because that is only mistake they made. Unclear terminology. Everything else is one man on a crusade, and a bit of clickbait titles on some videos.
Umm, all you points above is practically a verbatim summary of what I said in my videos.
-
Get a grip. Zoom out can be useful. We all agree to that by now.
Is it necessary ? No it is not. Very few people use it in isolated situations, and you can as well accomplish same results using zoom mode and/or propper timebase settings. Comfort of any work procedure is highly individual thing.
Should Siglent add full manual control of acquisition memory like R&S has? Yes by all means, if they can. It is ALWAYS better to have more options. I still would like if they would make zoom mode more configurable to be able to use less screen space as I would rather use that. It is more logical and straightforward to me. And any user of Picoscope and LeCroy.
Would I refuse to buy LeCroy or Siglent scope because of that? No, not by a long shot. I bought Picoscopes despite that, because it is unimportant to me. I just use zoom mode when I need to capture long and look at short time. Period.
What bothers me a bit are these overblown overtones in how this, frankly, non issue, is presented here.
I have an urgent message to Siglent: Please issue urgent firmware update in which in all menus and user manuals you rename memory depth options so it is clear memory management is Auto with max length.
Because that is only mistake they made. Unclear terminology. Everything else is one man on a crusade, and a bit of clickbait titles on some videos.
Umm, all you points above is practically a verbatim summary of what I said in my videos.
Yes, but discussion was going away from it....
I only reiterated points that were written here even before you made those videos..
Your videos are pretty much verbatim of our previous discussion and analysis on the topic by several members here..
That is nature of discussions on specific topic, we speak about same things.. It only means we agree on something..
Regards,
Sinisa
-
I'll drop this here for study.
SDS5054X Zoom mode dual timebase Stop.
SPI source=STB3
-80ms to +99ms decoded data listed in ~3700 bytes
We can navigate through the capture with a drag of a finger, H Pos or mouse in either window(dotted outline = active) and play forward or backwards or jump to a timestamp.
Decode bar placed wherever you like. :P
Hide the right pane menu if required. :P
Then there's also History......
Same tools as are in SDS2000X Plus.
(https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/?action=dlattach;attach=1002782)
-
[...] It only means we agree on something..
Regards,
Sinisa
We are having a violent agreement! :D
-
[...] It only means we agree on something..
Regards,
Sinisa
We are having a violent agreement! :D
I think everybody is quite civilised... We disagree. So what? If any of these discussions make anyone learn anything, and/or Siglent, or any other manufacturer make better products because of these discussions, it's a win.
-
This is a marketing tip from Siglent.
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.
-
LOL :-DD
Made my day..
-
The beauty of dso is, you can change nearly everything in firmware.
So, in case of siglent, why don´t change the memory management, letting the user allow to choose for himself always the maximum memory - or choosing it to auto.
They do.. from their own workflow its fine as it is and even with my own now that i know how it works, its just that everyone else whom dont understand how to use the zoom control to control it.. and thats a great deal of people
Nonsense. Zoom mode just wastes precious space when you need to set it to the full memory depth in order to force an oscilloscope to use all the memory. There is nu useful information in there to have it on screen. Search and (when decoding) the list with decoded packages are way more useful navigation tools. And using the decoded list view in turn requires to do full memory decoding and not just what is on screen.
Again you use wording that makes it look like you insist that people are stupid if they don't think like you.
Zoom is useful, and navigational clues and buffer position are crucial piece of it. You just dislike it. On your R&S with large screen and freely configurable zoom size, it well worth the screen space it uses. On Picoscope with excellent zoom implementation it doesn't even use additional screen space at all. It is very easy and intuitive to use.
You misunderstand my point but I see I had to clarify it better. If you have to use zoom mode to force an oscilloscope to use all the memory then the zoom mode loses it's intended function: offering a view on a signal using 2 different time/div / horizontal position settings. As you already stated this is very useful to keep track of 2 different parts of a at the same time (which is precisely why dual time bases where invented). However viewing the entire buffer in a zoom window just produces a bunch of colored horizontal bars in most cases. The picture Tautech posted above shows that. IOW: It is a waste of screen space taken by zoom mode AND loss of functionality if the only purpose of zoom mode is to have a workaround to force an oscilloscope to use all the memory.
-
Forgetting about the zoom out feature entirely, why on earth can't a user who manually selected X memory depth get that memory depth at the timebase they want?
Because they are boneheads who didnt think of it like that? From their perspective why would you need such a silly feature when you have a full advanced module to use instead? Function already exists.. go make something else / dont waste your time on X feature mentality.. as the chinese would say.. its 'chabuduo' and usually the best way to deal with that is just be insistent without causing them to lose face when they originally didnt care it was substandard. This was the basis for my earlier comment about their culture being that way.. just something that is common with their culture anyone having stuff made there has to be aware of if any QC
Either way from what tau posted it sounds like they will add UI functions to do just that since its just an extension of the zoom functions already there or rather i should say it is storing the data already if in zoom mode.. copy paste code / build UI without zoom UI and make a lot more people happy.. which is actually a better outcome because it means they are listening and willing to actively address it
For the longest time I thought they flat out didnt even support timebase / expanded memory depth which always irked me because otherwise you are forced to look at a giant blob of a cluster fuck and good luck figuring that out if you are just watching it while waiting to trigger
-
You misunderstand my point but I see I had to clarify it better. If you have to use zoom mode to force an oscilloscope to use all the memory then the zoom mode loses it's intended function: offering a view on a signal using 2 different time/div / horizontal position settings. As you already stated this is very useful to keep track of 2 different parts of a at the same time (which is precisely why dual time bases where invented). However viewing the entire buffer in a zoom window just produces a bunch of colored horizontal bars in most cases. The picture Tautech posted above shows that. IOW: It is a waste of screen space taken by zoom mode AND loss of functionality if the only purpose of zoom mode is to have a workaround to force an oscilloscope to use all the memory.
Same reason i keep bringing up the UI needs modded to allow those components to be selectively hidden or shown or even a small slider... aka just tell if you want expanded memory when available and display it in the timebase box like 'normal'
I both like the full waveform slider and dislike it at the same time... the screen is big enough that it doesnt matter its there or not really.. that said however i want my real estate back anyway because its just a distraction unless im actually wanting to scroll through it and in that case just unhide it
-
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.
-
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
-
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.
That is ofcourse just an opinion; we can't verify Siglent's sales versus others.
Anyway, if a manufacturer wants to cater the professional market then the product must have 100% of the features the professional market requires. No crutches. No half-assed work-arounds. Likely this will make Siglent increasing their prices even more above Rigol's in order to recoup the development costs. Still I think there will be very good value for money. Siglent is getting very close to A-brand territory.
Edit: I agree with what Martin72 wrote below.
-
@Rob:
It could always getting better... ;)
Siglent should "allow" the users to have individual control on the memory ( 200mpts...Boy...), then there will be nearly nothing to stop everyone to buy a siglent.
-
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.
Sorry I was too busy setting my scope mem depth manually and play with horizontal window all day long 8)
I don't why there is problem outside Europe but thanks to members here, I knew several things about this scope before it's released. I sold my SDS2204X waiting for It.
I asked for quotes from the first day and there is always stock.
There was a break two or three days at Batronix but it returned to stock very quickly.
-
Siglent is getting very close to A-brand territory.
That is also my assessment, although I´m "only" a testfield technician…
With the SDS5000/SDS 2000X+, they´re are close to it - Remember the specs of the sds2k+, timebase 1ppm and low noise frontend...at this price...
And the SDS5K is the cheapest 1Ghz scope on the market…
Sure, there will be Pros and Cons on the memory mangement thing, but what is the goal of a manufacturer…
Right, to sell as much as possible, so their product should fullfill nearly all the needs.
And when the needs hang on to some, who prefer fully memory control...Why don´t following this.
-
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 8)
...............
Navigate can help with that. ;)
-
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
-
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?
-
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. :popcorn:
-
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?
-
Got a clever plan, we're all ears. :popcorn:
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.
-
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).
-
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).
-
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
-
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.
(https://siglent.fi/data/SDS1000X-E-4-CH/table-amount-of-segments-wfmbuffer.png)
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)
-
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 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg2786800/#msg2786800)
And discussion just beforehand. ;)
-
Got a clever plan, we're all ears. :popcorn:
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.
-
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.
-
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).
-
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 ...
-
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. :popcorn:
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
-
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.
-
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).
:clap:
And you worked that out without RTFM. :-+
-
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. :popcorn:
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. :-+
-
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... :-+
-
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. :popcorn:
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. :palm:
-
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. :popcorn:
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. :palm:
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 ?
-
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. :palm:
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.
-
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. :palm:
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.
-
[attachimg=1]
Gentlemen, keep calm... ;)
-
Since many people that doesn't have (or actively use) scope that has Lecroy/Picoscope/Siglent type of memory management are absolutely sure it is evil and unusable, based on prejudice, wild accusations and no real data, here is an example why all this is a BOGUS problem.
Used Pico as example:
A look at 50 ns pulse width (yes that is a zoom factor of 1M (1 milion), without any visible performance impact :
[attachimg=1]
same thing with resizable, floating overview:
[attachimg=2]
This is full size capture, with 200ms worth of data....
[attachimg=3]
What is crippled here, or hard to use or hard to understand ?
How is this HARDER to understand than manually fuffing around with sample lengths, timebases and such?
What is unclear here?
And to answer to Dave's predicament, you never get ANYTHING free.
Either way you need to MANUALLY set scope to capture long capture BEFOREHAND (either by virtue of fixed sample memory length, or fixed time length.)
And you don't want to keep scope in this ultra long capture setting all the time. It is practically unusable for normal "scoping around". Not only because it is "lot of data to process". It is simply that every capture will last 200ms even without any processing time. While discussing whether 1M WFMs/sec is better than 100k WFMs/sec is a moot point, once we start talking about 4 WFMs/sec it gets unusable for normal use.
So you will go back to auto memory management or short sample length for "normal" use. Meaning every time you want to use "zoom out" you will need to setup scope memory depth manually and specifically for that and do that beforehand. So the argument " it is nice to have this for times you didn't plan for it, you just realized something, and than you just zoom out and there it is.." doesn't stand.
It is always deliberate manual setup, either way. I do recognize that each person has its own way of thinking, but calling different way to achieve same thing "crippling defect" and suggesting that "people should not buy these scopes until this defect is fixed" is very, very wrong, both factually, and as a message..
It just seems unnecessarily inflammatory..
-
Since many people that doesn't have (or actively use) scope that has Lecroy/Picoscope/Siglent type of memory management is absolutely sure it is evil and unusable, based on prejudice, wild accusations and no real data, here is an example why all this is a BOGUS problem.
I have to stop you right there... I have owned a Siglent scope and the automatic memory mode drove me nuts because it got in the way of working efficiently. So from my side there is no prejudice; only hands on experience and hard facts. I also own a Lecroy scope BTW but I got that because it was cheap and has oodles of bandwidth.
Besides all that: stop attacking people's workflow and force your workflow on others. Nobody is attacking your workflow or forcing a workflow upon you. In the end it is about adding more flexibility to cater more usage scenarios and not coming up with workarounds (which don't work in all cases).
-
[...]
Used Pico as example:
[...]
The "root cause" of the whole discussion is that the typical oscilloscope doesn't have a very big screen, so the various zooming ideas being discussed are essentially ways to overcome that in a smooth and convenient way.
Having the scope run on your PC gives you a whole bunch of new advantages, obviously. With a comparatively gigantic screen, you can have several windows open with different degrees of zoom.
On the other hand, a PC based scope requires that you are totally comfortable with a mouse-and-keyboard workflow, rather than physical knobs. Personally, I like both approaches!
-
Since many people that doesn't have (or actively use) scope that has Lecroy/Picoscope/Siglent type of memory management is absolutely sure it is evil and unusable, based on prejudice, wild accusations and no real data, here is an example why all this is a BOGUS problem.
I have to stop you right there... I have owned a Siglent scope and the automatic memory mode drove me nuts because it got in the way of working efficiently. So from my side there is no prejudice; only hands on experience and hard facts. I also own a Lecroy scope BTW but I got that because it was cheap and has oodles of bandwidth.
Besides all that: stop attacking people's workflow and force your workflow on others. Nobody is attacking your workflow or forcing a workflow upon you. In the end it is about adding more flexibility to cater more usage scenarios and not coming up with workarounds (which don't work in all cases).
I'm not attacking your workflow. I sad many times that I understand it works and you like it.
But is not better than what I do, simply different keystrokes and way of thinking.
And since nobody gave any real example of workflow where it is real impediment ,except you, that did give a real, good example of where this manual memory setting is useful (I keep giving you credit for that). This is not addressed to you but is a documented explanation how it works on Picoscope, and why many things said here are not standing... As I said, you are right about your example. But that is something I very effectively and simply accomplish on Picoscope the way it is and I guarantee you it has no "crippling defect" because it was made that way.
-
[...]
Used Pico as example:
[...]
The "root cause" of the whole discussion is that the typical oscilloscope doesn't have a very big screen, so the various zooming ideas being discussed are essentially ways to overcome that in a smooth and convenient way.
Having the scope run on your PC gives you a whole bunch of new advantages, obviously. With a comparatively gigantic screen, you can have several windows open with different degrees of zoom.
On the other hand, a PC based scope requires that you are totally comfortable with a mouse-and-keyboard workflow, rather than physical knobs. Personally, I like both approaches!
Agree. That is why I said many messages ago that this is not something that even needs different memory strategy, just reworked zoom mode.
Zoom mode IS dual timebase mode. Just better screen management is needed. And I do think that problem is worse on my Keysight 3000T than on scopes with 10" and 12" screens..
-
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 ?
Correct, you use the code base of zoom mode but are just hiding the shown UI components and rescaling the zoom area to full screen
And you don't get rid of either, you allow the user to use split screen or hide what they want... in the end its all functions of telescopic zooming people are doing, only thing going around and around are semantics of what it looks like
-
[...]
Used Pico as example:
[...]
The "root cause" of the whole discussion is that the typical oscilloscope doesn't have a very big screen, so the various zooming ideas being discussed are essentially ways to overcome that in a smooth and convenient way.
Having the scope run on your PC gives you a whole bunch of new advantages, obviously. With a comparatively gigantic screen, you can have several windows open with different degrees of zoom.
On the other hand, a PC based scope requires that you are totally comfortable with a mouse-and-keyboard workflow, rather than physical knobs. Personally, I like both approaches!
Which i find ironic in the case of the 2k+... while i dont like the real estate consumed by the horizontal scrollbar.. it also isnt a hindrance other than its more data on the screen i dont need to immediately be looking at so for me it works fine as is.. my only adovation is for hiding the extra ui bits so i get more screen space back... which also just happens to be the more natural way to zoom in and out / control memdepth to timebase
-
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 ?
Correct, you use the code base of zoom mode but are just hiding the shown UI components and rescaling the zoom area to full screen
And you don't get rid of either, you allow the user to use split screen or hide what they want... in the end its all functions of telescopic zooming people are doing, only thing going around and around are semantics of what it looks like
Of course not. ;)
What will be interesting is exactly how it's implemented. Zoom in and Zoom out capture capabilities !
When I have some more 2kX Plus hopefully I'll get see a beta of the proposed solution but it's a little way off yet.
Existing strategies will not apparently be changed only capture memory management.
-
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 ?
Correct, you use the code base of zoom mode but are just hiding the shown UI components and rescaling the zoom area to full screen
And you don't get rid of either, you allow the user to use split screen or hide what they want... in the end its all functions of telescopic zooming people are doing, only thing going around and around are semantics of what it looks like
Of course not. ;)
What will be interesting is exactly how it's implemented. Zoom in and Zoom out capture capabilities !
When I have some more 2kX Plus hopefully I'll get see a beta of the proposed solution but it's a little way off yet.
Existing strategies will not apparently be changed only capture memory management.
lol does defprom still have yours?
-
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 ?
Correct, you use the code base of zoom mode but are just hiding the shown UI components and rescaling the zoom area to full screen
And you don't get rid of either, you allow the user to use split screen or hide what they want... in the end its all functions of telescopic zooming people are doing, only thing going around and around are semantics of what it looks like
Of course not. ;)
What will be interesting is exactly how it's implemented. Zoom in and Zoom out capture capabilities !
When I have some more 2kX Plus hopefully I'll get see a beta of the proposed solution but it's a little way off yet.
Existing strategies will not apparently be changed only capture memory management.
lol does defprom still have yours?
Nope. :(
Got sold before I even got it back.....and we were in Covid lockdown at the time !
The moment it came back, in the mail again it went to its new owner.
So now I just have to use a SDS5054X. ;D
-
.............
So now I just have to use a SDS5054X. ;D
Awwwww, poor soul !! :-DD
-
https://www.youtube.com/watch?v=wLcdZjFuho0 (https://www.youtube.com/watch?v=wLcdZjFuho0)
Just seen it now..
If I understand it right, they (siglent) sacrifice the manual handling of the full memory for permanent active history ?
It´s a little bit confusing me, because manual "says" the number of stored frames are depending to the timebase setting.
So as you actual got different memorypoints depending on the timebase, you also would have different amount of frames which will be stored.
So what do they do with the 200 mpts ?
Just asked them now via email.
-
video link
Just seen it now..
If I understand it right, they (siglent) sacrifice the manual handling of the full memory for permanent active history ?
It´s a little bit confusing me, because manual "says" the number of stored frames are depending to the timebase setting.
So as you actual got different memory points depending on the timebase, you also would have different amount of frames which will be stored.
So what do they do with the 200 mpts ?
Assigned to the History memory buffer......it is all used irrespective of the mem depth selected.
Circular buffer and when smaller mem depths are used more History frames are available.
Keep RTFM. ;)
-
Keep RTFM. ;)
Nice advice... ;)
The more you repeat this, the more it must be getting important.
Meanwhile the siglent europe support answered me now, on a sunday evening.
It was not an auto-answer you might expect as nearly always as a first reaction.
-
Keep RTFM. ;)
Nice advice... ;)
The more you repeat this, the more it must be getting important.
Meanwhile the siglent europe support answered me now, on a sunday evening.
It was not an auto-answer you might expect as nearly always as a first reaction.
That's surprising... its midnight over there, get the deskew yet? :P
-
No Sir and it´s getting better…
On livechat I´ve told them, well when delivering with UPS, you should be better deliver to the company I work.
No problem they repeat, just tell us the adress.
I´ve told them…
Yesterday I got a new status, it is on it´s way…
To my private adress... :P
-
https://www.youtube.com/watch?v=wLcdZjFuho0 (https://www.youtube.com/watch?v=wLcdZjFuho0)
Just seen it now..
If I understand it right, they (siglent) sacrifice the manual handling of the full memory for permanent active history ?
Yes, correct.
Other scopes on the market like R&S allow your to do both without problem.
It´s a little bit confusing me, because manual "says" the number of stored frames are depending to the timebase setting.
So as you actual got different memorypoints depending on the timebase, you also would have different amount of frames which will be stored.
So what do they do with the 200 mpts ?
They fill up the 200M with as many frames as will fit based on the current timebase. You get no say in it, and you can't disable it.
You can kinda-sorta get around it by setting a slow timebase setting and using using 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. :popcorn:
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. :palm:
No. No and No!
In this place I ask... what are you smoking if you can not imagine how this solution work and so that then it can keep BOTH kind of working principle in same scope just so that user normal run with fixed mem length in full window zoom mode like ancient DS1052E) and after then when he stop scope he can zoom out... zoom out like its is some miraculous feature. Like in your scope you can zoom in and out and pan and go to other position details or less details, up to you how much you want zoom in or out. But after this @elasia based solution it also keep opportunity that also in run mode you can also zoom out up to full memory length displayed and NEWER drop situation where something is out from display and whole trace available only in stop mode. With this simplest solution you get all together up to you how you want setup and use your scope. With my poor language skills, I cannot explain it in such a way that you too can perceive it in practice. Try make model using carton, scissors and glue and pen.
If you use this kind of (improved Siglent) scope I can ask, what functionality you are then missing. Perhaps you need then desperately try find new arguments or move the goal in middle of the game.
-
Please read all of my posts on this topic. I have explained very clearly why and how zoom mode is NOT the solution. And if you think carefully about it then you'll also see that by using zoom mode to force the memory length you sacrifice the zoom function (delayed / dual timebase) as well. Also, don't get stuck in old grudges and be blinded by them (same problem Tautech has). Currently Siglent is missing a memory management feature which is easy to add and it seems they are working on it right now.
-
Please read all of my posts on this topic. I have explained very clearly why and how zoom mode is NOT the solution. And if you think carefully about it then you'll also see that by using zoom mode to force the memory length you sacrifice the zoom function (delayed / dual timebase) as well.
Translation; you are wrong I am right, please don't ask me to justify why I am right.
Also, don't get stuck in old grudges and be blinded by them (same problem Tautech has).
Pot calls kettle black.
Currently Siglent is missing a memory management feature which is easy to add and it seems they are working on it right now.
Translation; Siglent produced a product lacking a function that seems to defy logic in why anyone with a basic grasp of reality would not use such a vast amount of memory to be able to zoom out. But hey, don't worry, the Siglent coding cavalry are about to ride over the hill and rescue us all....
On the brighter side, at least you didn't say we were all "stupid" for not agreeing with you.
-
Please read all of my posts on this topic. I have explained very clearly why and how zoom mode is NOT the solution. And if you think carefully about it then you'll also see that by using zoom mode to force the memory length you sacrifice the zoom function (delayed / dual timebase) as well. Also, don't get stuck in old grudges and be blinded by them (same problem Tautech has). Currently Siglent is missing a memory management feature which is easy to add and it seems they are working on it right now.
I know you keep saying it but what we are talking about doesnt even modify siglents UI zoom mode as it is.. im lost why you keep saying zoom is sacrificed?
I'm now using zoom mode as is and it works fine to zoom out and see more data on screen, i mean thats kind of its job right? What do you think zoom mode is suppose to be? I'm a bit lost on that as well
What we have been talking about is using the zoom functions core code to be cloned and wired up to an enhanced UI with just a couple of menu bar selections to pick your higher timebase/memdepth from a list of timebases they can support and already do because they are defined for the zoom module to already use
Now for what this is NOT.. its not just magically adding more memspace to the current timebase they quite possibly cant support for xyz design reasons and is the part they are debating how to do still.. and might take them awhile to figure out as that really would be a major memory reallocation against their code base
-
Also, don't get stuck in old grudges and be blinded by them (same problem Tautech has).
Pot calls kettle black.
Nope. One of my customers bought some Siglent equipment because I suggested it. Including equipment needed for a very critical demonstration for the US government. In the end grudges and principles are just a waste of energy and money.
-
Please read all of my posts on this topic. I have explained very clearly why and how zoom mode is NOT the solution. And if you think carefully about it then you'll also see that by using zoom mode to force the memory length you sacrifice the zoom function (delayed / dual timebase) as well. Also, don't get stuck in old grudges and be blinded by them (same problem Tautech has). Currently Siglent is missing a memory management feature which is easy to add and it seems they are working on it right now.
I know you keep saying it but what we are talking about doesnt even modify siglents UI zoom mode as it is.. im lost why you keep saying zoom is sacrificed?
I'm now using zoom mode as is and it works fine to zoom out and see more data on screen, i mean thats kind of its job right? What do you think zoom mode is suppose to be? I'm a bit lost on that as well
In some cases you might want to look at a signal at two positions / different time bases (this is called dual timebase on analog oscilloscopes). With auto memory length the memory depth will be set to the amount needed to fill the screen with the longest time/div setting. However if you want to force the oscilloscope to use more memory you'll need to set the time/div longer. But in that case you likely won't be able to see the details in a signal. So without being able to manually force the memory depth you can use the zoom mode to force deeper memory OR see two parts of a signal at the same time. IOW: With auto memory depth you can't have both deep memory and see two parts of the same signal at the same time.
-
Currently Siglent is missing a memory management feature which is easy to add and it seems they are working on it right now.
The fact that they're "working on it" proves that there's a problem.
-
Please read all of my posts on this topic. I have explained very clearly why and how zoom mode is NOT the solution. And if you think carefully about it then you'll also see that by using zoom mode to force the memory length you sacrifice the zoom function (delayed / dual timebase) as well. Also, don't get stuck in old grudges and be blinded by them (same problem Tautech has). Currently Siglent is missing a memory management feature which is easy to add and it seems they are working on it right now.
I know you keep saying it but what we are talking about doesnt even modify siglents UI zoom mode as it is.. im lost why you keep saying zoom is sacrificed?
I'm now using zoom mode as is and it works fine to zoom out and see more data on screen, i mean thats kind of its job right? What do you think zoom mode is suppose to be? I'm a bit lost on that as well
In some cases you might want to look at a signal at two positions / different time bases (this is called dual timebase on analog oscilloscopes). With auto memory length the memory depth will be set to the amount needed to fill the screen with the longest time/div setting. However if you want to force the oscilloscope to use more memory you'll need to set the time/div longer. But in that case you likely won't be able to see the details in a signal. So without being able to manually force the memory depth you can use the zoom mode to force deeper memory OR see two parts of a signal at the same time. IOW: With auto memory depth you can't have both deep memory and see two parts of the same signal at the same time.
Oh you mean split screen? Yeah they dont really do a good job of that either.. you just get the smaller horizonal box at the top you cant vertically resize to choose how much each pane is using
-
Oh you mean split screen? Yeah they dont really do a good job of that either.. you just get the smaller horizonal box at the top you cant vertically resize to choose how much each pane is using
Yes, zoom mode = split screen.
-
Oh you mean split screen? Yeah they dont really do a good job of that either.. you just get the smaller horizonal box at the top you cant vertically resize to choose how much each pane is using
Yes, zoom mode = split screen.
Eh.. the way it is now its hard to really call it split screen with independent timebases... their intent is more like the top is just a view finder from how it works as is but yeah thats something else that would be nice to have
-
Please read all of my posts on this topic. I have explained very clearly why and how zoom mode is NOT the solution. And if you think carefully about it then you'll also see that by using zoom mode to force the memory length you sacrifice the zoom function (delayed / dual timebase) as well. Also, don't get stuck in old grudges and be blinded by them (same problem Tautech has). Currently Siglent is missing a memory management feature which is easy to add and it seems they are working on it right now.
I know you keep saying it but what we are talking about doesnt even modify siglents UI zoom mode as it is.. im lost why you keep saying zoom is sacrificed?
I'm now using zoom mode as is and it works fine to zoom out and see more data on screen, i mean thats kind of its job right? What do you think zoom mode is suppose to be? I'm a bit lost on that as well
In some cases you might want to look at a signal at two positions / different time bases (this is called dual timebase on analog oscilloscopes). With auto memory length the memory depth will be set to the amount needed to fill the screen with the longest time/div setting. However if you want to force the oscilloscope to use more memory you'll need to set the time/div longer. But in that case you likely won't be able to see the details in a signal. So without being able to manually force the memory depth you can use the zoom mode to force deeper memory OR see two parts of a signal at the same time. IOW: With auto memory depth you can't have both deep memory and see two parts of the same signal at the same time.
Honestly, I don't understand what are you saying.
[attachimg=1]
How is this not dual timebase? How is this not detail from bigger picture?
-
You choose an example in which you can still see both signals on an oscilloscope with very little memory. Set the bitrate to 1Mbit/s (100 times higher) with a much higher packet rate as well and try to do the same with the top zoom window set to 5ms/. You'll see a contigous colored band. If you set the zoom window to 50us/ in order to see the packets a Siglent scope will shorten the memory depth and there is nothing you can do about it. You have a choice between either having long memory but not being able to see the packets in the zoom window OR seeing the packets but not have deep memory.
-
You choose an example in which you can still see both signals on an oscilloscope with very little memory. Set the bitrate to 1Mbit/s (100 times higher) with a much higher packet rate as well and try to do the same with the top zoom window set to 5ms/. You'll see a contigous colored band. If you set the zoom window to 50us/ in order to see the packets a Siglent scope will shorten the memory depth and there is nothing you can do about it. You have a choice between either having long memory but not being able to see the packets in the zoom window OR seeing the packets but not have deep memory.
No it won't. I showed you example from my Pico where I sampled 100 MPoints in 200ms and shown it zoomed in to 20ns /div, zoom factor of 1M X. Yes, one million times.
Tautech posted one image above, where he got 50 MPoints at 20 ms/div (200 ms total) and is showing details at 20 us/div.
This is how it works but you don't seem to understand. On main timebase you grab big chunk of data, and zoom shows a subset of that, in such a detail that is only defined by sampling rate. Which will be limited by memory size.
But zooming in won't change anything from how timebase and sampling is set, only what are you looking at.
So you enable 100 MPoints, set timebase to use all 100 MPoints, and you can zoom in to every single point...
And zoom will not shorten or change anything.
What are you saying is SIMPLY NOT TRUTH. Just look at the overwhelming evidence shown here..
-
........... IOW: With auto memory depth you can't have both deep memory and see two parts of the same signal at the same time.
In this previous extremely simple "single toggle button" solution this is not possible of course if need two separate zoomed in parts displayed. But also in your explanation this full deep memory is available only after stop. Edit: clarified: Runtime you can see only these two zoomed in parts with more or less limited positioning. (I use also "zoomed in" thinking for this full window zoom mode what is just how many (most) scopes work. You may have 10M sample memory and 1Gsa/s and your fastest 2ns/div "timebase" zoomed in (full screen zoom in) 10 div wide window is just example 20ns slice from this example 10000000ns long acquistion length. And what happen when turn "timebase" only zoom in factor change.
Now if your time base is 20ns you can select zoom 20ns and move it to other position in this long memory.
But how if you then have moved it but you suddenly want zoom it out. many scopes do not accept it. You need first change this "main timebase" aka zoom factor aka horizontal scale.
Full memory lenght to display + dual independent zoom in to details like in some ancient good analog scope is this.
Digital scope can do it and also in runtime whole memory length display is possible to see or shut off and these two separate "zoomed in" traces can draw overlaid with free time position related to each others and or each others based fixed difference where all are user adjustable including also freedom for set fixed trigger time position in acquisition memory. Three timebase with dual independent delayed timebases (timebase is bit fun word with digital scopes but Im from analog scopes golden era). Of course all can do, even Rolls Royce. But there is markets and how much some features really add sales and more importantly profit to maker.... all is nice to have but money talks.
But I want scope what can display full current memory length always when/if I want on the screen and many scopes can not. Even if length is 1G I want see whole trace without hiding parts out from display except cases when I do not care this. If I want cdetails today it is best there is user settable windows available with different scales overlaid on screen and full freedom for user to position and adjust these scales and time relations to each others and trigger-.
-
You choose an example in which you can still see both signals on an oscilloscope with very little memory. Set the bitrate to 1Mbit/s (100 times higher) with a much higher packet rate as well and try to do the same with the top zoom window set to 5ms/. You'll see a contigous colored band. If you set the zoom window to 50us/ in order to see the packets a Siglent scope will shorten the memory depth and there is nothing you can do about it. You have a choice between either having long memory but not being able to see the packets in the zoom window OR seeing the packets but not have deep memory.
What is real reason for these lies?
This is handled many many times including document images etc. Only what Sig do not have is hardware decode with pros and cons. Yes it is slower to decode and also some limits with decode result length but also it can decode without real time live signal just afterwards..
-
You choose an example in which you can still see both signals on an oscilloscope with very little memory. Set the bitrate to 1Mbit/s (100 times higher) with a much higher packet rate as well and try to do the same with the top zoom window set to 5ms/. You'll see a contigous colored band. If you set the zoom window to 50us/ in order to see the packets a Siglent scope will shorten the memory depth and there is nothing you can do about it. You have a choice between either having long memory but not being able to see the packets in the zoom window OR seeing the packets but not have deep memory.
No it won't. I showed you example from my Pico where I sampled 100 MPoints in 200ms and shown it zoomed in to 20ns /div, zoom factor of 1M X. Yes, one million times.
Tautech posted one image above, where he got 50 MPoints at 20 ms/div (200 ms total) and is showing details at 20 us/div.
This is how it works but you don't seem to understand. On main timebase you grab big chunk of data, and zoom shows a subset of that, in such a detail that is only defined by sampling rate. Which will be limited by memory size.
But zooming in won't change anything from how timebase and sampling is set, only what are you looking at.
So you enable 100 MPoints, set timebase to use all 100 MPoints, and you can zoom in to every single point...
And zoom will not shorten or change anything.
What are you saying is SIMPLY NOT TRUTH. Just look at the overwhelming evidence shown here..
Sorry, but again you are not understanding the problem; you should try the steps I wrote on a Siglent or Lecroy oscilloscope and you'll see the limitations for yourself. You think you achieve the same but you don't. It is true there are many routes to Rome. You keep insisting the taking the long route to Rome is that same as taking the short route to Rome. That simply isn't true. It is no my fault you can't see the short route to Rome.
-
You choose an example in which you can still see both signals on an oscilloscope with very little memory. Set the bitrate to 1Mbit/s (100 times higher) with a much higher packet rate as well and try to do the same with the top zoom window set to 5ms/. You'll see a contigous colored band. If you set the zoom window to 50us/ in order to see the packets a Siglent scope will shorten the memory depth and there is nothing you can do about it. You have a choice between either having long memory but not being able to see the packets in the zoom window OR seeing the packets but not have deep memory.
No it won't. I showed you example from my Pico where I sampled 100 MPoints in 200ms and shown it zoomed in to 20ns /div, zoom factor of 1M X. Yes, one million times.
Tautech posted one image above, where he got 50 MPoints at 20 ms/div (200 ms total) and is showing details at 20 us/div.
This is how it works but you don't seem to understand. On main timebase you grab big chunk of data, and zoom shows a subset of that, in such a detail that is only defined by sampling rate. Which will be limited by memory size.
But zooming in won't change anything from how timebase and sampling is set, only what are you looking at.
So you enable 100 MPoints, set timebase to use all 100 MPoints, and you can zoom in to every single point...
And zoom will not shorten or change anything.
What are you saying is SIMPLY NOT TRUTH. Just look at the overwhelming evidence shown here..
Sorry, but again you are not understanding the problem; you should try the steps I wrote on a Siglent or Lecroy oscilloscope and you'll see the limitations for yourself. You think you achieve the same but you don't. It is true there are many routes to Rome. You keep insisting the taking the long route to Rome is that same as taking the short route to Rome. That simply isn't true. It is no my fault you can't see the short route to Rome.
I think there are people full of good will who try to understand with the support of screenshots.
So I believe the best thing to make yourself understood is that you make a capture with your manual memory depth capable R&S or GW Instek and you do the same with your Lecroy in a scenario where clearly demonstrates the difference between the two memory management implementation.
So that everyone understands without ambiguity.
I know it takes time, but it could reduce the 100-year war and save millions of lives.
-
Dave's video already shows the "problem" explicitly (at least for my knowledge level).
The rest of the rumblings are different ways of explaining the thing (with more or less expert details) but, in the end, after all the juice has been squeezed, all come down to the same.
Those that disagree with this analysis, have misunderstood the simplicity of the bad/wrong (strike the one that makes you itchy) implementation that Dave's has showed in the video.
-
Dave's video already shows the "problem" explicitly (at least for my knowledge level).
The rest of the rumblings are different ways of explaining the thing (with more or less expert details) but, in the end, after all the juice has been squeezed, all come down to the same.
Those that disagree with this analysis, have misunderstood the simplicity of the bad/wrong (strike the one that makes you itchy) implementation that Dave's has showed in the video.
Yes, I think everyone has understood the problem since Dave posted the video.
But this is a problem that has been discussed here for years, often on the initiative of nctnico when we talk about the operation or the choice of an oscilloscope but rarely with a demonstration as explicit as Dave's one.
Despite this, there still seems to be misunderstandings between some here and on the real impact on real cases.
It would be great if nctnico could show us a case that we can solve with a GW Instek or an R&S and that we cannot with a Siglent or a Lecroy or with or with more steps or less efficiency.
-
It's not about can or can not, it's about the time it takes. You can decode serial data even without the scope doing it. It just takes longer.
-
You choose an example in which you can still see both signals on an oscilloscope with very little memory. Set the bitrate to 1Mbit/s (100 times higher) with a much higher packet rate as well and try to do the same with the top zoom window set to 5ms/. You'll see a contigous colored band. If you set the zoom window to 50us/ in order to see the packets a Siglent scope will shorten the memory depth and there is nothing you can do about it. You have a choice between either having long memory but not being able to see the packets in the zoom window OR seeing the packets but not have deep memory.
No it won't. I showed you example from my Pico where I sampled 100 MPoints in 200ms and shown it zoomed in to 20ns /div, zoom factor of 1M X. Yes, one million times.
Tautech posted one image above, where he got 50 MPoints at 20 ms/div (200 ms total) and is showing details at 20 us/div.
This is how it works but you don't seem to understand. On main timebase you grab big chunk of data, and zoom shows a subset of that, in such a detail that is only defined by sampling rate. Which will be limited by memory size.
But zooming in won't change anything from how timebase and sampling is set, only what are you looking at.
So you enable 100 MPoints, set timebase to use all 100 MPoints, and you can zoom in to every single point...
And zoom will not shorten or change anything.
What are you saying is SIMPLY NOT TRUTH. Just look at the overwhelming evidence shown here..
Sorry, but again you are not understanding the problem; you should try the steps I wrote on a Siglent or Lecroy oscilloscope and you'll see the limitations for yourself. You think you achieve the same but you don't. It is true there are many routes to Rome. You keep insisting the taking the long route to Rome is that same as taking the short route to Rome. That simply isn't true. It is no my fault you can't see the short route to Rome.
I DID show you that I accomplish the same with Picoscope.. With 1 million factor zoom.. Simultaneously capturing 100 Mpoints of data with 500 MS/sec and at the same time looking at it at trigger point (or any other point relative to trigger) at 20 ns /div.... Here it is 10 ms/div timebase , looking at it at 1,2 us/div, while simultaneously decoding 100 Mpoints worth of data sampled at 1GS/sec.
[attachimg=1]
If I wanted to speculate I would simply think that you don't know how to use zoom properly, so you didn't set timebase to long enough before pressing zoom.
Or that you did try that on some previous Siglent scope that DID behave like this, and had some weird behaviour.
That would explain why are you so adamant at repeating what is proven (with images) that is not true.
Entering zoom mode doesn't change any of parameter of sampling that is set previously with max mem depth and timebase. It simply opens new view to buffer with separate time axis on which it plots smaller subset of data on different time axis from timebase.
-
It would be great if nctnico could show us a case that we can solve with a GW Instek or an R&S and that we cannot with a Siglent or a Lecroy or with or with more steps or less efficiency.
That is another matter and goes deeply into each other's way of using a scope. Based on all the information in this forum it's perfectly clear that it will never be a consensus in the way people use a so generic instrument as a scope is. And, specially, people with lots of experience and accustomed to use it in a certain way.
Of course, it's not only about the people's way but also the type of signal analysis and/or glitches that are being searched that influence the best way to handle the scope.
If Siglent corrects this "quirk" i'm sure it will not be only nctnico that will be happy :). That will benefit even the current Siglent advocates! And some/many of them have yet to understand that benefit.
-
Dave's video already shows the "problem" explicitly (at least for my knowledge level).
The rest of the rumblings are different ways of explaining the thing (with more or less expert details) but, in the end, after all the juice has been squeezed, all come down to the same.
Those that disagree with this analysis, have misunderstood the simplicity of the bad/wrong (strike the one that makes you itchy) implementation that Dave's has showed in the video.
What Dave have shown is good explanation how Siglent scope works. I agree that they should add manual memory management if they can, just because. It can't hurt.
I'm not disagreeing with Dave's findings.
I'm fine with the fact that Nico uses something and it works for him.
My problem with Nico's interpretation is that he keeps saying things that are simply not true... I show example with 1 million zoom factor that disproves his statements, he says that if I chose different timebase it would be different. It wouldn't. I know how my scope works, I'm the one that use it on daily basis. He says Siglent scopes can't show zoomed data without losing detail few posts down from image from Elasia that clearly shows it can do it.. I really don't care much for that.
I know I can be very stubborn sometimes. Not very often, but I simply cannot stand that incorrect is being sold as correct by repetition, false argumentation and misdirection.
It ain't truth. Simple as that. I can stop, but it will never be truth. Never.
-
Still rolling on... different scopes word differently! OMG! None of them is perfect and there isn't one true way to manage memory. Let the users pick what they want, rather than insisting others should blindly believe your ways are best.
-
Dave's video already shows the "problem" explicitly (at least for my knowledge level).
The rest of the rumblings are different ways of explaining the thing (with more or less expert details) but, in the end, after all the juice has been squeezed, all come down to the same.
Those that disagree with this analysis, have misunderstood the simplicity of the bad/wrong (strike the one that makes you itchy) implementation that Dave's has showed in the video.
What Dave have shown is good explanation how Siglent scope works. I agree that they should add manual memory management if they can, just because. It can't hurt.
I'm not disagreeing with Dave's findings.
I'm fine with the fact that Nico uses something and it works for him.
My problem with Nico's interpretation is that he keeps saying things that are simply not true... I show example with 1 million zoom factor that disproves his statements, he says that if I chose different timebase it would be different. It wouldn't. I know how my scope works, I'm the one that use it on daily basis. He says Siglent scopes can't show zoomed data without losing detail few posts down from image from Elasia that clearly shows it can do it.. I really don't care much for that.
I know I can be very stubborn sometimes. Not very often, but I simply cannot stand that incorrect is being sold as correct by repetition, false argumentation and misdirection.
And it doesn't occur to you that you are simply misunderstanding what I'm trying to point out? I know I'm not the best one to explain things so it is not entirely your fault. I don't know how I can get you to see the subtle nuances you are missing -again my shortcoming-. You using other oscilloscopes besides one from Siglent doesn't help either because the behaviour this thread is about is very specific for how auto memory length works. However saying people tell lies because you don't understand their point is not the smartest move to make.
-
Still rolling on... different scopes word differently! OMG! None of them is perfect and there isn't one true way to manage memory. Let the users pick what they want, rather than insisting others should blindly believe your ways are best.
:horse: :rant: :horse: :palm:
-
Dave's video already shows the "problem" explicitly (at least for my knowledge level).
The rest of the rumblings are different ways of explaining the thing (with more or less expert details) but, in the end, after all the juice has been squeezed, all come down to the same.
Those that disagree with this analysis, have misunderstood the simplicity of the bad/wrong (strike the one that makes you itchy) implementation that Dave's has showed in the video.
What Dave have shown is good explanation how Siglent scope works. I agree that they should add manual memory management if they can, just because. It can't hurt.
I'm not disagreeing with Dave's findings.
I'm fine with the fact that Nico uses something and it works for him.
My problem with Nico's interpretation is that he keeps saying things that are simply not true... I show example with 1 million zoom factor that disproves his statements, he says that if I chose different timebase it would be different. It wouldn't. I know how my scope works, I'm the one that use it on daily basis. He says Siglent scopes can't show zoomed data without losing detail few posts down from image from Elasia that clearly shows it can do it.. I really don't care much for that.
I know I can be very stubborn sometimes. Not very often, but I simply cannot stand that incorrect is being sold as correct by repetition, false argumentation and misdirection.
And it doesn't occur to you that you are simply misunderstanding what I'm trying to point out? I know I'm not the best one to explain things so it is not entirely your fault. I don't know how I can get you to see the subtle nuances you are missing -again my shortcoming-. You using other oscilloscopes besides one from Siglent doesn't help either because the behaviour this thread is about is very specific for how auto memory length works. However saying people tell lies because you don't understand their point is not the smartest move to make.
You've continually made "can't be done" statements without putting all the conditions/assumptions required to back that up.
Between you and Dave its just another fanboy rant at this stage.
-
I stated the exact conditions several times in several way so you can try it yourself. But be aware that this is expert equipment use. Like pro-athletes who need shoes that have a tiny, insignificant looking tweak that makes all the difference between losing and winning. Anyway, there is not much need for further discussion. It appears Siglent is working on adding new features to the memory management so you can force full memory depth. At least they see and understand the value and that is all that matters. (Hopefully) we end up with more oscilloscopes to choose from so mission accomplised.
As tv84 put it so elegantly: That will benefit even the current Siglent advocates! And some/many of them have yet to understand that benefit.
Or let's pull in a quote from Albert Einstein. He wasn't so subtle:
Great spirits have always encountered violent opposition from mediocre minds. >:D
-
Great spirits have always encountered violent opposition from mediocre minds. >:D
Story of my life... i swear i spend more time just stirring up hornet nests lol
but noooo we cant do xyz! ... bullshit :horse: :horse: :horse: :-DD
-
It would be great if nctnico could show us a case that we can solve with a GW Instek or an R&S and that we cannot with a Siglent or a Lecroy or with or with more steps or less efficiency.
That is another matter and goes deeply into each other's way of using a scope. Based on all the information in this forum it's perfectly clear that it will never be a consensus in the way people use a so generic instrument as a scope is. And, specially, people with lots of experience and accustomed to use it in a certain way.
Of course, it's not only about the people's way but also the type of signal analysis and/or glitches that are being searched that influence the best way to handle the scope.
If Siglent corrects this "quirk" i'm sure it will not be only nctnico that will be happy :). That will benefit even the current Siglent advocates! And some/many of them have yet to understand that benefit.
Yes it's true that it's a bit off topic, but Dave's video shows that a problem discussed here in tens of threads for several years can be summed up in a single video.
I understood ( I hope... ) the test nctnico wants to make to show that the automatic management on the Siglent doesn't allows (for example) to look at a high bitrate packet in both the top zoomed window and the bottom window AND then look at another position WITHOUT having to recapture.
This is an example he found, I think, to make it clear that the use of the zoom function on the Siglent doesn't completely resolve the lack of manual memory management.
Now we are approaching 20 pages with some misunderstandings that still persist.
All this blabla to say that until we haven't some sort of standart test plan / benchmark to see how different oscilloscopes work with exactly the same settings and signals, I still think that a screenshot or a small video or a gif can be much more explicit than dozens replies more or less well written with more or less diplomacy ;D
-
show that the automatic management on the Siglent doesn't allows (for example) to look at a high bitrate packet in both the top zoomed window and the bottom window AND then look at another position WITHOUT having to recapture.
Yet they do that without fault !
All the primary timebase record can be panned through from within the zoomed window.
And Navigate to any time position in the capture too.
An example of the required setup posted in another thread:
(https://www.eevblog.com/forum/blog/eevblog-1312-siglent-oscilloscopes-crippling-history-mode!/?action=dlattach;attach=1003482)
-
Yet [Siglent scopes] do that without fault !
Huh! I thought the simple conclusion that Dave came to was that Siglent scopes don't give users the option to manually make some of the vast amount of memory available to enable the ability to zoom out - furthermore Tautech actually told us that Siglent were working on the problem - or did I miss something?
Here we go again, the Siglent dealer chiming in to try to convert us non-believers that Siglent already does what we need, we just have to drink more Koolaid and watch while Tautech walks across water without sinking deeper than his ankles.
FFS, can't we just give it a break? As jemangedeslolos says, Dave has summed everything up in a simple video.
:horse:
-
Yet they do that without fault !
All the primary timebase record can be panned through from within the zoomed window.
And Navigate to any time position in the capture too.
An example of the required setup posted in another thread:
(https://www.eevblog.com/forum/blog/eevblog-1312-siglent-oscilloscopes-crippling-history-mode!/?action=dlattach;attach=1003482)
I know my english is bad but if you try to decrypt, it is not quite exactly what ntcnico suggests.
You can only see beautiful colors on the top window but you cannot compare this signal with the signal zoomed in the bottom window.
The "dual time base" thing on analog scope that ntcnico is trying to explain.
If you choose very close timebase, you will see the problem.
-
Yet they do that without fault !
All the primary timebase record can be panned through from within the zoomed window.
And Navigate to any time position in the capture too.
An example of the required setup posted in another thread:
(https://www.eevblog.com/forum/blog/eevblog-1312-siglent-oscilloscopes-crippling-history-mode!/?action=dlattach;attach=1003482)
I know my english is bad but if you try to decrypt, it is not quite exactly what ntcnico suggests.
You can only see beautiful colors on the top window but you cannot compare this signal with the signal zoomed in the bottom window.
The "dual time base" thing on analog scope that ntcnico is trying to explain.
If you choose very close timebase, you will see the problem.
Yes in this case the zoomed timebase is not large enough to show the portion from which it is taken although the H Pos trigger pointer and the zoom time marker (73.6us) indicate the main zoom window reference to the 0s position in the capture.
Is that not clearly enough marked ?
Oh and have a look at the video I linked in this post:
https://www.eevblog.com/forum/blog/eevblog-1312-siglent-oscilloscopes-crippling-history-mode (https://www.eevblog.com/forum/blog/eevblog-1312-siglent-oscilloscopes-crippling-history-mode)!/msg3097466/#msg3097466
-
Ok, me either I can't seem to make myself understood.
I'm going to take Gandalf_Sr's advice and take a break ;D
-
jemangedeslolos
I feel you English is rather good, far better in fact than a lot of my compatriots :clap:
Managed the same result on the Rigol MSO8000 only the capture time was far longer due to the 500Mpts of memory.
However still had to manually set the acquire <> Memory depth to max and single shot capture.
This I am absolutely convinced is due to the way manufactures prioritise the feature with the memory, capture rates and implementation of how its done. In the marketing blurb. This *may* then cause conflicts within the certain aspects of the way the scope works with other functions. However Siglent should give you a working option to adjust and turn off this memory feature just my observation
-
show that the automatic management on the Siglent doesn't allows (for example) to look at a high bitrate packet in both the top zoomed window and the bottom window AND then look at another position WITHOUT having to recapture.
Yet they do that without fault !
All the primary timebase record can be panned through from within the zoomed window.
And Navigate to any time position in the capture too.
An example of the required setup posted in another thread:
(https://www.eevblog.com/forum/blog/eevblog-1312-siglent-oscilloscopes-crippling-history-mode!/?action=dlattach;attach=1003482)
This is clear and ok.
But IF we need long capture where is zoomed in main window and then zoomed in zoom window or not more zoomed in zoom window but different position in whole capture.
Oscilloscope what works full window zoom mode and have normal window split zoom can do it.
main window is zoomed in window to whole capture length. Zoom window is same time scale than main window or zoomed in more. So there is three things. 1. Whole capture length, over display width. 2. Main window what show more or less "zoomed in" part of this depending time scale and memory length. 3. Then there is what we normally call zoom window, what can normally be same time scale what main window or more short part of it aka zoomed in".
With this kind of working principle it is possible to look two separate zoomed in part from whole memory length. But usually in runtime can not see (in this case) whole memory at once on screen without hidden parts.
Of course also this fixed memory length principle where main window is some time slice from whole memory (full window zoom mode principle) can do better but display size is real bottle neck for make dual independent zoom window both with own independent timebase (time scale) and both with fully independent time position related to reference point what can be trigger position and also trigger position fully free to set what ever position in whole memory length or out from capture memory and so on.
-
Or let's pull in a quote from Albert Einstein. He wasn't so subtle:
Great spirits have always encountered violent opposition from mediocre minds. >:D
Oh I get it now.. Your'e Albert Einstein and I'm mediocre mind... Sorry it took me so long to get it... But that explains it...
But I gotta give you , you do have great sense of humour.. ^-^
-
So, I was thinking long and hard ( and me being not very smart it is kinda slow process ).
If you set manual sample memory to 100 Mpoints.
You set timebase to 1 ms/div.
At 1GS/sec you will have 100 ms worth of data in memory, 10 ms on the screen.
And then you zoom in separate window to 20 ns/div.
That will give you effect of TRIPLE timebase. Full length sampled at one length (not visible on screen but in memory), a intermediate length in main window (that you freely move around inside sampled data with normal timebase controls) and a third time length in second window (zoom window, that you move around with zoom controls).
To accomplish that effect on scope without manual memory, you would need TWO independent zoom windows:
[attachimg=1]
I can see how that might be useful sometimes, on a scope without multiple zoom windows..
-
So, I was thinking long and hard ( and me being not very smart it is kinda slow process ).
If you set manual sample memory to 100 Mpoints.
You set timebase to 1 ms/div.
At 1GS/sec you will have 100 ms worth of data in memory, 10 ms on the screen.
And then you zoom in separate window to 20 ns/div.
That will give you effect of TRIPLE timebase. Full length sampled at one length (not visible on screen but in memory), a intermediate length in main window (that you freely move around inside sampled data with normal timebase controls) and a third time length in second window (zoom window, that you move around with zoom controls).
To accomplish that effect on scope without manual memory, you would need TWO independent zoom windows:
(Attachment Link)
I can see how that might be useful sometimes, on a scope without multiple zoom windows..
Exactly what I tried explain in my last post (answering to Tautech).
Many scopes can do this partially. In runtime they can show, without zoom function open, just full window "zoomed in" part from whole length and with selected time scale.
When zoom window function open they can show same part of signal using more fast time scale or some other part from whole memory length with same or more fast time scale than main window. Just like I previously told.
1. Whole length with its time scale as main window time scale so there is not 3 time scales, only two (but many scopes in normal mode do not show this whole signal length in display except small bar graph top part of scree.)
2. Zoomed in main window with user selected time scale (main t/div setting) what is just this normal screen. Only that we do not normally say it is "zoomed in" display. Many scopes work normally in this full window zoomed mode with more or less part of capture is outside of screen what can not see in runtime, just visually blind.
3. Zoom function in use, screen vertically splitted. Same or more zoomed in part of signal in "zoom window"
If all are born in digital scopes era without anything about analog scopes, do we still talk about timebase when we talk oscilloscopes UI settings. Perhaps not. We perhaps talk about time scale as vertical, example voltage or current etc scale.
In this kind of "normal" scope there can be two visible window what shoe part of whole capture length (if scope is in this working mode) 1st is based to memory length in use and samples interval but I think it is wrong to say it have different third time base aka horizontal time scale. It have this time scale what we set when we are looking it. Even if length is 10ms and our main window have 10 divisions and our setup is 1ns/div and our window to 10ms long captured signal is only 10 ns slice and 9999990 not visible in runtime. Oh well, runtime can zoom out, and set 1ms/div and see whole length (if scope do not force overlap)
Cheap solution is add fixed memory length function as usually is in many many scopes - and is still also in some Siglent more old oscilloscopes so it can not say Siglent do not know what it is. Even more, some older Siglent scopes have Dual Independent time scale horizontal alternate mode with independent dual trigger system what is very rare. And fixed memory length with normal main window zoom and split window zoom.
How to keep whole user selected memory length visible, if user want, on screen and least two separate different time scale and position sub windows on screen... this is challenge. If there need be full freedom for set time scales in both sub window and fully free time position for both, this need different hardware.
Why do like others, walk your own road, Siglent! Plese let us see dual independent time scale aand position "zoom" windows with full length diaplay with user selectable fixed length or autoselected memory length where user can set limits and or force sample interval.
Also please add true dual independent time scale axis mode (noy alternate) with independent triggers for both (principle like in Siglent old SDS1000CML what have dual timescale independent trigger alternate mode), so that it can work least with two channels simultaneously and what can imitate (poorly but somehow) real dual independent beam scope. It was not mistake when in history Tektronix made 7844 dual beam model.
Scopes what have dual fully separate ADC and dual memory like 4 channel Siglents have good change to do it.
-
I have to wonder how much of this would infringe on lecroy and is actually no compete locked away
-
Just asked them now via email.
And got an answer.
After asking them twice or triple without reaction if I could do that, I let the bomb drop:
They´re working about, it´s on their to do list.
Will surely not come with the next update because of the complexity of the thing.
And I hope they won´t do a fast shot, but at last:
This is siglent, they take user/customers reactions seriously, one step more to become an A brand.
-
This is siglent, they take user/customers reactions seriously,...
Of course seriously. All money, what Siglent may get is in customers pocket.
Btw, continuous around 15% investment to research and product developing from sales is not very bad.
;)
-
Hi. Does anybody know if this is going to be fixed and changed to like the majority of scopes work.
I know we can work around but even if its just a design choice, its not practical. Changing time base and capturing just to be able to see longer capture is counter intuitive when one has the memory setting. Also what if someone wants to stop after seeing something on the screen.
This serious limitation or bad design choice can be deal breaker for me.
So any chance this is going to change in any FW update
-
It's been a long standing implementation of capture strategy by LeCroy, Pico scope and Siglent all of which are respected brands in their respective fields.
It allows more power to the user other than in corner use cases.
AFAIK it's still on a low priority list for Siglent to modify to suit those that can't/won't adapt to a different way of reaching the same result.
-
It's been a long standing implementation of capture strategy by LeCroy, Pico scope and Siglent all of which are respected brands in their respective fields.
It allows more power to the user other than in corner use cases.
AFAIK it's still on a low priority list for Siglent to modify to suit those that can't/won't adapt to a different way of reaching the same result.
Thanks for the reply
BTW what is the more power this choice brings. Do you mean history?
-
It's been a long standing implementation of capture strategy by LeCroy, Pico scope and Siglent all of which are respected brands in their respective fields.
It allows more power to the user other than in corner use cases.
AFAIK it's still on a low priority list for Siglent to modify to suit those that can't/won't adapt to a different way of reaching the same result.
Thanks for the reply
BTW what is the more power this choice brings. Do you mean history?
Not only History as a larger total memory depth that some DSO's offer allows for longer/greater detail captures than those DSO's with small memory depth common in DSO's that are optimized for zoom out and allow inspection of what is not already on the display.
You may have seen Dave zoom out the timebase and find the limits to what is possible however with a capture 'long' and zoom in this handicap is then avoided.
Scopes that have a sensible Zoom window ratio like the SDS2104X Plus screenshot earlier on this page allow for the full memory to be used for the primary window without impacting largely on the zoomed 'working' window size and with a touch display like X Plus has we can pan across the full primary display record from within the zoomed display with a finger.
DSO's that display their full acquisition information on the display allow us, the user and boss of the instrument to make informed decisions of how best to operate it.
-
I assume all the siglent scopes are designed this way e.g. 1104x-e. Right?
-
I assume all the siglent scopes are designed this way e.g. 1104x-e. Right?
I mean to ask with respect to the zoom out/history functionality that I asked about in my previous questions?
So all the current siglents behave the same way?
-
I assume all the siglent scopes are designed this way e.g. 1104x-e. Right?
I mean to ask with respect to the zoom out/history functionality that I asked about in my previous questions?
So all the current siglents behave the same way?
Yes, it's Siglent's, LeCroy's and Picoscope's design philosophy as zooming in is a more powerful use of a deep memory architecture than zooming out.
There is a bigger picture to consider why some DSO's are this way as sampling rate, memory depth and WFPS rate are all somewhat dependant on one another and careful study of datasheets can reveal how all brands make tradeoffs in their designs to maximise performance.
None are 100% right or wrong only different to operate and get the best from.
However a deep memory DSO is highly desirable in order to have the greatest versatility.
-
Yes you can stop and after then zoom out and look if there is...
(https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/?action=dlattach;attach=1184812;image)
But I want more... So I turn to this road...
Just because I want more. And -- because I know where is more.
(https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/?action=dlattach;attach=1184816;image)
It is difficult to understand how some believe they get more if this upper part of image is hidden and exchanged with some nearly nonsense horizontal bargraph. Or I just have to learn to see the emperor’s new clothes and know how to praise them.
-
I assume all the siglent scopes are designed this way e.g. 1104x-e. Right?
I mean to ask with respect to the zoom out/history functionality that I asked about in my previous questions?
So all the current siglents behave the same way?
Yes, it's Siglent's, LeCroy's and Picoscope's design philosophy as zooming in is a more powerful use of a deep memory architecture than zooming out.
There is a bigger picture to consider why some DSO's are this way as sampling rate, memory depth and WFPS rate are all somewhat dependant on one another and careful study of datasheets can reveal how all brands make tradeoffs in their designs to maximise performance.
None are 100% right or wrong only different to operate and get the best from.
However a deep memory DSO is highly desirable in order to have the greatest versatility.
Now you are contradicting yourself. Not being able to zoom out lessens the versatility and seriously slows down some type of measurements. And I repeat: there is no trade-off to be made to support zooming out. R&S shows that by supporting all acquisition modes.
It is similar to driving a car with a very wide turning circle. Such a car is difficult to drive in places with narrow streets (narrow corners, turning around, parking, etc). Some people never run into situations where it is a problem, some people don't know/care and will move forward/backward many times and others will see the limitation for what it is and buy a different car to drive around more easely.
@rf-loop: you don't need zoom mode to know there is more. For many types of measurements you know there is more and what the signal should look like. It is just that you are not making such measurements and thus don't understand why zooming out is such an important feature for other people. IOW: Zooming out is an important feature but you just don't understand why. On top of that you make a fool out of yourself by ridiculing other people's workflow.
-
I assume all the siglent scopes are designed this way e.g. 1104x-e. Right?
I mean to ask with respect to the zoom out/history functionality that I asked about in my previous questions?
So all the current siglents behave the same way?
Yes, it's Siglent's, LeCroy's and Picoscope's design philosophy as zooming in is a more powerful use of a deep memory architecture than zooming out.
There is a bigger picture to consider why some DSO's are this way as sampling rate, memory depth and WFPS rate are all somewhat dependant on one another and careful study of datasheets can reveal how all brands make tradeoffs in their designs to maximise performance.
None are 100% right or wrong only different to operate and get the best from.
However a deep memory DSO is highly desirable in order to have the greatest versatility.
Now you are contradicting yourself. Not being able to zoom out lessens the versatility and seriously slows down some type of measurements. And I repeat: there is no trade-off to be made to support zooming out. R&S shows that by supporting all acquisition modes.
It is similar to driving a car with a very wide turning circle. Such a car is difficult to drive in places with narrow streets (narrow corners, turning around, parking, etc). Some people never run into situations where it is a problem, some people don't know/care and will move forward/backward many times and others will see the limitation for what it is and buy a different car to drive around more easely.
@rf-loop: you don't need zoom mode to know there is more. For many types of measurements you know there is more and what the signal should look like. It is just that you are not making such measurements and thus don't understand why zooming out is such an important feature for other people.
|O |O |O
I think you know it is actually full window zoom and nothing else what you admire so much. Is it better to also show this whole together this zoomed part. What you loose when it is displayed. Nothing. Except if you are after this KS wfm speed hype. In other side there is zero loose and other side there is you can get more.
But this discuss will never stop, you can keep your way to use oscilloscopes and be happy with it. Every user is right if he is perfectly satisfied scope meet his needs and deep-rooted ways of using it. //
-
You forgot to quote: On top of that you make a fool out of yourself by ridiculing other people's workflow.
-
You forgot to quote: On top of that you make a fool out of yourself by ridiculing other people's workflow.
I appreciate your opinion very much.
-
I assume all the siglent scopes are designed this way e.g. 1104x-e. Right?
I mean to ask with respect to the zoom out/history functionality that I asked about in my previous questions?
So all the current siglents behave the same way?
Yes, it's Siglent's, LeCroy's and Picoscope's design philosophy as zooming in is a more powerful use of a deep memory architecture than zooming out.
There is a bigger picture to consider why some DSO's are this way as sampling rate, memory depth and WFPS rate are all somewhat dependant on one another and careful study of datasheets can reveal how all brands make tradeoffs in their designs to maximise performance.
None are 100% right or wrong only different to operate and get the best from.
However a deep memory DSO is highly desirable in order to have the greatest versatility.
Now you are contradicting yourself. Not being able to zoom out lessens the versatility and seriously slows down some type of measurements. And I repeat: there is no trade-off to be made to support zooming out. R&S shows that by supporting all acquisition modes.
It is clear you do not understand the tradeoffs when they are quite clear in a R&S datasheet.
Study enough datasheets with the knowledge of how different brands do capture management strategy when using ADC/FPGA's and the tradeoffs stick out like a sore thumb but they are best left for the observant reader to discover for themselves.
This is not about brands but design architecture and implementation.
Maybe take a deep breath and read and fully comprehend my post above.
-
I assume all the siglent scopes are designed this way e.g. 1104x-e. Right?
I mean to ask with respect to the zoom out/history functionality that I asked about in my previous questions?
So all the current siglents behave the same way?
Yes, it's Siglent's, LeCroy's and Picoscope's design philosophy as zooming in is a more powerful use of a deep memory architecture than zooming out.
There is a bigger picture to consider why some DSO's are this way as sampling rate, memory depth and WFPS rate are all somewhat dependant on one another and careful study of datasheets can reveal how all brands make tradeoffs in their designs to maximise performance.
None are 100% right or wrong only different to operate and get the best from.
However a deep memory DSO is highly desirable in order to have the greatest versatility.
Now you are contradicting yourself. Not being able to zoom out lessens the versatility and seriously slows down some type of measurements. And I repeat: there is no trade-off to be made to support zooming out. R&S shows that by supporting all acquisition modes.
It is clear you do not understand the tradeoffs when they are quite clear in a R&S datasheet.
Please point them out and I can tell you exactly where your error is. There is absolutely nothing Siglent's memory management can do which the R&S scopes (RTB2k, RTM3k and RTA4k) can't.
Edit: two days later and still no explaination from tautech on how Siglent's memory management is better compared to that found in R&S scopes (which caters all modes). 8)
-
Ok, me either I can't seem to make myself understood.
Some people simply don't want to listen.
They put their hands on their ears and go "nananananananananana" when sombody says that Siglents aren't gifts from the gods.
Me? I say there's no excuse for not filling the entire memory when the 'scope is stopped.
-
It's been a long standing implementation of capture strategy by LeCroy, Pico scope and Siglent all of which are respected brands in their respective fields.
It allows more power to the user other than in corner use cases.
AFAIK it's still on a low priority list for Siglent to modify to suit those that can't/won't adapt to a different way of reaching the same result.
Not having a Siglent/LeCroy/Pico, I can't comment on the practicality aspects between Zoom In and Zoom Out, but this latest skirmish highlights Siglent's decision to not change the behaviour of their Mem Depth setting from "Maximum usable memory" to "User set memory" - IMHO a non-catastrophic bug, but still a bug.
Yes you can stop and after then zoom out and look if there is...It is difficult to understand how some believe they get more if this upper part of image is hidden and exchanged with some nearly nonsense horizontal bargraph. Or I just have to learn to see the emperor’s new clothes and know how to praise them.
rf-loop, is there a way to resize/collapse this top zoomed out part? If negative, then I am on the camp that prefers the "nearly nonsense horizontal bargraph" - I have more space to look at the waveform.
-
It's been a long standing implementation of capture strategy by LeCroy, Pico scope and Siglent all of which are respected brands in their respective fields.
It allows more power to the user other than in corner use cases.
AFAIK it's still on a low priority list for Siglent to modify to suit those that can't/won't adapt to a different way of reaching the same result.
Not having a Siglent/LeCroy/Pico, I can't comment on the practicality aspects between Zoom In and Zoom Out, but this latest skirmish highlights Siglent's decision to not change the behaviour of their Mem Depth setting from "Maximum usable memory" to "User set memory" - IMHO a non-catastrophic bug, but still a bug.
No it's a design decision and for good reason and common to all 3 brands.
Any change to current behaviour could impact on specifications optimised by the current design philosophy.
-
It's been a long standing implementation of capture strategy by LeCroy, Pico scope and Siglent all of which are respected brands in their respective fields.
It allows more power to the user other than in corner use cases.
AFAIK it's still on a low priority list for Siglent to modify to suit those that can't/won't adapt to a different way of reaching the same result.
Not having a Siglent/LeCroy/Pico, I can't comment on the practicality aspects between Zoom In and Zoom Out, but this latest skirmish highlights Siglent's decision to not change the behaviour of their Mem Depth setting from "Maximum usable memory" to "User set memory" - IMHO a non-catastrophic bug, but still a bug.
No it's a design decision and for good reason and common to all 3 brands.
Any change to current behaviour could impact on specifications optimised by the current design philosophy.
No, it doesn't (and not only on Siglent but also for Lecroy and Picoscope scopes). That is the real kicker! So quit the marketing BS. Nobody is buying it. You can't even explain what the benefit is of this so called 'design choice' is anyway.
The reason I know that there are no downsides to adding 'zoom out' is because I have designed & build oscilloscope (like) data acquisition systems.
-
It's been a long standing implementation of capture strategy by LeCroy, Pico scope and Siglent all of which are respected brands in their respective fields.
It allows more power to the user other than in corner use cases.
AFAIK it's still on a low priority list for Siglent to modify to suit those that can't/won't adapt to a different way of reaching the same result.
Not having a Siglent/LeCroy/Pico, I can't comment on the practicality aspects between Zoom In and Zoom Out, but this latest skirmish highlights Siglent's decision to not change the behaviour of their Mem Depth setting from "Maximum usable memory" to "User set memory" - IMHO a non-catastrophic bug, but still a bug.
No it's a design decision and for good reason and common to all 3 brands.
Any change to current behaviour could impact on specifications optimised by the current design philosophy.
No, it doesn't (and not only on Siglent but also for Lecroy and Picoscope scopes). That is the real kicker! So quit the marketing BS. Nobody is buying it. You can't even explain what the benefit is of this so called 'design choice' is anyway.
The reason I know that there are no downsides to adding 'zoom out' is because I have designed & build oscilloscope (like) data acquisition systems.
Well, it is a design philosophy, by choice, which defines architecture. And you cannot know how easy is to add something to already released product, unless it is you who designed it or have privileged knowledge.
And I highly doubt what you designed some time ago was even close to complexity of SDS2000X+. And with that I don't mean you're not smart enough or something like that. Far from it. I simply don't think you had resources to undertake such a project and work on it for years doing nothing else. And with silicone available then. SDS2000X+ is a huge project.
To be honest, I don't know either whether it can be done or not or how "easy" it would be to implement this as an afterthought. Only Siglent does.
But what I do know, that it is not a problem per se. It is simply different way of working, and LeCroy, for instance, shows no intention to change it and customers are fine with it. They address usability the way I already explained to you several times, by having more flexible viewports and zoom windows. If SDS2000X+ would allow for zoom overview window to be shrunk to very small, you wouldn't even know you're in zoom window and would work the same as you do on your RTM3000. On my Picoscope I capture full timebase length by deciding I'm going to capture 200 ms, and then open as many different views I like, looking at different parts of waveform at different zoom settings at the same time. Beauty.. See attachment.
But to be honest, on SDS2000x+, when you enable zoom, what screen is left is still bigger than my whole screen on Keysight 3000T.. So yeah, not such a big deal....
Also, to repeat from before, better is better. If they can improve on this, so people like you can have it their way too, it is going to make it even better. But it is not a showstopper. It simply isn't perfect. Which (being perfect on entry level products) for some reason is not requirement for big brands like Keysight and R&S and LeCroy. They are allowed to make products that are deliberately limited for marketing purposes. With them it is business decisions and "small niggles". With Siglent and Rigol it's "crap I wouldn't buy"...
For instance, on your RTM3000, when you grab your full memory (the way you do it, because it supports that :-+), what do you do with it? How do you search through 400 MB of SPI or I2C messages?
You don't. Because of a small niggle that it doesn't even support that... You save data to the stick and take it to the PC and analyze it in Excel. To me that is not a workflow acceptable to me.
In my opinion, you would have been better off by buying Picoscope 6403E, and grab and analyze it directly on a PC. And what you have is a 9000€ scope when it is on special discount.
Your crusade over this "it works differently than what I am used to, so it must be wrong" is very much unimportant distraction over more important thing:
Will SDS2000X+ allow you to do more work and enable you to do stuff you cannot if you buy similarly priced DSOX1204G ?
Does DSOX1204G have:
- 10" touch screen
- histograms
- histicons
- trend plots
- low noise 500uV/div real hardware sensitivity.
- CAN FD trigger/decode
- 100 MPoints per ch (200 MPoint max interleaved)
- 50 Ohm inputs
- Zone trigering
- all the advance triggering modes
- 2 Mpoint FFT
- Multichannel FRA
- 16 digital channels (paid option, but it is there to be had if MSO is needed)
All of these are real advantages, directly usable every day and in every scenario. All of that makes this SDS20000X+ more like something between R&S RTB2000 and RTM3000, for the price of DSOX1204G...
Apart from this "I would like to use memory differently" niggle, it's a steal... In it's price range it is a king. Together with some compromises, still a price category winner.
And know what, funny thing, people that actually own it and use it have no problems with it. Funny that... Only armchair warriors that don't even own one have problems with it.
I do get it, it is different than what you're used to. And when I first tried ANY piece of equipment it felt weird. MSOX3000T is touted by people here as "best usability, most intuitive, easiest to use". That's crap. It's not. If you're coming from 10 years of using Tektronix, it won't be logical at all.. But few weeks later, after you memorize things by doing it, it feels natural. Same as people, saying, "Picoscope is weird, I cannot use scope on a PC". Yes you can, and it's fine. It's just different. And after you let yourself go of the biases, you realize how superior is sometimes to Keysight 3000T. for some type of work.
Regards,
Sinisa
-
No it's a design decision and for good reason and common to all 3 brands.
Any change to current behaviour could impact on specifications optimised by the current design philosophy.
So you'll have no problem explaining the benefits of this design choice, right?
-
It's been a long standing implementation of capture strategy by LeCroy, Pico scope and Siglent all of which are respected brands in their respective fields.
It allows more power to the user other than in corner use cases.
AFAIK it's still on a low priority list for Siglent to modify to suit those that can't/won't adapt to a different way of reaching the same result.
Not having a Siglent/LeCroy/Pico, I can't comment on the practicality aspects between Zoom In and Zoom Out, but this latest skirmish highlights Siglent's decision to not change the behaviour of their Mem Depth setting from "Maximum usable memory" to "User set memory" - IMHO a non-catastrophic bug, but still a bug.
No it's a design decision and for good reason and common to all 3 brands.
Any change to current behaviour could impact on specifications optimised by the current design philosophy.
No, it doesn't (and not only on Siglent but also for Lecroy and Picoscope scopes). That is the real kicker! So quit the marketing BS. Nobody is buying it. You can't even explain what the benefit is of this so called 'design choice' is anyway.
The reason I know that there are no downsides to adding 'zoom out' is because I have designed & build oscilloscope (like) data acquisition systems.
Well, it is a design philosophy, by choice, which defines architecture. And you cannot know how easy is to add something to already released product, unless it is you who designed it or have privileged knowledge.
It is not a design philosophy. Remember that zoom mode can be used to force use of all the memory while the oscilloscope still works the same. All Siglent needs to do is add a flag to the software which causes the memory length to be what the user selected and hide the zoom window. All the lower level logic is already present in the hardware and software. It is a UI change only. If Siglent makes this simple modification then they have a nearly ideal scope.
And for sure you can go raving on about other features but please read back to my 'wide turning circle car' example. Different people have different needs. I rarely (close to never) use search so for me this is not a deal breaker. However I'm not going to ridicule you for 'search on protocol decoding' being a deal breaker for you. I respect your needs so please respect mine. For me no 'zoom out' is a deal breaker because I use it often. Als note that I have owned a Siglent scope and not having the 'zoom out' mode enabled permanently annoyed the hell out of me.
-
It is not a design philosophy. Remember that zoom mode can be used to force use of all the memory while the oscilloscope still works the same. All Siglent needs to do is add a flag to the software which causes the memory length to be what the user selected and hide the zoom window.
Yep. No changes are needed at all. If it can capture the full memory when it's zoomed out then it can capture the full memory when it's zoomed in. No parameters have changed.
It's probably more work to not fill the whole memory.
-
It is not a design philosophy. Remember that zoom mode can be used to force use of all the memory while the oscilloscope still works the same. All Siglent needs to do is add a flag to the software which causes the memory length to be what the user selected and hide the zoom window. All the lower level logic is already present in the hardware and software. It is a UI change only. If Siglent makes this simple modification then they have a nearly ideal scope.
And for sure you can go raving on about other features but please read back to my 'wide turning circle car' example. Different people have different needs. I rarely (close to never) use search so for me this is not a deal breaker. However I'm not going to ridicule you for 'search on protocol decoding' to be a deal breaker for you. I respect your needs so please respect mine.
I'm not raving when it's facts. Unfortunately, it is hard for me to express myself very concisely in a foreign language. So I do generate lots of words.. Sorry for that.
You cannot ridicule me for for 'search on protocol decoding' because that is valid point and very much important. What you propose is special case of optimization that is, while can be nice in your specific case , which I agree, is not a deal breaker, because it can be accomplished to the full if you sacrifice a little bit of (very large) screen. Not being able to do something at all and being able to do something but with small compromises is a big difference. Big difference.
Is it ideal ? No. Would it be nice if they did this? Sure.
I couldn't care less, but they would gain potential new customers that do care. Win-Win.
But as thousands of buying customers that voted with their money show, it isn't a priority. They can't make them as fast as they sell.. So obviously, it is not a big deal.
I'm not ridiculing you. After lengthy discussion before, when I finally understood what you meant about this, I did concur that it might have merit in some cases, and that it is a valid request. But I do not consider it basic requirement, but more of refinement. For the record, my opinion was to add it if possible. Just, not very high priority, because it is scope in active development and some other stuff is higher priority. That is all.
And I'm sure that Siglent will be pleased with your comment: " If Siglent makes this simple modification then they have a nearly ideal scope." That is actually a big compliment, coming from you, as a user with vast experience and who is sometimes very particular about details. If that is all needed to be added, that means they are on a very good path. And once they get to it to add this too, they will have very, very good product.
Stay safe,
Sinisa
-
That is actually a big compliment, coming from you, as a user with vast experience and who is sometimes very particular about details.
Totally agree there. I would say the strongest I've ever seen from nico regarding Siglent. :)
Even tautech will start coding...
-
And pigs might fly.
-
“With enough thrust, pigs fly just fine“ (RFC1925)
-
It's been a long standing implementation of capture strategy by LeCroy, Pico scope and Siglent all of which are respected brands in their respective fields.
It allows more power to the user other than in corner use cases.
AFAIK it's still on a low priority list for Siglent to modify to suit those that can't/won't adapt to a different way of reaching the same result.
Not having a Siglent/LeCroy/Pico, I can't comment on the practicality aspects between Zoom In and Zoom Out, but this latest skirmish highlights Siglent's decision to not change the behaviour of their Mem Depth setting from "Maximum usable memory" to "User set memory" - IMHO a non-catastrophic bug, but still a bug.
No it's a design decision and for good reason and common to all 3 brands.
Any change to current behaviour could impact on specifications optimised by the current design philosophy.
No, it doesn't (and not only on Siglent but also for Lecroy and Picoscope scopes). That is the real kicker! So quit the marketing BS. Nobody is buying it. You can't even explain what the benefit is of this so called 'design choice' is anyway.
The reason I know that there are no downsides to adding 'zoom out' is because I have designed & build oscilloscope (like) data acquisition systems.
Well, it is a design philosophy, by choice, which defines architecture. And you cannot know how easy is to add something to already released product, unless it is you who designed it or have privileged knowledge.
It is not a design philosophy. Remember that zoom mode can be used to force use of all the memory while the oscilloscope still works the same. All Siglent needs to do is add a flag to the software which causes the memory length to be what the user selected and hide the zoom window.
Boy, that escalated fast.
At any rate, thanks Sinisa and tautech for the additional insights. I still am on the camp of "bug", but I guess that is how I roll... In my DS4014 I can set the full 140Mpts and leave it at that throughout the horizontal range (from 1ns/div to 1000ks/div) and take the penalty on the wfm.
-
Boy, that escalated fast.
At any rate, thanks Sinisa and tautech for the additional insights. I still am on the camp of "bug", but I guess that is how I roll... In my DS4014 I can set the full 140Mpts and leave it at that throughout the horizontal range (from 1ns/div to 1000ks/div) and take the penalty on the wfm.
Rafael, you are absolutely correct, it is nice to be able to chose. As I said before I'm all for that. I don't call it bug, because, it would be bug if it was on the menu and datasheet and then, when you click it, it doesn't work. That's a bug.
What you could call it is a missing feature. That is it. How important it is, is a matter of debate, QED.... :-DD..
I would presume Siglent wants customers to be happy, and if feasible, they will add it. If that will attract more customers, adding features will happen.
But I would presume that changing fundamental features how timebase and acquisitions work, would need massive testing if all the rest of the scope still works as it should.
So even if it was implemented right now, it would probably warrant a new major FW number and testing that goes with it.
To make it clear, I have no clue what is really happening in Siglent in regard to this, those are my presumptions how I would do it if I was in charge of that.
Take care and stay safe,
Siniša
-
I guess the benefit to Siglent of making this change, is that potential customers that are used to Agilent / Keysight products would no longer miss this feature.
It seems to me that it might be a problem to implement it in a responsive way without the magic of the Megazoom tech?
-
I guess the benefit to Siglent of making this change, is that potential customers that are used to Agilent / Keysight products would no longer miss this feature.
It is not just Agilent / Keysight; every other oscilloscope manufacturer out there has zoom-out on their DSOs! Siglent and Lecroy are the outliers who don't have it.
-
I guess the benefit to Siglent of making this change, is that potential customers that are used to Agilent / Keysight products would no longer miss this feature.
It is not just Agilent / Keysight; every other oscilloscope manufacturer out there has zoom-out on their DSOs! Siglent and Lecroy are the outliers who don't have it.
So, Rigol has it too?
-
So, Rigol has it too?
Yes. Even the low end DS1054Z can do it.
-
It seems to me that it might be a problem to implement it in a responsive way without the magic of the Megazoom tech?
It won't make any difference at all to responsiveness. An oscilloscope is always filling up the memory when it's waiting for a trigger event and that's all this is - filling up the memory.
-
I guess the benefit to Siglent of making this change, is that potential customers that are used to Agilent / Keysight products would no longer miss this feature.
It is not just Agilent / Keysight; every other oscilloscope manufacturer out there has zoom-out on their DSOs! Siglent and Lecroy are the outliers who don't have it.
So, Rigol has it too?
Check Dave's video:
https://www.youtube.com/watch?v=bVxDibdosdI (https://www.youtube.com/watch?v=bVxDibdosdI)
Add Yokogawa to the list of manufacturers which support zoom-out on their DSOs as well.
-
But I would presume that changing fundamental features how timebase and acquisitions work, would need massive testing if all the rest of the scope still works as it should.
Yes, I really understand. At work I am usually the one that hates changing default behaviour/settings. :-+
-
But I would presume that changing fundamental features how timebase and acquisitions work, would need massive testing if all the rest of the scope still works as it should.
That's the thing: it is not a big change. Only a some UI changes. All the necessary logic to support zoom-out is allready there. Go sit behind a DSO and enable zoom-mode. You can scroll left/right / change the timebase of the main window without any problem. Now imagine doing the same with the zoom window hidden. What is functionally different? You keep thinking it is a major overhaul and months of work but it isn't. Most of the work is likely for someone at Siglent to change his/her mind and to realise that zoom-out is a standard feature on every DSO of their competitors.
-
I guess the benefit to Siglent of making this change, is that potential customers that are used to Agilent / Keysight products would no longer miss this feature.
It is not just Agilent / Keysight; every other oscilloscope manufacturer out there has zoom-out on their DSOs! Siglent and Lecroy are the outliers who don't have it.
Agilent Infiniivision series DOESN'T have it, the way you like it. While in a run mode, it grabs only screen full of data from trigger to trigger. On some timebases it will grab a bit more but far from whole memory.
And when you press Stop, it makes separate Single capture for the last one if there is triggerable event within 200-250ms (or so) from moment you press Stop. If not, you are left with only screen full of data.
I already demonstrated that before and documented it into detail.
So, no, Keysight doesn't do it. Please everybody stop repeating that, it is not truth.
Regards,
-
But I would presume that changing fundamental features how timebase and acquisitions work, would need massive testing if all the rest of the scope still works as it should.
That's the thing: it is not a big change. Only a some UI changes. All the necessary logic to support zoom-out is allready there. Go sit behind a DSO and enable zoom-mode. You can scroll left/right / change the timebase of the main window without any problem. Now imagine doing the same with the zoom window hidden. What is functionally different? You keep thinking it is a major overhaul and months of work but it isn't. Most of the work is likely for someone at Siglent to change his/her mind and to realise that zoom-out is a standard feature on every DSO of their competitors.
If I remember correctly, you are the person that actually said that you prefer fact that R&S releases software so rarely because it is a sign that they are testing properly. You said it was a sign of quality, and that Chinese manufacturers should test better. I don't know how big overhaul this would be, as I know how software is written. But I do think it is MAJOR change in the core of the system (what is scope of data for measurement? Zoom, gates, full buffer ?) If they do change this ( and I hope they DO ), I would WANT them to do it right and to test the crap out of it...
And zoom out doesn't exist. Competition have one memory strategy (that by the way is reason people say Tektronix scopes are slow, because they set it to 10Ms depth and then go: "Boy this thing is slow, cannot make more than few hundred triggers per minute..."). "Zoom out" is artefact that your scope captured more data than you originally set it to show on screen.
Rigol, by default, doesn't use that strategy, but uses same one as Keysight and Siglent, and Lecroy..
But Rigol has advantage that you can enable full memory, so user can choose. I hope Siglent will add it too, if for nothing else to end this endless, repetitive dejavu....
-
But I would presume that changing fundamental features how timebase and acquisitions work, would need massive testing if all the rest of the scope still works as it should.
That's the thing: it is not a big change. Only a some UI changes. All the necessary logic to support zoom-out is allready there. Go sit behind a DSO and enable zoom-mode. You can scroll left/right / change the timebase of the main window without any problem. Now imagine doing the same with the zoom window hidden. What is functionally different? You keep thinking it is a major overhaul and months of work but it isn't. Most of the work is likely for someone at Siglent to change his/her mind and to realise that zoom-out is a standard feature on every DSO of their competitors.
If I remember correctly, you are the person that actually said that you prefer fact that R&S releases software so rarely because it is a sign that they are testing properly. You said it was a sign of quality, and that Chinese manufacturers should test better. I don't know how big overhaul this would be, as I know how software is written. But I do think it is MAJOR change in the core of the system (what is scope of data for measurement? Zoom, gates, full buffer ?) If they do change this ( and I hope they DO ), I would WANT them to do it right and to test the crap out of it...
Sorry but this isn't the subject at all. I claim it is simple to add and now you jump to testing??? It makes no sense at all. 'Zoom out' is simple to add so it is simple to test. You keep grasping straws to justify 'zoom out' is difficult to add. With my software engineering hat on and knowledge about oscilloscope memory management I say it isn't difficult to add because I KNOW it isn't.
-
But I would presume that changing fundamental features how timebase and acquisitions work, would need massive testing if all the rest of the scope still works as it should.
That's the thing: it is not a big change. Only a some UI changes. All the necessary logic to support zoom-out is allready there. Go sit behind a DSO and enable zoom-mode. You can scroll left/right / change the timebase of the main window without any problem. Now imagine doing the same with the zoom window hidden. What is functionally different? You keep thinking it is a major overhaul and months of work but it isn't. Most of the work is likely for someone at Siglent to change his/her mind and to realise that zoom-out is a standard feature on every DSO of their competitors.
If I remember correctly, you are the person that actually said that you prefer fact that R&S releases software so rarely because it is a sign that they are testing properly. You said it was a sign of quality, and that Chinese manufacturers should test better. I don't know how big overhaul this would be, as I know how software is written. But I do think it is MAJOR change in the core of the system (what is scope of data for measurement? Zoom, gates, full buffer ?) If they do change this ( and I hope they DO ), I would WANT them to do it right and to test the crap out of it...
Sorry but this isn't the subject at all. I claim it is simple to add and now you jump to testing??? It makes no sense at all. 'Zoom out' is simple to add so it is simple to test. You keep grasping straws to justify 'zoom out' is difficult to add. With my software engineering hat on and knowledge about oscilloscope memory management I say it isn't difficult to add because I KNOW it isn't.
OOkay...... :-+
-
But I do think it is MAJOR change in the core of the system
No it isn't. The capture routine has to work with any memory size (you can zoom out until you get all the memory, right?)
All they need to do is always use all the memory instead of computing a smaller memory size and using only part of it.
In reality it should simplify the code.
-
When it´s so simple to change, when it seems it got only advantages when always using the full memory amount- Why do a major brand like teledyne lecroy not use it?
When it´s so important for many one in the world, why won´t they change it in the last decades, instead they still got satisfied customers around the world..Are these all blind dumbasses ?
There must be a advantage when lecory handle it in this way - and a disavantage on the other side.
(...) Which (being perfect on entry level products) for some reason is not requirement for big brands like Keysight and R&S and LeCroy. They are allowed to make products that are deliberately limited for marketing purposes. With them it is business decisions and "small niggles". With Siglent and Rigol it's "crap I wouldn't buy"...
True, true...
And it´s a very annoying thing.
A real superb scope model like the "new" 2K siglent doesn´t have a feature like this zoom out thing - Reading this thread, people who are interesting to buy it may get the impression that this absence is a very bad flaw that would make it unusable.
-
When it´s so simple to change, when it seems it got only advantages when always using the full memory amount- Why do a major brand like teledyne lecroy not use it?
Because traditionally Lecroy serves a different market; the market where waveforms/s don't matter so much but signal analysis does. More geared towards scientific use. AFAIK Lecroy offers the widest number of signal analysis tools on their scopes (after you pay for all the options). But there are a few things Lecroy doesn't support (on their own designs): peak detect and AFAIK averaging and high resolution are available as (slow) math traces only instead of being produced by the acquisition engine. All in all Lecroy has a very purist approach towards signal acquisition. This is fantastic for signal analysis (I really like my Wavepro 7300A for that) but as a general purpose bench scope it is less than ideal. And calling Lecroy a major brand is a bit of an overstatement; to me they seem to be aiming towards high profit niches. Much of their other gear consists of rebadges.
-
And calling Lecroy a major brand is a bit of an overstatement
...........
-
And calling Lecroy a major brand is a bit of an overstatement..........
::)
Name the 2 manufacturers making 100+ GHz scopes.
-
GW Instek and Micsig ??? ;)
-
GW Instek and Micsig ??? ;)
Only in their dreams.
-
And calling Lecroy a major brand is a bit of an overstatement
...........
Just look at Lecroy's sales revenue. A quick Google search learns me that it is dwarfed by that of Keysight, Tektronix, Rhode & Schwarz and Yokogawa by a factor of 5 to 20 (not combined but compared to each!). Lecroy really isn't a big player in the test equipment market. And you may laugh at GW Instek but they do half of Lecroy's revenue and equal to that of Rigol and Siglent combined.
-
When it´s so simple to change, when it seems it got only advantages when always using the full memory amount- Why do a major brand like teledyne lecroy not use it?
Who knows?
But that's "argument from authority (https://en.wikipedia.org/wiki/Argument_from_authority)". It's not a reason for Siglent to follow them or an argument that Siglent is "doing the right thing".
All it means is that TDL is doing it wrong, too.
-
No SDS2104X Plus left ...customers have them all so out comes zoom on a SDS5104X.......
What's not to like......still an 8" display of which half is still usable.
Cluttered display ? :-//
All available memory used.
2 displays each with its own timebase and each accessible by clicking or touch.
~160 packets consisting of ~920 bytes and zoom in or out to your heart's content.
(https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/?action=dlattach;attach=1187606)
(https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/?action=dlattach;attach=1187610)
-
When it´s so simple to change, when it seems it got only advantages when always using the full memory amount- Why do a major brand like teledyne lecroy not use it?
Who knows?
But that's "argument from authority (https://en.wikipedia.org/wiki/Argument_from_authority)". It's not a reason for Siglent to follow them or an argument that Siglent is "doing the right thing".
All it means is that TDL is doing it wrong, too.
What is an "argument from authority" ? Fact that Nico and you say it's easy so that's it?
It is not "who knows why". LeCroy has dozens of whitepapers that explains why, but that requires reading and accepting the fact that one might not be smartest guy in the room and may be wrong.
So we have two punters who claim they know better than engineers that make 100 GHz scopes....
There is no argument here. We have Nico who have digital view of the world : his way and wrong way, and you who join any controversial discussion with no intention of contributing anything useful, just riling up emotions and provoking people.....Like Bugs Bunny, but without charm....
LeCroy, Siglent, Picoscope, Rigol (by default AUTO strategy), R&S (by default AUTO strategy), Keysight Infiniivision (Run mode), Micsig (by default AUTO strategy) and all others that have AUTO memory mode use that same method of only grabbing only amount of data that is equivalent to length of screen in current timebase. They all do it to minimize amount of data taken in every trigger to get faster reacting scope and keep sampling rate high to avoid aliasing. It is like analog scope, you see what you see. There is NO data before or after screen, and there is no need to. If you want to see more, you put more time ON the screen. Benefit of digital scope is that you can stop it and then zoom in and still see details.
There is no simpler or more logical way of doing it, and as I said before, most of the scopes come by default set for that use pattern. Tektronix added AUTO mode on latest models, because people were asking for this "LeCroy" mode, because twiddling memory length manually all the time is pain in the ass. Why would stupid scope always collect 0,1 second of data, update 10 times a second (like a multimeter), and then throwaway everything except 1 usec of data ( throwing away 99,999% of data) and then show that on the screen. How is that efficient, good engineering.
What Nico does is similar to Rube Goldberg machine, where he achieves same result by setting several setting, doing mental math and paying attention that they all sit together in the end by side effect to give him his data.
Instead of using the doorknob to open the door, he devised a system of levers and pulleys that opens the door from the lever on the wall next to the door , because he doesn't like how doorknob makes the door look. And then one day, he realized, if he moves that lever low enough, he can open the door with a foot. Which is kind of neat when your hands are full. And then he saw the light and now it is the only righteous way..
Rest of use just use doorknobs, and open the door with an elbow if our hands are busy. He likes his handles and pulleys, his complicated ways of doing simple things ? Great, glad for him. Me, I'll keep using doorknobs, like millions of others.
-
What is an "argument from authority" ?
I did link to the Wikipedia page, but the short version is "not an argument based on logic or evidence".
LeCroy, Siglent, Picoscope, Rigol (by default AUTO strategy), R&S (by default AUTO strategy), Keysight Infiniivision (Run mode), Micsig (by default AUTO strategy) and all others that have AUTO memory mode use that same method of only grabbing only amount of data that is equivalent to length of screen in current timebase.
Nope. All of them grab the amount of data which is the current memory depth. That can easily be more data than fits on screen.
They all do it to minimize amount of data taken in every trigger to get faster reacting scope and keep sampling rate high to avoid aliasing.
Are you saying Keysights are slowed down and/or suffer aliasing because of this? My Rigol certainly wasn't.
It is like analog scope, you see what you see. There is NO data before or after screen, and there is no need to.
:palm:
If you want to see more, you put more time ON the screen. Benefit of digital scope is that you can stop it and then zoom in and still see details.
What if the event is a rare one and you can't simply "put more time on screen" then re-record it?
There is no simpler or more logical way of doing it
Um, yes there is. It's a much more natural workflow to simply zoom out from what you're looking at.
-
What is an "argument from authority" ?
I did link to the Wikipedia page, but the short version is "not an argument based on logic or evidence".
LeCroy, Siglent, Picoscope, Rigol (by default AUTO strategy), R&S (by default AUTO strategy), Keysight Infiniivision (Run mode), Micsig (by default AUTO strategy) and all others that have AUTO memory mode use that same method of only grabbing only amount of data that is equivalent to length of screen in current timebase.
Nope. All of them grab the amount of data which is the current memory depth. That can easily be more data than fits on screen.
They all do it to minimize amount of data taken in every trigger to get faster reacting scope and keep sampling rate high to avoid aliasing.
Are you saying Keysights are slowed down and/or suffer aliasing because of this? My Rigol certainly wasn't.
It is like analog scope, you see what you see. There is NO data before or after screen, and there is no need to.
:palm:
If you want to see more, you put more time ON the screen. Benefit of digital scope is that you can stop it and then zoom in and still see details.
What if the event is a rare one and you can't simply "put more time on screen" then re-record it?
There is no simpler or more logical way of doing it
Um, yes there is. It's a much more natural workflow to simply zoom out from what you're looking at.
It's yellow.
-
What Nico does is similar to Rube Goldberg machine, where he achieves same result by setting several setting, doing mental math and paying attention that they all sit together in the end by side effect to give him his data.
Instead of using the doorknob to open the door, he devised a system of levers and pulleys that opens the door from the lever on the wall next to the door , because he doesn't like how doorknob makes the door look. And then one day, he realized, if he moves that lever low enough, he can open the door with a foot. Which is kind of neat when your hands are full. And then he saw the light and now it is the only righteous way..
And now back to ridiculing other people's workflow :palm: I was hoping my previous message would appeal to your maturity but appearantly it hasn't. How are we supposed to take you serious when you keep pulling nonsense out of your ass? Just accept the fact that you don't understand everything. Understanding why 'zoom out' is more efficient is one of them.
A simple example: looking at the data in the middle of an I2C message (only part of the message on screen). A scope with deep memory length will capture the start (and thus is able to decode the message) without explicitely needing to setup a zoom window and think what kind of time/div that zoom window needs to have. I2C usually runs at tens of kHz at least. Even a relative short span like 10Mpts of memory @1Gs/s gives you a total time of 10ms. That is enough to capture an I2C message a few bytes long (clocked at 10kHz) several times over. Why make setting up an oscilloscope more troublesome than it has to?
-
No SDS2104X Plus left ...customers have them all so out comes zoom on a SDS5104X.......
What's not to like......still an 8" display of which half is still usable.
Cluttered display ? :-//
In my opinion, yes. I have less screen area to what I really want to see from the waveform itself, not the entire capture. Sure, a Pico will never have this issue, but an 8'' screen (just like my DS4014) this is not good.
LeCroy, Siglent, Picoscope, Rigol (by default AUTO strategy), R&S (by default AUTO strategy), Keysight Infiniivision (Run mode), Micsig (by default AUTO strategy) and all others that have AUTO memory mode use that same method of only grabbing only amount of data that is equivalent to length of screen in current timebase.
Sinisa, that is where you lose me. No question about the benefits or characteristics of the Auto setting, but another is the fact that in a Rigol I can set a memory depth and the oscilloscope will obey my command. That is not what is seen in Dave's video: Siglent will size it according to what it thinks it is better.
And no, I don't need to do "mental math and paying attention that they all sit together" either.
Otherwise, I have been in lenghty interface and ease-of-use discussions to know these things are hard to convince if there is not a very clear benefit one way or another.
-
No SDS2104X Plus left ...customers have them all so out comes zoom on a SDS5104X.......
What's not to like......still an 8" display of which half is still usable.
Cluttered display ? :-//
In my opinion, yes. I have less screen area to what I really want to see from the waveform itself, not the entire capture. Sure, a Pico will never have this issue, but an 8'' screen (just like my DS4014) this is not good.
You may have misunderstood. :-//
10" native display but in Zoom mode 8" of corner to corner usable display still remains where in this image only half is used by 3 traces including the decode display.
This is a pile of screen real estate in which to add a further trace, apply Maths, Histograms, Statistics, Measurements etc any of which can be positioned on the remaining half of the display to ones liking.
(https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/?action=dlattach;attach=1187978)
A stopped/captured waveform record is where the power of a DSO can then be applied to magnify amplitude, Pan or Search the whole record with a range of parameters to ensure the waveform integrity meets requirements of which for SDS5000X we have the minimum 125 Mpts at this primary timebase setting. SDS2000X Plus will show a minimum 100 Mpts record with the same scope settings.
These are relatively new and powerful scopes that like any new device/tool/component takes time to comprehend and properly utilize in a manner we may have not used or fully understood when compared to previous experience.
-
@Tautech: please stop making a fool out of yourself by pretending everyone but you is stupid. DSOs have had zoom mode and math since the late 80's. Oscilloscope users are well aware that it exists; there is nothing new or special about zoom mode and math these days.
-
Sinisa, that is where you lose me. No question about the benefits or characteristics of the Auto setting, but another is the fact that in a Rigol I can set a memory depth and the oscilloscope will obey my command. That is not what is seen in Dave's video: Siglent will size it according to what it thinks it is better.
And no, I don't need to do "mental math and paying attention that they all sit together" either.
Otherwise, I have been in lenghty interface and ease-of-use discussions to know these things are hard to convince if there is not a very clear benefit one way or another.
Rafael, it is probably me not being able to explain well. Rigol comes by default in Auto, and I met more than few people that keep using it only in Auto, because for interactive work it is better, than having to think about capture memory, and still have scope work as fast as possible. If you want to understand how Siglent memory works, put your Rigol in Auto memory and observe how it behaves.
That is what I wanted to explain. I also repeated many times that Rigol is better in this regard, because you can choose fixed memory too. Which you use sometimes also, which is OK, because sometimes it can be useful. That is fine.
About mental math, that is maybe debatable. Why? Because, when you set 14 Mpts memory depth, how long SPI (or any other event) sequence can you get with it ? And by long I mean how much time you get in total? 10 ms, 20 ms, 330 ms ?
Please see attached excel table and verify if I calculated wrong...
In short , if you're looking at short timebase and you don't need fast refresh, you will have a lot data captured off the screen.
But that is because your scope have huge 140(70)MPts memory. Nicos scope has 80(40)MPts, so you loose some advantage.
If you have 10 Mpoint scope, it looks less good. But still usable.
Problem is that, after hundreds of messages, I managed to make Nico say what is his main use for it. What he said it was capturing long data on serial buses, while looking at very short part of that capture that has some event or packet of interest. He keeps scope in RUN mode (not Single), and if he sees the event (error, or whatever is of interest) he manually stops the scope (events are sparse, so there is time to react) and then can move inspect whole capture for details. Captures are quite long, on order of 0,1 -2 seconds, done on low sample rates.
To achieve that, you cannot run too fast timebase, because at 80Mpts you need 50Msps/sec to achieve 1,6 sec, for instance. How do you setup your scope to do that?
Regards,
-
LeCroy, Siglent, Picoscope, Rigol (by default AUTO strategy), R&S (by default AUTO strategy), Keysight Infiniivision (Run mode), Micsig (by default AUTO strategy) and all others that have AUTO memory mode use that same method of only grabbing only amount of data that is equivalent to length of screen in current timebase.
Nope. All of them grab the amount of data which is the current memory depth. That can easily be more data than fits on screen.
2N3055 is correct, and provided the specific modes which cause this to occur. The "current" memory depth on many scopes varies and can't always be set explicitly. This entire thread is that extremely narrow point.
They all do it to minimize amount of data taken in every trigger to get faster reacting scope and keep sampling rate high to avoid aliasing.
Are you saying Keysights are slowed down and/or suffer aliasing because of this? My Rigol certainly wasn't.
Why auto? Lets go way back in time:
https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038 (https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038)
Thats a Rigol (the specific brand you asked for) causing aliasing or slow update rates if the user selects an inappropriate memory depth. On older Tek scopes there wasn't an auto memory setting and it was quite annoying to go into the menus to adjust the memory depth every time you wanted to change capture lengths (some debugging does well to look at small details and then larger ones, back and forth). Keysight megazoom scopes? They don't let the user set any of that and always maintain the highest update rate (in run mode, in single trigger they fill the full depth), aliasing isn't an issue with them as they have very effective filtering to prevent it.
-
2N3055 is correct, and provided the specific modes which cause this to occur. The "current" memory depth on many scopes varies and can't always be set explicitly. This entire thread is that extremely narrow point.
Thank you for summarizing that better than I ever could.
Thats a Rigol (the specific brand you asked for) causing aliasing or slow update rates if the user selects an inappropriate memory depth. On older Tek scopes there wasn't an auto memory setting and it was quite annoying to go into the menus to adjust the memory depth every time you wanted to change capture lengths (some debugging does well to look at small details and then larger ones, back and forth). Keysight megazoom scopes? They don't let the user set any of that and always maintain the highest update rate (in run mode, in single trigger they fill the full depth), aliasing isn't an issue with them as they have very effective filtering to prevent it.
EDIT. deleted.
-
Sinisa, that is where you lose me. No question about the benefits or characteristics of the Auto setting, but another is the fact that in a Rigol I can set a memory depth and the oscilloscope will obey my command. That is not what is seen in Dave's video: Siglent will size it according to what it thinks it is better.
And no, I don't need to do "mental math and paying attention that they all sit together" either.
Otherwise, I have been in lenghty interface and ease-of-use discussions to know these things are hard to convince if there is not a very clear benefit one way or another.
About mental math, that is maybe debatable. Why? Because, when you set 14 Mpts memory depth, how long SPI (or any other event) sequence can you get with it ? And by long I mean how much time you get in total? 10 ms, 20 ms, 330 ms ?
It doesn't matter as long as it is enough. It is like the gas gauge in a car you have driven for a decent amount of time. If it points at 'half full' you know how far you can get (and need to refuel for the trip ahead or not) because you are familiar with the car. Not everything needs to be quantified to 10 digits after the decimal point to in order to be accurate enough, usefull and/or true. How much gas is there in the car? 'Enough' is sufficient to know.
Problem is that, after hundreds of messages, I managed to make Nico say what is his main use for it. What he said it was capturing long data on serial buses, while looking at very short part of that capture that has some event or packet of interest. He keeps scope in RUN mode (not Single), and if he sees the event (error, or whatever is of interest) he manually stops the scope (events are sparse, so there is time to react) and then can move inspect whole capture for details. Captures are quite long, on order of 0,1 -2 seconds, done on low sample rates.
Now you are mixing up several scenarios I outlined.
-
The zoom out thing is obviously useful in some scenarios, where you have both "trees" and "forests" going on, and you are switching between the two perspectives.
How did this end up being so hotly debated? - got to love the Internet! :D
-
How did this end up being so hotly debated?
Its not hotly debated, like has happened on other topics a minority (or single person) keeps reposting misleading information for some unknown reason. They can't fully justify or support their claims but keep coming back for more ridicule.
It'd be great if scopes offered the choice to set all these parameters, but absolutely none do. Its that all the different scopes have different ways to achieve the same thing, and their tradeoffs are different. What you like I might hate, which is fine. But I don't go out of my way to insist everyone else should like what I do, and all scopes should change their way of working to match my ideas. I also don't bomb every thread even slightly related to shout about how particular brands work in ways I don't prefer, blowing up tiny issues that no-one asked about.
The fun thing is there has been a manufacturer who radically changed their operation mode: Tek. Auto vs non auto, which is most popular? which causes more support requests?
-
[...]
The fun thing is there has been a manufacturer who radically changed their operation mode: Tek. Auto vs non auto, which is most popular? which causes more support requests?
Is there anything quite as disheartening as staring at an oscilloscope screen that refuses to display any trace? :D
-
An elder Note from Lecroy about the advantage of long memory:
http://cdn.teledynelecroy.com/files/appnotes/lecroy_long_memory_in_digital_scopes_appnote010.pdf (http://cdn.teledynelecroy.com/files/appnotes/lecroy_long_memory_in_digital_scopes_appnote010.pdf)
The uploaded pic shows a part of the rigol ds1000z user manual...
-
No SDS2104X Plus left ...customers have them all so out comes zoom on a SDS5104X.......
What's not to like......still an 8" display of which half is still usable.
Cluttered display ? :-//
In my opinion, yes. I have less screen area to what I really want to see from the waveform itself, not the entire capture. Sure, a Pico will never have this issue, but an 8'' screen (just like my DS4014) this is not good.
You may have misunderstood. :-//
10" native display but in Zoom mode 8" of corner to corner usable display still remains where in this image only half is used by 3
traces including the decode display.
That is surely more screen realstate than what I understood. Thanks for clarifying.
(No chance to customize this and remove the zommed out bar, I suppose? I need moar, MOAR screen! :D )
Rafael, it is probably me not being able to explain well. Rigol comes by default in Auto, and I met more than few people that keep using it only in Auto, because for interactive work it is better, than having to think about capture memory, and still have scope work as fast as possible. If you want to understand how Siglent memory works, put your Rigol in Auto memory and observe how it behaves.
Thank you again. You probably explained this before but I also could not understand correctly (not native as well). :-+
[...]
The fun thing is there has been a manufacturer who radically changed their operation mode: Tek. Auto vs non auto, which is most popular? which causes more support requests?
Is there anything quite as disheartening as staring at an oscilloscope screen that refuses to display any trace? :D
:-DD :-DD :-DD
The latest Tek models MDO 3 and 4 felt that way for me...
-
It'd be great if scopes offered the choice to set all these parameters, but absolutely none do.
Still there is a basic set of operating modes common amongst most brands (as Dave has demonstrated in his 'zoomout' video). This thread is about the behaviour of 2 outliers when it comes to benchtop oscilloscopes.
-
It'd be great if scopes offered the choice to set all these parameters, but absolutely none do.
Still there is a basic set of operating modes common amongst most brands (as Dave has demonstrated in his 'zoomout' video). This thread is about the behaviour of 2 outliers when it comes to benchtop oscilloscopes.
A use case which is so complex and full of gotchas that almost no-one uses it! You've been unable to clearly explain the benefits of such a workflow, hence the many users getting confused.
Its really simple, 99% of people would use a zoom window so they can see both. Zooming out is not a great idea as it lacks controls of where the capture window is located.
You didn't like that it used up some extra screen space you felt was better used on other things. Fine. Thats not a reason to change memory management, thats a motivator to improve the customisability of the traces/zoom windows. But you keep rallying against anything but your narrow solution, when for the majority there are far better ways to do it.
Adjustable memory controls, could be useful, zero manufacturers have implemented it.
Adjustable windows, probably much better, thats where newer instruments are going.
But keep going with your short one liners that miss all the nuance and details which your nonsense arguments rely on. We'll keep point out how they are silly.
-
No SDS2104X Plus left ...customers have them all so out comes zoom on a SDS5104X.......
What's not to like......still an 8" display of which half is still usable.
Cluttered display ? :-//
In my opinion, yes. I have less screen area to what I really want to see from the waveform itself, not the entire capture. Sure, a Pico will never have this issue, but an 8'' screen (just like my DS4014) this is not good.
You may have misunderstood. :-//
10" native display but in Zoom mode 8" of corner to corner usable display still remains where in this image only half is used by 3
traces including the decode display.
That is surely more screen realstate than what I understood. Thanks for clarifying.
You're welcome.
Some maintain Zoom mode is too confined to be workable yet the simple screenshot offered and measurements shown there's actually more screen real estate than some scopes offer in unzoomed mode however we only have this nice 25/75 ratio in these latest scopes with the new UI.
(No chance to customize this and remove the zommed out bar, I suppose? I need moar, MOAR screen! :D )
SDS6000....coming in a while .....12" display. :)
But seriously we all want larger displays for some display intense jobs and most modern DSO's permit porting the display to a larger screen where that screen size itself is the only limiting factor....
-
But seriously we all want larger displays for some display intense jobs
Where 12" (our hdo6034A) is my personal absolute limit, watching it in short distance.
We got a lecroy WR9054 also, it´s 15.4" screen reminds of sitting in the first row in a cinema... :P 8)
In fact, the 10" screen of my private siglent sds2k+ is perfect for me.
-
It'd be great if scopes offered the choice to set all these parameters, but absolutely none do.
Still there is a basic set of operating modes common amongst most brands (as Dave has demonstrated in his 'zoomout' video). This thread is about the behaviour of 2 outliers when it comes to benchtop oscilloscopes.
A use case which is so complex and full of gotchas that almost no-one uses it! You've been unable to clearly explain the benefits of such a workflow, hence the many users getting confused.
Read the comments to Dave's video; you'll see that many people are using zoom-out and consider it a standard DSO feature.
All in all the reality is that your statement is the other way around; there are a limited number of people who:
1) Don't understand the benefit because they don't need it and somehow are opposed to it as a result or maybe because they want a solution which works for 10 out of 10 cases instead of one which is faster but only covers 9 out of 10 cases.
2) Have a vested interest in a brand which doesn't support 'zooming out' and keep spreading marketing wank.
It is not my function to explain things in depth. I'm not getting paid for that so be happy with what I give you for free. I just point out how to do things more efficiently (less twiddling of knobs) and oppose marketing wank.
The whole discussion is pretty similar to the (recurring) one in the CAD section where people don't see the usefullness of having a part database which holds the parts information instead of littering the symbol library with ordering information (etc) and on top of that are heavily opposed to this workflow beyond reasoning. Almost to the point where they claim 'everyone using a part database is an idiot' while having a seperate part database (part management) is one of the key feature in the eyes of the professional PCB CAD vendors and is also mandatory feature for many of their professional customers.
Anyway, I'm going to leave this discussion as it is. It has been long enough and arguments are going in circles.
-
It is not my function to explain things in depth. I'm not getting paid for that so be happy what I give you for free.
LOL.
-
How is manually setting memory depth and time base every time you want to change what you're looking at less keypresses than simply set timebase, press zoom, set 2nd timebase and position.
Memory settings are usually not on buttons or main menu so you at least need to press Acquistion - Record length -select length. That is 3 steps for memory set alone. Then you need to setup timebase for screen (making sure to keep sample rate in sweet spot that will guarantee your wanted full sample), and then you need to find a place in a buffer with delay command or knob, for which you don't have any visual aid, but need to find the right place blindly, pretty much zooming out to see where you are, moving displayed portion with delay, and then zooming in and keep repeating it in until you are at the right spot.
You see, after this thing kept going for a while, I went and took out my Micsig (which has both auto, and manual memory management. auto is default).
And I tried what you're saying and it was not less keypresses, but significantly more twiddling on average. You need to constantly twiddle back and forth with time base and position to look around. I set time base for full capture, press zoom, set secondary time base, set zoom position, and then after capture, i just move zoom position with finger on the visual map of capture. That's it. Yes it uses screen space for zoom. But it is way faster, more intuitive, WISIWIG, you literally see what you're doing. And, I didn't mention this before, you can disable zoom and move around with timebase and delays same way as you do... So you capture initial capture with zoom with all the benefits that has, and once you have your data, disable the zoom and move around as you would your way.
-
which has both auto, and manual memory management. auto is default
Everyone took "Auto" as default....Why....My guess is, it´s "foolproof" meaning it´s the most usable condition at all.
But not for everyone, we´ve learned here. 8)
-
It'd be great if scopes offered the choice to set all these parameters, but absolutely none do.
Still there is a basic set of operating modes common amongst most brands (as Dave has demonstrated in his 'zoomout' video). This thread is about the behaviour of 2 outliers when it comes to benchtop oscilloscopes.
A use case which is so complex and full of gotchas that almost no-one uses it! You've been unable to clearly explain the benefits of such a workflow, hence the many users getting confused.
Read the comments to Dave's video; you'll see that many people are using zoom-out and consider it a standard DSO feature.
All in all the reality is that your statement is the other way around; there are a limited number of people who:
1) Don't understand the benefit because they don't need it and somehow are opposed to it as a result or maybe because they want a solution which works for 10 out of 10 cases instead of one which is faster but only covers 9 out of 10 cases.
2) Have a vested interest in a brand which doesn't support 'zooming out' and keep spreading marketing wank.
It is not my function to explain things in depth. I'm not getting paid for that so be happy with what I give you for free. I just point out how to do things more efficiently (less twiddling of knobs) and oppose marketing wank.
The whole discussion is pretty similar to the (recurring) one in the CAD section where people don't see the usefullness of having a part database which holds the parts information instead of littering the symbol library with ordering information (etc) and on top of that are heavily opposed to this workflow beyond reasoning. Almost to the point where they claim 'everyone using a part database is an idiot' while having a seperate part database (part management) is one of the key feature in the eyes of the professional PCB CAD vendors and is also mandatory feature for many of their professional customers.
Anyway, I'm going to leave this discussion as it is. It has been long enough and arguments are going in circles.
Its all here in the thread, you insist that zoom windows cannot be used. Which is plainly untrue and a made up constraint of yours. I much prefer to have a zoom window set so I can see both interesting features without having to adjust or touch anything. So insisting that everyone else is just like you and the world should change for that is very much your problem that you need to come to terms with.
https://en.wikipedia.org/wiki/Confirmation_bias
I have worked with a wide range of scopes and colleagues, and never seen anyone use the "zoom out" workflow or trick intentionally. We're trying to imagine how this workflow could be used practically and add value to our work, but you're had to narrow the constraints so far to such a specific point its silly. We politely explain how if any one of the synthetic constraints is removed then there is no real problem and many ways to achieve the task.
Since people don't seem to read back through the thread:
One way is as good as the other, maybe, but DSOs are designed, primarily, around zooming in.
Says who? Nobody provided any evidence that zooming out is not the way an oscilloscope works. The fact it (recording beyond the screen) is possible on many oscilloscopes suggests that those are actually designed to work this way.
They can work that way, yes. But you keep insisting that other ways to achieve the same result are completely irrelevant and not to be considered. That may be for you, but you keep bringing this extremely narrow and unusual workflow up as some general advice when its completely your imaginary construction.
If you want to bring it up, then you'll need to actually put out the reasons, constraints, and benefits of your method. This thread is full of people completely not understanding why you keep talking about this the way you do. Smells like trolling.
When put in context its an obvious obscure corner case, it requires all these simultaneously:- slow/infrequent trigger rate (compared to the detail window being viewed)
- interesting detail at short time window
- possibly interesting detail in the larger capture (but can't rely on another trigger arriving)
- unwillingness to use a zoom window
You just draw out the discussion endlessly with distractions and nonsense. You've got a workflow that works for you, great. You'd like to see it available on more scopes, great, write to the manufacturers. But stop arguing that this workflow is somehow important for others to consider if you can't motivate us to its benefits.
So lets consider your latest point by point:
Read the comments to Dave's video; you'll see that many people are using zoom-out and consider it a standard DSO feature.
Some people, no measure of how significant that is.
All in all the reality is that your statement is the other way around; there are a limited number of people who:
1) Don't understand the benefit because they don't need it and somehow are opposed to it as a result or maybe because they want a solution which works for 10 out of 10 cases instead of one which is faster but only covers 9 out of 10 cases.
2) Have a vested interest in a brand which doesn't support 'zooming out' and keep spreading marketing wank.
Not sure how any of that is part of the discussion and what I've been saying. You have this list of constraints (above) which are unstated but you are sure everyone else values them and has them in place.
It is not my function to explain things in depth. I'm not getting paid for that so be happy with what I give you for free. I just point out how to do things more efficiently (less twiddling of knobs) and oppose marketing wank.
More efficiently? Use the zoom, zero controls to be touched or adjusted. Sounds more efficient to most people.
You have these (continually unstated) constraints which are essential to make your arguments. We're pointing out how a) they are silly, b) they're a very narrow corner case rarely encountered, and c) how other options trade off different priorities/values.
But sure keep, coming back with one liners about how specific brands and models cant do the job. Or we don't know anything can can't use scopes properly.
-
But sure keep, coming back with one liners about how specific brands and models cant do the job. Or we don't know anything can can't use scopes properly.
Nice try to twist my words but I'm not going to let you bait me into endless circular discussions as you did with Wuerstchenhund.
-
But sure keep, coming back with one liners about how specific brands and models cant do the job. Or we don't know anything can can't use scopes properly.
Nice try to twist my words but I'm not going to let you bait me into endless circular discussions as you did with Wuerstchenhund.
:-DD |O
And what do you call this ?
@Tautech: please stop making a fool out of yourself by pretending everyone but you is stupid. DSOs have had zoom mode and math since the late 80's. Oscilloscope users are well aware that it exists; there is nothing new or special about zoom mode and math these days.
When I give a further indepth reply to a member that was proven to help their understanding and done in a way for other readers to understand and you nitpick through it.
You my man are the incessant troll and barely worth the effort to type a reply.
Instead I suggest you direct your energies to lobby KS for far greater memory depth in their instruments so you can have the instrument you want but don't like in its current configuration.
Good luck you'll need it.
-
Know this isn't directly related to the Zoom topic, but think it's a worthwhile perspective.
Joined this a year ago to collect information on purchasing a new DSO, in past had only considered Tektronix, HP/AG/KS (some R&S) equipment but knew this would be out of my budjet since it was now out of my pocket (retired), not the company's. After a little time it came clear who the Fan boys/girls, unbiased, informed, uninformed, and just plain no-valued-added individuals were. Some seem to provide no worthwhile input other than criticizing everyone and everything else that doesn't fit their agenda.
Sure early on I knew tautech was a Siglent dealer, but he provided significant worthwhile information while limiting bashing others or brands unless provoked. Recently he even downplayed the new low end Siglent DSO, so not just spewing mis-informantion like many, but provided a valuable perspective especially for a newcomer interested in a low end DSO. He also provides guidance to those that want to "hack" their equipment and even provided help with a few that are trying to DIY replicate the Siglent Logic Analyzer probe.
The constant criticism and no-valued-added responses from some just take away from the excellent information and guidance from those that are informed, especially true for newcomers that haven't developed the "read-between-the-lines" skills yet!!
BTW we selected a Siglent SDS2102X Plus (4X was BO), and used the Zoom function a few times, not a Zoom connoisseur like some, but worked fine for we've needed.
Best,
-
Thats a Rigol (the specific brand you asked for) causing aliasing or slow update rates if the user selects an inappropriate memory depth.
Any 'scope can have pathologically slow combinations of memory depth/sample rate.
eg. If you tell a Rigol DS1054Z to use 24Mb memory with 25kSamples/sec. sample rate then yes, it takes 10 seconds to refresh the screen. It's math.
This isn't what's being discussed here though so let's not pretend that it is. If I tell a Siglent to use all the memory then it should use it.
-
Know this isn't directly related to the Zoom topic, but think it's a worthwhile perspective.
Joined this a year ago to collect information on purchasing a new DSO, in past had only considered Tektronix, HP/AG/KS (some R&S) equipment but knew this would be out of my budjet since it was now out of my pocket (retired), not the company's. After a little time it came clear who the Fan boys/girls, unbiased, informed, uninformed, and just plain no-valued-added individuals were. Some seem to provide no worthwhile input other than criticizing everyone and everything else that doesn't fit their agenda.
Sure early on I knew tautech was a Siglent dealer, but he provided significant worthwhile information while limiting bashing others or brands unless provoked. Recently he even downplayed the new low end Siglent DSO, so not just spewing mis-informantion like many, but provided a valuable perspective especially for a newcomer interested in a low end DSO. He also provides guidance to those that want to "hack" their equipment and even provided help with a few that are trying to DIY replicate the Siglent Logic Analyzer probe.
The constant criticism and no-valued-added responses from some just take away from the excellent information and guidance from those that are informed, especially true for newcomers that haven't developed the "read-between-the-lines" skills yet!!
BTW we selected a Siglent SDS2102X Plus (4X was BO), and used the Zoom function a few times, not a Zoom connoisseur like some, but worked fine for we've needed.
Best,
Thank you for attempting to keep a positive tone - it is entirely possible to disagree while still being civil about it... it is just so bloody HARD when there are so many idiots in the world who won't see things your way! :D
-
Thank you for attempting to keep a positive tone - it is entirely possible to disagree while still being civil about it... it is just so bloody HARD when there are so many idiots in the world who won't see things your way! :D
Someone once said "You can't win an argument with an idiot, they have more ammunition!" ::)
Best,
-
Thats a Rigol (the specific brand you asked for) causing aliasing or slow update rates if the user selects an inappropriate memory depth.
Any 'scope can have pathologically slow combinations of memory depth/sample rate.
eg. If you tell a Rigol DS1054Z to use 24Mb memory with 25kSamples/sec. sample rate then yes, it takes 10 seconds to refresh the screen. It's math.
This isn't what's being discussed here though so let's not pretend that it is. If I tell a Siglent to use all the memory then it should use it.
Read your own words, that I quoted in full, and will do so again with the expanded context 2N3055 very clearly explained:
LeCroy, Siglent, Picoscope, Rigol (by default AUTO strategy), R&S (by default AUTO strategy), Keysight Infiniivision (Run mode), Micsig (by default AUTO strategy) and all others that have AUTO memory mode use that same method of only grabbing only amount of data that is equivalent to length of screen in current timebase. They all do it to minimize amount of data taken in every trigger to get faster reacting scope and keep sampling rate high to avoid aliasing. It is like analog scope, you see what you see. There is NO data before or after screen, and there is no need to. If you want to see more, you put more time ON the screen. Benefit of digital scope is that you can stop it and then zoom in and still see details.
Are you saying Keysights are slowed down and/or suffer aliasing because of this? My Rigol certainly wasn't.
Two entirely different behaviours of aliasing and update rate, joined together into a barely coherent point. Lets take them all apart since you don't seem to understand the underlying behaviours.
Aliasing does occur if you don't leave the memory on auto (and sometimes even if you do), on the Rigol scope. Its extremely hard to get aliasing artefacts to show on the Keysight Infiniivision (mega-zoom) scopes, switching from normal to high-res mode makes it worse but still very minor.
You joined a Rigol scope (that does suffer aliasing) in with a scope that effectively doesn't. No differentiation, just trying to say they are the same. They are different there. They are also different that the Keysight mega-zoom scopes don't offer the manual memory settings to create long captures outside the visible window (that reduces update rates).
So trying to say they are the same on either of these points is completely untrue. I pointed that out and showed previous examples of the Rigols behaviour.
Note that the keysight mega-zoom can't have pathologically slow combinations as they don't offer the controls to set that (and the other scopes that refuse to leave memory outside the visible window). So you're still pushing further misleading information, trying to make a generalisation that all scopes are impacted the same when they aren't.
There are a group of scopes which force the user to maximise information reaching the screen, and there are a group of scopes which let the user capture data outside the screen. This entire thread. But you seem to get it disastrously wrong and add yet more noise to whats rapidly becoming a dumpster fire (people don't bother to read the content and keep bringing up the same questions/wrong information over and over, suggesting the correct/accurate information is buried).
-
There are a group of scopes which force the user to maximise information reaching the screen, and there are a group of scopes which let the user capture data outside the screen. This entire thread.
The ONLY point I'm making is that the two aren't exclusive.
The argument being made in this entire is that the Siglent doesn't allow zoom out because it would slow down disastrously. That's not true, and that's the point I was trying to make by example. Keysights don't slow down, Rigols don't slow down... not unless you pick a pathological combination of sample rate and buffer size. Both Keysights and Rigols allow zoom out (among others).
That's it. That's the total of what I'm trying to say.
If this thread is a "dumpster fire" it's because the Siglent people refuse to accept the simple facts and are trying to deflect the plain truth via. hand waving.
-
There are a group of scopes which force the user to maximise information reaching the screen, and there are a group of scopes which let the user capture data outside the screen. This entire thread.
The ONLY point I'm making is that the two aren't exclusive.
The argument being made in this entire is that the Siglent doesn't allow zoom out because it would slow down disastrously. That's not true, and that's the point I was trying to make by example. Keysights don't slow down, Rigols don't slow down... not unless you pick a pathological combination of sample rate and buffer size. Both Keysights and Rigols allow zoom out (among others).
That's it. That's the total of what I'm trying to say.
If this thread is a "dumpster fire" it's because the Siglent people refuse to accept the simple facts and are trying to deflect the plain truth via. hand waving.
Scopes slow their waveform rate if they are capturing data outside the screen. True, proven, tested.
It doesn't happen on the Keysight Infiniivision/megazoom models as they don't do it, despite what you think, they aren't capturing the data outside the screen constantly.
It does happen on the Rigol:
https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038 (https://www.eevblog.com/forum/testgear/new-tektronix-tbs2000-oscilloscopes/msg1283038/#msg1283038)
Adding more memory depth does slow down the Rigol DS1054, regardless of if that adds capture outside the screen or not.
Keysight Infiniivision/megazoom scopes do slow down when adding more memory, its well hidden and hard to get the data, but its still true:
https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/msg973064/#msg973064 (https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/msg973064/#msg973064)
They slow down so much less than other scopes (it appears to be their major design goal and marketing point regardless of the true benefits) that there is no option to reduce the memory depth because it is such a small penalty compared to other competitive products.
Selecting more memory on the Rigol is guaranteed to slow it down in almost every single realistic case (waiting for you to do the classic fanboy thing and jump on one of the obscure cases where that was reversed).
The list of examples above that 2N3055 collected summed this up really clearly:
LeCroy, Siglent, Picoscope, Rigol (by default AUTO strategy), R&S (by default AUTO strategy), Keysight Infiniivision (Run mode), Micsig (by default AUTO strategy) and all others that have AUTO memory mode use that same method of only grabbing only amount of data that is equivalent to length of screen in current timebase. They all do it to minimize amount of data taken in every trigger to get faster reacting scope and keep sampling rate high to avoid aliasing.
Thats it, there are some scopes that don't let you set the capture window larger than the window visible on the screen. Its a valid design decision and one I prefer.
-
If this thread is a "dumpster fire" it's because the Siglent people refuse to accept the simple facts and are trying to deflect the plain truth via. hand waving.
No Sir.
-
there are some scopes that don't let you set the capture window larger than the window visible on the screen. Its a valid design decision and one I prefer.
Sure, but it's often useful and you should be allowed to override the behavior if you want to.
https://youtu.be/bVxDibdosdI?t=741
Surely the Siglent won't slow down because you use more than 10 bytes of memory...? :-//
-
In another thread some users claimed that the Siglent 5000 series DOES have zoom out capability.
I just tried on the SDS5104X and it does NOT in Auto memory mode but it DOES in fixed memory depth mode.
I think zoom mode might have been mentioned, but that's not the point.
-
In another thread some users claimed that the Siglent 5000 series DOES have zoom out capability.
I just tried on the SDS5104X and it does NOT in Auto memory mode but it DOES in fixed memory depth mode.
I think zoom mode might have been mentioned, but that's not the point.
Memory management and its options/guises are a recently added feature to SDS5000X in the FW version V0.9.7R2 before last.
It was developed in SDS2000X HD and SDS6000A.
-
Memory management and its options/guises are a recently added feature to SDS5000X in the FW version V0.9.7R2 before last.
It was developed in SDS2000X HD and SDS6000A.
aah interesting... so maybe it could be coming to any other remaining models featuring same / similar shared firmware platform? Or perhaps it requires a specific set of hardware common in those listed above? ^^
-
Memory management and its options/guises are a recently added feature to SDS5000X in the FW version V0.9.7R2 before last.
It was developed in SDS2000X HD and SDS6000A.
aah interesting... so maybe it could be coming to any other remaining models featuring same / similar shared firmware platform? Or perhaps it requires a specific set of hardware common in those listed above? ^^
It would be an FPGA capture architecture thing I think, not the processor firmware as such.
-
Memory management and its options/guises are a recently added feature to SDS5000X in the FW version V0.9.7R2 before last.
It was developed in SDS2000X HD and SDS6000A.
So still not available on the 2000X?
-
I just tried on the SDS5104X and it does NOT in Auto memory mode but it DOES in fixed memory depth mode.
If you still got a MSO5000, try the same on it.
-
Memory management and its options/guises are a recently added feature to SDS5000X in the FW version V0.9.7R2 before last.
It was developed in SDS2000X HD and SDS6000A.
aah interesting... so maybe it could be coming to any other remaining models featuring same / similar shared firmware platform? Or perhaps it requires a specific set of hardware common in those listed above? ^^
It would be an FPGA capture architecture thing I think, not the processor firmware as such.
That is correct.
-
If you still got a MSO5000, try the same on it.
I don't, Rigol wanted it back.
-
IF I remember it right, you can´t zoom out when auto memory is active on the MS5000.
Someone got to test it..
-
Memory management and its options/guises are a recently added feature to SDS5000X in the FW version V0.9.7R2 before last.
It was developed in SDS2000X HD and SDS6000A.
So still not available on the 2000X?
SDS2000X has been phased out. But no,the new Memory management featureset has not been implemented in SDS2000X Plus and TBH I'm not sure that it can be. However I'd imagine Siglent wish to maintain a point of difference between it and the 12 bit SDS2000X HD.
Dave, you have a KS3000 in the lab right ? With the feeble memory depth they have how far can they zoom out on a capture from say 1ns vs your SDS5104X in Fixed memory mode ?
-
Checked once the zoom out on the 2K HD:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-12bit-(published-for-chinese-domestic-market-only)/msg4291393/#msg4291393 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-12bit-(published-for-chinese-domestic-market-only)/msg4291393/#msg4291393)
-
Dave, you have a KS3000 in the lab right ? With the feeble memory depth they have how far can they zoom out on a capture from say 1ns vs your SDS5104X in Fixed memory mode ?
Using my MSO-X 3024A, acquired at 2ns/div which is as high as it would go. Pressed Stop and zoomed out until I could see the ends of the data. Looks like it uses 2Mpoints for zoom out in this case.
EDIT:
Tried again using Single trigger mode instead of Stop and it had twice as much data, so 4Mpoints. Not going to upload another picture so you'll have to take my word.
-
Checked once the zoom out on the 2K HD:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-12bit-(published-for-chinese-domestic-market-only)/msg4291393/#msg4291393 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-12bit-(published-for-chinese-domestic-market-only)/msg4291393/#msg4291393)
Yeah, nah.
With a fast timebase setting and only in Fixed mem mode how far (timebase steps) can you actually zoom out before the capture won't fill the display ?
-
My opinion is that right way to test it is:
Set trigger mode to Normal trig. Not Auto or Single.
Don't use Stop button. When normal acquisition is running just remove signal so it cannot trig anymore and cannot do new extra last acquisition with possible more memory (HPAK).
After then stop and zoom out.
-
Dave, you have a KS3000 in the lab right ? With the feeble memory depth they have how far can they zoom out on a capture from say 1ns vs your SDS5104X in Fixed memory mode ?
Irrelevant to the discussion of zoom out capability. Now you are just talking memory depth. The answer is of course 4M worth at your current timebase.
-
Dave, you have a KS3000 in the lab right ? With the feeble memory depth they have how far can they zoom out on a capture from say 1ns vs your SDS5104X in Fixed memory mode ?
Irrelevant to the discussion of zoom out capability. Now you are just talking memory depth. The answer is of course 4M worth at your current timebase.
Also related to sampling rate. ;)
-
Dave, you have a KS3000 in the lab right ? With the feeble memory depth they have how far can they zoom out on a capture from say 1ns vs your SDS5104X in Fixed memory mode ?
Irrelevant to the discussion of zoom out capability. Now you are just talking memory depth. The answer is of course 4M worth at your current timebase.
|O
Buuhh... of course zoom out capability need more memory depth than screen width when oscilloscope run example in full screen zoomed in mode. As they do when it capture more than what is display width without display splitted zoom. What is so difficult here and specially for experts, engineers... or even journalists of the (technical) yellow media, whoever.
-
Dave, you have a KS3000 in the lab right ? With the feeble memory depth they have how far can they zoom out on a capture from say 1ns vs your SDS5104X in Fixed memory mode ?
Irrelevant to the discussion of zoom out capability. Now you are just talking memory depth. The answer is of course 4M worth at your current timebase.
|O
Buuhh... of course zoom out capability need more memory depth than screen width when oscilloscope run example in full screen zoomed in mode. As they do when it capture more than what is display width without display splitted zoom. What is so difficult here and specially for experts, engineers... or even journalists of the (technical) yellow media, whoever.
Chill out. tautech is just doing his usual thing of taunting me and doing the Siglent wank thing. I wasn't going to play the game.
-
Play this game:
Leo Bodnar 10 MHz pulser, SDS6204A Normal triggering, Fixed Mem depth (500 MPts), ERES = OFF = 5 GSa/s for others to more easily play along, starting from 500ps/div in Dots mode, dots just visible @ ~3/div (png3)
Some 23 timebase steps (500ps - 20ms) before the display is no longer full from zooming out.
Maybe it is time for Dave to edit his BS about crippling zoom out modes.
-
Play this game:
Leo Bodnar 10 MHz pulser, SDS6204A Normal triggering, Fixed Mem depth (500 MPts), ERES = OFF = 5 GSa/s for others to more easily play along, starting from 500ps/div in Dots mode, dots just visible @ ~3/div (png3)
Some 23 timebase steps (500ps - 20ms) before the display is no longer full from zooming out.
Maybe it is time for Dave to edit his BS about crippling zoom out modes.
No I will not play your stupid game by comparing a scope with 500M of memory vs one with 4M, bugger off.
-
Memory management and its options/guises are a recently added feature to SDS5000X in the FW version V0.9.7R2 before last.
It was developed in SDS2000X HD and SDS6000A.
aah interesting... so maybe it could be coming to any other remaining models featuring same / similar shared firmware platform? Or perhaps it requires a specific set of hardware common in those listed above? ^^
It would be an FPGA capture architecture thing I think, not the processor firmware as such.
That is correct.
So the SDS2000X+ doesn't have a compatible hardware architecture for the new memory management?
-
Trying out posting in the Oscilloscope Zoom Out Quirk thread with quoted messages from a different thread, so as to retain all context while posting in the proper thread ...
There is no free lunch. There is no data being captured outside set time. It is only that you can set time by obscure mental calculation (flying blind and calculating sample rate/ manual memory length ratio) or by simply setting proper time base in a first place...
You keep on repeating this but it isn't true. In fact for many of the measurements I do, I don't even care about time/div setting. And in some cases (like verifying protocol bitrates which can be off by a factor 100) I don't even know which time/div setting I'd need to use to get the signal on screen.
Well, if you don't care about the timebase setting then that means you can set it to whatever setting gets you the maximum amount of time on the screen while retaining the scope's full sample rate (or to capture however much time you like), right? This means that, for these use cases at least, the Siglent approach will work just fine for you. What, then, is the problem?
The deep memory simply makes sure there is always enough data. I make a measurement and twist the time/div knob until there is a visible signal. Then I use a measurement and / or cursors to tell me what I want to know. There is zero mental calculation and zero preparation.
OK, but you have to set the timebase to something. How do you set it on your scope so as to get the maximum capture depth while also retaining the sample rate you want?
On the Siglent, this is directly visible, especially on the 2k+ and up. The little timebase box at the bottom of the screen shows the sample rate, the memory depth, and the timebase. This makes it trivial to set the scope up to capture into the entirety of available memory while retaining the maximum sample rate.
For the scopes you use, does it always capture into all available memory irrespective of your timebase? My Instek does, except that I have to always define the amount of available memory (in points), and if I define it to be less than the amount the scope has, then it will simply leave the rest unused, while the Siglent will use the remainder for remembering prior captures.
But we have been around this before. It is like the eternal discussion about automatic / stick shift in cars. The thing is a good DSO offers both so everyone can be happy.
I completely agree, and I'm happy that Siglent has seen the light on this. But how many offer both "what you see is all you get" and "a capture always uses all the available memory", selectable by the user?
Again: suggesting to use the zoom window is just stupid. Especially on the lower end scopes, the zoom window takes away a significant portation of the already small screen. It doesn't help improve the useability especially if you have a bunch of traces and protocol decoding enabled.
That's true on the lower end scopes. The higher end scopes have enough real estate and resolution that zoom mode is very functional, even with protocol decoding and multiple traces. If you're stopping the scope (either because you used single capture or because you manually stopped the scope), then you can use the full screen to move around and zoom in and out within the capture as you please.
I will say this: for single capture mode, it really should use all the available memory always. This is because the history buys you nothing, since each time you press the "single" button it'll clear the history, so the scope may as well use all the memory for the one capture you're performing. This is the one exception that Siglent should have made to the "what you see is all you get" behavior from the start. Either that, or it should remember prior captures as long as the capture parameters (timebase, trigger settings, etc.) remain the same.
-
I find R&S, LeCroy, Siglent, Picoscope type of history buffers (that actually remember 1000s of previous triggers) much more important and useful. That is the feature that I would take into account in purchasing decision. Why nobody speaks about that...?
I believe that's "history mode" on a Siglent. It's something you can enable/disable and nothing to do with the topic at hand.
https://siglentna.com/operating-tip/siglent-x-series-oscilloscopes-sequence-history-mode/
That's "sequence" history mode. That's different from the normal capture history. On my 2000X+, it's possible to appear to turn off the normal capture history, but it doesn't actually prevent the scope from placing captures into its history buffer.
Sequence history is part of the sequence mode and is for minimizing the trigger re-arm time and for eliminating the normal processing that goes into capturing, so as to make it possible to capture as many fast events as possible.
On the Siglent, captures always go into the history buffer. As long as the size of each capture is less than half of the total size of memory the scope has, you'll have a capture history in "normal" and "auto" trigger modes ("single" is a different matter).
In history mode it makes perfect sense to only save what's on screen, it maximizes the number of waveforms that can be stored.
Yes, and on the Siglent, the capture history is always present (save for single shot mode).
When I press the STOP button, or use a single shot trigger in normal mode? It makes no sense at all.
It makes sense for when you press the stop button. Otherwise there wouldn't be any point in having the normal capture history in the first place. You have to stop the scope in order to review the history, after all.
But I agree with you on single shot mode, since it always clears the history upon invoking that anyway, so it may as well use the entirety of memory for the single capture.
-
Trying out posting in the Oscilloscope Zoom Out Quirk thread with quoted messages from a different thread, so as to retain all context while posting in the proper thread ...
There is no free lunch. There is no data being captured outside set time. It is only that you can set time by obscure mental calculation (flying blind and calculating sample rate/ manual memory length ratio) or by simply setting proper time base in a first place...
You keep on repeating this but it isn't true. In fact for many of the measurements I do, I don't even care about time/div setting. And in some cases (like verifying protocol bitrates which can be off by a factor 100) I don't even know which time/div setting I'd need to use to get the signal on screen.
Well, if you don't care about the timebase setting then that means you can set it to whatever setting gets you the maximum amount of time on the screen while retaining the scope's full sample rate (or to capture however much time you like), right? This means that, for these use cases at least, the Siglent approach will work just fine for you. What, then, is the problem?
The deep memory simply makes sure there is always enough data. I make a measurement and twist the time/div knob until there is a visible signal. Then I use a measurement and / or cursors to tell me what I want to know. There is zero mental calculation and zero preparation.
OK, but you have to set the timebase to something. How do you set it on your scope so as to get the maximum capture depth while also retaining the sample rate you want?
You are overthinking it. Zen master says: 'Try not to find problems that aren't there'.
All DSOs except for the ones from Lecroy and some older Siglent models, allow at least to force full memory. And several offer an automatic mode. Maybe Siglent's change may also inspire Lecroy to rethink their memory management strategy.
-
...
I will say this: for single capture mode, it really should use all the available memory always. This is because the history buys you nothing, since each time you press the "single" button it'll clear the history, so the scope may as well use all the memory for the one capture you're performing. This is the one exception that Siglent should have made to the "what you see is all you get" behavior from the start. Either that, or it should remember prior captures as long as the capture parameters (timebase, trigger settings, etc.) remain the same.
There is a common scenario where history mode makes perfect sense even in single mode.
And that is when you are experimenting, you tweak something in your DUT (analog or digital) and take single capture, tweak few minutes, capture that ... Now you have 20 captures over 2 hours. You go in history mode and overlay them, measure, decode. compare..
You can save them for documentation if you want then.
I to do that on Picoscope all the time, now I can do it on both Pico and Siglents..
EDIT:
No you're right, it does not...
I must have confused it with something that was discussed..
Sorry!
-
Trying out posting in the Oscilloscope Zoom Out Quirk thread with quoted messages from a different thread, so as to retain all context while posting in the proper thread ...
There is no free lunch. There is no data being captured outside set time. It is only that you can set time by obscure mental calculation (flying blind and calculating sample rate/ manual memory length ratio) or by simply setting proper time base in a first place...
You keep on repeating this but it isn't true. In fact for many of the measurements I do, I don't even care about time/div setting. And in some cases (like verifying protocol bitrates which can be off by a factor 100) I don't even know which time/div setting I'd need to use to get the signal on screen.
Well, if you don't care about the timebase setting then that means you can set it to whatever setting gets you the maximum amount of time on the screen while retaining the scope's full sample rate (or to capture however much time you like), right? This means that, for these use cases at least, the Siglent approach will work just fine for you. What, then, is the problem?
The deep memory simply makes sure there is always enough data. I make a measurement and twist the time/div knob until there is a visible signal. Then I use a measurement and / or cursors to tell me what I want to know. There is zero mental calculation and zero preparation.
OK, but you have to set the timebase to something. How do you set it on your scope so as to get the maximum capture depth while also retaining the sample rate you want?
You are overthinking it. Zen master says: 'Try not to find problems that aren't there'.
All DSOs except for the ones from Lecroy and some older Siglent models, allow at least to force full memory. And several offer an automatic mode.
They all do that, allow user to force full memory. Some with manual memory settings and all of them with timebase.
My gripe with you quest on this is that you make it sound like you cannot do it, and not that you like certain way of doing it and insist it is only "righteous way". It's not. Timebase and zoom is achieving same purpose. You don't like that, fine. But it is there and the rest of us just use that.
That is all..
-
Maybe Siglent's change may also inspire Lecroy to rethink their memory management strategy.
I think it was the opposite, our newer lecroys from 2019 allowing to change between fixed memory or fixed samplerate - before siglent did anything in this direction.
Now you have it on the 2000HD, 5000 and 6000 models and AFAIK because of the "new" filter functions they got.
(This could be the reason why the 2000X+ didn´t get that)
Btw, I hate fullquotes... ;)
-
Where it comes to Lecroy my point of reference is their Wavepro 7k series. When I select a fixed memory depth on it, it treats that as the maximum memory. The actual memory length it uses, depends on the number of samples needed to fill the screen. IOW: it uses some kind of semi-auto mode which can be annoying at times. It is possible that Lecroy's newer software is more flexible where it comes to memory management.
-
More or less....
You really can choose only between fixed mem OR fixed samplerate, no auto mode.
Both, fixed mem and samplerate, can be adjusted.
-
...
I will say this: for single capture mode, it really should use all the available memory always. This is because the history buys you nothing, since each time you press the "single" button it'll clear the history, so the scope may as well use all the memory for the one capture you're performing. This is the one exception that Siglent should have made to the "what you see is all you get" behavior from the start. Either that, or it should remember prior captures as long as the capture parameters (timebase, trigger settings, etc.) remain the same.
There is a common scenario where history mode makes perfect sense even in single mode.
And that is when you are experimenting, you tweak something in your DUT (analog or digital) and take single capture, tweak few minutes, capture that ... Now you have 20 captures over 2 hours. You go in history mode and overlay them, measure, decode. compare..
You can save them for documentation if you want then.
Except that on the Siglent, you can't do this. I wish you could.
Whenever you hit the "single" button, it clears the history.
Did they change that behavior in the models above the 2000X+? Because you certainly can't get multiple history entries via "single" on the 2000X+.
-
...
I will say this: for single capture mode, it really should use all the available memory always. This is because the history buys you nothing, since each time you press the "single" button it'll clear the history, so the scope may as well use all the memory for the one capture you're performing. This is the one exception that Siglent should have made to the "what you see is all you get" behavior from the start. Either that, or it should remember prior captures as long as the capture parameters (timebase, trigger settings, etc.) remain the same.
There is a common scenario where history mode makes perfect sense even in single mode.
And that is when you are experimenting, you tweak something in your DUT (analog or digital) and take single capture, tweak few minutes, capture that ... Now you have 20 captures over 2 hours. You go in history mode and overlay them, measure, decode. compare..
You can save them for documentation if you want then.
Except that on the Siglent, you can't do this. I wish you could.
Whenever you hit the "single" button, it clears the history.
Did they change that behavior in the models above the 2000X+? Because you certainly can't get multiple history entries via "single" on the 2000X+.
HUh.. let me check this..
No you're right, it does not...
I must have confused it with something that was discussed..
Sorry!
-
Hmm....smells like a feature adding in future firmwares...
-
Hmm....smells like a feature adding in future firmwares...
Not that I know of, really I remember a lengthy discussion about it and probably something left in my head...
-
OK, but you have to set the timebase to something. How do you set it on your scope so as to get the maximum capture depth while also retaining the sample rate you want?
You are overthinking it. Zen master says: 'Try not to find problems that aren't there'.
Except I'm not overthinking it. It's simply a question of how to get the capture characteristics to be what you want them to be. Since there are situations in which you don't care about what the timebase setting is, it follows that you can then use the timebase to get the capture size you want in those situations. Point being that those situations, which you explicitly called out, are precisely the ones where you have the fewest valid objections to Siglent's "what you see is all you get" approach.
Where the scope behavior you advocate for becomes truly useful is when you do care about the timebase setting and you want to use all of the available (or configured) memory for the capture.
All DSOs except for the ones from Lecroy and some older Siglent models, allow at least to force full memory.
You can force full memory in all of the Siglent scopes. It's just a question of how to go about it. For the "what you see is all you get" scopes, you force that via the appropriate timebase setting.
It's a tradeoff. The downside of the "what you see is all you get" approach is that you don't get to use all of the configured memory while having a smaller timebase. The upside of it is that (save for the maximum capture buffer size, which is separately configured) you fully control the entire capture configuration with a single setting (the timebase) and you always know exactly what you're going to get without having to reference anything other than the timebase settings.
Ideally, you want to be able to choose which approach to take. Fortunately, Siglent has seen the light on that and now makes that possible.
One approach that no scope manufacturer I know of implements would be to allow the user to specify the maximum capture length as a multiple of the time represented by the screen as defined by the timebase setting So, for instance, you might set it to 10x, and thus you'd always capture 10 times the amount of time shown on the screen. Such an approach would retain the primary advantage of "what you see is all you get", namely that it would make it possible for you to always know exactly what you're going to get, and it would allow you to always zoom out by the configured amount. The remaining memory (if available) would then be used to store prior captures in the way Siglent already does.
And several offer an automatic mode.
It's not clear to me what specific advantages that would have, most especially if the particulars of "automatic mode" are manufacturer-specific, as I'd expect them to be.
-
The last scopes I got(private)/use(on work) having the auto mode as default setting.
-
OK, but you have to set the timebase to something. How do you set it on your scope so as to get the maximum capture depth while also retaining the sample rate you want?
You are overthinking it. Zen master says: 'Try not to find problems that aren't there'.
Except I'm not overthinking it. It's simply a question of how to get the capture characteristics to be what you want them to be. Since there are situations in which you don't care about what the timebase setting is, it follows that you can then use the timebase to get the capture size you want in those situations. Point being that those situations, which you explicitly called out, are precisely the ones where you have the fewest valid objections to Siglent's "what you see is all you get" approach.
I suggest you re-read this thread. I have tried to explain how & why zooming out is convenient in great detail as good as I can in previous posts. If you think that these situations are the ones where there are the fewest objections to not having zoom out, then I'm afraid I can't explain it in a way you can fully understand it. Trying to explain again, would take this discussion in a circle. For me the advantages are crystal clear though and a scope which can not zoom out would seriously hamper my workflow efficiency.
-
I suggest you re-read this thread. I have tried to explain how & why zooming out is convenient in great detail as good as I can in previous posts.
I don't disagree that being able to zoom out is very convenient under some circumstances. I wasn't disputing that. I was responding specifically to the situations you called out in which you said you don't care what the timebase setting is. Well, if you don't care what the timebase setting is, then what exactly is the advantage of being able to zoom out if you set the timebase to generate a maximum sized capture? Or, alternatively, what's the disadvantage of not being able to zoom out under those circumstances? You're probably twiddling the timebase knob either way in the event the timebase isn't something you care about, right?
If you think that these situations are the ones where there are the fewest objections to not having zoom out, then I'm afraid I can't explain it in a way you can fully understand it. Trying to explain again, would take this discussion in a circle. For me the advantages are crystal clear though and a scope which can not zoom out would seriously hamper my workflow efficiency.
Well, for any given situation, either you care about your timebase or you don't. I presumed that those situations in which you don't care about your timebase are ones in which you could set the timebase arbitrarily, in which case you could just as easily set it to something that guarantees a maximum-depth capture. If you want to be able to zoom out under those conditions, then you have to give up sample rate to do it.
So what exactly are you after under those conditions?
-
More choice is always good, but nctnico's unstated/shy/hidden refusal of zoom mode is around limitations of specific scopes (which are often not the scopes that this argument is "injected" into). It is valid for the very narrow case of those circumstances and specific scope, and the problem is it is presented as some generalisation or common issue completely out of context and unexplained.
Below is an attempt at a pictorial representation of some of the limitations/decisions/tradeoffs real people would consider.
If your scope only offers the first example of zoom (small view of trigger) it may well be impractical, or if zoom blocks some other function being used. But this is the sort of nuance that is never stated or avoided by nctnico, even when others are clearly saying and pointing to the second example (large view of trigger) at which point the argument that it is too hard to see becomes silly.
More choice, good.
Arguing people to un-mentioned corner cases to win internet argument, troll.
-
Data point on Micsig oscilloscopes. STO1104E allows to perform "zoom-out" if memory depth is set to manual mode (i.e. max 70M). In auto memory mode with most time bases there is no info beyond the data on screen. Memory size, sampling rate and time division settings are always shown on a screen and you can mentally calculate if the is data beyond the screen.
-
Memory size, sampling rate and time division settings are always shown on a screen and you can mentally calculate if the is data beyond the screen.
Alternatively: Just look at the little indicator at the top... :)
(https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/?action=dlattach;attach=1629049;image)
-
Good point, these icons represent memory situation clearly.
-
Memory management and its options/guises are a recently added feature to SDS5000X in the FW version V0.9.7R2 before last.
It was developed in SDS2000X HD and SDS6000A.
aah interesting... so maybe it could be coming to any other remaining models featuring same / similar shared firmware platform? Or perhaps it requires a specific set of hardware common in those listed above? ^^
It would be an FPGA capture architecture thing I think, not the processor firmware as such.
That is correct.
I think Siglent can make it with tweaking the zoom mode. IMHO, just turn the upper-split screen into a time zone strip and that might do the trick. I guess it depends on Siglent's decision rather than architecture limitation.