| Products > Test Equipment |
| Siglent - 11/20 - New SDS1104X-U, 4 channel 100MHz, 1Gsa/s economy oscilloscope |
| << < (26/32) > >> |
| 2N3055:
Scope timebases on Keysight 3000T range from 5E-10 to 50 seconds per div.. It is hard doing tricks like that with 11 orders of magnitude of time span. Also, you forget about measurements, those have to be optimized for speed and for that you want streamlined data formats and flow. Also you cannot retrigger while capturing unless you have datapath that will change where it writes data all the time.. Capturing goes into circular buffer of certain size, all the time. Trigger engine only leaves the marker where trigger happened, and then you rollover and keep capturing until you reach trigger point from the other side. Than you start dumping data on other memory location, leaving last data buffer for display/measurement engine to process it. That is also your history buffers. Or you can do what Keysight does, always getting absolute minimum of data points and reconfigure to single on STOP. And you shuffle and do tricks inside Megazoom chipset. That are possible only because very small memory. If you were to make 10-MEgazoom or 100-Megazoom chip, it would have to work differently. It's literally 100 times more processing than what 1-Megazoom chip has to do. Not to mention fixed low res display window compared to higher resolution displays... |
| kcbrown:
--- Quote from: 2N3055 on February 04, 2021, 12:04:02 pm ---Scope timebases on Keysight 3000T range from 5E-10 to 50 seconds per div.. It is hard doing tricks like that with 11 orders of magnitude of time span. --- End quote --- Why? The timebase, combined with the memory depth, ultimately determines the sampling rate. The sampling rate is set so as to ensure that the time covered by the buffer is never less than the time represented by the screen. The algorithm I described is independent of the sample rate. --- Quote ---Also, you forget about measurements, those have to be optimized for speed and for that you want streamlined data formats and flow. --- End quote --- Sure, and that would place some additional demands on at least some of the data. I fully expect that the sampled data would have to be decimated and processed in real time by the FPGA. But these are separate processing paths. I admit that if you're using DRAM, then a memory controller that makes possible the kinds of parallel processing of data needed here might be quite a challenge to design. Decimation into a separate buffer (likely internal to the FPGA) would have to be able to keep up with the fastest sampling rate the scope is capable of. Fast SRAM is more expensive but might be needed for something like this if the sample rate is high enough. You might even incorporate SRAM into your DRAM memory controller design and use that as a write-through cache to satisfy reads when possible. --- Quote ---Also you cannot retrigger while capturing unless you have datapath that will change where it writes data all the time.. --- End quote --- Why is that? As you note, a trigger event merely sets a marker. That happens while capturing. The implementation I described requires only a single trigger event location pointer, which always points at where the last trigger event occurred. --- Quote ---Capturing goes into circular buffer of certain size, all the time. Trigger engine only leaves the marker where trigger happened, and then you rollover and keep capturing until you reach trigger point from the other side. Than you start dumping data on other memory location, leaving last data buffer for display/measurement engine to process it. That is also your history buffers. --- End quote --- That's exactly what I was describing above. The primary difference is that what I described would re-arm the trigger after the acquisition had passed the location boundary of the display, rather than the end of the buffer, and whether or not the buffer location for the next acquisition would be reset to the start of the current buffer section of N points would depend on whether a trigger event occurred within the last N points (if no event occurred within the next N points then it would reset the acquisition location to the start of the existing buffer area because the rest of the buffer area might contain a trigger event and that would need to be preserved). Think of the implementation I described as a conditional circular buffer implemented within another circular buffer that's twice the size. The point of it is to ensure that you always preserve a memory region of N points that contains the last seen trigger event within it, as long as at least one trigger event was seen at all, as well as to ensure that the trigger fires, and the resulting processing happens, as often as possible. My question is: how is what I described so different from what scopes currently do that what I described is not possible to implement with the hardware used by low-end scopes? What mandates that the trigger must fire at most once per amount of time represented by the memory depth and sample rate combination? |
| nctnico:
--- Quote from: kcbrown on February 04, 2021, 07:09:40 pm ---My question is: how is what I described so different from what scopes currently do that what I described is not possible to implement with the hardware used by low-end scopes? What mandates that the trigger must fire at most once per amount of time represented by the memory depth and sample rate combination? --- End quote --- Simplicity and low return on investment. See how much discussion already is sparked by relatively basic acquisition schemes. Besides that the search function found on many oscilloscopes nowadays can look for trigger events in the acquired data (either in a single record or segments). This is similar to what you are proposing. |
| kcbrown:
--- Quote from: nctnico on February 04, 2021, 08:26:03 pm ---Simplicity and low return on investment. See how much discussion already is sparked by relatively basic acquisition schemes. Besides that the search function found on many oscilloscopes nowadays can look for trigger events in the acquired record. This is similar to what you are proposing. --- End quote --- I guess so. That's especially true if it requires designing a custom DRAM controller. |
| tautech:
Talk about cutting it fine :phew: .....finally got around to checking the SDS1104X-U BW after spotting Defpom reporting is as only a little over its rated 100 MHz BW and indeed it just barely makes spec. Source SDG6022X Sweep 0-200 MHz -3dB point ~103 MHz |
| Navigation |
| Message Index |
| Next page |
| Previous page |