Low Cost PCB's Low Cost Components

Author Topic: Mechatrommer's Rigol DSO Bug Report Space  (Read 5897 times)

0 Members and 1 Guest are viewing this topic.

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Mechatrommer's Rigol DSO Bug Report Space
« on: February 10, 2016, 10:03:56 PM »
first. rigol support http://www.rigolna.com/tech-support/ space (thanks to Karel) for reporting bug is too small, no attachment allowed etc, so i'm reporting here and then i will link to their report space. i got a reply from Jason Chonko Applications Engineer at Rigol Technologies. he gave me format on how to report... simply..

1) What are you task are you trying to perform?
2) What are you seeing vs. what you expect to see?
3) Can you send me a text version of your code, in the exact order that the commands are being sent?

so i will try as brief and as clear as i can... here i go...

info:
Jason is only for North American Users support, but i guess my problem is global, so if he can pass this msg to Rigol Intl, they can fix the world...
their international website is http://int.rigol.com/

edit: international website doesnt provide bug reporting mechanism or i cant find the link to...
« Last Edit: February 10, 2016, 11:06:01 PM by Mechatrommer »
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol Bug Report Space
« Reply #1 on: February 10, 2016, 10:19:24 PM »
Rigol DSO DS1052E FW 4.2.1 SP1 Bug Report (#1):
symptom:
when downloading data to pc in long maximum memory mode (1MB or 1048576 Bytes) after the scope is triggered and stopped (single mode). the downloaded data (excluding 10 bytes (urrghh 10?) TMC header) is not fully valid. few bytes on the leading and trailing edge (beginning and the end bytes) are garbage. i know DS1000E is near its supported life, but i hope they continue fixing it.. i thought after the so long years from FW 00.02.02 to FW 00.04.02.01 SP1 upgrade, they can catch this bug and fix it, but no, they missed it, so i'm reporting...

symptom persistence/severity:
permanent. reproducible everytime 100%, there seems to be no workaround to get full valid data. not severe as it doesnt interfere with dso functionality...

1) What are you task are you trying to perform?
ANS: download 1048576 Bytes valid signal data to PC for post-processing.

2) What are you seeing vs. what you expect to see?
ANS: garbage data on leading and trailing edge of the returned data buffer. i expect to see full valid data of 1048576 Bytes total.

3) Can you send me a text version of your code, in the exact order that the commands are being sent?
ANS: see attachment. code in VB6. the pictures shows those garbage data
« Last Edit: February 12, 2016, 07:49:38 PM by Mechatrommer »
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #2 on: February 10, 2016, 10:40:05 PM »
Rigol DSO DS1054Z FW 4.3.2.3 SP2 Bug Report (#1):

symptom:
when downloading data to pc in mem. depth auto mem.length maximum memory mode after the scope is triggered and stopped (single mode). the downloaded data (excluding 11 bytes (11? is this standardized already?) TMC header) is garbage interleaved between ch1 and ch2 data (ch1,ch2 only visibility)...

symptom persistence/severity:
after boot, this symptom seems to be reproducible everytime. but after some buttons pressing on the dso, this symptom may dissapear.. not severe as it doesnt interfere with dso functionality...

1) What are you task are you trying to perform?
ANS: download available internal memory data for ch1 only and then ch2 separately to PC for post-processing.

2) What are you seeing vs. what you expect to see?
ANS: garbage interleaved data between ch1 and ch2. i expect to see two separate data for each wav:data? command.

3) Can you send me a text version of your code, in the exact order that the commands are being sent?
ANS: see attachment. code in VB6. the pictures shows those garbage data
« Last Edit: February 12, 2016, 07:45:37 PM by Mechatrommer »
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #3 on: February 10, 2016, 10:57:58 PM »
if anyone can reproduce this bug, or figured out the workaround. feel happy to chime in...
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline Karel

  • Frequent Contributor
  • **
  • Posts: 968
  • Country: 00
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #4 on: February 11, 2016, 06:01:27 AM »
Rigol DSO DS1054Z FW 4.3 SP2:

symptom:
when downloading data to pc in mem. depth auto mem.length maximum memory mode after the scope is triggered and stopped (single mode). the downloaded data (excluding 11 bytes (11? is this standardized already?) TMC header) is garbage interleaved between ch1 and ch2 data (ch1,ch2 only visibility)...

I can't reproduce this bug.
By the way, you shouldn't set the aquire memory depth to auto. You have to select one of the values as described
in the programming guide.  After selecting the memory depth, let it aquire some time, then set it to stop and then download
the data. I tested it on two channels with different signals (one squarewave and one sine wave, different frequencies).
Works fine here, no garbage interleave whatsoever.



The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #5 on: February 11, 2016, 07:35:08 AM »
Rigol DSO DS1054Z FW 4.3 SP2:
I can't reproduce this bug.
Works fine here, no garbage interleave whatsoever.
and you are using the my provided VB6 program attached above? are you on latest FW 4.3.SP2? are you following the exact dso setting provided in Form1.frm?
Code: [Select]

    'DS1054Z (FW 4.3.2.3 SP2) is switched on
    'ch1,2 setting = 10X, 10mV/div
    'ch1 offset = 30mV (0V signal at top screen)
    'ch2 offset = -30mV (0V signal at bottom screen)
    'time is 100ns/div mem depth auto, (500MSa/s, 600pts), acquisition peak
    'ch1,2 is not connected to any probe
    'trigger source is ch1 at 0V level

By the way, you shouldn't set the aquire memory depth to auto. You have to select one of the values as described
in the programming guide.
if using my own words is not that good enough, maybe this is more trusty... fwiw...

« Last Edit: February 11, 2016, 07:41:23 AM by Mechatrommer »
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online ebastler

  • Super Contributor
  • ***
  • Posts: 1153
  • Country: de
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #6 on: February 11, 2016, 08:44:46 AM »
Hi Mechatrommer,
I only had a quick look at your code and did not try to run it so far. Noticed that you don't set the data format (via "WAV:FORM") before you request the data via "WAV:DATA?". The programmer's manual suggests to always set the desired data format explicitly, and does not seem to state a default data format which is used otherwise. Maybe the data format varies, depending on prior command history, if you don't explicitly set it to what you need?
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #7 on: February 11, 2016, 03:59:48 PM »
Noticed that you don't set the data format (via "WAV:FORM") before you request the data via "WAV:DATA?".
we dont have to call it, during startup it will take a default value which according to the DS... is "BYTE" but anyway, to satisfy the request i added the code, see attached the added code with "'XXXX" on the right to note that those are redundant (it should be) lines. and the file output hex values... still interleaved... (min raw data value somewhere around 0x19 and max value around 0xE1) so yeah, it did not help ;) i suggest you startup you dso, set it as instructed in Form1.frm, run the code and send me the file dump "c:\rigol_data.tmp". make sure you have same firmware as me...

The programmer's manual suggests to always set the desired data format explicitly
i dont see it stated anywhere in the DS. maybe under another topic? point me to the page please..
« Last Edit: February 11, 2016, 04:06:41 PM by Mechatrommer »
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #8 on: February 11, 2016, 04:04:09 PM »
for testing this, make sure you on FW...
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline Karel

  • Frequent Contributor
  • **
  • Posts: 968
  • Country: 00
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #9 on: February 11, 2016, 06:44:07 PM »
Rigol DSO DS1054Z FW 4.3 SP2:
I can't reproduce this bug.
Works fine here, no garbage interleave whatsoever.
and you are using the my provided VB6 program attached above? are you on latest FW 4.3.SP2? are you following the exact dso setting provided in Form1.frm?

No, I'm using DSRemote and, yes, I'm using the latest firmware.

By the way, you shouldn't set the aquire memory depth to auto. You have to select one of the values as described
in the programming guide.
if using my own words is not that good enough, maybe this is more trusty... fwiw...

I wrote that because that's the way how DSRemote is doing it.
DSRemote just works. Your software doesn't. Look for the differences.
The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #10 on: February 11, 2016, 07:02:21 PM »
And you don't have to install Linux to look at the DSRemote code. Even if it's not in VB you can see the commands clearly and how things happen on the code.
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #11 on: February 11, 2016, 07:48:04 PM »
No, I'm using DSRemote.
:palm: if someone tell you... help me i cant run linux binary in windows. are you going to tell him... the binary works with me! because i'm on linux!... ?
DSRemote just works. Your software doesn't. Look for the differences.
i dont care about this DSRemote crap. i know i can make safe calls sequence to the DSO and get the right data, but that is "avoiding the bug" method, but because you are avoiding the bug doesnt mean its not there. the bug is "SPECIFIC" to the provided code sequence. and its should not be happening.
And you don't have to install Linux to look at the DSRemote code. Even if it's not in VB you can see the commands clearly and how things happen on the code.
it is not. DSRemote uses different path, namely tmc_dev, i dont know what is tmc_dev and i'm not going to waste my time digging... sorry... afaik, rigol didnt provide official visa driver for linux so i dont know what its using... and i dont wanna hear, install linux thing... i am sorry..
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #12 on: February 11, 2016, 08:36:45 PM »
I think save_data.cpp is pretty clear even if you don't know C++ you can follow the  tmcdev_write(device, ...); commands where the ... is the command itself.
You don't need to know how the tmcdev_write really works, it's just sending those commands to the scope.
Then you can look at mainwindow.cpp to see how is driven.
Also Interface.cpp has other methods (functions) that might be helpful.

I don't have a Linux system (well I do, but have not boot it up for probably one year and it's sitting in one corner gathering dust).

 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #13 on: February 11, 2016, 08:57:47 PM »
thanks miguel for the instruction, but i'll save that for later... fwiw, i developed my own Rigol Control long time ago, quite similar functionality to DSRemote. recently updated to enable connection to DS1054Z, data live stream may reach 7-10 fps on 1ch and 3-5 fps on 2ch, quite slow this DS1054Z. as for older DS1052E, its whooping 60+ fps even on 2 channels active, 100+ fps on 1 channel. but i didnt publish it since mere "remote control" is not that tempting, i can do everything on the scope anyway. except the FFT which i developed separately in C++ dll, 13 windowing option available if you like. phosphor and intensity grading (finite persistence) also simulated in the program way back long before DS1054Z even exist... i have many sw, goltek, rigol capture, bode plotter, recorder etc. you name it, you price it. just so you know..
« Last Edit: February 12, 2016, 04:24:55 AM by Mechatrommer »
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online ebastler

  • Super Contributor
  • ***
  • Posts: 1153
  • Country: de
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #14 on: February 11, 2016, 08:58:02 PM »
i dont care about this DSRemote crap. i know i can make safe calls sequence to the DSO and get the right data, but that is "avoiding the bug" method, but because you are avoiding the bug doesnt mean its not there. the bug is "SPECIFIC" to the provided code sequence. and its should not be happening.

It might not be what you intend, but you come across as somewhat aggressive and demanding, Mechatrommer.

Also, I was assuming that you have a problem getting the data transfer to work reliably. I was prepared to look into your code in more detail, to help you out and to learn something myself in the process. But now it seems that you have a working solution, and this is just about proving that there supposedly is a Rigol bug in response to some specific command sequence. (Which may or may not be "legal" according to the programmer's guide.) I don't think I am interested in that venture. Good luck with it anyway...
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #15 on: February 11, 2016, 09:22:35 PM »
It might not be what you intend, but you come across as somewhat aggressive and demanding, Mechatrommer.
sometime its getting in my nerve actually but i just like to keep in control ;D. i dont demand anything, but the guy seems to not get it and keep advertising his dsremote. as someone said, you need to follow the specific procedure if you want to reproduce it and he didnt do it and add pain to injury saying he worked i dont, of course i dont! i dont care whats work, i only care what doesnt. ;) the workaround to run it in linux is simply out of question. fwiw
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline pascal_sweden

  • Super Contributor
  • ***
  • Posts: 1373
  • Country: no
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #16 on: February 11, 2016, 10:36:26 PM »
I agree. If it doesn't work, Rigol should at least be able to reproduce and should be able to tell why it doesn't work. If it doesn't work because of a design consideration or a limitation, they should indicate this in the programming manual. If there is really no reason why it should not work, they better fix it.

Maybe good for the guys who reproduce, to indicate on which scope, as the OP indicated a problem both on the DS1052E series and on the DS1054Z series. So if you reproduce a specific issue on a specific target, clearly highlight which of the two issues you reproduced on which of the two target devices :)
 

Online ebastler

  • Super Contributor
  • ***
  • Posts: 1153
  • Country: de
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #17 on: February 11, 2016, 11:40:08 PM »
i dont care whats work, i only care what doesnt. ;)
That nicely sums up the difference in our approaches. :P
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #18 on: February 12, 2016, 04:14:19 AM »
this ds1054z visa communication bug is wasting me alot of time, instead of progressing with software development, i have to go back and forth to figure out whats going on and press buttons to see what happen next, SHEET! i'm getting 30 pts data in 5ns/div mode, what?  i dont know which school this rigol software developers have attended to  |O :bullshit:  :rant:
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline hibone

  • Regular Contributor
  • *
  • Posts: 54
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #19 on: February 12, 2016, 10:34:10 AM »
Hello there,

I'm sorry I have not the patience nor the expertize to test your software.
Just a couple of doubt. Could it be an issue with the visa driver? Does the problem remains with a different version?

Also, do the commands reach the other side as intended?
If you input the commands by hand through, I don't know, Matlab, or the Rigol frontend, do the result be the same?

Here I am wondering if by some chance, there is something wrong with the code that maybe is simply ignored by the other scope, and thus it does not lead to any issue.

Maybe it could be something entirely different such as ground loops or something along those lines.

I'm sorry I cannot really be of help, although I got a similar experience with a TI device where I ended the "technician" code snippets to no avail, thus he simply ignored the thread.
Thus I can understand the frustration.

Hope you can solve your issue soon.

 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #20 on: February 12, 2016, 11:42:03 AM »
Rigol DSO DS1054Z FW 4.3.2.3 SP2 Bug Report (#2):

Symptom:
when requesting data from dso during "RUN" state, we receive 30 pts, ie partial data of the screen.

Persistence/Severity:
reproducable everytime. severity: medium-hard for pc software development. non-severe for dso user.

1) What are you task are you trying to perform?
ANS: download data from the screen in RUN state

2) What are you seeing vs. what you expect to see?
ANS: partial data is copied, 30 pts only. i expect 1200 pts of full screen data points.



3) Can you send me a text version of your code, in the exact order that the commands are being sent?

the exact order is as follows:

1) dso connected to pc by usb cable. communication is made with visa32.dll and bundled visa32.bas for VB6 app.

2) in running state (auto or normal).. using dso button, set mem depth to auto (from "acquire" button), set to 5ns/div timescale.

3) activate ch1 and ch2, top screen will show 500MSa/s 30.0 pts

4) from VB app, establish connection using
Code: [Select]
    res = viOpenDefaultRM(defrm)
    res = viFindRsrc(defrm, "USB?*", list, nmatches, matches)
    res = viOpen(defrm, matches, 0, 0, vi)
    hwnd = vi
as outlined by the VB6 code example provided by Rigol.

5) send command ":WAV:MODE MAXIMUM" to switch reading mode. (it is critical to invoke this command, otherwise bug will not reveals itself)

5) press button stop or single on the dso. dso will enter "stop" state.

6) from VB app, download data using command as in the programming guide (PG):
Code: [Select]

":WAV:SOUR CHAN1"
":WAV:DATA?"

or

":WAV:SOUR CHAN1"
":WAV:MODE NORM"
":WAV:DATA?"


7) you will receive 30 pts data. this is expected since PG stated data will be read from internal memory during "STOP" state (maximum 30 pts have been saved).

8> press button run on the dso. dso will enter "running" state.

9) from this on, whenever you send request data ":WAV:DATA?" to the dso, it will return 30 pts (partial data on screen) from "viVScanf hWnd, "%t", bufPtr" function call. changing timescale to any value on the dso, you will still get 30 pts partial screen data..

10) there are 2 ways to remedy this problem...

a) from dso button/knob panel, change to timescale so that it will record more than 1200 pts for eg 200ns/div (1.2Kpts) or 500ns/div (3Kpts), make sure we are still in ":WAV:MODE MAXIMUM", if not, send the command again. press "STOP" and download the data it will be 1.2Kpts or 3Kpts as expected. set the dso to "RUN" mode. the dso will recover and will return 1200 pts full screen whenever ":WAV:DATA?" is invoked.

b) no need to change timebase as (a) leave timescale at 5ns/div or where the problem is. make sure we are still in ":WAV:MODE MAXIMUM", if not, send the command again. set mem depth to other than AUTO (greater than 1200), press stop. download data to pc. press RUN button. download data to pc again, now its ok 1200pts full screen.

11) setting back to 5ns/div (30pts) in running mode. invoking ":WAV:DATA?" request, we will get 1200pts as expected, but not when you do step 5-9 again.

12) close the visa session by using code recommended by Rigol example..
Code: [Select]
    viClose hwnd
    viClose defrm



so...
Q: what you expect to see?
A: i expect to see what has been stated by the Bloody Goat Damned Programming Guide!

« Last Edit: February 12, 2016, 07:45:55 PM by Mechatrommer »
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #21 on: February 12, 2016, 12:47:51 PM »
Just a couple of doubt. Could it be an issue with the visa driver? Does the problem remains with a different version?
there is possibility. so i downloaded and installed the visa latest version 14.1... just now. still the same bug...

Also, do the commands reach the other side as intended?
all commands are replied correctly, except the number of points. so i'm pretty sure the command reached the other end..

Maybe it could be something entirely different such as ground loops or something along those lines.
as said, its very unlikely what you said. a data short of few bytes is not the sign of ground loop problem. it also in check with TMC header 11 bytes ahead... TMC header said... #9000000030... that means 30 points sent, and 30 points it is...

I'm sorry I have not the patience nor the expertize to test your software.
do you need expertise to:
1) switch on your scope
2) connect it to pc using usb cable
3) download my WIndows exe test program
4) run it?
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline hibone

  • Regular Contributor
  • *
  • Posts: 54
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #22 on: February 14, 2016, 12:00:59 AM »
do you need expertise to:
1) switch on your scope
2) connect it to pc using usb cable
3) download my WIndows exe test program
4) run it?


Nope, but it wouldn't be of use either, since i got a DS2072A-S (tweaked to DS2302A-S).
I'm sorry about that.
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #23 on: February 15, 2016, 01:23:39 AM »
Rigol DSO DS1054Z FW 4.3.2.3 SP2 Bug Report (#3):

Symptom:
the converted voltage value in PC from downloaded byte data through usb cable is wrong at smallest V/div ie 10mV/div 10X probe setting. the formulation of V = (0x8E - YORigin - YREFerence) x YINCrement breaks down at this small voltage scale. the returned "WAV:PREamble?" scaling value yinc,yref,yori is wrong, the RAW data downloaded to PC is wrong.

Persistence/Severity:
reproducable everytime. severity: medium-hard for pc software development. non-severe for dso user.

1) What are you task are you trying to perform?
ANS: download data from the DSO in BYTE format and convert it to the correct voltage level as shown on the DSO screen.

2) What are you seeing vs. what you expect to see?
ANS: i'm seeing wrong data, i expect correct data.

3) Can you send me a text version of your code, in the exact order that the commands are being sent?
simply.... you need to be a programmer to see this... send this to your nearest rigol software engineer, let him review back his byte conversion code, and he will know what i'm talking about. i'm tired of preparing free lunch for him.. my code should be completed by now...
« Last Edit: March 26, 2016, 02:13:25 AM by Mechatrommer »
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 7550
  • Country: my
  • reassessing directives...
Re: Mechatrommer's Rigol DSO Bug Report Space
« Reply #24 on: February 20, 2016, 07:24:09 AM »
Rigol DSO DS1054Z FW 4.3.2.3 SP2 Bug Report (#4):

Symptom:

1) using ":WAVeform:MODE MAXIMUM" or ":WAVeform:MODE RAW", in ":TRIG:STAT?" = "STOP" to download raw data (BYTE) from internal memory (not screen).... after downloading the data, we call ":WAV:PRE?" or ":WAV:YOR?" to get Y origin information. the bug is, it always return 0 (zero) even though channel (marker) position on the screen in not in the middle. see picture below which is not tally with the return value of ":WAV:PRE?"

2) Yincrement value may change value (i tried on 10mV/div probe 10X setting) and conversion formula (0x8E - YORigin - YREFerence) x YINCrement is unusable to get correct voltage value. when this happen, Yincrement on the other V/div is still the same, ie broken value. the remedy to this, to get back the correct Yincrement value, is to redo DSO self-calibration.



Persistence/Severity: Nasty

1) What are you task are you trying to perform?
ANS: download data from DSO's internal memory in BYTE format and convert it to the correct voltage value using formula (0x8E - YORigin - YREFerence) x YINCrement given by Rigol Programming Guide.

2) What are you seeing vs. what you expect to see?
ANS: i'm seeing wrong data, i expect correct data as stated in the PG.
« Last Edit: February 20, 2016, 07:25:43 AM by Mechatrommer »
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf