New Rigol DS1054Z oscilloscope

[ebastler]

I'm not sure why, but it seems to be somewhat offensive to desire a much longer sweep period than 50s/div. Is it really unreasonable?

Not offensive, of course, but it seems like a scope provides the wrong trade-off between time resolution and ADC resolution for such long-term monitoring tasks. (And it consumes more power than needed, and it is noisy while it sits there logging...)

[frozenfrogz]

Taking a webcam to record the screen of a DMM and using OCR to convert video input to CSV seems more reasonable than using a digital scope for voltage logging xD

As mentioned before, there are quite a number of cheapish DMMs with a serial port for data logging. On a very tight budget you could take a Uni-T / Vichy and hack the serial connection into it. There are a couple of threads on these. I would prefer that over the oscilloscope solution.

[JPortici]

I'm not sure why, but it seems to be somewhat offensive to desire a much longer sweep period than 50s/div. Is it really unreasonable?

fun fact, the Lecroy boat anchor i have over here has 10kS/s as the longest timebase :|
that's a 27 hours long record

[David Hess]

I'm not sure why, but it seems to be somewhat offensive to desire a much longer sweep period than 50s/div. Is it really unreasonable?

fun fact, the Lecroy boat anchor i have over here has 10kS/s as the longest timebase :|
that's a 27 hours long record

Some of the early DSO boat anchors support an external sampling clock so the timebase can be controlled with a convenient pulse or function generator.  An external sampling clock also allows synchronous sampling applications like demodulation.

[RoGeorge]

Where in forum is enhancement suggestion list being kept ?

I would like to add following to it -

Not sure if someone has already covered this but I would like
added into firmware -

...

2) Chart recorder function coupled with PC API. There are times
I need to look at very slow rate events, circuits, that want strip
chart like functionality.

Item 2 another user has suggested to me to use the programming manual
and write code to do this.

Regards, Dana.

I bet such a request will never be added into firmware, but until then you can use this script to log the data:
https://github.com/RoGeorge/DS1054Z_data_logger
'DS1054Z_logger.py' is a Python script that adds Vavg measurement for all the 4 channels of a Rigol DS1054Z oscilloscope, then periodically log the Vavg values in a PC file using a LAN connexion between computer and oscilloscope. No drivers are required to be installed on the PC.

To run the data logger, you must have Python 2.7 installed on your PC. Linux usually have it installed by default. For Windows, download and install Python 2.7 from Internet (https://www.python.org/downloads/). After you have Python 2.7, download and unzip the https://github.com/RoGeorge/DS1054Z_data_logger/archive/master.zip . Go to the place where you unzipped it. Connect your PC and your oscilloscope to the LAN.

Assuming your oscilloscope have the IP address "192.168.1.7", type in the command line:

Code: [Select]

python DS1054Z_logger.py 3600 192.168.1.7
This will measure the Vavg voltage once per hour (3600 seconds), display the data and log it into a CSV file. To end the logging, press 'ESC'. If you want to make a chart, open the CSV data with any spreadsheet program, like Open Office Calc (recommended because it is free) or Microsoft Office Excel.

[metrologist]

Thanks a ton.

This worked flawless too.

https://rigol.desk.com/customer/en/portal/articles/2270585-simple-excel-2010-vba-control-program-for-all-oscilloscopes

[Fungus]

fun fact, the Lecroy boat anchor i have over here has 10kS/s as the longest timebase :|
that's a 27 hours long record

I just checked the DS1054Z and it goes down to 40kS/sec at the slowest rate.

With 24Mb of memory that's 10 minutes.

[metrologist]

You could also use segmented memory and get many hours, iirc.

[okurka]

Am I the only one who got a 72 hour trial instead of 36?

[Fungus]

Am I the only one who got a 72 hour trial instead of 36?

Yes.

[Rbastler]

I think I had 36h, but now infinite 

[metrologist]

I'm trying to understand persistence time. I am triggering a 1pps signal and watching 10 MHz slowly drift on the second channel. I was expecting to set persistence time to 500ms  and see two traces after the second trigger, and then the persisting trace would fade away before the 3rd trigger. It looks like a 1sec persistence time persists a trace for 20 seconds, 500ms persists for 11 seconds, and 100ms persists for 3 seconds. 

[boggis the cat]

I'm trying to understand persistence time. I am triggering a 1pps signal and watching 10 MHz slowly drift on the second channel. I was expecting to set persistence time to 500ms  and see two traces after the second trigger, and then the persisting trace would fade away before the 3rd trigger. It looks like a 1sec persistence time persists a trace for 20 seconds, 500ms persists for 11 seconds, and 100ms persists for 3 seconds. 

That seems odd.  Triggering issue?  Averaging mode set?  'Auto' trigger set instead of normal?

I think these modes have the usual behaviour of holding each trace for the set persistence time.  If the 'scope sample rate / triggering were producing ten traces per second then you would always have ten traces present, with the first one displayed having 'faded' the most.  If your trigger is working correctly then you should be getting a new trace each second, and it should fade out over the set persistence time.

(I don't have this 'scope, so perhaps this is incorrect.)

[JPortici]

I'm trying to understand persistence time. I am triggering a 1pps signal and watching 10 MHz slowly drift on the second channel. I was expecting to set persistence time to 500ms  and see two traces after the second trigger, and then the persisting trace would fade away before the 3rd trigger. It looks like a 1sec persistence time persists a trace for 20 seconds, 500ms persists for 11 seconds, and 100ms persists for 3 seconds. 

IIRC persistence in this scope (and in many DSOs) is calculated using trigger events rather than time. don't know why it's still expressed in seconds but still..
this is something i read in another thread -> https://www.eevblog.com/forum/testgear/is-the-rigol-ds4000-trace-persistance-operaton-correct/
I made a note on investigating this issue with all the scopes i can get access to

[metrologist]

Thank you for your investigation, and what a coincidence, that other thread! I think it should work a bit different as I described. I no longer expect the trace to fade during Wait for trigger mode, but the persisting trace should not be present on the next trigger when the elapsed time has expired.

For example, if I set a persistence of 1s and a trigger happens every second, the trace should either persist just once (not for 20 seconds), or maybe not at all as that is a threshold condition. If I set the persistence in this case to anything less than 1s, then there should not be any persisting trace. If I set it to 5s, then I would expect to see 4 persisting traces (or 5 depending on the threshold). Maybe the resolution of the threshold should be the minimum hold-off time.

[Plasmateur]

I'm still having a bit of a hard time correctly transferring waveform data. It appears I have a sinusoidal wave with correct time steps when plotting the data, however the scaling is completely off and the signal does not oscillate about zero. I have the most recent firmware.

Using a signal generator @ 1MHz 2Vpp to trigger the DS1054Z, I send the following SCPI commands.

Code: [Select]

*RST

Wait 5 seconds

Then, for the next lines of code sent, I wait the same X seconds between each command where X has been varied to be between 50ms per command up to 1000ms per command in an attempt to see if waiting between commands will solve the problem of  receiving the incorrect YIN and YOR values.

Code: [Select]

:TRIG:MODE EDGE
:TRIG:EDGE:SOUR CHAN1
:TRIG:EDGE:LEV 1
:TRIG:EDGE:SLOP POS
:RUN
:TRIG:EDGE:SWE SING
(unit is triggered, wait X seconds)

Code: [Select]

:WAV:SOUR CHAN1
:WAV:MODE RAW
:WAV:FROM BYTE
:WAV:PRE?

Read data which is an array of different parameters. The returned YIN,YOR values appear to be incorrect when applying the following method to reconstruct the waveform.

(Signal_Array - YOR - YREF) X YIN = Waveform with a dt of XIN

Not sure what I'm doing wrong here.

[Karel]

I'm still having a bit of a hard time correctly transferring waveform data.

It's all written in the latest version of the programming guide which you can find here:

http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0386/1/-/-/-/-/DS1000Z_Programming%20Guide_EN.pdf

If you need some example code that demonstrates how to download the waveform data, have a look at the sourcecode of DSRemote:

https://github.com/Teuniz/DSRemote/

[metrologist]

Something that wasn't really obvious to me until I started playing with persistence is that the current channel's trace is overlayed on top of the other traces. 

[Mr. Scram]

After searching Google, I cannot seem to find a satisfying answer to the following question: is it possible to record waveforms on the DS1054Z in a way that they can be exported and played back on a arbitrairy signal generator in any sort of reasonable and usable fashion? Or am I looking for something that I am not going to find?

[2N3055]

After searching Google, I cannot seem to find a satisfying answer to the following question: is it possible to record waveforms on the DS1054Z in a way that they can be exported and played back on a arbitrairy signal generator in any sort of reasonable and usable fashion? Or am I looking for something that I am not going to find?

If you have Rigol AWG you can connect them directly with USB and do that directly between instruments without PC...

[Fungus]

After searching Google, I cannot seem to find a satisfying answer to the following question: is it possible to record waveforms on the DS1054Z in a way that they can be exported and played back on a arbitrairy signal generator in any sort of reasonable and usable fashion? Or am I looking for something that I am not going to find?

That's going to depend more on the signal generator than on the DS1054Z.

A DS1054Z can export data in various formats, you can grab data from a DS1054Z via a cable and use it for things.

So... if your google search term included the word "DS1054Z" then it was probably wrong. 

[Mr. Scram]

If you have Rigol AWG you can connect them directly with USB and do that directly between instruments without PC...

That actually sounds really good. What is this function called? I have searched for 'record', 'replay' and similar terms along with the DS1054Z and the Rigol DG1000Z series, but came up with nothing. Other than someone having a hard time exporting anything at a reasonable speed from the DS1054Z, that is. There does not seem to be a lot of information out there.

That's going to depend more on the signal generator than on the DS1054Z.

A DS1054Z can export data in various formats, you can grab data from a DS1054Z via a cable and use it for things.

So... if your google search term included the word "DS1054Z" then it was probably wrong. 

Yes, it seems that my Google skills are not up to par at the moment. Garbage in, garbage out.

[Mr. Scram]

It seems I found something in the message below. No source of the information, though.

https://www.eevblog.com/forum/testgear/new-rigol-dg1022z/msg1075992/#msg1075992

[2N3055]

It seems I found something in the message below. No source of the information, though.

https://www.eevblog.com/forum/testgear/new-rigol-dg1022z/msg1075992/#msg1075992

What do you mean no source of information...  .... If you connect DS1000Z series scope and DG1000Z series via usb cable you get menu to transfer waveform..
Download manual for DS1000Z  and DG1000Z it is in there.... That's your source..

[Mr. Scram]

What do you mean no source of information...  .... If you connect DS1000Z series scope and DG1000Z series via usb cable you get menu to transfer waveform..
Download manual for DS1000Z  and DG1000Z it is in there.... That's your source..

Sorry, not having the correct terminology made it a bit hard to find. No luck with 'transfer', 'import', 'record', 'replay', or a number of other terms. Eventually, looking for 'USB' led me to the following result in the Rigol DG1022Z manual:

TMC DS: seamlessly interconnect with the RIGOL DS that meets the TMC standard. Read and store the waveform data collected by the DS and rebuilt waveform losslessly.

In the manual of the DS1054Z it is mentioned it is a USBTMC device. It seems the DS1054Z and Rigol DG1022Z should indeed be able to communicate this way. Other AWGs of the same class also appear to possess this capability, though I am unsure of how compatible those actually are.

Thanks for the replies! Having the right terms makes all the difference in the world. It looks to be a really neat feature and rather unfortunate for my bank account