EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: awakephd on May 30, 2024, 12:06:57 am
-
As the title says, I am a newbie, at least when it comes to DSOs. I'm naught but a self-taught hobbyist when it comes to electronics in general, but I have been using an old analog Tektronix scope for 30+ years - but last night when my long-awaited Siglent SDS804X HD arrived was the first time I've ever even touched a DSO. Obviously, I have a good bit of learning to do, and I promise to do as much as I can via the manual, YouTube tutorials, and the like. But may I please ask a few questions here? Please, please, pretty please?
I'll limit myself to 2 questions to start:
Here's the first question I have after my initial bit of trying out the scope - a question that is generic to DSOs, not specific to this scope. Even after watching several zillion YouTube tutorials (the best ones I've found so far were an 18-video set from Keysight) and playing / experimenting with the scope, I don't really understand what the memory depth is doing for me. The specs say "Record length up to 50Mpts." How do I access those 50 million points? Do I initiate a recording? Is it always recording? Does this allow me to look forward and backward in time through a waveform?
Second question is specific to the SDS804X: I saw in another thread that new firmware has just very recently come out - 1.1.3.6 if I recall correctly. My scope shows 1.1.3.3, so I need to upgrade. Uhmm ... so far I haven't figured out a) where to get the firmware, and b) how to upgrade the scope. I realize that this one may be a matter of RTFM - I'm working on it! But I still have a long way to go ... and as I read the manual, I want to try things to be sure I'm understanding them ... and I don't know whether there is anything that will be substantially different in the UI after the upgrade, but if so, I'd rather be trying out the latest version rather than an earlier version ... so thus my question!
I thank you in advance for any help that anyone is willing to provide!
On edit: strike 2a above - I see that a link to download the new firmware is in another thread. I've downloaded the .zip file ... now what do I do with it??
-
Memory depth right now will mostly effect history for you (max data it can record). You don't need to worry too much about it, but if you want a faster response time from your scope, lower memory depth will usually perform faster. To learn more about it......RTFM. 😉
This is usually the best place to get your firmware: https://int.siglent.com/download/ - which currently you'll want: https://int.siglent.com/upload_file/zip/firmware/Oscilloscope/SDS800X_HD_V1.1.3.6_EN.zip
Then RTFM page 221: https://siglentna.com/wp-content/uploads/dlm_uploads/2024/02/SDS800X_HD_UserManual_EN01A.pdf
Thanks,
Josh
-
The specs say "Record length up to 50Mpts." How do I access those 50 million points? Do I initiate a recording? Is it always recording? Does this allow me to look forward and backward in time through a waveform?
It's always recording.
That's how much data is in memory when you press "STOP".
-
That's how much data is in memory when you press "STOP".
... except when it isn't (perhaps half or more of the time).
As per the manual:
Then RTFM page 221: https://siglentna.com/wp-content/uploads/dlm_uploads/2024/02/SDS800X_HD_UserManual_EN01A.pdf (https://siglentna.com/wp-content/uploads/dlm_uploads/2024/02/SDS800X_HD_UserManual_EN01A.pdf)
The actual sample points are related to the current time base and may be less than memory depth.
Here's the first question I have after my initial bit of trying out the scope - a question that is generic to DSOs, not specific to this scope. Even after watching several zillion YouTube tutorials (the best ones I've found so far were an 18-video set from Keysight) and playing / experimenting with the scope, I don't really understand what the memory depth is doing for me.
The headline figure of memory depth is not always available/used, and can vary in how its implemented between different scopes. But the manual (above does explain it simply) or focused articles such as:
https://www.rohde-schwarz.com/au/applications/importance-of-deep-memory-in-oscilloscopes-application-card_56279-409160.html (https://www.rohde-schwarz.com/au/applications/importance-of-deep-memory-in-oscilloscopes-application-card_56279-409160.html)
-
1. Memory depth is very helpful when you have a signal that you can't trigger on. Just press STOP and zoom in. If you have good memory depth, you'll see the signal in great detail when you zoom in. This is how you access those 50Mpts. Also memory depth is useful with single shot acquisitions, the more the better: with 100Mpts you can get 1 second of 100MS/s or 0.1seconds of 1GS/s, which is a lot! Also, with large memory you can enable segmentation mode that will allow you to capture at much greater waveform rate, so you can capture any glitches quicker. Large memory should also be helpful for some maths functions like FFT I assume.
2. Make sure you're on reliable power supply, preferably through UPS during firmware upgrade process..Get a FAT32 formatted USB drive and copy the firmware ADS file there. Select Utility -> Menu -> Maintenance -> Upgrade. Click Browse, then select the ADS file. Then touch the Recall icon. Then click Upgrade. I would also recommend to check out the manual. Unfortunately they don't include it with the scope. Perhaps it is the right thing to do because it must be aligned to current firmware. As pointed out by KungFuJosh, please get it from the website and have a read, besides some spelling mistakes it is pretty good.
-
That's how much data is in memory when you press "STOP".
... except when it isn't (perhaps half or more of the time).
Oh, I forgot... it's a Siglent. They don't zoom out.
https://www.youtube.com/watch?v=bVxDibdosdI (https://www.youtube.com/watch?v=bVxDibdosdI)
-
That's how much data is in memory when you press "STOP".
... except when it isn't (perhaps half or more of the time).
Oh, I forgot... it's a Siglent. They don't zoom out.
Like 99% of people expect a scope to work. But do continue adding more confusion for the person asking polite questions, then yet another thread can be filled with ZOOM OUT nonsense.
-
Like 99% of people expect a scope to work.
Dave certainly didn't expect it.
And I was told Siglent had stopped doing it, which is why I posted what I posted.
There's NO excuse for not filling the memory when you press STOP, sorry.
(and this is my last post on the subject here)
-
Oh, I forgot... it's a Siglent. They don't zoom out.
1. Totally incorrect, with the scope that is mentioned in this thread and all other Siglent DSO's !
2. Zoom mode provides all the zoom out capability one needs if, and if you know how to use it !
3. Siglent deep memory DSO's with Memory management features provide an order of magnitude more zoom out capability than most of the market leaders.
I challenged Dave on this recently and he didn't wanna play. :horse:
-
Interesting, I just tested this on my $150 scope. It does that.
Image1: Single shot @20ns/div.
Image2 : Zoom out to 2ms/div (max).
Image3: Zoom in to 2ns/div (min).
Image4: See what it looked like at -16ms (see value near “D”)
-
I challenged Dave on this recently and he didn't wanna play. :horse:
Because you're moving the goalposts. The Siglent way isn't the natural, logical, most useful way to work. If you want the full memory you have to work zoomed out without being able to see any detail, press STOP, then zoom in.
-
I challenged Dave on this recently and he didn't wanna play. :horse:
Because you're moving the goalposts. The Siglent way isn't the natural, logical, most useful way to work. If you want the full memory you have to work zoomed out without being able to see any detail, press STOP, then zoom in.
Here again you display knowledge lacking.
What prey tell is the Siglent way ?
Did you miss the bit where I mentioned those Siglent DSO's that offer Memory Management.
Goal posts ?
Different usage style just as Pico and LeCroy offer is quite natural for anyone using those brands.
Go pick a squabble with LeCroy converts for example and see how you get on. :horse:
I'll leave this here from SDS814X HD as an example of a valid use case, that being able to pan through a record to examine it in detail.
-
@ OP pls rtfm before saying things ... i had to read docs to understand a few things ... even for old turds like TEK tds 7k series who's are way older than me loll
-
As the title says, I am a newbie, at least when it comes to DSOs. I'm naught but a self-taught hobbyist when it comes to electronics in general, but I have been using an old analog Tektronix scope for 30+ years - but last night when my long-awaited Siglent SDS804X HD arrived was the first time I've ever even touched a DSO.
There is much to be learnt about SDS800X HD capabilities here:
https://www.eevblog.com/forum/testgear/sds800x-hd-review-demonstration-thread/ (https://www.eevblog.com/forum/testgear/sds800x-hd-review-demonstration-thread/)
Further, to assist others with these DSO's, general questions should be asked here to help serve as guidance for others:
https://www.eevblog.com/forum/testgear/siglent-sds800x-hd-12-bit-dsos-coming/ (https://www.eevblog.com/forum/testgear/siglent-sds800x-hd-12-bit-dsos-coming/)
-
Like 99% of people expect a scope to work.
Dave certainly didn't expect it.
Didnt expect what? Didn't know zoom out was a "thing" ? probably, zoom out is some obscure corner case that no-one was ever mentioning or talking about until a particularly noisy member on this forum decided to blow it out of proportion.
Dave jumped on the bandwagon and fuelled the flames.
Is it relevant to beginners or most people using scopes? No. There is no general use case for it. Despite all the noise it hasn't seen a significant practical use described over the well established tools of zoom windows.
-
All,
I hate that this is already devolving into arguments. That will make it harder for the newbie to sort the wheat from the chaff (it lowers the s/n ratio, to use an electronics metaphor). :(
I understand that everyone is passionate about their preferred brand, but from the perspective of a newbie, I don't and can't have any opinion on which is the "right" or "best" way to do something; if one scope does it this way and another does it that way, that is, ATM, just an "aha" for me. Eventually I may develop a preference, and perhaps, in time, I too will be converted into righteous indignation when anyone attempts to suggest it should be done some other way. For now, I'm just trying to figure the bloody thing out! All that to say, if it is possible, if you would be willing, it would help me tremendously to state things more in terms of "this is how brand x does it" rather than "brand x is stupid and defective for doing it that way." :)
The link to Dave's video was actually very helpful for me in making sense of what memory depth is. I confess that i was assuming it would work more like the Keysight, which is part of why I was having trouble understanding - I hit "stop," but there was no data past the end of the screen. I think I am now understanding that, for the Siglent and a few others, what is captured is only what fits on the screen at a given moment - thus, one must zoom out, capture, then zoom in to see detail. Right? Maybe?
To take a practical example, if I am trying to decode some messages on an SPI bus, here is what I think I am understanding: On the Siglent, I will need to show "all" of the messages on the screen to capture them - even though at that point they will be so squished together than I can't discern the content of any of the messages. Then, once capture, I can zoom in and scroll through to see the actual content of the messages. Have I got it right?
One more possibly related question. I feel rather dumb for asking this, but ... I think I have just begun to realize that the "trigger point" of the waveform on the screen is actually in the center of the screen (by default), meaning that the scope is showing me events that happened before the trigger. Is that correct? Unless I have completely forgotten what I have done in the past with my old analog Tektronix, this is very different behavior, as the analog scope starts the sweep at the trigger, meaning that anything prior to the trigger simply cannot be shown. Clearly this is a huge advantage for the DSO! And if I understand correctly, I can adjust the trigger point left and right, so that I see less of what happened prior to the trigger and more after, or vice versa.
I will greatly appreciate your (hopefully gentle) correction and redirection if I have muddled up any of the above. I am learning! And I am working my way through the manual! Now I just need more time ... irritating that work is getting in the way of pursuing my hobby, but there it is ...
-
Yes to both your questions.
For H Pos, go into System setting and change H Pos to Position.
After doing this, wherever you have it on the display it will remain exactly there when you adjust the timebase.
-
The link to Dave's video was actually very helpful for me in making sense of what memory depth is. I confess that i was assuming it would work more like the Keysight, which is part of why I was having trouble understanding - I hit "stop," but there was no data past the end of the screen. I think I am now understanding that, for the Siglent and a few others, what is captured is only what fits on the screen at a given moment - thus, one must zoom out, capture, then zoom in to see detail. Right? Maybe?
That depends on the Siglent model you have. I believe the recent Siglent models support the 'industry standard' way of capturing data beyond the edges of the screen when set to manual record length. So you need to set the maximum memory depth and check if the record length as shown on screen is actually the length you have specified. If your Siglent supports capturing data beyond the edges of the screen, then you should be able to zoom out or scroll left/right after a capture. One extra condition is that the time/div setting has to allow for capturing more data than fits on the screen. The tipping point is when setting the time/div long enough so that the samplerate drops (gets lowered) in order to capture enough points to fill the screen.
To take a practical example, if I am trying to decode some messages on an SPI bus, here is what I think I am understanding: On the Siglent, I will need to show "all" of the messages on the screen to capture them - even though at that point they will be so squished together than I can't discern the content of any of the messages. Then, once capture, I can zoom in and scroll through to see the actual content of the messages. Have I got it right?
On Siglent no. Siglent only decodes the portion of a signal shown on a screen. If you want to scroll through messages in detail without losing oversight (or have decoded data while the start of the message is not on screen), you'll need to open the zoom window to force the messages on the screen (even though they may not be readable) and then you can scroll through them to see the details.
-
I think I am now understanding that, for the Siglent and a few others, what is captured is only what fits on the screen at a given moment - thus, one must zoom out, capture, then zoom in to see detail. Right?
Right.
(...and it's NOT a natural way to work, no matter how much the Siglent people spin it)
There's hundreds of EEVBLOG threads discussing this so I'll shut up (again).
-
I think I am now understanding that, for the Siglent and a few others, what is captured is only what fits on the screen at a given moment - thus, one must zoom out, capture, then zoom in to see detail. Right?
Right.
(...and it's NOT a natural way to work, no matter how much the Siglent people spin it)
There's hundreds of EEVBLOG threads discussing this so I'll shut up (again).
This can't be the case, since modern DSOs are very easy to comprehend, and all beginners have to do is press the "auto" button.
(I'll shut up now, unless provoked :) )
-
The Siglent way isn't the natural, logical, most useful way to work. If you want the full memory you have to work zoomed out without being able to see any detail, press STOP, then zoom in.
Can you think of a case where you don't want "full memory", at least not on each waveform capture?
-
I think it's funny that some members need to jump in and whine about the workflow of one brand vs. another brand, when we all know that even the top historical A brands have their own workflows that sometimes contradict each other.
The OP bought a nice entry level Siglent scope, and he wants to learn to use it better. It's hardly useful to complain about workflow comparisons when 1. the OP wants to learn to use his new scope, and 2. other brands that he doesn't own aren't relevant, especially as he mentioned this is his first DSO.
-
I don't really understand what the memory depth is doing for me.
Set your scope up with a 1MHz input signal from whatever you have available, then change the timebase to 10ms/div. Press your "SINGLE" button to get a single freeze frame. Then start turning the horizontal timebase knob to zoom in on the signal. Once you can see your 1MHz waveform, use the horizontal position knob to scan through your captured signal.
-
I was able to take a few minutes on break to experiment a little further. I now understand much, much better what I am seeing: If I pay attention to the horizontal information in the little box at the bottom center right, it shows not only the current time per division, but also the total memory points that will be captured and the sampling rate at which they will be captured. As I adjust the horizontal timebase setting, I can see exactly what I am going to get if / when I press the run/stop button. (And presumably likewise if I do a single sweep?) So if for some reason I need to see the absolute maximum number of points sampled at the absolute highest rate, I can select the timebase that shows 50M and 2Gs and click on Run/Stop.
I realize that for those of you familiar with the Siglent or similar machines, I am telling you what you already know! And worse yet, my example above is probably ridiculously contrived and not something I will ever need in the real world. But now that I know, it all seems so simple, and I feel so delightfully empowered ...
... until I run into the next thing that I don't understand, which no doubt will come soon. I will no doubt be back with yet another example of my ignorance in search of enlightenment. :)
-
Just take your time and enjoy the trip..
-
To take a practical example, if I am trying to decode some messages on an SPI bus, here is what I think I am understanding: On the Siglent, I will need to show "all" of the messages on the screen to capture them - even though at that point they will be so squished together than I can't discern the content of any of the messages. Then, once capture, I can zoom in and scroll through to see the actual content of the messages. Have I got it right?
This is where you might want to explore the sequence/history mode, which can capture packets each on their own acquisition "screen" without all the quiet/empty bits in between. That will be quicker to step through but depends if there is enough gap between the data to cleanly separate them. Or use triggers to capture the message/signal/packet/byte that you are specifically interested in. Or as posted above, have the zoom window open so you can see both the long and short timeframe.
Using the horizontal timebase control alone is just one way to work, and unlikely the best way to navigate the data.
One more possibly related question. I feel rather dumb for asking this, but ... I think I have just begun to realize that the "trigger point" of the waveform on the screen is actually in the center of the screen (by default), meaning that the scope is showing me events that happened before the trigger. Is that correct? Unless I have completely forgotten what I have done in the past with my old analog Tektronix, this is very different behavior, as the analog scope starts the sweep at the trigger, meaning that anything prior to the trigger simply cannot be shown. Clearly this is a huge advantage for the DSO! And if I understand correctly, I can adjust the trigger point left and right, so that I see less of what happened prior to the trigger and more after, or vice versa.
This is where the deep/long memory is an advantage, you can put the trigger as far to the right as the memory will support! Viewing data from before the trigger with your own little time machine.
-
The link to Dave's video was actually very helpful for me in making sense of what memory depth is. I confess that i was assuming it would work more like the Keysight, which is part of why I was having trouble understanding - I hit "stop," but there was no data past the end of the screen. I think I am now understanding that, for the Siglent and a few others, what is captured is only what fits on the screen at a given moment - thus, one must zoom out, capture, then zoom in to see detail. Right? Maybe?
No, there is no extra detail from capturing a longer screen and then zooming in. If anything it presents the risk of capturing less high frequency detail if increasing the timebase caused the scope to reduce the sample rate (due to hitting its memory depth limit).
In run mode (not single capture mode) the keysight models do not capture around the visible window all the time, it's a "bonus" that occurs some times. Some other brands do it all the time, but that slows the update rate and triggers/information may never reach the screen:
(https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/?action=dlattach;attach=1623970;image)
-
You have to realise though that when doing protocol decoding, you don't want multiple trigger events in a single screen because the protocol decoding can decode one trace only. So typically triggering is set to normal and the signals are generated by instructing the DUT to do so. All in all a very slow process which doesn't need fast waveform updates at all. In most cases you want a record which is as long as possible. Capturing beyond the screen helps to look at the cause & effect of what has been captured. For example: sometimes there is a surprise and having more data is extremely helpfull to catch would could become an elusive bug, early on in the development process. But even without a need, capturing beyond the screen typically makes it not necessary to mess with the oscilloscope settings before having the DUT sending new data. Just scrolling left / right a bit to bring the section of interest on screen is enough.
-
But now that I know, it all seems so simple, and I feel so delightfully empowered ...
Lots of memory points are handy on occasion, but to really be able to use an oscilloscope you have to understand triggering. And that is not simple. Most scope work (or at least a lot of it) can be done with a few thousand points. I even have one with less than 1k points and while that can be a limitation, it is pretty good at what it does.
-
Capturing beyond the screen helps to look at the cause & effect of what has been captured.
You're really going to push your single minded position that this is the true/only/correct way to do things? While conveniently avoiding mentioning the use of a zoom window to see everything simultaneously without any hidden surprises...
and people wonder why the signal to noise is so low here.
:horse:
-
But now that I know, it all seems so simple, and I feel so delightfully empowered ...
Lots of memory points are handy on occasion, but to really be able to use an oscilloscope you have to understand triggering. And that is not simple. Most scope work (or at least a lot of it) can be done with a few thousand points. I even have one with less than 1k points and while that can be a limitation, it is pretty good at what it does.
Very true.
For complex triggers related to digital signals, logic analysers and protocol analysers excel. They are much more effective (than scopes) at reducing the amount of non-information the user needs to ignore. That leaves us to concentrate on the useful information.
As with all things, carefully select the right type of tool for the task.
-
Capturing beyond the screen helps to look at the cause & effect of what has been captured.
You're really going to push your single minded position that this is the true/only/correct way to do things? While conveniently avoiding mentioning the use of a zoom window to see everything simultaneously without any hidden surprises...
I'm not pushing anything on anyone. I want to show what is possible; how making measurements can be more efficient and effective. Just showing how to potentially use a tool more effectively depending on the situation. I leave the choice to the reader to judge whether it is useful for them or not. It is actually you who wants take options away from people in order to make everyone adhere to your limited, single minded way of thinking.
In the end there are more ways to skin a cat and some problems are better solved using a different approach which may not be obvious to those who never deal with such problems. You are kind of like my neurologist telling my surgeon on how to operate on my wrist. The neurologist complained the surgeon wanted to make a large cut in the palm of my hand leaving a big scar so his suggestion was to make a small cut on my wrist what would result in a much smaller scar. What the surgeon knew is that he could blend the scar in with one of the many creases in the palm of my hand and thus making the larger scar invisible. The neurologist overlooked that as surgery is not his field of expertise. Both have studied medicine, both are medical doctors but then specialisations and problems they deal with diverted.
-
But now that I know, it all seems so simple, and I feel so delightfully empowered ...
Lots of memory points are handy on occasion, but to really be able to use an oscilloscope you have to understand triggering. And that is not simple. Most scope work (or at least a lot of it) can be done with a few thousand points. I even have one with less than 1k points and while that can be a limitation, it is pretty good at what it does.
Very true.
For complex triggers related to digital signals, logic analysers and protocol analysers excel. They are much more effective (than scopes) at reducing the amount of non-information the user needs to ignore. That leaves us to concentrate on the useful information.
As with all things, carefully select the right type of tool for the task.
Since it is a beginner asking, you better explain what type of device you consider "logic analysers and protocol analysers".
Devices you are referring to are not manufactured anymore.
Today when you say "logic analysers and protocol analysers" people think you mean Saleae type USB device.
Which basically have no triggering to speak of, only very rudimentary one.
Actually, one of the reasons why some people buy MSO scopes is that they have better triggering than Saleae type devices.
-
To take a practical example, if I am trying to decode some messages on an SPI bus, here is what I think I am understanding: On the Siglent, I will need to show "all" of the messages on the screen to capture them - even though at that point they will be so squished together than I can't discern the content of any of the messages. Then, once capture, I can zoom in and scroll through to see the actual content of the messages. Have I got it right?
To a point.
Ideally we always want to see a truly stable waveform which signifies trigger settings are correct at least for basic decoding.
While there are several shortcuts to get a result my advice to get accustomed to the absolute power of the trigger suite you have.
Some KISS examples using a single channel for UART.
To get a properly stable waveform you need to prevent retriggering within a packet using a Holdoff time setting a little longer than a packet. How long is a packet is the first thing we need to know and for this we need get a few packets on the display and press Stop and eyeball its width against the graticules.
For these examples a 60ms Holdoff is just adequate to get rock solid stable triggering.
However, while we are still in the trigger menu, we need set the correct edge which for most protocols is Idle High so we need a falling edge trigger to mark the beginning of packet data.
Now we should have sound triggering however with the H Pos mid display there's only half the display to show full packets and their decode so we need move H Pos to the left with the encoder and set it in place with Utility/System Settings/Ref Position with H Pos set to Position.
The back of the job is now broken and just decode settings remain, assigning the correct channel/s and Threshold levels, Idle High in this case, baud rate etc.
As has been discussed Zoom mode can be useful now to display a # of packets to permit panning through them and the zoomed window for each packet decode or each byte.
Hoping the attached screenshots are of assistance.
-
Capturing beyond the screen helps to look at the cause & effect of what has been captured.
You're really going to push your single minded position that this is the true/only/correct way to do things? While conveniently avoiding mentioning the use of a zoom window to see everything simultaneously without any hidden surprises...
I'm not pushing anything on anyone. I want to show what is possible
By only suggesting a single method that is inferior in the majority of situations? That's not one-sided, misleading, or pushing at all.... [/s]
Persuasive language and trying to claim the majority in a corner case you invented is disingenuous. Misleading. Adding noise.
As always you conveniently leave out all the preconditions nesscecary for your corner case to be valid, and then conveniently expect people new to the conversation to already know that. Awful lot of hand waving and misdirection to push your nonsense for some reason.
Want to present it plainly/fairly? You won't get any push back, but rather you come back time and time again with the inflammatory and leading pronouncements.
-
To take a practical example, if I am trying to decode some messages on an SPI bus, here is what I think I am understanding: On the Siglent, I will need to show "all" of the messages on the screen to capture them - even though at that point they will be so squished together than I can't discern the content of any of the messages. Then, once capture, I can zoom in and scroll through to see the actual content of the messages. Have I got it right?
To a point.
Ideally we always want to see a truly stable waveform which signifies trigger settings are correct at least for basic decoding.
While there are several shortcuts to get a result my advice to get accustomed to the absolute power of the trigger suite you have.
Some KISS examples using a single channel for UART.
To get a properly stable waveform you need to prevent retriggering within a packet using a Holdoff time setting a little longer than a packet. How long is a packet is the first thing we need to know and for this we need get a few packets on the display and press Stop and eyeball its width against the graticules.
For these examples a 60ms Holdoff is just adequate to get rock solid stable triggering.
However, while we are still in the trigger menu, we need set the correct edge which for most protocols is Idle High so we need a falling edge trigger to mark the beginning of packet data.
Now we should have sound triggering however with the H Pos mid display there's only half the display to show full packets and their decode so we need move H Pos to the left with the encoder and set it in place with Utility/System Settings/Ref Position with H Pos set to Position.
The back of the job is now broken and just decode settings remain, assigning the correct channel/s and Threshold levels, Idle High in this case, baud rate etc.
As has been discussed Zoom mode can be useful now to display a # of packets to permit panning through them and the zoomed window for each packet decode or each byte.
Hoping the attached screenshots are of assistance.
I was able to follow some of that ... will have to sit down and try actually to decode a signal in order to see if I truly understood or not. Unfortunately, this weekend is tied up with a trip, so it may be a few days before I get time. :(
-
I was able to follow some of that ... will have to sit down and try actually to decode a signal in order to see if I truly understood or not. Unfortunately, this weekend is tied up with a trip, so it may be a few days before I get time. :(
Can I suggest starting with a signal you know, either:
- a "simple" standard like a square wave with 0.1% duty cycle and sharp edges
- a complex serial stream like a program "printing" A...Za...z to a UART, with/without spaces between the characters
-
Can I suggest starting with a signal you know, either:
- a "simple" standard like a square wave with 0.1% duty cycle and sharp edges
- a complex serial stream like a program "printing" A...Za...z to a UART, with/without spaces between the characters
Oh, believe me, I am starting simple. Last night I set up an ATTiny84 to output 0 - 254 on 8 of its pins - nice, simple square waves of varying frequencies to test, try out the various available measurements, etc. I even did an FFT, not that I truly know enough about FFTs to understand how to set it up or what I was seeing as a result ...
-
Can I suggest starting with a signal you know, either:
- a "simple" standard like a square wave with 0.1% duty cycle and sharp edges
- a complex serial stream like a program "printing" A...Za...z to a UART, with/without spaces between the characters
Oh, believe me, I am starting simple. Last night I set up an ATTiny84 to output 0 - 254 on 8 of its pins - nice, simple square waves of varying frequencies to test, try out the various available measurements, etc. I even did an FFT, not that I truly know enough about FFTs to understand how to set it up or what I was seeing as a result ...
FFT of digital signals...
The square wave's period shows up in the frequency domain as the fundamental frequency plus odd harmonics.
The highest harmonic is determined by the transition time; the period is irrelevant.
Varying the duty cycle changes the amplitude of the low frequency harmonics, but the high frequency harmonics are unaffected.
Maybe https://entertaininghacks.wordpress.com/2018/05/08/digital-signal-integrity-and-bandwidth-signals-risetime-is-important-period-is-irrelevant/ might help a little by confirming the theory you will learn.
But learning how to trigger on characters emitted by a UART is a useful way of understanding your scope's capabilities. Doubly so when comparing it with a logic or protocol analyser.
-
...But learning how to trigger on characters emitted by a UART is a useful way of understanding your scope's capabilities. Doubly so when comparing it with a logic or protocol analyser.
First I want to thank OP for starting such an interesting thread, but, I get here and the story just stops?
-
In the early days of DSOs, memory depth was of much greater instant impact on everyday use of a 'scope to look at complex analog signals.
One standard use was to look at one, or several analog video fields, to look at aberrations on the blanking level & sync part of the waveforms.
To this end, to accommodate the around 40ms duration of two fields, the 'scope would be set to around 5ms/div.
Early DSOs often quoted quite decent sample rates, but these were only valid for much faster time/div settings.
At these slow timebase rates, the memory would soon run out of capacity, so as the sweep time was increased, the sample rate was reduced, until a complex wideband video signal became totally unrecognisable.
Over time, memory depth slowly, then rapidly, increased, until that original problem has pretty much disappeared with decent affordable DSOs, & the other niceties of memory depth have become the primary topics of discussion.
There are still DSOs available which are sufficiently low in memory depth that the old problem raises its head. They are usually very cheap, or old.
-
Today when you say "logic analysers and protocol analysers" people think you mean Saleae type USB device.
Which basically have no triggering to speak of, only very rudimentary one.
2N3055, please elaborate on why this is and why LA makers don’t include more/better triggering?
(Clearly digital only LA’s can’t trigger on analog signals but once a signal is in a digital realm specifying trigger conditions should not be too hard - yes?). Thx
-
Today when you say "logic analysers and protocol analysers" people think you mean Saleae type USB device.
Which basically have no triggering to speak of, only very rudimentary one.
2N3055, please elaborate on why this is and why LA makers don’t include more/better triggering?
(Clearly digital only LA’s can’t trigger on analog signals but once a signal is in a digital realm specifying trigger conditions should not be too hard - yes?). Thx
I'm afraid I don't know why they don't.
I would presume it is because many of those USB protocol decoders (like Saleae) are simple USB streaming devices that have no logic on primary hardware side, but simply stream data to software.
There are some USB LA/PA that have some logic, and have various degree of triggering, but you need to search for them.
But even those don't have very sophisticated triggering that old LA used to have.
-
With more memory, triggering becomes less important. Especially on a logic analyser which has a capture -analysis workflow. I have a high-end logic analyser from Tektronix with a programmable trigger statemachine which can trigger on sequential and logical conditions beyond your wildest dreams. But it is extremely rare that I use that feature. My logic analyser has so much memory and a time stamped mode that it can collect extremely long time spans. In many cases I don't care about a trigger condition, I just hit the 'run' button to make a single acquisition. That single acquisition has all the information I need. The search & analysis features of the software help me to find problem areas and correlate cause & effect. Then again, I fire my logic analyser up when my MSO runs out of steam but that is unlikely to happen. I find myself using an MSO for 99% of the measurements I used to use a logic analyser for.
My first logic analyser only had like 1kpts or 2kpts of memory. Triggering on very specific conditions was very important as the memory was short. Getting a full picture of cause & effect typically required taking at least several measurements, storing / retrieving data and comparing. It did the job but getting a result (as in identify a problem) could take very long.
-
With more memory, triggering becomes less important. Especially on a logic analyser which has a capture -analysis workflow. I have a high-end logic analyser from Tektronix with a programmable trigger statemachine which can trigger on sequential and logical conditions beyond your wildest dreams. But it is extremely rare that I use that feature. My logic analyser has so much memory and a time stamped mode that it can collect extremely long time spans. In many cases I don't care about a trigger condition, I just hit the 'run' button to make a single acquisition. That single acquisition has all the information I need. The search & analysis features of the software help me to find problem areas and correlate cause & effect. Then again, I fire my logic analyser up when my MSO runs out of steam but that is unlikely to happen. I find myself using an MSO for 99% of the measurements I used to use a logic analyser for.
My first logic analyser only had like 1kpts or 2kpts of memory. Triggering on very specific conditions was very important as the memory was short. Getting a full picture of cause & effect typically required taking at least several measurements, storing / retrieving data and comparing. It did the job but getting a result (as in identify a problem) could take very long.
The key point about complex triggers and filters is that they reduce the amount of "noise" in the captured data. Reduced "noise" reduces the importance of long capture buffers. While I will, reluctantly, eyeball 1kSamples of data, there's no way I'm going to trawl through 10MSamples of data!
I'll discuss this in "logic analyser terms"; the equivalents with protocol analysers shouldn't be difficult to work out :)
The simplest kind of filter is "clock rising edge", since that removes crap that is irrelevant to your state machine implementation. If you have a 1kHz state machine clock and sample at 10MS/s, that immediately removes 99.9% of the "data".
The next kind of filter is to only look at information to/from one device on a bus. Sometimes the filter can be as simple as a single CE line, sometimes it involves recognising an address.
Closely allied to that is only capturing information in (filtering) or after (arming/triggering) your FSM has entered a specific state.
In many cases you want to be able to demonstrate that something has not occurred. In such cases the capture depth is, of course, irrelevant; you just let the analyser rip and hope/expect to see it still waiting when you return after your coffee break. That kind of analysis is difficult without
-
With more memory, triggering becomes less important. Especially on a logic analyser which has a capture -analysis workflow. I have a high-end logic analyser from Tektronix with a programmable trigger statemachine which can trigger on sequential and logical conditions beyond your wildest dreams. But it is extremely rare that I use that feature. My logic analyser has so much memory and a time stamped mode that it can collect extremely long time spans. In many cases I don't care about a trigger condition, I just hit the 'run' button to make a single acquisition. That single acquisition has all the information I need. The search & analysis features of the software help me to find problem areas and correlate cause & effect. Then again, I fire my logic analyser up when my MSO runs out of steam but that is unlikely to happen. I find myself using an MSO for 99% of the measurements I used to use a logic analyser for.
My first logic analyser only had like 1kpts or 2kpts of memory. Triggering on very specific conditions was very important as the memory was short. Getting a full picture of cause & effect typically required taking at least several measurements, storing / retrieving data and comparing. It did the job but getting a result (as in identify a problem) could take very long.
The key point about complex triggers and filters is that they reduce the amount of "noise" in the captured data. Reduced "noise" reduces the importance of long capture buffers. While I will, reluctantly, eyeball 1kSamples of data, there's no way I'm going to trawl through 10MSamples of data!
Well, you don't have to trawl to 10Msamples of data. Just select part of the acquisition and let the analysis tools do their job to answer questions like minimum / maximum setup & hold, number of clock pulses in an interaction / burst, frequency, etc. Typically I'm interested whether a design behaves the way I intend it to behave so there are no hidden surprises lurking. There are many ways something may appear to work only to fall apart when the cirumstances are slightly different. Having one acquisition to do analysis on is much easier compared to setting different triggers and re-measure for every detail you want to check. And even if you set triggers to detect fault situations, you will want to have as much data as possible to see what lead to the fault c.q. what where the circumstances. Otherwise you only know a fault occured without a clue on how to reproduce it.
-
With more memory, triggering becomes less important. Especially on a logic analyser which has a capture -analysis workflow. I have a high-end logic analyser from Tektronix with a programmable trigger statemachine which can trigger on sequential and logical conditions beyond your wildest dreams. But it is extremely rare that I use that feature. My logic analyser has so much memory and a time stamped mode that it can collect extremely long time spans. In many cases I don't care about a trigger condition, I just hit the 'run' button to make a single acquisition. That single acquisition has all the information I need. The search & analysis features of the software help me to find problem areas and correlate cause & effect. Then again, I fire my logic analyser up when my MSO runs out of steam but that is unlikely to happen. I find myself using an MSO for 99% of the measurements I used to use a logic analyser for.
My first logic analyser only had like 1kpts or 2kpts of memory. Triggering on very specific conditions was very important as the memory was short. Getting a full picture of cause & effect typically required taking at least several measurements, storing / retrieving data and comparing. It did the job but getting a result (as in identify a problem) could take very long.
The key point about complex triggers and filters is that they reduce the amount of "noise" in the captured data. Reduced "noise" reduces the importance of long capture buffers. While I will, reluctantly, eyeball 1kSamples of data, there's no way I'm going to trawl through 10MSamples of data!
Well, you don't have to trawl to 10Msamples of data. Just select part of the acquisition and let the analysis tools do their job to answer questions like minimum / maximum setup & hold, number of clock pulses in an interaction / burst, frequency, etc. Typically I'm interested whether a design behaves the way I intend it to behave so there are no hidden surprises lurking. There are many ways something may appear to work only to fall apart when the cirumstances are slightly different. Having one acquisition to do analysis on is much easier compared to setting different triggers and re-measure for every detail you want to check. And even if you set triggers to detect fault situations, you will want to have as much data as possible to see what lead to the fault c.q. what where the circumstances. Otherwise you only know a fault occured without a clue on how to reproduce it.
Those examples are little more than glorified signal integrity problems.
If you look the points I made and you snipped, you will realise that they are about more complex "higher" level specification and implementation issues.
-
No, definitely not signal integrity issues. The difference between your and mine approach is that you want to catch things you think might be wrong. OTOH, I want to see that what seems to be working correctly is actually correct. For example: I don't want to just check the messages I expect on a bus but also check if there aren't any unexpected messages on a bus. That offers a much higher degree of test coverage. But it requires acquiring & analysing much more data.
-
No, definitely not signal integrity issues. The difference between your and mine approach is that you want to catch things you think might be wrong. OTOH, I want to see that what seems to be working correctly is actually correct. For example: I don't want to just check the messages I expect on a bus but also check if there aren't any unexpected messages on a bus. That offers a much higher degree of test coverage. But it requires acquiring & analysing much more data.
I wrote glorified signal integrity tests, as a shorthand.
Your understanding of my test objectives.and techniques is flawed.
-
Oh FFS
Please you 2 go get a room together, not one where the OP is attempting to get his head around the featureset of his first DSO.
-
Come on Rob, never get in the way of true love. 😉
-
Oh FFS
Please you 2 go get a room together, not one where the OP is attempting to get his head around the featureset of his first DSO.
Don't worry. I have set a hard limit at two replies to tggzzz within 20 posts. >:D
-
This may already have been mentioned, but the full memory available is always filled on a Siglent (most scopes for that matter). You can just go to the history to see the rest of it if you have nothing better to do with your life than scroll through 10s of millions of data points looking for something you didn't expect. :-//
As I think someone already said, learning how to define triggers properly is the key. And that is time you only have to spend once.
-
If (part of) your work (like mine) consists of doing single shot measurements, then history doesn't matter. It is wasted memory because the previous measurement simply isn't relevant. So please give me the choice to have full memory in a single shot even though some or most of it doesn't show on screen right away.
-
If (part of) your work (like mine) consists of doing single shot measurements, then history doesn't matter. It is wasted memory because the previous measurement simply isn't relevant. So please give me the choice to have full memory in a single shot even though some or most of it doesn't show on screen right away.
Can you explain this a little better (not being argumentative, but I just don't understand)? What is it you are looking for that can ONLY occur after the moment of acquisition?
-
Hello,
It would be good if awakephd would say what signal sources he has available, so that you could suggest better experiments.
Best regards
egonotto
-
So please give me the choice to have full memory in a single shot even though some or most of it doesn't show on screen right away.
That option is there but you just don't like the way you make it happen--and it isn't really that much work even if it isn't what you're used to.
-
If (part of) your work (like mine) consists of doing single shot measurements, then history doesn't matter. It is wasted memory because the previous measurement simply isn't relevant. So please give me the choice to have full memory in a single shot even though some or most of it doesn't show on screen right away.
Can you explain this a little better (not being argumentative, but I just don't understand)? What is it you are looking for that can ONLY occur after the moment of acquisition?
for your reading pleasure, a separate 562 post thread on just that topic, linking to the context that nctnico intentionally leaves out (which makes this blatant inflammatory posting):
https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/msg3060638/#msg3060638 (https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/msg3060638/#msg3060638)
Dismissal of using a zoom window for... ill-defined/unsubstantiated reasons. Perhaps this forum will get another several thousand posts of crap on this topic over the next 10 years?
-
it isn't really that much work even if it isn't what you're used to.
It should be zero work when it's something that's done as often as this.
I simply don't see the excuse for not fulling the memory when you press STOP.
(or use single trigger - same thing)
The STOP button is one of the single biggest features of a DSO.
-
it isn't really that much work even if it isn't what you're used to.
It should be zero work when it's something that's done as often as this.
I simply don't see the excuse for not fulling the memory when you press STOP.
Refer you back to the mega thread:
https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/ (https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/)
If the data is captured already for the stop button to hold it, then you've been having to capture that data on every trigger and slow the acheivable acquisition rate. If that is intended behaviour then it should be set and adjusted by the user, not the default. Using a zoom window adds more controls and makes the mode obvious, fewer controls, quicker to do, but takes up some of the visible screen. A trade off I'm very happy with and do not want swapped out.
-
for your reading pleasure, a separate 562 post thread on just that topic
Okay, I get the gist (without reading all 562 posts). So, with my background in mathematics and physics I can see absolutely no reason to assume that "some unknown event" would be more likely to occur after some arbitrary (arbitrary WRT "some unknown event") trigger point than before. In fact, because the very nature of "some unknown event" being unknown, in it's very nature it can be proven mathematically that it must be just as likely to occur before the trigger point than after .. annnnd .. given the fixed amount of memory available (whatever that amount may be) there could be no possible advantage one way or the other since we cannot know when "some unknown event" might occur. From a physics perspective, this is just slap in the face obvious.
The end result is that a "zoom out" or "scroll forward" feature is just a gimmick. Like pink paint on your Cadillac.
Some people believe the earth is flat too. :palm: :scared: :-DD :-DD
-
for your reading pleasure, a separate 562 post thread on just that topic
Okay, I get the gist (without reading all 562 posts).
You'd think if it was such a killer feature then one of the proponents would be able to show us some screen shots of an (even a contrived) example where it is beneficial. Instead we just get endless hand waving and arguing.
-
I simply don't see the excuse for not fulling the memory when you press STOP.
The memory is full either way when you press STOP. Apparently you would prefer that it be filled with something different by default.
-
Instead we just get endless hand waving and arguing.
:palm: Yup, the special imaginary advantages of cool gizmos.
-
Oh FFS
Please you 2 go get a room together, not one where the OP is attempting to get his head around the featureset of his first DSO.
I tend to agree.
I did post use-cases for which advanced features are used, but they were ignored.
-
...
for your reading pleasure, a separate 562 post thread on just that topic, linking to the context that nctnico intentionally leaves out (which makes this blatant inflammatory posting):
https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/msg3060638/#msg3060638 (https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/msg3060638/#msg3060638)
Dismissal of using a zoom window for... ill-defined/unsubstantiated reasons. Perhaps this forum will get another several thousand posts of crap on this topic over the next 10 years?
Interesting, for several reasons.
-
Oh FFS
Please you 2 go get a room together, not one where the OP is attempting to get his head around the featureset of his first DSO.
I tend to agree.
I did post use-cases for which advanced features are used, but they were ignored.
And rightly so.
Did you not walk before you could run......sure this stuff is pretty straight forward to many of us but some need a helping hand before just getting past basic features.
-
Oh FFS
Please you 2 go get a room together, not one where the OP is attempting to get his head around the featureset of his first DSO.
I tend to agree.
I did post use-cases for which advanced features are used, but they were ignored.
And rightly so.
Did you not walk before you could run......sure this stuff is pretty straight forward to many of us but some need a helping hand before just getting past basic features.
Often it is useful to be aware of use cases so that:
- you can recognise them when they arise
- you gain perspective of why certain features are present
- you choose the most appropriate tool for the job, e.g. avoiding using a hammer with screws
It is always useful to have knowledge that exceeds the current requirements. That way you know the boundaries, and that you haven't unwittingly strayed outside the boundaries.
However with modern DSOs the boundaries are a little like this[1]
https://www.google.co.uk/maps/place/Netherlands/@51.4459163,4.9256093,21z/data= (https://www.google.co.uk/maps/place/Netherlands/@51.4459163,4.9256093,21z/data=)!4m6!3m5!1s0x47c609c3db87e4bb:0xb3a175ceffbd0a9f!8m2!3d52.132633!4d5.291266!16zL20vMDU5ajI?entry=ttu
but that's an advantage, isn't it.
[1] to get the best understanding, slowly zoom out 4 or 5 times, concentrating on the boundaries :)
-
If (part of) your work (like mine) consists of doing single shot measurements, then history doesn't matter. It is wasted memory because the previous measurement simply isn't relevant. So please give me the choice to have full memory in a single shot even though some or most of it doesn't show on screen right away.
Can you explain this a little better (not being argumentative, but I just don't understand)? What is it you are looking for that can ONLY occur after the moment of acquisition?
I need to take you a step back here.
First of all: When you measure something, you want to be able to make a relation between cause and effect so you can draw a conclusion from the measurement result. This may sound obvious but for many it requires training to measure / collect data in a way so it is possible to establish a singular cause & effect relationship.
Secondly: I'm not looking at something which can only occur after the moment of acquisition. I just want 1 acquisition with as much data as possible so I can see what happened before AND after an event. I might not always need the data but with shorter memory DSOs I have often wished to have more data in order to have more information about what happened before and after an error condition. That can show the problem so it can be fixed right away or can give valueable glues on what to set triggers for and thus save a lot of time (and money) instead of poking around in the dark. Keep in mind that my typical measurements are for DUTs which are highly sequential through hardware and/or software.
Back to the history buffer: When I'm debugging / testing embedded firmware / FPGA / hardware, each single shot measurement represents a new version with a fix or change. Which means that whatever is in the history buffer is no longer relevant information as I won't be able to match a specific acquisition with a specific change somewhere. There is no way to draw a meaningfull conclusion from the data in the history buffer. So I rather have no history buffer at all if that means getting more memory for the current acquisition.
A history buffer is only usefull if you can record all relevant information in/by the oscilloscope itself (input versus output) without making changes to the DUT. That way you can draw a meaningfull conclusion from the acquisitions in the history buffer. Keep in mind though that a history buffer and segmented recording are functionally equal it is just that an automatic history buffer is easier to use / setup.
-
Please post an example of where filling up the memory is worse.
(Or where not filling it up is better...)
-
Please post an example of where filling up the memory is worse.
(Or where not filling it up is better...)
He cannot, because there is none.
If you need long capture you take a long capture (regardless how you do it, by setting manual long memory or long time base).
If you are at shorter time base you are using only small portion of memory so rest is either waisted for nothing or you can put history there and make it useful.
-
It's not just about zooming, it's about panning left/right after STOP.
The Rigol DS1045Z's serial decoders were widely mocked for only being able to decode what was visible on screen.
To me the Siglent system seems like that except serial decoding was something I only did every other week but zooming/panning is something I do all the time.
-
It's not just about zooming, it's about panning left/right after STOP.
The Rigol DS1045Z's serial decoders were widely mocked for only being able to decode what was visible on screen.
To me the Siglent system seems like that except serial decoding was something I only did every other week but zooming/panning is something I do all the time.
Why do you think you cannot move around captured buffer on Siglent? You can. Exactly the same as on any other scope.
-
I need to take you a step back here.
First of all: When you measure something, you want to be able to make a relation between cause and effect so you can draw a conclusion from the measurement result. This may sound obvious but for many it requires training to measure / collect data in a way so it is possible to establish a singular cause & effect relationship.
Secondly: I'm not looking at something which can only occur after the moment of acquisition. I just want 1 acquisition with as much data as possible so I can see what happened before AND after an event. I might not always need the data but with shorter memory DSOs I have often wished to have more data in order to have more information about what happened before and after an error condition. That can show the problem so it can be fixed right away or can give valueable glues on what to set triggers for and thus save a lot of time (and money) instead of poking around in the dark. Keep in mind that my typical measurements are for DUTs which are highly sequential through hardware and/or software.
Back to the history buffer: When I'm debugging / testing embedded firmware / FPGA / hardware, each single shot measurement represents a new version with a fix or change. Which means that whatever is in the history buffer is no longer relevant information as I won't be able to match a specific acquisition with a specific change somewhere. There is no way to draw a meaningfull conclusion from the data in the history buffer. So I rather have no history buffer at all if that means getting more memory for the current acquisition.
A history buffer is only usefull if you can record all relevant information in/by the oscilloscope itself (input versus output) without making changes to the DUT. That way you can draw a meaningfull conclusion from the acquisitions in the history buffer. Keep in mind though that a history buffer and segmented recording are functionally equal it is just that an automatic history buffer is easier to use / setup.
I respectfully remain unconvinced. I think you have convinced yourself of an advantage that is not there.
Besides, there is a way to do exactly what you want by setting up your capture properly - and in this case you can place your trigger point any where you like in the data captured. Zoom = Pink Cadillac. Only has merit to those that "like it".
-
I need to take you a step back here.
First of all: When you measure something, you want to be able to make a relation between cause and effect so you can draw a conclusion from the measurement result. This may sound obvious but for many it requires training to measure / collect data in a way so it is possible to establish a singular cause & effect relationship.
Secondly: I'm not looking at something which can only occur after the moment of acquisition. I just want 1 acquisition with as much data as possible so I can see what happened before AND after an event. I might not always need the data but with shorter memory DSOs I have often wished to have more data in order to have more information about what happened before and after an error condition. That can show the problem so it can be fixed right away or can give valueable glues on what to set triggers for and thus save a lot of time (and money) instead of poking around in the dark. Keep in mind that my typical measurements are for DUTs which are highly sequential through hardware and/or software.
Back to the history buffer: When I'm debugging / testing embedded firmware / FPGA / hardware, each single shot measurement represents a new version with a fix or change. Which means that whatever is in the history buffer is no longer relevant information as I won't be able to match a specific acquisition with a specific change somewhere. There is no way to draw a meaningfull conclusion from the data in the history buffer. So I rather have no history buffer at all if that means getting more memory for the current acquisition.
A history buffer is only usefull if you can record all relevant information in/by the oscilloscope itself (input versus output) without making changes to the DUT. That way you can draw a meaningfull conclusion from the acquisitions in the history buffer. Keep in mind though that a history buffer and segmented recording are functionally equal it is just that an automatic history buffer is easier to use / setup.
I respectfully remain unconvinced. I think you have convinced yourself of an advantage that is not there.
You are allowed to have your own opinion. I'm sorry I can't explain the advantages of zooming out better (they are definitely real, like not having to think about the precise trigger point!) and you feel the need to go down the ridiculing path instead of just respecting other people's ideas even if you don't fully understand them.
-
I need to take you a step back here.
First of all: When you measure something, you want to be able to make a relation between cause and effect so you can draw a conclusion from the measurement result. This may sound obvious but for many it requires training to measure / collect data in a way so it is possible to establish a singular cause & effect relationship.
Secondly: I'm not looking at something which can only occur after the moment of acquisition. I just want 1 acquisition with as much data as possible so I can see what happened before AND after an event. I might not always need the data but with shorter memory DSOs I have often wished to have more data in order to have more information about what happened before and after an error condition. That can show the problem so it can be fixed right away or can give valueable glues on what to set triggers for and thus save a lot of time (and money) instead of poking around in the dark. Keep in mind that my typical measurements are for DUTs which are highly sequential through hardware and/or software.
Back to the history buffer: When I'm debugging / testing embedded firmware / FPGA / hardware, each single shot measurement represents a new version with a fix or change. Which means that whatever is in the history buffer is no longer relevant information as I won't be able to match a specific acquisition with a specific change somewhere. There is no way to draw a meaningfull conclusion from the data in the history buffer. So I rather have no history buffer at all if that means getting more memory for the current acquisition.
A history buffer is only usefull if you can record all relevant information in/by the oscilloscope itself (input versus output) without making changes to the DUT. That way you can draw a meaningfull conclusion from the acquisitions in the history buffer. Keep in mind though that a history buffer and segmented recording are functionally equal it is just that an automatic history buffer is easier to use / setup.
I respectfully remain unconvinced. I think you have convinced yourself of an advantage that is not there.
You are allowed to have your own opinion. I'm sorry I can't explain the advantages of zooming out better (they are definitely real!) and you feel the need to go down the ridiculing path instead of just respecting other people's idea even if you don't fully understand them.
We understand what are you doing.
We don't understand why do you insist it is universally better than the other way around that achieves same results.
And no, I cannot respect other people opinion (or have any other opinion about it) if I don't understand it.
I do respect that you have right to think whatever you want.
And you have to respect I have the same right. Including thinking you are wrong.
But this is philosophical/legal/freedom of expression-speech argument.
We are talking here about technical solutions. There is no place for opinions here.
Just facts. Is something faster/more accurate/can do something you cannot otherwise/cheaper.....
Stuff like that.
And please stop calling it "zooming out". It is simple practice to take very long capture in Single/normal mode and analyze it when stopped by inspecting details in that long capture. Most of the scopes with deep memory can do that.
We all do that already.
-
You are allowed to have your own opinion. I'm sorry I can't explain the advantages of zooming out better (they are definitely real!) and you feel the need to go down the ridiculing path instead of just respecting other people's idea even if you don't fully understand them.
I'm not ridiculing you at all. :-// you must have missed this: I respectfully remain unconvinced.
Since there is already a way to do exactly what you want (and that way offers complete control of the capture) then the zoom "feature" is just a gimmick. A perfect analogy would be the "green mode" on a camera verses setting the exposure yourself. In both the case of the camera's "green mode" and the oscilloscopes "zoom feature" you are letting the device choose how your data is collected.
-
You are allowed to have your own opinion. I'm sorry I can't explain the advantages of zooming out better (they are definitely real!) and you feel the need to go down the ridiculing path instead of just respecting other people's idea even if you don't fully understand them.
I'm not ridiculing you at all. :-// you must have missed this: I respectfully remain unconvinced.
Since there is already a way to do exactly what you want (and that way offers complete control of the capture) then the zoom "feature" is just a gimmick. A perfect analogy would be the "green mode" on a camera verses setting the exposure yourself. In both the case of the camera's "green mode" and the oscilloscopes "zoom feature" you are letting the device choose how your data is collected.
Ofcourse there are always multiple ways to achieve the same goal. Equally, there are less and more effective ways to achieve a goal. For me being able to have information beyond the screen allows me to not having to think about how to setup the scope precisely to capture what I need. No matter what, the data I need is there and thus I can concentrate more on the problem I'm trying to solve rather than messing with the tools. To some this sounds outright insane but it saves me a lot of time.
I know the zoom window can be used for even finer control but that comes at the price of needing to mess with 2 timebases and giving up what is most dearest to me on an oscilloscope: vertical space. Along a similar line you can argue that the history buffer is a useless feature / gimmick because the same can be accomplished using segmented recording which also allows finer control over the precise number of segments.
-
I know the zoom window can be used for even finer control but that comes at the price of needing to mess with 2 timebases and giving up what is most dearest to me on an oscilloscope: vertical space.
Here is where you are not fully conversant with Siglent DSO development, much different to how Zoom mode and memory management was implemented in the past.
Now when your fingers are on the timebase encoder Zoom mode is engaged with just a press, < not new, but toggling between windows in Zoom mode is just another press of the timebase encoder and in those models that offer memory management the main timbase can be zoomed out an order of magnitude more than most DSO's available.....while in Stop mode.
12bit SDS2000X HD, 8bit SDS5000X and all higher BW models have this capability which can negate the need for Zoom mode yet in Zoom mode the trigger point is always visible so to have a reference point when panning through a capture.
-
...But learning how to trigger on characters emitted by a UART is a useful way of understanding your scope's capabilities. Doubly so when comparing it with a logic or protocol analyser.
First I want to thank OP for starting such an interesting thread, but, I get here and the story just stops?
Dan, as the OP, I am sorry that I haven't posted the past couple of days - I've been out of town and away from the scope, so haven't been able to follow up. The story will continue ... unfortunately with frequent interruptions occasioned by my real job getting in the way of my hobbies. :(
-
Hello,
It would be good if awakephd would say what signal sources he has available, so that you could suggest better experiments.
Best regards
egonotto
A very primitive signal generator (basic sine, square, triangle waves), plus whatever I can generate from an Atmel ATTiny84 or Arduino Nano, i.e, I2C, SPI, UART, plus PWM at various frequencies. And for a "real" test, I am planning to test and experiment with the effectiveness of basic R/C de-bounce filters on various switches.
-
Why do you think you cannot move around captured buffer on Siglent? You can. Exactly the same as on any other scope.
But normally there's nothing there.
(unless you previously zoomed out, re-captured, then zoomed in again trying to remember the horizontal scale you were at before you did all that, yes, we got that...)
-
All, I am very sorry to have kicked over what is apparently an old and hotly debated ant hill regarding memory and zoom and such.
I will repeat that as a newbie, I have no dog in this fight, other than seeking to understand how to use the scope I actually have (as opposed to the ones that I don't have which happen to handle things differently). From where I sit (in a sea of ignorance!), I honestly don't see why this argument is so consuming. Despite many suggestions to the contrary, it is not clear to me - perhaps because of my ignorance - that one approach is superior to the other; they are simply different. Maybe each approach offers some advantages over the other ... but in the end it seems like arguing over a preference for apples vs. oranges.
One more time, I plead my ignorance - perhaps I just don't know enough to appreciate the finer nuances of the argument. From what I can see, you are all experienced users who are getting really good use out of your preferred scopes ... in which case, why give a fig if someone else prefers and is getting really good use out of a scope that does things differently??
-
One more time, I plead my ignorance - perhaps I just don't know enough to appreciate the finer nuances of the argument. From what I can see, you are all experienced users who are getting really good use out of your preferred scopes ... in which case, why give a fig if someone else prefers and is getting really good use out of a scope that does things differently??
It's not you, none of their conversation belongs in this thread. I mentioned previously that the only thing that matters is as you said, learning to use the scope you have. Them debating different brand philosophies is completely useless, and counterproductive here.
-
author=nctnico link=topic=430231.msg5527699#msg5527699 date=1717337486]
allows me to not having to think about how to setup the scope precisely to capture what I need...
Yes, you're a fast-thinking knob twiddler. That's not meant as an insult, just a humorous description of how I see a certain set of people whose brains appear to operate very differently than mine. I can't operate a scope without knowing where the settings are at. And yes, bad encoders enrage me just as much as anyone else.
No matter what, the data I need is there
Unless it isn't. It will be there if the record length at the scopes fastest undecimated sampling rate is long enough. Otherwise it won't. And on something like a 1M Megazoom scope at 2GSa/s, that's a half a millisecond. Deliberately setting the timebase (no zoom needed if you don't like it for some reason, such as the zoom window taking half the screen) to what you need will cause the scope to slow down the sample rate appropriately. Possibly this isn't commonly an issue with your scopes as you use them, but it will come up in common uses using your technique.
Along a similar line you can argue that the history buffer is a useless feature / gimmick because the same can be accomplished using segmented recording which also allows finer control over the precise number of segments.
I would actually agree with that and don't find much utility in having the history buffer as a default. I'm especially annoyed that the SINGLE mode on my SDS2354X+ wipes appears to wipe out the history so you always only have one capture. It might be occasionally useful to take repeated single captures and save them all. In fact you can easily do this using the EXT TRIG and a pushbutton. So while I don't find the SINGLE memory management to be as appalling as you do, Siglent and it's proxies and proponents here have to reckon with the fact that they've not implemented a useful alternative system.
-
All, I am very sorry to have kicked over what is apparently an old and hotly debated ant hill regarding memory and zoom and such.
It's actually worth discussing and if you can tolerate the squabbling and understand the issue, you'll probably gain something. You appear to already have figured out what it is about in the general sense. It's not like we're having fistfights here.
-
All, I am very sorry to have kicked over what is apparently an old and hotly debated ant hill regarding memory and zoom and such.
I will repeat that as a newbie, I have no dog in this fight, other than seeking to understand how to use the scope I actually have (as opposed to the ones that I don't have which happen to handle things differently).
That's a very sane attitude :) Learn to use whatever tool you have to its best advantage.
Learning any complex tool takes time and energy; being simpler is an advantage of analogue scopes.
The number of people that have detailed experience of more than one similar tool is very limited. Various people have allegedly noted something to the effect that "academic fights are so vicious because the stakes are so small".
A very primitive signal generator (basic sine, square, triangle waves), plus whatever I can generate from an Atmel ATTiny84 or Arduino Nano, i.e, I2C, SPI, UART, plus PWM at various frequencies. And for a "real" test, I am planning to test and experiment with the effectiveness of basic R/C de-bounce filters on various switches.
That's an excellent cross-section :)
The debouncing should show an advantage of digitising scopes over analogue scopes. While it is possible to use an analogue scope, it is useful to be able to push the button many times and use infinite persistence to overlay multiple traces.
I'd regard I2C/SPI/UART as being more or less equivalent, and just use whatever's most convenient.
What you haven't explicitly mentioned is correlating two or more signals, e.g. time delays between signals, or triggering on the combination of several signals.
You might also like to explore signal integrity issues. Classic examples are poorly constructed (TTL) digital counters, or octal buffers driving a heavily loaded bus.
Have fun, whenever you can :)
-
author=nctnico link=topic=430231.msg5527699#msg5527699 date=1717337486]
Along a similar line you can argue that the history buffer is a useless feature / gimmick because the same can be accomplished using segmented recording which also allows finer control over the precise number of segments.
I would actually agree with that and don't find much utility in having the history buffer as a default. I'm especially annoyed that the SINGLE mode on my SDS2354X+ wipes appears to wipe out the history so you always only have one capture. It might be occasionally useful to take repeated single captures and save them all. In fact you can easily do this using the EXT TRIG and a pushbutton. So while I don't find the SINGLE memory management to be as appalling as you do, Siglent and it's proxies and proponents here have to reckon with the fact that they've not implemented a useful alternative system.
On the R&S RTM3004 it is implemented the same. Each press on the single button wipes the history. I don't quite see the logic in doing this either but maybe it is done to make sure each capture is made using the exact same configuration. However, on the R&S scope there is a setting to tell how many captures need to be taken in single mode before the entire acquisition 'session' is completely over.
-
Why do you think you cannot move around captured buffer on Siglent? You can. Exactly the same as on any other scope.
But normally there's nothing there.
(unless you previously zoomed out, re-captured, then zoomed in again trying to remember the horizontal scale you were at before you did all that, yes, we got that...)
Not trying to debate, but I think Fungus’ comment is correct - yes?
-
I know the zoom window can be used for even finer control but that comes at the price of needing to mess with 2 timebases and giving up what is most dearest to me on an oscilloscope: vertical space.
Here is where you are not fully conversant with Siglent DSO development, much different to how Zoom mode and memory management was implemented in the past.
Now when your fingers are on the timebase encoder Zoom mode is engaged with just a press, < not new, but toggling between windows in Zoom mode is just another press of the timebase encoder and in those models that offer memory management the main timbase can be zoomed out an order of magnitude more than most DSO's available.....while in Stop mode.
12bit SDS2000X HD, 8bit SDS5000X and all higher BW models have this capability which can negate the need for Zoom mode yet in Zoom mode the trigger point is always visible so to have a reference point when panning through a capture.
- is there a link to a video showing this? Thx
-
Why do you think you cannot move around captured buffer on Siglent? You can. Exactly the same as on any other scope.
But normally there's nothing there.
(unless you previously zoomed out, re-captured, then zoomed in again trying to remember the horizontal scale you were at before you did all that, yes, we got that...)
Not trying to debate, but I think Fungus’ comment is correct - yes?
No it is not..
If you deliberately misuse equipment contrary to how it is supposed to be used you get bad results.
-
I am planning to test and experiment with the effectiveness of basic R/C de-bounce filters on various switches.
Sounds like a perfect example of where the Siglent way is going to be a pain in the ass. You'll be forever zooming in to look at detail then forgetting to zoom out again to prepare the 'scope for the next capture.
-
Why do you think you cannot move around captured buffer on Siglent? You can. Exactly the same as on any other scope.
But normally there's nothing there.
(unless you previously zoomed out, re-captured, then zoomed in again trying to remember the horizontal scale you were at before you did all that, yes, we got that...)
Not trying to debate, but I think Fungus’ comment is correct - yes?
Its more of the same omissions of conditions and imaginary problems.
There is no need to take another capture. 2N3055 explicitly says within the captured buffer. It's right there in the quote. Set the capture buffer to collect what you want it to, which is done by either method. The only difference is illustrated above by the large image I quote, whether or not there is a split in the display for the long and short views at the same time, or if the user has to manually switch between them.
Yet fungus somehow twists that around to the method already showing all the content and requiring fewer adjustments of the controls... apparently needing more work and additional steps (in their imagination). Which is not true in practice. Remember this is the poster who started out confidently wrong in "helping" the beginner with factually false information.... noise and post count ahead of truth and assistance.
Perhaps you can explain how the comment is correct? Or Fungus could explain how it is correct? Rather than these endless: nah you're wrong!
-
I am planning to test and experiment with the effectiveness of basic R/C de-bounce filters on various switches.
Sounds like a perfect example of where the Siglent way is going to be a pain in the ass. You'll be forever zooming in to look at detail then forgetting to zoom out again to prepare the 'scope for the next capture.
How many times do you want to post this crap? You're factually incorrect.
The scope in question can plainly capture a long time segment, its deep memory allows the sample rate to be maintained to longer horizontal timebases then other competitive examples.
This achieves the same capture depth as setting the memory depth to force capture around the window as other brands/models do. There is nothing requiring additional captures.
The ZOOM function does not change the horizontal timebase. Your lazy method of using the horizontal time base to zoom in and out would be the problem. But that is not required, or a logical way to use the scope. Not zooming out does nothing to change the capture depth, it's always set by the horizontal time base independent of the zoom position and scale.
So why keep pushing a beginner, who asked for some clarity on the best way to use their scope, away from the way that scope is designed to be used?
-
So why keep pushing a beginner, who asked for some clarity on the best way to use their scope, away from the way that scope is designed to be used?
100%. It's frustrating for those of us with some experience to see the nonsense, it can't be fun for beginners that are actually trying to learn.
-
I am planning to test and experiment with the effectiveness of basic R/C de-bounce filters on various switches.
Sounds like a perfect example of where the Siglent way is going to be a pain in the ass. You'll be forever zooming in to look at detail then forgetting to zoom out again to prepare the 'scope for the next capture.
How many times do you want to post this crap? You're factually incorrect.
So why keep pushing a beginner, who asked for some clarity on the best way to use their scope, away from the way that scope is designed to be used?
Actually the question was:
The link to Dave's video was actually very helpful for me in making sense of what memory depth is. I confess that i was assuming it would work more like the Keysight, which is part of why I was having trouble understanding - I hit "stop," but there was no data past the end of the screen. I think I am now understanding that, for the Siglent and a few others, what is captured is only what fits on the screen at a given moment - thus, one must zoom out, capture, then zoom in to see detail. Right? Maybe?
So there you have the proof you are so friggin' wrong in your thinking it isn't even funny, right in your face: people expect a DSO to capture beyond the screen because they find it useful. It is simple as that, like it or not. And yet you keep on going trying to push your limited view onto everyone. FFS :palm:
The best way is what gets people to results in a way which suits them best. Imagine somebody coming along insisting you stand behind your desk while you prefer to sit on a chair behind your desk.
-
I know the zoom window can be used for even finer control but that comes at the price of needing to mess with 2 timebases and giving up what is most dearest to me on an oscilloscope: vertical space.
Here is where you are not fully conversant with Siglent DSO development, much different to how Zoom mode and memory management was implemented in the past.
Now when your fingers are on the timebase encoder Zoom mode is engaged with just a press, < not new, but toggling between windows in Zoom mode is just another press of the timebase encoder and in those models that offer memory management the main timbase can be zoomed out an order of magnitude more than most DSO's available.....while in Stop mode.
12bit SDS2000X HD, 8bit SDS5000X and all higher BW models have this capability which can negate the need for Zoom mode yet in Zoom mode the trigger point is always visible so to have a reference point when panning through a capture.
- is there a link to a video showing this? Thx
Not that I'm aware of.
Which particular features interest you ?
Will a series of detailed screenshots suffice ?
I have SDS6204A that has the memory management features which can also be used like SDS800X HD with Auto memory management. Zoom mode for both of these works the in same way.
-
people expect a DSO to capture beyond the screen because they find it useful. It is simple as that, like it or not.
Some people expect that...
It is not without reason that the default setting for all scopes that I know across brands is “auto” as far as memory management is concerned.
And in this setting you can't look “behind” the screen and I bet 99% of the time you don't need to, otherwise it wouldn't be a default setting.
-
I know the zoom window can be used for even finer control but that comes at the price of needing to mess with 2 timebases and giving up what is most dearest to me on an oscilloscope: vertical space.
Here is where you are not fully conversant with Siglent DSO development, much different to how Zoom mode and memory management was implemented in the past.
Now when your fingers are on the timebase encoder Zoom mode is engaged with just a press, < not new, but toggling between windows in Zoom mode is just another press of the timebase encoder and in those models that offer memory management the main timbase can be zoomed out an order of magnitude more than most DSO's available.....while in Stop mode.
12bit SDS2000X HD, 8bit SDS5000X and all higher BW models have this capability which can negate the need for Zoom mode yet in Zoom mode the trigger point is always visible so to have a reference point when panning through a capture.
- is there a link to a video showing this? Thx
Which particular features interest you ?
The features you mentioned/indicated that are “much different to how Zoom mode and memory management was implemented in the past.”
“…Siglent DSO development, much different to how Zoom mode and memory management was implemented in the past.
Now when your fingers are on the timebase encoder Zoom mode is engaged with just a press, < not new, but toggling between windows in Zoom mode is just another press of the timebase encoder and in those models that offer memory management the main timbase can be zoomed out an order of magnitude more than most DSO's available.....while in Stop mode.
12bit SDS2000X HD, 8bit SDS5000X and all higher BW models have this capability which can negate the need for Zoom mode yet in Zoom mode the trigger point is always visible so to have a reference point when panning through a capture.”
-
people expect a DSO to capture beyond the screen because they find it useful. It is simple as that, like it or not.
Some people expect that...
It is not without reason that the default setting for all scopes that I know across brands is “auto” as far as memory management is concerned.
And in this setting you can't look “behind” the screen and I bet 99% of the time you don't need to, otherwise it wouldn't be a default setting.
I think the reason the default is auto is because that will ensure the highest waveform update rate as this is something many people find very important. Otherwise the support department will be swamped with questions. OTOH, there is no such setting on Keysight DSOs. You always get full memory for the last acquisition.
Edit: also think about why all (except for 1 or 2) major manufacturers of DSOs have been implementing capturing more than what is necessary to fill the screen for 40 years already (since the dawn of the DSO in the 1980's). If it where such an outlandisch or bad idea as some pretend it to be, then why are all the manufacturers still implementing it? Even the early Siglent scopes had capturing beyond the screen (the first firmware versions for the SDS2000 for example). It makes no sense for the oscilloscope manufacturers to implement/retain a feature without any significant demand for it.
-
Some people expect that...
I think MOST people would expect that. That's why Dave was so surprised.
It is not without reason that the default setting for all scopes that I know across brands is “auto” as far as memory management is concerned.
And in this setting you can't look “behind” the screen and I bet 99% of the time you don't need to, otherwise it wouldn't be a default setting.
:-//
Here's a Rigol in "auto" mode. Visible/hidden memory is shown in a special indicator at the top of the window.
As you can see, the memory being captured goes far beyond the visible screen, both before and after. I'm guessing about seven screens either way in this example.
(https://www.eevblog.com/forum/testgear/a-newbie-needs-some-help-with-my-first-dso/?action=dlattach;attach=2283484;image)
-
OTOH, there is no such setting on Keysight DSOs. You always get full memory for the last acquisition.
Except not all Keysight scopes do that, which has been tested and found to not occur in your magic corner case. This is all brand and model specific.
It cannot be simplified down to every/all/universal. Your claims of "industry standard" are a joke when it's not the default even on the scopes that support it.
-
I am planning to test and experiment with the effectiveness of basic R/C de-bounce filters on various switches.
Sounds like a perfect example of where the Siglent way is going to be a pain in the ass. You'll be forever zooming in to look at detail then forgetting to zoom out again to prepare the 'scope for the next capture.
How many times do you want to post this crap? You're factually incorrect.
So why keep pushing a beginner, who asked for some clarity on the best way to use their scope, away from the way that scope is designed to be used?
Actually the question was:
The link to Dave's video was actually very helpful for me in making sense of what memory depth is. I confess that i was assuming it would work more like the Keysight, which is part of why I was having trouble understanding - I hit "stop," but there was no data past the end of the screen. I think I am now understanding that, for the Siglent and a few others, what is captured is only what fits on the screen at a given moment - thus, one must zoom out, capture, then zoom in to see detail. Right? Maybe?
So there you have the proof you are so friggin' wrong in your thinking it isn't even funny, right in your face: people expect a DSO to capture beyond the screen because they find it useful. It is simple as that, like it or not. And yet you keep on going trying to push your limited view onto everyone. FFS :palm:
The best way is what gets people to results in a way which suits them best. Imagine somebody coming along insisting you stand behind your desk while you prefer to sit on a chair behind your desk.
You're taking the forced solution you pushed as a "win". I see that as a failure to educate the OP in the diversity of ways they could achieve the same result. Adding confusion to their mind instead of helping them understand the underlying concepts, which is where the question started.
There is no stopping and starting again. If you want to capture data around the trigger/magnified window then of course you have to set that before starting. With either method. So your communication has as I keep saying only added confusion and noise, no answered their honest questions.
Post truth world.
-
FWIW, I would hate for anyone to get too excited about what I might or might not have expected. I was expecting the waveform capture to start at the trigger point, so discovering that the scope captures all sorts of pre-trigger data was a big surprise. A very welcome, big surprise! :)
-
Here's a Rigol in "auto" mode. Visible/hidden memory is shown in a special indicator at the top of the window.
Here is a different Rigol model that in Auto mode keeps the memory depth equal to the visible window:
https://www.youtube.com/watch?v=yzb6_M3F5BQ (https://www.youtube.com/watch?v=yzb6_M3F5BQ)
So, it is model specific and people need to learn how their specific unit works. Industry standard my foot.
-
FWIW, I would hate for anyone to get too excited about what I might or might not have expected. I was expecting the waveform capture to start at the trigger point, so discovering that the scope captures all sorts of pre-trigger data was a big surprise. A very welcome, big surprise! :)
The trigger point is in the center of the buffer.
-
FWIW, I would hate for anyone to get too excited about what I might or might not have expected. I was expecting the waveform capture to start at the trigger point, so discovering that the scope captures all sorts of pre-trigger data was a big surprise. A very welcome, big surprise! :)
The trigger point is in the center of the buffer.
:-DD
And where if you place H Pos on the first graticule ?
-
So, it is model specific and people need to learn how their specific unit works. Industry standard my foot.
I don't have mine any more but that's not how I remember my DS1054Z working.
Anybody still have theirs...?
The Siglent refuses to capture outside the screen even when you set the memory depth manually to something much larger than the display.
-
So, it is model specific and people need to learn how their specific unit works. Industry standard my foot.
The Siglent refuses to capture outside the screen even when you set the memory depth manually to something much larger than the display.
So, lots of other scopes do this too. You just set the window to your preferred length and position then leave the zoom window open on the bit you want to see.
At this point you're arguing about the difference between the presented Rigol example with its large boarders, vs the Siglent which takes up around 1/3 of the screen.
So it's back to you taking preference to not see any content of the long capture unless you stop, vs others happy to see some detail of the long capture. But instead of just saying that its some convoluted mess about how CANT DO THING.
Why get emotional about it? Add personification to a scope? "The Siglent refuses" :-DD
Should I bomb any mention of a Rigol scope with your example of a scope that cant keep the memory depth to only the visible screen? It cant do some things other scoopes can, but its not some major issues that greatly limits the use of the scope.
-
So, it is model specific and people need to learn how their specific unit works. Industry standard my foot.
I don't have mine any more but that's not how I remember my DS1054Z working.
Anybody still have theirs...?
The Siglent refuses to capture outside the screen even when you set the memory depth manually to something much larger than the display.
Why are you claiming things that are not true?
Where did you get this information?
If you have Siglent scope that has manual memory control, it captures it same as R&S or any other scope that has it. You get trigger, and it captures exact amount you set it for.
But that beside the point, claiming that it is a good thing that scope always captures fixed amount of data instead of only what you need is simply laughable.
Old digital scopes had manual fixed memory length and you always had to twiddle manually and remember and think what you set and what is optimal.
Always long memory decreases number of triggers/s because it always captures lots of data. It slows down a scope, measurements, everything.
But OTOH, short memory forces scope to drop sampling rate.
And it frustrated people to no end. Manual memory mode is one of the main reason why people hated early DSO. If you had it on short memory it would alias all the time. If you set it to long memory it was SLOOW... Only few triggers per second... Wonder why...hmmm...
So after some time, scopes started coming with Auto memory management mode.
That one would automatically set memory length as you go through time base. Shorter memory on short time bases, longer as you go to longer timebases to keep sampling rate up (to avoid aliasing). As scope would get to max memory, then sample rate would eventually be dropped.
And everybody liked it because they were fed up with constantly twiddling memory settings.
This Auto mode exist on Siglent and Rigol. And Tek. And R&S and Micsig.
And manual mode works exactly the same on those too. Some Siglents have, some don't have manual memory mode. Nobody uses it anyways. It is a pain for actual use..
Difference (that confuses people) is that some scopes, when automatically set memory length, will have only few fixed memory lengths, and some will have an exact length for each timebase individually.
For instance Keysight 3000T. It has Auto memory mode. People keep repeating "it captures outside the screen!". It actually does not....
It uses a a trick when you stop the scope.
Take for an example a burst of data happening every 5 seconds.
You set it in Run mode, Normal trigger mode. It waits for signal.
Burst comes in. Capture.
You press Stop.
If you change timebase now, there is nothing outside the screen. WHAT?
BBButt Dave said there is....
Well. Dave is (partially?) wrong. It is not his fault (well he could have researched better before going on record..) but he was tricked.
See, MSOX3000T (and all other Megazooms IV) captures only what is on the screen in Run mode. But when you press Stop, it quickly reconfigures acquisition engine, and then initiates another trigger and captures ±200µ around the trigger. Unless you press Single in which case it will capture ±400µ around the trigger. That deletes last capture (one that you were looking into that prompted you to press Stop). If you are at 20µs/div or shorter. Unless you are at slower timebase in which case it doesn't. Or maybe. Or it does something else.
So it is a crapshoot. You might get something, or not, or maybe. If you do, it is going to be some random time. And only at fast timebases, 20µs/div and faster. To a serious person, that is not something to rely on. And the capture on the screen is not the one that you were looking at when you pressed Stop. That one was deleted and you get a different new one. Unless it times out (because signal is rare) in which case you get only what was on screen. So basically it is a lottery..
Only sure thing that will guarantee you will capture x amount of time around the trigger is to set the scope to do explicitly. With setting pretrigger time and post trigger time. Simplest, quickest and most intuitive way is to set it that scope shows the interval in question on the screen. It is simple. Like on analog scope. If it is not on the screen, you are not looking at it and you cannot see it.
It works on any and every scope including old CRT ones. And on digital scope, if you Stop it at that moment, you can than magnify portion of detail, by using timebase, Zoom, multiple windows or whatever scope in question supports and whatever is useful to you.
Everything else is mental acrobatics, or some special (forced?) corner case.
-
2N3055, that ^ is a helpful post - all of it, but especially the discussion of how the Megazooms IV operate. Thx
-
See, MSOX3000T (and all other Megazooms IV) captures only what is on the screen in Run mode.
That was also covered in the mega thread:
https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/msg3059524/#msg3059524 (https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/msg3059524/#msg3059524)
By you! Same posters present in that conversation, but come back here with lies misinformation.
-
Only sure thing that will guarantee you will capture x amount of time around the trigger is to set the scope to do explicitly.
I recently sold my Rigol DS1054Z and got me a Siglent SDS804X-HD.
The first time I tried to "zoom out" (more precisely, increase the timebase) on a stopped capture I thought "Oh, nothing outside the screen, I'll set a larger memory".
Did that, and, as we know, no dice.
I RTFMed. Always on History mode - mind blown.
Literally 10 minutes after getting the scope, I adapted to the different WoW; now I would really reluctantly go back to the old one, if I had to renounce history and zoom mode versatility.
But to each their own - at least until facts are correctly explained.
-
The Siglent refuses to capture outside the screen even when you set the memory depth manually to something much larger than the display.
Why are you claiming things that are not true?
Where did you get this information?
(https://www.eevblog.com/forum/testgear/a-newbie-needs-some-help-with-my-first-dso/?action=dlattach;attach=2283841;image)
-
The Siglent refuses to capture outside the screen even when you set the memory depth manually to something much larger than the display.
Why are you claiming things that are not true?
Where did you get this information?
.....when you set the memory depth manually......
-
The Siglent refuses to capture outside the screen even when you set the memory depth manually to something much larger than the display.
In Siglent's defense: the more recent models do support setting the memory length regardless it is more than needed to fill the display. Siglent finally woke up after Dave's video. So you'd have to check the model and firmware version.
-
The Siglent refuses to capture outside the screen even when you set the memory depth manually to something much larger than the display.
Why are you claiming things that are not true?
Where did you get this information?
(https://www.eevblog.com/forum/testgear/a-newbie-needs-some-help-with-my-first-dso/?action=dlattach;attach=2283841;image)
:blah: :blah:
(https://www.eevblog.com/forum/testgear/a-newbie-needs-some-help-with-my-first-dso/?action=dlattach;attach=2284099)
-
Siglent finally woke up after Dave's video.
Yes, exactly, because a forum operator had made a video and a handful of forum users blew the same horn, saying that it was really important to be able to do that, so Siglent woke up and gave the few people what they wanted.
I would think about that again.
Perhaps look into when and with which models this is possible and what these models have in common.
A little hint, this has something to do with a (math) function that did not previously exist in Siglent scopes.
-
Siglent finally woke up after Dave's video.
Yes, exactly, because a forum operator had made a video and a handful of forum users blew the same horn, saying that it was really important to be able to do that, so Siglent woke up and gave the few people what they wanted.
I would think about that again.
You may say it caters to a few people but then explain me this: All DSOs from many different brands I have owned and many which I used, supported capturing beyond what is needed to fill the screen (including the Siglent SDS2000 with the initial firmware but except Lecroy). Even my Tektronix 2230 from the 1980's had capturing beyond the screen. You can not convince me that oscilloscope manufacters from all over the world have been putting a feature in their equipment for about 40 years which only very few users find important. It just doesn't make sense.
Also keep in mind that EEVblog only has a very small number of EEs taking part. EEVblog is nowhere near representative where it comes to test equipment users or EEs in general. 9 out of 10 EEs I talk to never heard about EEVblog. Then again, Siglent seems to be quite interested in Dave's videos and sends him their equipment to test regulary. So it is reasonable to assume Siglent takes note of Dave's findings. OTOH test equipment manufacturers which have been around for a couple of decades already have a much better view on what is important to their customers and implement (=spend money on) features accordingly. Take a modern DSO from R&S or Tektronix for example, they all allow to set & use the maximum memory length even though these are new designs. That is no accident for sure!
-
Take a modern DSO from R&S or Tektronix for example, they all allow to set & use the maximum memory length even though these are new designs. That is no accident for sure!
As was previously said, SOME scope models from SOME brands do that, including Siglent. I don't see the point in this discussion at all.
-
This may not be very exciting to those of you who are more experienced ... but just in case anyone is interested, I am happy to report that I have had my first success in using my new SDS804X "for real."
I am sure this was a trivial example for most - a small custom PC board built around an Atmega Tiny 84a, a DVR8837c motor controller, an IR sensor, and a couple of buttons; I designed this to replace a failed controller board. Having 4 channels and the ability to capture relatively slow events (both in rolling mode and in single-shot mode where I could zoom in to check timing between various signals) allowed me to debug a problem with the DVR8837c (turned out that one of the leads didn't get soldered properly) - and it also alerted me to a strange bug that was completely unexpected, a periodic wake-up from sleep mode that shouldn't be happening - I still am working on what that's about. I was also able to test the debounce filter on the switches (using single-shot mode, then zooming in) to discover that I somehow put a 10uF capacitor where I meant to put a .1uF capacitor ... just a wee bit of difference. (In general I really like using 0603 and 0805 SMD components, but I hate that there are no markings on the capacitors - or at least, none that I am aware of - it wasn't until I saw the l - o - n - g slope of the signal that I realized something was wrong.
Again, none of this compares to the kinds of high-speed engineering some of you all do, but I am really thrilled - this is exactly the sort of thing I had not been able to pin down using my old analog scope, and thus the reason I decided to buy a DSO!
-
This may not be very exciting to those of you who are more experienced ... but just in case anyone is interested, I am happy to report that I have had my first success in using my new SDS804X "for real."
:-+
..........to discover that I somehow put a 10uF capacitor where I meant to put a .1uF capacitor ... just a wee bit of difference. (In general I really like using 0603 and 0805 SMD components, but I hate that there are no markings on the capacitors - or at least, none that I am aware of - it wasn't until I saw the l - o - n - g slope of the signal that I realized something was wrong.
Let ST42 be your next investment. ;)
https://www.eevblog.com/forum/testgear/design-a-new-precision-lcr-tweezers/ (https://www.eevblog.com/forum/testgear/design-a-new-precision-lcr-tweezers/)
-
This may not be very exciting to those of you who are more experienced ... but just in case anyone is interested, I am happy to report that I have had my first success in using my new SDS804X "for real."
I am sure this was a trivial example for most -
Again, none of this compares to the kinds of high-speed engineering some of you all do, but I am really thrilled - this is exactly the sort of thing I had not been able to pin down using my old analog scope, and thus the reason I decided to buy a DSO!
Good stuff! :)
It is easy to forget that a scope is merely one tool that helps you get a job done. What matters is that you decide what you need to find out, you know what each tool can and cannot do, you choose an appropriate tool, and use it effectively. Often it is easier to answer a question, and more difficult to find the right question to ask.
It is frequently the case that there is overlap in tools capabilities.
-
Let ST42 be your next investment. ;)
https://www.eevblog.com/forum/testgear/design-a-new-precision-lcr-tweezers/ (https://www.eevblog.com/forum/testgear/design-a-new-precision-lcr-tweezers/)
Thanks for the tip! Ordered and on the way ...