Products > Test Equipment
Siglent - 11/20 - New SDS1104X-U, 4 channel 100MHz, 1Gsa/s economy oscilloscope
2N3055:
Nico is right.
Only Keysight does this juggling.
Keysight in Normal mode keeps triggering and grabbing only screen full of data. Sometimes only 50 points. You can check that by sending single bursts from siggen manually.
Take a capture in RUN mode and try moving waveform horizontally or change timebase... And if you press STOP, it will do nothing with existing capture. Still no additional data.
It will actually wait for next trigger and that one will be taken same as if it were in SINGLE mode. So, on Keysight (3000T series) I confirm that going from RUN to STOP is similar to pressing SINGLE while in RUN mode. That one last capture will be full length.
Fun fact, if that last trigger it's waiting for, is delayed more than 100ms it will abort. So unlike SINGLE, it won't wait forever.
Keysight took a lot of time with all kinds of tricks like this to create an illusion that it takes long captures AND is fast at the same time. It isn't. It's just tricking user to think so..
On fast signals you would never know. Recently they added special capture mode to fix memory, because people wanted a mode where scope behaves deterministically....
So truth is, that with Keysight 3000T, you cannot notice something interesting on the screen while in RUN between triggers, press STOP and then look at the more data, like Dave and others think it works. That last long capture will be next trigger....Or none if it times out. The one you wanted to zoom out, will be either lost, or will be screen size, nothing before or after...
Every other capture while in RUN mode is just what will fit on screen at current timebase.
Same as Siglent, except Siglent has much more memory and Siglent won't do that trick with switching to SINGLE going from RUN to STOP.
On scopes that have fixed memory length, they will always capture full requested length. Rigols have a setting if you want memory to be Auto (Siglent style) or fixed length all the time..
So if you set Instek for 10 MS and you have it on any timebase that will keep 1 GS/sec, you will always get 10 ms of data, even if you set scope to 5ns/DIV. And have max 100 triggers per sec..
Regards,
Sinisa
2N3055:
--- Quote from: nctnico on February 03, 2021, 11:53:25 pm ---What is different between Siglent and other oscilloscopes is that Siglent dynamically alters the number of samples to sample only enough to fill the screen regardless of the memory depth selected by the user.
--- End quote ---
Keysight does it too, also Rigol and Micsig when set to Auto memory mode. It is normal mode, nothing unusual, or bad.
With Rigol and Micsig you do have a choice of strategy though, if that is important for user. Keysight sampler mode is too awkward to be used in normal work.
2N3055:
--- Quote from: kcbrown on February 04, 2021, 12:07:52 am ---
OK, so I apparently did misunderstand how the acquisition of the Instek works. This means the Siglent actually gives you an advantage here, because it gives you fine-grained control over the acquisition rate, whilst the Instek only gives you coarse control by way of specifying the acquisition buffer size.
I'll modify my original message to reflect the consequences of this, because they're not insignificant.
--- End quote ---
And now you understood exactly my point in lengthy discussion about scopes that "are better because they can set sample buffer size manually"..
It is easier and deterministic and requires no constant mental math (and less human errors because of it) to simply set time span you want to look at, capture the lot and then drill into detail.
The Siglent, LeCroy, Pico way. And Rigol ,Micsig R&S and many more support that memory management mode. With Siglent, Lecroy, R&S, Pico also supporting history mode, that lets you review previous captures..
If you really need to look at just a part of that big buffer, you open zoom window and dial in that exact time to look at.... Simple.
Nicos method does achieve same dataset, and saves screen space (zoom does take screen real estate, true), but is (to me) more convoluted to setup... But both work.
kcbrown:
--- Quote from: 2N3055 on February 04, 2021, 12:49:04 am ---And now you understood exactly my point in lengthy discussion about scopes that "are better because they can set sample buffer size manually"..
It is easier and deterministic and requires no constant mental math (and less human errors because of it) to simply set time span you want to look at, capture the lot and then drill into detail.
--- End quote ---
Yep. I recognized that early on: "It has the advantage of clarity, in that it makes it clear exactly what you're getting for any given capture, and it then is on you to set your timebase appropriately to capture what you need."
--- Quote ---Nicos method does achieve same dataset, and saves screen space (zoom does take screen real estate, true), but is (to me) more convoluted to setup... But both work.
--- End quote ---
This is one of the reasons the SDS2000X+ series is so nice. The screen is large enough that you still have a decent amount of waveform real-estate even in zoom mode. On that scope, zoom mode is suddenly way more usable. And it's clear they've done a lot to make it that way. Even mask testing works in zoom mode now, something I viewed as perhaps the most significant shortcoming to Siglent's implementation.
Honestly, it wouldn't take much at this point for Siglent to change zoom mode so that it can, at the user's option, use the entire waveform display area of the screen for the zoomed section, and have the unzoomed section represented in iconic form in exactly the same way that most other scopes represent the capture buffer versus the viewed portion, namely:
All they would then need is some way to clearly indicate that zoom mode is active, since changing the horizontal scale would no longer change the acquisition timebase.
I'd love to see the same sort of thing on the SDS2000X+ as well, though it has enough screen real estate that they could use perhaps 1 vertical division's worth of real estate to represent the unzoomed view.
kcbrown:
--- Quote from: tautech on February 04, 2021, 12:17:11 am ---Is it not blatantly obvious there are 2 different capture philosophies used by the wfps datasheet spec ?
--- End quote ---
The philosophies aren't as different as I thought, frankly. Both fill the defined buffer. The difference is in how the buffer is defined.
I'm frankly surprised that the Instek doesn't reenable the trigger immediately after it has gotten enough data to display. Which is to say, I'm surprised the Instek's capture sequence isn't something like this (the below presumes a system with a circular memory buffer of size 2*N, where N is the number of sample points configured for the capture):
1. Scope sets the start of the capture (call this S) to a predefined point in the buffer (probably just the absolute beginning address of the buffer), nulls the last trigger location (call this T), erases the display processor's list of frames, and begins acquisition. Acquisition continues until the scope is stopped.
2. While acquisition is going, it would take the following conditional actions:
a. If N points have been acquired and no trigger events have occurred since S, reset the acquisition location to S.
b. If N points have been acquired, and at least N/2 points have been acquired since T, then set S to the current acquisition location.
c. If the trigger conditions are met, set T to the current acquisition location and disarm the trigger.
d. If the current location corresponds to the rightmost acquisition point that would be shown on the screen after T, add the decimated data for the points from the beginning of the screen to the end of the screen to the display processor's list of frames, and re-arm the trigger.
e. If 1/60th of a second has passed since the last display update, the display processor combines all of the frames in its list (if any) into a single display frame and ships it to the screen, and clears its list. If its frame list was empty then it does nothing.
3. The scope is commanded to stop. At this point:
a. If a trigger event has occurred within the last N points, then (if necessary) continue to acquire until either N/2 points past the last trigger point or until N points since S, whichever is later, then stop capture, and then make it possible to see the captured data from S to the current point (i.e., would make it possible to see N points, with at most N/2 before the last trigger point and at least N/2 after it).
b. If a trigger event has not occurred within the last N points, but the other half of the total buffer contains a trigger event (i.e., 2b happened), then make that other half available for display.
c. Otherwise, no trigger events occurred since the scope was started, so there's nothing to display.
With the above setup, the trigger would be re-armed when acquisition hits the rightmost edge of the screen relative to the trigger. This would cause trigger events to be processed, and the display updated, not based on the length of the acquisition buffer but rather based on the width of the screen. But once the scope is stopped, you'd have an entire capture buffer's worth of data at your disposal.
The above is approximate, of course. I'm sure there are conditions that I haven't accounted for. But hopefully you get the idea here. In essence, the scope would always maintain a current circular acquisition buffer of N points, within a total memory buffer of 2*N points worth. It's double buffering, in essence, but the double buffering is conditional upon the trigger having fired at least once within the last N points, and making the buffer continuous in this manner means that you don't have to play with bank switching or anything like that which might complicate processing. But as a hardware matter, for it to work, the memory would need enough bandwidth to be written to at the sampling rate in one region while being read in a different region. And, of course, decimation for screen display purposes would certainly have to happen in hardware (FPGA).
I'm not any kind of genius or anything. That much should be obvious. :) The above seems straightforward in my naive estimation, so surely it has been thought of long before. What is it about it that makes it unworkable in practice, such that there doesn't seem to be an inexpensive scope that does it (that I know of)? It has the advantage of a trigger refresh rate that's as fast as the scope can manage combined with a traditional "the configured buffer always gets filled" end result that people expect.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version