EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: tcsaba101 on December 21, 2020, 09:01:11 pm
-
If you would have 4k USD budget for a scope what you would buy and why? It must be a new unused one.
4 ch needed.
-
R&S
-
R&S
You forget the "why".. ;)
Me, I would prefer the SDS5K from siglent - Why ?
Because it got 5GSa/s, 250Mpt Memory, 50 Ohm Termination, external sensors for e.g. current probes, etc.
350Mhz 4ch. model will cost appx 3300€ incl. VAT. and it´s hackable to 500Mhz.
Next would be indeed the R&S RTB2000 line.
It got higher resolution screen and real 10 bit ADC, but it got no sensor inputs or 50ohm termination.
Also it got less samplerate (2.5GSa/s) and memory(20Mpts).
But for 4000 bucks, in my opinion you have only these two choices.
-
If you would have 4k USD budget for a scope what you would buy and why? It must be a new unused one.
4 ch needed.
This question is impossible to answer without knowing what you want to do with it.
It is similar to asking which car to get for a given budget. Without knowing whether you like a sporty ride or have a family of 7 to drive around nobody can give you a sensible answer.
-
Like Nico say, lousy question.
State what you do and what are your expectations..
With 4000USD you can buy both great scope for your purpose or very good but wrong type...
-
Me, I would prefer the SDS5K from siglent - Why ?
Because it got 5GSa/s, 250Mpt Memory, 50 Ohm Termination, external sensors for e.g. current probes, etc.
350Mhz 4ch. model will cost appx 3300€ incl. VAT. and it´s hackable to 500Mhz.
Rigol MSO5074: 8Gsa/s, 350 mem = $990 :)
-
If I would have only 990 to spend, then yes.
But the starting question was, what if you would have 4000...
-
Tektronix MDO 3 series is nice, in particular thanks to the built in spectrum analyzer and huge display. It's got its issues and only buy it when the software options are bundled to it for free, but it's a cool instrument.
-
If you would have 4k USD budget for a scope what you would buy and why? It must be a new unused one.
4 ch needed.
Following in this type of questioning: and why do you have only 4k USD budget?
-
Thanks for the answers!
I have had a post where I have discussed the details, got one good answer.
https://www.eevblog.com/forum/testgear/sds5034x-or-rtb2k-com4/msg3372606/#msg3372606 (https://www.eevblog.com/forum/testgear/sds5034x-or-rtb2k-com4/msg3372606/#msg3372606)
I have put another viewpoint in this post. And I see this way it was more interesting.
This question is impossible to answer without knowing what you want to do with it.
It is similar to asking which car to get for a given budget. Without knowing whether you like a sporty ride or have a family of 7 to drive around nobody can give you a sensible answer.
This I wrote down in my post above.
Me, I would prefer the SDS5K from siglent - Why ?
Because it got 5GSa/s, 250Mpt Memory, 50 Ohm Termination, external sensors for e.g. current probes, etc.
350Mhz 4ch. model will cost appx 3300€ incl. VAT. and it´s hackable to 500Mhz.
Next would be indeed the R&S RTB2000 line.
It got higher resolution screen and real 10 bit ADC, but it got no sensor inputs or 50ohm termination.
Also it got less samplerate (2.5GSa/s) and memory(20Mpts).
But for 4000 bucks, in my opinion you have only these two choices.
Thanks Martin! My budget will open on 1st of Febr. Still I have time to decide.
I am bending to the SDS5034X because of SPS and memory, it will better fit to my present and future equipment in hand.
Following in this type of questioning: and why do you have only 4k USD budget?
I think for my present use even this range of equipment is a bit of overkill. The Rigol MSO5074 would fulfill the present use.
When I have set up the budget plan the 4k range was the most logical choice.
I think today this is the most powerful price/features domain. Especially using the manufacturer's promotion on the market now!
There is a big price gap to the next level of oscilloscope families like Siglent SDS5104, Rigol MSO8000 or R&S RTM3000, etc.
-
If you haven't found it already here is the SDS5000X thread:
https://www.eevblog.com/forum/testgear/at-last-siglent_s-sds5054x-touchscreen/ (https://www.eevblog.com/forum/testgear/at-last-siglent_s-sds5054x-touchscreen/)
Nice DSO and I have a 5054X as my personal scope with all the bells and whistles like MSO and active probe so anything you wanna see please just ask.
-
Thanks for the answers!
I have had a post where I have discussed the details, got one good answer.
https://www.eevblog.com/forum/testgear/sds5034x-or-rtb2k-com4/msg3372606/#msg3372606 (https://www.eevblog.com/forum/testgear/sds5034x-or-rtb2k-com4/msg3372606/#msg3372606)
I have put another viewpoint in this post. And I see this way it was more interesting.
For this budget I'd get both scopes on loan and see which one fits you best. Be sure to make some kind of test plan / test setup though in order to go through some real usage scenarios. Personally I think the R&S scope beats the Siglent where it comes to decoding (especially displaying decoded data and doing full memory decoding) and memory handling in general.
-
If we are to look decoding:
R&S 3k
I2C, SPI, UART/RS-232/RS-422/RS-485, CAN, LIN, audio (I²S/LJ/RJ/TDM), ARINC, MIL
Siglent 5kX...all currently free on promotion
I2C, SPI, UART, CAN, LIN, CAN FD, FlexRay, I2S, MIL-STD-1553B, Manchester and Sent (last 2 added in recent FW)
-
I took a look at that other post, and my answer would be to get a Picoscope and SDS2000X+..
Between those two there isn't much you can't do.
Picoscope can have two 27" screens, many zooms, views, it has excellent FFT, saving and opening data directly to PC etc etc..
For decoding, that is my goto scope.
Also it has good API, direct link to Lavbiew, Matlab, and you can quickly put together your code to do something.
Also it has always running history buffers, as many math channels as you like et etc.
Also has DeepMeasure, and you can export data to Excel for later analysys (That works for decodes too).
For CAN you can have translate file to work with symbolic messages..
Only thing you don't get are protocol triggers.. But that is not such a problem as I tough it would be, I just set classical trigger and grab the lot...
Classical triggers are advanced.
I also use it all the time when I need to document something, it's just faster than grabbing from standalone scope..
Combining that with another interactive scope for general probing around would give you lot of capability.
-
I must have completely mis interpreted the title. I literally thought the question was about a scope with a 4K screen. If such a scope existed it would be fantastic as I'm sitting in front of a 4k screen right now. This makes me wonder if the Pico Scopes or other PC based scopes can actually make use of a 4K screen.
-
Siglent SDS2104X Plus
-
I must have completely mis interpreted the title. I literally thought the question was about a scope with a 4K screen. If such a scope existed it would be fantastic as I'm sitting in front of a 4k screen right now. This makes me wonder if the Pico Scopes or other PC based scopes can actually make use of a 4K screen.
They work on 4K screen. But it is useful only for having many small viewports. Unless you have 16 Bit Pico, signal doesn't get any use of all the (unnecessarily) high resolution. For an 8 bit scope, your whole vertical resolution is 250 pixels..... I find that 1920*1200 on 24" screen yields pixels that are not perceptible at normal working distance. I would think that it make sense for 32" screens to go for 4K...
-
I must have completely mis interpreted the title. I literally thought the question was about a scope with a 4K screen. If such a scope existed it would be fantastic as I'm sitting in front of a 4k screen right now. This makes me wonder if the Pico Scopes or other PC based scopes can actually make use of a 4K screen.
They work on 4K screen. But it is useful only for having many small viewports. Unless you have 16 Bit Pico, signal doesn't get any use of all the (unnecessarily) high resolution. For an 8 bit scope, your whole vertical resolution is 250 pixels..... I find that 1920*1200 on 24" screen yields pixels that are not perceptible at normal working distance. I would think that it make sense for 32" screens to go for 4K...
For an 8 bit scope your vertical resolution is around 250 pixels per channel but with say 4 channels thats 1000. Add in a spectrum plot and a few maths / reference channels and some gaps between channels and some space for UI and even at 8 bits 2000 pixels makes sense.
Many scopes now are either 10 or 12 bit (1024 or 4096 vertical steps) in hardware or offer resolution enhancement to these levels so for these scopes a large 4K display is fully justified. Its like going from an old VHS video tape to modern HD - you will not want to go back.
-
Let me explain better: it is always better to have more screen real estate.
But 3840 x 2160 pixel on 24" monitor won't give you more screen space, it will make everything smaller.
So you can put many little scope windows on the screen, and you will have to come closer to see it.
What you need is more screen area, as in 3x3 meter monitor... >:D
I opted for classic 1920x1200 res, but have two monitors side by side.
Not that I'm saying that I'm against it. It's just that there is not much difference from normal working distance, graphic card has to manage 4x the pixels, and at some point you cannot really put more things on the screen because they get too small when you sit normally at the desk.
It means nothing that they are perfectly clear when you come close and use magnifying glass..
It is like saying 300HP car is better than 150HP car. Of course it is, but in real life, sitting in traffic, you won't notice the difference. Except it needs more fuel and is more expensive. So if you need to give twice the money expecting twice the usability, it won't be like that. You would have more usability buying two smaller cars so you and your wife can can each drive at the same time. Of course, if 4K costs you nothing more and you still can get 2 by all means. It won't be wrong, quite the opposite. But biggest gain is from bigger monitor (by size) or more monitors, not by increasing resolution.
-
If you haven't found it already here is the SDS5000X thread:
https://www.eevblog.com/forum/testgear/at-last-siglent_s-sds5054x-touchscreen/ (https://www.eevblog.com/forum/testgear/at-last-siglent_s-sds5054x-touchscreen/)
Nice DSO and I have a 5054X as my personal scope with all the bells and whistles like MSO and active probe so anything you wanna see please just ask.
I have checked most of recent teardowns. Including Dave's extensive one.
I have some questions:
1. SPS: 5G/ 1 channel; 2.5G/2 channel (1, 3 inputs); If I use 3 or 4 channels what SPS is possible on different inputs?
2. On the screen can we control the menus using a mouse on the USB port?
3. Here is a video about "ERES" enhanced resolution: https://www.youtube.com/watch?v=hvW7IFjoHbU. (https://www.youtube.com/watch?v=hvW7IFjoHbU.) How the SPS and sample memory is changing with different resolutions?
4. What is the state of the firmware debugging? At the beginning, in a lot of posts this was a major concern of a "new Chinese top scope"?
-
Let me explain better: it is always better to have more screen real estate.
But 3840 x 2160 pixel on 24" monitor won't give you more screen space, it will make everything smaller.
So you can put many little scope windows on the screen, and you will have to come closer to see it.
What you need is more screen area, as in 3x3 meter monitor... >:D
I opted for classic 1920x1200 res, but have two monitors side by side.
Not that I'm saying that I'm against it. It's just that there is not much difference from normal working distance, graphic card has to manage 4x the pixels, and at some point you cannot really put more things on the screen because they get too small when you sit normally at the desk.
It means nothing that they are perfectly clear when you come close and use magnifying glass..
It is like saying 300HP car is better than 150HP car. Of course it is, but in real life, sitting in traffic, you won't notice the difference. Except it needs more fuel and is more expensive. So if you need to give twice the money expecting twice the usability, it won't be like that. You would have more usability buying two smaller cars so you and your wife can can each drive at the same time. Of course, if 4K costs you nothing more and you still can get 2 by all means. It won't be wrong, quite the opposite. But biggest gain is from bigger monitor (by size) or more monitors, not by increasing resolution.
It sounds like the 10/10 rule in HiFi systems. 10% better sound for 10 times higher cost.
-
I took a look at that other post, and my answer would be to get a Picoscope and SDS2000X+..
Between those two there isn't much you can't do.
Picoscope can have two 27" screens, many zooms, views, it has excellent FFT, saving and opening data directly to PC etc etc..
For decoding, that is my goto scope.
Also it has good API, direct link to Lavbiew, Matlab, and you can quickly put together your code to do something.
Also it has always running history buffers, as many math channels as you like et etc.
Also has DeepMeasure, and you can export data to Excel for later analysys (That works for decodes too).
For CAN you can have translate file to work with symbolic messages..
Only thing you don't get are protocol triggers.. But that is not such a problem as I tough it would be, I just set classical trigger and grab the lot...
Classical triggers are advanced.
I also use it all the time when I need to document something, it's just faster than grabbing from standalone scope..
Combining that with another interactive scope for general probing around would give you lot of capability.
Thanks, I have got answer to my Picoscope concerns. The easier documentation what I expected to help me in the job.
-
If we are to look decoding:
R&S 3k
I2C, SPI, UART/RS-232/RS-422/RS-485, CAN, LIN, audio (I²S/LJ/RJ/TDM), ARINC, MIL
Siglent 5kX...all currently free on promotion
I2C, SPI, UART, CAN, LIN, CAN FD, FlexRay, I2S, MIL-STD-1553B, Manchester and Sent (last 2 added in recent FW)
"R&S 2k" in the picture in this comparison not the "3k" line!
In the current promotions:
In R&S 2k the 16ch logic analyzer hw+fw included,
while for Siglent it is about 900 USD upgrade, if I understood well.
I will call the distributor in next days for the clear picture.
-
If you haven't found it already here is the SDS5000X thread:
https://www.eevblog.com/forum/testgear/at-last-siglent_s-sds5054x-touchscreen/ (https://www.eevblog.com/forum/testgear/at-last-siglent_s-sds5054x-touchscreen/)
Nice DSO and I have a 5054X as my personal scope with all the bells and whistles like MSO and active probe so anything you wanna see please just ask.
I have checked most of recent teardowns. Including Dave's extensive one.
I have some questions:
1. SPS: 5G/ 1 channel; 2.5G/2 channel (1, 3 inputs); If I use 3 or 4 channels what SPS is possible on different inputs?
2. On the screen can we control the menus using a mouse on the USB port?
3. Here is a video about "ERES" enhanced resolution: https://www.youtube.com/watch?v=hvW7IFjoHbU. (https://www.youtube.com/watch?v=hvW7IFjoHbU.) How the SPS and sample memory is changing with different resolutions?
4. What is the state of the firmware debugging? At the beginning, in a lot of posts this was a major concern of a "new Chinese top scope"?
1. It has dual 5 GSa/s ADC's and each with 250 Mpts mem support therefore when only 2 channels are used and each is on the other ADC full sampling and mem is available to each channel. EG, 1+3, 1+4, 2+3, 2+4.
Only when 3 or more channels are used is sampling and mem depth halved.
All channels active = 2.5 GSa/s and 125 Mpts each channel.
2. Certainly you can access most everything with a mouse. In the webserver app everything is controlled by mouse.
3. As my answer for #1 however ERES does impact on sampling rates in much the same way Averaging does.
4. Currently SDS5000X and SDS2000X Plus firmware are closely aligned where there are no show stopping bugs.
A few annoying bugs were fixed in the last firmware when customizable color traces and Manchester and Sent decodes where added.
If we are to look decoding:
R&S 3k
I2C, SPI, UART/RS-232/RS-422/RS-485, CAN, LIN, audio (I²S/LJ/RJ/TDM), ARINC, MIL
Siglent 5kX...all currently free on promotion
I2C, SPI, UART, CAN, LIN, CAN FD, FlexRay, I2S, MIL-STD-1553B, Manchester and Sent (last 2 added in recent FW)
"R&S 2k" in the picture in this comparison not the "3k" line!
In the current promotions:
In R&S 2k the 16ch logic analyzer hw+fw included,
while for Siglent it is about 900 USD upgrade, if I understood well.
I will call the distributor in next days for the clear picture.
RS 2k is in another lower class of capability whereas the model for an equal comparison is a RS 3k which still has far less memory depth to what the SDS5000X can offer.
MSO
SPL2016 is $ 369. License SDS-5000X-16LA is $ 429 which I always though was way too expensive when we can get the MSO license for the now old SDS2000X (before Plus models) for just $ 119.
It's a good thing the SDS5000X MSO license can be easily hacked. :phew:
-
RS 2k is in another lower class of capability whereas the model for an equal comparison is a RS 3k which still has far less memory depth to what the SDS5000X can offer.
Not quite so. The R&S RTB2000 series has up to 160Mpts and the RTM3000 series has up to 400Mpts in segmented recording / history mode.
-
Siglent itself compares the 5K model with Tek and Keysight, see pic.
The only advantage I see in the RTB2K models are the 10bit ADC, as ever, they´re unique in this pricerange.
-
RS 2k is in another lower class of capability whereas the model for an equal comparison is a RS 3k which still has far less memory depth to what the SDS5000X can offer.
Not quite so. The R&S RTB2000 series has up to 160Mpts and the RTM3000 series has up to 400Mpts in segmented recording / history mode.
RTM3000 actually has almost 214 Mpoints per ch in segmented mode, meaning 856 total in one of acquisitions settings.
OTOH SDS5000X has 500Mpoints in normal mode (2x250) and also much more than 500 MPoints in segmented, I don't know how much I cant find a post right now, someone measured it.
RTM3000 has a lot of memory in segmented mode, and also very fast retrigger time. But it has very limited analysis options on it..
It a shame, really, it could have been best scope in class, but they passed on on that opportunity. So many artificial limits by manufacturer, not create problems in their own scope hierarchy..
But in normal mode it is RTM3000 with 80 MPoint/2ch (or 40Mpoint/4ch) VS. SDS5000X with 250Mpoints/2ch (or 125Mpoints/4ch).
RTB2000 has only 20/10 MPoints 2/4ch.
Of course that might or might not be important, but is significant 3x difference in normal mode...
Problem is RTM is not 4k$ scope.
And RTB2000 is not in SDS5000X class. RTB2000 has nice GUI working for it, and some may favor that to better specs.. I would not.
-
Their "the power of ten" disclaimer are getting "old"....
10" Display are today not a breathtaker as the much more cheaper siglent SDS2K+ also got it
Native 10 bit ADC are a point, even today none got it for this price (RTB2K).
But do I really need it ?
10Mpts...Well, today this memory is nothing.
As said, the formerly "truly gamechanger" scopes from R&S are getting old... ;)
-
RTM3000 actually has almost 214 Mpoints per ch in segmented mode, meaning 856 total in one of acquisitions settings.
OTOH SDS5000X has 500Mpoints in normal mode (2x250) and also much more than 500 MPoints in segmented, I don't know how much I cant find a post right now, someone measured it.
Actually, segmented memory length is nearly identical: 216.75 Mpts per channel or 867 Mpts total for the Siglent SDS5000X.
This is standard for the Siglent, whereas it was a ~$1000,- option for the R&S when I last looked.
-
For an 8 bit scope, your whole vertical resolution is 250 pixels.....
That's only true fully zoomed in, but any decimation will increase the precision so unless you're running the scope to the limit you'll have more than eight bits of trace data.
-
Their "the power of ten" disclaimer are getting "old"....
10" Display are today not a breathtaker as the much more cheaper siglent SDS2K+ also got it
Native 10 bit ADC are a point, even today none got it for this price (RTB2K).
But do I really need it ?
10Mpts...Well, today this memory is nothing.
As said, the formerly "truly gamechanger" scopes from R&S are getting old... ;)
Not if you want a scope which just works. Reading the SDS2k+ bugs and features thread doesn't make me want one. I prefer to buy something which has seen some testing at the manufacturer rather than being the one who is doing the testing AND having to pay for a piece of equipment.
-
The SDS2K+ just works also.
And the R&S weren´t flawless from the beginning on, have a look at the threads.
Bugs are everywhere, nobody works perfect... ;)
Every scope on the market were launched with a basic functionality or, better, you can work with every scope regardless of their bugs.
They got, when, annoying ones or ones who are hard to find, but all got one thing in common:
You can work with them.
-
The SDS2K+ just works also.
They got, when, annoying ones or ones who are hard to find, but all got one thing in common:
You can work with them.
And you can use a hammer to drive in a nail as well. The recent discussion about the history buffers dissapearing is another fine example which shows Siglent isn't thinking things through at all. I can tell you the R&S scopes keep the history buffers when using the cursors (which are a great tool to compare waveforms). Heck, I can even start & stop the scope and change the time base. For as long as there is no new trigger event the history buffer stays intact. IOW: it is only erased when there is a good reason to do so.
-
The SDS2K+ just works also.
They got, when, annoying ones or ones who are hard to find, but all got one thing in common:
You can work with them.
And you can use a hammer to drive in a nail as well. The recent discussion about the history buffers dissapearing is another fine example which shows Siglent isn't thinking things through at all. I can tell you the R&S scopes keep the history buffers when using the cursors (which are a great tool to compare waveforms). Heck, I can even start & stop the scope and change the time base. For as long as there is no new trigger event the history buffer stays intact. IOW: it is only erased when there is a good reason to do so.
Where on earth you found that information SDS2000X+ nukes history if you move cursors ??
Also what are the good reasons. Would you be so kind and tell us when RTM3000 nukes history buffers?
Does it nuke it when you change timebase, vertical position and attenuation and enable/disable channels?
-
The SDS2K+ just works also.
They got, when, annoying ones or ones who are hard to find, but all got one thing in common:
You can work with them.
And you can use a hammer to drive in a nail as well. The recent discussion about the history buffers dissapearing is another fine example which shows Siglent isn't thinking things through at all. I can tell you the R&S scopes keep the history buffers when using the cursors (which are a great tool to compare waveforms). Heck, I can even start & stop the scope and change the time base. For as long as there is no new trigger event the history buffer stays intact. IOW: it is only erased when there is a good reason to do so.
Where on earth you found that information SDS2000X+ nukes history if you move cursors ??
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg3390482/#msg3390482 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg3390482/#msg3390482)
Also what are the good reasons. Would you be so kind and tell us when RTM3000 nukes history buffers?
Does it nuke it when you change timebase, vertical position and attenuation and enable/disable channels?
Not until there is another trigger event.
-
Also what are the good reasons. Would you be so kind and tell us when RTM3000 nukes history buffers?
Does it nuke it when you change timebase, vertical position and attenuation and enable/disable channels?
Not until there is another trigger event.
Really? Well, that's when the Siglent nukes the history buffers as well. It won't do anything to the buffers when the scope is stopped, and if you make a timebase, volts/div, voltage offset, or trigger location change while it's waiting for a new trigger event, it won't nuke the history then either. It seems to be when a new acquisition happens that it nukes the history.
Same for when you're playing with the cursors and such -- even when it's waiting for a trigger event, it won't do anything to the history buffers until a new trigger event takes place.
Thanks for incentivizing me to go look -- it never occurred to me to check this.
Honestly, I'm very surprised that the R&S will nuke the history buffer under any circumstances save for when you explicitly tell it to.
What does the R&S do to the history when you manipulate the volts/div, timebase, or offsets while it's actively doing captures? Does it nuke the history buffer upon the first new trigger event it sees the way the Siglent will? If it does, then there's scant difference between the R&S and the Siglent in this respect, save perhaps for cursor manipulation (which shouldn't do anything to the history buffer during normal acquisition under any circumstances).
-
Am I the only one who sees tons of bugs reported by R&S buyers ?
Or maybe nobody sees them because they are drowned in tons of posts that talk about the poor responsiveness of R&S to solve them ?
Or.... does ntcnico have special glasses that filter out both bad comments about R&S AND good ones for Siglent ?
-
Also what are the good reasons. Would you be so kind and tell us when RTM3000 nukes history buffers?
Does it nuke it when you change timebase, vertical position and attenuation and enable/disable channels?
Not until there is another trigger event.
Really? Well, that's when the Siglent nukes the history buffers as well. It won't do anything to the buffers when the scope is stopped, and if you make a timebase, volts/div, voltage offset, or trigger location change while it's waiting for a new trigger event, it won't nuke the history then either. It seems to be when a new acquisition happens that it nukes the history.
Same for when you're playing with the cursors and such -- even when it's waiting for a trigger event, it won't do anything to the history buffers until a new trigger event takes place.
Thanks for incentivizing me to go look -- it never occurred to me to check this.
Honestly, I'm very surprised that the R&S will nuke the history buffer under any circumstances save for when you explicitly tell it to.
What does the R&S do to the history when you manipulate the volts/div, timebase, or offsets while it's actively doing captures? Does it nuke the history buffer upon the first new trigger event it sees the way the Siglent will?
Yes. The rule is that you have data with the same acquisition parameters in the segmented recording / history buffer (in the end history buffer is exactly the same as automatic circular segmented recording). So if there is an acquisition coming in with different acquisition parameters (timebase, v/div, offset, sample mode) the buffer will need to be cleared. BTW: the RTM3004 I have here will show you that there are records in the segmented recording / history buffer as soon as you change the parameters as a warning.
-
Yes. The rule is that you have data with the same acquisition parameters in the segmented recording / history buffer (in the end history buffer is exactly the same as automatic circular segmented recording). So if there is an acquisition coming in with different acquisition parameters (timebase, v/div, offset, sample mode) the buffer will need to be cleared. BTW: the RTM3004 I have here will show you that there are records in the segmented recording / history buffer as soon as you change the parameters as a warning.
That being the case, then, I have to presume that if the scope is actively triggering when you change the parameters, it will clear the history buffer essentially as soon as the next trigger event arrives, which could be a very small amount of time after you move the controls. And, of course, if the trigger events are frequent enough, it would end up clearing the history buffer multiple times as you move the controls. This is exactly what happens on the Siglent. If the R&S behaves that way (and it sounds like it does), then it and the Siglent behave identically in this regard.
I expect, however, that the R&S does not regard movement of the cursors, or enabling or disabling the cursors, to be an event that requires clearing the history. Can you check it to see if R&S does it correctly? Also, it would be interesting to know if it clears the history if you press one of the trigger mode buttons while it's actively doing acquisitions, particularly when the mode button you press matches the mode you're already in. On the Siglent, it will clear the history under those circumstances.
This also raises a question about the UI responsiveness on the R&S: when you move the controls while the scope is actively acquiring while trigger events are coming in frequently (say, for instance, you have a 1 KHz sine wave that you're edge triggering on), how smooth is it, and does moving the controls interfere with the rate at which captures are occurring? The Siglent isn't the smoothest thing in the world here: the act of restarting acquisition and, perhaps, of clearing the history as well, takes some overhead that, when combined with the fact that the scope is attempting to interleave acquisition restarts with processing movement of the controls, results in visible lag and stuttering. How well does the R&S do in this respect?
My view is that Siglent should prioritize UI handling in this instance, and not restart acquisition until something like 100ms after control movement stops. This would allow them to dedicate the scope's full CPU capability to handling the UI and would thus (absent some horrible implementation) make it buttery smooth.
-
Yes. The rule is that you have data with the same acquisition parameters in the segmented recording / history buffer (in the end history buffer is exactly the same as automatic circular segmented recording). So if there is an acquisition coming in with different acquisition parameters (timebase, v/div, offset, sample mode) the buffer will need to be cleared. BTW: the RTM3004 I have here will show you that there are records in the segmented recording / history buffer as soon as you change the parameters as a warning.
That being the case, then, I have to presume that if the scope is actively triggering when you change the parameters, it will clear the history buffer essentially as soon as the next trigger event arrives, which could be a very small amount of time after you move the controls. And, of course, if the trigger events are frequent enough, it would end up clearing the history buffer multiple times as you move the controls. This is exactly what happens on the Siglent. If the R&S behaves that way (and it sounds like it does), then it and the Siglent behave identically in this regard.
I expect, however, that the R&S does not regard movement of the cursors, or enabling or disabling the cursors, to be an event that requires clearing the history. Can you check it to see if R&S does it correctly? Also, it would be interesting to know if it clears the history if you press one of the trigger mode buttons while it's actively doing acquisitions, particularly when the mode button you press matches the mode you're already in.
On the RTM3004 moving the cursors doesn't restart segmented recording/history mode. The same for changing the trigger parameters; I can change the level, edge and coupling without the buffer being emptied. Changing the horizontal position does empty the buffer because it is an acquisition parameter. Clearing the buffers is not a time consuming operation. All that needs to be done is setting the counter to zero. UI wise the RTM3004 is not the fastest one around (especially the pushbuttons on the front panel) but the touchscreen allows to access everything with a few taps.
-
Also what are the good reasons. Would you be so kind and tell us when RTM3000 nukes history buffers?
Does it nuke it when you change timebase, vertical position and attenuation and enable/disable channels?
Not until there is another trigger event.
Really? Well, that's when the Siglent nukes the history buffers as well. It won't do anything to the buffers when the scope is stopped, and if you make a timebase, volts/div, voltage offset, or trigger location change while it's waiting for a new trigger event, it won't nuke the history then either. It seems to be when a new acquisition happens that it nukes the history.
Same for when you're playing with the cursors and such -- even when it's waiting for a trigger event, it won't do anything to the history buffers until a new trigger event takes place.
Thanks for incentivizing me to go look -- it never occurred to me to check this.
Honestly, I'm very surprised that the R&S will nuke the history buffer under any circumstances save for when you explicitly tell it to.
What does the R&S do to the history when you manipulate the volts/div, timebase, or offsets while it's actively doing captures? Does it nuke the history buffer upon the first new trigger event it sees the way the Siglent will? If it does, then there's scant difference between the R&S and the Siglent in this respect, save perhaps for cursor manipulation (which shouldn't do anything to the history buffer during normal acquisition under any circumstances).
Apart from cursors anomaly, Siglent handles it same as R&S, LeCroy, Picoscope and any other scope that has history buffres. It is nonsensical to gather random data.
You always gather data belonging to same measurement setup, so only data changes.... So it is directly comparable.
What you suggest is pretty much useless, and a would serve to decrease intelligence and usability of instrument by introducing additional manual steps to ensure validity of data.
Also it introduces human error into system (by not resetting data you would yield data that might have invalid segments).
Current way is there to ensure integrity of data in deterministic way.
This is not human rights or freedom of choice issue. It's math.
-
Native 10 bit ADC are a point, even today none got it for this price (RTB2K).
But do I really need it ?
Signal to noise ratio is a killer feature of Siglents (so I'm told) but somehow it's worthless in anything else?
-
Native 10 bit ADC are a point, even today none got it for this price (RTB2K).
But do I really need it ?
Signal to noise ratio is a killer feature of Siglents (so I'm told) but somehow it's worthless in anything else?
I have no idea what this sentence means.
But since you mentioned it, bad signal to noise ratio seems to be biggest problem of your posts...
-
:-DD
-
Apart from cursors anomaly, Siglent handles it same as R&S, LeCroy, Picoscope and any other scope that has history buffres. It is nonsensical to gather random data.
You always gather data belonging to same measurement setup, so only data changes.... So it is directly comparable.
Apparently not quite. The Siglent will clear the history upon changes to at least some of the trigger parameters (most notably, the level). It sounds like the R&S won't.
What you suggest is pretty much useless, and a would serve to decrease intelligence and usability of instrument by introducing additional manual steps to ensure validity of data.
Also it introduces human error into system (by not resetting data you would yield data that might have invalid segments).
What's an "invalid segment"? The scope captured data under the conditions it was told to capture it. Changing the conditions after the fact doesn't invalidate the prior captures, it only changes how new captures need to be interpreted, and even that might not be the case under some circumstances.
Despite that, I have no problem with invalidating the history buffer when a change occurs that really would cause new captures to differ materially from prior ones. But Siglent is currently much more aggressive about clearing the history buffer than that.
-
I have no idea what this sentence means.
Weird. I'm sure you're also active in that other thread where everybody is arguing over ENOBs.
It's a simple question? Why is 8 enough and 10 too much? Why so arbitrary?
-
Apart from cursors anomaly, Siglent handles it same as R&S, LeCroy, Picoscope and any other scope that has history buffres. It is nonsensical to gather random data.
You always gather data belonging to same measurement setup, so only data changes.... So it is directly comparable.
Apparently not quite. The Siglent will clear the history upon changes to at least some of the trigger parameters (most notably, the level). It sounds like the R&S won't.
What you suggest is pretty much useless, and a would serve to decrease intelligence and usability of instrument by introducing additional manual steps to ensure validity of data.
Also it introduces human error into system (by not resetting data you would yield data that might have invalid segments).
What's an "invalid segment"? The scope captured data under the conditions it was told to capture it. Changing the conditions after the fact doesn't invalidate the prior captures, it only changes how new captures need to be interpreted, and even that might not be the case under some circumstances.
Despite that, I have no problem with invalidating the history buffer when a change occurs that really would cause new captures to differ materially from prior ones. But Siglent is currently much more aggressive about clearing the history buffer than that.
I explained this already, this is third and last time. Changing trigger conditions absolutely changes everything in comparison with previous captures taken at different settings.
Invalid segments, are, from standpoint of data science, leftovers from previous series of captures, taken with different experimental setup, that don't belong to current data series (experiment). Period.
What might be an interesting addition is for the scope to ask before nuking, would you like to save current history to storage before proceeding, so you could automate process: grab set of data, save whole set, grab another one with different settings etc. etc. People ask me why I trumpet about Picoscopes all the time... Well Picoscope can do that for instance.
Let me explain. This is not debate club where you hone art of negotiation/persuasion so you get your way and get to win argument on argumentation only not the facts, where most important is who is the loudest one with most persuasive style. If you want to practice that, I would suggest to find a forum for legal professionals, so you can argue with lawyers in that manner.. That's the crowd that enjoys that..
Here it's math and engineering, place where numbers meet practicality in order to achieve cheapest results that are in spec.
Several members here already explained you how it must work to be right. It is not my invention, nor theirs, but is a fruit of several thousand engineer years in development from the likes of LeCroy etc.
It is what whole community that has been using these scopes has agreed upon to be most logical way of doing it...
If you plan to live in your parallel universe where you deny all that, be my guest...
-
I have no idea what this sentence means.
Weird. I'm sure you're also active in that other thread where everybody is arguing over ENOBs.
It's a simple question? Why is 8 enough and 10 too much? Why so arbitrary?
I was active there, for sure, but really didn't get what you meant.
Thank you for explaining.
8 bit is enough if there is high sensitivity low noise front end so you can squeeze maximum from it.
10 bit is better, always, but not necessarily more useful..
Good low noise 8bitter will be good enough for most of the jobs, and 10 bit scope might not be better enough to justify price difference.
So question would be more like this: what is more useful to you, a SDS2000X+ and a good multimeter and a Micsig STO1104C, or just one 10bit scope. With what set of equipment you will be able to measure more and be more productive?
Once equipment is GOOD ENOUGH, it is always about the price and what additional capabilities you can get for the price difference....
-
I explained this already, this is third and last time. Changing trigger conditions absolutely changes everything in comparison with previous captures taken at different settings.
Invalid segments, are, from standpoint of data science, leftovers from previous series of captures, taken with different experimental setup, that don't belong to current data series (experiment). Period.
This is all well and good when you're talking about using the scope as a measurement instrument for characterization work and other things where the kind of data consistency you're talking about is paramount.
What makes you believe that the usefulness of the history mechanism is in any way limited to that?
Just accidentally bumping the controls while the scope is performing acquisitions is reason enough to want the scope to retain the prior history at least long enough to allow you to preserve it.
Let's say I change the voltage offset of my i2c data channel while the scope is acquiring frames, and I'm chasing down a problem, such as one involving glitches in the analog control signal as they relate to messages going over the i2c bus. I'm not going to care at all that the capture parameters have slightly changed, because for what I'm doing in that case, that change is irrelevant. What matters to me in that case is the i2c data and timing relative to the control signal, and the characteristics of the control signal (which I didn't touch). But the history might be very relevant. Are you going to claim here that this use case is invalid?
I'm not claiming that Siglent doesn't have reason to clear the history when they do. I'm saying that Siglent's choice is overly-aggressive for some use cases, and that a different choice might be more appropriate for a general-purpose instrument. In any case, Siglent has provided a nice, neat way to clear the history at will: hit the trigger acquisition mode button that corresponds to the one you're already using. If absolute consistency across all history frames is that important to you, then you can hit the button to ensure it. Destroying data gathered on behalf of the user is generally regarded as a bad idea in the computing world unless absolutely necessary, and I fail to see how that principle doesn't apply here.
What might be an interesting addition is for the scope to ask before nuking, would you like to save current history to storage before proceeding, so you could automate process: grab set of data, save whole set, grab another one with different settings etc. etc. People ask me why I trumpet about Picoscopes all the time... Well Picoscope can do that for instance.
That would indeed be very useful, and would basically take care of the problem.
Here it's math and engineering, place where numbers meet practicality in order to achieve cheapest results that are in spec.
Several members here already explained you how it must work to be right. It is not my invention, nor theirs, but is a fruit of several thousand engineer years in development from the likes of LeCroy etc.
It is what whole community that has been using these scopes has agreed upon to be most logical way of doing it...
I don't recall seeing much discussion, prior to now, about the conditions under which the history buffer should be cleared. Maybe I haven't looked hard enough. As regards other things like how the acquisition mechanism works, you've got a good point here.
That said, the fact that different scopes have different implementations of the very same thing is reason enough to conclude that there are multiple valid approaches to these things. As (I presume) an engineer, you should certainly know that why some approach is preferred is as important as that it's preferred.
-
Well you already have a history buffer of sorts if you care to use it and it's called Zoom mode where the whole memory is displayed on the screen and in pre and post trigger states, also user searchable where one can also transfer search parameters directly to the trigger.
2N3055 is quite correct the History works as it should however for those new to these scopes there are many other features that can serve the users needs.
Get to know them.
-
Well you already have a history buffer of sorts if you care to use it and it's called Zoom mode where the whole memory is displayed on the screen and in pre and post trigger states, also user searchable where one can also transfer search parameters directly to the trigger.
That's not the same thing as the history, of course. The history and the current capture (which you can use zoom mode with and all that) are complementary, each useful in its own right and together quite powerful.
2N3055 is quite correct the History works as it should
As regards changes to the things that control the acquisition parameters, I'm certainly willing to concede that. It might not be reasonably feasible to change that. But I'm not willing to concede that with respect to things like operation of the cursors, or zoom mode, or anything that doesn't affect the acquisition parameters. Put another way, if it doesn't change how the scope would interpret the captured data, then it shouldn't clear the history (an exception might actually be hitting the currently active trigger mode button, since one could argue that there should be a way to force the history to be cleared on demand).
however for those new to these scopes there are many other features that can serve the users needs.
Get to know them.
Completely agree. There's lots of good stuff in these scopes that make them very capable.
-
Changing trigger conditions absolutely changes everything in comparison with previous captures taken at different settings.
That is highly debatable. Trigger settings aren't acquisition settings. Just conditions on how & when to start an acquisition. Contrary to the R&S RTM3004 my GW Instek GDS-2204E scope restarts the segmented recording when the trigger OR acquisition settings are changed though.
-
Trigger settings aren't acquisition settings.
Back to school!!!
-
Trigger settings aren't acquisition settings.
Back to school!!!
No. Think about it for a bit longer. A trigger does not change the shape of the signal you record (or put differently: how the data in the acquisition memory is to be interpreted) in any way. Imagine you have recorded 30 measurements and you find out that the trigger level is not ideal for some test cases. Do you want to repeat those 30 measurements or have the option to adjust the trigger level a bit? Maybe it isn't even possible to do all of the measurements using the same trigger settings. More flexibility is always better; as a user you can always force the oscilloscope to restart the segmented recording.
-
Trigger settings aren't acquisition settings. Just conditions on how & when to start an acquisition.
Sorry, Nico, but you're the one who needs to think a bit longer on precisely your own words.
An acquisition condition that determines the how&when IS an acquisition setting.
-
Trigger settings aren't acquisition settings. Just conditions on how & when to start an acquisition.
Sorry, Nico, but you're the one who needs to think a bit longer on precisely your own words.
An acquisition condition that determines the how&when IS an acquisition setting.
No. Acquisition setting is v/div, time/div, vertical position and horizontal position. Trigger only determines WHEN the data is acquired. Perhaps I should have removed the word how because the trigger does not really affect 'how' but it should be clear from the context anyway. Let's not get into semantics; that serves very little purpose. Leave that to language purists and lawyers.
-
Trigger settings aren't acquisition settings. Just conditions on how & when to start an acquisition.
Sorry, Nico, but you're the one who needs to think a bit longer on precisely your own words.
An acquisition condition that determines the how&when IS an acquisition setting.
But what matters here is whether or not the change in question changes how the data that's being recorded is going to be interpreted by the scope. Changing the trigger conditions doesn't change that. It doesn't alter the ADC settings. It doesn't alter the preamp or amplifier settings. It doesn't alter the sample rate. It changes nothing except when an acquisition is performed, not how the acquisition is performed, nor does it change what is recorded (the time of the trigger event itself is recorded irrespective of the trigger settings themselves, because the scope cannot know in advance when a trigger event will happen).
So Nico is exactly right here. If you nevertheless insist that changing the trigger settings somehow alters how the resultant data will be interpreted by the scope once it has been recorded, then by all means, please tell us how. Because I don't see it, and neither, apparently, does Nico.
-
Trigger settings aren't acquisition settings. Just conditions on how & when to start an acquisition.
Sorry, Nico, but you're the one who needs to think a bit longer on precisely your own words.
An acquisition condition that determines the how&when IS an acquisition setting.
No. Acquisition setting is v/div, time/div, vertical position and horizontal position. Trigger only determines WHEN the data is acquired. Perhaps I should have removed the word how because the trigger does not really affect 'how' but it should be clear from the context anyway. Let's not get into semantics; that serves very little purpose. Leave that to language purists and lawyers.
I apologize for being mistaken. I can see now how these two captures are actually exactly the same, they differ only in trigger setting and can be directly compared... |O
(https://www.eevblog.com/forum/testgear/4k-oscilloscope/?action=dlattach;attach=1141454;image)
and
(https://www.eevblog.com/forum/testgear/4k-oscilloscope/?action=dlattach;attach=1141458;image)
Get a grip, will ya...
-
I apologize for being mistaken. I can see now how these two captures are actually exactly the same, they differ only in trigger setting and can be directly compared...
Think of it like this: those captures could both have been caught in exactly that same way with a single appropriate trigger setting, e.g. "rising edge > 800mV in size". It would be exactly the same captures, both taken without any alterations between them. Why would they be "directly comparable" under those conditions but not "directly comparable" when one is taken under different trigger conditions than the other?
Now, the user might regard one case as being directly comparable while the other isn't, but how is the scope supposed to know? It can't. It doesn't know what the user considers to be important in the captures. Its job isn't to divine what's important to the user. Its job is to capture the data it's told to capture and to present it on demand, and that's all.
Consider, for instance, the case where you're actually interested in setting a trigger condition that is an "or" of two distinct conditions, but you don't have an "or" type trigger that would allow you to simultaneously specify both conditions. So you set up the scope to single-shot capture under the first condition, and then set up the scope to single-shot capture under the second condition, back to back. Because your intention is to compare both captures to each other, it should be clear that what you want in that case is for the scope to preserve both captures so that you can go back and forth between them. But the scope won't accommodate that, because it clears the first capture as a result of you changing the trigger conditions and hitting the "single" button again (both will clear the history buffer). Who's right here, the scope or the user? I argue that the user is correct. It's his use case, not the scope's.
-
I apologize for being mistaken. I can see now how these two captures are actually exactly the same, they differ only in trigger setting and can be directly compared...
Think of it like this: those captures could both have been caught in exactly that same way with a single appropriate trigger setting, e.g. "rising edge > 800mV in size". It would be exactly the same captures, both taken without any alterations between them. Why would they be "directly comparable" under those conditions but not "directly comparable" when one is taken under different trigger conditions than the other?
Now, the user might regard one case as being directly comparable while the other isn't, but how is the scope supposed to know? It can't. It doesn't know what the user considers to be important in the captures. Its job isn't to divine what's important to the user. Its job is to capture the data it's told to capture and to present it on demand, and that's all.
Exactly. Safe is to presume they belong to different data set. Period..
-
Exactly. Safe is to presume they belong to different data set. Period..
The user is ultimately responsible for interpreting what the scope gives him. It's the user's use case, not the scope's. The scope's job is to just capture what it's told. What makes it "safer" to throw away the prior captures than to preserve them? Data that is thrown away can't be recovered. Data that isn't thrown away can be disregarded later, or not, at the user's discretion. So how exactly is it "safer" to throw away the data?
And even if it is "safer" to throw away the data, what business is it of the scope to decide for the user what data is important and what data isn't? It's not the scope's job to save the user from himself.
-
I was looking at this from a different angle, you could line up a number of 8 bit high traces on a 4K Screen. Each of them with a full range of operation. If one pixel traces are too thin you could easily make the traces 2-4 pixels thick. That is vertical, Horizontal would just mean far more of the sample can be displayed on screen at one time.
The other big advantage is that you can or could plant all your in use instruments on one screen and still have room for a spread sheet, text editor or whatever.
I must have completely mis interpreted the title. I literally thought the question was about a scope with a 4K screen. If such a scope existed it would be fantastic as I'm sitting in front of a 4k screen right now. This makes me wonder if the Pico Scopes or other PC based scopes can actually make use of a 4K screen.
They work on 4K screen. But it is useful only for having many small viewports. Unless you have 16 Bit Pico, signal doesn't get any use of all the (unnecessarily) high resolution. For an 8 bit scope, your whole vertical resolution is 250 pixels..... I find that 1920*1200 on 24" screen yields pixels that are not perceptible at normal working distance. I would think that it make sense for 32" screens to go for 4K...
Early this year I purchased a 4K screen and to be perfectly honest it is eye opening after years of using laptop screen. One thing I would want to work to is an on screen instrument cluster. I really see a lot of potential in software based instruments or at the very least GUIs for hardware running on PC's. The sofware might not be there yet but that is just a time thing.
-
Exactly. Safe is to presume they belong to different data set. Period..
The user is ultimately responsible for interpreting what the scope gives him. It's the user's use case, not the scope's. The scope's job is to just capture what it's told.
It's not the scope's job to save the user from himself.
Exactly. An oscilloscope is not a toy for toddlers. At some point it can be expected the user knows what he/she is doing. A similar protection would be to force peak-detect on if the sampling rate drops below the maximum to prevent producing aliased waveforms but I know no DSO which does that.
-
Trigger settings aren't acquisition settings. Just conditions on how & when to start an acquisition.
Sorry, Nico, but you're the one who needs to think a bit longer on precisely your own words.
An acquisition condition that determines the how&when IS an acquisition setting.
No. Acquisition setting is v/div, time/div, vertical position and horizontal position. Trigger only determines WHEN the data is acquired. Perhaps I should have removed the word how because the trigger does not really affect 'how' but it should be clear from the context anyway. Let's not get into semantics; that serves very little purpose. Leave that to language purists and lawyers.
I apologize for being mistaken. I can see now how these two captures are actually exactly the same, they differ only in trigger setting and can be directly compared... |O
Get a grip, will ya...
I don't get your rigidity. I can think of hundreds of situations where it could be useful to compare signals with different trigger settings. Overlaying results with different settings/signal inputs for example and flip through them to see the effects.
Or lets take a simple example: a claw hammer. Because it is called a hammer you'll likely insist it can only be used as a hammer. Meanwhile the claw -which doesn't cost anything extra- adds a lot of different uses like pulling out nails and light demolition work making it very suitable for construction work.
-
I come in to see discussion about scopes at $4k level, but...
Can the battle be moved to where it should be?
-
This thread is not about "$4k" scopes, it's about "4k" scopes!
@wizard69 has just made a post about it in his last msg.
-
If you would have 4k USD budget for a scope what you would buy and why? It must be a new unused one.
4 ch needed.
Starter post..
-
Starter post..
I was kidding but you got me there... :)
(BTW the 1st time I saw the thread title, i thought on screen size.)