Siglent's new product- MSO/SDS2000 Series

[marmad]

New FW 2.0  keep and map every sigle true raw ADC samples (for display). New SPO engine do not drop out data for speed waveform update speed.  Wfm/s reduced speed is also clearly visible in new wfm/s table where many of t/div speeds have much lower wfm/s speed than FW1.0 versions.  But lso then fast t/div speeds wfm/s speed have big improvement, including also max speed what exist now with 5ns/div speed. Also fastest is now one channel in use and more channels, more slow. (naturally)
Also now scope stopped keep display, even if zoom in/out using time/div. And, it do not destroy true raw sample points, including sinx/x (In Siglent waveform draw goes all the way through the real points)

Yes, I think it's a better solution - and since the intensity-grading is nicer on the Siglent than the competition (Rigol, Instek, Agilent, etc), it's good that the focus is towards that rather than the wfrm/s at slower timebases.

[rf-loop]

New FW 2.0  keep and map every sigle true raw ADC samples (for display). New SPO engine do not drop out data for speed waveform update speed.  Wfm/s reduced speed is also clearly visible in new wfm/s table where many of t/div speeds have much lower wfm/s speed than FW1.0 versions.  But lso then fast t/div speeds wfm/s speed have big improvement, including also max speed what exist now with 5ns/div speed. Also fastest is now one channel in use and more channels, more slow. (naturally)
Also now scope stopped keep display, even if zoom in/out using time/div. And, it do not destroy true raw sample points, including sinx/x (In Siglent waveform draw goes all the way through the real points)

Yes, I think it's a better solution - and since the intensity-grading is nicer on the Siglent than the competition (Rigol, Instek, Agilent, etc), it's good that the focus is towards that rather than the wfrm/s at slower timebases.

And also if need more fast there is available new seqmented acquisition what today have up to 500kwfm/s speed.
But I have not yet made enough tests for speed table.
(previously it was "history")

Today there ia also automatic history what always store last captured waveforms (up to 80000 waveforms) with current normal wfm/s speed to history FIFO and what can look after scope is stopped.

If turn "sequence" function on, this history is not available. Captured segments (waveforms)  can look using this history function viewer. This very fast segmented capture is rejected to max 1024 waveforms. When segmented acquire is continuously on and working, display wfm/s update speed is highly reduced but not blank.

I hope they later develop more intelligence for analyze normal always stored history memory or seqmented acquisition memory. Example I miss function where waveforms can display  as "playback" but during adjustable speed playback it also add every displayed to stack (loverlay display)  if user select it.

[nctnico]

But don't for a minute pretend the history function is new. The Yokogawa DL1740 from the early 00's I just bought already has a completely working history function!

[Performa01]

I have successfully updated to the new R2.0 beta firmware and generally, I’m very impressed by the changelog alone. Siglent seems to have addressed just about any issue/complaint ever raised in this thread.

On top of this I’m deeply impressed by the fact that Siglent has not just tried to find fixes/work-arounds, but decided to completely redesign the firmware in order to make the acquisition work as it should on a pro-level scope, even when they had to sacrifice a little waveform update speed om slower timebases. But then again, they got a higher maximum for the spec-sheet as a reward, which is well deserved in my book.

Even when not everything works as intended right now ( I didn’t have time to do a proper test so far), the way Siglent have handled this makes me feel very comfortable about my decision to buy the SDS 2304 about three months ago. For me, this was certainly the best advertising they could have done for this slightly prematurely launched scope, and it will make me look into their other products too in the future.

On a first impression, two questions have arisen pretty quickly:

1)   There is the claim of a 70MSa memory option (via option key). So this sounds like it will be a SW-option and the new FW-design makes so much more efficient use of the existing physical memory that this has now become possible. However, I could not find any additional entry in the options menu. So how are we supposed to get the additional sample depth?
2)   When looking at the ‘Acquire’ menu, I notice it has changed quite a bit. There are now two pages (I believe it was only one on R1.0) and includes the additional ‘Acquisition Mode’ tag. According to the online help, this allows turning HW-acceleration on or off. And sure enough, screen update rate at a timebase of e.g. 5ns/dev drops to just 27. Now there’s the question: what’s the use for being able to turn HW-acceleration off?

[nctnico]

I'm not sure they rewrote the entire firmware from scratch. What worries me is that they didn't get to the MSO part yet. IMHO an input signal should be handled by the software as an input signal so there shouldn't be a difference between analog and digital channels. The fact the MSO part isn't done yet makes me assume the digital channels are still some bolted-on feature.

Make sure to read my review thread and Marmad's review thread because there are many bugs and issues listed there. Many are not very obvious and easely overlooked in a quick review. I can't test the new firmware since I (fortunately) no longer own an SDS2000.

[tautech]

I have successfully updated to the new R2.0 beta firmware and generally, I’m very impressed by the changelog alone. Siglent seems to have addressed just about any issue/complaint ever raised in this thread.

On top of this I’m deeply impressed by the fact that Siglent has not just tried to find fixes/work-arounds, but decided to completely redesign the firmware in order to make the acquisition work as it should on a pro-level scope, even when they had to sacrifice a little waveform update speed om slower timebases. But then again, they got a higher maximum for the spec-sheet as a reward, which is well deserved in my book.

Even when not everything works as intended right now ( I didn’t have time to do a proper test so far), the way Siglent have handled this makes me feel very comfortable about my decision to buy the SDS 2304 about three months ago. For me, this was certainly the best advertising they could have done for this slightly prematurely launched scope, and it will make me look into their other products too in the future.

On a first impression, two questions have arisen pretty quickly:

1)   There is the claim of a 70MSa memory option (via option key). So this sounds like it will be a SW-option and the new FW-design makes so much more efficient use of the existing physical memory that this has now become possible. However, I could not find any additional entry in the options menu. So how are we supposed to get the additional sample depth?
2)   When looking at the ‘Acquire’ menu, I notice it has changed quite a bit. There are now two pages (I believe it was only one on R1.0) and includes the additional ‘Acquisition Mode’ tag. According to the online help, this allows turning HW-acceleration on or off. And sure enough, screen update rate at a timebase of e.g. 5ns/dev drops to just 27. Now there’s the question: what’s the use for being able to turn HW-acceleration off?

#1
As this FW is a beta version, the option management additional memory selection has yet to be added.
At this time no pricing has been announced for the additional memory option, yes I have checked this with Siglent.

I'll have to do some research about #2 for you. 

[Wuerstchenhund]

I'm not sure they rewrote the entire firmware from scratch.

My guess is that they couldn't fix the mess the old V1.x firmware was and so ported the firmware of their new X-Series scopes to the SDS2000. Which probably was the only way out, as the new firmware can hardly be any worse than the old one.

[Performa01]

@Tautech thanks for the offer to investigate. I have found one possible reason already: With HW-acceleration on, you can’t see the individual dots (in dot mode) anymore when in normal or peak detect mode. See my findings below…

For some reason I don’t care so much about all the additional bells and whistles of a modern DSO. I consider them (sometimes very) nice to have, but can’t get upset when not everything works as I’d like. Has probably to do with the fact that I have used analog scopes for decades and only switched to DSO once reasonable sample speed and memory depths became affordable.

So I can forgive bugs in the FW, as long as the basic functionality is solid and the darn thing doesn’t crash. In this regard I had little complaints even with the R1.0 FW. Yes, the logic channels were rather simplistic and buggy, and I really could not understand why the serial decoders would only work with the analog channels.
And then I also thought it was a shame there was no ETS (equivalent time sampling), considering the sample rate drops to 1GSa/s with both channels in a group in use and the bandwidth of the analog frontend, which easily allows signals >500MHz to make it through to the ADC.

Apart from that, the basic operation was quite pleasing. I want good triggering, low noise and high signal fidelity – all combined with a responsive user interface and decent screen appearance (no ugly fonts and loud colors like some cheap scopes have). The SDS2000 R1.0 did deliver on that. The trigger is about the best I’ve ever seen on any scope and the noise performance is pretty impressive. Frequency response is almost perfectly flat, dropping to just 1.3~2.2dB at 300MHz, depending on the vertical attenuator setting (except 2mV/div, where BW is limited to 20MHz) and all channels behave very similar, differences at 300MHz are pretty much within +/-0.5dB. Phase errors and jitter were also not an issue at all.

However, display mode had to be ‘Vectors’ and sin(x)/x reconstruction filtering had to be turned on at high frequencies in order to get a reasonably undistorted signal trace, which was a shame, as otherwise this scope works very well in dot mode without sin(x)/x, where the trace gets a nice analog like appearance and intensity grading is aided by the actual luminance variation caused by the densitiy of the dots. Generally, for frequencies >420MHz the trace started showing double contours, thus making this scope unusable for looking at signals far above its bandwidth. I didn’t consider this a problem, as most analog scopes wouldn’t even trigger at frequencies higher than 30% above their nominal bandwidth.

I have discovered a major improvement with R2.0 in this regard.

It is now possible to view frequencies >500MHz even when in dot mode and without sin(x)/x. In this mode, the signal gets only slightly distorted at frequencies above 300MHz. With sin(x)/x on, the signal remains almost perfect up to 530MHz and starts showing double contours above. This is of course with one channel only and 2GSa/s sample rate. At 1GSa/s, the screen trace is usable up to some 340MHz with sin(x)/x on, and only 200MHz at best without.

Doing these tests, I also discovered an unexpected effect of the ‘Fast’ acquisition mode:  not only is it much faster (as the name suggests), but also outputs it a lot more dots on the screen. Probably a bunch of acquisitions is accumulated and output together, which makes a nice line because of the continous phase-shift in each individual acquisition. So with the HW-acceleration in FW R2.0, there is really no need for using vector mode, even at high frequencies. You always see a nice solid trace. This only works in ‘Normal’ and ‘Peak Detect’ acquisition modes though. Surprisingly, on ‘Average’ and ‘Eres’ there are only the true sampled dots visible.

After short investigation the reason for this has been revealed: there is no HW-acceleration available for these modes. Hence no additional dots, but also the waveform update rate drops down to about 12 per second. Don’t consider this to be a problem, since I very much doubt someone would deliberately select one of these averaging modes when high waveform update rates were important for the job…

[nctnico]

Interestinglingy I measured bandwidths of over 300MHz on my 200MHz SDS2204! I'm wondering if there is any bandwidth limiting going on or they didn't include any on early production runs. I do agree the triggering on the SDS2000 is superb. However unlike you I bought mine especially for the decoding and digital channels.

[tautech]

So I can forgive bugs in the FW, as long as the basic functionality is solid and the darn thing doesn’t crash. In this regard I had little complaints even with the R1.0 FW. Yes, the logic channels were rather simplistic and buggy, and I really could not understand why the serial decoders would only work with the analog channels.
And then I also thought it was a shame there was no ETS (equivalent time sampling), considering the sample rate drops to 1GSa/s with both channels in a group in use and the bandwidth of the analog frontend, which easily allows signals >500MHz to make it through to the ADC.

Apart from that, the basic operation was quite pleasing. I want good triggering, low noise and high signal fidelity – all combined with a responsive user interface and decent screen appearance (no ugly fonts and loud colors like some cheap scopes have). The SDS2000 R1.0 did deliver on that.............

Yes, your detailed reply pretty much mirrors my customers feedback too.
We all look forward to R2 FW being finished and the option FW tweaked for what will then be a pretty good package.
Thanks for your feedback.
I suggest you enter the Siglent activity that will put your experiences and findings in front of those at Siglent and maybe influence new FW tweaks:
http://www.siglentamerica.com/qyxwxx.aspx?id=1403&sid=216

[rf-loop]

Doing these tests, I also discovered an unexpected effect of the ‘Fast’ acquisition mode:  not only is it much faster (as the name suggests), but also outputs it a lot more dots on the screen. Probably a bunch of acquisitions is accumulated and output together, which makes a nice line because of the continous phase-shift in each individual acquisition.

(Simplified)
In slow mode it do one acquisition and push it to display and then repeat. Just like old "acquire-display-acquire-display..."  DSO do.
Also in this mode sampled points related to trigger time position are "random" as long as signal and aquire engine is not in synch. It may happend with some signal frequencies but still some time jittering mostly shake it.  If user switch on after processing vectors drav between sample points or if user select instead of straight line Sin(x)/x it drav it throughg raw ADC data points. (also of course in stop mode user can zoom in and out using timebase and can turn on and off these straight line or sinc line drawing.

In fast mode it do...   A: acquire..wait trig..adjust..some processing...repeat A until next display refres cycle. Do it and continue A.
In gthis mode it map to display all acquisitions (overlay each acquisition). There can be lot of acquisitions overlayed for one diplay refredh cycle... hudreds and even more.

If clock is 2GSa/s there is 500ps between samples.  It can think last point is "zero" then time goes... to 500 and here is next sample. If trigger occurs in position 300ps it need "quess" where is signal at this point. There need interpolate best fit line between samples... now "know" where this imagined (interpolated) line cross trigger position and do fine adjust.  Because this adjustment it set sample points to "random" positions.  If it trigger to closest true sample point what is crossed over trig position of course it leads very poor trigger jitter (1 sample period jitter)  So when we look sequential acquisitions it looks like true sample points "walk" or "run" and if we are in fast mode there is so many acquisitions overlayed (stacked) it looks like they are in random positions.

[Wuerstchenhund]

SDS2000 2.0 firmware (V100R02B01D01Pxx) is a completely new software architecture update from 1.0 firmware
(V100R01B01D01Pxx). So we need to redo the MSO, Decode and power analysis.

@Siglent,

Am I right assuming the sample memory upgrade to 70Mpts will be another paid-for option? How about making it a free upgrade for all SDS2000 that have been sold before you come up with the final mature v2 firmware? I'd say you owe the people that paid a lot of money for a buggy scope some kind of compensation for the long wait (which will continue, as relevant parts of the new firmware aren't ready yet)?

[rf-loop]

SDS2000 2.0 firmware (V100R02B01D01Pxx) is a completely new software architecture update from 1.0 firmware
(V100R01B01D01Pxx). So we need to redo the MSO, Decode and power analysis.

@Siglent,

Am I right assuming the sample memory upgrade to 70Mpts will be another paid-for option? How about making it a free upgrade for all SDS2000 that have been sold before you come up with the final mature v2 firmware? I'd say you owe the people that paid a lot of money for a buggy scope some kind of compensation for the long wait (which will continue, as relevant parts of the new firmware aren't ready yet)?

+1

[Performa01]

Interestinglingy I measured bandwidths of over 300MHz on my 200MHz SDS2204! I'm wondering if there is any bandwidth limiting going on or they didn't include any on early production runs. I do agree the triggering on the SDS2000 is superb. However unlike you I bought mine especially for the decoding and digital channels.

Yes, I’ve already wondered about that before I ordered my scope. When the 200MHz version of the scope goes up to >300MHz, it was very unlikely that the 300MHz version would do any better – and this assumption proved to be true when I measured the bandwidth of my scope soon after I got it.
Now I wonder if that’s the same for all version of the SDS2000? Probably not. Maybe Siglent have not planned to release a 300MHz version initially and the HW design didn’t include a switchable input filter for that. What was your HW-version? Mine is 5-3. My guess would be, the BW limit would be there on the current scopes.

Of course I hope for a decent implementation of the digital channels once R2.0 is finished. In R1.0 they did work, but with bugs and limitations – just look at the changelog for R2.0, where Siglent have listed all the issues ever found by contributors to this thread. And they definitely state that there will be serial decoding on the digital channels.

With the current beta R2.0, the digital channels are totally broken. When switched on, there are 16 channels displayed (but SDS2000 only supports eight) and the screen becomes a total mess when additional buttons are pressed in an attempt to explore the digital channel menu.
I can live with that for a while, as this is my first private MSO and I do have a logic analyser. Eight digital channels are not enough for many situations anyway, but still nice to have them at hand for the minor stuff without hooking up an additional device and of course the fact that all traces appear on the same screen and direct correlations between analog and digital is made easy.

[nctnico]

IMHO 16 channels on an MSO is too much. If you need that much channels you are much better off with a logic analyser.

[Performa01]

Figures about the waveform update rate have already been posted by rf-loop, yet only in dots mode without sin(x)/x reconstruction. While dots is perfectly fine as default mode imho, the sin(x)/x interpolation is indispensable at higher frequencies and faster timebase settings respectively. Vector mode is only needed for the averaging modes at higher frequencies, and these are situations where I consider waveform update rates as fairly insignificant.

So what I wanted to know was the waveform update rates in dot mode with sin(x)/x reconstruction, and no such measurements have been published yet as far as I know. But when trying to set up a measurement for this, I soon noticed that it was difficult to get stable readings on the frequency counter. The problem became immediately clear when looking at the trigger output with another oscilloscope: it’s the dead time. Triggering doesn’t occur as a constant pulse train, but in separate bursts, and these get a bit irregular at slower timebases on top of that. See attached example for 1µs timebase setting and 16MHz input signal.
 
With modern (reciprocal) frequency counters, we tend to get the frequency within one burst packet rather than the average frequency over an entire second. So in order to get meaningful figures I had to set up my counter in totalising A by B mode, feeding channel B with a 1s gating signal in order to make sure to actually get the number of trigger pulses per second. Yes, an old fashioned standard counter with its gate time set to 1s would have done the same, but I don’t have one anymore and with the reciprocal counters you never can be sure about the gating time as it depends on both resolution and input frequency and it’s probably not easy to make it exactly one second for instance.

Knowing that previous measurements most likely didn’t give the true number of trigger events per second, I decided to also repeat the measurements for sin(x)/x turned off. I also noticed, that the result was dependant on the input frequency, but not by a huge amount and finally decided to use 16MHz for all measurements up to 1ms/div timebase. I did the measurements only with one memory depth of 14MSa, as this is the maximum for both channels in a group. I did not want to go to the effort to repeat all the measurements with various memory settings, just looking at the tables posted by rf-loop give you an idea what the differences are at slower timebases. So here it goes:

Generator: 16MHz Sinewave, 100mV rms.
SDS 2304: 50mV/div, 50Ohm, x1, peak detect, dots, sin(x)/x off/on, 14MSa Memory

Looking at the table, we can see that sin(x)/x doesn’t make any difference for timebase settings slower than 20ns/div. So thankfully the firmware seems smart enough to turn that interpolation off automatically when not needed. This is also the reason why the table doesn’t contain any values for timebase settings slower than 100ns/div.

So with sin(x)/x on, the sweet spot is still 50ns, where also the difference between one or two channels is almost nonexistent, with 70k waveforms per second for both channels.

[Performa01]

In fast mode it do...   A: acquire..wait trig..adjust..some processing...repeat A until next display refres cycle. Do it and continue A.
In gthis mode it map to display all acquisitions (overlay each acquisition). There can be lot of acquisitions overlayed for one diplay refredh cycle... hudreds and even more.

Thank you for the clarification. This is pretty much what I've expected.

[rf-loop]

Measuring wfm/s update rate there is two (or more) values. Burst value and average.

I have used HP53131  with enough gate time (over 2s and lower timebases more) and manual trigger level set. Other possible is use it in time gated pulse counting mode.

But of course 2s is not enough for very low time bases. I have used also second oscilloscope so that I can see what is going on with trig out for avoid mistakes, mesuring refres time gap and burst speed and when all mesurement give enough same result I have accepted result. It is very nice to use period trigger mode for follow trig out stream...  In my all tables wfm/s speeds are averages. Example 60kwfm/s speed (SDS1000X) there is burst value bit over 70kwfm/s and inside burst there may occur some even more fast peak values.

Careful tests need time with least triple check measurement.... so I have not get ready measurements with sinx/x and vectors. Also with some other settings. (window, mask test, etc)

Now on the table is SDS1000X most important things. Next also sequense (segment) speeds with all timebases and mem settings..  perhaps many things need wait long time.  Also there is coming one other brand oscilloscope "miracle" for inspect.

EditAdd:
There is also some mysterious bug what affect wfm/s speed.
Take example.
If set dots etc with 5ns/div (same with many other t/div etc) and get 140kwfm/s. Now change V/div or vertical shift. After this, wfm/s speed drops markable amount and it stay dropped until change some settings.  Turn channel off and back on... and wfm/s speed return back to up. Also touching some other settings reset this speed drop back to normal. There is some bug in SPO "engine".  This error need find asap because it may (depending its mechanism) have some connectieon to some of other bugs. 

EditAdd: Question    @Performa01
This burst image looks strange...is it really de facto ok?    I can not soon check anything but I have watched trig out live stream so many times that when I see this, my first reaction was that there is something wrong.. perhaps I'm wrong but my memory tell it looks strange. Of course my old head  best before date is very obsolete....so..

[tautech]

Interestinglingy I measured bandwidths of over 300MHz on my 200MHz SDS2204! I'm wondering if there is any bandwidth limiting going on or they didn't include any on early production runs. I do agree the triggering on the SDS2000 is superb. However unlike you I bought mine especially for the decoding and digital channels.

Yes, I’ve already wondered about that before I ordered my scope. When the 200MHz version of the scope goes up to >300MHz, it was very unlikely that the 300MHz version would do any better – and this assumption proved to be true when I measured the bandwidth of my scope soon after I got it.
Now I wonder if that’s the same for all version of the SDS2000? Probably not. Maybe Siglent have not planned to release a 300MHz version initially and the HW design didn’t include a switchable input filter for that. What was your HW-version? Mine is 5-3. My guess would be, the BW limit would be there on the current scopes.

The first SDS2000 versions offered to dealers were SDS2304 HW 3.3 and without MSO HW and ports.
The basic DSO functionality is exactly as the latest models and for the those early HW 3.3 units all options HW except MSO are installed. Mine has AWG, Decode and Power analysis options activated.

[Performa01]

EditAdd: Question    @Performa01
This burst image looks strange...is it really de facto ok?    I can not soon check anything but I have watched trig out live stream so many times that when I see this, my first reaction was that there is something wrong.. perhaps I'm wrong but my memory tell it looks strange. Of course my old head  best before date is very obsolete....so..

This burst image is indeed true – it was this funny behaviour, first noted on the frequency counter, that made me investigate deeper into this.
It is not consistent throughout the horizontal timebase ranges. Please refer to the attached images, they show the trigger out signal at various timebase settings from 5ns to 2µs.

For timebases up to 100ns, the bursts are fairly consistent, i.e. the width of the gaps is reasonably constant.
The first image (5ns/div) includes the cursor measurement that indicates the gap between bursts is about 3.1ms.
Up to 100ns/div the picture doesn’t change significantly – at least not as long we don’t zoom in any further.
But at 200ns/div we can see lots af small gaps within the bursts even on the unzoomed picture. Btw. Acquisition is always peak detect on this scope, so we won’t miss any anomalies even when completely zoomed out.
At 500ns/div the gaps get significantly wider and there is also an uneven spacing.
At 1µs/div (the picture I have already shown) it is that strange pattern that drew your attention, and this settles for 2 bursts separated by a long gap at 2µs/div.

[Performa01]

The first SDS2000 versions offered to dealers were SDS2304 HW 3.3 and without MSO HW and ports.
The basic DSO functionality is exactly as the latest models and for the those early HW 3.3 units all options HW except MSO are installed. Mine has AWG, Decode and Power analysis options activated.

I have purchased all available options, as they were offered as a bundle at a discount. I don’t need the AWG and consequently haven’t even tried it yet, but thought the MSO option together with the serial decoders were fine – until I noticed they only worked on the analog lines... well, this will hopefully change anytime soon. For some reason I were unable to purchase the power analysis option and my trial count is already down to 27, because even taking a look at the menu counts as ‘activation’ – give me a break!

Regarding the BW-limits I really don’t know what Siglent is doing here. As there is no SW-option for it, do they actually build different HW for different bandwidths? Or is it just the same HW with different filter caps in the frontend? Apart from that, I consider it just ridiculous to have two different variants for 70 and 100MHz, no matter how the BW-limit is actually accomplished.

I’ve detected another quirk with the new beta FW R2.0: Every time I turn the scope on, I find several settings all over the place. Acquisition mode, memory depth, automatic measurements – pretty much everything _might_ be different to what it was hwen I turned the scope off. It always seem to be just two settings that are randomly changed, but it’s always different ones. Go figure…

[nctnico]

I’ve detected another quirk with the new beta FW R2.0: Every time I turn the scope on, I find several settings all over the place. Acquisition mode, memory depth, automatic measurements – pretty much everything _might_ be different to what it was hwen I turned the scope off. It always seem to be just two settings that are randomly changed, but it’s always different ones. Go figure…

I think this is the smoking gun pointing to the firmware being a re-hash of the old firmware instead of a complete rewrite. The old firmware had exactly the same problem!

[tautech]

Regarding the BW-limits I really don’t know what Siglent is doing here. As there is no SW-option for it, do they actually build different HW for different bandwidths? Or is it just the same HW with different filter caps in the frontend? Apart from that, I consider it just ridiculous to have two different variants for 70 and 100MHz, no matter how the BW-limit is actually accomplished.

Model BW's are at this time set at the factory and AFAIK all models in the SDS2000 series have the same -3 dB roll off frequency.
Like much equipment these days one imagines the HW is the same throughout the series range and BW's set by factory programming.

ATM making assumptions based on R2 FW findings IMHO is flawed, just report features that are not working correctly and hope the official R2 FW doesn't take forever.

Report issues to: support@siglent.com

[9a4wy]

Did someone try to downgrade from beta 02 to 1.37??
many freezes and bugs in beta 
K

[cidcorp]

Haven't even considered downgrading because I have *not* been having many problems with Freezing.  Looking forward to the Official release of the new firmware.  Does anyone actually have a time frame
when we might see it show up and what will be the proper channels to get a copy when it does.

And as for my $0.02 (the cents are Canadian so probably worth 0.01.. wait we don't have cents anymore ), I think Siglent has done a good job  of trying their best to improve the firmware by asking the
community for help/feedback - joining this forum was a smart idea... shame some are so hostile.

Thanks

Chris