Tektronix purchased Keithley, broke my instruments?

[John Robertson]

On 2019/07/05 8:07 a.m., Winfield Hill wrote:

John Robertson wrote...

On 2019/07/05 7:19 a.m., Winfield Hill wrote:
Winfield Hill wrote...

OK, it's working now. Modern FireFox & Java no longer
works, so I replicated the old environment: A laptop
with 32-bit Windows 7, delete Firefox and Java. Then
install old FireFox 7: Firefox Setup 7.0.1.exe and a
middle-age version of Java 6: jre-6u45-windows-i586.exe
Later, when Java asks to update itself, disable updates.

As of last Sept 18th, Firefox no longer supports NPAPI,
required for Java applets in the browser. And none of
the 64-bit FireFox versions ever did.

https://www.java.com/en/download/faq/firefox_java.xml

Have you looked at something like 'LiveConnect'?

https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Java_in_Firefox_Extensions

No, I'll check it out later, off to work now.

I run the latest 64-bit version of Firefox on my Mac and
have no problem viewing the tek.com web site.

This is what was happening. 64-bit Firefox put up the
instrument's web pages, but when I clicked on anything
requiring a Java applet to run, it failed, and the web
program then went to Keithley.com = tek.com for a copy
of Java, but quickly put up a security error message.

Trying 32-bit FireFox and Java also didn't work, since
the new picky FireFox no longer supported Java applets.
It took some experimenting to find the right versions.

The Virtual front panel, and the TSP Express system in
the machine, using the Java applets, is super useful.
I don't believe they in fact create any security risk,
but the world has moved on.

Loading this software combination into a laptop should
work with any 2000 to 2015-era Java web applet machine.

Hi Win,

I looked at the page source and while there is javascript, I see no java
apps. Are you sure (ducking) that this is a JAVA issue and not a problem
with javascript?

https://www.whatismybrowser.com/guides/how-to-enable-javascript/firefox

Just asking...

John ;-#)#

 

[Winfield Hill]

John Robertson wrote...

On 2019/07/05 8:07 a.m., Winfield Hill wrote:
John Robertson wrote...

On 2019/07/05 7:19 a.m., Winfield Hill wrote:
Winfield Hill wrote...

OK, it's working now. Modern FireFox & Java no longer
works, so I replicated the old environment: A laptop
with 32-bit Windows 7, delete Firefox and Java. Then
install old FireFox 7: Firefox Setup 7.0.1.exe and a
middle-age version of Java 6: jre-6u45-windows-i586.exe
Later, when Java asks to update itself, disable updates.

As of last Sept 18th, Firefox no longer supports NPAPI,
required for Java applets in the browser. And none of
the 64-bit FireFox versions ever did.

https://www.java.com/en/download/faq/firefox_java.xml

This is what was happening. 64-bit Firefox put up the
instrument's web pages, but when I clicked on anything
requiring a Java applet to run, it failed, and the web
program then went to Keithley.com = tek.com for a copy
of Java, but quickly put up a security error message.

Trying 32-bit FireFox and Java also didn't work, since
the new picky FireFox no longer supported Java applets.
It took some experimenting to find the right versions.

The Virtual front panel, and the TSP Express system in
the machine, using the Java applets, is super useful.
I don't believe they in fact create any security risk,
but the world has moved on.

Loading this software combination into a laptop should
work with any 2000 to 2015-era Java web applet machine.

Hi Win,

I looked at the page source and while there is javascript,
I see no java apps. Are you sure (ducking) that this is
a JAVA issue and not a problem with javascript?

https://www.whatismybrowser.com/guides/how-to-enable-javascript/firefox

All I know is I changed FireFox first, but had to experiment
with different versions of Java before having success. I'll
try to find time for more experiments, but it'd be nice if
someone else could help out. Now only have 9 days left to
add stuff to the book, wanted to get some more measurements.


--
Thanks,
- Win

 

[John Robertson]

On 2019/07/05 5:47 p.m., Winfield Hill wrote:

John Robertson wrote...

On 2019/07/05 8:07 a.m., Winfield Hill wrote:
John Robertson wrote...

On 2019/07/05 7:19 a.m., Winfield Hill wrote:
Winfield Hill wrote...

OK, it's working now. Modern FireFox & Java no longer
works, so I replicated the old environment: A laptop
with 32-bit Windows 7, delete Firefox and Java. Then
install old FireFox 7: Firefox Setup 7.0.1.exe and a
middle-age version of Java 6: jre-6u45-windows-i586.exe
Later, when Java asks to update itself, disable updates.

As of last Sept 18th, Firefox no longer supports NPAPI,
required for Java applets in the browser. And none of
the 64-bit FireFox versions ever did.

https://www.java.com/en/download/faq/firefox_java.xml

This is what was happening. 64-bit Firefox put up the
instrument's web pages, but when I clicked on anything
requiring a Java applet to run, it failed, and the web
program then went to Keithley.com = tek.com for a copy
of Java, but quickly put up a security error message.

Trying 32-bit FireFox and Java also didn't work, since
the new picky FireFox no longer supported Java applets.
It took some experimenting to find the right versions.

The Virtual front panel, and the TSP Express system in
the machine, using the Java applets, is super useful.
I don't believe they in fact create any security risk,
but the world has moved on.

Loading this software combination into a laptop should
work with any 2000 to 2015-era Java web applet machine.

Hi Win,

I looked at the page source and while there is javascript,
I see no java apps. Are you sure (ducking) that this is
a JAVA issue and not a problem with javascript?

https://www.whatismybrowser.com/guides/how-to-enable-javascript/firefox

All I know is I changed FireFox first, but had to experiment
with different versions of Java before having success. I'll
try to find time for more experiments, but it'd be nice if
someone else could help out. Now only have 9 days left to
add stuff to the book, wanted to get some more measurements.

At this point I'd be asking on the mozilla FireFox support forum for
assistance. I don't have a windows machine so can't duplicate your
environment.

Good hunting!

John :-#)#

 

[Lasse Langwadt Christense]

fredag den 5. juli 2019 kl. 23.06.46 UTC+2 skrev John Robertson:

On 2019/07/05 8:07 a.m., Winfield Hill wrote:
John Robertson wrote...

On 2019/07/05 7:19 a.m., Winfield Hill wrote:
Winfield Hill wrote...

OK, it's working now. Modern FireFox & Java no longer
works, so I replicated the old environment: A laptop
with 32-bit Windows 7, delete Firefox and Java. Then
install old FireFox 7: Firefox Setup 7.0.1.exe and a
middle-age version of Java 6: jre-6u45-windows-i586.exe
Later, when Java asks to update itself, disable updates.

As of last Sept 18th, Firefox no longer supports NPAPI,
required for Java applets in the browser. And none of
the 64-bit FireFox versions ever did.

https://www.java.com/en/download/faq/firefox_java.xml

Have you looked at something like 'LiveConnect'?

https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Java_in_Firefox_Extensions

No, I'll check it out later, off to work now.

I run the latest 64-bit version of Firefox on my Mac and
have no problem viewing the tek.com web site.

This is what was happening. 64-bit Firefox put up the
instrument's web pages, but when I clicked on anything
requiring a Java applet to run, it failed, and the web
program then went to Keithley.com = tek.com for a copy
of Java, but quickly put up a security error message.

Trying 32-bit FireFox and Java also didn't work, since
the new picky FireFox no longer supported Java applets.
It took some experimenting to find the right versions.

The Virtual front panel, and the TSP Express system in
the machine, using the Java applets, is super useful.
I don't believe they in fact create any security risk,
but the world has moved on.

Loading this software combination into a laptop should
work with any 2000 to 2015-era Java web applet machine.



Hi Win,

I looked at the page source and while there is javascript, I see no java
apps. Are you sure (ducking) that this is a JAVA issue and not a problem
with javascript?

https://www.whatismybrowser.com/guides/how-to-enable-javascript/firefox

Just asking...

I think you are misunderstanding the issue, it is not the tek site that
is the problem, it is the webpage running on the instrument that fails with a java issue

 

[John Robertson]

On 2019/07/06 2:48 a.m., Lasse Langwadt Christensen wrote:

fredag den 5. juli 2019 kl. 23.06.46 UTC+2 skrev John Robertson:
On 2019/07/05 8:07 a.m., Winfield Hill wrote:
John Robertson wrote...

On 2019/07/05 7:19 a.m., Winfield Hill wrote:
Winfield Hill wrote...

OK, it's working now. Modern FireFox & Java no longer
works, so I replicated the old environment: A laptop
with 32-bit Windows 7, delete Firefox and Java. Then
install old FireFox 7: Firefox Setup 7.0.1.exe and a
middle-age version of Java 6: jre-6u45-windows-i586.exe
Later, when Java asks to update itself, disable updates.

As of last Sept 18th, Firefox no longer supports NPAPI,
required for Java applets in the browser. And none of
the 64-bit FireFox versions ever did.

https://www.java.com/en/download/faq/firefox_java.xml

Have you looked at something like 'LiveConnect'?

https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Java_in_Firefox_Extensions

No, I'll check it out later, off to work now.

I run the latest 64-bit version of Firefox on my Mac and
have no problem viewing the tek.com web site.

This is what was happening. 64-bit Firefox put up the
instrument's web pages, but when I clicked on anything
requiring a Java applet to run, it failed, and the web
program then went to Keithley.com = tek.com for a copy
of Java, but quickly put up a security error message.

Trying 32-bit FireFox and Java also didn't work, since
the new picky FireFox no longer supported Java applets.
It took some experimenting to find the right versions.

The Virtual front panel, and the TSP Express system in
the machine, using the Java applets, is super useful.
I don't believe they in fact create any security risk,
but the world has moved on.

Loading this software combination into a laptop should
work with any 2000 to 2015-era Java web applet machine.



Hi Win,

I looked at the page source and while there is javascript, I see no java
apps. Are you sure (ducking) that this is a JAVA issue and not a problem
with javascript?

https://www.whatismybrowser.com/guides/how-to-enable-javascript/firefox

Just asking...

I think you are misunderstanding the issue, it is not the tek site that
is the problem, it is the webpage running on the instrument that fails with a java issue

You are correct, I did not read the content correctly.

Opps.

John :-#(#

 

[John Robertson]

On 2019/07/06 8:27 a.m., John Robertson wrote:

On 2019/07/06 2:48 a.m., Lasse Langwadt Christensen wrote:
fredag den 5. juli 2019 kl. 23.06.46 UTC+2 skrev John Robertson:
On 2019/07/05 8:07 a.m., Winfield Hill wrote:
John Robertson wrote...

On 2019/07/05 7:19 a.m., Winfield Hill wrote:
Winfield Hill wrote...

OK, it's working now.  Modern FireFox & Java no longer
works, so I replicated the old environment:  A laptop
with 32-bit Windows 7, delete Firefox and Java.  Then
install old FireFox 7:  Firefox Setup 7.0.1.exe  and a
middle-age version of Java 6: jre-6u45-windows-i586.exe
Later, when Java asks to update itself, disable updates.

    As of last Sept 18th, Firefox no longer supports NPAPI,
    required for Java applets in the browser.  And none of
    the 64-bit FireFox versions ever did.

https://www.java.com/en/download/faq/firefox_java.xml

Have you looked at something like 'LiveConnect'?

https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Java_in_Firefox_Extensions


   No, I'll check it out later, off to work now.

I run the latest 64-bit version of Firefox on my Mac and
have no problem viewing the tek.com web site.

   This is what was happening.  64-bit Firefox put up the
   instrument's web pages, but when I clicked on anything
   requiring a Java applet to run, it failed, and the web
   program then went to Keithley.com = tek.com for a copy
   of Java, but quickly put up a security error message.

   Trying 32-bit FireFox and Java also didn't work, since
   the new picky FireFox no longer supported Java applets.
   It took some experimenting to find the right versions.

   The Virtual front panel, and the TSP Express system in
   the machine, using the Java applets, is super useful.
   I don't believe they in fact create any security risk,
   but the world has moved on.

   Loading this software combination into a laptop should
   work with any 2000 to 2015-era Java web applet machine.



Hi Win,

I looked at the page source and while there is javascript, I see no java
apps. Are you sure (ducking) that this is a JAVA issue and not a problem
with javascript?

https://www.whatismybrowser.com/guides/how-to-enable-javascript/firefox

Just asking...

I think you are misunderstanding the issue, it is not the tek site that
is the problem, it is the webpage running on the instrument that fails
with a java issue



You are correct, I did not read the content correctly.

Opps.

John :-#(#

I assume Win saw this discussion on forum.tek.com regarding the issue
and a possible solution:

https://forum.tek.com/viewtopic.php?f=14&t=141425

-----
Re: TSP Express Unable to Launch

Post by Stuart M Âť May 30th, 2019, 7:13 am
Java 8 and newer browsers do not work.
Here's what still works...

32-bit browser
Firefox ESR (latest version is now 60).
Internet Explorer 11.

Java Runtime (jre) (32-bit)
In addition to one of the above 32-bit browsers, you will also need
32-bit java runtime.
Java runtime (x86)versions 6 and 7 both still work.
Once java runtime is installed, you need to enable the add-in from your
browser.
Top
-----
Re: TSP Express Unable to Launch

Post by Wayne L Âť June 2nd, 2019, 11:31 pm
You can try delete cache or just run from Java control panel.
(images)
-----

Sorry about making the stupid assumption previously...

John :-#(#

 

[Winfield Hill]

John Robertson wrote...

I assume Win saw this discussion on forum.tek.com regarding the issue=20
and a possible solution:

https://forum.tek.com/viewtopic.php?f=3D14&t=3D141425

Yes, it was Stuart M's answer: to use 32-bit Firefox
and 32-bit Java Runtime (jre). But not all 32-bit
versions worked, I experimented to find a working set.
Once the machine's Java app, in a working Firefox and
with a working Java, it didn't try to call Keithley.


--
Thanks,
- Win

 

Winfield Hill <winfieldhill@yahoo.com> wrote in news:qfqlqh0r3
@drn.newsguy.com:

Yes, it was Stuart M's answer: to use 32-bit Firefox
and 32-bit Java Runtime (jre). But not all 32-bit
versions worked, I experimented to find a working set.
Once the machine's Java app, in a working Firefox and
with a working Java, it didn't try to call Keithley.

I'd bet that the reason is that that particular 64 bit java &
firefox was default IPV6 and your ISP does not pass the call, hence
the rejection.

IPV4 is 32 bit.

So, if you exploreed the setting in the 64 bit version and blocked
IPV6 connect hooks, it would fall back to IPV4 and work.

The reason it works now is because 32 bit java is IPV4 only.

I experienced a similar problem 4 years ago and that fixed it.

Seeing the particulars of your problem in this thread and the
solution that "worked", I'd almost bet it would work on the 64 bit
set if the jave jre setting was changed.

 

[Steve Wilson]

Just a few comments. Your post is long so I will trim wherever
possible. First, I wish to apologize for submitting the AD8307. It
has no RF output so it cannot be used to measure phase in a VNA. The
AD640, AD8306, AD8309 all have differential signal out so they are
suitable for VNA operation. There may be others.

Chris Jones <lugnut808@spam.yahoo.com> wrote:

> Log amps are fine if you need to measure changes in power level

Just to be consistent, all the techniques discussed here measure
voltage. You can convert voltage to power with the equation P =
E^2/R, but the resulting equations are awkward. From Mogami:

The defining equation for decibels is

A = 10*log10(P2/P1) (dB)

where P1 is the power being measured, and P1 is the reference to
which P2 is being compared.

To convert from decibel measure back to power ratio:

P2/P1 = 10^(A/10)

Voltage is more easily measured than power, making it generally more
convenient to use:

A = 20*log10(V2/V1) (Z2 == Z1)

The equation for obtaining voltage ratio from dB is

V2/V1 = 10^(A/20)

http://www.mogami.com/e/cad/db.html

with an accuracy of maybe 1dB or a bit better, but if you need to
measure a change in power level with an accuracy of say 0.01dB
then a mixer and ADC is a much better approach.

There are no VNAs with 0.01dB accuracy. An ADC cannot give 0.01dB
over a wide range of input signals. A log converter may be able to
approach 0.1dB over a wide range of signals if properly calibrated.

The reason is this: log amps like the AD8307 work by cascading a
lot of amplifier stages and then putting a rectifier on each
stage, and summing the outputs of the rectifiers. This works
pretty well, but if you plot the output signal (voltage) vs. the
input power in dB, then you see a periodic ripple, with a small
bump every few dB, spaced according to how much gain per stage is
used in the log amp.

The ripple is minimal. You can calibrate it out.

That is why the AD8307 has a "log conformance +/-0.3dB typical,
+/-1.0dB max" specification.

The AD8307 is not trimmed. There are many other factors that
determine the log conformity. These can all be calibrated out,
providing you can find an accurate step attenuator.

In a manual scalar network analyser where you just plot the
response on an oscilloscope, the log amp would be fine (at low
frequencies anyway) as you probably don't care to measure the
response of a filter better than a dB or so. Without calibration
to correct for impedance mismatching on your VNA ports you are not
going to be able to check the steps on an attenuator to 0.01dB or
stuff like that anyway.

There are no VNAs with an accuracy of 0.01dB. Most are 0.1 to 0.2dB
over a very limited amplitude range. The HP 8753D has an uncertainty
around 0.1dB from 0 to -60dB, rising rapidly to 5dB at -100dB

https://literature.cdn.keysight.com/litweb/pdf/5962-9770E.pdf?id=
1000080939:epsg:dow

In a VNA where you want to use computer correction and calibration
to take out the effects of the cables and imperfect matching, it
is necessary to measure the relative amplitude of signals with
much better accuracy. eg if your connectors produce reflections at
20dB, but you can measure this error and subtract it out
digitally, then you can still measure the return loss of a DUT at
say -40dB, perhaps with 0.1dB precision or better.

This relies on being able to subtract two fairly large signals,
and accurately determine the difference between them, which is
much smaller.

You have return loss backwards.

"Return loss is a measure of how well devices or lines are matched.

A match is good if the return loss is high. A high return loss is
desirable and results in a lower insertion loss. Return loss is used
in modern practice in preference to SWR because it has better
resolution for small values of reflected wave."

https://en.wikipedia.org/wiki/Return_loss

You want a high return loss. When you are working with 30-40dB
return loss, 0.1db accuracy is not important. If you are working
with 6dB return loss, half your power is wasted. You have to fix it,
so 0.1dB accuracy is meaningless.

Having 0.3dB of ripple in the transfer function of the log amp
really screws up this subtraction.

You have already calibrated the ripple out. And you are not subtracting
two fairly large signals.

There might be ways to characterise it, but it is temperature
dependent too.

Measure the temperature and add a correction factor.

You could put it in a thermstatic oven, but it is frequency
dependent too.

The log converter works at a fixed frequency.

[...]

Log amps are also inherently wideband, so they measure the noise
in a wide bandwidth, which limits dynamic range. Only by filtering
part-way along the log-amp can this be fixed. Note the 10.7MHz
bandpass filter in fig. 42, and so that circuit is only good for a
10.7MHz VNA! You will need a mixer for other frequencies, and then
you might as well follow it with a nice, high resolution ADC which
will give you very precise measurements across a very wide dynamic
range.

1. The VNA is a superheterodyne. The Log converter works at the IF,
which is fixed.

2. The high accuracy of an ADC is only obtained at the maximum input
signal. The accuracy degrades as the input signal gets weaker.

For example, a 24 bit ADC has a dynamic range of about 100dB, or a
ratio of 10**(100/20) = 100,000. That corresponds to 2**17 =
131,072, so the bottom 7 bits of the ADC are just noise and can be
thrown away.

So let's see what resolution can be obtained at full signal. One bit
is 20 * Log(100001/100000) = 8.685e-5dB. That is pretty good. But a
VNA has to work over a wide range of amplitudes.

Now let's try 60 db down. That is 1/1000 of the original, which is
100000/1000 = 100. One bit is 20 * Log(101/100) = 8.642e-2dB, or
0.08642dB.

So we haven't reached -60dB, and you have already blown your 0.01dB
goal.

The reason the log converter is so much better is because it
distributes the entire dynamic range over a series of identical
stages. Each stage has to carry only a small part of the dynamic
range, then it transfers the load to the next stage.

It is much easier to get a single stage to function well over a
small range, than to try to do it all in one swoop, like the ADC
approach.

And guess what! Some parts of a VNA and a spectrum analyzer are very
similar. So if you can get a VNA to work well, you have already made
a good section of a spectrum analyzer. You will, of course, want
wider frequency range, better image rejection, lower spurs, better
bandwidth control, and so on.

Or make it a modular approach and switch the needed sections to
whichever function in use at the moment. But keep these things in
mind as you develop your plans.

Comments and corrections are welcome.

[...]

 

Steve Wilson <no@spam.com> wrote in news:XnsAA8519102E8F3idtokenpost@
69.16.179.23:

"Return loss is a measure of how well devices or lines are matched.

Shouldn't that be "devices AND their connection lines"?

I mean doesn't the transmission line become part of the entire output
transducer and its impedance and return loss.

ie from the "output jack all the way to the tip of the antenna".

 

[Clifford Heath]

On 7/7/19 4:27 pm, Steve Wilson wrote:

Just a few comments. Your post is long so I will trim wherever
possible. First, I wish to apologize for submitting the AD8307. It
has no RF output so it cannot be used to measure phase in a VNA. The
AD640, AD8306, AD8309 all have differential signal out so they are
suitable for VNA operation. There may be others.

AD8302 has a phase output, and relative amplitude. They only work if the
two input signals are within 30dB of each other, so not good for a VNA
with anything like a useful dynamic range (without PGAs ahead anyhow).

Clifford Heath

 

[Chris Jones]

On 07/07/2019 16:27, Steve Wilson wrote:

Just a few comments. Your post is long so I will trim wherever
possible.As will I, where I don't wish to comment. No offence intended.

There are no VNAs with 0.01dB accuracy.

I apologise, the first one I looked up was 0.04dB at best:
https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/ZNA_dat-sw_en_5215-4652-22_v0200.pdf
Whether it is 0.01 or 0.04dB does not alter the argument, however. You
will not be able to achieve this degree of log conformance as easily
with a log amplifier as you would with an ADC. Remember also that the
specifications for these instruments includes a lot of things other than
just the receiver detector, so the error budget for the receiver is smaller.

An ADC cannot give 0.01dB
over a wide range of input signals.
This depends on what you mean by "wide".

A log converter may be able to
approach 0.1dB over a wide range of signals if properly calibrated.

Yes, but calibrating it requires for example a stepped attenuator, with
fine steps known to be more accurate than that. I'm not saying you
couldn't make such an attenuator, but you'd probably need a good VNA to
calibrate that attenuator. So you might as well just use the good VNA
that you already had, and if it came from any of the leading VNA
manufacturers, it won't use a log-amp inside.

By the way, did you know that the phase shift of log amps (the ones with
an output that you can measure the phase of) varies with the input
amplitude? Figuring out how to calibrate that out really well ... you
could use a good VNA!

The reason is this: log amps like the AD8307 work by cascading a
lot of amplifier stages and then putting a rectifier on each
stage, and summing the outputs of the rectifiers. This works
pretty well, but if you plot the output signal (voltage) vs. the
input power in dB, then you see a periodic ripple, with a small
bump every few dB, spaced according to how much gain per stage is
used in the log amp.

The ripple is minimal. You can calibrate it out.

Minimal, but not good enough to compete with alternative solutions. You
can indeed calibrate it out, but that is harder than alternative solutions.

That is why the AD8307 has a "log conformance +/-0.3dB typical,
+/-1.0dB max" specification.

The AD8307 is not trimmed. There are many other factors that
determine the log conformity. These can all be calibrated out,
providing you can find an accurate step attenuator.
Haha, yes, and all you need to make one of those is a good VNA!

I did once design a transmitter with a 2GHz stepped attenuator to
control the output power, and we trimmed the prototypes of those with an
Agilent PSA. It had no trouble correcting the attenuator steps to within
0.03dB. I expect it could have measured it much more accurately, but I
didn't put in enough resolution into the chip to correct it better than
that, as there was no need. By the way, like most modern spectrum
analysers, the PSA uses an ADC, not a log-amp, to measure amplitude.

In a manual scalar network analyser where you just plot the
response on an oscilloscope, the log amp would be fine (at low
frequencies anyway) as you probably don't care to measure the
response of a filter better than a dB or so. Without calibration
to correct for impedance mismatching on your VNA ports you are not
going to be able to check the steps on an attenuator to 0.01dB or
stuff like that anyway.

There are no VNAs with an accuracy of 0.01dB. Most are 0.1 to 0.2dB
over a very limited amplitude range. The HP 8753D has an uncertainty
around 0.1dB from 0 to -60dB, rising rapidly to 5dB at -100dB

https://literature.cdn.keysight.com/litweb/pdf/5962-9770E.pdf?id=
1000080939:epsg:dow

Ok point taken, commercially available VNAs are typically not good to
0.01dB, but bearing in mind the age of the 8753, one would hope to do
better than 0.1dB these days, and starting with a log-amp is not the
easy way to do that.

In a VNA where you want to use computer correction and calibration
to take out the effects of the cables and imperfect matching, it
is necessary to measure the relative amplitude of signals with
much better accuracy. eg if your connectors produce reflections at
20dB, but you can measure this error and subtract it out
digitally, then you can still measure the return loss of a DUT at
say -40dB, perhaps with 0.1dB precision or better.

This relies on being able to subtract two fairly large signals,
and accurately determine the difference between them, which is
much smaller.

You have return loss backwards.

[snip]
Yes, please omit / add minus sign as appropriate. I think anyone
familiar with actually measuring it will know what I meant.

When you are working with 30-40dB
return loss, 0.1db accuracy is not important.

True, but my point was, that sometimes there is no option to avoid using
a test fixture with cables, and that might have significant loss between
the VNA and your device. And sometimes the connector on your cable will
have worse than 20dB return loss (so mag(S11)>-20dB for clarity!), right
at the VNA port. Potentially, the signal into the receiver that measures
reflected power will be mostly from the imperfections in the connectors,
and only a very small change in the signal reaching the receiver will
depend on the device under test. So, even to measure the 30-40dB return
loss with an uncertainty of 1dB will require much better than 1dB
accuracy (when measuring differces in power levels) in the receiver
inside the VNA.

If you are working
with 6dB return loss, half your power is wasted. You have to fix it,
so 0.1dB accuracy is meaningless.

If you are making something by the million a week, and if the cheapest
way to make it results in a 6dB return loss, and it works, and if your
customer will happily pay for that but they won't pay for 5.5dB, then
you'd better measure it, and you won't want to waste much of your margin
on crappy test gear.

Having 0.3dB of ripple in the transfer function of the log amp
really screws up this subtraction.

You have already calibrated the ripple out.
Only with heroic effort.

And you are not subtracting
two fairly large signals.

Sometimes you are. You could make a specialised VNA that can only
measure certain amplitudes, but I wouldn't want one. When you compute
A/R, for certain magnitudes of A/R the ripples will all line up and
everything will be nice, but for other magnitudes of A/R they will not
line up and it will not be so nice.

There might be ways to characterise it, but it is temperature
dependent too.

Measure the temperature and add a correction factor.

You can do that, but it is not a single factor. Every hump and wobble of
the transfer function could move sideways, get deeper or shallower etc.

I'm not saying you can't do it, I'm just saying that I wouldn't want to.

You could put it in a thermstatic oven, but it is frequency
dependent too.

The log converter works at a fixed frequency.
Ok, it was not clear to me that you had realised that you need a mixer.

Log amps are also inherently wideband, so they measure the noise
in a wide bandwidth, which limits dynamic range. Only by filtering
part-way along the log-amp can this be fixed. Note the 10.7MHz
bandpass filter in fig. 42, and so that circuit is only good for a
10.7MHz VNA! You will need a mixer for other frequencies, and then
you might as well follow it with a nice, high resolution ADC which
will give you very precise measurements across a very wide dynamic
range.

1. The VNA is a superheterodyne. The Log converter works at the IF,
which is fixed.
Ok, now it is clear to me that you do realise that you need a mixer.

2. The high accuracy of an ADC is only obtained at the maximum input
signal. The accuracy degrades as the input signal gets weaker.

For example, a 24 bit ADC has a dynamic range of about 100dB, or a
ratio of 10**(100/20) = 100,000. That corresponds to 2**17 =
131,072, so the bottom 7 bits of the ADC are just noise and can be
thrown away.

So let's see what resolution can be obtained at full signal. One bit
is 20 * Log(100001/100000) = 8.685e-5dB. That is pretty good. But a
VNA has to work over a wide range of amplitudes.

Now let's try 60 db down. That is 1/1000 of the original, which is
100000/1000 = 100. One bit is 20 * Log(101/100) = 8.642e-2dB, or
0.08642dB.

So we haven't reached -60dB, and you have already blown your 0.01dB
goal.

Commercial VNAs use more than one ADC sample to estimate the amplitude.
If you do that, and if there is some noise (or deliberately-added
dither) then you can measure signals rather smaller than the least
significant bit of the converter.

It is interesting to see how they did it in the old HP instruments, and
to imagine how much better you could do with modern components:
https://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1984-11.pdf
Look at the article on page 21 of that document.

The reason the log converter is so much better is because it
distributes the entire dynamic range over a series of identical
stages.
Yet none of the best VNAs use one.

And guess what! Some parts of a VNA and a spectrum analyzer are very
similar. So if you can get a VNA to work well, you have already made
a good section of a spectrum analyzer.

As I mentioned above, even spectrum analysers, that in the olden days
did use log amps, nowadays use ADCs to measure the IF instead. Even if
you don't care about being able to demodulate fancy digital signals, and
don't care about getting rid of the log conformity errors of log amps,
there are other advantages:
1. RMS calculations can be done properly. Guess what: the average of the
log of a signal is not always the same as the log of the average of the
signal. Log amps are usually calibrated to read correctly (or as close
as they can) for sine wave inputs. If your input is noise, or worse
still some modulated signal for which you don't know the statistical
properties, you can't easily compute the true RMS value from the
filtered output of the log amp.
2. You can make much more accurate "resolution bandwidth" filters in the
digital domain.

The main problem I see with trying to make a combined spectrum analyser
and VNA is that the requirements are conflicting: You care a lot about
rejecting arbitrary unwanted frequencies in a spectrum analyser, so
usually you will want a tracking YIG filter as a preselector, or always
up-convert to a first IF higher than your highest supported input
frequency. Both of these approaches are likely to make the response
drift (especially in phase) more than you would want for a VNA, where
you don't need the preselection filter because the only large signals
present are from the VNA itself. Also, the spectrum analyser needs a
good input attenuator with lots of range, whereas you could probably get
away with little or no built-in facility for input attenuation on a VNA.
Also any decent VNA should have 4 receivers at least (two per port, and
at least 2 ports), yet all but one of these would be wasted in the
spectrum analyser mode.

I say build two separate instruments, and optimise each one properly.

 

[Steve Wilson]

Clifford Heath <no.spam@please.net> wrote:

On 7/7/19 4:27 pm, Steve Wilson wrote:
Just a few comments. Your post is long so I will trim wherever
possible. First, I wish to apologize for submitting the AD8307. It
has no RF output so it cannot be used to measure phase in a VNA. The
AD640, AD8306, AD8309 all have differential signal out so they are
suitable for VNA operation. There may be others.

AD8302 has a phase output, and relative amplitude. They only work if the
two input signals are within 30dB of each other, so not good for a VNA
with anything like a useful dynamic range (without PGAs ahead anyhow).

Clifford Heath

The AD8302 has only 60dB log range. Useless for VNA applicaations. There are
much better devices available.

 

[Winfield Hill]

DecadentLinuxUserNumeroUno@decadence.org wrote...

Winfield Hill <winfieldhill@yahoo.com> wrote:

Yes, it was Stuart M's answer: to use 32-bit Firefox
and 32-bit Java Runtime (jre). But not all 32-bit
versions worked, I experimented to find a working set.
Once the machine's Java app, in a working Firefox and
with a working Java, it didn't try to call Keithley.

I'd bet that the reason is that that particular 64 bit
java & firefox was default IPV6 and your ISP does not
pass the call, hence the rejection.

Maybe, but the point was, with a proper browser calling
a proper Java to execute the Java code (after doing the
simple stuff with Javascript), no web call is made. Had
the web call gone through, it still wouldn't have worked,
because when I finally did get that far, all I got was a
message from Tek, in the instrument-action screen, saying
to setup a ticket, which I did, but heard nothing back.

> The reason it works now is because 32 bit java is IPV4 only.

There is no web access at all going on now.


--
Thanks,
- Win

 

Winfield Hill <winfieldhill@yahoo.com> wrote in
news:qft5f30rcu@drn.newsguy.com:

Maybe, but the point was, with a proper browser calling
a proper Java to execute the Java code (after doing the
simple stuff with Javascript), no web call is made.

You keep saying 'proper'. As I said, the SETTING in the 64 bit
jave jre version is the problem. With the setting right, it works.
whether it makes an internet call or not.

So maybe it is a 32 bit only thing for an older instrument not
hitting the web as you say. Maybe it will not even run the 64 bit
implementations.

But it has been an IPV6 problem in the past and IPV6 is not fully
embraced by the most important element... the ISP.

It is more secure so should be implemented all over the place, but
apparently got neglected because those ISPs felt that "what we have
works" Not broke don't fix. Where in fact, if they are too lazy to
set it up right, *they* are the broke part.

 

[Winfield Hill]

DecadentLinuxUserNumeroUno@decadence.org wrote...

Winfield Hill <winfieldhill@yahoo.com> wrote in
news:qft5f30rcu@drn.newsguy.com:

Maybe, but the point was, with a proper browser calling
a proper Java to execute the Java code (after doing the
simple stuff with Javascript), no web call is made.

You keep saying 'proper'. As I said, the SETTING in the
64 bit jave jre version is the problem. With the setting
right, it works. Whether it makes an internet call or not.

OK, I'll try to find time to try that, thanks.


--
Thanks,
- Win

 

[Winfield Hill]

jurb6006@gmail.com wrote...

When did this happen ? Now take that date and remember it.
Now go to the thingie in Windows and find out whenever
whatever update happened that coincides with the date
of your problem.

Great idea, but since I normally run my SMUs from their
front panels, I have no idea when it happened, some time
in the last five years, maybe. I'm even not 100% sure
on which of my computers I last had successful operation.


--
Thanks,
- Win

 

[Phil Hobbs]

On 7/7/19 2:27 AM, Steve Wilson wrote:

Just a few comments. Your post is long so I will trim wherever
possible. First, I wish to apologize for submitting the AD8307. It
has no RF output so it cannot be used to measure phase in a VNA. The
AD640, AD8306, AD8309 all have differential signal out so they are
suitable for VNA operation. There may be others.

Chris Jones <lugnut808@spam.yahoo.com> wrote:

Log amps are fine if you need to measure changes in power level

Just to be consistent, all the techniques discussed here measure
voltage. You can convert voltage to power with the equation P =
E^2/R, but the resulting equations are awkward. From Mogami:

The defining equation for decibels is

A = 10*log10(P2/P1) (dB)

where P1 is the power being measured, and P1 is the reference to
which P2 is being compared.

To convert from decibel measure back to power ratio:

P2/P1 = 10^(A/10)

Voltage is more easily measured than power, making it generally more
convenient to use:

A = 20*log10(V2/V1) (Z2 == Z1)

The equation for obtaining voltage ratio from dB is

V2/V1 = 10^(A/20)

http://www.mogami.com/e/cad/db.html

with an accuracy of maybe 1dB or a bit better, but if you need to
measure a change in power level with an accuracy of say 0.01dB
then a mixer and ADC is a much better approach.

There are no VNAs with 0.01dB accuracy. An ADC cannot give 0.01dB
over a wide range of input signals. A log converter may be able to
approach 0.1dB over a wide range of signals if properly calibrated.

The reason is this: log amps like the AD8307 work by cascading a
lot of amplifier stages and then putting a rectifier on each
stage, and summing the outputs of the rectifiers. This works
pretty well, but if you plot the output signal (voltage) vs. the
input power in dB, then you see a periodic ripple, with a small
bump every few dB, spaced according to how much gain per stage is
used in the log amp.

The ripple is minimal. You can calibrate it out.

That is why the AD8307 has a "log conformance +/-0.3dB typical,
+/-1.0dB max" specification.

The AD8307 is not trimmed. There are many other factors that
determine the log conformity. These can all be calibrated out,
providing you can find an accurate step attenuator.
snip

Long ago I calibrated a DLVA/digitizer combination to about 12 bits
using the ring-down of a crystal oscillator. You have to drive the
crystal gently enough that there are no significant nonlinear loss
contributions, and take the oscillator part out of the circuit during
the ring-down. I used PIN diode switches, but nowadays I'd probably use
a pHEMT for that job.

A garden-variety 80-MHz crystal will ring down by about 1 dB/ms, which
is a very convenient rate.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[Steve Wilson]

Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

Long ago I calibrated a DLVA/digitizer combination to about 12 bits
using the ring-down of a crystal oscillator. You have to drive the
crystal gently enough that there are no significant nonlinear loss
contributions, and take the oscillator part out of the circuit during
the ring-down. I used PIN diode switches, but nowadays I'd probably use
a pHEMT for that job.

A garden-variety 80-MHz crystal will ring down by about 1 dB/ms, which
is a very convenient rate.

Aren't you measuring Q?

Lecture 21: Decay of Resonances
http://www.physics.mcgill.ca/~guymoore/ph224/notes/lecture21.pdf

It would seem you have to measure at a much higher frequency than the
crystal to get an accurate indication of the ringdown. This may mean
sampling at several hundred MHz. Was there accurate samplers available
then? 12 bits is one part in 4096, or 0.00212dB per bit.

Why not use a precision step attenuator? HP has been checking precision
step attenuators for a long time. A graph on page 12 shows +/- 0.004dB
error at 60dB and 30MHz:

Calibration of Precision Step Attenuators
http://literature.cdn.keysight.com/litweb/pdf/5991-1226EN.pdf

It would appear you were beating HP with your method. That is quite some
achievement!

Cheers

Phil Hobbs

 

[Phil Hobbs]

On 7/7/19 10:10 PM, Steve Wilson wrote:

Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

Long ago I calibrated a DLVA/digitizer combination to about 12 bits
using the ring-down of a crystal oscillator. You have to drive the
crystal gently enough that there are no significant nonlinear loss
contributions, and take the oscillator part out of the circuit during
the ring-down. I used PIN diode switches, but nowadays I'd probably use
a pHEMT for that job.

A garden-variety 80-MHz crystal will ring down by about 1 dB/ms, which
is a very convenient rate.

Aren't you measuring Q?

Lecture 21: Decay of Resonances
http://www.physics.mcgill.ca/~guymoore/ph224/notes/lecture21.pdf

It would seem you have to measure at a much higher frequency than the
crystal to get an accurate indication of the ringdown. This may mean
sampling at several hundred MHz. Was there accurate samplers available
then? 12 bits is one part in 4096, or 0.00212dB per bit.

Why not use a precision step attenuator? HP has been checking precision
step attenuators for a long time. A graph on page 12 shows +/- 0.004dB
error at 60dB and 30MHz:

Calibration of Precision Step Attenuators
http://literature.cdn.keysight.com/litweb/pdf/5991-1226EN.pdf

It would appear you were beating HP with your method. That is quite some
achievement!

I didn't have one in the drawer, and there was no budget for it. Plus
I'd have had to be super careful about return loss and so forth. My
scheme did the calibration effectively with the DUT attached, so all
that stuff cancelled out.

I built a 60-MHz amplitude/phase digitizer as part of my interferometric
confocal microscope back in my mid-twenties. The calibrator was a lot
more complicated than the digitizer--it had two sources whose relative
phase could be walked in 1-degree steps via a pulse-swallowing counter,
and the aforementioned crystal ring-down amplitude calibrator. The
digitizers ran at 50 kS/s, so 1-dB per millisecond was a very convenient
number for calibrating.

The microscope is discussed in

<https://electrooptical.net/static/eoi/heterodyneMicroscope/GeneralizingTheConfocalMicroscope.pdf>

and the amplitude/phase digitizer is at
<https://electrooptical.net/www/confocal/HighPerformanceAmplitudeAndPhaseDigitizers.pdf>.

I needed to get some data so I could graduate, so I didn't build yet
another calibrator to check the first one, but the gizmo was pretty
stable considering what it was, and the deconvolution algorithm worked
very nicely--the data came out very smooth even on very small scales.

Cheers

Phil Hobbs



--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com