Controlling the Rigol DS1052E oscilloscope from a Linux computer via the usbtmc driver

NOTE: the below tricks how to circumvent a bug in Rigol DS1000 series firmware to read full sample memory via USB to a Linux computer are now obsolete, usbtmc.c in recent kernels (I checked 4.2.5) has been patched already in a better way

Rigol DS1052E model is the lowest one from the DS1000 series, however, as has been discussed on the net, it can be software-upgraded up to DS1152E, i.e. 150MHz bandwidth. Its sampling rate is up to 1GS/s (with single channel, no Math, and short sample memory), 500MS/s routinely. In my view it's a good device for the money and sufficient for most hobby projects.

However, when I tried to control it via computer to be able to automatize measurements and read sample memory, I have observed a bug - the firmware of the scope crashed when reading of long sample memory has been attempted. (Of course, running it with commercial software under Windows was out of question from principle ;-), and I preferred to avoid extensive 3rd party libraries (NI-VISA), to keep it as simple as possible, so I was using the usbtmc kernel driver. It worked with the short sample memory, as described by other authors here and here , but the scope crashed when I attempted a long transfer using :WAV:POINTS:MODE RAW.

After some debugging I have found that the problem lies in the fact, that obviously Rigol DS1000 firmware wants to transfer the whole sample memory at once and is not able to split the transmission to smaller chunks, while the usbtmc.c driver allocates a buffer of only 2048 bytes for the transmission. I would like to acknowledge here the excellent and quick support provided by the Rigol's vendor in Czech Republic SILCON ELECTRONICS, which was very helpful, in particular they provided the most recent firmware and an older documentation, which describes how to ask for the large sample memory using the command :WAV:POINTS:MODE, which was left out in the newer versions of the documentation, but still works with the firmware 4.0.

To circumvent this problem, I have modified usbtmc.c from the original 3.3.5 version, enlarging the buffer to 1MB + 2 pages and increased the transmission timeout.
#define USBTMC_SIZE_IOBUFFER (1032*1024)
#define USBTMC_TIMEOUT 10000

This worked about once in 10 attempts, while in 9 attempts the kernel panicked in swiotlb.c on some issue related to IOMMU. Fortunately this could be solved by changing the second parameter of kmalloc() from GFP_KERNEL to kmalloc(USBTMC_SIZE_IOBUFFER, GFP_DMA), at all places where USBTMC_SIZE_IOBUFFER was needed. I do not understand details of the kernel memory management, but I guessed that GFP_DMA is appropriate for memory to be used by DMA (probably allocates pages in some contiguous, more TLB-saving way, as a side effect, although the kernel documentation writes that it should be used to get memory within the first 16MB of physical RAM for old ISA cards...). It works now, however, I think that this is just a quick and dirty workaround of Rigol's firmware bug, since the scope should be able to split the data transfer to smaller pieces of a size requested by the driver. Just imagine the waste to allocate a 100MB buffer in the kernel space for a higher model! They should fix it!

Later I have found that there is another patch of usbtmc.c , which should provide a workaround of the Rigol's bug; this one seems to do more changes and avoid the huge buffer allocation. However, since my patch worked already, I did not try this one.

I have also improved a simple terminal-like program rigol.c, which communicates with the scope via the /dev/usbtmcX device, to make it more user-friendly and support the large data transfers.

Note: to get permissions to access the /dev/usbtmc0 device file, add a rule to /etc/udev/rules.d like e.g.: SUBSYSTEM=="usb", ATTRS{idVendor}=="1ab1", ATTRS{idProduct}=="0588", MODE="0660", GROUP="pittner"

Here is a brief example how to read the long sample memory:

Recently I found a python prorgam to process the WFM files from USB storage under linux: pyRigolWFM .

Now when this issue is solved, I plan to use the scope (besides the "regular" use) to gather power traces of Keeloq chips and try the side channel cryptanalysis, if I get some spare time to do it.. I hope that even the short 1MS memory of this device will be sufficient for this purpose.

My Electronics page

My hobby page

My main page with e-mail contact

TOP of my family pages