#qi-hardware IRC log for Thursday, 2015-02-05

wpwraksigh. if she stays much longer, she'll surely start a war ... http://www.nytimes.com/2015/02/05/world/americas/argentinas-president-mocks-chinese-accents-during-visit-to-china.html?_r=003:12
wpwrakDocScrutinizer05: (same issues) that would suck :(03:51
DocScrutinizer05well, same issues regarding timing and ignored commands when sent too fast. I wonder how that VISA stuff is handling that04:37
DocScrutinizer05I also wonder what's with *OPC and *OPC? 04:39
DocScrutinizer05>> The *OPC command is used to set the Operation Complete bit (bit 0) in the standard event status register to 1 after the current operation is finished. The *OPC? command is used to query whether the current operation is finished. The query returns 1 if the current operation is finished; otherwise, returns 0.<<04:40
DocScrutinizer05sounds like *OPC was the only command allowed during another command still finalizes04:41
DocScrutinizer05my current problem though is mainly the lacking value for ':ACQuire:MDEPth?' when set to auto. Combined with the idiocy that I cannpt download more than ~200k of waveform data in one chunk, and cannot even set wave:end to some value that would mean "end of available data"05:09
DocScrutinizer05IOW no dang hint on ceiling of buffer. Except for a nasty beep on device when I try to set wave:end to a value that's >wave:start + 200000 or > buffer-size05:11
DocScrutinizer05and yes, I could read back wav:end? and check if it accepted the new value or still has the old one. I also can read back syst:err? and check for error ' -220,"Parameter error" '05:14
DocScrutinizer05but it seems I have to wait/sleep significant fraction of a second before even reading back error (or doing any other command, on that behalf, maybe except *OPC?), so no reasonable procedure for downloading all bytes of wave buffer comes to mind05:16
DocScrutinizer05there's http://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg576271/#msg576271 and that guy seems to not even vare about timing at all - but then he's using that nasty VISA lib05:17
DocScrutinizer05s/vare/care/05:18
DocScrutinizer05otherwise he's doing basically exactly what I do, and he ignores the send_cmd(vi, ":ACQUIRE:MDEPTH?"); --> "AUTO" problem05:19
DocScrutinizer05there's also 05:20
DocScrutinizer05jr@saturn:~> send_cmd ' :WAVeform:PREamble?'05:20
DocScrutinizer050,2,400000,1,1.000000e-09,4.747600e-02,0,1.000000e-09,0,12505:20
DocScrutinizer05but 3rd parameter "points" (400000) is a simple silly wav:end? - wav:start?05:21
DocScrutinizer05and wav:end seems to come up with a default of 6000 (SIC!), no matter of real buffer depth05:22
DocScrutinizer05(kirchner) I rather wonder who's going to get assassinated next, suicide style05:31
DocScrutinizer05did you say Kirchner is socialist/left-wing? the methods rather feel like worst communism or random arbitrary totalitarian government05:33
DocScrutinizer05if it's unclear: I'm referring to ???man05:34
DocScrutinizer05the colorable suicide shot in the head05:35
DocScrutinizer05wpwrak: maybe you already should think twice before starting public rants about Kirchner. Or get decent bodyguards ;-)05:37
DocScrutinizer05hah, nice quote of Wim Wenders: "Do what only you can do! When you think 'somebody else could do this, maybe even better than me' then don't do it, no use in it"06:04
DocScrutinizer05I doubt anybody except the super-rich could survive on strictly following this rule, but it's a good guideline nevertheless06:05
DocScrutinizer05s/6000/1200/07:08
DocScrutinizer05jr@saturn:~> send_cmd '*OPC'; send_cmd ':WAVeform:STOP 1200';  send_cmd '*OPC?'07:13
DocScrutinizer05command error07:13
DocScrutinizer05jr@saturn:~> send_cmd ':SYST:ERR:next?'07:14
DocScrutinizer05-410,"Query INTERRUPTED"07:14
DocScrutinizer05NB a ` send_cmd ':WAVeform:STOP 1200'; send_cmd '*OPC' ` works without throwing error07:15
DocScrutinizer05jr@saturn:~> send_cmd '*OPC';  send_cmd '*OPC?'07:16
DocScrutinizer05107:16
DocScrutinizer05jr@saturn:~> send_cmd ':WAVeform:STOP 1200'; send_cmd '*OPC';  send_cmd '*OPC?'07:17
DocScrutinizer05command errorjr@saturn:~>07:17
DocScrutinizer05http://privatepaste.com/8a0dde7eb807:23
DocScrutinizer05wpwrak: I need your magic intuition to make sense out of *OPC[?]07:27
wpwrakDocScrutinizer05: (left/socialist) well, even the nazis were nominally socialist, right ? :) (nisman) a very ugly story indeed. what's a little odd is that the government seems to do its best to make this as damaging to itself as possible.07:41
DocScrutinizer05WTF??? works??07:46
wpwrak(scope) the *.. commands may be at a different level than the other commands. so yes, maybe *OPC? could do the trick. if it's implemented. did you ever see it return 0 ?07:46
DocScrutinizer05http://privatepaste.com/8efced984d07:46
DocScrutinizer05(o) no07:46
wpwrakah, it works ? maybe it realized that you had asked me for help and thus it decided that further resistance is futile. it has happened before :)07:47
DocScrutinizer05well, at least wav:stop 24000000 succeeded, without even spitting out any beeps and weird notes like "invalid param!"07:48
DocScrutinizer05http://privatepaste.com/44b15b02f707:52
DocScrutinizer05note that this still doesn't mean the wav:data? command will work as supposed to, it still may fail to provide uncrippled data07:56
wpwrakyeah, there's a lot of trial and error in such things08:11
wpwraki think it took a week or so before i had a set of empirical data that would let me use my scope properly, and avoid things like commands partially overwriting each other08:12
DocScrutinizer05http://privatepaste.com/8ce540dfab08:51
DocScrutinizer05how dull can a simple read() implementation get?08:53
DocScrutinizer05man 2 read; size_t count = (:wav:stop - :wav:start); return value = TMC header bytecount; :wav:start = man 2 lseek SEEK_SET09:02
DocScrutinizer05and yes, this would mean the header this shite delivers for start=1 end=24M (#9000000000) indicates "EOF"09:04
DocScrutinizer05hmm http://privatepaste.com/224b7b185410:09
wpwrakso .. that's success ?10:14
DocScrutinizer05ohmy, kinda: http://privatepaste.com/27e6fc60bf10:51
DocScrutinizer05data verification pending10:52
DocScrutinizer05watch the 2jitter", it's solely caused by Rigol "firmware" slow and random like geotectonics10:52
Action: DocScrutinizer05 wonders if wireshark would be worth a try on that one10:57
DocScrutinizer05anyway here's the dirty stuff I got so far: http://privatepaste.com/163c81b0ae10:58
DocScrutinizer05comments welcome, also regarding style10:59
DocScrutinizer05also how would I verify that the waveform downloaded is actually what the scope sampled, without gaps or glitches and no bogus values in it?11:08
DocScrutinizer05sidenote re speed: seems the bottleneck also applies to ethernet data download, not only to USB file storage11:09
DocScrutinizer05I guess it's actually the prolly 5.5bit MCU that is a) slow like molasses and b) has a pretty low priotity low bandwidth bus to access the ASIC's RAM11:11
DocScrutinizer05I2C? ;-)11:11
DocScrutinizer05anyway that idiotic thing thinks it needs to comment commands like 'wav:stop NNNN' with a tiny notifier on screen "Stop point changed!" and with a BEEP(!!)11:21
DocScrutinizer05while it comments end of download of a chunk with "Can Operate Now" (SIC!) and another beep11:22
DocScrutinizer05sure like hell that script needs a "send:cmd ':SYST:BEEP 0' "11:23
DocScrutinizer05download of 24MB takes 10:33 now11:25
DocScrutinizer05taking into account all the sleep $w after each command, I'd guess the bottleneck bandwidth is identical to that one seen on a fast contemporary USB memstick (80MB/21min)11:26
DocScrutinizer05~24000000 / 20000011:28
infobot_12011:28
DocScrutinizer05~633 / 12011:29
infobot_5.27511:29
DocScrutinizer05half of those average 5.3 seconds seems eaten by the 4 commands (:wav:start nnnn; :syst:err?; :wav:end nnnn; :syst:err?)11:30
DocScrutinizer05:syst:err seems cruft, aka debug-print11:31
DocScrutinizer05but seems to add to stability, prolly due to commands with output (:wav:start nnnn doesn't echo _anything_) serializing operation inside that lame MCU11:32
DocScrutinizer05(:wav:start nnnn doesn't echo _anything_) which is prolly part of the problem11:38
DocScrutinizer05 echo "$1" | netcat -w 2 $RIGOL_IP 5555  -->   echo "$1" | netcat -w 1 $RIGOL_IP 5555   ==>  10:33 --> 6:3011:44
DocScrutinizer05:-D \o/ :-S11:44
DocScrutinizer05*my* netcat doesn't know sub-second -w values11:45
DocScrutinizer05wait wait, doesn't netcat start timer resp tear down listening port as soon as input on stdin is EOF?11:47
DocScrutinizer05 (echo "$1"; sleep 0.1) | netcat -w 0 $RIGOL_IP 5555 # ????11:47
DocScrutinizer05this starts giving me ideas11:49
DocScrutinizer05I wonder if LXI protocil actually neesd a new TCP connection for each new command11:49
DocScrutinizer05well, I guess I know how to test that ;-P11:50
DocScrutinizer05HMMMMMM11:55
DocScrutinizer05jr@saturn:~> (echo "*IDN?"; sleep 0.5; echo ":SYST:ERR?"; sleep 0.5) | netcat 192.168.4.52 555511:55
DocScrutinizer05RIGOL TECHNOLOGIES,DS1104Z,DS1ZA164357442,00.04.02.SP311:55
DocScrutinizer050,"No error"11:55
DocScrutinizer05wow, weird stuff! http://privatepaste.com/8b132b431412:09
DocScrutinizer05note how :WAV:STOP? reply completely missing between line 2,312:11
eintopfwhat the hell is that? reverse engineering some oscilloscope protocol?12:16
wpwrakeintopf: it's DocScrutinizer05 discovering that talking to lab instruments often isn't as nice and easy as one may think ;-)12:20
DocScrutinizer05yeah, and no sophisticated perl or c++ or pythoon can really mitigate that, it's the lab instruments that are borked to the bone12:21
DocScrutinizer05after 'WAV:START NNNN' no trick substituates the needed sleep 0.2, when next command is 'WAV:STOP NNNN'12:22
wpwraksounds very familiar :) if course you can never quite tell where the problem will be, but you can be confident that there are problems :)12:23
wpwrakonce your findings begin to stabilize, you may want to report them on eevblog. maybe you can start a discussion there where other people can help you as well.12:26
kyakeintopf: don't tell me you are reading :)12:28
DocScrutinizer05http://privatepaste.com/6fcc2c43cf12:29
DocScrutinizer05^^^ looks already more decent than what the script is doing12:30
wpwrakyou should wait for those *OPC? responses12:30
DocScrutinizer05real    0m0.745s12:30
DocScrutinizer05maybe I should, maybe it's worthless12:31
DocScrutinizer05I still think OPC is cruft12:31
wpwrakthere's only one way to find out :)12:31
wpwrakbut yes, could be just a dummy12:31
DocScrutinizer05there's just a certain speed you can run this Rigol interface with. Doesn't matter if you fill the time with cruft commands like *OPC *OPC? and many tiny sleeps, or you just add 2 sleep 0.212:35
DocScrutinizer05time (echo ":WAV:STAR 1"; sleep 0.2; echo ":WAV:STOP 24000000"; sleep 0.2; echo ":WAV:STAR?";sleep 0.1; echo ":WAV:STOP?"; sleep 0.1; echo ":SYST:ERR?"; sleep 0.1) | netcat 192.168.4.52 555512:36
DocScrutinizer05real    0m0.708s12:36
DocScrutinizer05NB *OPC? always returns 112:37
DocScrutinizer05but I dunno how to use *OPC and *OPC? at all12:38
DocScrutinizer05the programming manual isn't enlightening: http://wstaw.org/m/2015/02/05/plasma-desktopsm1891.png12:39
DocScrutinizer05maybe this only applies for commands that per definition take minutes to complete, like calibration, selftest etc12:41
wpwrakyeah, with a scope it's difficult since most commands are "quick"12:41
wpwrakcan you command storage operations ? those should take long12:42
DocScrutinizer05nope12:42
DocScrutinizer05a pity12:42
DocScrutinizer05a forced trigger with a time base of 20s/div? ;-)12:43
wpwrakprobbaly not12:43
DocScrutinizer05ooh, even 50s/div available12:44
wpwrakif you send two beeps back to back, does it beep twice or just make a very very slightly longer beep ?12:44
wpwraktrigger is likely to be asynchronous12:44
DocScrutinizer05it makes one beep and throws error ;-)12:44
DocScrutinizer05actually I wonder how to send a beep12:45
DocScrutinizer05there's just SYST:BEEPer <bool>12:47
DocScrutinizer05to enable or switch off12:47
wpwrakah, seems that *OPC? also synchronizes, see http://na.support.keysight.com/pna/help/latest/Programming/Learning_about_GPIB/Understanding_Command_Synchronization.htm12:47
wpwrak(beep) ah yes, thought you could generate one directly12:49
DocScrutinizer05I can, e.g. by ':WAV:STOP NNN'  ;-P12:52
DocScrutinizer05(keysight) now THAT is some manual, not that rigol shite pathetic12:53
DocScrutinizer05then, Rigol seems to lack any input queue12:54
DocScrutinizer05otherwise I wouldn't know why "-410,"Query INTERRUPTED""12:55
wpwrakalmost a 404 ;-)12:56
wpwrak(manual) rule of thumb: there's always a good manual out there, but it's not for the product you have :)12:56
DocScrutinizer05indeed12:58
DocScrutinizer05keysight U1233a manual is ... non-existent12:58
DocScrutinizer05for that purpose12:58
DocScrutinizer05but then, there's an android app for that now X-P12:59
DocScrutinizer05why would you want to talk LXI SCPI to that critter when you got a nice android app, right?13:00
wpwrakwhee ! :-)13:00
DocScrutinizer05anyway, during the last years when I heard about Rigol and the stories I always thought it must be sth like Heathkit, or russian surplus. When I unpacked it I thought "no, this is a highly professional tool, yay". Now I start to learn it actually is like heathkit stuff ;-)13:05
wpwrakSCPI seems to be a mess everywhere. i don't think i've spoken to a single instrument yet that didn't need some weird quirks, be it rigol, tek, fluke, picotest, ...13:08
DocScrutinizer05yes, SCPI is a pathetic spec, from beginning, it seems13:13
DocScrutinizer05worse than Hayes13:13
DocScrutinizer05aka AT13:13
DocScrutinizer05anyway, how would I check the downloaded waveform file for 'correct' data?13:18
wpwrakmaybe by saving the same waveform on a USB stick and comparing the two ?13:21
wpwrakif that doesn't work, you'll have to record test patterns and see whether what you get looks about right13:21
DocScrutinizer05http://neo900.org/stuff/joerg/random-media/rigol-temp/13:29
--- Fri Feb 6 201500:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!