Reading raw data from a Rigol oscilloscope

class-d-testModern oscilloscopes can be used for much more than  just displaying a waveform. With the some programming, you can use it as a logic analyzer, for jitter measurements or run use it as a spectrum analyzer. In a later article I will show how to do jitter measurements with a digital storage oscilloscope (DSO). You can argue that there are instruments that are more specialized for these use cases than an oscilloscope. You’re right. However if you don’t need the all the features and the superior performance of these instruments (like a logic analyzer or a spectrum analyzer), a DSO might be a cheap alternative. For some specific use cases it might be even superior.

Even relatively cheap scopes like a Rigol DS2072 can already sample data with rates of 2GSamples/s which means one sample every 0.5 nanoseconds. The resolution is usually limited to 8 bit, but the first scopes are already available with 12bit resolution. For many use cases, even 8 bit are more than enough.

The basic approach is to let the scope sample into its internal memory with the sample rate you need, then load the data to a PC and do all the post-processing on the PC. My Rigol scope has an internal memory of 56MSamples – that’s a lot.

The example code at the end of this picture shows how to do this with a Rigol DS2xx2 scope. The standard version of this scope has a memory of only 14MSamples. You can upgrade the memory with a license key. However, for most tasks even the 14MSamples are enough.

There are some things you have to do to get the data from the scope and use the full 56MSamples memory:

  • Timing is important
    I had quite some problems getting the program to work. In most cases I was sending new command to fast. If the scope still processes the last command, it ignores new commands.
    In worst case it is not even responding anymore.
    As a rule of thumb I use 100ms delay after every command and one second after some commands like “AUTO”, “RUN” or “STOP”. This has been found by trial-and-error.
  • Activate only one channel if you don’t need the second
    If you use both channels, the sample memory per channel is only the half.
  • Stop the recording
    With live display only 1400 samples are available.

One characteristic I don’t like with this specific Rigol oscilloscope: data transfers over the network are quite slow. I was able to transfer 110kSamples/s over TCP/IP. That means reading out the full memory of the scope takes over 8 minutes! That’s not really fast. If you don’t need all the samples, reduce the number of samples with the “:WAVeform:POINts” command.
Now some example code how to get the data. You will see, that some parts are missing. It should just give you an idea how to do it by yourself. I have programmed my own measurement toolkit. However the code still needs some cleanup, therefore I won’t publish it now. I plan to publish it later. Note that this is not a high-priority task, therefore I can’t say when it will be ready.

def readdata(instrument):
    global samples
    
    line=str(instrument.connection.read(12))
    
    if not line.startswith("#9"):
        raise Exception("unknown data format: {}.".format(line))

    samplecount=int(line[2:11])
    data=instrument.connection.read(samplecount)
    for d in data:
        samples.append(ord(d))
        
    lf=instrument.connection.readline()
    if (len(lf))>2:
        raise Exception("additional data after samples: {}".format(lf))
  
    
def read_from_scope():
    global samples
    global periods
    samples=[]
    
    ins=get_instrument("DS2202")
    print ins.identify()
    
    
    ins.send_command(":AUT")
    time.sleep(2)
    ins.send_command(":CHAN2:DISP 0")
    ins.mem_depth(points)
    ins.set_aquisition_type("HRES")
    time.sleep(2)
    ins.send_command(":CHANNEL1:BWLimit OFF")
    ins.send_command(":CHANNEL1:COUPLING DC")
    ins.send_command(":CHANNEL1:DISPLAY ON")
    
    ins.send_command(":RUN")
    time.sleep(1)
    ins.send_command(":ACQuire:MDEP {}".format(points))
    ins.send_command(":STOP")
    time.sleep(1)
    ins.send_command(":WAVeform:MODE RAW")
    ins.send_command(":WAVeform:POINts {}".format(points))
    ins.send_command(":WAVeform:FORMAT BYTE")
    ins.send_command(":WAVeform:SOURCE CHAN1")
    
    ins.send_command(":WAVeform:RESet")
    time.sleep(1)
    ins.send_command(":WAVeform:BEGIN")
    time.sleep(1)
    starttime=datetime.datetime.now()
    while True:
        stat=ins.send_command(":WAVeform:STATUS?").lower()
        if stat.startswith("idle"):
            ins.send_command(":WAVeform:DATA?",auto_read=False)
            readdata(ins)
            break
        elif stat.startswith("read,"):
            count=int(stat[5:])
            if count==0:
                break
            ins.send_command(":WAVeform:DATA?",auto_read=False)
            readdata(ins)
        else:
            print "unexpected return string"
            sys.exit(1)
    endtime=datetime.datetime.now()
    sec=(endtime-starttime).total_seconds()
    slen=len(samples)
    print("Retrieved {} samples in {} seconds ({}kSamples/s)".format(slen,sec,slen/sec/1000))

Remote controlling instruments using LXI

440px-LXI_Logo.svgA lot of modern lab equipment like power supplies, oscilloscopes, signal generators and many more, have an onboard Ethernet interface and an “LXI” logo. LXI stands for “LAN eXtensions for instruments” and replaces the old GPIB IEEE-488 parallel control bus. You can use this interface to control your instruments remotely from a PC. With LXI Class-A and Class-B devices you can even exchange trigger data over the network. But let’s stick today with the simplest version: Class-C devices. These interfaces provide only remote control features.  The good thing about Class-C: you will find this type even in hobbyist instruments. For example, even the mid-range Rigol instruments today have an LXI interface.

Often the manufacturers provide remote control software (usually only for Windows PCs), sometimes plugins for LabView. The quality of this software is sometimes ok, but often not very good.

However as LXI is an open standard, you don’t need the software of the device manufacturer. You can simply create your own. And if you’re usually working on the command line on Linux or MacOS, it is really simple to use it.

The LXI command protocol is a simple text protocol over a TCP connection. That means you can even use the simple “telnet” command to control your instruments remotely.

Let’s do an example with the DSA815. First, download the Programming Guide from Rigol. Unfortunately this one comes in CHM format which is used in Windows. We need an additional program to read it on other operating systems. On MacOS iChm does the job.

Now, connect to the instrument using the telnet command line tool. The port on Rigol instruments is 5555, which is easy to remember. With other vendors the port might be different, check your manuals.

$ telnet 192.168.1.126 5555
Trying 192.168.1.126...
Connected to 192.168.1.126.
Escape character is '^]'.
*IDN?
Rigol Technologies,DSA815,DSA8A154402661,00.01.07.00.01

Seems to work. The “*IDN?” command is a standard command that is implemented by all LXI instruments and returns the ID of the instrument.

Do you want more? Ok,  lets do a frequency response plot from 100 kHz to 10 MHz using the internal tracking generator.

# enable tracking generator output
:OUTP 1
# average 1000 measurements
:TRACE:AVER:COUN 1000
# frequency range from 0 to 10 MHz
:SENSe:FREQ:START 10000
:SENSe:FREQ:STOP 10000000

You can do similar things with oscilloscopes, multimeters and function generators. This allows very powerful automated measurements as you can control different instruments from a central console. Note that while the protocol is standardized, the commands are not. Therefore you have to check the manual from your vendor.

You want to do even cooler things? Have a look at this article from Ken Shirriff. I will also show how to to jitter measurements down to 1ns with a mid-range Rigol scope.

HP 8903B repair

I really like my HP8903B audio analyzer. While PC based systems can outperform it in some areas, I like the robustness and simplicity of this standalone device. However it failed with “Error 14″. The analyzer is almost 20 years old, this can happen.

The modular design makes debugging relatively easy. After removing the analog front-end card, the analyzer worked again. Ok, there is a problem with this card. Looking at the card there was no obvious problem. Further debugging showed the one rail of the analog power supply was out-of-spec 13V instead of 15V. Looking at this on the oscilloscope showed a huge amount of ripple. At this point it was obvious that at least a capacitor in the power supply had a problem. There are 3 huge capacitors in the power supply, 2 for the analog +/-15V and another one for the digital 12V and 5V. Checking these capacitors showed that one of them was defective. Have a look at these huge parts. I replaced them with more modern caps (the black ones in the picture):

capacitors

The replacement was done in a few minutes, as these are screw-in capacitors. There is no need to solder anything.

hp8903b-caps

Looking at the picture now I think, I should also clean the device ;-)

Was this the root cause of “Error 14″? Let’s power it on again:

hp8903-raspberry

Yes, it is working again – great. If you ever get this error with your HP8903, check the power supply first.

QuadVol PCB design files

quadvol-acryl-squareSome users asked why the QuadVol board is not on stock anymore. Unfortunately I don’t have much time to support users of this board, therefore I won’t produce it anymore. However, I release the PCB design files for this project under the Creative Commons Attribution-ShareAlike 4.0 International License. You can download them here: quadvol.zip

Creative Commons License
QuadVol by Daniel Matuschek is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Based on a work at http://www.crazy-audio.com/projects/quad-volume-control/.

Sound quality of the Raspberry Pi B+

It is no secret that the sound quality of the onboard sound of the Raspberry Pi is not really good. Last week the Raspberry Pi foundation announced a new model B+ that is improved in some details. One aspect that was pointed out was the sound quality. It should be better with the new model. I was curious, therefore I ordered some new model B+ Raspberry Pis.

raspberry-bplus

What changed on the audio section? According to the Raspberry Pi foundation, there is an additional voltage regulator for the audio output and an additional output driver to drive low-resistance loads like headphones. However it is still using pulse-width modulation (PWM), which has a major impact on sound quality. The output voltage is still very low. I’ve measured less than 0.4Vrms. But let’s see how other performance parameters changed.



The test setup is as follows: The Raspberry Pi is connected to the network with a UTP cable. This reduces noise coupled in from the Ethernet port. Total harmonic distortions + noise (THD+N) is measured by a special HP8903B audio analyzer. This specialized instrument is able to measure THD+N down to 0.002% and allows also to measure the output voltage to test the linearity of the output. The input impedance of the audio analyzer is 100kOhm. The Raspberry Pi is powered by an external linear power supply.

For THD+N measurements the measurement bandwidth is 30kHz, for the frequency response we used 80kHz bandwidth to make sure that the instrument’s filter does not impact the audible frequency range.

hp8903-raspberry

On the Raspberry Pi, the volume was set to the maximum volume that works without clipping:

amixer sset "PCM" 95%

Test tones were created using SoX. Note that I’m not sure if SoX itself creates optimal sine waves. Therefore a minor part of the distortions might also com from the sine generator. However they will be are in the range < 0.1%. Also, you should not compare the absolute figures here to other measurements. While the HP8903B audio analyzer is a very good instrument, lots of factors influence the result. At THD+N levels < 0.1%, slight changes in the measurement setup can have huge impact on the results.

The following diagram shows the sum of the total harmonic distortions and noise (THD+N) of the old and the new Raspberry Pi. The lower the values the better the system performs.

rpi-new-thd

What happened here? The new Raspberry Pi performs even worse than the old Model B on frequencies below 1kHz.  As the distortions are driven by the frequency is seems that there is much more noise at lower frequencies. Didn’t they say the audio performance was improved by an additional voltage regulator? Yes, but the old Raspberry Pi used a linear voltage regulator to provide the 3.3V to many of the components on the board while the new one uses a switching regulator. Both can perform reasonably well. However switch mode power supplies often show higher noise figures. I will have a look into this in a later article soon.

Why aren’t there data for frequencies above 15kHz? The PWM of the Raspberry Pi is not able to create a signal that is at least similar to a sine wave at these frequencies. Therefore the audio analyzer was not able to determine the base frequency and therefore could not do any measurements.  Have a look how a 20kHz sine wave looks on the Raspberry Pi output:

20ksine-raspberry

Conclusion: Don’t buy the new Raspberry Pi just to get better onboard sound. You won’t get it. However, there are use cases were the new one is better, e.g. if you need 4 USB ports or low power consumption is important. For high-quality sound you still need an additional DAC like the HiFiBerry DAC.

New Lab PC

I used the last days to rearrange my lab workplace. The goal is it to connect all instruments over ethernet and control them using LXI. Then I remembered that I still had an Atom-powered PC lying around that was once built to implement an active crossover for the whole home theater. Unfortunately this project was never finished. The good thing: The PC was still there. Looking from today’s perspective, the specs are not really overwhelming: a dual core 1.8GHz Atom D525, 2GB RAM. But there are also some goodies: the sound card is an Asus Xonar D1, which performs really well and the system disk is an “old” 240GB Intel SSD (that was my first SSD).

labpcThe Asus Xonar D1 shows some impressive specs: THD+N < -105dB at 2Vrms at the output stage. The input isn’t specified, but I will measure it soon. A nice feature for my use case: The Xonar D1 comes with a half-height bracket and fits the small Antec ISK 300-65 Mini-ITX case.

Running Ubuntu 14, the performance is quite good. The system boots fast and the GUI works smoothly. Now I can start implementing virtual instruments on this system, but also use it as an audio measurement system.

I will start an article series about audio measurements soon to give an introduction to some audio measurements. It will not focus only on PC based measurements, but I want to give a more general introduction.

Audio Measurement Handbook

audiomeasurementhandbookAre you serious about audio measurements? Then the “Audio measurement handbook” by Bob Metzler is a very good introduction to the topic. You can buy used versions of the book on Amazon for more than 200US$ or you can get it for free from Audio Precision. Check out their starter kit. The book is from 1993, however most of the basic measurements haven’t changed. There is only one topic that the book does not cover: measurements of Class-D amplifiers. You can find a white paper about this in the AP white paper archive.

BTW: I will test an APx525 in the next time and compare it to older audio test equipment. Whit a price of >10k$ this is definitely not a hobbyist instrument. It is todays gold standard for audio measurements.