Agilent E8357A

[joeqsmith]

I am getting a sinking feeling about the source leveling.  Could it be that they were writing directly into the PNAs memory.  I tried some of the SCPI commands to read out the source calibration (not the commands which use the GPIB as the master).   So far I have been able to reliably crash the VNA software and Ethernet connection.      
 
I wonder if two different teams worked on the source and receiver leveling.  Maybe that's why they are so different.  They could have had everything stored in their custom MX files.   I bet there are some good stories about the culture within Agilent during this time.     

diag:poke/peek:byte,int&long
SENSn:CORR:CSET:STAT/SEL OFF/ON

[joeqsmith]

After unsuccessfully sorting out the source leveling, I decided to take a step back and try a very simple test.   The following is from the programming manual:

Source:Power:Correction Commands
Controls the source power correction features of the analyzer.

Note: the SOURce:POWer:CORRection:COLLect:ACQuire command, used to step the PNA and
read a power meter, cannot be sent over the GPIB. Use one of the alternative methods described
in the command details.

SOURce<cnum>:POWer<port>:CORRection[:STATe] <ON|OFF>
(Read-Write) Enables and disables source power correction for the specified port on the specified channel.

Parameters
<cnum> Any existing channel number. If unspecified, value is set to 1
<port> Port number to correct for source power. If unspecified, value is set to 1.
<ON|OFF> ON (or 1) turns source power correction ON.
OFF (or 0) - turns source power correction OFF.
Examples SOUR:POW:CORR ON
source1:power2:correction:state off

Query Syntax SOURce:POWer:CORRection[:STATe]?
Return Type Boolean (1 = ON, 0 = OFF)

Overlapped? No
Default OFF (0)

While from the description, this would seem to be related to the source's alignment,  I ran another sweep with the power meter attached.   I then sent the SOUR:POW:CORR OFF command.  The PNA flagged no errors or warnings.  I then took another sweep.   As you can see, it has no effect.  So these commands must be for some other feature but not the alignment.

[caesarv]

For the early PNAs, such as the E835xA, the source adjustment values are stored on the individual boards in EEPROM.  Most boards have a 512 byte EEPROM (not kB!)  This, of course, is not much memory but it is enough to store values for each band.  The receiver (mixer) cal had too much data, so it had to be stored in files on the HDD.  Later PNAs had large flash memory on the Test Set Mother Board and that was used whenever data had to be stored....with a few exceptions.
The EEPROM on each board is divided up into a Header (16 4-byte values) and the remainder. 

You can look at the contents of this by running the ViewEEHeaders program.  It will show the headers and the data.  You can even edit those values, although I do not recommend doing so.  Changing some values can really (and hopelessly) screw up operation.  There is a way to store all the data to a backup files....I suggest doing that. 

[joeqsmith]

FYI, this program requires a password.  I assume it uses blank, agilent or tsunami.  Mine is tsunami.   Using the View, Minimize Application, we can see a program called EEBACKUP.EXE located in the service directory.   It appears the PNA software must be running.   Selecting the Backup EEPROM causes a crash. 

Ignoring the backup and looking at the contents of the source board, it's not at all what I would expect for a precise leveling adjustment.   I wonder if these hardware adjustments are separate from the leveling adjustments.   Or, maybe you can't actually get the source anymore level than what I have shown.   

I would have guessed that they wanted to be able to send out a replacement board and not have to deal with send the data on a separate media.  If you still had to send the instrument in for alignment anyway, this really makes little sense.   

[joeqsmith]

Oddly enough, it recovers?   A new menu is then displayed.   My system sits on the LAN, making it easy to transfer files.  Once you get the save and completed message the software creates 4 files.   Interesting if they have these recrcal12&21 files which are different than the MX files.   All 4 files are ASCII.   I have attached the EEPROM.DAT file from mine (renamed to .TXT).

[Forzaman]

I don't have any need to go beyond 6GHz at the moment. Obtaining the time domain option was my main goal.

The only reason I was wanting to increase the frequency range was to increase the time domain resolution.   I wanted to use the PNA as a comparison to the $120 LiteVNA.  They limit the LiteVNA's firmware to 9.3GHz.   Attached are two of the circuits I demo'ed  (splitter with an LC tank and a low pass filter).   The data from the PNA is pretty much what I would expect.   

You can see the demo here if interested:

Finally got around to looking at the video. Very nice software... must have taken you a long time to develop. I hope the LiteVNA folks funded some of the development. LOL

I should have all the equipment on hand in the next week or so to run the alignment. Let me know if you want me to provide  any information.

[joeqsmith]

Thanks.  The software started with my first VNA a few decades ago and continues to evolve.   It's self funded except for a friend had purchased the one of the LiteVNAs and my first NanoVNA for me to help them understand how to use a VNA.       

The suppliers have provided their products to some of the larger YT channels for reviews (unboxing).   I haven't received anything from them and have not asked.  Now if Keysight offered to set me up with some new equipment, I would be open for chat.    

I'm basically stuck with the PNA.   If you decide to increase the frequency range, it would be interesting to see how level your source was before and after alignment.  The problem, I am not sure you can get that data without writing custom software for your setup.  It may help answer what to expect if I ever were able to align it. 

[joeqsmith]

I should have all the equipment on hand in the next week or so to run the alignment. Let me know if you want me to provide  any information.

If you have backed up your EEPROM like I show above and assuming you are aligning the source, it would be helpful if you backed up the EEPROM after alignment as well.  Then provide both files.  This will tell us if this is where they are storing this data and if so, which locations changed.   

[Forzaman]

I should have all the equipment on hand in the next week or so to run the alignment. Let me know if you want me to provide  any information.

If you have backed up your EEPROM like I show above and assuming you are aligning the source, it would be helpful if you backed up the EEPROM after alignment as well.  Then provide both files.  This will tell us if this is where they are storing this data and if so, which locations changed.

Ok... Will do.

[Forzaman]

I backed-up my EEPROM. It saved a eebud.dat file in D:/calfiles. It is quite a bit different than the original eebud.dat file that dates back to 2004. I then selected the restore EE data, which prompted me for a password (tsunami). I exited though without performing a restore. Did you get the "save EEPROM data" menu after following through with the restore? I can't get that menu to show up.

[joeqsmith]

After selecting save.   I never tried to restore.

[Forzaman]

Ok. I thought that is how you got to the second EEPROM save and restore menu where you can select the location to save the backup file. I don't get that menu... maybe I have older firmware. By default it saves the backup to D:/calfiles, and the name of my file is eebudat.dat not EEPROM.dat.

[joeqsmith]

Did you select the Specify Location like I show?  I wanted to save mine to my local PC, not the PNA and that may be the reason for the difference.  You could also check that version is the same. 

Note how that second EEPROM save is pointing to E:\MXCAL which is the my desktop PC.   

[joeqsmith]

Also, if you don't mind posting the two files (before and after).  If you add the extended range and realign it again, I would like to have that file as well. 

If Keysight has some sort of software for that power meter, it would be very nice to see how tight your meter is compared with the VNA.   The problem is you would need to use CW and manually set the PNA.  More trouble than it's worth.   

[Forzaman]

I don't get the menu that asks where to save the EEPROM data. I get the first menu (screen shot attached). When I select Backup EEPROM a message pops-up saying the EEPROM was backed-up (no crash), but didn't say where. When I selected Restore EE from backup, a pop-up window appeared asking for the password, after that it asked if I wanted to restore the  EEPROM from D:\calfiles\eebudat.dat without providing an option to select from another location. I do not get the 2nd menu you show where you can select the file location. It seems my EEBackup program defaults to the D:\calfiles folder.

[joeqsmith]

Check the EEPROMTOOL.EXE.   Remember mine crashed when I tried to run BACKUP.EXE.   When I went to minimize the PNA software, I saw that dialog.   Having tried both, it may be from the other program.   If you don't see it there,  I'll try and replicate the steps I took.   It's very possible that EEBACKUP.EXE is hardcoded to store the data to the D:\calfiles which may explain why it crashed on my PNA as I never setup the second partition.   You would think that it would post something more useful, like "D:\calfiles not found" "Would you like to backup the data to another location"...   

[Forzaman]

I attached a document that describes the procedure to use multiple drives on a PNA, or a single drive on multiple PNAs. It mentions that on older PNAs, the EEPROM data is backed-up to D:\calfiles.

[joeqsmith]

Currently my PNA has a single SSD with only one partition setup.  While the original HDD that was supplied with my PNA has a second partition which would have been identified as D:\,  I have no use for it and did not set it up.   The original eebudata.dat on my PNA was stored under D:\calfiles.   When backing up the data, I had it save to  E:\MXCAL which again, is the my desktop PC.  I thought I had made all of that clear before but I am guessing you feel it somehow matters where they are stored?   

One reason I wanted the PNA was for the Ethernet connection.  With it being Windows based, it's a breeze to interface with it.  Not just moving files but also for controlling it. 

I have not had the PNA on today and didn't try the other program to see if this was how I was able to select the target location. 

[Forzaman]

I just provided the document to confirm your suspicion that the older PNAs default to the D:drive for EEPROM data backup. Other than the EEPROM backup, it appears that it doesn't matter where files are stored. No need to try and reproduce the menu that allows the user to specify the location... again, I just mentioned that I couldn't get it for your information since you posted your observations. I'm happy with it defaulting to D: drive.  BTW, I bought a SSD (Transcend 64GB) to see if it would speedup the OS, but for some reason my duplicator doesn't work with the SSD as the target. May have to use cloning S/W instead.

[joeqsmith]

I did try to replicate my findings but ran into some really strange problem.  Maybe you can reproduce it.

I tried to run the EEBACKUP.EXE tool again and get the same crash.  I then ran the EEPROMTOOL.EXE and could select the target location and file name as before.   So, this is the tool I used to create the EEPROM.DAT file I uploaded.   

Next I ran a diff between the original EEBUDAT.DAT file that came with the PNA.  These two files are not the same.  Even their sizes differ.

Next I setup a FAT32 partition and set it to to drive D.  I did not install any files or create any directory structures on it.  I then ran the EEBACKUP.EXE.  This time no obscure error and it counts as it reads the data.  It then creates a new directory D:\Calfiles with EEBUDAT.BAK and EEBUDAT.DAT.   Running a diff on these to files, they match.   

Next I ran a diff on them against the original EEBUDAT.DAT file that came with the PNA.  These do NOT match!!!   

On a hunch, I reran the EEBACKUP.EXE program and created two new files.   Running a diff on these to files, they again match.   I then ran a diff between them and the previous ones I created.  These do NOT match!!! 

I'm glad I didn't try a restore.

[Forzaman]

Wow... that is strange. I'm glad I didn't try a restore either. When I backed up the EEPROM using EEBACKUP.EXE, it overwrote the original eebudat.dat file, but didn't touch the original eebudat.bak file. Comparing the files, the sizes were different and the data was quite a bit different as well. I'll try the EEPROMTOOL.EXE in the next day or two... not playing in the sandbox today. My Rx alignment is delayed a bit... the 8482A power sensor I sourced needs calibration. Cheers.

[joeqsmith]

I had backed up the entire contents of the original drive and then made an image.  I archived the contents locally and packed away the drive just in case.    For this test, I just renamed to files to append Set1, Set2 ... to the name and then archive them to the local PC.   You could just rename them and leave them inside your  D:\calfiles area.  Then just run the software again and let it create two new files.   Rinse and repeat.   

Maybe the software isn't smart enough to detect what hardware is installed.  It may be scanning for data that isn't present and we get some randomness in the file.  After seeing it crash and burn with an obscure error with a missing drive letter,  I don't have a lot  of confidence that this is some well polished code.   It's an engineering tool, much like my own software.      It would be nice to know what is happening as it may help in decoding the alignment data for the source.

I take it you had the higher frequency detector already in cal.   Did you get one that takes to 9GHz or just 6?

Looks like Caesar may have returned to the rat race....

Caesar Valenti  Nov 27   #130804 
I have a 500MHz CPU disc image that I could post...I just need to find a place to put it.  It is at work right now, so it will have to wait until Monday.

[Forzaman]

I lucked out with the test equipment. A company that I'm consulting for has all the equipment on hand that is called up in the manual (8482A sensor, E4412A sensor, E4419B meter). The 8482A has a range of 100kHz to 4.2GHz, and the E4412A is 10MHz to 18GHz. The 8482A is not in active use, so I told them I would pay to get it calibrated for borrowing their equipment. They may consider selling everything to me since they mainly use newer equipment now. I may just sell my power meter (Anritsu ML2438A w/ sensors) and buy theirs to support the PNA.

[Miek]

It would be nice to know what is happening as it may help in decoding the alignment data for the source.

If you have a look under the Edit menu in the ViewEEHeaders utility (aka eepromtool.exe), it has a rough description of the parameters for each band (pic attached). Also, decompiling sourcecal.exe gives some slightly clearer names:

Code: [Select]

  loc_00413212: If 0042C3DCh <= 0 Then
  loc_00413248:   var_eax = call Proc_3_15_42A130("+++++ Band " & CStr(var_0042C3DC) & " +++++", , )
  loc_0041326D:   If 0042C166h >= 8 Then
  loc_0041326F:     var_eax = Err.Raise
  loc_00413275:   End If
  loc_004132D1:   var_eax = call Proc_3_15_42A130("DetOffDac(" & CStr(var_0042C166) & ")= " & CStr(ecx+edx*4+00000040h), , )
  loc_004132FE:   If 0042C166h >= 8 Then
  loc_00413300:     var_eax = Err.Raise
  loc_00413306:   End If
  loc_00413363:   var_eax = call Proc_3_15_42A130("BreakDac(" & CStr(var_0042C166) & ")= " & CStr(edx+eax*4+00000060h), , )
  loc_00413390:   If 0042C166h >= 8 Then
  loc_00413392:     var_eax = Err.Raise
  loc_00413398:   End If
  loc_004133F3:   var_eax = call Proc_3_15_42A130("Power1Dac(" & CStr(var_0042C166) & ")= " & CStr(eax+ecx*4), , )
  loc_00413420:   If 0042C166h >= 8 Then
  loc_00413422:     var_eax = Err.Raise
  loc_00413428:   End If
  loc_00413484:   var_eax = call Proc_3_15_42A130("Slope1Dac(" & CStr(var_0042C166) & ")= " & CStr(ecx+edx*4+00000020h), , )
  loc_004134B1:   If 0042C166h >= 8 Then
  loc_004134B3:     var_eax = Err.Raise
  loc_004134B9:   End If
  loc_00413519:   var_eax = call Proc_3_15_42A130("LogOffDac(" & CStr(var_0042C166) & ")= " & CStr(edx+eax*4+00000080h), , )
  loc_00413546:   If 0042C166h >= 8 Then
  loc_00413548:     var_eax = Err.Raise
  loc_0041354E:   End If
  loc_004135AD:   var_eax = call Proc_3_15_42A130("SlopeOffDac(" & CStr(var_0042C166) & ")= " & CStr(eax+ecx*4+000000A0h), , )
  loc_004135DA:   If 0042C166h >= 8 Then
  loc_004135DC:     var_eax = Err.Raise
  loc_004135E2:   End If
  loc_00413641:   var_eax = call Proc_3_15_42A130("DeltaDac(" & CStr(var_0042C166) & ")= " & CStr(ecx+edx*4+000000C0h), , )
  loc_0041366E:   If 0042C166h >= 8 Then
  loc_00413670:     var_eax = Err.Raise
  loc_00413676:   End If
  loc_004136D6:   var_eax = call Proc_3_15_42A130("Power2Dac(" & CStr(var_0042C166) & ")= " & CStr(edx+eax*4+00000100h), , )
  loc_00413703:   If 0042C166h >= 8 Then
  loc_00413705:     var_eax = Err.Raise
  loc_0041370B:   End If
  loc_0041376A:   var_eax = call Proc_3_15_42A130("Slope2Dac(" & CStr(var_0042C166) & ")= " & CStr(eax+ecx*4+00000120h), , )
  loc_00413797:   If 0042C166h >= 8 Then
  loc_00413799:     var_eax = Err.Raise
  loc_0041379F:   End If
  loc_004137FE:   var_eax = call Proc_3_15_42A130("Power3Dac(" & CStr(var_0042C166) & ")= " & CStr(ecx+edx*4+00000140h), , )
  loc_0041382B:   If 0042C166h >= 8 Then
  loc_0041382D:     var_eax = Err.Raise
  loc_00413833:   End If
  loc_00413893:   var_eax = call Proc_3_15_42A130("Slope3Dac(" & CStr(var_0042C166) & ")= " & CStr(edx+eax*4+00000160h), , )
  loc_004138BE:   0042C166h = 0042C166h + 00000001h
  loc_004138CD:   GoTo loc_0041320B
  loc_004138D2: End If
  loc_004138F9: var_eax = call Proc_3_15_42A130("DacPer1dBSlope = " & CStr(var_0042C058), , )
  loc_00413933: var_eax = call Proc_3_15_42A130("Yig slope = " & CStr(var_0042C064), , )
  loc_0041396E: var_eax = call Proc_3_15_42A130("PMYO = " & CStr(var_0042C05C), , )
  loc_004139A9: var_eax = call Proc_3_15_42A130("Yig offset = " & CStr(var_0042C060), , )
  loc_004139CF: var_eax = call Proc_3_15_42A130("===========================================================", , )

[joeqsmith]

That's a very good deal.   If they sell you the equipment, you may have to start a small side alignment business....  Road trip!!       Ideally I would like to be able to use any power meter (assuming it is up to the task) to align it.

I had looked at the header when Caesar mentioned it.