Agilent E8357A

[joeqsmith]

All combinations cause the same error.  Sending DIAG by itself also causes the same error.  I looked at the included help built into the PNA and they also make no mention of this command.  I have attached a copy of the manual I use to program it. 

My inferences were based on the file attached and what I saw when I looked at the code.

My question was about your attempt to use the undocumented DIAG command.  You could use the old DOS Debug command.    Another option would be to load up a different debugger or just use the built in Agilent tools.   But again, my PNA has no additional hardware.


Forzaman, can you zip all of your cal files and post them?  You may need to do two posts. 

[Forzaman]

Forzaman, can you zip all of your cal files and post them?  You may need to do two posts.

Sure, no problem. If you are referring to the files in D:\calfiles, I just have four files; mxcalfile_r4p12, mxcalfile_r4p21, eebudat.dat, eebudat.bak. Is this what you want?

[joeqsmith]

Forzaman, can you zip all of your cal files and post them?  You may need to do two posts.

Sure, no problem. If you are referring to the files in D:\calfiles, I just have four files; mxcalfile_r4p12, mxcalfile_r4p21, eebudat.dat, eebudat.bak. Is this what you want?

From the service manual, it appears that they stored them in two separate locations. 

copy all files that are prefixed with mxcalfile_ in the C:/Program Files/Agilent/Network Analyzer directory

The mxcalfile_ files that were stored on the D:/Calfiles directory will be restored automatically. Other files must be moved or copied manually.

If there are more located in the other directory, please include these as well.  If they are the same name, maybe just rename them and let me know where they were stored.   Could you also provide the Application Code Version you are running.  This can be found on the About page. 

[Forzaman]

Joe, zipped file is attached. Filename includes the code version. Folders in the archive indicate location. Cheers.

[joeqsmith]

Joe, zipped file is attached. Filename includes the code version. Folders in the archive indicate location. Cheers.

Thanks, I have them now.   

All pure guess work and just talking out of my ass,  looking at the raw data, it appears they have everything in 8-Byte records.  Records end in 3f-42 & 0 (I'll call that the record type).

FORZ12vs21:   Looking at your two files, index 2 & 3 are swapped.  Much of the data between these two files are identical.  Perhaps some sort of very long pointless header.   

FORZ_JQS_12vs12:  Your 12 file compared with the one I generated.    Index 0 and 4 do not match.  Perhaps an encoded serial number?   Then there is again a very long header which appears identical.   

Forz_12vs21_data:  Looking at your two files, everything is identical starting at index 4 to 95.  I suspect after this is the actual data for the receivers.

Forz_12vs21_data_flip_decimate_combine_fixpoint:
I suspect one file contains data for two receivers?  If I strip off the record type, then flip the byte order, decimate the records and convert it to some sort of fixed point we get this mess.  One column per receiver, 182 records each.   Guessing they would do a linear sweep from the 300k to 9GHz.

I'll try loading your files onto my PNA and see if it barks about a SN.  If so, then change those two index's and see what happens.  If it loads, I expect there is going to be a fairly dramatic change in the offset.   If it seems right, maybe introduce a disturbance in one receiver.   May not be too bad.  Then again, as I said, all a guess.

[Miek]

All of the values in the file are 8-byte little-endian floats. The value starting at 0x20 (let's call it x) seems to relate to the number of entries in the file. Then there are x/2 values denoting the frequency of each entry. After that, there are x*2 values which I'm guessing should be paired up into complex numbers and then matched with the frequency list.

Edit: also, the first value in the file is the total number of doubles in the file (not including itself), so (634+1)*8 = 5080 bytes and (459+1)*8 = 3680 bytes. The next value is 4 in all examples, and then the next two values are either 0,1 or 1,0 depending on the filename p21 or p12.

[joeqsmith]

Attached showing both headers and data (after decimate) for Forzaman's files on log scale.     

Yes the first index is the number of total records.  Then the number of receivers (?).   Receiver select, number of frequencies tested,  table of the frequencies tested.  Then the data, ping ponged between the two receivers.   All is double.

We can see Forzaman's system is only 6GHz and will need to be aligned after they increase the range.  Mine has data to 9GHz because I generated the files after I extended the range.  Of course it's all garbage.

Now that all this makes sense, next step is to write some software to align it. 

I am not sure why their files are missing data for the two receivers after I am guessing the range changes.   I would expect they would have data for all four.  Odd.

[Forzaman]

Attached showing both headers and data (after decimate) for Forzaman's files on log scale...

Great info. I should be able to get my hands on the required power meter and sensors to perform the receiver calibration once my unit is upgraded. The E4419B won't have the G12 or H12 option (higher accuracy certification), but will be calibrated, as will the sensors. I can send you the Cal files once this is done.

[joeqsmith]

I have to purchase or rent equipment to align it.    I did write a simple program to create the two files and set a unique value for each of the four columns.  I used the receiver display to monitor the effects and map out the receivers while changing one column at a time.    I can cause a shift across the entire range.   

I wonder what they were trying to accomplish.  I've been using mine without these files since it arrived and again, don't believe it ever had them from the factory.   Any flatness would have been addressed when performing the calibration.   This is where we need Joel Dunsmore to chime in.  He may be able to provide some much needed insight. 

When I look at your files, it seems unstable and not what I would expect.  I could understand a shift as it goes through the bands but not like what you have going on with the higher frequencies.   I wonder if you made some sort of flatness measurement and then tried to rename the files in the C:\programs...., exit and reload the PNA program (no need to reboot), how it effects the flatness.   Maybe just use the receiver display with nothing attached to the PNA's connectors.    It would also be very interesting to see your files after you align it.

Your files are basically  +/-1.  I use using 10, 20..    What's interesting is that this seems to cause other problems.  Almost like these changes are not just a function of some software math but changing something in the hardware?    Sorry  I didn't take any photos, but instead of just seeing a shift, in one channel, it caused a different channel to become unstable (shifts of several 10s of dBs.).   Really odd. 

[joeqsmith]

Under $100 and covers the entire range!
https://www.ebay.com/itm/284299377445?hash=item4231903b25:g:ztQAAOSwYipgpMWS

   

[Miek]

I really think they're meant to be interpreted as two lists of complex numbers. If you do it that way you can see that the magnitude of the first list looks plausible - it's mostly continuous with a jump at 3 GHz where the source switches to using the 3rd harmonic of the synthesizer. In 2d, it's close to 1+0j at low frequencies then plots (roughly) a circle around the origin, which makes sense since there should be some cable delay in the test.

Given the text from the service manual:

The receiver calibration is used to adjust the network analyzer receivers for a flat response
across its full frequency range. A power meter is connected to Port 1, as shown in
Figure 3-19, to establish a reference for flatness. A signal from Port 1, as shown in
Figure 3-20, is used to adjust the “B” receiver at Port 2. The adjustment is repeated using a
signal from Port 2 to adjust the “A” receiver at Port 1.

I expect that each file may only have the response from one receiver and the two files represent adjustment for each direction. Since the second list of complex numbers is purely real, this may be the power meter response and the first list is the A or B receiver response.

[joeqsmith]

"interpreted as two lists of complex numbers."

"... each file may only have the response from one receiver and the two files represent adjustment for each direction. Since the second list of complex numbers is purely real, this may be the power meter response ... "

Thanks for the post.   This makes sense.    Any thoughts as why they do this at all?   Once they know the source is level, what do they gain?  The one thing I was thinking is I often don't calibrate the instrument and this would have the potential to tighten things up.   

[Miek]

I think the goal is to meet the "Uncorrected system performance" spec. I would expect any of this error to be corrected by a full 2-port cal, so I don't think it's critical to do the adjustment.

I got quite in-depth looking into this on my E5062A. It came with only the transmission-reflection test set and I was able to enable the 2-port test set on it, and as part of that I had to generate the right calibration files to get good uncorrected performance. One was the "port characteristics" file, which turned out to be a standard 12 error-term calibration that gets loaded by default and overridden when doing your own cal.

I'd expect the PNA to have something similar somewhere and it should capture any error in receiver flatness, so it's odd to have a separate test & cal file, but the service manual has a clue - from the "Calibration Coefficient Test" it says:

f the Analyzer Fails this Test:
• If the analyzer fails tracking error terms only, perform “Receiver Calibration
Adjustment” on page 3-44 and repeat this test.
• Failure of any other error terms indicate a hardware failure. Refer to the appropriate
error term discussion in Appendix A, “Error Terms,” for a typical cause of failure. Refer
to Chapter 7, “Repair and Replacement Procedures,” for instructions on replacing the
suspected faulty component or assembly.

Maybe they found that the other error terms are far more stable than the transmission tracking error and so they only adjust that. If they were to overwrite all of the error terms, it could hide damage to the calibration kit/ports/couplers.

[joeqsmith]

I processed Forzaman's two files as complex and split out the two halves.  I think you are spot on.   

I think the goal is to meet the "Uncorrected system performance" spec. I would expect any of this error to be corrected by a full 2-port cal, so I don't think it's critical to do the adjustment.

I am the worse when it comes to calibration and will typically only do it as a last step and if I am just looking for some rough idea and don't calibrate at all.   When I got the PNA, I noticed it's a bit more error than would have liked.  This alignment would certainly improve that.   

***
Correct freq index, aligned the two files vertical to easier see what is going on.

[joeqsmith]

One odd thing I noticed, when I had the PNA create the two files if you look at the frequency table, both list 40MHz twice.  Any idea what is going on here?  Is this the point where they switch sensors? 

***
Replicates are also at 10M, 748M, 1.5G, 3G, 4.5G, 6G, 6.5G & 7.75G.   So something else is going on.   

[Forzaman]

I have to purchase or rent equipment to align it.    I did...

I didn't perform any alignment yet. Those cal files were on the unit when I received it (file dates are 2009). I only performed a PNA operator's test, which everything passed. I can look at the Receiver display.

The service manual indicates that only the A and B receivers are adjusted during the receiver alignment. Therefore it would make sense that there are only two sets of data.

[joeqsmith]

I didn't perform any alignment yet. Those ..

I figured that when I saw the 6GHz upper range in your table.  Now that Miek has sorted out the format, there's no need to supply your cal files after alignment. 

Notice how your files also have repeat measurement points at the same locations.  I think that's the last remaining question... Well,, maybe...

[Forzaman]

One odd thing I noticed, when I had the PNA create the two files if you look at the frequency table, both list 40MHz twice.  Any idea what is going on here?  Is this the point where they switch sensors? 

***
Replicates are also at 10M, 748M, 1.5G, 3G, 4.5G, 6G, 6.5G & 7.75G.   So something else is going on.

I recall Caesar mentioning in another forum that measurement points are taken at the beginning and end of each band with only a 1Hz separation between the end of one band and the start of the next.

[joeqsmith]

Nice catch.  Indeed, I needed to increase the display precision.   (9999999, 10000000).

[caesarv]

The main purpose of the mxcal files is to provide a simple default calibration.  This way, if you make an S11 measurement and place a short/open on the port, it will show a line at 0dB.  Likewise, if you measure S21 of a short thru-cable, the trace should also be near 0dB.  These files are somewhat bypassed if you perform a user calibration beforehand.  So even if there are no files, you can still make an accurate measurement by performing a user cal.  You need to perform the Receiver Adjustment in order to generate a real correction for your particular instrument.  This requires a power sensor or two that covers the entire frequency range.

For the E835xA series, the corrections do not vary all that much from unit to unit, so you can use the corrections from one unit on another.  It will not be really accurate, but it will suffice in most cases.  I have zipped my E8358A files and have included them here.

[joeqsmith]

Thanks, I downloaded them an will have a look. 

If the system has been user calibrated, does it still use the data from these files or are they only used as a default when no calibration has been performed?   

[joeqsmith]

Looking at Forzaman's 12 on left  compared with Caesarv's 12 on right. 

I wonder when you run the alignment, does the PNA set the output much lower?  I was expecting the power meter to be around 0 rather than -7. 

[caesarv]

The mxcal files are always used if available.  Then, when you perform a user calibration, the corrections are applied on top of the existing mxcal values.  I believe that there are also some second order effects with the mxcal files that deal with the phase transitions between bands....but my memory is a bit fuzzy on the exact details.

[joeqsmith]

Thanks.  Any  idea about the -7dBm power recorded from the meter?  Mine defaults to 0dBm and I assumed they would run the alignment at that level.   

[joeqsmith]

Assuming the datasheet uncorrected values are what we are looking for, my system without these files is no where near that. 

I don't have a good way to measure power  but wanted to try and create these files.   I added support to my software for my Signal Hound BB60C and automated the alignment process.  The SA is limited to 6GHz and is not a good reference.  My software uses 0dBm when performing the alignment.  After 6GHz, I fudged the data.  Assuming the SA was rolling off, I filling out the array with the value measured at 5.5GHzish.   So ignore the data beyond 6GHz.

It appears to improve things a fair amount and with my poor attention to calibration, it may be worth renting a meter to align it.