¿ªÔÆÌåÓý

  1. HP-Agilent-Keysight-Equipment
  2. Messages
Expanded Topics Messages
Date
Re: BNC that does not have the bayonet lugs

 

Mike,

On the BWD instrument these connectors are recessed deep in an insulator where the rotating part of the mating BNC connector is nestled down inside the same insulator. This prevents any ability to rotate it in the normal locking sense because you can't get to it. The recess obviously keeps all metal portions of the connector away from grabbing probably due to the high voltage rating of this instrument and related safety factors.

Since the BWD instrument inputs are purely differential and each channel has two inputs the shields of the probe cables are at ground level for their normal noise shielding purpose. Since this instrument is designed for connection to the AC mains for analysis purposes the inputs are rated to 1000V. Even with the BNC shells at ground BWD still apparently designed in the extra level of protection by recessing the connectors.

Greg
Re: Off Topic - Looking for assistance with power sensors

 

"Razvan Popescu via groups.io" <yo8ryr@...> writes:

Hi,

On 22/05/2025 22:11, Sven Schnelle via groups.io wrote:
This is likely just coincidence because they are all calibrated by
keysight - it might be at any location in the EEPROM.
Yes, that is correct. The start address formula x*8+9 applies and you
can use any address as long as you are following that formula.
Practically you can start with your table at address 9.

Without updating the checksum of the table the power meter will not
accept the new data... I attached a program i used to rewrite the
calibration data of my sensor. Keysight doesn't do any business with
private persons, so there was no other way i guess.
I didn't have any issues with the old HP branded E4413A. I didn't see
anything that would look like a checksum. The end of the EEPROM in my
case had many bytes written with value 255. Maybe the first 9 (0 to 8)
addresses that cannot be used for calibration table are used for
checksum and other data?!

Is it possible that the old E441XA sensors don't have a checksum?
Maybe the checksum was added later in E93XXA series?!
Can't say because i don't have many power sensors (namely an E9304A, and
two a ECP-18A + E4412A).

The eeprom contains an eeprom header in the following format (everything
in big endian format):

struct header {
uint8_t version; /* 0x00 */
uint16_t unknown_0x01; /* 0x01 */
uint16_t tablecount; /* 0x03 */
struct tabledesc tables[0]; /* 0x05 */
} __packed;

tablecount is the number of calibration tables, version the overall
version of the eeprom. The table descriptors are starting at offset 5
in the eeprom, and each table header looks like this:

struct tabledesc {
uint16_t offset;
uint8_t type;
uint8_t version;
uint16_t size;
uint8_t checksum;
} __packed;

'offset' is the absolute start location in the eeprom, 'type' what kind
of table this is (cali factors, temp compensation, linearity,
etc). 'version' which format the table has - for most of the tables at
least two versions exist. 'size' is how many bytes the table contains.
'checksum' is the sum of all bytes in that tables. I haven't seen that
this is optional, but can't say for sure.

An entry in the calibration factor table is:

struct calfactor_entry {
uint32_t freq; /* 0x00 in khz */
uint16_t calfactor_low; /* 0x04 */
uint16_t calfactor_high; /* 0x06 */
} __packed;

which is the 8 bytes in length you mentioned.
Re: BNC that does not have the bayonet lugs

 

Maybe for a quick connect/disconnect? - Mike

Mike B. Feher, N4FS
89 Arnold Blvd.
Howell NJ 07731
908-902-3831

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Greg Muir via groups.io
Sent: Thursday, May 22, 2025 6:30 PM
To: [email protected]
Subject: Re: [HP-Agilent-Keysight-equipment] BNC that does not have the bayonet lugs

Beyond conjecture.....

BNCs used in the BWD 880 PowerScope.

Greg







--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
Re: HP8566B with YTO unlock indication appears to have no YTO output at all

 

I swapped out the entire A13 (I think that's the right number) YTO/PLL assembly with one from an old 8566A carcass that I was using for another project. The YTO output was good and strong, but way off in frequency since the YTO is now different and the coil driver system is at the original's tweak settings, which I don't want to mess with unless I have to. It still shows YTO unlock warning - not surprising but it would have been nice if it came out close to right on and started working. Oh well. Also, some of the mounting screws were missing, so someone had been looking in here before.
?
So, it looks like it's narrowed down to something in A13. I still have some swapping options to try out yet, then better measurements on the supplies and support circuitry, then probably a bunch of adjustments, depending on the true cause.
?
Ed
Re: HP 478A Thermistor Sensor. Input return loss and matching

 

I spent some time looking at my early 478A sensor again this evening and removed the ferrite (that I had added) and also bypassed the 2.7R damper resistor R1 fitted by HP. I then looked at the return loss on a VNA and also looked at the frequency response when the 432A + 478A was used to level a HP 83752A sweeper.?
?
The plots below show that with no damping the input return loss shows a classic zigzag shaped resonance just above 50 MHz. The VSWR is actually slightly better at 50 MHz without the damper but the VSWR obviously gets much worse at 53.5 MHz.?
?
With the 2.7R resistor R1 removed, the frequency response using the sweeper shows a narrow upwards blip of almost +0.3dB at 53.5 MHz and this is due to the undamped resonance here. The resonance draws energy away from the thermistors and this degrades the efficiency. The blip is positive and this shows that the efficiency must be lower in the dip as the sweeper has to put out a bigger signal to get the same output from the 478A sensor.?
?
The response from 10 MHz to 50 MHz is exactly as a simulation with about 0.1dB change from 10 MHz to 50 MHz. If I add a ferrite, this completely removes the blip at 50 MHz but it does degrade the efficiency down at 10-20 MHz. So there is no free lunch with the ferrite. I still haven't decided on the best choice of ferrite here and I may also try increasing the capacitance after the ferrite to be similar to the later 478A sensor.
?
I think this experiment does indicate that the 2.7R resistor R1 was added by HP to try and tame this internal resonance. The combined capacitance value of C3 and C4 may well have something to do with the operation of the 431 meter, but I think HP added some damping resistance to one of the capacitors to tame the resonance at 53 MHz and this may be partly why these parts are marked as factory selected.?
?
?
?
?
--
Regards
Jeremy
HP8566B with YTO unlock indication appears to have no YTO output at all

 

I have never encountered a bad YTO in a 8566, but this might be one. I just got this unit and had some time to check it out, assuming typical small problems. I'll have to bring a scope out to my truck next - it's the only place left where I can park enough equipment and have some flat space to actually work on it. I figured the unlock was for common reasons, and looked first with a counter at the 1LO output and found nothing. Since microwave counters can't get a reading sometimes if the frequency is flailing around, I next put a 436A and 8484A on to see if there's any RF power at all regardless of frequency - nope.
?
I haven't exhaustively checked the possible reasons for no YTO signal yet, so all the supplies will be next up for ripple etc - the DC values seem OK but the scope will say for sure. I have to get familiarized again with this beast since I haven't worked on the main RF section guts in a few years. Then all the usual other stuff to check out in the connections, signal paths, and support circuits. So far everything looks normal control- and display-wise, except there's no input signals showing above the noise floor in any band, which makes sense if there's no 1LO at all. I think all the internal PLL and other indicator LEDs are showing normal conditions. The unit overall looks very clean inside, and complete. One odd thing is that someone in the past had put the little front panel SMA 2IF I/O link in the wrong spot - the IF out was tied to the 1LO and the IF in was terminated. I don't think this could have possibly hurt anything.
?
Should the worst be the case, I have spare YTOs, but I'm hoping it's something simple in the circuitry to be discovered.
?
Anyway, while I study and revisit the manual and start poking around, I figured I'd check to see if anyone has seen this sort of problem before.
?
Ed
Re: BNC that does not have the bayonet lugs

 

Beyond conjecture.....

BNCs used in the BWD 880 PowerScope.

Greg

P5226199b.JPG

Re: Off Topic - Looking for assistance with power sensors

 

Hi,

On 22/05/2025 22:11, Sven Schnelle via groups.io wrote:
This is likely just coincidence because they are all calibrated by
keysight - it might be at any location in the EEPROM.
Yes, that is correct. The start address formula x*8+9 applies and you can use any address as long as you are following that formula.
Practically you can start with your table at address 9.

Without updating the checksum of the table the power meter will not
accept the new data... I attached a program i used to rewrite the
calibration data of my sensor. Keysight doesn't do any business with
private persons, so there was no other way i guess.
I didn't have any issues with the old HP branded E4413A. I didn't see anything that would look like a checksum. The end of the EEPROM in my case had many bytes written with value 255. Maybe the first 9 (0 to 8) addresses that cannot be used for calibration table are used for checksum and other data?!

Is it possible that the old E441XA sensors don't have a checksum? Maybe the checksum was added later in E93XXA series?!

Regards,
Razvan
Re: Optiion upgrade HP 8753C/B

 

Correction: when running service code 56 it is "OPTION COR FAIL".?
Re: Optiion upgrade HP 8753C/B

 

Hello All,?
?
Caesar graciously provided me with the option codes to install option 006 on my 8753C several months back. I have finally located an 85047A for a reasonable price, and I am trying to install the code for Opt 006 to enable it. After entering the code Caesar provided, I keep getting the error "CORRECTION CONSTANTS NOT STORED" while running service code 56, and I am still not able to select higher than 3GHz. I have moved the jumper on the A9 to the "ALT" position but it does not seem to be accepting the upgrade.?
?
Also, I am getting the same error when trying to run the service code "55" for serial number correction.?
?
I have been following the instructions here:?Instalation note 8753C.pdf?as well as the instructions beginning on page 123 of the HP Service Manual here:?
?
Has anyone run into this situation where the option codes are not accepted??
?
Re: BNC that does not have the bayonet lugs

 

Already tons of various and diverse messages that are ultimately just conjectures... Paul, please post a photo of the connector you're talking about. Indeed, we often say that a small drawing is worth far more than a long speech. In your case, a small drawing would truly be the best. Thanks in advance.
Re: Off Topic - Looking for assistance with power sensors

 

"Razvan Popescu via groups.io" <yo8ryr@...> writes:

Hi,

I found partially my notes regarding E4413A that I had from a friend.
What I did was the following:

1) Before doing any EEPROM sensor operations run the following command
to stop the auto trigger from the power meter:

INIT:CONT OFF

2) Read the calibration table:
"DIAG:DET:EEPR? MemoryAddress,NumberOfBytesToRead"
Do not read more than 100 bytes, it will crash the power meter. In my
case an E4418B. Table size depends on how many frequency points were
calibrated. You can add additional points if you want for specific
frequencies like ham radio bands. There is enough space in the EEPROM.
Only the calibration table for the 26.5 GHz model was exactly 256
bytes.
H33 model will have it bigger.

Important thing to note is that the calibration table starts at 569
for E441XA sensors.
This is likely just coincidence because they are all calibrated by
keysight - it might be at any location in the EEPROM.

You can only write at specific locations based on the following
formula:
Start byte address in the EEPROM for each conversion entry is x*8+9
First 4 bytes are the frequency, next 2 bytes are the low CF and last
2 bytes are the high CF.

I will give an example below what will be the bytes values for a 50
MHz frequency and CF LOW 100% and CF HIGH 100%.

(0 * (2 ^ 24) + 0 * (2 ^ 16) + 195 * (2 ^ 8) + 80) / 1000 = 50 (MHz)
So if we consider that starting address is 569 for the E441XA sensors
you will need to write the following bytes at the address starting
569.

569 -> 0
570 -> 0
571 -> 195
572 -> 80
---- This will cover the 4 bytes for the frequency at 50 MHz ----

Now the next 2 bytes will be for the CF LOW:

100 * (64 * 256 + 0)/2^14 = 100 (CF LOW 100%)

573 -> 64
574 -> 0

Since the value for the CF HIGH is also 100 the same bytes will be
written to the addresses 575 and 576.
Without updating the checksum of the table the power meter will not
accept the new data... I attached a program i used to rewrite the
calibration data of my sensor. Keysight doesn't do any business with
private persons, so there was no other way i guess.
Re: Off Topic - Looking for assistance with power sensors

 

Hi,

I found partially my notes regarding E4413A that I had from a friend.
What I did was the following:

1) Before doing any EEPROM sensor operations run the following command to stop the auto trigger from the power meter:

INIT:CONT OFF

2) Read the calibration table:
"DIAG:DET:EEPR? MemoryAddress,NumberOfBytesToRead"
Do not read more than 100 bytes, it will crash the power meter. In my case an E4418B. Table size depends on how many frequency points were calibrated. You can add additional points if you want for specific frequencies like ham radio bands. There is enough space in the EEPROM.
Only the calibration table for the 26.5 GHz model was exactly 256 bytes.
H33 model will have it bigger.

Important thing to note is that the calibration table starts at 569 for E441XA sensors.

You can only write at specific locations based on the following formula:
Start byte address in the EEPROM for each conversion entry is x*8+9
First 4 bytes are the frequency, next 2 bytes are the low CF and last 2 bytes are the high CF.

I will give an example below what will be the bytes values for a 50 MHz frequency and CF LOW 100% and CF HIGH 100%.

(0 * (2 ^ 24) + 0 * (2 ^ 16) + 195 * (2 ^ 8) + 80) / 1000 = 50 (MHz)
So if we consider that starting address is 569 for the E441XA sensors you will need to write the following bytes at the address starting 569.

569 -> 0
570 -> 0
571 -> 195
572 -> 80
---- This will cover the 4 bytes for the frequency at 50 MHz ----

Now the next 2 bytes will be for the CF LOW:

100 * (64 * 256 + 0)/2^14 = 100 (CF LOW 100%)

573 -> 64
574 -> 0

Since the value for the CF HIGH is also 100 the same bytes will be written to the addresses 575 and 576.


3) Write the calibration table:
DIAG:DET:EEPR MemoryAddress,ValueOfByte

Based on the values above the commands should be:
INIT:CONT OFF
DIAG:DET:EEPR 569,0
DIAG:DET:EEPR 570,0
DIAG:DET:EEPR 571,195
DIAG:DET:EEPR 572,80
DIAG:DET:EEPR 573,64
DIAG:DET:EEPR 574,0
DIAG:DET:EEPR 575,64
DIAG:DET:EEPR 576,0

This will update the sensor EEPROM for the 50MHz CF value only.
You will need to repeat the process for all frequency points that you need.

For the H33 you will have even more points but there is enough space.
I didn't figure it out where is the EEPROM entry for the Standard vs OPT H33 to convert a normal sensor to the H33 model.

When you finish you can run INIT:CONT ON or just Preset or reboot the power meter. It will activate the trigger again by default.

New sensors like E93xxA also have a temperature compensation table but I never had one to investigate it and even the broken ones on eBay are too expensive. I was told that hardware for 6 GHz and 18 GHz is the same but it is missing the calibration table.

I hope it helps. If someone can build a python script to automate the process it would be great, my programming skills are not very good and now I don't really have any free time... This would be a project for the winter.

Regards,
Razvan

On 22/05/2025 16:38, George/Gyorgy Albert via groups.io wrote:
Sorry, correction: for writing this is the right form: "DIAG:DET:EEPR eepromaddress, eepromvalue" (the ? must be removed).
BR,
G
On 5/22/2025 5:36 PM, George/Gyorgy Albert via groups.io wrote:
EEPROM writing, if my notes are correct it is "DIAG:DET:EEPR? eepromaddress, eepromvalue".
Re: Off Topic - Looking for assistance with power sensors

 

"VeeCal" <Sales@...> writes:

Fantastic!

Okay, so this makes me feel a bit better. I was thinking I was the
only one out here that wanted to try this. Something
that has been made abundantly clear to me is to capture the data from
the eeprom before attempting to write to it, just
in case the file becomes corrupted I have a backup copy to restore
from. With this in mind I will work towards a script
to capture this in all instances.
Be careful. The EEPROM clock line is shared with the chopper pins. I'm
assuming they are using some phantom powering of the power sensors
electronics. Likely there were no pins left and they wanted to stay
compatible with older power sensor.

Downside is that you have to wait after writing each byte to the EEPROM.
I used the following script after bricking my sensor a few times:

------------------------------------------------------------
#!/usr/bin/python3

import pyvisa
from functools import partial
import time
import sys
rm = pyvisa.ResourceManager()
inst = rm.open_resource('TCPIP0::192.168.0.50::gpib0,13::INSTR')

#inst.write("DIAG:TEST 16")
i=0
with open(sys.argv[1], "rb") as file:
for char in file.read():
notmatch=1
while notmatch:
print(f'{i}', end='\r')
value = inst.query(f'DIAG1:DET:EEPR? {i},1')
time.sleep(0.1)
if int(value) != char:
print(f'writing offset {i}, data {char}, old {int(value)}')
inst.write(f'DIAG1:DET:EEPR {i},{char}')
time.sleep(0.1)
else:
i = i + 1
notmatch=0
file.close()
--------------------------------------------------------

This reads each byte, and if it differs reprograms it until it
matches. Never ever abort the program, this will brick your sensor. And
it is all your fault if the script doesn't work for you. ;-)
Re: Off Topic - Looking for assistance with power sensors

 

"F1EKU via groups.io" <rfconsulting.fr@...> writes:

According to HPAK's technical documentation, it's impossible to write
new calibration factors into the sensor because
each time it requires calculating a checksum that the EPMs of the
E4416/17/18/19 series cannot compute. They explain that
for this, we must use the newer EPMs from the N1911/12/13/14
series. Personally, I've been able to read a sensor's entire
block and write it back into another probe, but changing one or more
values within the block always resulted in the
inability to initialize the modified probe on an E44XX series power
meter. Of course, HPAK uses an external program
capable of calculating the checksum when they calibrate a sensor upon
request and write the complete block, even with an
E44XX power meter. Does anyone know the solution for calculating the
checksum?
Yes, i reverse engineered the EEPROM format of the E9XXX power sensors
because i wanted to add option H18 to my E9304A. The EEPROM contains
different tables, and each table header contains a simple 'add all
bytes' style checksum. But one has to be very careful when writing the
EEPROM - if the EEPROM contents are not valid, the power meter shows an
error message (or even locks up completely). Communication with the
power sensor is no longer possible and you need some tricks to
re-establish communication.
Programming codes for option 002 and option 003 for 8663A

 

We are in the middle of upgrading our software to support the RS FSMR measuring receiver and came across a section of the test for pulse and phase mod that we would like to automate. The current test is done manually (which is fine) but we thought it would be fun to snazzy it up by fully automating it. Kicker is, we can find nothing anywhere on the internet for commands to control either 002 or 003. The manuals on the net are SN specific and only seem to reference the base unit. I scoured the Wiki repository here and came up zilch on that as well.

Is it possible there are no commands to control this or would someone be able to point me in the direction of where we should be looking?

With respect, Mike
Re: Off Topic - Looking for assistance with power sensors

 

Fantastic!

Okay, so this makes me feel a bit better. I was thinking I was the only one out here that wanted to try this. Something that has been made abundantly clear to me is to capture the data from the eeprom before attempting to write to it, just in case the file becomes corrupted I have a backup copy to restore from. With this in mind I will work towards a script to capture this in all instances.
Re: Off Topic - Looking for assistance with power sensors

 

Thank you for the response. Yes, we have a lab that is asking for this but again it is not something I have played with.

If you would not mind, I would like to speak to you to get your insights on how to proceed or even if we should proceed. Please send me an email to sales@... I will show you what we have so far and what we would like to try. At the moment we are adding in a RS FSMR measuring receiver as a driver to the 8663A calibration program. THAT is a NICE receiver!?
Re: Off Topic - Looking for assistance with power sensors

 

Sorry, correction: for writing this is the right form: "DIAG:DET:EEPR eepromaddress, eepromvalue" (the ? must be removed).

BR,

G

On 5/22/2025 5:36 PM, George/Gyorgy Albert via groups.io wrote:
EEPROM writing, if my notes are correct it is "DIAG:DET:EEPR? eepromaddress, eepromvalue".
--
Gy?rgy Albert
Mob +40-722-304534
Re: Off Topic - Looking for assistance with power sensors

 

Hi,

A few years ago I also tried to find out the calibration tables of the E4412/4413 power sensors, using my E4418B power meter. The "DIAG:DET:EEPR? eepromaddress, 1" command was definitely working (and returned the EEPROM location content), where I looped eepromaddress from 0 to 2047 (the address seems truncated to 11 bits, so using addresses higher than 2047 interprets the modulo 2048 part). I compared the read value with the dumped EEPROM content, and it matches. The second parameter when the content is read, '1',? is the number of bytes. I used reading only one single byte in a loop, but multiple bytes also can be read.

I tested also the EEPROM writing, if my notes are correct it is "DIAG:DET:EEPR? eepromaddress, eepromvalue". There were (several) checksum bytes for sure, if one single bit was altered in the content, at startup the sensor has been declared defective (corrupt table). But I didn't succeed to decrypt the table locations and checksum calculation.

In one of the EPM power meter manuals (probably this document is the source of inspiration : 9018-01324.pdf) I found some service commands, which I tested. The results are listed in the attached text file.

BR,

George/Gyorgy

On 5/22/2025 12:04 PM, Razvan Popescu via groups.io wrote:
Hi,

I will check my notes. I remember there were some GPIB DIAG and INIT commands that are not documented.

If you look at the PS-Cal and SureCal calibration software you will see they can read/write the new values via the power meter GPIB commands. Maybe for the newest sensors it is a little bit more difficult but for the HP branded E4413A that I had it was OK.

Regards,
Razvan

On May 22, 2025 8:43:32 AM UTC, "F1EKU via groups.io" wrote:
According to HPAK's technical documentation, it's impossible to write new calibration factors into the sensor because each time it requires calculating a checksum that the EPMs of the E4416/17/18/19 series cannot compute. They explain that for this, we must use the newer EPMs from the N1911/12/13/14 series. Personally, I've been able to read a sensor's entire block and write it back into another probe, but changing one or more values within the block always resulted in the inability to initialize the modified probe on an E44XX series power meter. Of course, HPAK uses an external program capable of calculating the checksum when they calibrate a sensor upon request and write the complete block, even with an E44XX power meter. Does anyone know the solution for calculating the checksum?

--
Gy?rgy Albert
Mob +40-722-304534

E4418_service_GPIB_commands.txt
E4418_service_GPIB_commands.txt

21 - 40 of 151504