Mmmh...
This is how it looks like on the 1074z:
And this is the VI output:
Mmmh...
This is how it looks like on the 1074z:
And this is the VI output:
I notice you are only capturing 12Mpts on the scope. How much memory are you requesting from the program?
12 Mpts, too.
There is a dt value underneath the the waveform graph, what does it read?
Ok the issues with the program should be fixed, it was running out of memory calculating waveform statistics, now it only uses the first 50k points to calculate waveform stats. I was also storing the waveform array with unnecessary precision, anyway it should be ok now.
Let me know of any bugs
AlessandroAU,
Any chance your program will also work with a Rigol DS2000 series scope?
Ok the issues with the program should be fixed, it was running out of memory calculating waveform statistics, now it only uses the first 50k points to calculate waveform stats. I was also storing the waveform array with unnecessary precision, anyway it should be ok now.
Let me know of any bugs
AlessandroAU,
Any chance your program will also work with a Rigol DS2000 series scope?
The VSIA commands are _slightly_ different but different enough so it won't work :\
1
looks like its not grabbing the initial waveform (config) data for some reason... I don't know why that would happen... the commands should not differ
just curious where can one download the AlessandroAU's Labview program? How much is it? i just got a 1054z and do not have a dedicatred SA yet
thanks
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
Would you be willing to post the VI for this? I'd like to modify it, maybe even make a DS2000 version.
We expect the final firmware for the MSO1000Z and DS1000Z series to be released by December 19th
Which is tomorrow, and hopefully it will heal my scope.
We expect the final firmware for the MSO1000Z and DS1000Z series to be released by December 19th
Which is tomorrow, and hopefully it will heal my scope.
and hopefully I'll be able to finish my review.
I ordered a DS1054Z last month and have been waiting for news about its delivery and bug fixes (I have been closely following this thread and other relevant ones for ages).
I just received an email saying my scope was due to be posted out today so I called up Rigol to ask about the AC coupled trigger mode bug and the jitter issue as I had not seen any mention of a fix on this thread.
I have been told by a very helpful member of staff that they have just received a batch of scopes that have been flown over directly to the UK and they all have a new firmware on them which fixes these issues.
I ordered a DS1054Z last month and have been waiting for news about its delivery and bug fixes (I have been closely following this thread and other relevant ones for ages).
I just received an email saying my scope was due to be posted out today so I called up Rigol to ask about the AC coupled trigger mode bug and the jitter issue as I had not seen any mention of a fix on this thread.
I have been told by a very helpful member of staff that they have just received a batch of scopes that have been flown over directly to the UK and they all have a new firmware on them which fixes these issues.
We will not have a firmware release until maybe the first half of January.
@kerrsmith,
When received your scope can you run the above software against a sample and post your result here. We are dying to see if Rigol fixed the ADC chaos clock problem. Thks.
@Bud
I am not sure I will be able to be of much help as my signal generator has decided to stop working - instead of a sine wave it now outputs a highly distorted square wave...
I am currently working on my own basic signal generator but currently it is in a non-functional state as I am half way through soldering it all together - thought it was a perfect time to do this as I was not really expecting my scope to arrive until early January.
Hopefully someone on the forum will also receive one from the same batch as me and will have the equipment needed to actually run some tests.
@Bud
I am not sure I will be able to be of much help as my signal generator has decided to stop working - instead of a sine wave it now outputs a highly distorted square wave...
I am currently working on my own basic signal generator but currently it is in a non-functional state as I am half way through soldering it all together - thought it was a perfect time to do this as I was not really expecting my scope to arrive until early January.
Hopefully someone on the forum will also receive one from the same batch as me and will have the equipment needed to actually run some tests.
A signal generator is not necessarily the best source anyway unless you know its stability and noise characteristics.
A more predictable generic source would be anything that has a crystal oscillator in it. You could try an Arduino, for example. You could probe the crystal out XTAL2 pin (and hopefully it won't suppress the oscillation with the extra probe capacitance).
And if you don't want to install the drivers with Alessandro's nice program, you could send the capture to me and I'd be happy to run the FFT and post it. Scope settings: Single channel, 1.2MPts, 1GS/s, normal acquisition mode.
OK, that sounds like it should be possible then, I did not think of using my Arduino.
Hopefully the scope will arrive tomorrow and once I have worked out how to do the captures I will have some data I can send to you.
I will dig out the manual I downloaded a while ago and have a read up on how do the captures etc.
<snip>
I just received an email saying my scope was due to be posted out today so I called up Rigol to ask about the AC coupled trigger mode bug and the jitter issue as I had not seen any mention of a fix on this thread.
I have been told by a very helpful member of staff that they have just received a batch of scopes that have been flown over directly to the UK and they all have a new firmware on them which fixes these issues.
Of course, they could also have changed the PLL filter components as well as installed new firmware... so just because they have fixed scopes coming out of the factory doesn't necessarily mean the new firmware will fix the problems for the rest of us
My scope is still enjoying its vacation in Beaverton. Maybe Chris has some news for us.
I've gone back to my waveform reader for these clock analyses, and I've been able to develop some heuristics to identify the raw data bytes instead of manually looking at a dump of hex bytes. It works for all the files I have, which in the grand scheme of things, isn't many.
Thought I'd post it if it can be of any use to others. Save it as "rig_read.m".
It's written in Octave, which is somewhat of a cross between Basic and APL, and should run in matlab also. For anyone who's interested in installing Octave:
http://wiki.octave.org/Main_PageThis is NOT a generalized utility, so no complaints please. It was written to deal with our clock investigation. Suggestions or improvements, however, in the form of code snippets are welcome.
Alessandro: Does your utility only go at the SCPI port or can it read files too?
function [t, v] = rig_read(name, over_read = -1)
#
# v0.3 - MarkL @ eevblog, Dec 18, 2014
#
# Quick and extremely dirty read of rigol waveform (.wfm) dump
# files. Throw-away code written for sample clock analysis.
#
# Returns time and raw ADC values in two N-row arrays.
#
# Example usage:
#
# [t,v] = rig_read("NewFile5.wfm");
#
# Assumes:
# One byte per data point (acquisition mode "Normal")
# One channel enabled
# 1GS/s or 2GS/s, depending on model
#
# Debugging and verifying data:
#
# If over_read is not 0, over_read bytes will be read before and
# after (if possible) the calculated start and end of data. When
# the returned waveform is plotted, the extra bytes can be examined
# to verify the correct start and end has been calculated since the
# extra bytes before and after (if any) should appear as garbage.
# Example:
#
# [t,v] = rig_read("NewFile5.wfm", 20);
# plot(v(1:100)) # valid data should start at point 21
#
# If there's data past the calculated end, the following *may*
# show garbage bytes after the data:
#
# plot(v(end-100:end))
#
# Setting over_read to anything, even 0, also disables interleave.
# This prevents interleave from creating garbage if the data
# start/end are wrong, and also allows you to check for the
# discontnuity which should appear in the exact middle of
# pre-interleaved data:
#
# [t,v] = rig_read("NewFile5.wfm", 0);
# plot(v(end/2 -9: end/2 +10)) # discontinuity at point 10 to 11
#
#
# Runs in Octave, but should run in matlab too.
#
# Disclaimer: This program is NOT the proper way to read these files
# and has only been tested on a limited number of waveform files.
#
f = fopen(name, "r");
if (f < 0)
fprintf(stderr, "%s: file open failed\n", name);
return
endif
# Figure out the file size.
#
fseek(f, 0, SEEK_END);
fsize = ftell(f);
frewind(f);
fprintf(stderr, "file size %d bytes\n", fsize);
# The model name is somewhere in the first 24 bytes. So far, two
# possible file formats have been encountered.
pre = fread(f, 24, "uchar");
if (strcmp(char(pre(5:7)'), "DS2"))
# First file format.
#
model = "DS2";
else
# Second file format.
#
# Convert to string and get rid of trailing zeros with sprintf()
#
model = sprintf("%s", char(pre(9:24)));
endif
fprintf(stderr, "model: %s\n", model);
skip = -1; # bytes until data start, -1 means not computed yet
interleave = 0; # perform interleave when done
switch (model)
case { "DS1054Z", "DS1104Z" }
# Raw data runs to the end of the file. Work backwards by
# comparing the file size against the number of points possible
# that the scope can store.
#
# An extra 512 points always seems to get stored at the tail.
# Sometimes it's ok, and sometimes it appears to contain
# out-of-sync waveform data in the middle of it starting at
# various offsets. Just drop the last 512 bytes since we don't
# know. Maybe it's a leftover buffer.
#
bytes = guess_points_ds1k(fsize);
skip = fsize - bytes - 512;
sample_hz = 1e9;
case "DS2"
# Look for a possible number of data points and try to match it
# to the file size assuming we started reading from that point.
#
# A pointer to the data start seems to live at 0x00f0.
#
fseek(f, 0x00f0);
possible_skip = fread(f, 1, "uint32", "ieee-le");
# After that, there's other stuff but the number of data points
# seems to always land on a 16 byte boundary. We just don't
# know which one so check a range to see if there's a
# combination that works out to the right file size.
#
for offset = 0x100:0x10:0x170
fseek(f, offset);
bytes = fread(f, 1, "uint32", "ieee-le");
if (possible_skip + bytes == fsize)
# heuristic matched
skip = possible_skip;
# assume DS2k
interleave = 1;
sample_hz = 2e9;
break;
endif
endfor
otherwise
fprintf(stderr, "model %s: unknown\n", model);
return
endswitch
if (skip < 0)
fprintf(stderr, "sorry, no heuristics matched\n");
return
endif
# Hopefully it's all figured out at this point. Extract the data
# bytes.
if (over_read == -1)
# over_read was not set by the user
over_read = 0;
else
# over_read was set
if (interleave)
fprintf(stderr, "warning: over_read set; interleave disabled\n", over_read);
endif
interleave = 0;
endif
skip = skip - over_read;
bytes = bytes + 2*over_read;
fprintf(stderr, "raw data %d (0x%04x) to %d (0x%04x)\n", skip, skip, skip+bytes, skip+bytes);
# Skip to start of data bytes.
#
fseek(f, skip);
# Read bytes until end of the file.
#
[v,c] = fread(f, bytes, "uchar");
# [v,c] = fread(f, Inf, "uint16", "ieee-be"); # not used
# [v,c] = fread(f, Inf, "uint32", "ieee-be"); # not used
fclose(f);
if (c != bytes)
fprintf(stderr, "warning: end of file reached: couldn't read last %d bytes\n", bytes - c);
endif
fprintf(stderr, "read %d data points\n", length(v));
if (interleave)
# Two channels alternately sample the signal, but appear in the
# data as a full channel record, then the other. Re-interleave
# them as alternating bytes, like so:
#
# AAAABBBB --> ABABABAB
#
if (interleave)
fprintf(stderr, "performing data interleave\n");
endif
v = vec( [v(1:end/2), v(end/2+1:end)]' );
endif
# Hard code time array.
#
t = (([0:length(v)-1])/sample_hz)';
endfunction
function n = guess_points_ds1k(size)
# Given the file size, return a guess on how many data points are in
# the file, based on the possibilities in the DS1k series. The
# guess is whatever's closest to the file size.
pts = [12000 120000 1200000 12000000 24000000];
[s, i] = sort(abs(pts - size));
n = pts(i(1));
endfunction
# emacs
# Local Variables:
# mode: text
# End:
Alessandro: Does your utility only go at the SCPI port or can it read files too?
I just grab waveform data from SCPI commands
Version 2.2 works fine with my 1074z
Rigol has created updated firmware for the MSO1000Z and DS1000Z series of scopes in immediate response to the issues found by Dave and the EEVBlog community.
Firmware has passed the engineering and applications tests and is proceeding to the full suite of testing to go into production. We expect the final firmware for the MSO1000Z and DS1000Z series to be released by December 19th with the MSO2000A, DS2000A, and DS2000 firmware to follow and to be available by toward the end of December.
..
So Chris, is Rigol still going to release the final firmware for the DS1000Z series today (19 December)?
If not, when do you think there will be a solution available for those of us who are experiencing 70ns or more jitter?
Maybe a chance to at least reload the previous firmware which was not so bad?
I hope to hear back from you on this soon and with some good news.