Mechatrommer's Rigol DSO Bug Report Space - Page 1
Forum section: electronics / testgear

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 10, 2016, 11:03:56 am
content: first. rigol supporthttp://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 ishttp://int.rigol.com/edit: international website doesnt provide bug reporting mechanism or i cant find the link to...

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 10, 2016, 11:19:24 am
content: 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

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 10, 2016, 11:40:05 am
content: 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

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 10, 2016, 11:57:58 am
content: if anyone can reproduce this bug, or figured out the workaround. feel happy to chime in...

author: Karel
author_rank: Super Contributor
timestamp: February 10, 2016, 07:01:27 pm
content: Quote from: Mechatrommer on February 10, 2016, 11:40:05 amI 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 describedin the programming guide. After selecting the memory depth, let it aquire some time, then set it to stop and then downloadthe 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.

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 10, 2016, 08:35:08 pm
content: Quote from: Karel on February 10, 2016, 07:01:27 pmand 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:'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 levelQuote from: Karel on February 10, 2016, 07:01:27 pmif using my own words is not that good enough, maybe this is more trusty... fwiw...

author: ebastler
author_rank: Super Contributor
timestamp: February 10, 2016, 09:44:46 pm
content: 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?

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 11, 2016, 04:59:48 am
content: Quote from: ebastler on February 10, 2016, 09:44:46 pmwe 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 helpi 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...Quote from: ebastler on February 10, 2016, 09:44:46 pmi dont see it stated anywhere in the DS. maybe under another topic? point me to the page please..

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 11, 2016, 05:04:09 am
content: for testing this, make sure you on FW...

author: Karel
author_rank: Super Contributor
timestamp: February 11, 2016, 07:44:07 am
content: Quote from: Mechatrommer on February 10, 2016, 08:35:08 pmNo, I'm using DSRemote and, yes, I'm using the latest firmware.Quote from: Mechatrommer on February 10, 2016, 08:35:08 pmI wrote that because that's the way how DSRemote is doing it.DSRemote just works. Your software doesn't. Look for the differences.

author: miguelvp
author_rank: Super Contributor
timestamp: February 11, 2016, 08:02:21 am
content: 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.

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 11, 2016, 08:48:04 am
content: Quote from: Karel on February 11, 2016, 07:44:07 amif 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!... ?Quote from: Mechatrommer on February 10, 2016, 08:35:08 pmi 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.Quote from: miguelvp on February 11, 2016, 08:02:21 amit 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..

author: miguelvp
author_rank: Super Contributor
timestamp: February 11, 2016, 09:36:45 am
content: 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).

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 11, 2016, 09:57:47 am
content: 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..

author: ebastler
author_rank: Super Contributor
timestamp: February 11, 2016, 09:58:02 am
content: Quote from: Mechatrommer on February 11, 2016, 08:48:04 amIt 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...

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 11, 2016, 10:22:35 am
content: Quote from: ebastler on February 11, 2016, 09:58:02 amsometime its getting in my nerve actually but i just like to keep in control. 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

author: pascal_sweden
author_rank: Super Contributor
timestamp: February 11, 2016, 11:36:26 am
content: 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

author: ebastler
author_rank: Super Contributor
timestamp: February 11, 2016, 12:40:08 pm
content: Quote from: Mechatrommer on February 11, 2016, 10:22:35 amThat nicely sums up the difference in our approaches.

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 11, 2016, 05:14:19 pm
content: 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

author: hibone
author_rank: Regular Contributor
timestamp: February 11, 2016, 11:34:10 pm
content: 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.

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 12, 2016, 12:42:03 am
content: 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 state2) 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 pts4) from VB app, establish connection usingCode:res = viOpenDefaultRM(defrm)res = viFindRsrc(defrm, "USB?*", list, nmatches, matches)res = viOpen(defrm, matches, 0, 0, vi)hwnd = vias 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:":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:viClose hwndviClose defrmso...Q: what you expect to see?A: i expect to see what has been stated by the Bloody Goat Damned Programming Guide!

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 12, 2016, 01:47:51 am
content: Quote from: hibone on February 11, 2016, 11:34:10 pmthere is possibility. so i downloaded and installed the visa latest version 14.1... just now. still the same bug...Quote from: hibone on February 11, 2016, 11:34:10 pmall commands are replied correctly, except the number of points. so i'm pretty sure the command reached the other end..Quote from: hibone on February 11, 2016, 11:34:10 pmas 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...Quote from: hibone on February 11, 2016, 11:34:10 pmdo you need expertise to:1) switch on your scope2) connect it to pc using usb cable3) download my WIndows exe test program4) run it?

author: hibone
author_rank: Regular Contributor
timestamp: February 13, 2016, 01:00:59 pm
content: Quote from: Mechatrommer on February 12, 2016, 01:47:51 amNope, but it wouldn't be of use either, since i got a DS2072A-S (tweaked to DS2302A-S).I'm sorry about that.

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 14, 2016, 02:23:39 pm
content: 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...

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 19, 2016, 08:24:09 pm
content: 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: Nasty1) 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.

author: Mechatrommer
author_rank: Super Contributor
timestamp: February 25, 2016, 02:20:16 pm
content: ok, since yesterday, Rigol representative Jessie Jiang has contacted me. sent me some VI programs to test and clarify some few things to me. it seems most of the firmware bugs i reported has something to do with failure to press or activate "STOP" button or "STOP" command after changing V/Div, S/div etc setting, which seems to be needed to update some internal housekeeping things like preamble returned value, and interleaved memory arrangement.. FWIW, interleaved memory arrangement is used in their WFM file format. but somehow got stucked or leaked into USB stream when "STOP" command has not been activated. in WFM its no problem since we have enough data points as reported on the screen, but leak through USB only half the set.some people may say, yeah you have to follow the steps, but i say its still less elegant way. housekeeping stuffs should be updated the day we touch setting buttons like V/div, S/Div etc. we dont have to remember to press "STOP" button before rig up the "SINGLE" mode capture. this extra steps can be eliminated in this modern super processing power days, we are not in the 70's anymore. but anyway i give a thumbs up to Rigol for replying back to me, their support team are not that crappy afterall, well but not that stellar either... i've passed my wish to them ie no need to press STOP button to get the right preamble values i hope they listening and make the fix in the next FW update... thumbs up to them.

author: Mechatrommer
author_rank: Super Contributor
timestamp: March 01, 2016, 06:55:17 pm
content: another bug report... or peculiar behaviour or hardware limitation? i'm not sure... see picture attached...p1: V/div at 500mV/div... signal is 1Vpp 17MHz square wave. pay attention to the bottom signal at 0V...p2: V/div reduced to 200mV/div... still acceptable... bottom signal at ~10mVp3: V/div reduced to 100mV/div... ok... bottom signal at ~10mVp4: V/div reduced to 50mV/div... boom!... bottom signal at ~170mV, all of sudden...

author: ebastler
author_rank: Super Contributor
timestamp: March 01, 2016, 08:35:19 pm
content: Hmm, interesting... Wonder whether that is actually the front-end saturating due to the significant overdrive? Still, it should not do that, of course... What happens if you attenuate the signal by a factor of 10?

author: nctnico
author_rank: Super Contributor
timestamp: March 02, 2016, 01:12:18 am
content: That is typical behaviour when overdriving an input on a DSO so no bug there.

author: Mechatrommer
author_rank: Super Contributor
timestamp: March 02, 2016, 02:01:01 am
content: Quote from: nctnico on March 02, 2016, 01:12:18 amthanks for clarifying.. but the effect is so sudden. but i guess the general rule is, dont overdrive the inputedit:from jason chonko... the support team is getting better and better...http://cp.literature.agilent.com/litweb/pdf/5989-0068EN.pdf

author: Mechatrommer
author_rank: Super Contributor
timestamp: March 25, 2016, 03:12:45 pm
content: Rigol DSO DS1054Z FW 4.3.2.3 SP2 Bug Report (#4):Symptom:time/phase shift/lag between channel 1 and channel 2. inconsistent 100-300ns CH1 lag... see attached pictures.Persistence/Severity:everytime.1) What are you task are you trying to perform?ANS: download 2 synchronized signal, such as USB differential signal. at correct time shift.2) What are you seeing vs. what you expect to see?ANS: i'm seeing wrong time shift (phase lag) data, i expect correct time shift.3) Can you send me a text version of your code, in the exact order that the commands are being sent?reading mode:-":WAV:POINTS:MODE MAXIMUM"-":WAVeform:FORMat BYTE"-MemDepth = regardless "AUTO, 6K, - 12M" pts-dso in STOP (press STOP button in AUTO or NORMAL state) or SINGLE (triggered and stopped) state-download is not immediate. few seconds is provided for the DSO to save the data after STOPed state.so inadequate saving time to memory is not an excuse.