开云体育

28 : DERDEI : Use of Standalone [gnuplot] Instead of [maxima]

Hello,

Allow us, please, to confirm the interested Common User,
who already observed that is indeed redundant in this case,
since the use of [maxima], which is still buggy, after thirty-seven
37 years of development:
(software)

is limited to calls of [gnuplot], that is of tool, which is under
development and extremely fruitful in results, for thirty-three
33 years:


Hence, the direct use of [gnuplot] instead of [maxima] is
strongly possible, e.g. in the way we already use it in our work:

[tlnomiva] : Transmission Line Nominal Values without
Tolerance - from Cable Specifications and Technical
Data Sheets : /F/L/O/S/S/ for MS Windows:


Sincerely,

gin&pez@arg

28

29 : ann : our nanovna will be evaluated tonight

31 : On the Uncertainties of the "Standards" - Part II
-
23 : On the Uncertainties of the "Standards" - Part I - 30 September 2019
/g/nanovna-users/message/3517

@ Jeff Anderson
/g/nanovna-users/message/3294 - 30 September 2019
/g/nanovna-users/message/3294 - 28 September 2019

Hello Jeff.

We are terribly sorry for this delayed reply - please, accept our apologies.
Our excuses have to obviously do with the needed work for:

30 : our final report 1 :
/g/nanovna-users/message/3989 - 4 October 2019

Well, after all that said, here are our answers:

JA : "For the Open and Short standards, in what terms (or parameters)
do you define each standard's two uncertainties?"

GZ : Let's look at the [inut.txt] file contents, line-by-line:

(1st):1
(2nd):101
(3rd): -0.01 0.029 -0.01 2. 2.
(4th):1

of which their meaning is as follows:

(1st):(Fields:1):

A flag defining what will be computed and extracted:

0 : complex Gamma
1 : complex Z

(1st) : in the test file [input.txt] : 1

(2nd):(Fields:1):
Number of the above values that will be computed and extracted

(2nd) : in the test file [input.txt] : 101

(3rd):(Fields:5):(From left to Right - below as : a,b,c,d,e):

Uncertainty Data as they are given by the Manufacturer
of the "standards" :

The first 3 fields are for the Magnitude -pure number- of
SHORT, LOAD, and OPEN in this order, and

the last 2 fields are for the Argument -in Degrees-
of SHORT and OPEN, in this order

- there is no need for the Argument of LOAD, because
this is and Undefined one -

(3rd)(a): For the Magnitude of SHORT : this value is its
Lower Error Bound and thus a Negative number must
be given - There is no need for an Upper Error Bound,
because it is always 0, in an attempt to keep the its
Computed Values as close as possible to the the
Boundary of the Unit Circle

(3rd)(a) : in the test file [input.txt] : -0.01

(3rd)(b) : For the magnitude of LOAD : this value is its
Upper Error Bound and thus a Positive number must
be given - There is no need for a Lower Error Bound,
because it is always 0, in order to be the Center of
the Unit Circle which lies at the Origin

(3rd)(b) : in the test file [input.txt] : 0.029

(3rd)(c) : For the magnitude of OPEN : exactly the
same as in (3rd)(a)

(3rd)(c) : in the test file [input.txt] : -0.01

- But, the values in (a) and (c) may differ -

(3rd)(d) : For the argument of SHORT : this value
is the absolute value of its Symmetrical, LOWER
and UPPER bounds and thus a Positive number
must be given

(3rd)(d) : in the test file [input.txt] : 2

(3rd)(e) : For the argument of SHORT : exactly
the same as in (3rd)(d)

(3rd)(e) : in the test file [input.txt] : 2

- the values in (d) and (e) may differ -

(4th) : Inaccuracy of all the readings as
number of questionable units in the Last
Significant Digit

(4th) : in the test file [input.txt] : 1

Best regards,

gin&pez@arg

31

32 : a REGION executable
-
also @Gary O'Neil :
27 September 2019 - /g/nanovna-users/message/3259
26 September 2019 - /g/nanovna-users/message/3091
26 September 2019 - /g/nanovna-users/message/3070

Hello,

Allow us, please, to inform you that we just uploaded the version 101 of
REGION executable:



- 131,584 bytes -

Sincerely,

gin&pez@arg

32

34 : Trying to Limit the Misunderstanding up to its Removal

Hello,

We feel much obligated to all of you in this thread.

The interested Reader and/or the kind Contributor
is giving us the chance to exercise our duty of
explaining our work to him who is asking specific
clarifications about it.

But in addition to that, he is encouraging, motivating,
and inspiring us to search for a possibly more
appropriate place of our small Objective World
in the big Objective World of Metrology, as it is
Publicly expressed by a bunch of a gradually
increasing number of Organizations - today there
are eight 8 of them - which although they are
activated in obviously very different, widely divergent,
Fields of Knowledge [*], they have, however, as their
Common Cause the International Coordination
of Understanding and Correctly Applying of the
Measuring.

Anyway, by the beginning of this year 2019, this
common effort attracted our interest, because it
sounded in our small world as one of the most
interesting experiments in which we would like
to try to be humbly involved.

Therefore, the dawn of Toy Era in our small world,
as it is signified by the Massive Invasion of the
cheap NanoVnas, it forced us to intensify our
searching in this direction, and thus we started
in the preceding last days - thanks to you all -
a more systematic study of the current edition
VIM3 of the International Vocabulary of Metrology,
which was approved by the voting members of
these very eight 8, in order to see if and where
there is a way for our work to come under the
concepts and terms of this very VIM3 or even
of the previous editions of it.

Sincerely,

gin&pez@arg

[*] International Bureau of Weights and Measures
BIPM, as the coordinator of: (1) International
Electrotechnical Commission IEC, (2) International
Federation of Clinical Chemistry and Laboratory
Medicine IFCC, (3) International Laboratory
Accreditation Cooperation ILAC, (4) International
Organization for Standardization ILAC, (5)
International Union of Pure and Applied Chemistry
IUPAC, (6) International Union of Pure and Applied
Physics IUPAC, and (7) International Organization
of Legal Metrology OIML, plus (8) BIPM itself.

34

yin, gin & pez@arg

Thank you for your gracious response and compliance to my request.

In my efforts to understand your project, I think I may have had a bit of an epiphany that may start me toward understanding your needs.

I hope my response here will be of some help toward getting what I believe you are looking for from the NanaVNA users on this forum and possibly elsewhere as well.

I will begin by first referring you to page 12/15 of your presentation document:

I believe the box on the right of page 12/15 describes a four step process that is the functional flow through the software tools you have developed, and have been describing, To summarize the steps, I interpret them as follows:

1)The configuration data for the VNA measurements is entered via the (Physical State) GUI illustrated on page 4/15.
This GUI tool looks like it performs the identical function as the NanoVNA configuration setup when connected to a PC. There is no provision in this GUI tool for the input of Calibration Standards correction coefficients. If my understanding is correct, the omission of calibration coefficients is intentional. Please comment on this and correct me on this assertion. I sense this is a point you wish to make visible without ambiguity or confusion.

2) The results of four VNA measurement sweeps of a short circuit (SH.SC), an open circuit (OP.SC), a load standard (LD.LD), and a device measurement (ME.ME) are collected as 4 independent files and formatted to the input specifications of the REGION tool. These are the tasks of the ANALYSE tool.

A fifth file (INPUT.TXT) is externally and independently created which describes the magnitude only uncertainties to be used by the REGION tool. It is not clear how the uncertainty parameters are determined or specified, but they do not appear to be standards coefficients and are described as uncertainties in magnitude only. I do however suspect that they are intended to be used to statistically bias the measurements of arbitrary calibration devices (equally to or as an alternative to the use of characterized standards); and these are used for the computation of error regions surrounding each of the measured (raw) complex data points. These assertions also need corrected or made clear to remove ambiguity and enhance understanding.

3) Utilizing the output created by the ANALYSE tool; the REGION tool computes DER's and DEI's and outputs the results in both rectangular and polar form for each of the measurement frequencies.

4) Finally; the DERDEI tool formats and plots the computed output results of the REGION tool which then yields the graphical presentation that reveals the bounded region of uncertainty of the measurements.

My comments:

What I think I have been able to comprehend to this point may be close enough for me to offer a few comments that may prove useful toward reaching your goal. While it still remains unclear; I will state your goal here as a desire to obtain multiple random test cases using your software to estimate VNA measurement uncertainty. My guess is that the randomness of measurements made with uncharacterized DIY calibration standards is of special interest/benefit to you in the evaluation and defense of your software and associated algorithms.

If the software flow is as I have described, there may be some minor revisions you could make which would greatly simplify and expedite getting the data you are pursuing.

Referring back to step #1 above; the (Physical State) GUI.Input tool looks redundant to the tasks performed by VNA users traditionally and generally. It appears however that it outputs data in a format that satisfies the input requirements of your ANALYSE tool. There are many sources of S-parameter data, and the RF Test equipment industry has adopted, or at the very least supports Touchstone; a simple, text readable, defacto standardized approach to formatting, porting and saving S-parameter data. I have attached a copy of that standard here for your reference. A simple one line header (e.g. # MHz S MA R 50 ) provides all the information required to interpret the data that follows.

If your REGION tool can be easily modified to accept Touchstone formatted data as its input, you could do away with the GUI.Input and ANALYZE tools altogether, since their task is simply to gather and format the data used in the REGION and DERDEI tools. More importantly; you would gain easy access to more data than you will want or need, as libraries of Touchstone formatted S-parameter data exist in abundance. Furthermore; the ANAlYSE tool is also used to gather data via a GPIB iinterface. This too is not required, as it is only the NanoVNA's (or any VNA) data that is of interest to you, and GPIB is utilized in complex test or volume manufacturing environments, and rarely (if at all) in individual user applications.

Additionally; If modified as described, the REGION tool could be easily combined with a simple input GUI that enables a user to input the four input data files and the parameters necessary to compose the uncertainty limits file.

Appending the DERDEI tool to the REGION tool and compiling them as a single executable would result in a compact and easy to distribute and use utility that would be better positioned to gain exposure and attention across the RF test and measurement community.

Alternatively; your REGION tool if made Touchstone compatible, is sufficient (without need for distribution) to enable you to specify the requirements of random measurements that you may desire of various component types such as Antennas, components, Filters, Amplifiers, etc, and even DIY calibration kits as needed throughout the evolution of your research; leaving your team to assess, compare, and refine the output of the DERDEI tool.

I look forward to your response and perhaps a better understanding of how or if I can advance to a level of understanding where I am able to contribute in a meaningful manner.

--
73

Gary, N3GO

35 : Straight In The Heart of The Matter

@Gary O'Neil - 6 October 2019:
/g/nanovna-users/message/4169

Hello Gary,

Well, to put it simply : in our small world, your
last message sounds really Great ! Thank you
very much; indeed.

OK then. But, it would take some time, in order
to reply you - in a sequence of parts, of course.
Therefore, please, stay tuned.

Kind regards,

73

nikolitsa oe3zgn|sv7dmc & petros oe3zzp|sv7bax @ arg iaoi nfi

35

30 : our final report 1
33 : the mathematical expressions

[ for the sake of completeness of the topic, the contents of this
[ message are just a repetition of the following two 2 messages:
[ 4 October 2019 : /g/nanovna-users/message/3989
[ 5 October 2019 : /g/nanovna-users/message/4068
[ which we wrongly sent outside of this topic
[ -
[ please accept our apologies

30 : our final report 1

29 : ann : our nanovna will be evaluated tonight :
/g/nanovna-users/message/3867

hello all,

this is our final report on the comparison of our
[nanovna] and [vna] in terms of frequency

1 : for nominal values without uncertainty :

red : nanovna - blue : vna

r :
x :

after all that said, accept, please, our humble - but sincere - congratulations

sincerely yours,

gin&pez@arg

30

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

33 : the mathematical expressions

hello,

allow us, please, to emphasize that the mathematical
expressions we used for:

30 : our final report 1 - 4 Oct 2019
/g/nanovna-users/message/3989

are just those mentioned at:
16 : 27 September 2019
/g/nanovna-users/message/3161

that is the ones shown at:


sincerely,

gin&pez@arg

33
30

36 : Primary AnyVNA Measurements

35 : Straight In The Heart of The Matter - 6 October 2019 :
/g/nanovna-users/message/4177
@Gary O'Neil

Hello Gary,

Well, to start from the beginning, would you clarify for us,
please, if would you unreservedly agree with us on that :

"
Primarily, anyVNA measures
( Amplitude Ratio , Phase Difference )
couples in terms of
Frequency
"
?

Regards,

gin&pez@arg

36

gin & pez @ arg;

I am comforted that I seem to be approaching a conceptual understanding of your work. It has elevated my interest.

I am responding to your question with an expanded definition that is intended to enable the separation of the hardware and software components of “Any” VNA measurement.

More precisely, any VNA measures amplitude vs. frequency, and either measures or computes phase in accordance with the architecture of its design, and then performs the mathematics required to yield a result that is declared the complex relationship between a power generated by a source and the power either passed, attenuated/absorbed, or amplified (S21, S12,... Smn, Snm) through a device under test (DUT) or load, and/or the complex relationship between a power generated by a source and the reflected/rejected power at the injection port of the device under test (DUT) or load (S11, S22,... Snn ).

These complex relationships, called Scattering parameters and expressed as transmission and reflection coefficients respectively, are then compared to a normalized set of measurements made of a set of reference impedance standards; the result of which is then used to compute the parameters of influence to transmission, and absorption or reflection by a device under test (DUT).

In the context and spirit of your question as I believe it to be, your statement defines the “hardware” requirements of any VNA measurement system, and we are in agreement on this point. To that end, the primary task of Any VNA is to output a frequency associated complex number pair that is representative of the transmission or reflection coefficient or coefficients it has been configured to provide. Beyond that task, and whether performed internally or externally, all else is derived computationally.

My apologies for not providing the terse response solicited.

--
73

Gary, N3GO

37 : ann : the uncertainties of our nanovna will be estimated tomorrow

37 : The [LeastVNA]

@Gary O'Neil - 6 October 2019 : /g/nanovna-users/message/4194

35 : Straight In The Heart of The Matter - 6 October 2019
/g/nanovna-users/message/4184

-

Dear Gary,

Swell !

We already wrote a detailed draft, as a reply to your
interesting message above, of equal if not more length than that
and we will send it sometime later.

However, we have to interpreter your lengthy message as a kind
of manifestation of hesitation by you - not at all an
unjustifiable one ! - to accept our [AnyVNA] description, that
is of what you already called it "any" VNA, which signifies a
lack of consensus from your side to accept unreservedly that:

"Primarily, [AnyVNA] measures ( Amplitude Ratio , Phase
Difference ) couples in terms of Frequency"

because, according to you:

"More precisely, any VNA measures amplitude vs. frequency, and
either measures or computes phase in accordance with the
architecture of its design"

in which you drop the [Ratio] and [Difference] terms and
exclusively or-ed the measurement with computation, that is
- in our humble opinion - you reduce the Vector Network Analyzer
to a Scalar one, and most importantly, you cancel your attempt
to separate "hw" from "sw" and/or "fw".

After that, because our point of view stays constantly as a
facupov one, that is : From A common User's Point Of View, and
because we trust you, we accept your reservations regarding the
phase in the different ways of "any VNA" realization, and while
we are waiting your full explanations on why your modifications
increase the precision of your "any VNA" description, we
decrease right now our expectations from [AnyVNA] to [LeastVNA],
but we greatly increase its description by giving even more
details as follows - always facupov:

The [LeastVNA] :

(a) has at least one port realized by an external connector
with two sides : an internal and an external ones,

(b) uses an either internal or external device plus internal
circuitry in order to separate two cosinusoidal waves of the
same frequency coexisting at least into its port and beyond
that internally : an Input to- and Output from- the port,
caused by one-or-two coexisting signals at the external side
of its connector,

(c) measures in a range of frequencies "whatever needed" to
form a couple of two dimensionless quantities :

( Amplitude Ratio , Phase Difference )

between two cosinusoidal signals of the same frequency
resulting from- and analogous to- these two Input and Output
waves, respectively, as the first and second operands in these
formed division and subtraction operations,

(d) indicates these two quantities to its user,

(f) provides the user with a conceptual "error" model, that
is with a set of a rather small number of rather simple
algebraic equations, connecting the measurement of any load
with unknown or "known" nominal value Gamma with its indicated
value gamma,

using intermediately three 3 parameters "S", obviously
determinable by measuring three 3 "standard" loads of "known"
nominal value, with obviously the same indications in this
range of frequencies, independently of any other load of
unknown nominal value,

that is, after 4 = 3 + 1 measurements in total,

BUT :

(g) does not provide its user with the means to complete his
measurements because it ignores the uncertainty of these
three 3 "standards" and the inaccuracy of these 8 = 4 x 2
indications.

And we are basing our today description on that 51 years
old simplification - perhaps in the first ever publicly known
related paper - that is:

"is simply a microwave frequency vector ratio voltmeter",

given by Richard H. Hackborn at 'An Automatic Network
Analyzer System', Microwave Journal, May 1968, p.46.

However, yes, indeed. Our research has to do with an investigation
of the possibility of founding a seeing facupov of [AnyVNA] through
[LeastVNA] from now on, or equivalently, after your apt comments,
to see it conceptually. Therefore, we think that we have your
unreserved consensus to this sharable point and thus we put this
Very Cause into our small objective world, that is into our "sow"
from now on.

Please, stay tuned !

Kind regards,

73

nikolitsa oe3zgn|sv7dmc & petros oe3zzp|sv7bax @ arg iaoi nfi

37

Good afternoon nikolitsa oe3zgn|sv7dmc & petros oe3zzp|sv7bax @ arg iaoi nfi;

As I stated in an earlier post, our communications get somewhat contaminated in translation. Please understand that you have my unreserved agreement on your definition. My use of quotation marks encompassing any... i.e. “any” VNA was intended to communicate that I am not all knowing with respect to the architectural differences employed by various equipment manufacturers. In the context of our discussions, I also believe that the hardware choice is not relevant, and that it is your desire to focus on the software independent of the hardware choice in the evaluation of the derived measurement uncertainties. My overtly verbose description was an attempt to separate the hardware from the software, to ensure my understanding of the point that the hardware employed for the measurements is irrelevant.

I have not yet read your response in its entirety. I sensed a priority to put your mind at ease, and respond immediately in that regard. I will comment on anything I feel unclear about your response after giving it my undivided attention.

73

Gary, N3GO






agreement

--
73

Gary, N3GO

Hello again nikolitsa oe3zgn|sv7dmc & petros oe3zzp|sv7bax @ arg iaoi nfi;

In your expanded definition, you state:

“ g) does not provide its user with the means to complete his
measurements because it ignores the uncertainty of these
three 3 "standards" and the inaccuracy of these 8 = 4 x 2
颈苍诲颈肠补迟颈辞苍蝉.”

To be clear on this, and thus my concern for an unambiguous understanding of your approach; this comment raises my concern that you may be contaminating your conclusions due to a potential oversight on your part.
There is a conditional but important (firmware/software) difference that distinguishes the NanoVNA. This difference is my motivation to discuss hardware and firmware/software independently as an assurance that we are playing the same instrument, and hearing the same music. I am curious how that metaphor translates. :-)

The NanoVNA, as with any VNA, outputs results that have been normalized to the measuring equipment environment (offsets and ranges) and then calibrated to a set of fixed standards. The NanoVNA however does not attempt to correct for the characterized uncertainties of the standards, but rather assumes them to be ideal as measured. The key and very important difference is the characterization, and this is what traditionally is employed to offset and thereby minimize and bound the measurement uncertainties to a high tolerance in any (critically used) VNA. While purists will argue (with valid rationale) that the task requires precisely constructed standards devices; short of the normal high quality associated with stability and repeat ability, the task is principally computational.

I will need further clarification if I am remiss in my understanding of the role of the calibration standard uncertainties as a prerequisite requirement beyond their measured values taken as nominal. FACUPOV, where the Common User is a hobbyist that possesses a $50 instrument and perceives it as a fun new toy; most NanoVNAs will never be graced with such fine jewelry.

We are in total agreements on all of your remaining points.

--
73

Gary, N3GO

38 : our final report 2 : core uncertainty strips
37 : ann : the uncertainties of our nanovna will be estimated tomorrow
/g/nanovna-users/message/4218

Hello,

Allow us, please, to inform you that we just uploaded
the Core Uncertainty Strips for our NanoVNA:

r ~ f :


x ~ f :


info
Kernel: 4.0.0
Compiler: GCC 5.4.1 20160919
Architecture: ARMv6-M
Core Variant: Cortex-M0
Port Info: Preemption through NMI
Platform: STM32F072xB Entry Level Medium Density devices
Board: NanoVNA
Build time: Aug 2 2019 - 16:40:01

Sincerely,

gin&pez@arg

38

Good evening GIN&PEZ;

I believe I have had a second epiphany, and I believe I am getting close in my understanding of your project.

I first respectfully suggest that I hold you accountable in part for the difficulty of following the segmented approach of your presentation. This is a subjective (not personal) but technical criticism for the following:

1) Insufficient information is provided in many of your posts to alert a reader to your concerns, questions, suggestions, or criticisms without first navigating to one or more of the embedded links.

2) Our statements are not always translated in precise coordination with our intentions, making it difficult for a reader to be motivated to follow the links as a pre-requisite to comprehending the post.

3) Understanding a post that necessitates toggling back and forth through various links interrupts the reader who is required to divert their attention toward the task of navigating previous posts, and documents.

4) Short logically organized contextually segmented posts are convenient and efficient when engaged 1 to 1. It is uninviting, confusing, or convoluted to potentially beneficial contributors who stumble upon the thread in passing.

I will now dispense with the subjective criticism and return to the task of interpreting and understanding your results.

I have consumed your final report 1 and final report 2; and I find them to be consistent with my understanding to this point. I have also gone back and reviewed our previous exchanges, and I believe I am very close to capturing the objectives of your project.

The above leaves me with the following comments and questions;

1) The graphical data in final report 2 appears excellent as I would anticipate. it is however simply a pair of graphs.

2) Neither final report 1, nor final report 2, nor both of them combined, is insufficient to be termed a final report. I suspect this to be another translational issue, as I have subjectively described at the beginning of this post.

3) The origin, conditions, and requirements of the tests and environment supporting the data is required as a condition of giving it meaning. I assume this is forthcoming, but there is no hint of a final report #3 or a final final report, including a summarized conclusion.

I am encouraged and cautiously optimistic at where I am with my understanding, and hopeful that your findings are at least as well articulated as your series of 5 publications on this topic.

I will be staying tuned.

--
73

Gary, N3GO

Hi Gary -

I am getting close in my understanding of your project

I hope you find time to summarize your journey of discovery
and interpret interesting implications for less diligent folks (me).

Hello Oristo;

It is good to know this topic is being followed. I hope there are others more capable and perhaps more patient than I, and I welcome them to please chime in. It may expedite the pace of this journey and bring it to a timely and worthwhile conclusion.

This has been an onion peeling exercise for me, and I am not yet at a point where I can conclude that my understanding has correctly converged. If I do reach that point, I would need to reproduce their results to confirm my understanding is valid. Much of what is being shared appears guarded, and I’m not yet certain my optimism is well founded. The struggle to get this far cautions me away from any supportive conclusions or opinions.

That said; perhaps I’m approaching a steeper slope on the learning curve, a third epiphany will manifest itself, and I will become immediately enlightened. My hope is that it is a sweet onion. :-)

It is my intellectual curiosity and passion for knowledge that fuels my own efforts, but my patience is being tested by the peripheral effort required to assess the merit of their work. I do remain committed and encouraged however.

--
73

Gary, N3GO

38 : Update - The [LeastVNA]

@Gary O'Neil - 6 October 2019 :
/g/nanovna-users/message/4194

35 : Straight In The Heart of The Matter - 6 October 2019
/g/nanovna-users/message/4184

Hello,

Allow us, please, to inform you that we withdrawn the previous
description of [LeastVNA] given at:

37 : The [LeastVNA] - 7 October 2019
/g/nanovna-users/message/4250

and we corrected, modified, and more abstracted it, as follows:

- - - - - - (c) gin&pez@arg (cc-by-4.0) 2019 : start - - - - - -

An operating [LeastVNA] system:

(1) Includes an internal or external device with at least one
external connector, where the User connects a load

(2) Has an internal or external cosinusoidal voltage generator
working within an operating range of frequencies, briefly:
"source", that produces a cosinusoidal oscillation with
frequency f, briefly: "signal", at the connector load

(3) Produces, with its source, two cosinusoidal voltage waves in
f, coexisting at least into the connector and beyond that
internally, which are directed, with respect to connector, as
Input and Output waves, and named as Reflected wave from the
load R and Incident wave to the load I, respectively, briefly:
"waves"

(4) Separates the coexisting waves R and I and delivers to
itself two signals r and i, which are analogously resulting from
R and I, respectively, with amplitudes and phases ( Ar , Pr )
and ( Ai , Pi ) respectively

(5) Forms a couple of values for the following two dimensionless
quantities:

( Amplitude Ratio AR , Phase Difference PD ),

from these two signals r and i, as follows:

( AR = Ar/Ai , PD = Pr - Pi )

(6) Measures and presents these two values AR and PD to the User
as indications or readings, with a finite number of digits, of
course.

- end : (c) gin&pez@arg (cc-by-4.0) 2019 -

Sincerely,

gin&pez@arg

38

39 : The [LeastVNA] - Update 2

Hello,

Allow us, please, to inform you that we revised and withdrawn
the previous description of [LeastVNA] given at:

38 : Update - The [LeastVNA] - 9 October 2019 :
/g/nanovna-users/message/4432

and then we modified and amplified it, as follows:

- - - - - - (c) gin&pez@arg (cc-by-4.0) 2019 : start - - - - - -

- From A Common User's Point Of View -

An operating [LeastVNA] system:

(1) Includes an internal or external device with at least one
external connector, where the User connects a load

(2) Has an internal or external cosinusoidal voltage generator
working within an operating range of frequencies, briefly:
"source", that produces a cosinusoidal voltage oscillation with
frequency f, briefly: "signal", as its output towards to load

(3) Produces, unavoidably, with its source, two cosinusoidal
voltage waves in f, coexisting at least into the connector, as
well as "far" beyond that, "elsewhere" internally, which are
directed, with respect to the connector, as Input and Output
waves, briefly: "waves", and named as the Reflected wave
from the load and the Incident wave to the load, respectively

(4) These coexisting waves manifest themselves locally in
various places of their paths as two locally coexisting signals,
resulting from these waves and identified by the amplitude
and phase of these two coexisting waves, respectively

(5) Separates, somewhere internally, these two coexisting waves
and delivers to itself, at two special places internally, two
separated signals r and i, identified by the amplitude and phase
of these two separated waves at these special places,
respectively, where these special places are always "far" away,
but equidistantly, from the connector, having amplitudes and
phases ( ar , pr ) and ( ai , pi ), respectively

(6) Forms and measures a couple of values for the following
two dimensionless quantities:

( amplitude ratio a, phase difference p ) ,

from these two separated signals r and i, as follows:

( a = ar/ai , p = pr - pi )

(7) Presents these two values a and p to the User as indications
or readings, with a finite number of digits of course, which are
obviously resulting from the presence of the connected load

Finally, after all that said:

(8) The User should expect that, in general, these two
indications a and p of the internally separated signals r and i
-
once again : at special places "far" away from the connected
load
-
may be quite different from the values A and P, which the User
should except that they exist between the coexisting signals
R and I on the connected load, resulting and identified
respectively from the coexisting waves there, that is from the
load connected there, which is finally the sole responsible of
their appearance during the [LeastVNA] operation
-
the User has been warned

- - - end : (c) gin&pez@arg (cc-by-4.0) 2019 - - - - - - - - - -

Sincerely,

gin&pez@arg

39