Thread Tools
Sep 18, 2008, 02:03 PM
Registered User
Originally Posted by Mark_O
What if you did a ":TIM:SCAL 500 uS" ?
Let's see what happens ...

RECV 1.000e-03

At least consistent

Isn't the command parser supposed to handle unit suffixes?
I didn't know that this was indeed possible. Section 7.5.1 of SCPI-99
even has examples.

- Werner
Sign up now
to remove ads between posts
Sep 18, 2008, 06:27 PM

Sorry I diappeared. I've been doing other things, as well as polishing up on Ubuntu. Have installed a telnet/ssh server, and am running PUTTY.EXE and WINSCP.EXE (Window's style Explorer via SSH). I'm slowly moving over onto Ubuntu, except for my development tools that I have to use Windows for.

I'm trying to get to grips with issuing commands out to the Rigol now like you are here. That's my next step.

These commands which you're posting to each other back and forth. How are you issuing them please?


ps. RE: this thread parking. I dropped Jim (RCGROUP's Administrator) an email to say 'Hello,' and the 'Man from RCGROUPS,' he say "Yes!!!" I've achived all of our posts in case though, so all of this information here is stored by someone.
Last edited by Alison F; Sep 18, 2008 at 07:13 PM.
Sep 18, 2008, 09:55 PM
Registered User
Originally Posted by wpwrak
so just multiplying the desired value with 0.99 before transmission seems
to do the trick.
I have the eye diagram to prove it :-)

Signal: 1MHz with 30% duty cycle, i.e., 300ns high, then 700ns low.
Rise and fall time 100ns each. (The eye diagrams I've shown before
had a duty cycle of 50%, but this is more interesting.)

The edge falling at 0ns stays low for 600ns (700ns minus half the
sum of rise and fall time), then rises. The edge rising at 0ns stays
high for 200ns (300ns minus edges) and then drops again.

The code that produces the eye diagram is a little chaotic, so it's
not in the repository yet. I hope I'll have time to clean is up and
generalize it this weekend.

- Werner
Sep 18, 2008, 10:25 PM
Registered User
Originally Posted by Alison F
These commands which you're posting to each other back and forth. How are you issuing them please?
To issue low-level commands, I use this script (I call it


from tmc.scope import *
from sys import argv

s = rigol_ds1000c()
for c in argv[1:]:
    if c.find("?") == -1:
        print s.query(c)
# ./ ':TIM:OFFS .000123' ':TIM:OFFS?'
SEND :TIM:OFFS .000123
RECV 1.230e-04
But that's just for playing. My current "real work" application uses the
following script to collect all SDIO (in SPI mode) commands a given
device sends by configuring it to raise a GPIO on the Nth command,
and varying the value of N:

This generates the files sdio-000-0, sdio-000-1, sdio-041-0, etc.

I look at the results either with or I batch-decode them with
this script (e.g., ./ sdio-*):

I've achived all of our posts in case though, so all of this information here is stored by someone.
Great !

- Werner
Sep 20, 2008, 04:56 AM
Registered User
One tidbit I didn't see anywhere in the manual that folks may find useful...

Press and hold any button or knob for a couple seconds (rather than a quick click), and an informative "help" message box will pop up. Multipage Help dialogs can be paged through (fwd/rev) with the Run/Stop and Auto, respectively. Click again to remove it.

Also, most probably already know that in the Storage menu, if you enable ParaSave for BMP and/or CSV files, you will get a parallel .TXT file with the same name as the .CSV (or .BMP) that contains all the current setting parameters. E.g.,

Analog Ch State Scale Position Coupling BW Limit Invert
CH1 On 2.00mV/ 0.00uV DC Off Off
CH2 On 2.00mV/ 0.00uV AC Off Off

Analog Ch Impedance Probe
CH1 1M Ohm 1X
CH2 1M Ohm 1X

Time Time Ref Main Scale Delay
Main Center 100.0us/ 284.0000us

Trigger Source Slope Mode Coupling Level Holdoff
Edge CH2 Rising Auto DC 12.0mV 100ns

Acquisition Sampling Averages Memory Depth Sample Rate
Average Realtime 4 Normal 500.0kSa

This .TXT file will overwrite any other already there, without warning. So if you have a sample1.BMP saved, and later decide to save a sample1.CSV, the .TXT from the second will overwrite the first. For that matter, any corresponding .TXT file you might have will get nuked. So use caution in your file naming.

Lastly, if you disable the annoying Fast-Cal in the Utility menu, as Alison and others did to resolve their discontinuity issue (an early post in this thread), be aware that the scope will drift (as all scopes will) over time. This happens even after it has warmed up, and the room temp remains constant. It's fairly small (about 1 mV over an hour, in my testing), but that mV is internal, so it will show as a 10 mV or 100 mV offset error, depending on your probe setting. And AC coupling will not eliminate it. Fast-Cal eliminates that drift, so if you want to make accurate measurements, you should occasionally toggle Fast-Cal on & off.

(and, yes, I finally got a unit to play with. Er, ahem, "perform professional testing and evaluation"... yeah, that's the ticket. )
Sep 20, 2008, 06:43 AM
Registered User
A couple other observations...

internal (residual) input pre-amp noise (random fluctuations) is ~1 mVpp. By itself, that's not too bad, but since it is internal, that gets multiplied by the probe attenuation factor. So ~10 mVpp in most measurement scenarios. That's with no probe influence (i.e., acting as an RF antenna), either none connected, or with a BNC grounding cap in place.

If you turn Persistence on, you can see it almost fill a 1 division vertical segment.

The noise is very wideband, as can be seen if you examine it with the internal FFT. About -85 to -90 dBv down. Pretty much flat from DC-500 MHz.

Also, if you engage the FFT math option, you immediately lose the LongMemory (512 k/channel) capability. It drops to ShortMemory automatically (and doesn't revert back when you disengage the FFT ). It apparently uses this space for its internal calculations.

There's also a bug in the FFT section... at one point, I thought it was pretty clever, since it beeped, and limited me to a 100 MHz FFT spread, with a 200 MHz sampling rate. That's completely correct.

However, at a later time I was able to get it to go out well beyond the prescribed limit. E.g. at 400 MSa, I was able to go all the way out to 12.5 GHz! That was in Real-Time mode, without ET engaged, though I expect that limit was based on the ET-mode 25 GSa max sample-rate.
Sep 20, 2008, 12:27 PM
Registered User
When saving CSV data to USB, you may want to avoid the LongMemory mode. The analog channel pair gets saved as a 16 MB(!) text file, of exactly 512k lines (plus 2, for headers), which Excel will only be able to read the first 65536 lines from.

It will also take a rather long time to write out that 16 megabyte file. Precisely how long, I can't say. When it took over 2 minutes to hit the first tick mark on the Progress bar (and there are over 10 ticks), I decided not to sit and watch paint dry. But when I peeked in at around the 8 minute mark, it had already finished. So the progress bar wasn't an accurate (linear) indicator.

Also, in another session (where I hadn't stressed it by writing huge data chunks), I discovered it was best NOT to proceed if it reports "File Utility error", when attempting to write.

I have no idea what the problem is, because the memory stick had 100+ MB free, and later attempts worked just fine. But attempting to retry the operation resulted in neither the Busy status, nor another error message. Just an anonymous pause, while it was obliterating everything in memory, followed by a vertical-stripe rainbow screen, and full system lock up.

Power-cycle hard Reset is required at that point, and all I was trying to save was a 1k Setup file. Subsequent tests indicated that simply exiting from the Storage menus and returning was NOT sufficient to clear whatever File Utility problem there was (since I duplicated the system crash again), but it's likely (possible?) that pulling and re-inserting the memory stick would reset the File Utility, and avoid crashing. I'll try that next time.

Oh, BTW, this is with firmware rev. 3.07.01. YMMV.
Last edited by Mark_O; Sep 20, 2008 at 03:52 PM.
Sep 20, 2008, 06:07 PM
Registered User
Originally Posted by Mark_O
When saving CSV data to USB, you may want to avoid the LongMemory mode. The analog channel pair gets saved as a 16 MB(!) text file,
Excellent ! This means we have a way to compare downloads with the
real content of that long memory sample by sample.

Precisely how long, I can't say.
About 14 minutes :-)

- Werner
Sep 20, 2008, 08:42 PM
Registered User
Originally Posted by wpwrak
Excellent !
Well .... here's what I get when I let it save a 1MSa trace containing
a 200kHz ramp:

Interesting things seem to happen at the edge and around zero.
Here's the edge:

A look at the CSV file shows that the time only has three significant
digits. That's why the spacing changes at -0.001. Lots of the samples
just end up at the same x position.

This is the center:

My trigger was set to -4.8us, so this is really happening in the middle
of the memory. Seems that the scope is a little confused about
accessing the two banks. By the way, on the left-hand side, we see
the resolution artefacts again. Sample rate was 400MSa/s.

And this is what I get when I download the waveform. Note that I
zoomed in a little, so that the edges of the acquisition would be
off-screen. Also note that I got 1200000 samples, because the closest
setting is 100ns/div and there are 50 samples per div. So we can only
compare sample by sample at 100MSa/s or below.

This looks more like the output of my function generator. The edge
has the proper resolution:

And also the center looks boringly normal:

The CSV resolution problem can be solved by reconstructing the time
from the settings and the sample number, so it's not completely
useless. You just have to pay attention to what you're doing ...

- Werner
Sep 21, 2008, 11:36 AM
Registered User
I had written:
> it's likely (possible?) that pulling and re-inserting the memory stick would reset the File Utility, and avoid crashing. <

With 2 subsequent "opportunities" to test, I pulled the memory stick each time, and after re-inserting, was able to save without locking up the Rigol. So that's an effective work-around.

Also, my input pre-amp drift stabilized and maxed out at ~10-12 hours, at ~9 mV (90 mV with a 10x probe setting, plus 10 mV of random noise!). Hence the need for periodic Fast-Cals.

Interestingly, the internal noise isn't affected at all by the digital filters, but is quieted a bit by BW limiting. OTOH, Averaging at 16x is extremely effective at dealing with it, with almost 100% neutralization. With Fast-Cal and 16x Averaging enabled, low-voltage measurements with a 10x probe setting can be made with <2 mV uncertainty, which is very good for a digital scope.

(Actually, 8x Averaging works well with NormalMemory samples, 16x with LongMemory and BW limiting, and 32X with Long and no BW limiting, if you find yourself doing low-voltage measurements where the residuals are troubling.

With normal measurements at 500 mV/div levels typically, NONE of these tricks are required with NormalMemory depth. LongMemory tends to act like Peak-Detect, so in that case, even at higher levels, a 4x Averaging can be useful.)

Lastly, not that anyone would put their circuits anywhere near the LCD display of the unit, but bringing the probe into proximity reveals a strong 10 kHz RFI from the screen, that dies off rapidly a few inches away.
Sep 21, 2008, 01:26 PM
Registered User
I spent some more time trying out the RS-232 communications and control system. It uses a normal DB9-F-F "through" cable (no null-modem required), and the baud-rate has to be set correspondingly on both sides (along with 8-N-1). Just send text commands in, get text responses out. Oh, and make sure you enter a line-terminator (LF, ASCII $10) after each one. That way, you can play with making it do lots of stuff remotely.

Except, of course, for the ":WAV:DATA? <src>" commands, which are documented incorrectly in the Rigol User Manual. Not that I'd prefer it to transmit 4x as much data in ASCII .CSV format, but the manual should indicate that binary data is actually transmitted in that situation. Not a comma in sight.

One unfortunate gotcha is that normally you'd want to run it at the fastest speed possible (38.4 kBaud), but it reverts back to 9600 baud every time it's powered down. It's too bad that setting isn't retained in NVRAM. Apparently, you can't overcome this (automatically) in software either (even Ultrascope requires manual intervention).

This is because there's no direct BaudRate setting command (none documented, at any rate), and attempting to use the :KEY:UTIL clicks by starting at 9600, will lose comms the moment you send the command. It may be possible, via some clever programming, to start at 9600, bump it to 19.2k, change rate on the PC to 19.2k, then bump it again, and reset to the final rate of 38.4k.

But even this would be dependent on finding the key-states (menus, etc.) in a prescribed orientation, which may not always be the case. That's the problem with KeyPress-based menuing control systems, and why there always needs to be additional direct-setting commands (like Tek does, and evidently the Rigol-based HP doesn't).

Hierarchical menus are good for human-interfaces, but bad for machine interfaces. The "leaves" at the ends of the tree branches are final commands, and each should have a direct-execute equivalent command. That way, there's no need to traverse the tree to perform a function. For example, to toggle Fast-Cal on and off, ":DO:FASTCAL ON; DO:FASTCAL OFF". Instead, traversing the menu structure would be a rather painful sequence, and you could never be certain you were in the right mode to start. I suppose that's one advantage to using USB comms.

Lastly, I did try the Utility > Preference > Command > TEK. It works, to a degree. I.e., a handful of Tek-style commands are honored (e.g., :CHx, instead of :CHANx; and :DIS in place of :DISP), but most Tek commands I was aware of (from the TDS series 200,1000,2000) don't do anything at all. In particular, :SET? which returns all the setting values at once is rather handy... but doesn't work. OTOH, when in TEK mode, AFAICT none of the RIGOL commands would then work.

This is a documentation situation similar to that for the Printer... document that it exists, but then say asolutely nothing about how it could be utilized. Disapppointing.
Sep 21, 2008, 01:37 PM
Registered User
Two more quick tidbits:

The :HARDCOPY command spits out ~73 kB of binary data very fast, then locks up the unit. It's actually a bit less data than the undocumented :LCD:DATA? command, which dumps the screen in BMP format. (Possibly :HARD is in a PCL compressed format?)

Also, RS232 runs at full speed, which means it could dump a full 1 MB in <5 minutes, at 38.4 kBaud. Of course, all the incrementing, etc. that's done in the USB version would slow it down as well... possibly as slow or slower than the USB comms. But I thought you'd be interested to know, Werner, that it manages to pump out 3,840 bytes/sec.
Sep 21, 2008, 02:22 PM
Registered User
Oh, I forgot to mention...

whenever it sends binary data out over RS-232, the first 4 bytes are the byte count (size of block), in little-endian format. Beyond that, I can't comment on the internal format.

- channel data = 1,024 +4B
- math data = 2,048 +4B
- fft data = 6,144 +4B
- LCD data = 74,880 +4B
Sep 21, 2008, 06:38 PM
Registered User
Originally Posted by Mark_O
Werner, that it manages to pump out 3,840 bytes/sec.
USB still wins :-)

:HARDCOPY and :LCDATA? both get 234kB/s.
:WAVATA? [CHANn] are much slower with 9.7kB/s.
:WAVATA? DIG gets 19.0kB/s.

Where 1kB = 1000 bytes. Counting payload retrieved from the scope,
without USB TMC protocol overhead or the command sent to the scope.

I have to look into what :HARDCOPY does. I had just assumed that it
was a prerequisite for :LCDATA? but that doesn't seem to be right.
By the way, both return exactly 74880 bytes of payload in my case.

I'm in a silly mood today, so I left the wacky smileys on ;-)

- Werner
Sep 22, 2008, 05:23 PM
Registered User

that's very good info to have, and I'm happy to hear that USB is actually faster than serial! (One would hope.) Thanks for all the timing results.

I'm wondering why the channel data is so much slower. Obviously, it's not due to comm. channel constraints, so I assume it must have to do with the firmware code that fetches it for transmission. Does your "counting payload... without overhead" indicate the time stepping through multiple screens for the whole (large) waveform was factored out? If so, I'm a bit surprised it's still so slow. I thought you had indicated that pulling a meg out could be done in ~100 secs.

> "By the way, both return exactly 74880 bytes of payload in my case." <

I went back and checked, and mine did too. Not sure why I thought they differed. The exact data doesn't seem to be precisely the same, though that may simply be because I did them at different times. I.e., :HARD may simply be a synonym for :LCD:DATA? Did yours lock up after the :HARD? Perhaps that was just a fluke on mine (only tried once). I may have done the :HARD with the menus on-screen at the time.

Quick Reply

Thread Tools