Rohde & Schwarz CRTU/CMU200 GPIB control - Page 1
Forum section: electronics / testgear

author: davorin
author_rank: Unknown
timestamp: June 01, 2015, 09:37:48 am
content: Thought I start a new thread here as it won't fit anymore in the old one with the USB SAs (o;Trying to communicate with my CRTU through GPIB, but so far no luck...no response even with *IDN? query...Setup:- Intel NUC running Ubuntu 14.04 and linux-gpib-3.21- Beiming GPIB USB adapter F82357/S82357- ibterm test program- CRTU default set to address 20- CRTU running in DOS modeNo response either directly hooked up or now in a daisy chain, devices before and after respond normally.Any ideas where I can dig into next?

author: davorin
author_rank: Unknown
timestamp: June 01, 2015, 10:12:31 am
content: I replies at least at COM1 port:

author: davorin
author_rank: Unknown
timestamp: June 01, 2015, 01:50:53 pm
content: Nobody using GPIB/SCPI with the CRTU or CMU200?Fiddling around now with RS232 as GPIB just won't work....but so far to no joy....can't seem to find out how to trigger a simple spectrum scan...and just a grey screen with "Remote" on top isn't helpful either what it actually does (o;

author: jadew
author_rank: Frequent Contributor
timestamp: June 01, 2015, 01:54:38 pm
content: If you get a "Remote" indication it means the REN line is asserted. This suggests that it should be possible to control it over GPIB.

author: davorin
author_rank: Unknown
timestamp: June 01, 2015, 02:00:53 pm
content: Well...this only happens with the COM1 interface...not the GPIB port...But even with COM1 port, when I send something from the programming example like:Code:SENS:SPEC:FREQ:CENT 900 MHZI get: "-113, Undefined header" error message...

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: June 01, 2015, 04:17:47 pm
content: I had some time this afternoon so I gave it a quick try on my CRTU, and what should I say, controlling via GPIB works fine as expectedAll I did was connecting my Beiming 82357B clone to my Windows 8.1 laptop, going into the Agilent Connection Expert, start a rescan of the GPIB bus and voila, the CRTU shows up. Even issuing manual commands works fine (see screenshots, the black blob is the serial number blocked out).But then I'm using Windows, so it should work out of the box(sorry, couldn't resist)A nice feature is that the CRTU (and the CMU200) can be configured to list remote control commands on the device's screen, either all or filtered for specific parts only. It also shows the device's response.There's also a function to record the communication into a file.

author: davorin
author_rank: Unknown
timestamp: June 01, 2015, 04:33:31 pm
content: HelloYes..in Windows everything works as expected (o;No...I also do development in Win 8.1....but mainly touchscreen apps with json web services (o;Do you know the command which shows all supported commands?Mostly I will use the SA settings and if there is such, a screen dump...The Windows approach would have been my next test.....but in the end I like to have a small debian box where the F82357 is connected to control my devices through JSON as well...I'm right now doing a print screen through COM1....and as it turns out, it always defaults back to 9600/Xon/Xoff (o;Had also no luck printing to CF/PCMCIA card....(yes..tried the right hand slot ;o)

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: June 01, 2015, 04:48:18 pm
content: Quote from: davorin on June 01, 2015, 04:33:31 pmNot always of course. But unfortunately GPIB is still much better supported under Windows than under Linux.QuoteSorry, I don't know. I guess it will be documented somewhere in the CMU200 documentation, or in one of the many documents that come with the Windows partition on the CRTU.QuoteI guess you could try Windows to make sure that it's not a hardware problem. If it works under Windows then at least you know where the problem is.

author: davorin
author_rank: Unknown
timestamp: June 01, 2015, 05:06:34 pm
content: Strange...it really worked out of the box under Win8.1 pro with latest I/O Suite....At least have now something to start digging into the commands (o;

author: tmbinc
author_rank: Frequent Contributor
timestamp: June 01, 2015, 05:21:28 pm
content: Take a look at the "REMOTE.TXT" files (on the harddrive; access them either from windows, or press alt-f4 and then use the DOS shell). I haven't tried them, but there's stuff like "1;READ:ARRay:SPECtrum?" as well as a bunch of "0;HCOPy" that should allow you to get a screenshot to internal memory (=HDD), and then copy that with "0;MMEMory:TRANsf" or something.Again, I haven't tried any. I was just looking at the commands.

author: davorin
author_rank: Unknown
timestamp: June 01, 2015, 05:27:13 pm
content: Hmm...okay....something to try....Seems I have to send at the end a *GTL then to have the grey "Remote" screen vanished and have it displayed the nice RF spectrum again ;-)Have you tried the PCMCIA slot at all?At least I know now that GPIB works...seems to be something fishy with linux-gpib.3.21 then...haven't tried the 4.x beta yet...

author: tmbinc
author_rank: Frequent Contributor
timestamp: June 01, 2015, 06:27:36 pm
content: Hm, no issues here (using COM1).1;INITiate:SPECtrum1;SENSe:SPECtrum:FREQuency:STARt?4.800000E+0081;SENSe:SPECtrum:FREQuency:STOP?5.000000E+0081;READ:ARRay:SPECtrum?-7.450781E+001,-7.307031E+001,-7.244531E+001,-7.428125E+001,-7.307812E+001,-7.549219E+001,-7.500781E+001,-7.756250E+001,-7.492188E+001,-7.514844E+001,[...]Cut&pasting the result into a CSV, and plotting it with - yeah, Excel - appears to work well.

author: artag
author_rank: Super Contributor
timestamp: June 01, 2015, 06:36:03 pm
content: I always get messed up by the EOS and EOI conventions. Some good guidance here under the 'error on a read' section.http://digital.ni.com/public.nsf/allkb/A80DBFCCAC36EBDE862562C80058856E

author: davorin
author_rank: Unknown
timestamp: June 01, 2015, 06:38:31 pm
content: Hmm...odd....well...will try on Thursday again as I am away tomorrow and Wednesday....But that's true...that as soon a remote command is issued, the spectrum display is always gone until a *GTL or pressing "Local"....Not like with a LeCroy 9354AL (o;Gonna pickup my Signalhound SA44B tomorrow for comparing ;-)Well for the EOS/EOI...I would not expect such a problem with a newer device....I'm used to GPIB problems on older HP equipment like 5335A...

author: davorin
author_rank: Unknown
timestamp: June 05, 2015, 12:54:14 pm
content: One nice guy from NASA over at yahoo groups mentioned that it might have to with the CRTU requires asserted remote enable line...The Python bindings have "remote_enable" defined....but throws an error with:Code:libgpib: ibsre errorTraceback (most recent call last):File "crtu.py", line 6, in <module>v.remote_enable(0)File "/usr/local/lib/python2.7/dist-packages/Gpib.py", line 80, in remote_enablegpib.remote_enable(self.id,val)gpib.GpibError: remote_enable() failed: One or more arguments to the function call were invalid.with this simple code:Code:from Gpib import *v = Gpib('crtu')v.remote_enable(1)v.write("*IDN?")print v.read(200)

author: davorin
author_rank: Unknown
timestamp: June 19, 2015, 05:23:34 pm
content: Guess here it is better than the RPi thread (o;Just tried through RS232 with above example....but even the first command gives in the report display log an error:Code:INIT:SPECINIT:SPEC -113, "Undefined header"So the "SPEC" command is unknown...

author: tmbinc
author_rank: Frequent Contributor
timestamp: June 19, 2015, 11:22:54 pm
content: Don't forget the "1;" prefix.

author: bingo600
author_rank: Super Contributor
timestamp: June 20, 2015, 08:22:44 am
content: Inhttps://www.valuetronics.com/Manuals/R&S%20CMU%20200%20300%20OPS.pdfPg. 260QuoteIt seems like EOI or <NL/0x0a> would terminate a line (but remember to set 8-bit/binary compare in gpib.conf)/Bingo

author: davorin
author_rank: Unknown
timestamp: June 20, 2015, 10:53:15 am
content: Hmm...EOI is not asserted at all.....when I replace the GPIB address in gpib.conf with the one from my LeCroy 9354AL, then it is asserted and it responds:

author: davorin
author_rank: Unknown
timestamp: June 20, 2015, 11:17:34 am
content: This screen shows same EOI line when addressing the CRTU....the EOI goes a little higher than normal...same screen is also seen talking to a powered off device:

author: davorin
author_rank: Unknown
timestamp: June 20, 2015, 04:03:59 pm
content: First trace is talking to a HP 6632B,second trace same *IDN? sending to the CRTU:Not sure which signal to trigger on exactly...

author: davorin
author_rank: Unknown
timestamp: June 20, 2015, 04:20:27 pm
content: Now the traces from within Keysight tool on Windows 8.1 Pro:The second trace shows more detail on the end when EOI is asserted.

author: davorin
author_rank: Unknown
timestamp: June 20, 2015, 05:16:36 pm
content: Hmm...I suspect something is going wrong before the command is sent..meaning addressing the device...Has anyone one seen a timing diagram how the GPIB primary/slave addressing is done on the bus?

author: dcarr
author_rank: Regular Contributor
timestamp: June 21, 2015, 04:20:45 am
content: If it helps, here's a simple python script that works with my CMU200:DavidCode:#!/usr/bin/pythonimport serialimport timereal = Trueecho = Trueif real:s = serial.Serial('/dev/ttyUSB0', 115200, timeout=3, xonxoff=False) #might need to add enable control settingsdef cmd(cmd_string):if echo:print cmd_stringif real:s.write(cmd_string + '\n')#s.readline() #unclear if this is neededdef query(query_string):if echo:print query_stringif real:s.write(query_string + '\n')result = s.readline()if echo:print "-> " + resultreturn result#MAIN#sweep settings (MHz)freq_start = 900freq_end = 999query("*IDN?")query("*RST;*OPC?")cmd("*SEC 0")cmd("SYST:NONV:DIS") #disable NVRAM, manual says this is important for performancecmd("*SEC 1")#set input and output connectorscmd("INP RF4")cmd("OUTP RF2")#setup generator#cmd("SOURce:RFGenerator:TX:FREQuency 1MHZ")cmd("SOUR:RFG:TX:FREQ %dE6" % freq_start) #default level is -27dBmquery("INIT:RFG;*OPC?")#exit()#setup analyzer either NPOW or POW, TBD#TODO Set BW, delay, measurement time, etc. here#cmd("LEV:MAX 0")#cmd("CONF:POW:CONT SCAL,NONE") #might not want this#cmd("CONF:SUB:POW IVAL,0,1")cmd("RFAN:BAND 1000e3")cmd("INIT:RFAN") #unclear if I need this, it's in the example#cmd("INIT:WPOW")t1 = time.time()for f in range(freq_start,freq_end):#cmd("POW:FREQ:CENT %dE6" % f)cmd("RFAN:FREQ %dE6" % f)cmd("SOUR:RFG:FREQ %dE6;*WAI" % f)#query("SOUR:RFG:FREQ %dE6;*OPC?" % f)#query("READ:SUB:POW?") #may not work with SCALquery("READ:RFAN:POW?")#query("READ:WPOW?")t2 = time.time()print "%0.3fs for %d points, %f points/s" % (t2-t1, freq_end-freq_start, (freq_end-freq_start)/(t2-t1))

author: davorin
author_rank: Unknown
timestamp: November 14, 2015, 06:29:31 pm
content: Okay...since now GPIB works with the CRTU-RU....I browsed a little through the CMU200 operation manual and the examples here....I mostly get either "invalid header" or "query unterminated" errors on the screen.So far as I understood you always need to prefix a "1;" if you want to talk to the RF section of the instruments and assign it in the "remote setup"...Normal to see those errors? At least it seems to accept for example setting RF gen frequency...though reading back omits the first character:Code:ibterm>1;SOUR:RFG:FREQ 868 MHZibterm>1;SOUR:RFG:FREQ?.680000E+008ibterm>1;SOUR:RFG:FREQ?8.680000E+008

author: davorin
author_rank: Unknown
timestamp: December 07, 2015, 04:21:19 pm
content: Once back again at CRTU GPIB dumping...especially as my first CRTU doesn't accept my 128MB CF cards anymore for printing...Is the array size always constant when capturing the RF spectrum?Code:#!/usr/bin/pythonimport sysimport Gpibfilename = sys.argvtarget = open(filename, 'w')crtu = Gpib.Gpib('crtu')print "Writing to CRTU\n"crtu.write("1;INITiate:SPECtrum")crtu.write("1;SENSe:SPECtrum:FREQuency:CENT 2432 mhz")crtu.write("1;SENSe:SPECtrum:FREQuency:SPAN 50 mhz")crtu.write("1;READ:ARRay:SPECtrum?")print "Reading from CRTU\n"bytes = 200target.write(crtu.read(bytes))count = 0while crtu.ibcnt() == bytes:print 'Bytes read: ',counttarget.write(crtu.read(bytes))count += bytesprint '\nFinished dumping... 'print "Going local\n"crtu.write(crtu, "*GTL")target.close()Problem here with the code is that it times out when the CRTU has finished sending the RF data...so the script bails out and never send the "goto local" command...Hard to believe that there isn't a "screen dump" command like other devices have like the E4406A...

author: _Wim_
author_rank: Super Contributor
timestamp: December 14, 2015, 09:00:13 pm
content: Quote from: davorin on November 14, 2015, 06:29:31 pmHi,I was also struggling with the -113 , "undefined error" (using windows and a CMU200, connected though an agilent 82357B usb adaptor). In my case, the solution was instead of using the 1; prefix, to use 9; prefix because this prefix defines the secondary GPIB address, and the default secondary addres for RF-non signaling was "9" for the CMU200.I do not own a CRTU, but if you check the remote setup for seconday addresses to see what number is defined for RF (by default).

author: fisafisa
author_rank: Regular Contributor
timestamp: December 15, 2015, 09:11:54 pm
content: Using GPIB, can you use both RXTX chains?CiaoF

author: _Wim_
author_rank: Super Contributor
timestamp: December 15, 2015, 09:53:48 pm
content: Did not try this yet, but from a quick glance at the user manual, I would expect this to be no problem. I am still a vey beginner at GPIB, so progress is slow...

author: fisafisa
author_rank: Regular Contributor
timestamp: December 16, 2015, 08:29:58 pm
content: It would be nice to see if one can activate both TX on different ports.Acquiring both RXs on different port would be nice too.

author: davorin
author_rank: Unknown
timestamp: June 29, 2016, 05:03:40 pm
content: Okay...since PHP5 works nicely with GPIB and my NI GPIB card...thought I give this one a new try (o;A quick PHP hack drawing the spectrum of my CRTU-RU....Code:<?php$string="";$image="";$u=ibfind("crtu");ibpad($u,20);ibsad($u,97);ibwrt($u,"1;INITiate:SPECtrum");ibwrt($u,"1;READ:ARRay:SPECtrum?");while($r=ibrd($u,$string,1000)){$count=ibcnt();$image.=$string;if($count<1000)break;}ibwrt($u,"*GTL");$spectrum=explode(",",$image);$min=0;$max= -1000;foreach($spectrumas$value){$point=4*number_format((float)$value,5);$rf[] =$point;if($min>$point)$min=$point;if($point>$max)$max=$point;}//echo "Min: " . $min . "\n";//echo "Max: " . $max . "\n";$im= @ImageCreate(560,512);$background_color=ImageColorAllocate($im,234,234,234);$graph_color=ImageColorAllocate($im,25,25,25);$x1=0;$x2=0;$y1=0;foreach($rfas$pixel){$y2=150-$pixel;if($x2){imageline($im,$x1,$y1,$x2,$y2,$graph_color);//echo "<pre>Drawing from " . $x1 . ":" . $y1 . " to " . $x2 . ":" . $y2 . "</pre>";}$y1=$y2;$x1=$x2;$x2++;}header("Content-type: image/jpg");ImageJPEG($im);?>Much to improve though...but as a first start not bad...takes around 300msec to render the image:

author: davorin
author_rank: Unknown
timestamp: August 10, 2016, 05:04:43 pm
content: A little better now (o;Though some hardcoded values yet due to laziness (o;