EEVblog #683 - Rigol DS1000Z & DS2000 Oscilloscope Jitter Problems

[leppie]

I think this is the program you were looking for: http://meteleskublesku.cz/wfm_view/

Well, only windows and no sources. Seems i'll still need to write my own reader as an evening project

An evening? Good luck with that! 

Given MarkL just makes a small binary edit and then presumably just reading the bytes, all one need to do is download some FFT lib and a graphing lib.

A few hours tops to code (for someone knowing what they doing), but there are probably tools that can achieve the same with minimal effort.

[MarkL]

Given MarkL just makes a small binary edit and then presumably just reading the bytes, all one need to do is download some FFT lib and a graphing lib.

That's all I'm doing.  I dump the hex of the file and find the start of the data by hand.  It's mostly at the same offset per model, but not always (probably depends on what people have set).  And sometimes there's a tail that needs to get chomped.

One byte per sample at 1GHz is how I've asked people to do the capture.  Done.

One potentially useful side effect of all this is that I will have a nice pile of captures from different model scopes.  If no one objects, I could make them available for testing for anyone developing a real program to read them and do plots, FFT, etc.  (I can't imagine anyone would object, but if someone doesn't want their capture shared please PM me.)

I have a few more captures people have sent me.  I'll get them added to the "clock analysis post" this afternoon.

[leppie]

I have a few more captures people have sent me.  I'll get them added to the "clock analysis post" this afternoon.

 

I hope mine is not nonsensical as you did not specify what timebase to use 

[marmad]

A few hours tops to code (for someone knowing what they doing), but there are probably tools that can achieve the same with minimal effort.

Did you not read the post above mine from Michal_S detailing the difficulties of cracking the format on the new Rigol WFM files? And he's hardly the only one working on it - I know other people that have been as well.

It's easy as pie to open a WFM file in a hex editor and extract the waveform data manually - and quite simple to take a CSV file and translate that into binary data. But, please, whip me up a UltraVision WFM reader by tomorrow that can extract ALL information (i.e. all DSO settings, raw waveform data, etc) across all the model lines - a few hours tops, right? I'd love to see that. 

[sergey]

A few hours tops to code (for someone knowing what they doing), but there are probably tools that can achieve the same with minimal effort.

Did you not read the post above mine from Michal_S detailing the difficulties of cracking the format on the new Rigol WFM files? And he's hardly the only one working on it - I know other people that have been as well.

It's easy as pie to open a WFM file in a hex editor and extract the waveform data manually - and quite simple to take a CSV file and translate that into binary data. But, please, whip me up a UltraVision WFM reader by tomorrow that can extract ALL information (i.e. all DSO settings, raw waveform data, etc) - a few hours tops, right? I'd love to see that. 

It could few hours to code yes. But first you need to understand the file format, that's obviously orders of magnitudes more than few hours.

[sergey]

Well, only windows and no sources. Seems i'll still need to write my own reader as an evening project

An evening? Good luck with that! 

Well, don't get it as if i promised something! But i will spend some time on this just because it's kind of interesting to learn something from the process. Anyway, *if* i get something in there, i'll report back in the eevblog forum.

Let's get back to the jitter issues now

[marmad]

It could few hours to code yes. But first you need to understand the file format, that's obviously orders of magnitudes more than few hours.

That was precisely my point. It's like saying it would only take 10 minutes to drive across town - if only we had some petrol.

Apparently it took Dexter - the guy who coded the original WFM Viewer - some time to reverse-engineer the header fields of the earlier Rigol WFM format (from the DS1000E series). No one has done it yet for the UltraVision versions, so: no petrol.

Well, don't get it as if i promised something! But i will spend some time on this just because it's kind of interesting to learn something from the process. Anyway, *if* i get something in there, i'll report back in the eevblog forum.

Great, it's worth the effort - to the whole community.    I have spent a bit of time deciphering (or trying to decipher) many of the different file formats - including .MSK, .TRC, .REF, and .WFM.

[leppie]

That's all I'm doing.  I dump the hex of the file and find the start of the data by hand.  It's mostly at the same offset per model, but not always (probably depends on what people have set).  And sometimes there's a tail that needs to get chomped.

One byte per sample at 1GHz is how I've asked people to do the capture.  Done.

Did you not read the post above mine from Michal_S detailing the difficulties of cracking the format on the new Rigol WFM files?

Did you not read the post...? Let's not be dicks about it.

[marmad]

Did you not read the post above mine from Michal_S detailing the difficulties of cracking the format on the new Rigol WFM files?

Did you not read the post...? Let's not be dicks about it.

So, you start name-calling? And sorry - what exactly did I do? You responded to my post originally - not the other way round - and either you're still not getting the gist of the problem of writing an automated WFM reader in one evening:

It's mostly at the same offset per model, but not always (probably depends on what people have set).  And sometimes there's a tail that needs to get chomped.

...or you're just being.... well, let's say stubborn.

[leppie]

Did you not read the post above mine from Michal_S detailing the difficulties of cracking the format on the new Rigol WFM files?

Did you not read the post...? Let's not be dicks about it.

So, you start name-calling? And sorry - what exactly did I do? You responded to my post originally - not the other way round - and either you're still not getting the gist of the problem of writing an automated WFM reader in one evening:

It's mostly at the same offset per model, but not always (probably depends on what people have set).  And sometimes there's a tail that needs to get chomped.

...or you're just being.... well, let's say stubborn.

Within that context, seeing you want all the bells and whistles and given paid at standard industry rate, a couple months.

Within the context of this thread. I stick to my estimate.

[marmad]

Within that context, seeing you want all the bells and whistles and given paid at standard industry rate, a couple months.

Within the context of this thread. I stick to my estimate.

I'm not exactly sure we're talking about the same thing anymore, but I'll say just one last thing (then shut up about it):

I don't know how many UltraVision WFM files you've looked inside yourself - I've examined a hundred or so in the last couple of years, while trying to decipher Rigol's rather bizarre format (precisely why and by how much the data is offset from the header, etc) - with some help from EEVblog member Drieg, who was also looking into it - without any final success so far.

So if you believe you can whip out some software in an evening which JUST strips out the raw waveform data from any UltraVision WFM file - regardless of any settings on the DSO - please, do it. I don't think it's possible - but I would love to be proven wrong (and it would save me headaches in the future). 

[pa3bca]

If no one objects, I could make them available for testing for anyone developing a real program to read them and do plots, FFT, etc.  (I can't imagine anyone would object, but if someone doesn't want their capture shared please PM me.)

No objection especially not if the header is stripped off (the wfm output from my 2072A also contains the serial number and it imagines itself to be a 2302A which must be kept a secret  )
A quick scan did not unearth anything resembling a serial number in the 1074Z wfm file, but who knows..

[MarkL]

If no one objects, I could make them available for testing for anyone developing a real program to read them and do plots, FFT, etc.  (I can't imagine anyone would object, but if someone doesn't want their capture shared please PM me.)

No objection especially not if the header is stripped off (the wfm output from my 2072A also contains the serial number and it imagines itself to be a 2302A which must be kept a secret  )
A quick scan did not unearth anything resembling a serial number in the 1074Z wfm file, but who knows..

Good point.  I don't like my serial numbers out there either.

But since I don't know anything about the header (I skip it completely), I don't know what else "interesting" might be in there.

I'll check with all contributors first if anyone asks for the file set.

[Bud]

From Bud:
  DS2072A Hardware v2.0, Firmware 00.03.00.SP1

  F=280MHz via a 280MHz bandpass filter to reduce source spurious/harmonics
  ..
These look like there might be a tiny bit of 200kHz modulation in the clock.  But I'm also noticing the close-ups of the main carrier show that there is a slight difference in the offset between the two sources which may imply it's in the source.

I'm undecided on this one.

Bud: Being a precision RF guy, you probably know these sources very well.  Your comments?  Have you looked at your Rigol's internal clock with a swept analyzer?

No I still have not opened my scope, not sure yet if to sell it as there are many little things, beside possible clock issues, that irritate me and create a perception of a Fisher-Price product (you folks who do not know who Fisher-Price is can look ip the name in Wiki). To name a few :

- the elusive 50 Ohm input issue when the inputs forget their 50 Ohm state on power up so the settings say they are on 50 Ohm when in fact they are not
- deactivation of measurements is awkward and done with separate buttons than activation
- saving waveforms all of  a sudden the filenames switch to Chinese with no option to switch to English
- tiny fonts in measurements
- lock ups when in setting internal date/time
- lock ups when the scope is connected  to LAN
- cumulative lock ups even with the scope not connected to LAN nor to USB but if it locked up once, it locks up again after a few min after a reboot, then keeps locking up with a smaller and smaller interval after each reboot until locks up almost instantly after reboot. This I found to be specific when the scope is configured to boot to the Last state vs Default state. The way to fix it was to set the scope in the menu to boot to Default state, which seemed to clear  the memory that stores the current corrupted settings or whatever, so the scope ran ok after booting to Default state. I now configured it again for Last state and so far so good but I feel that is again until something happens that will cause it to lock up and then again after each reboot it may have that issue.

I am too busy to leave with the above problems, I want to have an Instrument that I turn on and it works and I trust it. Cant say so about DS2072A.

But anyway , getting back to the waveforms. I do have a problem with the 100/200kHz peaks that seem to be PFD artefacts but they look too strong, being only 60dB down from the fundamental. Especially the 200kHz one. THis may indicate the loop filter sucks as it supposed to suppress  these artefacts that are way away from the loop filter cut-off frequency of about 3kHz.
Also I am worried what that 60kHz artifact is (the closest to the fundamental). It is only 45dB down which is pretty bad. Its origin is unknown but does not seem to come from the source as I used two different sources. So yes I feel like clock on DS2072a also should be checked with a spectrum analyzer.

[MarkL]

But anyway , getting back to the waveforms. I do have a problem with the 100/200kHz peaks that seem to be PFD artefacts but they look too strong, being only 60dB down from the fundamental. Especially the 200kHz one. THis may indicate the loop filter sucks as it supposed to suppress  these artefacts that are way away from the loop filter cut-off frequency of about 3kHz.
Also I am worried what that 60kHz artifact is (the closest to the fundamental). It is only 45dB down which is pretty bad. Its origin is unknown but does not seem to come from the source as I used two different sources. So yes I feel like clock on DS2072a also should be checked with a spectrum analyzer.

I agree - it's not the sources.

At first I thought it might be the sources because the spectra changed when the source changed.  But the spectra are too similar to be a coincidence, and the difference is *very* small.  It may be from something as simple as the scope warming up while you changed the sources.

Can you see any cyclic delay jitter on this scope with these nice stable sources?  5us, 15us, etc (peaks of 100kHz sine)?  How about 7.3us, 21.8us, etc (peaks of 68.8kHz sine)?

They may be too far down to see visually in the time domain.

[David Hess]

2) Since Rigol is in a jitter-fixing mode, could they perhaps also tackle the issue of the 8ns jitter on the Trigger Output? This bug makes the use of the Trigger Output problematic at best, and was first noticed on the DS2000 and reported about 2 years ago. It is also present on all of the MSO/DS1000Z models, as shown in my attached image (Channel 3 is the Trigger Output fed back into the DSO displaying the ~8ns of jitter).

I will be very surprised if this can be improved.  The timing resolution of the Trigger Output is going to be limited by granularity of the FPGA clock unless they added interpolation hardware.  Didn't Rigol suggest that this output was more useful for verifying the waveform acquisition rate than as a low jitter trigger output?

[Bud]

Can you see any cyclic delay jitter on this scope with these nice stable sources?  5us, 15us, etc (peaks of 100kHz sine)?  How about 7.3us, 21.8us, etc (peaks of 68.8kHz sine)?

I do not see a pronounced cyclic delay jitter, but as I set more uS delay , jitter increases to the point the trace becomes unusable, especially at >100MHz input frequencies. The trace becomes very shaky and I can see the spread in horizontal jitter if I turn on permanent persistence. DS2072A may need a good investigation. With lower frequencies the problem apparently is masked and not that obvious. Given your FFT results I am not surprised.

[Bud]

I will be very surprised if this can be improved.  The timing resolution of the Trigger Output is going to be limited by granularity of the FPGA clock unless they added interpolation hardware.

We have already seen Rigol Chaos Clock passing the child PLL in the ADC chip in DS1000 and getting to the downstream device bus. If, say, trigger timing is derived from that chaos clock, improving the clock should improve the trigger output.

[AlessandroAU]

Here's a small application that can read the entire memory buffer of the 1000z scopes and preform an FFT. You can also right click on the graphs and export them to excel/clipboard.

Edit: Updated Program to fix some errors

[leppie]

Here's a small application that can read the entire memory buffer of the 1000z scopes and preform an FFT. You can also right click on the graphs and export them to excel/clipboard.

 

Can I assume one needs the 32-bit version of the LabView runtime?

Update: Yes, that one works

Looking pretty good and seeing what MarkL has shown. Nice app!



Looks nice with antialiasing turned on (in the app, not the scope)

[AlessandroAU]

Oops, Sadly yes you will need the runtime:

http://www.ni.com/download/labview-run-time-engine-2014/4887/en/

I can pack it with the exe as an install, but that brings it to 200mb anyway. So you might as well download the engine.

[leppie]

Oops, Sadly yes you will need the runtime:

http://www.ni.com/download/labview-run-time-engine-2014/4887/en/

I can pack it with the exe as an install, but that brings it to 200mb anyway. So you might as well download the engine.

Can you modify this app? If so, can you allow the UI to be maximized so the charts zoom accordingly? With a splitter maybe?

I was also getting out of memory errors when capturing anything above 2Mpts.

Maybe the 64-bit runtime wont have this issue?

[AlessandroAU]

Oops, Sadly yes you will need the runtime:

http://www.ni.com/download/labview-run-time-engine-2014/4887/en/

I can pack it with the exe as an install, but that brings it to 200mb anyway. So you might as well download the engine.

Can you modify this app? If so, can you allow the UI to be maximized so the charts zoom accordingly? With a splitter maybe?

I was also getting out of memory errors when capturing anything above 2Mpts.

Maybe the 64-bit runtime wont have this issue?

You can zoom/pan in on the charts with the tools underneath the graph (the three buttons).

Have you set the memory depth options correctly on your scope? (don't leave it on auto). Each of the memory depth settings works fine for me on a 1074.

Maybe a screenshot of the error? I think I've encountered it before, its driver/usb related and a reboot fixed it.

[pa3bca]

I can pack it with the exe as an install, but that brings it to 200mb anyway. So you might as well download the engine.

Unfortunately you have to create an account first before you can download the runtime. I hate that. Probably must supply all sorts of relevant and not so relevant personal info like shoe size and favorite coffee brew or whatever. (I know, I exaggerate).
So, if there would be any other way to download the runtime (that is legal of course)...
You app looks really very useful.

[AlessandroAU]

I can pack it with the exe as an install, but that brings it to 200mb anyway. So you might as well download the engine.

Unfortunately you have to create an account first before you can download the runtime. I hate that. Probably must supply all sorts of relevant and not so relevant personal info like shoe size and favorite coffee brew or whatever. (I know, I exaggerate).
So, if there would be any other way to download the runtime (that is legal of course)...
You app looks really very useful.

http://bugmenot.com/view/ni.com

The first login works