Date   
Re: Getting started with the nanoVNA guide

Dr. David Kirkby from Kirkby Microwave Ltd
 

On Mon, 2 Sep 2019 at 06:28, HexAndFlex via Groups.Io <iain_haggis=
yahoo.com@groups.io> wrote:

https://hexandflex.com/2019/08/31/getting-started-with-the-nanovna-part-1/

I have been working on what I hope is an easy to follow introduction to
the nanoVNA. It's fairly basic and aimed at users who have probably used
other test test equipment such as oscilloscope or maybe even a spectrum
analyser, but are unsure why they might benefit from a VNA.

This is a work in progress and I will aim to take any feedback given here
to improve the content.

Part 2 is in the works and I hope to have it uploaded this time next week.
Thank you - that will be most helpful to me. Here are a few comments, which
I hope are constructive - they are not meant to be critical.

1) I'm not really convinced an RF engineer would find a VNA more useful
than a multimeter. 😀😀 I think a VNA is second only to a multimeter.

2) I don't believe the analogy of the train in the tunnel is as good as the
diagram here

https://www.kirkbymicrowave.co.uk/Support/Guide-to-vector-network-analyzers/

which I stole from an Agilent Application note. I think the transmitted and
reflected signal off a lens is a bit less confusing than the train in the
tunnel. If you want to bring different frequencies into it, then this
could be expanded with different colour LEDs.

3) A high-end VNA will cost as much as a house *nowadays* - it is not just
years ago.

https://www.keysight.com/en/pdx-2812784-pn-N5227B/pna-microwave-network-analyzer-67-ghz

has a starting price of $176,888 for a basic 2-port model. With 4 ports and
a second source raising that cost rises to $358,749. Add in a few options,
and it will easily go beyond $500,000, and it would not surprise me if it
goes over $1,000,000 USD.

4) The graph of S11 is not the reflection coefficient, but the magnitude of
the reflection coefficient. I think a diagram showing the phase of the
reflection coefficient would be easier to understand than the Smith Chart.
I believe the Smith Chart overcomplicates things.

5) The comment "The cal kit and cables that come with the kit are pretty
cheap and nasty. That said, many pro VNAs don’t include cables or cal kits
at all. These generally cost extra, and aren’t cheap." I'm unaware of any
professional VNA that comes with cables or calibration kits, so at least
saying some(perhaps all) don't come with calibration kits is useful. I
would point out that they cost in excess of $1000 and many in excess of
$10,000.

6) The comment about missing features being "No de-embedding." does not
seem appropriate to me in a beginners guide. If someone does not know what
a VNA is, they are unlikely to know about de-embedding.

7) I believe the fact the VNA assumes ideal standards for opens and shorts
is a *serious* problem - far more than deembedding. Neither my 8753ES or
8720 support deembedding, but both have good support for calibration kit
defintions.

8) The comment "f you wish to do S21 measurements, you will probably need
to connect a cable to both ports", whilst accurate, I believe you should
say it's essential use both ports, and normally cables would be needed on
both ports. I would also reitteratee that S21 measured are "S21
(transmission) measurements.

9) More accurate calibrations will result if the open standard is not used.
The VNA assumes an ideal open, but the open standard just adds capacitance,
making the calibration less accurate. I posted a plot of the phase of both
an untermnated port and one with the open standard. The one with the open
standard was poorer.

10) The comment "Load: – Smith chart should be grouped around the centre of
the plot. LOGMAG Plot should be showing a low number (-50dB or below)" may
not be true at high frequency. I would check that, but I doubt it would be
worth checking at 900 MHz.

11) The comment "Time Domain Reflectometry. You can do this in
post-processing <https://zs1sci.com/blog/nanovna-tdr/> . Lots of high end
VNAs do not have this feature." is I feel untrue. I'm not aware of any
high-end VNA that does not have this feature, although it is sometimes a
software option that has to be paid for.

12) Somewhere (I forget where), the reference plane is mentioned. I would
at that this where the outer conductors of a pair of connector mate, and it
is often inside the connectors.

AS I say, these are meant to be constructive, so don't take them
personally.






--
Dr David Kirkby Ph.D C.Eng MIET
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, CHELMSFORD,
Essex, CM3 6DT, United Kingdom.
Registered in England and Wales as company number 08914892
https://www.kirkbymicrowave.co.uk/
Tel 01621-680100 / +44 1621-680100

Re: nanoVNA for Dummies

W5DXP
 

This easy to understand HP document, from which I learned a lot, could be entitled "S-Parameter Techniques" for Dummies.

http://www.sss-mag.com/pdf/an-95-1.pdf

Re: Early app for the NanoVNA

Harry McGavran Jr
 

I fetched today's version with the reference sweep changes -- now when I import an s1p file
Iit only gets used as a reference sweep. I'd like to be able to use markers and the tdr function
on touchstone files. That way I can look at previous sweeps I had saved without having
to do the sweep again. Can you allow loading of touchstone files as regular sweeps in addition
to the reference sweeps????

Re: Early app for the NanoVNA

Harry McGavran Jr
 

It would be really nice to be able to use "m" and "k" in the markers too!

Re: Early app for the NanoVNA

Rune Broberg
 

Thanks for the suggestions! I've pushed an update to the repository
implementing those two features.

I also want to make the markers measure both sweep and reference data, but
the UI is starting to get cluttered, so I want to figure out how to do it
in a nice way.

--
Rune / 5Q5R

On Mon, 2 Sep 2019 at 18:54, Harry McGavran Jr <w5pny@...> wrote:

It would be really nice to be able to use "m" and "k" in the markers too!



Re: Better, Worse, Worst....... baloney.

Warren Allgyer
 

Roger

I am reviewing your comparison results on my phone so I may have missed something.

What I see is comparisons of the S11 noise floor in the 60-70 dB range return loss. This is meaningless in the real world for all but the most critical applications, like comparing the return loss of an N connector versus an SMA for the example.

A return loss of 30dB equals a VSWR of 1.06:1. A return loss of 40 dB equals a VSWR of 1.02:1 and is exponentially more difficult to achieve and measure accurately. For all but the most critical lab measurements return loss values greater than 30 dB are meaningless. They are also much more sensitive to calibration errors.

Comparisons of noise floor are interesting and do indeed likely reflect more care, shielding, and execution against a design. They do not, however, represent an indication of comparative measurement accuracy at usable return loss values.

The comparison you could do to measure real world comparative performance would be to use a 100-500 ohm resistor and measure return loss and other parameters at, say, 50, 450, and 850 MHz. I will eat my hat if you find more than 1 dB of difference between the units and I expect it will be far less than that. I do not have a Hugen unit but the variance between my worse and worst units for these tests is less than 0.3 dB. NOTE: all units being compared must have been carefully calibrated using the same set of OSLIT loads!

In summary, a difference in noise floor between 60 and 70 dB is meaningless in the real world and has no bearing on the accuracy of the instrument for normal ranges of use.

WA8TOD

On Sep 2, 2019, at 8:57 AM, Roger Henderson <hendorog@...> wrote:

I have posted some comparisons here between my white 'Gecko/Salamander'
device and my hugen unit:
https://github.com/hendorog/nanovna_test/blob/master/NanoVNA%20comparison.ipynb


In all these traces, the lower the trace, the better. If the device is
theoretically perfect then the trace will be at some ridiculously low value
as it will ultimately be limited by the mathematical precision in the
calculations.
This is what happens if I save measurements and transfer them to a PC, do a
calibration and then apply the error correction to the load.
Since these are real physical devices, and they drift around so each sweep
will be slightly different - even when measuring the same load and not
touching anything.
So perfection doesn't happen, and the trace will slowly float upwards as
the device shows its limitations.

First test file was saved after calibrating both devices right after power
on.
Second test file was saved after leaving them both on for an hour and then
calibrating.
Tests 3, 4 and 5 were saved after increasing lengths of time.

There is a clear advantage in the hugen trace after each of the
calibrations.
Over time the two traces eventually come together.

The white unit is quite poor at 900MHz unless it has a good amount of warm
up time.
The white unit is much worse at the very lowest frequencies in the trace,
and note that it had a Start freq of 1MHz. This was my mistake as the hugen
unit was starting at 50kHz.

The other test I should do is to see how quickly the trace drifts away
from 0dB - after calibration and with the test port open.
I know the white unit is worse there too, just from informally testing it,
but it would be good to do it properly.

Also, it seems logical, well to me at least, that sealing up the sides to
limit air currents will improve these stability type results on both
devices. I haven't tried that though.

Roger


On Mon, 2 Sep 2019 at 19:18, Warren Allgyer <@allgyerw> wrote:

Hugen

With all due respect, the thread you cite says clearly there is no
operational difference among the fully shielded, "better" versions, the
"worse" clones, and the worst. No one has presented operational data that
distinguishes clone performance at any level. The thread actually says
slightly better performance was had from unshielded clones.

The images presented on the data comparison are indeed cut-and-paste
images from advertisements but they are identical to the actual VNAs in my
possession. I have posted an actual picture of my units as well so you can
see the images used for identification are identical.

The data I have published shows no significant difference between the two
clones.

So let's review:

1) No one, including you, have published any data or test results
demonstrating a significant performance advantage for the "real" unit
versus the clones.

2) No one, including you and me, has been able to publish data showing a
significant performance difference among the clones.

3) I have stated but not published data (I am happy to do so) where I
compared the results of my two clones to a spectrum analyzer/tracking
generator/RF bridge combination and found no significant variance in
results among all three devices.

The qualities of the original versus the clones...... so far..... have
been distinctions without differences. Those differences have been cosmetic
only and no one has shown a resulting measurement discrepancy.

I challenge you or anyone on this board to publish actual data showing
that a clone performs significantly worse than an "original". I don't think
that has been done. The thread you cite certainly does not support measured
differences. If you have data please show it. If not then I think we all
need to stop confusing the readers here. Some people have actually returned
what are likely perfectly good devices because of cosmetics.

WA8TOD




Re: Getting started with the nanoVNA guide

Jerry Gaffke
 

I don't feel I know something until I touch bottom with physical reality,
assuming such a thing exists.

In the case of the S parameters, that means describing them as a vector ratios
of two vector voltages, using complex number arithmetic:
https://en.wikipedia.org/wiki/Complex_number
https://en.wikipedia.org/wiki/Electrical_impedance
https://en.wikipedia.org/wiki/Reflection_coefficient
https://en.wikipedia.org/wiki/Scattering_parameters

Bottom paragraph of post https://groups.io/g/nanovna-users/message/1318
shows that I got hung up on that for awhile. Many sources did not
explicitly state S11 (for example) was a voltage ratio. I assumed it dealt with power,
like SWR. (Historically, some "S parameter" models did deal with power ratios.)

Baier's paper on correction factors has some great stuff, but does not touch bottom:
http://sdr-kits.net/DG8SAQ/VNWA/12_term_dg8saq.pdf
He never bothers to mention that all his variables are vector quantities.
Never describes what physical properties they measure.
Figure 1 shows a two terminal load ZL connected between the
lines representing the incident and reflected voltages (wrong!).
The TX-Oscillator port of Figure 1 is ignored in the math.

Maybe I should let HexAndFlex write that guide to the nanoVNA,
and I'll write a guide to help non-RF people like me navigate Baier's paper.

Jerry, KE7ER

Re: Getting started with the nanoVNA guide

Larry Rothman
 

Looks great!
In the calibration section, you should get the user to calibrate the touchscreen as well. That will go a long way in making the use of the touchscreen a pleasant experience.
One of my earlier Aug posts has the instructions listed.

Regards
Larry

Re: Early app for the NanoVNA

Harry McGavran Jr
 

Thanks -- NICE! Although you might to change the title of of the "Reference Sweep" section of the GUI
to "Import Touchstone File" or some such, since the touchstone files can now be used as either
Referrence or Current sweeps.

Re: Building the firmware

Larry Rothman
 

Excellent!
Thanks

Re: Getting started with the nanoVNA guide

Jeff Anderson
 

On Mon, Sep 2, 2019 at 09:18 AM, Dr. David Kirkby from Kirkby Microwave Ltd wrote:


9) More accurate calibrations will result if the open standard is not used.
The VNA assumes an ideal open, but the open standard just adds capacitance,
making the calibration less accurate. I posted a plot of the phase of both
an untermnated port and one with the open standard. The one with the open
standard was poorer.
Does the software really assume an "ideal" open? In a different thread (https://groups.io/g/nanovna-users/message/1187), Roger Henderson mentioned that the software had programmed into it a C0 value of 50 femtofarads for the open
standard. Would this be enough to compensate for the phase difference you measured?

- Jeff, k6jca

Re: Building the firmware

DMR
 

Compilation of NanoVNA source code in Windows XPx32, Windows 10x64
Installation verified, sorry for possibly inaccurate translation.

Re: Building the firmware

Reginald Beardsley
 

The main limitation to putting the TDR function on the device is RAM. You can write the FFT to pad the end of the frequency domain array with zeros without using up memory, but you still need space for the time domain output.

That said, I've not yet examined the mathematics of time gating and I've not looked at the current FW source yet.

Conditional compilation might let the user select which functions they wanted so for example they might be able to have SWR, log magnitude and TDR for doing antenna work. That would allow tuning antennas, measuring cable losses and finding cable faults with a $35-50 device. And one could always reflash a different set of options.

However, I'm hoping that with expanded functionality using a larger MCU, the OEMs will adopt that instead.

With the basic functionality and design worked out, there is a lot of opportunity to use bigger screens, add USB or SD card support, better packaging, longer battery life, etc.

It would be interesting to know how many companies are building these, but OSSW/OSHW provides an opportunity for an individual with a small amount of capital to enter a market previously restricted to much larger and more heavily capitalized companies. As a consequence, basic T&M kit has dropped tremendously. A personal lab bench that was unthinkable for a grad student 30 years ago is readily affordable. I was one of those poor grad students who could do almost nothing. I was not an EE, so I could not use the department labs.

Have Fun!
Reg

Re: Upgrade MCU from STM32F072C8T6 to STM32F303CCT6

Jose Luu
 

For more flash memory, the STM32F072CBT6
( note: CB instead of C8 ) has 128k flash instead of 64k and will work
without hassles. I have heard that sometimes the C8s where actually CBs,
therefore you may just try your luck flashing a bigger firmware before
attempting surgery.

Ref: page 124 of the datasheet
https://www.st.com/resource/en/datasheet/stm32f072c8.pdf

Jose



On Mon, Sep 2, 2019, 17:41 Reginald Beardsley via Groups.Io <pulaskite=
yahoo.com@groups.io> wrote:

Is this a pin compatible alternative? If it is, I'm ordering a 2nd unit
from China. And will be doing LQFP rework for the first time also. I had
looked for a pin compatible device myself, but got rather lost in ST's
product selector.

I did some calculations this morning and there is not enough RAM to add
TDR to the existing FW.. But an extra 24 KB would do the trick. It may be
possible to get a 1 microsecond time window and 100-125 ps time resolution
with the more powerful chip.

However, an alternate FW which just did TDR could provide 1 microsecond
and 200-250 ps resolution on the current chip. That would be very useful
in a portable device. And at $35 cheap enough for only occasional use.

Have Fun!
Reg



Re: TDR Python Script

Wim
 

Hi Rune,
First of all, thanks for making this app available, this makes the nanoVNA even more useful!

I Installed your app on my Win7/32bit machine, worked perfectly on the first try. Very nice!

I found one little bug/strange feature: "sweep start "sweep end" can be defined as "500k" to "900M" (easier to type than all those zero's), but this does not work for the markers.
I also was unable to move the markers using the mouse, I thought I read somewhere this should be possible.

Re: TDR Python Script

Rune Broberg
 

Hi,
you're welcome! I changed the marker frequency function in the code that's
on GitHub, but it's a sufficiently minor change that I haven't made a new
.zip file with an executable for it yet. I will probably release a new
build tomorrow, assuming I get a few more new things done.

Making the markers mouse-controlled is among the things I'd *like* to do,
but I'm not entirely sure *how* yet ;-)

--
Rune / 5Q5R

On Mon, 2 Sep 2019 at 18:53, <@_Wim_> wrote:

Hi Rune,
First of all, thanks for making this app available, this makes the nanoVNA
even more useful!

I Installed your app on my Win7/32bit machine, worked perfectly on the
first try. Very nice!

I found one little bug/strange feature: "sweep start "sweep end" can be
defined as "500k" to "900M" (easier to type than all those zero's), but
this does not work for the markers.
I also was unable to move the markers using the mouse, I thought I read
somewhere this should be possible.



Re: Upgrade MCU from STM32F072C8T6 to STM32F303CCT6

Jerry Gaffke
 

Might hold the STM32F on the nanoVNA in reset, should tristate all of it's IO pins.
Wire a new connector to the board to give access to the i2c bus and the A2D's
serialized data, also that STM32F reset pin so it can be easily grounded.
Cable that connector over to a Raspberry Pi.
Port the nanoVNA's STM32F embedded software to the RPi.
https://groups.io/g/nanovna-users/message/1453

Can now have a 27" 1920x1080 HDMI screen, or perhaps a small 5" at 800x400 for portable use.
https://www.amazon.com/Elecrow-800x480-Interface-Supports-Raspberry/dp/B013JECYF2
Can easily add switches and quadrature encoders into the RPi if a mouse is too much trouble.
Compile and run all the STM32F nanoVNA embedded software and any experimental extensions
as one big happy program on the RPi.
Have gigabytes of RAM available for correction factors and plot points and such.
Could still disconnect the RPi from that new connector and go back to a stock nanoVNA,

Jerry, KE7ER

On Sun, Sep 1, 2019 at 07:45 PM, Ken Liao, AA6KL wrote:
Has anyone though of upgrading the STM32F072C8T6 to other MCU with larger SRAM
and flash memory? The original NanoVNA author, ttrftech, uses STM32F303 for
his other project CentSDR and has the chip data defined at

https://github.com/ttrftech/CentSDR/tree/master/NANOSDR_STM32_F303

From the datasheet, it seems that STM32F303CCT6 is a good replacement for the
original STM32F072C8T6. 256KB flash memory versus 64KB; 40KB SRAM versus 16KB.
This enables the possibility of enlarge the sample points from 101 to more
points, and other features.

Before I start rework on th LQFP-48 IC for the first time in my life, I would
appreciate your feedback on the feasibility and suggestions.

Ken

Re: Better, Worse, Worst....... baloney.

Roger Henderson
 

Hi Warren,
There are a couple of real world takeaways from the measurements I think.

One point is that the trace is not anywhere near 60dB at all freqs. It is
only around 25dB RL on the white unit at the highest end in the first test.
To measure RL with a degree of confidence we need about 10dB of 'headroom'.
So that allows you to measure down to maybe 15dB with a few dB if error.
Errors in RL measurements are huge if you get close to the effective
directivity limit of the vna.
If you tried to measure a 20dB RL device then the actual result could be
anywhere in a 10 or 12dB range.

It does not behave a spectrum analyzer and this is not a noise floor. An
antenna measurement for example will often show a dip in the trace well
below this 'accuracy floor'.
That measurement will be rubbish and I will eat my hat if most people don't
fall for it.

The second point is that saved calibrations are pointless if the device
drifts all over the place after calibrating.

The white device drifts more and so for more confidence in that higher
range, it needs to be powered on 'for a while', then a cal done, then the
measurement taken.
That is the same procedure you use for a lab VNA.
The hugen device could be turned on, and a measurement taken right away
using a saved cal.
That procedure matches how you use any other antenna analyser.

Both of the above points are relevant to the simple 'antenna analyzer' use
case. Which is turn it on, attach it to the feedline, and take the
measurement.
The worse the accuracy is then the more expert you need to be to make use
of the device.

I have added the open port tests. After doing a calibration and leaving
overnight the white unit has drifted away from 0dB much more than the hugen
device.
This lends more weight to the above comment - the white unit should be
calibrated immediately before any use.

The bottom line is that I see clear differences between the different units
I have at least.

Roger

[image: image.png]

On Tue, 3 Sep 2019, 5:35 AM Warren Allgyer, <@allgyerw> wrote:

Roger

I am reviewing your comparison results on my phone so I may have missed
something.

What I see is comparisons of the S11 noise floor in the 60-70 dB range
return loss. This is meaningless in the real world for all but the most
critical applications, like comparing the return loss of an N connector
versus an SMA for the example.

A return loss of 30dB equals a VSWR of 1.06:1. A return loss of 40 dB
equals a VSWR of 1.02:1 and is exponentially more difficult to achieve and
measure accurately. For all but the most critical lab measurements return
loss values greater than 30 dB are meaningless. They are also much more
sensitive to calibration errors.

Comparisons of noise floor are interesting and do indeed likely reflect
more care, shielding, and execution against a design. They do not, however,
represent an indication of comparative measurement accuracy at usable
return loss values.

The comparison you could do to measure real world comparative performance
would be to use a 100-500 ohm resistor and measure return loss and other
parameters at, say, 50, 450, and 850 MHz. I will eat my hat if you find
more than 1 dB of difference between the units and I expect it will be far
less than that. I do not have a Hugen unit but the variance between my
worse and worst units for these tests is less than 0.3 dB. NOTE: all units
being compared must have been carefully calibrated using the same set of
OSLIT loads!

In summary, a difference in noise floor between 60 and 70 dB is
meaningless in the real world and has no bearing on the accuracy of the
instrument for normal ranges of use.

WA8TOD
On Sep 2, 2019, at 8:57 AM, Roger Henderson <hendorog@...> wrote:

I have posted some comparisons here between my white 'Gecko/Salamander'
device and my hugen unit:
https://github.com/hendorog/nanovna_test/blob/master/NanoVNA%20comparison.ipynb


In all these traces, the lower the trace, the better. If the device is
theoretically perfect then the trace will be at some ridiculously low
value
as it will ultimately be limited by the mathematical precision in the
calculations.
This is what happens if I save measurements and transfer them to a PC,
do a
calibration and then apply the error correction to the load.
Since these are real physical devices, and they drift around so each
sweep
will be slightly different - even when measuring the same load and not
touching anything.
So perfection doesn't happen, and the trace will slowly float upwards as
the device shows its limitations.

First test file was saved after calibrating both devices right after
power
on.
Second test file was saved after leaving them both on for an hour and
then
calibrating.
Tests 3, 4 and 5 were saved after increasing lengths of time.

There is a clear advantage in the hugen trace after each of the
calibrations.
Over time the two traces eventually come together.

The white unit is quite poor at 900MHz unless it has a good amount of
warm
up time.
The white unit is much worse at the very lowest frequencies in the trace,
and note that it had a Start freq of 1MHz. This was my mistake as the
hugen
unit was starting at 50kHz.

The other test I should do is to see how quickly the trace drifts away
from 0dB - after calibration and with the test port open.
I know the white unit is worse there too, just from informally testing
it,
but it would be good to do it properly.

Also, it seems logical, well to me at least, that sealing up the sides to
limit air currents will improve these stability type results on both
devices. I haven't tried that though.

Roger


On Mon, 2 Sep 2019 at 19:18, Warren Allgyer <@allgyerw> wrote:

Hugen

With all due respect, the thread you cite says clearly there is no
operational difference among the fully shielded, "better" versions, the
"worse" clones, and the worst. No one has presented operational data
that
distinguishes clone performance at any level. The thread actually says
slightly better performance was had from unshielded clones.

The images presented on the data comparison are indeed cut-and-paste
images from advertisements but they are identical to the actual VNAs in
my
possession. I have posted an actual picture of my units as well so you
can
see the images used for identification are identical.

The data I have published shows no significant difference between the
two
clones.

So let's review:

1) No one, including you, have published any data or test results
demonstrating a significant performance advantage for the "real" unit
versus the clones.

2) No one, including you and me, has been able to publish data showing a
significant performance difference among the clones.

3) I have stated but not published data (I am happy to do so) where I
compared the results of my two clones to a spectrum analyzer/tracking
generator/RF bridge combination and found no significant variance in
results among all three devices.

The qualities of the original versus the clones...... so far..... have
been distinctions without differences. Those differences have been
cosmetic
only and no one has shown a resulting measurement discrepancy.

I challenge you or anyone on this board to publish actual data showing
that a clone performs significantly worse than an "original". I don't
think
that has been done. The thread you cite certainly does not support
measured
differences. If you have data please show it. If not then I think we all
need to stop confusing the readers here. Some people have actually
returned
what are likely perfectly good devices because of cosmetics.

WA8TOD






Re: Building the firmware

Larry Rothman
 

Enhancement request: please put a revision or version number on your document so when we download it, we will know more about it.
Thanks

Re: Getting started with the nanoVNA guide

Jerry Gaffke
 

I guess it's traditional. Section 3 figure 2 of the HP document from 1967
that W5DXP pointed to in post 1668 also shows a two terminal load placed
across the incident and reflected signals.
Unlike Baier, they also did this with the source on the left side.

From my rather limited understanding of what's going on, this is simply wrong.
The load should have both a2 and b2 signals from the s-box going into a single port.

We can't really assume a solid ground plane, since we are often dealing
with transmission lines here. So that single port into the load
represents the electrical return path as well.

Am I missing something?

Jerry, KE7ER

On Mon, Sep 2, 2019 at 10:36 AM, Jerry Gaffke wrote:
Figure 1 shows a two terminal load ZL connected between the
lines representing the incident and reflected voltages (wrong!).