There are only 800 horizontal dots on the screen yet the data comes back as 1200 points. I could see doubles if the dataset was twice the screen size but that doesn't appear to be the case. Sooner or later it is going to come down to the resolution.
Indeed, in the PC extracted points I couldn't reproduce any time shift between channels bug.
Since the first scope screen capture from the bug description shows a "T'D" in the upper left corner, I guess the data was extracted with the scope in the running mode. In running mode, only 1200 points can be saved to PC (the same as the ones from the display). So I saved first 1200 points from channel 1 and 2, then chart them in a spreadsheet. The points from the 2 channels are well aligned in time.
Unfortunately, the time-difference bug as described here:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg862373/#msg862373
and which was reported to and confirmed by Rigol on March 1th, has not been solved with the latest fw 00.04.04
So, downloaded deep waveform data is still defect...
I was looking at the data points within the screen, and I could not reproduce this bug with FW 00.04.04.01.01 (SP1)
Could somebody please help me with some details, in order to reproduce the bug?
- What scope settings must be used(other then the ones that can be seen in the pic)?
- How many data points were extracted?
- At what point(s) can be seen the time difference?
- The data points were retrieved in ASC or Byte mode?
- What SCPI commands were sent in order to retrieve the data points?
tmc_lan write: :STOP
tmc_lan write: :WAV:MODE RAW
tmc_lan write: :WAV:YINC?
tmc_lan write: :WAV:YREF?
tmc_lan write: :WAV:YOR?
tmc_lan write: :WAV:STAR 1
tmc_lan write: :WAV:STOP 250000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 250000 bytes
tmc_lan write: :WAV:STAR 250001
tmc_lan write: :WAV:STOP 500000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 500000 bytes
tmc_lan write: :WAV:STAR 500001
tmc_lan write: :WAV:STOP 750000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 750000 bytes
tmc_lan write: :WAV:STAR 750001
tmc_lan write: :WAV:STOP 1000000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 1000000 bytes
tmc_lan write: :WAV:STAR 1000001
tmc_lan write: :WAV:STOP 1200000
tmc_lan write: :WAV:DATA?
received 200000 bytes, total 1200000 bytes
There are only 800 horizontal dots on the screen yet the data comes back as 1200 points. I could see doubles if the dataset was twice the screen size but that doesn't appear to be the case. Sooner or later it is going to come down to the resolution.
In this scope visible part of trace lenght is 600 points on the screen, not 800. 12 div 50 pts/div
Display Resolution 800 horizontal × RGB × 480 vertical pixel
The resolution of the LCD is 800 horizontal, but the waveform doesn't span the whole width. There is the menu on the right side.
The resolution of the LCD is 800 horizontal, but the waveform doesn't span the whole width. There is the menu on the right side.
Exactly. Unlike the higher-end Rigol models, the onscreen menus can't be hidden, so you don't get the full screen width for trace data.
Exactly. Unlike the higher-end Rigol models, the onscreen menus can't be hidden, so you don't get the full screen width for trace data.
Also higher models do not give full screen width trace when menu is off.
Attached Rigol DS6000 menu off and menu on.
Display TFT resolution 800x480
Menu Off trace lenght is 700 ( 14 div) and menu On trace lenght looks like around 642 (bit under 13 div)
Example in Siglent (SDS1000X and 2000X) trace lenght is 700. (TFT800x480 and 14 div) (with menu, and it is always on)
I found a change I would like to make: It's interesting that the user adds measurements on the left menu, and attempts to delete them on the right menu, but it should be changed.
What would be so wrong with selecting the same item you added again, to delete them?
if in the meantime you change the channel and you press onthe measurement button you won't delete the one you want but rather add a new one.
the real bug/feature miss is that they are still. not. deleted. at. all. only "hidden"
$ cat filter_bandpass.scpi
:TIMebase:MAIN:SCALe 0.002
:MATH:OPERATOR FILTER
:MATH:FILTer:TYPE BPASS
:MATH:FILTer:W1 750
:MATH:FILTer:W2 1250
:MATH:DISPlay ON
cat filter_bandpass.scpi > /dev/usbtmc
Phase and Delay
Anyone else looked into this? Does averaging affect this measurement, and is it possibly this region of phase shift? If I understand correctly, I should be able to duplicate the test with an ~1.3m coaxial delay line and 100 MHz source.
I notice the Rigol counter does not seem to have having a problem measuring 10 kHz with 250 MS/s in your follow-up screen shot.
What I mean, is it correct +180.01 degrees or -179.99 degrees?
usb 1-2: new high-speed USB device number 4 using ehci-pci
usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
usb 1-2: New USB device found, idVendor=1ab1, idProduct=04ce
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: DS1000Z Series
usb 1-2: Manufacturer: Rigol Technologies.
usb 1-2: SerialNumber: DS1ZA17040xxxx
usbcore: registered new interface driver usbtmc