Delayed Sweep "zooms in" on part of a displayed waveform

I have an old Tek scope. A great 50MHz analog beast that was surely the envy of every engineer — well every engineer in 1976 anyway.

Of course, its a Tek so it is built like a tank and has the usual great features — for a 1976-vintage analog scope. One thing it has that is very cool is “delayed sweep.” The idea is that the scope will trigger as normal and then you can pick a fixed time delay and a different time base to actually drive the display. Huh? All that means is that while watching a regular wave form you can “zoom” in on a section of it. The delay tells you how far into the original screen to start, and the faster sweep gives you the zoom factor. The user interface for this is comical but effective. The scope has a special mode where the time delay and “zoomed” time base makes the trace very bright. So you twist the knobs until the part you want to zoom in on is bright and then you can zoom in.

The Rigol DS1102E (or is it a DS1052E? I forget) has the same capability, but being digital it is very simple and the user interface is much more effective. See the screen shot? The top trace shows a 32kHz PWM signal (about 4%) generated, of course, from a GP3. The bottom trace is the “zoom in” — you can pick delayed sweep from the menus or if you are lazy just click the horizontal scale knob (did you know if you press and hold any button you’ll get help — unless you’ve uploaded unofficial firmware).

Once you turn on delayed sweep you get blue bars on the top that show you the part of the wave you are zooming. You can move the trace with the horizontal position knob and change the zoom level using the horizontal scale. Note that the main window (top trace) is at 10uS/division (you can read that near the bottom of the screen). But the zoomed in part is 500nS/division (right under the enlarged pulse).

When you have seen enough, just click the horizontal scale knob again and you are back to “undelayed trigger” or whatever you want to call it. This can be really handy when you are navigating a long buffer. The top view shows you where points of interest in the buffer are, but the bottom view shows you the detail you want.

What would all of this been worth in 1976? My Tek retailed for about US$2500 in its day. Amazing.

GNU Plot streaming GP3 data "live"

Linux has a long history of stringing together data and processing to get new features. With the GP-3 interface board analog and digital “real world” data just become another piece of data to process using the Linux tools.

This article shows you how to string together a GP-3, some fancy shell script, a Perl script found on the Internet, and GNU Plot to make a data recorder that is flexible without writing any actual code.

Well with a digital scope there’s no need for chop mode at all. You just acquire both channels and display both on the screen which, after all, is really a random access device. So what’s alternate mode? Well suppose you are looking at two signals that don’t really have anything to do with one another. What you really want is two scopes, right? One to trigger on one signal and another to trigger on the other. You might not even want the same time scale for each channel. That’s what alternate triggering does. It splits the screen in half and each half is like an independent scope.

For example, see the picture at the head of this article. The top signal is another GP3 JavaScript creation. This one is a good candidate for pulse width triggering. Here’s the code:

io=createGP3();

io.openPort("/dev/ttyS0");

io.setLow(6);

while (1)

{

  io.pulseOut(6,100);

  io.pulseOut(6,50);

}

Just a long pulse and a short pulse over and over again. That's the top signal and a perfect candidate for pulse triggering.

The bottom half of the screen is just the scope's 1kHz calibration signal. No worries using edge trigger there. If you trigger on either signal alone, the other one will go crazy. Notice each half is even using its own time base (200uS/div up top and 1mS/div at the bottom).  But with alternate triggering its like getting two one channel scopes out of your dual channel scope. Of course, you lose some functions (notably delayed trace, a topic I'll cover some other time). But you gain the ability to see two unrelated signals at the same time. 

Captured PWM Pulse Train

The Rigol DS1102E/DS1052E has several interesting features and I thought I’d try to do a few blog posts highlighting the ones I found most interesting. This time, I’m going to show you “pulse triggering”.

If you are used to an analog scope, triggering is pretty simple. The idea is that when the scope sees the voltage go above (or below if you select negative slope) some trigger level voltage, the scope starts its sweep. Once it starts, its going to go to the end. With a digital scope like the Rigol, the instrument buffers traces all the time and when the trigger event occurs, it marks some point in the buffer and then fills in the rest of the buffer. So nominally that trigger point is the center. You can look backwards at what happened before the trigger and forward to what happened after the trigger.

With a digital instrument you can more fun kinds of triggers. So here’s an example of where “normal” triggering isn’t really adequate. Pulse width modulation (PWM) varies a pulse train to have a particular duty cycle. For example, a 50% PWM signal might be “on” for 10uS and “off” for 10uS. This can be used to control a motor’s speed or a lamp’s brightness efficiently, among other things.

The GP3 board is an economical way to convert a serial port (or a USB port with a serial adapter)) into an analog and digital I/O port. There’s 8 digital I/O, 5 analog inputs, a counter, and — what I’m interested in right now — a hardware PWM output. You can actually output “bursts” of PWM on any of the digital ports, but the hardware output just keeps making a PWM signal until you reprogram it or tell it to stop.

You can control the GP3 with most any programming language. There are libraries for C/C++, ActiveX (VB, VBA, etc.), Java, and even more obscure languages. There is also a “point and click” interface (GP3EZ) if you don’t want to do any programming. But for the purposes of this test, I’m going to use the Java library which includes a test program that executes JavaScript. Here’s my JavaScript program:

// Make a PWM "transistion" to show off Rigol pulse trigger
io=createGP3();
io.openPort("/dev/ttyS0"); // this is under Linux, like COM1 on Windows

// hardware pwm

while (1)

{

io.pwm(26,20000);  // about 10% at 20kHz

pause(500);  // wait 1/2 second

io.pwm(191,20000); // about 75% at 20kHz

pause(500);

}

Pretty simple. First the board will kick out a chain of very short pulses and then switch to some very long pulses. Your job, should you decide to accept it, is to examine the time of transition — what happens when the board switches?

Its easy to set this up with the Rigol’s trigger:

Trigger Settings

The 9.47uS isn’t critical. It just needs to be bigger than the small pulses and smaller than the wide pulses. Then push the down arrow and select Single for the sweep type. This will cause the scope to get one trigger, record the data, and stop.

If the Run/Stop button is red then the scope has already triggered (not likely in this case). It should be green, so if it is red, push it so that it is green. Now you can run the JavaScript program (assuming your CLASSPATH is set right, java GP3Script pwmtest.js will do it.

You can see the result at the start of this post. The Run/Stop button turns red and you should see something like the picture. Notice that the trigger point is marked with the T flag. It occurs AFTER it sees a pulse greater than 9.47uS. You can see that the pulse before that was in fact very narrow (the 10% pulse; about 4uS wide). So we did actually capture the exact moment that the board switched from 10% to 75%. Of course there is plenty of data to the left and the right of the trigger if you want to see more of either width pulse.

Don’t forget when using pulse triggering you still need to set the trigger level or the results can be unstable. You want the level high enough up the pulse to keep noise near ground level from triggering it, it seems.

You can select lots of options on the pulse trigger, including when a pulse is greater than a certain width, less than a certain width or equal to a certain width. You can also pick positive or negative pulses. This is a great way to let the scope watch your data instead of having to collect a lot of samples and then try to find the interesting part.

Ultrascope in Action

I recently bought a Rigol DS1102E (um, well… maybe it was a DS1052E and I own a serial cable).

Being a Linux user, I wondered if Rigol’s software, Ultrascope, would work somehow on Linux. The device is USB and it shows up perfectly well as a usbtmc device, so if you want to write your own software on Linux, that’s pretty easy.  But it also means not much chance of Wine running Ultrascope (although maybe with the serial cable; I didn’t try that). However, I have XP running under VirtualBox for just this sort of thing.

I installed the drivers and Ultrascope off the CD. Big mistake. The CD has the service manual on it and the operator’s manual, so don’t throw it away. But don’t install any software off of it either. Here’s what you need:

1) Latest NI Drivers: http://joule.ni.com/nidu/cds/view/p/id/1605/lang/en

2) The Rigol USB drivers have the wrong USB ID or something on Linux is changing the ID (vendor=1ab1,pid=0588 in Linux/VirtualBox, the Rigol.inf file vendor=0400,PID=05dc). Of course, I was so smart, I changed the INF file and got it mostly working. WRONG. Use the NI driver. What that means is in Device manager, it should say “USB Test and Measurement Device” NOT “Rigol USB Test and Measurement Device”. If you already have the Rigol drive installed, do an update driver, tell it to Install from a list and “Don’t search I will choose the driver to install.” If you have the NI stuff installed you should see two choices: Rigol USB Test and Measurement Device and USB Test and Measurement Device. You want the one WITHOUT Rigol in the name.

3) The VISA version of Ultrascope (this was my big mistake, using the “regular” version). See http://www.rigol.com/templates/T_Support_en/resources.aspx?nodeid=639&contentid=1582. Even on a “plain” Vista install the regular version had small issues.

Of course, for Virtualbox, you need to go to the Devices menu and “connect” the Rigol USB device (this one will say Rigol and that’s ok). You can also change your setup to add it automatically, but I’m going to assume you know how to do that.

And the results? Well, Ultrascope is probably of marginal value anyway. You can always dump data files and images to a USB drive right on the scope. I guess if you had a lot of setups, or wanted to use the measurement pass/fail feature. The Memory waveform will let you open the WFM files the scope dumps of waveforms, so I guess that’s something too.

Oh. And I haven’t tried it, but the fact that it is just using the NI VISA drivers tells me it ought to feed LabView with no problems. Of course, you could probably run that directly under Linux too.

Velleman Software on Linux

I like my Velleman PCS500. Its not perfect, but it does a good job and has been my “bench scope” for awhile now edging out my old faithful Tek scope for all but the most demanding jobs. However, there are two things I definitely don’t like about it. It uses a parallel port which many of my computers no longer have and the software doesn’t run under Linux.

When I built my last computer I stuck a cheap PCI parallel card in it. Of course, the PCI bus puts it at some wacky address like 0xE000 and most software can’t find it. I read this article: http://www.lafraze.net/nbernard/doc/misc_tips/velleman.html but it didn’t help either since the I/O wrapper won’t work on “high ports.” For the longest time I’ve just used an old Windows laptop as my “scope” and that’s worked ok.

But today I finally cracked the code to running the software under Linux (see the picture). Here’s what I did:

1) Set the permissions on the /dev/parport0 device to 666 (or you could add your user ID to the lp group and set it to 664 or 660):
sudo chmod 666 /dev/parport0

2) Create a new wine prefix:
WINEPREFIX=~/pcs500 winecfg

3) Inside winecfg set the default operating system to Win98. Close winecfg.

4) Run the wine regedit program. Create a key under HKEY_CURRENT_USER named Software\Wine\VDM\ppdev. Create a string value named 378 and make the value /dev/parport0. This must be under Current User and not System!

5) Download the PCLab2000SE software from Velleman and run setup like this:
WINEPREFIX=~/pcs500 wine setup.exe

6) Finish the install then run pcs500.exe from the ~/pcs500/drive_c/Program Files/Velleman/PcLab2000SE directory:
WINEPREFIX=~/pcs500 wine pcs500.exe

7) If you like, make a shortcut in your desktop software to launch this automatically.

I have noticed the software occasionally hangs up under Wine — don’t know if it is a problem with Wine or a problem with the software, but it doesn’t happen enough to be a problem.

Update: I can’t prove it, but it seems it mostly hangs when you switch away from the main window and then switch back (but not necessarily every time you switch). It actually doesn’t hang per se. You still get a trace, but you can’t work any of the controls. Sometimes if you play around it will respond again but mostly not. Again, I can’t prove it, but setting the main window to always be on top (or “Above Others” depending on your window manager) seems to improve the situation. It doesn’t eliminate the hangs but it seems to make them less frequent.

Hope that works for you!

However, because I like to tinker I’ve also tried a few home-grown solutions. Most of these center on an aquarium pump for air and steel wool for a heat exchanger. I haven’t had good luck with these — maybe because I don’t have the right components or maybe because I’m “spoiled” with real tools.

The truth is, the best “cheap” results I’ve had have been with an $20 embossing gun I got on sale for $10 at Hobby Lobby. If you are handy enough with metal working to get it to accept they cheap Aoyue tips, I think it would be good enough for just about everything and they are cheap enough to replace if you burn one up.

Here’s a homebrew station that looks promising though. It uses part of an old hair dryer and a soda bottle for the air source. I haven’t tried it, but surely it would produce more air flow than what I’ve done in the past.

Another idea is to hack up a “heat gun”. Here’s at least one (plenty of other homebrew SMD irons on the same site).

I really like the Radio Shack boards that are laid out like a solderless breadboard. This is a “game show” style controller produced for a client with a Basic Stamp. The only downside to these boards is that they are one sided and the copper will very easily delaminate if you get it too hot.

Another client project, this one is an H-bridge for motor control, driven by a Basic Stamp and PAK PWM controller.

A board to control HVAC equipment.

This StarFire board (bare and assembled) was a PIC processor used to gather, store, and transmit model rocketry telemetry. I volunteer with a group that lets high school kids learn about engineering by building quite large rockets. The PIC is riding in a socket that allows an in circuit emulator to attach. Note the two RS-1 serial boards attached to produce RS232 ports. One was socketed, so the board could hook to a PC during development, but a TTL-level GPS in flight, if I recall.