Rigol DS1000Z series (ds1054z, ds1074z, ds1104z and -s models) Bugs/Wish List

[ebastler]

some confusion or WTF moment during an attempt to transfer data from ds1000z to my pc... i thought the label at the top is memory depth for 1 channel since enabling the other channel will half the memory, so i thought they must be shared (600 for one, 600 for the other), but it turned out to be even worst (at data dso->pc transfer at least)... rigol, cant you capture 600 pts per channel? so i can have 1.2Kpts memory for both ch1 and ch2 shared? maybe this involve hardware limitation but i'm not sure, i'm just confused with the top memory depth label... and with this shared-half-the-memory, i cant even get the whole screen capture for every channel at this particular setting (during stop mode, pictures below) ..

It seems that in your second attempt (with two channels enabled), you only transferred the first half of the trace on the scope screen to the PC. My guess is that the scope does indeed use 600 points per channel, as advertised. But it transfers both channels in an interleaved way. So you need to transfer 1200 data points to the PC and will have both traces complete.

Could you give that a try? I think your interpretation, and the extrapolation to a "really serious issue", may be incorrect here.

[Karel]

1 channel visible: 24Mpts capture per channel
2 channel visible: 6Mpts capture per channel (12Mpts / 2)
3 channel visible: 2Mpts capture per channel (6Mpts / 3)
4 channel visible: 1.5Mpts capture per channel (6Mpts / 4)

Nope, it's like how it's written in the manual:

1 channel visible: 24Mpts capture per channel
2 channel visible: 12Mpts capture per channel
3/4 channel(s) visible: 6Mpts capture per channel

[Mechatrommer]

It seems that in your second attempt (with two channels enabled), you only transferred the first half of the trace on the scope screen to the PC. My guess is that the scope does indeed use 600 points per channel, as advertised. But it transfers both channels in an interleaved way. So you need to transfer 1200 data points to the PC and will have both traces complete.
Could you give that a try?

i tried that before making the post. i requested available buffer size by using :wav:preamble, returned 600... to avoid frustration and "just maybe" situation, i requested position 601-1200 manually, errk failed, dso returned zero byte...

Nope, it's like how it's written in the manual:
1 channel visible: 24Mpts capture per channel
2 channel visible: 12Mpts capture per channel
3/4 channel(s) visible: 6Mpts capture per channel

maybe thats what happening in the scope. but what is transferred to pc is like my post. i'll try again better code to ensure it is not just an extrapolation... i hope you are right..

[Mechatrommer]

1 channel visible: 24Mpts capture per channel
2 channel visible: 6Mpts capture per channel (12Mpts / 2)
3 channel visible: 2Mpts capture per channel (6Mpts / 3)
4 channel visible: 1.5Mpts capture per channel (6Mpts / 4)

Nope, it's like how it's written in the manual:
1 channel visible: 24Mpts capture per channel
2 channel visible: 12Mpts capture per channel
3/4 channel(s) visible: 6Mpts capture per channel

wait a minute. that is not how its stated... here the exact terms... page 250 or 18-1 (User Guide) page 256 on latest dec 2015 revision also the same..

Analog channel:
standard 12M pts (single-channel),
6M pts (dual-channel),
3M pts (3/4-channel);

optional 24 Mpts (single-channel),
12 Mpts(dual-channel),
6 Mpts (3/4-channel)

it doesnt say "per channel" so it may means like what i mean above..

[Karel]

Nope, it's like how it's written in the manual:
1 channel visible: 24Mpts capture per channel
2 channel visible: 12Mpts capture per channel
3/4 channel(s) visible: 6Mpts capture per channel

maybe thats what happening in the scope. but what is transferred to pc is like my post. i'll try again better code to ensure it is not just an extrapolation... i hope you are right..

If you don't trust Rigol's programming guide, try DSRemote and you will see that it works as described.

[Mechatrommer]

DSRemote? where can i get that? i followed visa programming guide, and that is what i got... i checked on the dso graticule, yes. internal of the dso, its working as your speced, but visa viScanf command sadly returns what is not wanted

[Karel]

DSRemote? where can i get that? i followed visa programming guide, and that is what i got... i checked on the dso graticule, yes. internal of the dso, its working as your speced, but visa viScanf command sadly returns what is not wanted

http://www.teuniz.net/DSRemote/

[Mechatrommer]

that link is the source code, i need Windows executable that can be executed out of the box.

[Karel]

that link is the source code, i need Windows executable that can be executed out of the box.

You don't need to be afraid for Linux. It installs as easy as windows and it comes for free.

So, don't hesitate and try it.

[Mechatrommer]

You don't need to be afraid for Linux. It installs as easy as windows and it comes for free.

linux is not my problem, time is... and furthermore, i need to verify this in windows environment using the provided visa32.dll path...

[Mechatrommer]

hi again, today i retried the bug after dicking around a while with my scope... https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg861267/#msg861267 ... and to my surprise the bug disappeared, i can get the right 600pts ch1 data now while ch2 is active, no interleaved spagetthy bullshit anymore. so i played reboot, download the scope several times, sometime i can reproduce the bug, sometime i can get the scope correct, when its correct, it seems to be correct forever now. i believe it has something with trigger state of the scope. i pretty believe this is intermittent bug, maybe i should get rid of asking the scope goes into "NORMAL" trigger mode and then goes to "SINGLE" and wait until the scope triggered ie "STOP" mode. i'll leave my earlier report as is in case rigol people watching and take this case into consideration.

[Mechatrommer]

and then it reveals another bug. i downloaded both channel 1&2 data that i thought now correct. when i superimpose them, i realized phase shift on ch1 data, its like both of them are not saved/sampled into the internal memory at the same time...ch1 seems to be saved ~120ns earlier... (currently on FW 2.3.11, SW 4.3.2.3 (sp2) BOOT 0.0.1.3)

[miguelvp]

Are you using :WAVeform:XORigin? and :WAVeform:YORigin? on each channel to get the origin time and voltage per waveform?
Also you should query for XINCrement, YINCrement, XREFerence, YREFerence and then depending on the MODE you will need other parameters to make sure you can define the capture correctly.

:WAVeform:PREamble? has all of them combined with extra information as well.

Edit:
But this applies to the channel selected in:
:WAVeform:SOURce

Or do you have another way to get both at the same time? Maybe if you shared your code we can look at what can be wrong.

[Mechatrommer]

:WAVeform:PREamble? has all of them combined with extra information as well.

i dont think it helps. it doesnt have XORigin or XREFerence relative to the other channels. for example XREF ch1 relative to ch2, or another value relative to ch3 etc. for example in my case here, preamble is...

0,1,300,1,2.000000e-09,-3.000000e-07,0,4.281250e-02,0,118          for SOUR:CHAN1 and..
0,1,300,1,2.000000e-09,-3.000000e-07,0,4.230469e-02,-47,120       for SOUR:CHAN2

the difference is in YORi and YREF which is not the above problem (x-axis phase shift) so lets forget Y data. and i dont know what XREF and XORi refering or relative to what? i have -3.000000e-07 XORigin, its -300ns, so i doesnt make sense since time offset in the above picture is 120ns, XREF is useless, its 0. even if i manage to find offset ch1 data in relative to ch2 data. to correctly show them on screen, i have to x-offset either one resulting in... not so nice figure...

[ebastler]

May I suggest that this discussion on troubleshooting the data transfer be moved to a separate thread? Given Karel's repeated statements that he has not experienced any issues in his software, I think it is more likely than not that you are just struggling with the PC programming side, or maybe with unclear specifications of the Rigol side. And in any case, I think the extended troubleshooting discussion is becoming a bit long for this thread, which was meant as a collection of observations and suggestions. It deserves its own thread.

[Mechatrommer]

this thread is about bug wishlist right?

which was meant as a collection of observations and suggestions

i did exactly this, i didnt mean or ask to get it fixed. and then people chime in suggesting noobs solutions. so i chime in again how about someone with a possible fix PM me to ask my source code for peer review? this will be much shorter... i posted here in hope that rigol people can consentrate on this one thread. if i make another thread, it will just dissapear unheard in the middle of the sea...

[ebastler]

this thread is about bug wishlist right?

Yeah, but Rigol's bugs, not your programming bugs. 
(Sorry, couldn't resist...)

[Mechatrommer]

Yeah, but Rigol's bugs, not your programming bugs. 
(Sorry, couldn't resist...)

are you sure? any function calls through visa driver to the dso should be taken cared of by them.. returning bullshit spaghetti or phase shifted data is not suppose to happen in any call sequence, at worst the dso should return 0 byte data.. and fyi, i read through majority of the programming guide, i've done this yesterday, i've done this 5 years ago on my DS1052E.. i hope you have a slight clue about software development...

[alsetalokin4017]

Do these bugs happen using DSRemote on Linux?  I haven't seen them....

[Karel]

and then it reveals another bug.

When I write software, and something isn't working as expected, I always assume that I made an error before pointing
to somebody else. It happened many times to me, that I couldn't find an error in my code till having a look at it again
after a couple of days.

Also, most bugs can be reproduced, at least by a couple of other users with the same device.

[Karel]

There's something strange indeed. I measure a time difference of 100nSec. between the two channels after downloading the data.

The DS1000Z series oscilloscopes contains just one ADC. This means that the four channels are not simultaneously sampled.
Ergo, the horizontal position of channels 2, 3 and 4 are off with 0.25/sf seconds.
But that doesn't explain the difference of 100nS.

[Mechatrommer]

Also, most bugs can be reproduced, at least by a couple of other users with the same device.

1) same code run at 2 different time, produced 2 different output one is correct one is not. the only difference is due to that in the second time, i tinkered the dso earlier. so the code is at fault?

2) its understandable why you cant reproduce my bug because you dont have my code, and i dont ask you to. if you are interested and have the environment then PM me i can give you my code and the exact steps to reproduce it, Windows XP and VB6 is easy to install and use friendly

3) probably your code is not making the call sequence that produce the bug, my code did. so you are on the safe side. its like saying, do it my way, its the only way. fwiw, i havent violated the programming guide and its not been mentioned that, you cant do this you cant do that. if it did, i wouldnt have done that...

[Karel]

I guess you missed my last reply.

[Mechatrommer]

But that doesn't explain the difference of 100nS.

the 120nS is not fixed, its only specific to my earlier case. whatever the exact value is doesnt matter, "time shift" does exist. and the software bugs i reported above, happened during dso trigger state "STOP", either manually pressing "STOP" or "SINGLE" button on the scope, or automated trigger and stop from the SW, but as i said, its intermitent. during running mode and downloading 1200 pts per channel, the time shift is not visible though. so this is not "everytime" scenario...

[Karel]

But that doesn't explain the difference of 100nS.

the 120nS is not fixed, its only specific to my earlier case. whatever the exact value is doesnt matter, "time shift" does exist. and the software bugs i reported above, happened during dso trigger state "STOP", either manually pressing "STOP" or "SINGLE" button on the scope, or automated trigger and stop from the SW, but as i said, its intermitent. during running mode and downloading 1200 pts per channel, the time shift is not visible though. so this is not "everytime" scenario...

I suggest you make a nice bugreport and sent it to Rigol. They don't read this thread.
Let's hope they fix it soon, but knowing Rigol....