AnsweredAssumed Answered

E5080B Calibration with E-Cal(N4433D) error

Question asked by NeilL on Nov 25, 2020
Latest reply on Dec 15, 2020 by NeilL

Like • Show 0 Likes0
Comment • 8

I need to perform 4-port calibration with E-cal on E5080B remotely.
The SCPI command I written is :

SENS1:CORR:COLL:GUID:ECAL:ACQ SOLT,1,2,3,4

When E5080B(26.5GHz) + N4433A , this command works fine.
However, the same one E5080B + N4433D , it can't calibrate and got error message as below :

Error : -290 : Did not find one or more thru standards defined that would
satisfy the thru method specified for the port pair and for the frequency
span to be calibrated.

how can I fix this error?

BTW, it has no problem with E5080B + N4433D calibrate 4-port manually.

NeilL Dec 4, 2020 4:01 AM

Correct Answer

I've found the root cause...or workaround. I'm not sure...

The key point is the commands as below :

SENS1:CORR:COLL:GUID:ECAL:ACQ SOLT,1,2,3,4 => Error -290

SENS1:CORR:COLL:GUID:ECAL:ACQ SOLR,1,2,3,4 => works normally

From help document I know about that :

SOLT: using defined through

SOLR: using undefined through

however , I make some experiment on E5080B with N4433A/D,

check the table about the command feedback condition as below :

E5080B (20GHz) FW : 13.90

E5080B (26.5GHz) FW : check at next week

Does the FW. Version have influence on this?

and..which command (SOLT and SOLR) has the better performance at RF ?

See the reply in context

No one else had this question

Outcomes

8 Replies

daras Nov 25, 2020 9:14 AM
Mark Correct
Correct Answer
I don't have access to an ENA or the particular ECal model that you are using to try this out, but here are some possible causes that may contribute to the problem you are seeing:

1- you have more than 1 ECal connected to the ENA and the first enumerated ECal may not be the N4433D that you are trying to use.
2- your ECal may have user characterizations that are incompatible with the 4 port calibration you are trying to do and the user characterization is getting selected as the default instead of the factory characterization.

If the calibration works manually, but not from the remote API, then the issue is not the firmware not recognizing that particular ECal model (happens from time to time when a new ECal model is introduced and the customer is running older firmware). The issue is most likely that somehow a default ECal is selected that does not match the calibration you are trying to do. However, you can always explicitly select the ECal that you want to use by using the SENS:CORR:COLL:GUID:ECAL:SEL command. In the online help for that command there are examples for what string to use to identify the particular ECal and characterization you want. If you add that command and are still having the same issue, please post back here with details about the firmware version you are using and maybe even a state file that we can use to replicate your issue.
Like • Show 0 Likes0
Actions
- NeilL @ daras on Nov 26, 2020 6:33 PM
  Mark Correct
  Correct Answer
  Thanks your quickly reply,
  but our E5080B was occupied by others to next Monday, I will try SENS:CORR:COLL:GUID:ECAL:SEL next week.
  
  I can only tried to make a simple experiment yesterday :
  1. Remove all E-cal (while E5080B has no e-cal plugged)
  2. Press power button of E5080B to shutdown and re-power-on.
  3. After firmware loading complete, plugged in N4433D only and wait for ready.
  4. Send SENS1:CORR:COLL:GUID:ECAL:ACQ SOLT,1,2,3,4 ,
  the result was still failed and got the same error message.
  
  According to the number 1. possible cause,
  does it mean that the ECAL list recorded in E5080B can't be reset by powering cycle?
  Like • Show 0 Likes0
  Actions
am95405 Nov 25, 2020 9:20 AM
Mark Correct
Correct Answer
Are your connectors (the gender) identical between your two ECals? Is everything else identical in the setup (frequency)?
Like • Show 0 Likes0
Actions
- NeilL @ am95405 on Nov 26, 2020 6:32 PM
  Mark Correct
  Correct Answer
  Thanks your quickly reply
  1. About connector : Yes
  2. RF path setup : E5080B(set to 26.5GHz) <--cable--> L7106B(20GHz) <--cable--> N4433D
  Like • Show 0 Likes0
  Actions
  - am95405 @ NeilL on Nov 30, 2020 8:18 AM
    Mark Correct
    Correct Answer
    Here are some ideas, though I have no idea if any of them will help. :-) Just brainstorming possible issues ...
    
    1. Have you tried connecting the ECal to the analyzer without the switch?
    
    2. We had an issue with ECal and FieldFox (that we resolved) where if the ECal had non-sequential user characterizations stored in it (user char 1, user char 3, user char 4), it would fail. It had no problem with user char 1, 2, and 3. So it may be worthwhile checking to see if your ECal module has user-characterizations stored in it. This goes along with Dara's #2 comment above. Not about sequences, but in general, lack of compatibility.
    Like • Show 0 Likes0
    Actions
NeilL Dec 4, 2020 4:01 AM
Unmark Correct
Correct Answer
I've found the root cause...or workaround. I'm not sure...
The key point is the commands as below :
SENS1:CORR:COLL:GUID:ECAL:ACQ SOLT,1,2,3,4 => Error -290
SENS1:CORR:COLL:GUID:ECAL:ACQ SOLR,1,2,3,4 => works normally
From help document I know about that :
SOLT: using defined through
SOLR: using undefined through

however , I make some experiment on E5080B with N4433A/D,
check the table about the command feedback condition as below :
E5080B (20GHz) FW : 13.90
E5080B (26.5GHz) FW : check at next week
Does the FW. Version have influence on this?
and..which command (SOLT and SOLR) has the better performance at RF ?
Like • Show 0 Likes0
Actions
- am95405 @ NeilL on Dec 4, 2020 9:40 AM
  Mark Correct
  Correct Answer
  SOLR is the preferred method.
  
  As to the SOLT error, I would need to understand the connectors you are stating you have (m/f), and the ECal's, and if it has defined thru's, if needed. Dara may know this without having to look it up. But SOLR should be a good choice and allow you to make the measurement.
  _______________________
  FYI, I created this video a while back to explain the difference between these Cals in simple terms.
  FieldFox VNA Calibration - Unknown Thru vs SOLT - YouTube
  
  This is the text of the video:
  SOLT is short open load thru.
  SOLR is short open load reciprocal thru.
  SOLR is a more generic interpretation, in that the only requirement of the thru is that it is reciprocal. Reciprocal means a device where the S21 = S12, meaning the forward and reverse frequency responses are identical. This is true for any passive, non-ferrite-based device, like a simple thru adapter or a cable. So if your thru is just an adapter, it is reciprocal.
  Many Keysight/Agilent/HP VNA users are used to SOLT, and that works well for insertable devices, but not so well for non-insertable devices. Let’s explore this.
  The OSL part of these two cals is the same, and it is the shorts and opens that determine your reference plane location. The load is the same. But now let’s talk about the thru, which is where the difference lies.
  If you have a male-female device, which is called an insertable device, then the thru is simple. For the thru, you connect the female-male ends of your cable together. But what if you have a female-female device, which is called an non-insertable device, and is very common, you do your OSL on port 1 with your female standards, OSL on port 2 with female standards, and now to connect the two male cables together you need a female-female adapter. You no longer can connect your cables directly together with the software GUI tells you to connect the thru.
  You could just pick up any female-female barrel and connect the two, but the challenge is with the traditional definition of SOLT, the assumption is a zero-or flush thru, or a defined thru. So, if it’s a flush-thru, now you have an adapter where it was expecting nothing, and you’ve introduced errors. You could have a defined thru, and some cal kits include barrels in them, and the cal kit definition has the definition for the thru, but that definition is only loss and delay, not the full 2-port S-parameters. The definition assumes a perfect match which introduces errors.
  Here is where SOLR with unknown thru comes to the rescue. You connect your OSL, OSL, and then you can connect your barrel and it will de-embed it for you. In this case, the adapter is measured and accurately removed as part of your calibration. It’s the same connections, but the algorithm is smarter. Unknown thru provides you the accuracy without any extra work. It is very flexible as it works for both insertable and non-insertable devices, so that’s why it’s the default and recommended cal for 2-port measurements for FieldFox, and other Keysight VNAs.
  Sometimes users seem to prefer SOLT because “it looks better”. SOLT in nearly all cases assumes a flush thru, it assumes perfection, and therefore after you’ve done your cal, if you leave your thru connected, you see a nice flat line at 0 dB for S21. On the other hand, if you do the same thing with unknown thru, it shows a bit of loss or not perfect 0 dB. That’s because it’s showing you the true S21 of that adapter or even that male-female connection. Your S21 was never that perfect. SOLT with the defined thru assumed it is perfect and normalized it, so you see zero. That’s why users sometimes think SOLT is better, but that’s not the case.
  As a final note, the term full 2-port can be confusing. Both SOLT and unknown thru are full 2-port Cals. You’d have to look at the specific analyzer to see what it means.
  Like • Show 0 Likes0
  Actions
  - NeilL @ am95405 on Dec 15, 2020 5:52 PM
    Mark Correct
    Correct Answer
    Thanks your video to clarify the confusion.
    We'll change the method to SOLR from SOLT.
    Like • Show 0 Likes0
    Actions

E5080B Calibration with E-Cal(N4433D) error

Outcomes

Related Content

Recommended Content