Bug:
When the scope saves CSV data from the "memory" (not from the screen), the increment value is not right and has to be changed manually (Rigol's BUG ?). You must edit CSV file manually and put there sampling rate^-1See wish list item W, at the top of this thread, it's based on this, knows issue.
Bug:
When the scope saves CSV data from the "memory" (not from the screen), the increment value is not right and has to be changed manually (Rigol's BUG ?). You must edit CSV file manually and put there sampling rate^-1See wish list item W, at the top of this thread, it's based on this, knows issue.W is about the file name numbering and the other CSV-related issues are about save speed and the scope refusing to actually write files under some circumstances.
Inside the CSV file, the scope stores the "increment" and in the memory dumps I looked at, that increment is 25X longer than it should be to correctly represent the expected sampling period. If the increment is 10us, I have to set the increment to 400ns (2.5MSPS) when I do math on the data to get the expected result or plot.
Is this a bug? The screenshot below shows a signal input on CH1 (yellow) via 10x probe, and the AUX "Trig Out" from the back panel BNC on CH2 (blue) via BNC patchcord (1x).
I would have expected the Trig Out pulse to be synchronized with the trigger point as indicated on the CH1 trace. Instead there appears to be a delay of about 360 ns. This delay or horizontal offset is constant at about 360 ns, no matter the horizontal timebase setting.
DS1054Z with "firmware" 04.03.SP1
Well, the scope does need some time to process the signal and to confirm that it has met the trigger condition, doesn't it? And then it can't go back in time to set the trigger output signal... I don't see how the behavior could be any different from what you describe, in any digital scope. Clearly not a bug, in my view.
I agree that it's not a bug, there clearly has to be some delay that's a (hopefully) small fraction of the waveform update rate (max of about 40K/sec). It would be nice to have the delay of "about 360 ns" documented but it's nice to know that it's constant.
Recently channel 4 on my DS1074Z (modified to be DS1104Z) has started acting up and measurements are all over the place.
When I try to do self-calibration on the scope, it seems to take forever (I have waited for over 30 minutes) on the ch4 calibration, short video of the "endless operation"
:SYSTem:OPTion:UNINSTall
to the scope by your favorite method)Hi,
Thanks for the suggestion. I followed it (remove options, upgrade firmware), but unfortunately the calibration still never exits the same ch4 calibration sequence (I waited 45 minutes)
I guess I need to try to contact Rigol, and see what their support thinks of the situation..
Sorry to multipost, but here is another one for your list: https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/
Basically, the RAW mode of data acquisition over USB returns garbage, rather than the waveform.
Is the bug list reported periodically to Rigol? How have they responded to this list in the past?
Do they know that it is a joint effort from EEVBlog users?
Did you install/activate the 500uV option? as this does not seem to be supported by the HW and can cause several issues.
Did you install/activate the 500uV option? as this does not seem to be supported by the HW and can cause several issues.
What issues are those?
Did you install/activate the 500uV option? as this does not seem to be supported by the HW and can cause several issues.
What issues are those?
I never tried the 500uV option myself, but from what I heard it caused unstable DC offsets and didn't really work as it should.
Sorry to multipost, but here is another one for your list: https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/
Basically, the RAW mode of data acquisition over USB returns garbage, rather than the waveform.
Sorry to multipost, but here is another one for your list: https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/
Basically, the RAW mode of data acquisition over USB returns garbage, rather than the waveform.
https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/msg724742/?topicseen#msg724742
Basically, the RAW mode of data acquisition over USB works fine if you make sure to download not more than 250000 bytes at a time. DSRemote downloads the whole deep memory waveform data (up to 24Mpts) nicely (when using it with the DS1054Z).
I do agree however, that this workaround is necessary because of a bug in the firmware.
Folks
Here's a weird one I noticed last week out in the field. I've just got back and thought I'd try it out again, both on the MSO1074Z-S and on an Agilent MSO7104B.
There seems to be an anomaly in pattern triggering on both analogue and digital channels.
The synopsis is four digital channels providing a state and one analogue channel a rising edge trigger. The Rigol seems to mis-trigger about half the time.
If I add a fifth digital channel on the same analogue triggering channel and use the digital channel to edge trigger instead of the analogue channel, it works correctly 100% of the time.
Pattern triggering seems to work with one analogue channel edge triggering and one digital channel for state, but any more makes it mis-trigger.
The pattern trigger is:
Ch1 D0=N/A
Ch2 CLK=rising
D7 WE_=0
D6 CAS_=0
D5 RAS_=1
D4 CS_=0
Agilent:
Rigol, analogue trigger channel Ch2, state on four digital channels D4-D7:
Rigol single shot, works about half the time:
Rigol single shot, mis-triggers the other 50% of the time:
Rigol, all digital pattern trigger, using D3 as rising edge CLK instead of Ch2
I have tried adjusting analogue trigger and digital threshold levels and acquisition settings. Interestingly, switching sin(x)/x interpolation seems to make a temporal difference to the trigger when it mis-fires.
I don't know whether to believe this or not but it seems to be edge triggering off both D6 rising and Ch2 rising. Some more fiddling about strongly suggests that the triggering simply isn't being set correctly, with potentially multiple edge triggers.
Using just analogue channels on their own seems OK from the limited amount of testing I just did.
So, the workaround for now is simply to make pattern sources either all digital channels or all analogue channels for pattern triggering.
Edit: Firmware is 00.04.03.SP1, board version 6.1.1.