Author Topic: Rigol DS1054z - problem getting memory data points (Read 5373 times)

emartine · « **on:** March 08, 2019, 02:10:27 pm »

Hello everyone. I am having trouble getting data out of my Rigol DS1054z scope.
I am using python to send this commands to scope:

:STOP
:WAV:MODE RAW
:WAV:SOUR CHAN1
:WAV:FORM BYTE
:WAV:START 1
:WAV:STOP 250000
:WAV:DATA?

the problem is I get no more than a couple of bytes when i launch the 'DATA?' command, when I should get 250000 points (250000 bytes)..

I am using usb. could this be the cause?
I got 2.4M of samples in my waveform.

Thanks for any help!

Karel · « **Reply #1 on:** March 08, 2019, 03:17:15 pm »

Which OS are you using?

Fungus · « **Reply #2 on:** March 08, 2019, 03:28:13 pm »

Did you stop the 'scope running? RAW only works when it's stopped.

What value does :WAV:STOP? show?

emartine · « **Reply #3 on:** March 08, 2019, 05:03:47 pm »

Yes. first command is :STOP.
Will try the command :WAV:STOP? and report back. I set it at 250000
(Maximum for byte)

emartine · « **Reply #4 on:** March 08, 2019, 05:05:16 pm »

I have tested this in GNU/Linux Arch.
I have also tried it in GNU/Linux Debian under Virtualbox VM using both USB 2.0 and USB 1.0... without luck

Karel · « **Reply #5 on:** March 08, 2019, 06:12:07 pm »

Try the following command in the console:

Code: [Select]

echo "*IDN?" > /dev/usbtmc0; cat /dev/usbtmc0
It should respond as follows:

Code: [Select]

RIGOL TECHNOLOGIES,DS1104Z,DS1ZA170XXXXXX,00.04.04.SP3
cat: /dev/usbtmc0: Connection timed out

Now use the example to send the commands you listed above and see what happens:

Code: [Select]

echo ":STOP" > /dev/usbtmc0
etc.

emartine · « **Reply #6 on:** March 08, 2019, 06:47:15 pm »

Thanks Karel, yes.
I can send commands to the scope without problem.
I can stop, run, single trigger, ask for sample rate, etc.. I get reply without problem..

I even wrote a python program to require memory data in 250000 bytes batches.. (I attach it in case anyone want to see it).
the problem is after I send the :WAV:DATA? command.. I get only a couple of bytes.. not the bytes that the scope reports in the TMC header..

Karel · « **Reply #7 on:** March 08, 2019, 06:59:06 pm »

What happens if you download the memory waveform data using DSRemote? (Save -> Wave Inspector)

emartine · « **Reply #8 on:** March 08, 2019, 07:01:33 pm »

I tried DSRemote but got an error during startup with it latest commit in git.
Seems the app is sending a non recognized command.

HoracioDos · « **Reply #9 on:** March 08, 2019, 07:05:21 pm »

Hi.
I had some trouble connecting to DSO via serial port (usbtmc) in the past. Did you try to do the same via LAN?. You can try lxi-tools. It works fine. Developer is usually in this forum.
https://github.com/lxi-tools/lxi-tools.
PS: You can connect with DSREMOTE via LAN too

Karel · « **Reply #10 on:** March 08, 2019, 07:22:11 pm »

Quote from: emartine on March 08, 2019, 07:01:33 pm

I tried DSRemote but got an error during startup with it latest commit in git.
Seems the app is sending a non recognized command.

Here it works fine using the latest commit. What is the version of the firmware of your scope?

Run DSRemote from the console and check the output to see with which command the error occurs.

emartine · « **Reply #11 on:** March 08, 2019, 09:00:48 pm »

My software version is 04.04.sp3.
Dsremote reports:
on window:
An error occurred while reading settings from device. File read_settings_thread.cpp line 2604.
Can not read device settings.

on log:
tmc_dev write: *IDN?
tmc_dev write: :CHAN1:BWL?
tmc_dev write: :CHAN1:COUP?
tmc_dev write: :CHAN1:DISP?
tmc_dev write: :CHAN1:INV?
tmc_dev write: :CHAN1:OFFS?
tmc_dev write: :CHAN1:PROB?
tmc_dev write: :CHAN1:UNIT?
tmc_dev write: :CHAN1:SCAL?
tmc_dev write: :CHAN1:VERN?
tmc_dev write: :CHAN2:BWL?
tmc_dev write: :CHAN2:COUP?
tmc_dev write: :CHAN2:DISP?
tmc_dev write: :CHAN2:INV?
tmc_dev write: :CHAN2:OFFS?
tmc_dev write: :CHAN2:PROB?
tmc_dev write: :CHAN2:UNIT?
tmc_dev write: :CHAN2:SCAL?
tmc_dev write: :CHAN2:VERN?
tmc_dev write: :CHAN3:BWL?
tmc_dev write: :CHAN3:COUP?
tmc_dev write: :CHAN3:DISP?
tmc_dev write: :CHAN3:INV?
tmc_dev write: :CHAN3:OFFS?
tmc_dev write: :CHAN3:PROB?
tmc_dev write: :CHAN3:UNIT?
tmc_dev write: :CHAN3:SCAL?
tmc_dev write: :CHAN3:VERN?
tmc_dev write: :CHAN4:BWL?
tmc_dev write: :CHAN4:COUP?
tmc_dev write: :CHAN4:DISP?
tmc_dev write: :CHAN4:INV?
tmc_dev write: :CHAN4:OFFS?
tmc_dev write: :CHAN4:PROB?
tmc_dev write: :CHAN4:UNIT?
tmc_dev write: :CHAN4:SCAL?
tmc_dev write: :CHAN4:VERN?
tmc_dev write: :TIM:OFFS?
tmc_dev write: :TIM:SCAL?
tmc_dev write: :TIM:DEL:ENAB?
tmc_dev write: :TIM:DEL:OFFS?
tmc_dev write: :TIM:DEL:SCAL?
tmc_dev write: :TIM:MODE?
tmc_dev write: :TRIG:COUP?
tmc_dev write: :TRIG:MODE?
tmc_dev write: :TRIG:EDG:SLOP?
tmc_dev write: :TRIG:EDG:SOUR?
tmc_dev write: :TRIG:EDG:SOUR CHAN1
tmc_dev write: :TRIG:EDG:LEV?
tmc_dev write: :TRIG:EDG:SOUR CHAN2
tmc_dev write: :TRIG:EDG:LEV?
tmc_dev write: :TRIG:EDG:SOUR CHAN3
tmc_dev write: :TRIG:EDG:LEV?
tmc_dev write: :TRIG:EDG:SOUR CHAN4
tmc_dev write: :TRIG:EDG:LEV?
tmc_dev write: :TRIG:EDG:SOUR CHAN1
tmc_dev write: :TRIG:HOLD?
tmc_dev write: :DISP:GRID?
tmc_dev write: :MEAS:COUN:SOUR?
tmc_dev write: :DISP:TYPE?
tmc_dev write: :ACQ:TYPE?
tmc_dev write: :ACQ:AVER?
tmc_dev write: :DISP:GRAD:TIME?
tmc_dev write: :MATH:FFT:SPL?
tmc_dev write: :MATH:DISP?
tmc_dev write: :MATH:FFT:UNIT?
tmc_dev write: :MATH:FFT:SOUR?
tmc_dev write: :MATH:FFT:HSC?
tmc_dev write: :MATH:FFT:HCEN?
tmc_dev write: :MATH:OFFS?
tmc_dev write: :MATH:SCAL?
tmc_dev write: :DEC1:MODE?
tmc_dev write: :DEC1:DISP?
tmc_dev write: :DEC1:FORM?
tmc_dev write: :DEC1:POS?
tmc_dev write: :DEC1:THRE:CHAN1?
tmc_dev write: :DEC1:THRE:CHAN2?
tmc_dev write: :DEC1:THRE:CHAN3?
tmc_dev write: :DEC1:THRE:CHAN4?
tmc_dev write: :DEC1:THRE:AUTO?
tmc_dev write: :DEC1:UART:RX?
tmc_dev write: :DEC1:UART:TX?
tmc_dev write: :DEC1:UART:POL?
tmc_dev write: :DEC1:UART:END?
tmc_dev write: :DEC1:UART:BAUD?
tmc_dev write: :DEC1:UART:WIDT?
tmc_dev write: :DEC1:UART:STOP?
tmc_dev write: :DEC1:UART:PAR?
tmc_dev write: :DEC1:SPI:CLK?
tmc_dev write: :DEC1:SPI:MISO?
tmc_dev write: :DEC1:SPI:MOSI?
tmc_dev write: :DEC1:SPI:CS?
tmc_dev write: :DEC1:SPI:SEL?
tmc_dev write: :DEC1:SPI:MODE?
tmc_dev write: :DEC1:SPI:TIM?
tmc_dev write: :DEC1:SPI:POL?
tmc_dev write: :DEC1:SPI:EDGE?
tmc_dev write: :DEC1:SPI:WIDT?
tmc_dev write: :DEC1:SPI:END?
Disconnected from device

Thanks!

smithnerd · « **Reply #12 on:** March 08, 2019, 11:31:09 pm »

I wrote a similar shell script, using plain IO redirection, so no dependencies other than a working USBTMC subsystem and dd. This was working with whichever Rigol firmware version was current in Nov. 2017, but have had no need to use it since then. I would have been using Devuan/Debian stable.

This might be helpful with your debugging:

Code: [Select]

#!/bin/bash

CHUNK_SIZE=250000

if [ -z "$3" ]
then
	echo "Usage: $0 chan n_pts filename"
	echo
	echo "Examples:"
	echo "	$0 CHAN1 12000 file.bin"
	echo "	(12000 points from channel 1)"
	echo
	exit 1
fi

# clobber existing file because dd won't (with the options chosen)
if [ -f $3 ] ; then
	rm $3
fi

# open device for R/W
exec 3<>/dev/usbtmc0

if [ $? -ne 0 ] ; then
	printf "Error opening device.\n"
	exit -1
fi

# Select source channel
printf ":WAV:SOUR $1\n"
printf ":WAV:SOUR $1\n" >&3

# Select byte transfer, not ascii
printf ":WAV:FORM BYTE\n"
printf ":WAV:FORM BYTE\n" >&3

# Select deep memory, not screen
printf ":WAV:MODE RAW\n"
printf ":WAV:MODE RAW\n" >&3

remaining=$2
i=0

until [ $remaining -le 0 ] ; do
	# why not wait, just in case?
	printf "*WAI\n" >&3

	# Select start data point
	start=$(((i * $CHUNK_SIZE) + 1))
	printf ":WAV:STAR $start\n" >&3

	# Select end data point
	# 	partial chunk?
	if [ $remaining -lt $CHUNK_SIZE ] ; then
		stop=$((($i * $CHUNK_SIZE) + $remaining))
		remaining=0
	else
		stop=$((($i+1) * $CHUNK_SIZE))
		remaining=$(($remaining - $CHUNK_SIZE))
	fi

	printf ":WAV:STOP $stop\n" >&3

	printf ":WAV:DATA?\n" >&3

	# header
	read -N 11 <&3 header
	size=${header:2}
	printf "\tChunk: $size ($start to $stop, $remaining left)\n"

	# copy chunk of waveform data
	dd <&3 bs=8192 oflag=append conv=notrunc status=none \
		iflag=count_bytes count=$size of=$3

	# increment chunk count
	i=$(($i+1))
done

# close device
exec 3>&-

Karel · « **Reply #13 on:** March 09, 2019, 07:42:38 am »

Quote from: emartine on March 08, 2019, 09:00:48 pm

My software version is 04.04.sp3.
Dsremote reports:
on window:
An error occurred while reading settings from device. File read_settings_thread.cpp line 2604.
Can not read device settings.

on log:
tmc_dev write: *IDN?
<cut>
tmc_dev write: :DEC1:SPI:END?
Disconnected from device

Your scope doesn't respond to the command :FUNC:WREC:ENAB?

Try the command:

Code: [Select]

echo ":FUNC:WREC:ENAB?" > /dev/usbtmc0; cat /dev/usbtmc0
It should respond with:

Code: [Select]

0
cat: /dev/usbtmc0: Connection timed out

If it doesn't respond with 0 or 1, it could be caused by not having installed the option "Record & Playback".
On your scope, go to the menu Utility -> Options -> Installed and make sure you have the following options installed:

"DECODER RS232,I2C,SPI Official"
"MEM_DEPTH 24M/12M/6M Official"
"TRIGGER Timeout,Runt,Window,Delay,Setup,NthEdge,RS232,I2C,SPI Official"
"RECORDER Record/Re-play Official"
"BANDWIDTH 100M Official"

Update:

I uninstalled all options and DSRemote still works fine. So, it doesn't seem to be a problem.

Only thing I can think of now is the following problem in the firmware of the scope that Rigol does not want to fix.
The scope presents itself as an USB 2.0 High Speed device but it uses a packetsize
of 64 bytes. The USB 2.0 protocol specification dictates that highspeed connections MUST use a
packetsize of 512 bytes. Now, some USB host controller chips are "forgiving" and accept the smaller
packetsize. Some USB host controllers are less forgiving and don't accept the too small packets.
You can see the packetsize protocol violation of Rigol when you type dmesg in a terminal after you
connected the scope:

Code: [Select]

usb 3-2: new high-speed USB device number 4 using ehci-pci
  usb 3-2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
  usb 3-2: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
  usb 3-2: New USB device found, idVendor=1ab1, idProduct=04ce
  usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
  usb 3-2: Product: DS1000Z Series
  usb 3-2: Manufacturer: Rigol Technologies.
  usb 3-2: SerialNumber: DS1ZA17040xxxx
  usbcore: registered new interface driver usbtmc

Connect the scope via LAN to see what happens there.

HoracioDos · « **Reply #14 on:** March 09, 2019, 06:33:34 pm »

Quote from: Karel on March 09, 2019, 07:42:38 am

Only thing I can think of now is the following problem in the firmware of the scope that Rigol does not want to fix.
The scope presents itself as an USB 2.0 High Speed device but it uses a packetsize
of 64 bytes. The USB 2.0 protocol specification dictates that highspeed connections MUST use a
packetsize of 512 bytes. Now, some USB host controller chips are "forgiving" and accept the smaller
packetsize. Some USB host controllers are less forgiving and don't accept the too small packets.
You can see the packetsize protocol violation of Rigol when you type dmesg in a terminal after you
connected the scope:

Code: [Select]
usb 3-2: new high-speed USB device number 4 using ehci-pci usb 3-2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 usb 3-2: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64 usb 3-2: New USB device found, idVendor=1ab1, idProduct=04ce usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-2: Product: DS1000Z Series usb 3-2: Manufacturer: Rigol Technologies. usb 3-2: SerialNumber: DS1ZA17040xxxx usbcore: registered new interface driver usbtmc
Connect the scope via LAN to see what happens there.

Hi @Karel. That's why I connect to my DS1054Z via LAN. It's an old issue that many of us have reported to you in the past. I'm perfectly aware that it's not a DSREMOTE problem.

Karel · « **Reply #15 on:** March 09, 2019, 06:49:48 pm »

Quote from: HoracioDos on March 09, 2019, 06:33:34 pm

Hi @Karel. That's why I connect to my DS1054Z via LAN. It's an old issue that many of us have reported to you in the past. I'm perfectly aware that it's not a DSREMOTE problem. I don't know if it's the same case here, but it won't do any harm to try via LAN.

I know. Recently I bought myself a brandnew notebook. I installed the same OS and same software and it's impossible to use
the DS1054Z via USB. LAN works fine. On my desktop pc it works great via USB.
It's a shame Rigol doesn't want to fix that bug.

emartine · « **Reply #16 on:** March 10, 2019, 05:09:20 pm »

Hello everyone.
Karel, yes, I get>
0
cat: /dev/usbtmc0: Connection timed out
when I ask for ":FUNC:WREC:ENAB?".

This is probably that USB bug. Will try with an old computer via LAN and report back.
Thanks for your help.

Karel · « **Reply #17 on:** March 10, 2019, 05:46:53 pm »

Maybe if more people start to write to Rigol and complain about this bug,
then maybe they change their minds and they will do something about it...

emartine · « **Reply #18 on:** March 11, 2019, 12:25:09 pm »

I have tested this in an old computer with usb 2.0 and the scope returns the complete bytes!
Conclusion: there must be something with the usb3.0 interface of my current laptop or that usb bug described above.
$:-\$
Thanks to everyone!

Karel · « **Reply #19 on:** March 11, 2019, 12:39:03 pm »

Quote from: emartine on March 11, 2019, 12:25:09 pm

I have tested this in an old computer with usb 2.0 and the scope returns the complete bytes!
Conclusion: there must be something with the usb3.0 interface of my current laptop or that usb bug described above.
$:-\$
Thanks to everyone!

There's nothing wrong with your laptop. Instead, there's something wrong with the scope.
I reported this bug long time ago (March 2017) to Rigol and their response was:

"the bug is confirmed, but it seems to hard to fix it.
A fix will be implemted in new Models, for older ones, no confirmation to
have a fix available soon."

HoracioDos · « **Reply #20 on:** March 11, 2019, 12:50:59 pm »

Quote from: emartine on March 11, 2019, 12:25:09 pm

I have tested this in an old computer with usb 2.0 and the scope returns the complete bytes!
Conclusion: there must be something with the usb3.0 interface of my current laptop or that usb bug described above.
$:-\$
Thanks to everyone!

It's a simple solution as long as you have this old pc. I would be thinking in a more permanent solution like connecting DSO through LAN to your router or notebook.

Fungus · « **Reply #21 on:** March 11, 2019, 12:58:21 pm »

Quote from: HoracioDos on March 11, 2019, 12:50:59 pm

Quote from: emartine on March 11, 2019, 12:25:09 pm
I have tested this in an old computer with usb 2.0 and the scope returns the complete bytes!
Conclusion: there must be something with the usb3.0 interface of my current laptop or that usb bug described above.
$:-\$
Thanks to everyone!
It's a simple solution as long as you have this old pc. I would be thinking in a more permanent solution like connecting DSO through LAN to your router or notebook.

Yep. If the "laptop PC" hasn't got an Ethernet connector then you could connect the DS1054Z to a router.

alsetalokin4017 · « **Reply #22 on:** March 11, 2019, 01:23:51 pm »

I haven't been able to get it to work by connecting the scope directly to the computer (either desktop or laptops) with a straight or crossover Ethernet patch cable. Plugging the scope into a router or switch works though. My main LAN router sees the scope and allows it to connect to any of the other computers, wired and wireless, on the local net.

DSRemote rocks! It is so cool to be able to display and control the scope from the wireless laptop in a different room.

emartine · « **Reply #23 on:** March 11, 2019, 03:02:04 pm »

Yes, HoracioDos & Fungus. That would be my best option, but I am afraid I would need an ethernet adapter for my laptop.
(this new laptops dont come with LAN adapter

). And my router is far from my bench.. $:-\$

Karel · « **Reply #24 on:** March 11, 2019, 04:24:44 pm »

https://www.amazon.com/Cable-Matters-Port-Ethernet-USB-C/dp/B075NKWPLZ/

No need to install drivers when using Linux, works out of the box.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Rigol DS1054z - problem getting memory data points (Read 5373 times)

Share me