New Rigol DS2000-S series with built-in dual-channel 25-MHz AWG

[mrflibble]

Regarding the possibility of a "remote UI": that prompts curiosity as to opportunities for adding a minimal external controller box with whatever UI knobs etc one might prefer... say an Arduino via USB or Ethernet.

Yup, had pretty much the same idea. I do something similar for my own scpi controlled little projects. I've only recently started doing this, but so far I like it ... for the most part. STM32 + chibios + libscpi + caffeine == controlling your project with scpi commands over serial and ethernet. Latest thingy is some simple PWM stuff for testing H-bridges. So setup duty cycle, frequency, ramps, triggers and all that over SCPI. And the "front panel" right now consists of a couple of knobs + buttons.

The part I don't like? The libscpi I use right now is very basic. But hey, for now it is almost good enough and doesn't have me looking too often at writing my own lex + yacc or antlr based parser or whatever the cool kids use these days. That libscpi is still strncasecmp() galore, but MUST NOT THINK ABOUT IT. Black box. ohhhhhhmmmmmmmm.

Right now I simply echo commands to the serial port. Later I'll reuse a simple qt app from some time ago that did something very similar. As in you press a pretty button in the GUI, and it then sends the appropriate command over serial/ethernet. I have that working on linux and on android tablet for controlling a DDS module. Should also work on windoze, but I haven't checked that build for ages because who the hell cares. Life's too short for windoze builds.

All that to say that, yes, it's pretty doable to make your own control panel. But I will say that I am a bit ambivalent in that regard. Ideally a good scope UI will do all the things I need on the front panel with a minimum of button presses. I do NOT expect a scope like this (or a dedicated signal source for that matter) to have a full math toolbox for signal generation. That is something easier done on a dedicated PC. But the lack of 0-9 digits and nano-micro-milli buttons for quick entry of frequency and such, that is just silly. It probably is a space tradeoff, but still... And the lack of detent when selecting frequency also doesn't sound all that confidence inspiring either. Something like that would indeed prompt me to make an app on the android where you enter the frequency, and then send SCPI command. And probably a couple of frequency presets and all that. I already have that in the DDS controller anyways, so copy/paste ftw.


Anyways, things that I noticed that could possibly do with some attention:
- timestamps for use with segmented memory
- creating waveforms using matlab/whatever and uploading it to the scope. Maybe something with pretty pixels, but I am not much of a GUI person. Command line tends to get the job done faster for me.
- related to segmented memory, downloading all the segments in one fast transfer instead of this slowpoke business of reading a segment into display memory and then readout display memory for each and every segment. Not sure if that is possible, but it's worth looking into. That will require some experimentation as the high quality docs are useless as authoritative source. I think of rigol programming docs more as a "collection of command suggestions that might even do something".

Oh yeah, related to timestamping the trigger ... does anyone know how shitty the jitter is on the trigger out on the DS1000Z? I think I read something like 2 ns jitter best case. So then since you know your instrument it would be 2 ns jitter. Which is pretty bad, but would still be useable for the purpose of knowing when a particular segment was.

The reason I ask ... I would like to be able to combine the DS1000 with my HP scope. Let the DS1000 do the triggering, and then use the trigger out as trigger source for the HP. Basically to combine the large memory of the DS1000 with the better single shot capability of the HP for when I need to look at some fast edges. Maybe this will be shit, maybe not, I don't know until I've tried it. The HP is nice, but the memory size is soooo 1990's. As is the crt and the turbine engine fans.

The scope need an app for the signalgen to be used, I'm not using mine, for me this ui is totally useless.

It's actually not that hard to do if you want to play with SPCI.  I think you can even do it over the network using telnet and without installing any software.

SCPI over telnet looks to be trivial indeed. I recall it being port 6666 but not 100% sure since I don't own one yet, so not committed to memory.

[Rigby]

It's actually not that hard to do if you want to play with SPCI.  I think you can even do it over the network using telnet and without installing any software.

SCPI over telnet looks to be trivial indeed. I recall it being port 6666 but not 100% sure since I don't own one yet, so not committed to memory.

I can't find a way to make this work.  Port 5555 is open when I scan, but telnet doesn't connect.  sadface.jpg.

[mrflibble]

It's actually not that hard to do if you want to play with SPCI.  I think you can even do it over the network using telnet and without installing any software.

SCPI over telnet looks to be trivial indeed. I recall it being port 6666 but not 100% sure since I don't own one yet, so not committed to memory.

I can't find a way to make this work.  Port 5555 is open when I scan, but telnet doesn't connect.  sadface.jpg.

I did a quick check, and it could very well be that it uses ye olde RPC port mapper on port 111. You can use wireshark to check the secret handshake between VISA and the rigol. That way you know what rcp call to do and make your own telnet wrapper with a small C prog or your favorite script language.

[gwideman]

I'm very interested in progress on this! I've seen numerous threads that claim that control via telnet (or at least sockets) should be possible, but I haven't seen a report of it being done, and how to do it.

Really the interest is in being able to carry on the SCPI conversation without a VISA library, to facilitate simple external boxes to be able to talk to the scope.

Thanks for reporting the efforts!

[mrflibble]

I'm very interested in progress on this! I've seen numerous threads that claim that control via telnet (or at least sockets) should be possible, but I haven't seen a report of it being done, and how to do it.

Just send me one and I'll have sockets working for you within 24 hours of delivery. I'll even pay for my own energy drink.

Really the interest is in being able to carry on the SCPI conversation without a VISA library, to facilitate simple external boxes to be able to talk to the scope.

That indeed is the idea.

[Rigby]

Just send me one and I'll have sockets working for you within 24 hours of delivery. I'll even pay for my own energy drink.

I'm actually halfway inclined to give you webcam and remote access to a PC, so you can see the scope visually while you control it via SPCI.  If you're interested in that, let me know and I'll get it set up.  It will take me a couple days to get things going at the least.  Using SPCI in combination with the front panel buttons seems to lock things up (actually anything complex seems to lock it up somewhat) so you'll need someone on hand to power cycle the thing, potentially.

[Mark_O]

The scope need an app for the signalgen to be used, I'm not using mine, for me this ui is totally useless.

It's actually not that hard to do if you want to play with SPCI. 

I think you're confused.  SPCI is the group that got upset with the abuse echen was inflicting on his 1074Z (Society for Prevention of Cruelty to Instruments), during his 'teardown'.    

SCPI is what you were looking for.    Learn it.  Know it.  Use it.  (think, Skippy)

[Rigby]

Yes, thank you.

[Mark_O]

Yup, had pretty much the same idea.

...

Whew!  That was quite the brain dump!

- related to segmented memory, downloading all the segments in one fast transfer instead of this slowpoke business of reading a segment into display memory and then readout display memory for each and every segment. Not sure if that is possible, but it's worth looking into.

It's not possible.    Not on any of the Rigol models.  I've asked Rigol if this is something they could enable, and they said no.

You have to step through and select each frame, before you can send the samples it contains.  Though you're really not reading it into and out of display mem.  It's considerably faster than that would imply.

Oh yeah, related to timestamping the trigger ... does anyone know how shitty the jitter is on the trigger out on the DS1000Z? I think I read something like 2 ns jitter best case. So then since you know your instrument it would be 2 ns jitter. Which is pretty bad, but would still be useable for the purpose of knowing when a particular segment was.

The reason I ask ... I would like to be able to combine the DS1000 with my HP scope. Let the DS1000 do the triggering, and then use the trigger out as trigger source for the HP. Basically to combine the large memory of the DS1000 with the better single shot capability of the HP for when I need to look at some fast edges.

Considering the magnitude of the re-arm time on the Rigols, I don't think a few ns of TriggerOut jitter will be much of a factor at all.  If that's going to be an issue for you, then this is not the tool you're looking for.

[alex.forencich]

It's actually not that hard to do if you want to play with SPCI.  I think you can even do it over the network using telnet and without installing any software.

SCPI over telnet looks to be trivial indeed. I recall it being port 6666 but not 100% sure since I don't own one yet, so not committed to memory.

I can't find a way to make this work.  Port 5555 is open when I scan, but telnet doesn't connect.  sadface.jpg.

I did a quick check, and it could very well be that it uses ye olde RPC port mapper on port 111. You can use wireshark to check the secret handshake between VISA and the rigol. That way you know what rcp call to do and make your own telnet wrapper with a small C prog or your favorite script language.

Smells like it might use VXI-11, which is very common for instruments that support LAN.  If you like python, check out my python VXI-11 driver at http://www.github.com/alexforencich/python-vxi11/.  You should be able to talk tho the device from the Python terminal like so:

Code: [Select]

>>> import vxi11
>>> instr = vxi11.Instrument("192.168.1.xxx")
>>> instr.ask("*IDN?")
'some response'

VXI-11 is quite common and there are definitely drivers available in other languages as well.

[EEVblog]

Oh yeah, related to timestamping the trigger ... does anyone know how shitty the jitter is on the trigger out on the DS1000Z? I think I read something like 2 ns jitter best case. So then since you know your instrument it would be 2 ns jitter. Which is pretty bad, but would still be useable for the purpose of knowing when a particular segment was.

The triggering is analog and comes from your input waveform, so it's going to what it's going to be, right?

[mrflibble]

- related to segmented memory, downloading all the segments in one fast transfer instead of this slowpoke business of reading a segment into display memory and then readout display memory for each and every segment. Not sure if that is possible, but it's worth looking into.

It's not possible.    Not on any of the Rigol models.  I've asked Rigol if this is something they could enable, and they said no.

You have to step through and select each frame, before you can send the samples it contains.  Though you're really not reading it into and out of display mem.  It's considerably faster than that would imply.

Well, crap. I don't have one yet, so I can't muck about to see how fast you can get it. But I did watch marmad's vid on the subject, and there the frame by frame downloading looked damn slow.

Considering the magnitude of the re-arm time on the Rigols, I don't think a few ns of TriggerOut jitter will be much of a factor at all.  If that's going to be an issue for you, then this is not the tool you're looking for.

Not to worry, the effective re-arm time of my HP in this use case is even more. single-shot, slurp waveform over gpib, re-arm.

Smells like it might use VXI-11, which is very common for instruments that support LAN.  If you like python, check out my python VXI-11 driver at http://www.github.com/alexforencich/python-vxi11/.  You should be able to talk tho the device from the Python terminal like so:

Yup, VXI-11 is my guess as well. If only because some discussions about other Rigol gear also talks about them using VXI-11 on their LXI enabled products. I had already found some linux-gpib + agilent code snippets I was going to use, but your python lib might be even easier.

Oh yeah, related to timestamping the trigger ... does anyone know how shitty the jitter is on the trigger out on the DS1000Z? I think I read something like 2 ns jitter best case. So then since you know your instrument it would be 2 ns jitter. Which is pretty bad, but would still be useable for the purpose of knowing when a particular segment was.

The triggering is analog and comes from your input waveform, so it's going to what it's going to be, right?

To a certain degree certainly. But you'd expect the triggering circuit to apply a fair amount of gain (plus clipping) to increase the slewrate into the comparator. Or am I missing something? Entire possible of course. Anyways, it is what it is as you say. I am just trying to find out more accurately "what it is". So I'm interested in hearing about people using the ext trigger in a setup, and if it was useful/crap/some-problems-but-okay.

[gwideman]

I think you're confused.  SPCI is the group that got upset with the abuse echen was inflicting on his 1074Z (Society for Prevention of Cruelty to Instruments), during his 'teardown'.    

Hahahaha -- nice one.  The screwdriver torture inflicted on that poor 1074Z is all the more painful given the current supply shortage.  There are plenty of good homes waiting to adopt one.  :-)

[mrflibble]

I think you're confused.  SPCI is the group that got upset with the abuse echen was inflicting on his 1074Z (Society for Prevention of Cruelty to Instruments), during his 'teardown'.    

Hahahaha -- nice one.  The screwdriver torture inflicted on that poor 1074Z is all the more painful given the current supply shortage.  There are plenty of good homes waiting to adopt one.  :-)

Yeah, that one was particularly painful to watch. That poor scope. I watched that vid before I made my purchasing decision to also go for a 1074Z, but yeah, I promise I will not abuse my scope like that. You know, whenever Rigol decides to provide dealers with more than 1 scope per month or something. 

[Mark_O]

You have to step through and select each frame, before you can send the samples it contains.  Though you're really not reading it into and out of display mem.  It's considerably faster than that would imply.

Well, crap. I don't have one yet, so I can't muck about to see how fast you can get it. But I did watch marmad's vid on the subject, and there the frame by frame downloading looked damn slow.

In that case, you've already seen how fast it can go.  I doubt marmad tossed in some time-wasting code, just for fun.

Actually, on the 1000Z you may be able to go somewhat faster than what you saw.  The reason being that on the DS2000 he was also taking time to query for and retrieve the time-stamp logs.  Since there are none on the 1000Z, you can skip that.  Now while your reaction might be, "That time must be negligible", it may not be.  That's because there are many segments (up to 60,000), and there's overhead and latency involved when asking for and retrieving that small chunk of data, that is way out of proportion to the size of the data. I wouldn't be surprised to see something like a 20%+ speedup, though I could be all wet.  Also, the 1000Z has less data to transfer (24M vs. 56M), so that will speed things up as well.

Still, it's probably going to be slower than you'd like, especially if you capture a large number of frames.