I'm programming a calibration. The cals done w/ the ECal module connected at port A to the PNA-X port 1 work fine. So now I'm trying to do a calibration w/ the ECal module connected at port A but now the PNA-X port 2. If I do a cal through the Cal Wizard, I can specify port 2 for the calibration and all is well. However, I'm unable to find the SCPI commands to tell the PNA-X to use port 2 (instead of port 1) for the ECal calibration. Please advise.
unguided (this must be an automated process - no operator intervention).
I did do a CALC:PAR:SEL prior to starting the cal.
BTW, it's a 1-port SOL cal (for a VSWR measurement), if that matters. I'm only using port A on the ECal (it's because the ECal they bought was male/female and the UUT is male/male) - that's why I have to use port 1 on some cables and port 2 on others.
If you have the code for port 1 and it works, you should just need to set the measurement to S22 prior to setting the calibration type and it should work. You might post the command sequence you are using.
Also as an alternative, you might want to consider using the guided calibration (SENS:CORR:COLL:GUID....) commands to do these 1 port calibrations. with guided you can be explicit about what kind of cal you want to perform and on which ports. there will be no dependency on the selected measurement. There are a number of guided cal SCPI programming examples in the help file.
Doesn't the guided cal require operator intervention at the PNA-X? We don't want to do that, the operator does not necessarily have a view of the PNA-X and the UUT and the computer at the same time.
As for the code, I'll have to write it down manually and then type it in here, so that will take some time. I'll do that.
BTW, this is easily reproducible manually. Just do a 1-port cal using the cal wizard and select the eCal. UNLESS you select the proper PNA-X port, it will not cal (error is the unable to orient ECal one).
no, you can program the guided cal, just like the unguided cal and it will not require any more manual intervention from the operator than the unguided cal. As long as the ecal is connect to the right port before you start your program, you can go from start to finish without ever having to stop and prompt the operator.
Note that at the end you can query the description of the calibration step, but since this cal is always a single step cal, you really don't need to do that and can just process to acquire step and then saving the cal.
OK, since I had to copy the SCPI commands down manually, I found the error (well, I haven't run the test again but I'm fairly confident that I found the cause)
I had been using a sub-VI (built by someone else) that performed the ECal portion (set the frequency and did the SENS:CORR:COLL:ACQ). Well, that VI wasn't written to be too general purpose. In it I found another CALC:PAR:SEL CH1_S11_1. The measurand was hard-coded. Since I always know that I have to do a CALC:PAR:SEL to do other setup commands, I just removed the hard-coded one in the sub-VI. This same sub-VI had also hard-coded the calibration type (to full 2-port) but I had already fixed that to be a selectable option item (defaulted to full 2-port). When I made that change I did not notice the CALC:PAR:SEL (my bad).
Thanks for the help.
BTW, here's the code snippet in case you have other comments:
SYST:PRES if input port -----> this portion assumes the preset will create CH1_S11_1,S11 as trace 1 on channel 1 DISP:WIND:TRAC:DEL CALC:PAR:DEF:EXT 'CH1_S22_1','S22' DISP:WIND:TRAC:FEED 'CH1_S22_1' CALC:PAR:SEL 'CH1_S22_1' SOUR:POW:LEV:IMM:AMP <power level> MMEM:DEL '<filename and path>' -----> is there a way that you guys could make it, if the file doesn't exist not to create the error or a way to see if the file exists??? SENS:SWE:POIN <# of pts> perform eCal SENS:FREQ:STAR <input start freq>HZ SENS:FREQ:STOP <input stop freq>HZ CALC:PAR:SEL 'CH1_S11_1' -----> now deleted this SENS:CORR:COLL:METH <input method type> SENS:CORR:PREF:ECAL:ORI:STAT ON SENS:CORR:COLL:ACQ ECAL1,CHAR0
Unguided cal is a carry over from the old 8753/8510 days of network analysis and we keep it around on the PNA platform mainly for backwards compatibility. all of our new innovations in calibration methodologies are implemented through the guided cal engine. for example, if you want to do 2-port unknown thru cal, that is only available in the guided cal. Another example, if you want to do anything more than a 2-port cal (3, 4, N-Port), then you have to use guided cal. With our new PNA-X platform we have introduced a number of new measurement applications for active devices, IMD, Noise Figure, swept frequency Gain Compression, etc. All of these new applications come with their own specialized guided calibration wizards and none of them support unguided cal. In short if you ever want to do anything other than simple 1 or 2 port s-parameter or response calibrations, then you'll have to use the guided cal interface, so you mind as well start getting used to it now
I also agree that guided cal is the way to go. Once you have the base code written for a guided cal sequence, it is fairly easy to go change things or use the queries built into the guided calibration structure to prompt the user to make the proper selections.
One comment on Guided Cal: it is fussy as hell about the exact syntax of the connector and ecal description (or Ecal or is it ECal). so do as dara does; never hardcode the connectors or ecal, just query it and pass it back to the connectors setting function. Saves lots of headaches.
Well, I finally got around to this again and I'm still having problems. This command is failing:
The error is 187 (unable to orient the Ecal). If I change ECAL1 to ECAL2, I get error 172 (could not configure the ECal). If I turn auto orientation off, (SENS:CORR:PREF:ECAL:ORI:STATE OFF) I don't get an error w/ ECAL2 (same error w/ ECAL1) but the calibration isn't right (disconnect the cable and the S22 trace is very noisy).
Remember the DUT end of the cable is connected to port A of the ECal module, and the port 2 of the PNA-X is connected to other end of the cable