Rigol DS2000 Firmware 00.03.03.01.00 Comments and Bugs

[Teneyes]

Hello Rigol DS2000 owners, I am starting this new thread for comments and Bug reports related to the
Firmware Release 00.03.03.01.00.

This Release has Fixed the AC Trigger Position offset , I reported in July 2013
This Release has Fixed the AC Trigger Jitter , Wim13 reported in July 2013
This Release has Fixed the Roll to Y-T incorrect Scaling  @500uV/div
                                         , PureVector reported in Dec 2014


This Release has added  Auto Setup input coupling mode, on second page of Util Menu.

BUG  & LIMITATION REPORTS:
    01.00 There is a very rare Bug with Trigger position w/AC triggering (see next Post)
               EV confirms on DS2000

    02.00 The Auto Setup function for AC input is incorrect when there is
             any DC offset to the Input
             Andtfoot confirms on MSO2202A

    03.00 Limitation The Pass/Fail counter has a limit then wraps to negatives 

    04.00  Bug/Limit   Trigger Delay discontinuity, on DS2202 or DS2302
              The delayed trigger point jumps 1nsec.
              The Delay value where this occurs is just past the Integer value of nSec.
              Update this only occurs in 'AUTO' at 700 Pts , the work-around is to set more memory 7KPts

[Teneyes]

Trigger Position Offset Error
This is a rare Bug which occurs at specific frequency inputs, fast rise times, AC input coupling and AC triggering.  I would like to see if anyone else can confirm it also occurs on their DS2000, or DS2000A.

In the first Display below I show that the Position of the Trace is offset early about 8nSec occasionally. The display shows a mask for the correct trace and the count of the errors that occurred over 41,000,000 waveforms to have 25,000 errors.

This error occurs at various frequencies ( 2.017 MHz) , But does not occur at other Frequencies
at 2.020 MHz  I observe No errors in 10,000,000 Wfms (display 2)
at 1.9885 MHz  I observe No errors in 10,000,000 Wfms (display 3) 

I first observed this as I was adjusting the vertical position up and down.  Infinite persistence helps to capture the event.

Note the Waveform update rate was 32.082KHz

My observation has been reported to Rigol, but no confirmation Feedback.

[Teneyes]

Auto Setup BUG
With this new Firmware , there is an menu to Select which input Coupling the "Auto" function will set. This Menu in under UTIL. 2nd page. See 1st display below.

2nd display shows the input with DC coupling ( 3Vpp+ .5Vdc), correct
3rd display shows the input with AC coupling ( 3Vpp+ .5Vdc), correct

Now
the 4th display shows the new feature has a Bug that after Auto is Selected then the vertical position is incorrect for AC input coupling

The 5th display shows the position corrects after pushing the Chan 1 'Zero' Position, the Chan 2 Zero, the trigger Zero 

Can anyone Confirm this??

[Teneyes]

Comment on the new "AUTO SETUP". 
I am thinking this feature was added because Dave Jones made comments in the EEVBLOG #685 that a Scope should have AC coupling as default. But I think Dave is suggesting the default should be AC Trigger Coupling .and Not Input coupling. 
My suggestion to Rigol was to have a menu to Select the Auto setup. with these 3 choices:
          DC input with DC triggering
          DC input with AC triggering
          AC input

What would you like??? ( besides no Bugs Daaaah)

[Teneyes]

This Release has Fixed the Roll to Y-T incorrect Scaling  @500uV/div
                                         , PureVector reported in Dec 2014 Here

Well this small bug has been somewhat Fixed 
As the DSO is switched from Roll mode to Y-T mode the DSO briefly displays the error screen then stalls and after a break the DSO displays the correct Y-T displays
I find this fix a bit 'Hokey'

I have managed to capture the intermediate display with RUU
Below is:
1  Roll Mode display
2  The brief(200ms) error ( 1/2 scale)
3  Then the Correct 'Y-T' display

[Mark_O]

Trigger Position Offset Error
This is a rare Bug...

In the first Display below I show that the Position of the Trace is offset early about 8nSec occasionally. The display shows a mask for the correct trace and the count of the errors that occurred over 41,000,000 waveforms to have 25,000 errors.

It's interesting that you can use the scope to count it's own errors.  But perhaps not as interesting for those actually using it to (try to) detect errors in a DUT.

[Teneyes]

Trigger Position Offset Error
It's interesting that you can use the scope to count it's own errors.  But perhaps not as interesting for those actually using it to (try to) detect errors in a DUT.

Yes, not so much 'interesting' but important to know the characteristics of your equipment for use with the DUT.
I am not getting any confirmation from any user.
I will be aware of this error and to watch for this and compensate. 
Like if rise times are slow ,then not to worry.
If there are many  spikes  on infinite persistence, then the spike  8ns before trigger could be false.

There is high probability that Rigol will not address this as it is too rare and difficult to fix for just Me

I will Note this error, like I did for the jitter and offset error we found 2 years ago
And accept Rigol's decision.
It is Not a reason to sell or return my DSO.

I accept that it is just an exercise to investigate:
          "Why always 8ns offset"
          "Why only on fast rise times, with fewer sample points to detect the time of the trigger"
          "Why no errors at some input frequencies"
          "Why # of errors increase as input changes to another frequency, than drops  to No errors"
          "Why no Errors at some vertical positions, yet many errors at other vertical position"
          "Why after a self calibration does the vertical position that Errors occur at change a bit"
 Yes I have referred all this information to Rigol 2 week ago. But I doubt they had time or intention to confirm.
Sure would nice to have someone to confirm at least one observation

[andtfoot]

I have an MSO2072A and would like to help confirm the bugs. I may need a hand replicating the setup though.
Before I upgrade the firmware though... In one of the other threads it's mentioned that the firmware upgrade could knock out the CAN decoding (make it not available). Can anyone confirm?
In bug 1, when you say it occurs at 2.017MHz, does that mean you are feeding it a square wave of 2.017MHz?

[Teneyes]

In one of the other threads it's mentioned that the firmware upgrade could knock out the CAN decoding (make it not available).
In bug 1, when you say it occurs at 2.017MHz, does that mean you are feeding it a square wave of 2.017MHz?

I would think all FW updates must keep installed option keys.
The DS2000 keeps all options.

Yes , the in put is a Square wave. I used the sync output  of a DG4000 ,in order to get a fast rise time pulse. And the frequency was that of the Gen output. I 1st saw the odd error when testing for jitter with 200KHz. Using a Fast pulse makes it easy to see jitter , So once the trace was triggered and I set trigger position to center ,I moved the trace up slowly. That is when I observed the flash of a trace at the incorrect local. So a function gen. Is required.

[andtfoot]

In one of the other threads it's mentioned that the firmware upgrade could knock out the CAN decoding (make it not available).
In bug 1, when you say it occurs at 2.017MHz, does that mean you are feeding it a square wave of 2.017MHz?

I would think all FW updates must keep installed option keys.
The DS2000 keeps all options.

Yes , the in put is a Square wave. I used the sync output  of a DG4000 ,in order to get a fast rise time pulse. And the frequency was that of the Gen output. I 1st saw the odd error when testing for jitter with 200KHz. Using a Fast pulse makes it easy to see jitter , So once the trace was triggered and I set trigger position to center ,I moved the trace up slowly. That is when I observed the flash of a trace at the incorrect local. So a function gen. Is required.

Firmware uploaded... I can confirm the options stay the same.

Just trying bug #1 now, and I can't get it to fail yet.

Once the signal was there, I hit Auto, then changed signal and trigger coupling to AC. I then had to drag the waveform up to see it properly ('0V' was right at the top of the signal), and the trigger down for the signal to stay steady.

Setup is:
GW Insek AFG2225
- Trigger out to Rigol MSO2072A chan #1 in with 50R terminator on T-junction
- Trigger activated by 'Burst' signal on Channel 2 of AFG, set to freq of 1.017MHz


Rigol MSO2072A, with 200MHz and all options

Model:MSO2202A
Hardware Ver:2.2
Firmware:00.03.03.01.00

   DSO Vertical System
CH1:On
Scale:3.000e+02mV/
Position:1.002e+03mV
Coupling:AC
Invert:Off
Bandwidth Limit:OFF
Probe Ratio:1X
Impedance:1M
Unit:V

   DSO Horizontal System
Delay:Off
Time Mode:YT
Time Scale:5.000000e-09s
Delay Time Scale:2.000000e-09s
Time Offset:0.000000e+00s
Delay Time Offset:0.000000e+00s

   DSO Acquire System
Acquire Mode:Normal
Memory Depth:140
Average Num:2
Sampling Rate:2.000e+09

   DSO Normal Trigger System
Trigger Mode:Edge
Trigger Source:CH1
Trigger Sweep:Auto
Trigger Coupling:AC
Trigger Noise Reject:Off
Trigger HoldOff:1.000000e-07s
CH1 Level:-0.350000V
Trigger Edge Slope:Rising

[EV]

I can get this bug when rotating vertical gain knob or some others. Why I get now the picture in negative colors from RUU?

[egonotto]

Hallo,

the delay to trigger out is over 200ns with a jitter of 8ns p-p


Best Regards
egonotto
 

[EV]

Here is one picture more without touching any buttons. 100 fails of 165 712 frames.

[Teneyes]

Firmware uploaded... I can confirm the options stay the same.
Just trying bug #1 now, and I can't get it to fail yet.
Once the signal was there, I hit Auto, then changed signal and trigger coupling to AC. I then had to drag the waveform up to see it properly ('0V' was right at the top of the signal), and the trigger down for the signal to stay steady.

Thanks AndTfoot
First thing,  Did you Self-Cal ?. always need to do after a FW change. ( they must move the Cali Data table, or something).

It looks like the rise time on your input is a bit too slow. 
My Function Gen square wave output is to slow also. But never tried an Arb function.
Can you try some other switch source if you can another Device trigger out.( MB analog scope Z out, used to use that for TDR),

Make sure just Chan 1 only on the Rigol MSO

See EV's pulse
Here's an old waveform fast pulse  , just kidding

[Teneyes]

Here is one picture more without touching any buttons. 100 fails of 165 712 frames.

Thanks Eino,
We should state your DSO is a DS2000 non A.

Now if you change the Frequency. slightly , does the Error rate going up and Down?
I do the changes while in the PassFail mode as the Error mask is wide enough to not be an error

And lucky I happen upon errors that are very dependant on the frequency!
Notice 2.202 MHz for My DS2072  +
Frequency(MHz) errors (per 1M Wfrms)
       1.00    46
       2.00     1
       3.00     0
       4.00     0
   
       2.50     0
       2.40     0
       2.30     8
       2.20    78
       2.10    12
       2.00    14
       1.90     8
       1.80     6
       1.70    12
       1.60    19
       1.50     2
       1.40    18
       1.53     4
       1.47     3
LATER Retesting   
       2.200    0
       2.201    4
       2.202   62
       2.203    5
       2.204    2



Also in order to accurately vary the Vertical Position:
I had to use  my PC , Ultra Sigma , the SCPI control panel with the SCPI command:
  Chan1:offs 0.0xx.
 
Yes an obscured artifact (man made)

[Teneyes]

the delay to trigger out is over 200ns with a jitter of 8ns p-p

Thanks egonotto
That Trigger out Jitter has always been there ,
The delay is different for DC and AC coupled triggering
And the Jitter varies depending on input frequencies and can be small
see Pix for Trigger out on Chan 2

[EV]

We should state your DSO is a DS2000 non A.

Now if you change the Frequency. slight , does the Error rate going up and Down?
I do the changes while in the PassFail mode as the Error mask is wide enough to not be an error

I have DS2202 (non A).

Yes I noticed that the error rate changes along with the frequency. I have not noticed this error because I use almost always DC input and DC coupling.

[eevblognube]

Hi, I'm new here, but I was wondering if it is known whether this new firmware will allow feature unlocking.
I really would like to purchase a DS2072A and unlock it.
If unlocking is supported, will it work to upgrade the firmware to the latest and then perform an unlock?

[andtfoot]

Ok, looking at bug 2 (Auto setup).
I can confirm it happens to me; see 1st and 2nd shots.

I also tried the same thing on the internal 1kHz tet signal, and the same signal from the AFG-2225 (without any DC offset). That's the other two.

[AintBigAintClever]

Trig-to-Edge, F7 F6 F7 Utility (the usual extended menu key combo)
Page Down
Project
Here you've got Screen Test, Key Test, Gain1 and Gain2, which I think were there before, but if you Page Down you get a ResumeCal button, Page Down once more to get the return-to-previous-menu button.

Don't know if ResumeCal is a new feature, not sure what it does, but I ended up doing a recal after pressing it because adjusting the scale - with no input - was pushing the trace off the screen. If you cancel a Self-Cal, ResumeCal certainly doesn't pick up where it left off, it just loads new settings that seem to put the traces out-of-whack so you end up doing a Self-Cal again anyway.

EDIT: it's referred to in some older DS4000-related posts on here, so it may have been around for a while. The DS6000 calibration guide says it's "to restore the oscilloscope to its default parameters when the calibration fails or
the oscilloscope fails to save the parameters."

[Teneyes]

Ok, looking at bug 2 (Auto setup).
I can confirm it happens to me;

Thanks Andtfoot
It looks like when the "Auto" function is selected that the FW subtracts off the DC offset when
only 1/2 the offset should be Subtracted 
I hope that is Clear to RIGOL programmers
See Pics
1    DC input
2    After Auto is selected  when setup to AC input

NOTE: PLease watch the EEVBLOG #685 before commenting on the need for this function.

[Teneyes]

It's interesting that you can use the scope to count it's own errors.  But perhaps not as interesting for those actually using it to (try to) detect errors in a DUT.

Yes the Rigol DSO is comprised of many sub systems:
  The Analog input
  The ADC to Convert to DIgital
  The Sample Memory
  The Trigger Detection system
  THE Display Memory
  The Measurement system
  The Post Analysis systems and Logging

Now, I am using the Post Analysis part of the DSO to check how well the Trigger Detection subsystem is working in my testing,
Does that help explain.
Is there a Flaw in my methods?  anyone?

[Teneyes]

Bug 01.00  Update
  This Bug appears to Happen on DC input also

 So as I had the error repeatably occuring I varied the Memory depth
with these results:
  Depth     Errors/MWfs
   1.4k         127
    14K          53
   140K         320
   1.4M         250
    14M         240 

[Teneyes]

Bug 01.00  Update

Here is a series of Displays , by using infinite persistence and slowly adjusting the vertical position until there were errors in the position of the triggered trace. always been 8nsec early. Try it yourself
The Displays are:
      1. Error in Vectors Mode
      2. Error in Dots at 100mv trigger level
      3. Error in Dots at 200mv trigger level
      4. Error in Dots at 300mv trigger level
      5. Error in Dots at 400mv trigger level
      6. Error in Dots at 100 to 400 mv trigger level  .

What I see with the series of Dot mode displays is that the error only occurs when a sample is at a specific value . as there is no variations in the position of the samples in error trace with infinite persistence selected

Then I see that the Specific value of the sample that causes the Error is = the tigger level, which stands to reason that the trigger detection system is making an Error as to when the trigger point occurred in time.

In the Last display I showed how the persistence held the dots on the display as I change the trigger level higher (so cool)
Note to Clear Persistence (use CLEAR)

Does any one have experience with trigger Comparator ?
apply a  dead band, Ignore sample in Deadzone?

In any Case I told Rigol to:
      "Follow the Yellow Dot Road to a solution"

[hooverphonique]

that a Scope should have AC coupling as default. But I think Dave is suggesting the default should be AC Trigger Coupling .and Not Input coupling. 

yes, that's definitely what he meant!

[Teneyes]

Bug 01.00  Update      More Testing with 2 Channels
Here with 2 channels on and the fast pulse there are only a few samples during the step of the input signal.
Here are 3 displays at 42, 336,and 636 mV Trigger level setting
Then a display where the trigger level was manually varied from 30-630mV
and finally a display with a Sinewave on Chan 2 with trigger errors occurring on Chan1

Do I show a "cause and effect" clearly???

Why is the offset 8 nSec?
Does the FW move 16 samples from the Sample memory to the Display memory in  groups (128 bits)?

Will Rigol address this??? It is hard to say, very rare, and just a limitation, 
   

[Teneyes]

Bug 01.00  Update
  Just to be Clear!
 No Options are Installed and there are errors

[Teneyes]

03.00    Limitation
      While testing the errors in waveforms with the Pass/Fail function I encountered the limit on the Wfms counter which is 2,147,483,648 . Which I laughed knowing it was 31 bit integer
The counter then wraps to  -2,147,483,647 and continues up +.

Given that at 20,000 Wfmrs/sec it would take about 30 hours to reach the limit , it is a large limit

BUT there is room to improve and here are some suggestions:
   1. Just like the "Stop on Error"  , the DSO could Stop at the 2G Wfmrs limit

   2. If the Counter goes negative just add 4G before displaying, and Stop on -1

   3.  Increase the Counter size  to the Space allocated on the screen for the count , 999,999,999,999

As I was testing , I wished there was the Feature, like the 'Stop on Error'  that was a "Stop on #" a count. This Stop on Count would be settable, so one could walk away and return to see how many errors occurred in 10M WFmrs ... 
Just a Suggestion for improvement....

Response from Rigol
______________________________________
That is funny.
Almost a full 32 bit number. Excellent testing.
I bet you are the only person to find that   
Regards,  Chris Armstrong
Director of Product Marketing & SW Applications
______________________________________________

[Teneyes]

Bug 01.00  Update
 more testing show that  this error occurs on all Edge trigger Modes, but mostly on the Falling Edge trigger.
See the Pass/Fail counts below.

So I will review the setup to Test.
  AC input Coupling
 AC trigger Coupling
 Set Falling Edge Trigger
Set Persistence to Infinite
Input the Fast Square wave or  repeating Pulses ( about 2 MHz,  vary this also)
Slowly move Veritical Position, stop when persistence show a trace at 8ns early

Once you see errors occurring then set to Dots
I am Wondering if this occurs on the MSO

[andtfoot]

Testing for Bug 1 again. Still can't get it (I don't think my function generator is good enough), but I did make the scope crash though... does that count? 

[Teneyes]

Bug 01.00  Update

. does that count? 

@andtfoot, Thanks
Yes , I would think that counts, You win, or should I said you Lose more severely

Here are more tests to show that the Error occurrences change with the Number of measurements that are on.

Yes rarely happens. any comments?
And the next post is more so

[Teneyes]

Bug 04.00  Bug or Limit ?    Trigger Delay discontinuity
      This condition is only noticeable on DS2202 or DS2302
    With DC input and DC trigger a delayed trigger point jumps 1 sample period early at specific delays.
 1 sample period = 0.5 nSec for single channel and = 1.0nSec for 2 Channels.
The Delay value where this occurs is just near the Integer value of nSec.
This occurs when using the faster timebases
For the DS2202, 1Chan the error in the display occurs when the Delay is X.01, X.02, X.03 and X.04 nSec (where X=-14 to 14)

For the DS2302, 1Chan the error in the display occurs when the Delay is  X.01, and X.02 nSec (where X=-7 to 7)

There are discontinuities throughout the adjustment of the Trigger Delay .
See the 4th Pix , where I set the Trigger Delay time

You Can see the manual adjustment increments are 0.02 or 0.04 nSec

Yes I checked Delay settings from -4.00nSec to -5.05nSec in 0.01 increments.

This also Occurs when zooming from 20ns/div lower
This does not occur when zooming from 50ns/div lower

This also occurs with FW 00.03.01.00.04

Nice to have a confirmation , and a MSO2000A owner check

A Bug or a Limit ?

[Teneyes]

Bug 04.00  a very small Bug or Limitation ?    Trigger Delay discontinuity
Well I satisfied myself on this point. 
In the displays below I show where and when the error occurs
Here are displays at different Trigger delay points
1) The Trigger delay is set to 0.00 nS  and is correct
2) The Trigger delay is set to 1.00 nS  and is correct
3) The Trigger delay is set to 1.01 nS  and is NOT correct
4) The Trigger delay is set to 1.02 nS  and is NOT correct
5) The Trigger delay is set to 1.03 nS  and is correct

Now you can see  that the display with the Trigger delay is set to 1.01 nS  is the same as
the display with the Trigger delay is set to 0.00 nS 

This error occurs near every 1 nSec increment
It is rare that one manual makes a delay adjustment to these settings and the resulting error is very small just 1 nSec.  ( one sample time )
In order to test , I used SCPI commands to set the values accurately.
This is a small error and only visible on DS2202 and DS2302 models set on fast timebase.

Now I observed that this error only occurs in "AUTO" , when the memory depth is only 700Pts.
and when the memory depth is set higher the error does not occur.

I make the hypothesis that the program that processes the 700 sample pts thru the SineX/X function and then maps the result in to the display memory has a fault at specific points.

But I say again this trying to interpolate 700 1nSec points into 1400 (10pSec) setting positions can be tricky.

So if you are measuring down to 10pSec offsets, be sure to use the work around of more Memory depth. 
A Programming curiosity!

[Teneyes]

In the 1st display I show recorded waveforms (.Gif ) of the error
I have narrow the condition down for my DSO and signals. 
   AC input coupling
   AC trigger coupling
   Fast rise or fall pulse
   Fast update rate ( 5ns/div ) so the the error can be observed
   Infinite persistence also so the error can be observed
   vertical position off 0.0 adjusted for error
   Input frequency 1 to 2.5 MHz  ,

In the 2nd display , I show an error trace in DOTS format , and this shows that ONLY when the sample data has a sample point at the trigger point does this Error occur.
Also as the Trigger point is changed the trace that causes the error has a DOT/sample point at the Trigger level , the display shows the variation/streaking of the other points. (persistence)
With this correlation of Error point to Trigger point, I hypothesize that the programming for trigger detection is the source of this error.

Because of the difference between input source oscillator and the internal DSO sample clock the occurrence of this error must be such that one sample (at 2GS/s) does coincide with the Voltage input to be equal to the Trigger point. ( involving many factors: freq, update rate, sample clock, amplitude, offset....)

Based on this,  I conjecture that the trigger program is testing for an input greater than (or less than) the trigger point in order to display the trace.
BUT when the input is Exactly equal to the Trigger point there is an error and the Trace data points are displayed incorrectly

[Teneyes]

Bug 01.00  Update
  An easier way to test for this Bug is with a square wave and then vary the duty cycle.
In the displays I show where the error occurs at 21.3% duty cycle. (vectors , Dots)
By varying the duty cycle the AC zero point varies and the AC trigger point of '0.0' is at a different DC input value.    Once the errors is observed then one can vary the AC trigger point to see how the error follows the trigger value.

[miguelvp]

I already did bring it up in the jitter thread but I'll add it in here as well.

USB thumb drive can only be inserted once, if you take it out it won't recognize a second re-insertion. Can anyone confirm this?

Thanks.

[andtfoot]

I already did bring it up in the jitter thread but I'll add it in here as well.

USB thumb drive can only be inserted once, if you take it out it won't recognize a second re-insertion. Can anyone confirm this?

Thanks.

It works fine for me.
I just tried the following successfully:
- Power on scope
- Insert thumbdrive and check in 'Storage->Disk Manage'
- Remove thumbdrive, wait ~5 seconds, reinsert
- Save picture to thumbdrive
- Remove thumbdrive, wait ~5 seconds, reinsert
- Save Setups, then picture to thumbdrive
- Remove thumbdrive nad check files in PC

[CustomEngineerer]

Looks like this thread is probably dead but still seemed like the right place to post this.

I installed the 00.03.03.01.00 firmware on my DS2072A-S shortly after its release (around Jan 1st). I just noticed what I think is a new math operation called "Digital Filter" that was introduced with this firmware. I don't use the math functions very often so maybe I just missed it before but I don't remember seeing this ever. I've searched these forums and google and can't find a mention of it anywhere. Its also not listed in Rigol's documentation that I can find.

The "Digital Filter" operation has 4 filter types. Low Pass, High Pass, Band Pass and Band Stop. The Low Pass filter has a Upper Frequency Limit setting that can be set to 2.50kHz - 247kHz. The High Pass has a Lower Frequency Limit setting that can be set to 2.50kHz - 247kHz. The Band Pass and Band Stop filters have both an Upper Limit and Lower Limit setting that each can be set to 2.50kHz - 247kHz with them not be able to be set closer than 2.50kHz of each other.

Sorry if this is well known and I'm just really unobservant.

[marmad]

I installed the 00.03.03.01.00 firmware on my DS2072A-S shortly after its release (around Jan 1st). I just noticed what I think is a new math operation called "Digital Filter" that was introduced with this firmware. I don't use the math functions very often so maybe I just missed it before but I don't remember seeing this ever. I've searched these forums and google and can't find a mention of it anywhere. Its also not listed in Rigol's documentation that I can find.

The "Digital Filter" operation has 4 filter types. Low Pass, High Pass, Band Pass and Band Stop. The Low Pass filter has a Upper Frequency Limit setting that can be set to 2.50kHz - 247kHz. The High Pass has a Lower Frequency Limit setting that can be set to 2.50kHz - 247kHz. The Band Pass and Band Stop filters have both an Upper Limit and Lower Limit setting that each can be set to 2.50kHz - 247kHz with them not be able to be set closer than 2.50kHz of each other.

Sorry if this is well known and I'm just really unobservant.

Cool! This is certainly a new feature that I hadn't seen yet - I haven't had a chance to play with the new firmware yet because I've been abroad (and away from my scope) for a long time. Glad to see Rigol is still slipping in new features, although I sure wish they'd publicize it when they do it (a simple changelog would be great).

[Teneyes]

I installed the 00.03.03.01.00 firmware on my DS2072A-S shortly after its release (around Jan 1st). I just noticed what I think is a new math operation called "Digital Filter" that was introduced with this firmware.

I agree , very cool
Here is Display of a 500Hz to 6KHz sweep(20ms) with a 4K Lo Pass Dig.Filter.
on to more testing

[Teneyes]

Display of 10KHz HI Pass Digital Filter with 0.5-20KHz 12ms Sweep

The Max. Cutoff Frequency of HiPass setting is dependant on the Scan Rate
ie.  for 1ms/div the Max. Frequnecy is 49.5KHz
  But that is Not very useful
below I show :
10KHz Hi Pass
20kHz Hi Pass
30KHz Hi Pass

[Teneyes]

More Digital Filter testing
4-6k Band Pass Filter with 1 to 10KHz sweep over 22ms

[Teneyes]

More Digital Filter testing
6-12KHz Band Reject Filter with 2 to 16KHz sweep over 11ms

Now I find it Bad that once you set up the filter  Cutoff Frequency  , if you change the Time base the those Frequencies will Change, 
I think the Frequencies should NOT Change,
although  there will be the end limits that would be able to restrict a setting.

[CustomEngineerer]

I had just discovered the digital filter at around 3-4 in the morning and clearly didn't really play with it. It appears that each time base setting its own minimum and maximum cutoff frequencies. I am just listing the coarse time base ranges, but even with fine time base adjustment each possible time base has its own specific cutoff range. You can clearly see the pattern. It looks like when you change time bases it just translates what you had the upper and lower limits set at to the new frequency range. So if you had the the time base set at 10.00ms and the lower limit was set at 20% of the range for 10.00ms, if you change the timebase to 20.00ms the lower limit would now be 20% of the range for 20.00ms. For example, if you have the lower limit set to 1.50kHz on time base 10.00ms, when you change the time base to 20.00ms the lower limit would become 750Hz. If you change the time base back to 10.00ms the lower limit would be 1.50kHz.
1.000ks -> 500uHz - 49.5mHz (Yes, that is micro and millihertz)
500.0s -> 1.00mHz - 99.0mHz
200.0s -> 2.50mHz - 247mHz
100.0s -> 5.00mHz - 495mHz
50.00s -> 10.0mHz - 990mHz
20.00s -> 25.0mHz - 2.47Hz
10.00s -> 50.0mHz - 4.95Hz
5.000s -> 100mHz - 9.90Hz
2.000s -> 250mHz - 24.7Hz
1.000s -> 500mHz - 49.5Hz
500.0ms -> 1.00Hz - 99.0Hz
200.0ms -> 2.50Hz - 247Hz
100.0ms -> 5.00Hz - 495Hz
50.00ms -> 10.0Hz - 990Hz
20.00ms -> 25.0mHz - 2.47Hz
10.00ms -> 50.0mHz - 4.95Hz
5.000ms -> 100mHz - 9.90Hz
2.000ms -> 250mHz - 24.7Hz
1.000ms -> 500mHz - 49.5Hz
20.00ms -> 25.0Hz - 2.47kHz
10.00ms -> 50.0Hz - 4.95kHz
5.000ms -> 100Hz - 9.90kHz
2.000ms -> 250Hz - 24.7kHz
1.000ms -> 500Hz - 49.5kHz
.
.
.
5.000ns -> 100MHz - 9.90GHz
2.000ns -> 250MHz - 24.7GHz

Edited to fix typo in the 20.00ms - 1.000ms range. Thanks Teneyes

[CustomEngineerer]

marmad,

Agreed, a change log would be nice. I can't believe after the firmware issues that Rigol has had that they wouldn't want to tell us about the cool new features they add along with the bugs they fix.

Teneyes,

Thanks for testing the digital filter out. I don't currently have a function generator that can do sweeps easily (hence the reason I got the DS2072A-S, oops) so its nice to see that the digital filter's do actually seem to be working. Plus, pretty pictures.

[CustomEngineerer]

Pix are very easy with Marmad's RUU program, have you tried it? Here

Yes, very cool program. Would have been awesome if Rigol could have done the 3D waveform plots on the scope like Marmad did in RUU. I have at least a couple of times ended up playing around with those for hours instead of actually accomplishing what I had originally set out to do.

[Teneyes]

Here is the comparison of two Digtal filter functions; the Hi Pass is shown along with a Bandpass adjusted for the same frequency range. 
Does anyone have  an idea why they are different?
  Different functions?
and is there a way that the can be the same ?
Should the function be the same on the low frequency side?

I like the complete cutout of the 'Bandpass' dig. filter on the low side.

PS I used single trigger on DSO and the DSO trigger out is connectted to the Function Gen Trigger-input to start the Sweep

[Rory]

Let's see what the impulse and step responses on those filters are.

[Teneyes]

Progressing the testing to Lo and Hi Pass Digital filter with Sawtooth input

[Teneyes]

Progressing the testing to Lo and Hi Pass Digital filter with trapezoid input

[Teneyes]

Now the Digital Filter with Bandpass filter set to 3-4KHz and the input of a sweep from 2-5KHz
1 Sawtooth wave
2 Sine wave
3 Square wave
Does anyone know the equations that are used here???

[Teneyes]

Here is a sweep of 5-18KHz sine wave with a Digital Bandpass filter
1. Bandpass set from 8 - 12 KHz
2. Bandpass set from 8 - 12 KHz but zoomed 1 step from 500us/div to 200us/div
3  Still Zoomed  with Bandpass set form 4-5KHz

Question : How should the Zoom work when Digtal filter ON??

Is this a Bug??

[Teneyes]

More testing on the Zoom of digital Filter Function
Here I test a LoPass Dig. Filter : Normal and Zoom
1  LoPass at 20Khz and sweep from 5-40Khz
2  LoPass at 20Khz and sweep from 5-40Khz  Zoomed
3  LoPass at   8Khz and sweep from 5-40Khz  Zoomed

From this, I conjecture that the FW is using the 5oous/div time base, with the Zoomed Data and therefore the Digital Filter function is incorrect by a factor of  200/500.
Therefore the Cutoff frequency becomes 2/5 of 20KHz=8KHz.
I conclude it is a Bug!!

In zoomed mode the filter slope should expand by the zoom factor (display division)