开云体育

If my hypothesis is correct then that means the impedance of the DUT at say 250MHz will affect the measurement at 750MHz. A possible way to check is to measure a resonator with a sharp dip at 250MHz and then sweep the VNA around 750MHz.

The NanoVNA plot of the coaxial stub shows a few ripples that are unphysical (see attached image). It is unlikely the loss of the coax suddenly increases like that with frequency, and as your home made VNA shows that ripple isn't actually there. The most interesting thing here is that the "real" S11 of the coax should cross the "open circuit" point (or very close to it) given that it has low loss, which should also be very close to the open circuit standard. If the actual impedance is close to the impedance of the open circuit standard, how come the measurement is so far from it? I think we can rule out linearity error because there can't be much linearity error between two very close measurements. Calibration error can also be ruled out because the S11 of the open standard would have to be >1 to generate those graphs shown. The only thing left I can think of is that the fundamental signal is bleeding in because the mixer has very low IIP3, which means that in harmonic mode the distortion of the fundamental IF signal will create a 3rd harmonic and not just the 3rd harmonic RF signal.
I think it's pretty clear from those plots that your homemade 3GHz VNA is the most accurate out of the 3.

Hi Bryan,
thank you for looking into this! I have user selectable scaling on the list
for probably the next release, but I hadn't yet realized, that there might
be cases where a cable would show a negative impedance, as your second
screenshot suggests.

Do you know what values it is supposed to show?

Have you set the NanoVNA to normal (non-TDR) mode before making the
readings?

If you would be willing to send me a Touchstone file of the data, that
would be helpful for testing! :-)
--
Rune / 5Q5R

On Wed, 6 Nov 2019 at 06:28, bryburns via Groups.Io <bryburns=
[email protected]> wrote:

On Tue, Nov 5, 2019 at 02:12 AM, Rune Broberg wrote:

The Time Domain Reflectometry window now has a display of an impedance
transform, showing the calculated impedance of the transmission line the
NanoVNA is looking at from the calibration plane onwards.

Rune,

Thanks for the new release and your continued work on this project. I
took a quick look at your new TDR output.

Not sure what is happening with the new TDR plot you are displaying. The
impulse TDR seems correct; however, the impedance TDR may not be correct.
But, I cannot be sure.

The purpose of the impedance TDR plot is to show the impedance as a
function of time by transforming frequency domain data into the time
domain. Version 0.3.0m firmware (and several others) seem to show what I
would expect on the nanoVNA for the Low-Pass Step Transform of the
frequency domain data. I give 2 simple examples below.

When a length of open ended 50 ohm line is connected to CH0, the impedance
should show ~50 ohms for a time that corresponds to the length of the
transmission line and then the impedance should go to a very large value.
This can be seen in the screen capture of such a cable in the file
"RG316_50ohmCable_0.5m_TDR.png which is attached. This is a piece of RG316
that is ~0.5 m long with the end away from the VNA open. You can see the
marker at 3.47ns which is equivalent to 359 mm along the transmission line
reading 50.3 ohms. I have set the display to read the "resistance" on the
nanoVNA and set the scale to 25 ohms per division. Of course, once the end
of the cable is reached, the resistance goes off scale toward the top
because the cable is open at that distance (time.) Measurements beyond the
end of the cable are not often useful but do represent multiple traverses
along the cable which are caused by mismatches at both ends of the cable.
For the purpose of evaluating the impedance of the transmission line we can
ignore information at times (distances) beyond the end of the cable. We
can verify that the transmission line is ~50 ohms along its length by
moving the cursor in time (or distance.)

To make the point further, I have included a second example
(75OhmCable_1meter.png) which is a piece of 75 ohm coax that is
approximately 1-meter in length. The setup on the nanoVNA was the same.
Here we see that the impedance is showing 74.4 ohms at 5.2ns (538mm) along
the transmission line. And, again, measurements beyond the end of the
transmission line are not important to verifying that the transmission line
impedance is good along its length. Again, we can verify that the
impedance is good for the entire length.

With the TDR plotting in nanoVNA-Saver 0.1.5 I can't see the part that is
of interest. I have shown the two plots from the two cables here from
nanoVNA-Saver 0.1.5. These attachments are
"R316_50ohmCable_0.5m_TDR_nanoVNASaver0_1_5.png" and
"75OhmCable_1meter_nanoVNASaver0_1_5.png". A major part of the problem is
that the impedance scale does not make observations in the range of
interest (50-75 ohms) easily observed. It is not at all important to
represent the entire range of impedance measurement but, it is important to
enable the user to see what is happening in the early part of the time
domain. To facilitate the user observing what is of interest, you need to
enable y-axis scaling as you have on other charts.

Perhaps setting the minimum and maximum impedance values to display will
be enough. The user will know what they are measuring where you cannot
know. I hope these examples illustrate why.

Thanks for considering this issue in your next release.

--
Bryan, WA5VAH

Hi Herb,
I hope someone will be able to help you with the understanding - And I will
be following along the thread closely, as I too am not entirely certain
what it's telling me ;-)

I have put the wish for one or more extra markers for the TDR part on the
TODO list! :-)

--
Rune / 5Q5R

Dear GIN & PEZ
I must, unknowingly, have asked a very wrong question. Apologies for that.
The reason for asking was the simplification to the formula G=m/s
I was assuming, probably very wrong, that any simplification is based on the absence of impact of the factors that are being ignored.
You are able to calculate the uncertainty of the measurement so I was merely interested how the factors being ignored where in magnitude of impact compared to the magnitude of uncertainty of the measurement.
But if this is a stupid question please ignore it and do not spend any time to reply, only state: This is a stupid question.

--
Erik, PD0EK

Thank you GIN & PEZ;

Your post #6529

#73': On the sine qua non Core Uncertainty of AnyVNA - incl. NanoVNA - System
(the message #73 is withdrawn mainly because its conclusion is too weak)

Seems to add significant clarity to my understanding of your project overall;

I will attempt a concise summary of my understanding, and seek your confirmation on this, or clearly illuminate those components of thought where I am in error.

The One port LeastVNA equation:

[#52]

Is a reduced (one-port) expression derived from the full (two port) set of equations

[#16]

and neither of these are new, but are based on the prior works of perhaps many.

The unique property of [#52], (and [#16] as well) is that they describe calibrations of any VNA using just the nominal measurements of the SOL standards, and any nominal DUT measurements from
which the desired DUT parameters are then computed.

An additional unique (and most important property) of the equations is that they do not attempt to correct for any source of uncertainty bias. Correction parameters are intentionally ommitted.

[#16], and [#52] as a subset, are declared the Core equations for any VNA calibration, and define the variables, and computational requirements common to any VNA (All VNA's) for the following reasons:
1) The measurements are performed identically for any VNA
2) The quanity of measurements and computations are identical for any VNA
3) ALL measurement uncertainties that are not common to ALL VNA's are excluded from the computations and results.
4) The equations enable measurements made on any VNA calibrated as a "system" to be compared equally without bias. All known unavoidable uncertainties are common to all VNAs, and are
absorbed equally and identically into the calibration as the overall uncertainty of the measurement system itself.

The Core uncertainty is defined as the unavoidable deterioration of computational precision created when multiplying and dividing by indeterminately large and small quantities, the accumulation of
round-off and truncation errors, and the unavoidable number of mathematical operations required to arrive at a computed final result.

The Core uncertainty, is a computational artifact, that is objectively deterministic, and defines the UNAVOIDABLE MINIMUM boundaries of uncertainty in any VNA, that can not be improved through
the use of higher precision equipment or components. This is the objective of the DERDEI software currrently in the form of a FORTRAN calculator and wxMaxima plotting utility.

In other words...

Sine qua non F(Any)CUPOV. :-)

73

Gary, N3GO

--
73

Gary, N3GO

On Tue, Nov 5, 2019 at 11:40 PM, Kurt Poulsen wrote:

UPS about the R&S TR-Check have you tried to run in W95 compatibility mode and
as administrator ?

Hello Kurt,

After reading T-Check.pdf from you from 2010-01-31,
I tried under Windows 10-64
The Installation files are from 1997.
When trying to start SETUP.EXE it was not possible.
Next I started the MS compatibility check, Windows 8 was recommended, and set.
That does not work too.
Next with administrator rights, no success.

Next try was to install under Windows 7-32. That works.
A test with the provided data file ZVR.S2P works.
But my from NanoVNA-Saver exported, extended S2P file was not accepted.
I could not figure out, what was wrong with the format.

Next I tried VNWA version 36.7.8.1 after reading your text from 2014-01:
How to perform a T-Check for a VNWA Calibration.pdf
A test with data file ZVR.S2P works.
But my from NanoVNA-Saver exported, extended S2P file was not accepted.
I could not figure out, what was wrong with the format.

Next I found the spreadsheet from Erik:
Thread: Trying to understand the T-Check outcome of the nanoVNA
/g/nanovna-users/message/3020
T-Check.xlsx (199 KB)
I could not make it to work with my data file.

Then I posted in /g/nanovna-users/message/6502,
asking for help.
Erik provided a new version of his spreadsheet T-Check.xlsx (220 KB)
/g/nanovna-users/message/6505

I imported my data file T-CheckR31.S2P and it worked, see
/g/nanovna-users/message/6517

I will optimise this spreadsheet to accept direct NanoVNA-Saver
exported S2P files, without modification.
I read, that in case of a symmetric T-Check hardware setup
you could copy to fill last 4 columns:
copy C2-S11Real to C8-S22Real
copy C3-S11Imag to C9-S22Imag
copy C4-S21Real to C6-S12Real
copy C5-S21Imag to C7-S12Imag

73, Rudi DK5FA

On Tue, Nov 5, 2019 at 02:12 AM, Rune Broberg wrote:

The Time Domain Reflectometry window now has a display of an impedance
transform, showing the calculated impedance of the transmission line the
NanoVNA is looking at from the calibration plane onwards.

Rune,

Thanks for the new release and your continued work on this project. I took a quick look at your new TDR output.

Not sure what is happening with the new TDR plot you are displaying. The impulse TDR seems correct; however, the impedance TDR may not be correct. But, I cannot be sure.

The purpose of the impedance TDR plot is to show the impedance as a function of time by transforming frequency domain data into the time domain. Version 0.3.0m firmware (and several others) seem to show what I would expect on the nanoVNA for the Low-Pass Step Transform of the frequency domain data. I give 2 simple examples below.

When a length of open ended 50 ohm line is connected to CH0, the impedance should show ~50 ohms for a time that corresponds to the length of the transmission line and then the impedance should go to a very large value. This can be seen in the screen capture of such a cable in the file "RG316_50ohmCable_0.5m_TDR.png which is attached. This is a piece of RG316 that is ~0.5 m long with the end away from the VNA open. You can see the marker at 3.47ns which is equivalent to 359 mm along the transmission line reading 50.3 ohms. I have set the display to read the "resistance" on the nanoVNA and set the scale to 25 ohms per division. Of course, once the end of the cable is reached, the resistance goes off scale toward the top because the cable is open at that distance (time.) Measurements beyond the end of the cable are not often useful but do represent multiple traverses along the cable which are caused by mismatches at both ends of the cable. For the purpose of evaluating the impedance of the transmission line we can ignore information at times (distances) beyond the end of the cable. We can verify that the transmission line is ~50 ohms along its length by moving the cursor in time (or distance.)

To make the point further, I have included a second example (75OhmCable_1meter.png) which is a piece of 75 ohm coax that is approximately 1-meter in length. The setup on the nanoVNA was the same. Here we see that the impedance is showing 74.4 ohms at 5.2ns (538mm) along the transmission line. And, again, measurements beyond the end of the transmission line are not important to verifying that the transmission line impedance is good along its length. Again, we can verify that the impedance is good for the entire length.

With the TDR plotting in nanoVNA-Saver 0.1.5 I can't see the part that is of interest. I have shown the two plots from the two cables here from nanoVNA-Saver 0.1.5. These attachments are "R316_50ohmCable_0.5m_TDR_nanoVNASaver0_1_5.png" and "75OhmCable_1meter_nanoVNASaver0_1_5.png". A major part of the problem is that the impedance scale does not make observations in the range of interest (50-75 ohms) easily observed. It is not at all important to represent the entire range of impedance measurement but, it is important to enable the user to see what is happening in the early part of the time domain. To facilitate the user observing what is of interest, you need to enable y-axis scaling as you have on other charts.

Perhaps setting the minimum and maximum impedance values to display will be enough. The user will know what they are measuring where you cannot know. I hope these examples illustrate why.

Thanks for considering this issue in your next release.

--
Bryan, WA5VAH

I am preparing to update the PCB version of NanoVNA-H to V3.4. The UART port will be reserved，hhis makes it easy to DIY Bluetooth connection. It is expected that the relevant test will be completed next week and the schematic will be uploaded to github. If something goes well I will sell the new version of NanoVNA-H in December.

I believe I can apply stuff from the links.
Thanks.

But I 'll need to read ALL messages first to comment on them.

Since I do not see how to reply to the thread and not to single message , posting this here may not be any good.

I generally do some "do diligence" in deciding my projects.
Then I try to stick with the decision.
Adding Bluetooth to NanoVNA my goal is to use USB port and appropriate Bluetooth dongle.
I have no desire to muck around the NanoVNA PCB nor learn innards of used processor.
I am well aware of limits of standard Bluetooth.

Thank you GIN & PEZ



--
73

Gary, N3GO

it's not clear what you're expecting and what is wrong... Could your please explain?

In general I see some issues with divider:

1) Two 20 k resistors leads to 40k continuous load on the battery. So, the battery will have leak and continuous discharge.
4.2V / 40k = 105 uA. This is too much for power off mode.

2) With divider you're also needs to take into account VBAT input impedance. I don't know exact value, needs to check the datasheet, but as I remember, ADC has about 10k input. It needs to be taken into account

3) The divider leads to voltage divide (not offset like diode), it needs correction multiplier in the firmware. Current firmware don't have correction multiplier, just correction offset, because it expects simple diode instead of divider on VBAT input.

Battery correction multiplier needs additional calibration value. So, it needs to setup vbat_offset and vbat_scale. It's going to be a bit complicated for ordinary user. I think it's better to keep things simple and easy.

I used resistors to make a voltage divider, and tied the 20K across D2 and the 100K from D2- to C47 gnd.
In the attached image, currents with VBATEN on and off show 60 and 35 uA, respectively.
One image shows the resistors installed...they are the smallest 1% I have, and for the first time in a long time, I felt like a bull in a china shop using a baseball bat trying to solder those GIANT 1/8W resistors onto the SMD board.
The screen shows 3324 mV, and the batt measures 4200. It is, of course, uncalibrated. The Nano is using a voltage offset for a diode, and I have installed a voltage divider with a fixed scale of 1.4. It is reported ~900mV low. Not sure how to make sense of that, unless the version I am running is not actually accounting for any drop at all. I think that I am a version behind, and will correct that in the next day or so. Hmm...just checked. Running 0.4.3, the latest on my drive. Guess I don't know how to check or change the diode drop...

I'd like to work with a dev to test the stability of the voltage divider. Based on my experiences with real time embedded systems, the averaging of 32 samples should not be necessary. With any sampling system, there is a settling time after input is selected. I have not looked it up in the manual yet, but I understand many of the issues surrounding ADC sampling, in general. In fact, wrt the diode, that circuit might benefit from a small cap to stabilize the circuit.

How much to the 32 samples differ? That is, what are the stats: avg, std dev, etc? In terms of what we are doing, how much accuracy do we need?

A comment about data fitting. It is possible to fit almost any crummy data with a poly of high enough degree. The downside is that although all the data point may fit using that approach, twixt data points the poly might wander afar. It helps to have a feeling for the type of system response: linear, poly, power, trig, etc. Then determine what constitutes a reasonable fit. THEN analyze the data, and see if it meets your expectations.

I use the attached spreadsheet because I can have several data sets on the same sheet and keep them visually in mind.
The sheet as attached shows the fit for the 20k-100k divider, and has a feature to show enabling VBATEN.

I'll prolly download some code and look at it, but I am not prepared to compile...I assume that I need to install a fair bit of software to get to that point, and I'd rather...in the short run especially...work with someone who already does all that.

73 de Rich NE1EE
On the banks of the Piscataqua

Rune,
I'm still hoping someone can help me understand the new TDR impedance measurement display ( see message /g/nanovna-users/message/6520 ). One other thing in regards to the TDR display which I hope eventually makes your "to do" list is related to the attachment.

The cable assembly in the attachment was made up of a 0.3m length of RG-174, a BNC bullet and a 1m length of RG-223 terminated in a 50 ohm load. The TDR measurement display showed a peak at around 0.3m for the RG-174 cable and then another peak at around 1.3m for the RG-223 cable. Very happy with the numbers, but currently NanoVNA-Saver only displays a marker for the highest peak, which as shown in the attachment, is not always the only peak of interest. It would be great if an additional user selected marker could be enabled to more accurately mark additional peaks.

Best Regards,

-Herb

#73': On the sine qua non Core Uncertainty of AnyVNA - incl. NanoVNA - System
(the message #73 is withdrawn mainly because its conclusion is too weak)

erik@... - 5 November 2019 : /g/nanovna-users/message/6495

Dear Erik,

Thank you very much indeed for your interest in our work and also for the chance
you give us to explain it -always facupov, of course- further !

Therefore, regarding your specific question:

"How are you sure the errors to be corrected are larger than the uncertainty in
your measurement. e.g. you are not trying to correct an already (almost) perfect
VNA?"

allow us, please, to definitely clear without any doubt that in our sow [#24], [#34]
we are only * c u r r e n t l y * sure for the following - but we hope to excuse us
because, maybe unfortunately enough, we selected to explain all that using
purposely a greatly emphatical language:

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

(0) "A perfect VNA" is an object of the * i m p e r f e c t * world of mathematics

(1) "An already (almost) perfect VNA" may be an object in other subjective worlds
- we don't know, but we are ready to include it in our sow, as soon as we will be
provided by the specific quantitative data of its existence

(2) "The Least VNA" is simply AnyVNA that is used as a Reflectometer or
Impedance Meter in terms of frequency of One-Port devices using the well-known
("standard", 'Standard' or Standard) set of three 3 loads {S, L, O}, all with known
nominal values given respectively, not at all by us but by their manufacturers, as
the so-called "{-1, 0, +1}" or whatever similar

[ but loosely, because this may be result in a * B I G * source of misunderstanding
[ since this "set of values" is in fact the one of the couples of values:
[
[ { ( 1 , -180 ) , (0 , undefined ) , ( 1 , 0 ) }
[
[ in terms of their ( modulus , argument ) ordered
[ -
[ that is in order to avoid to mess up the things, the modulus value has always to
[ appear first, after the opening left parenthesis and before the separating comma,
[ and then the second argument value to appear before the closing right parenthesis
[ -
[ pairs or couples of values

although a last -apt, as usual- comment made by our Fellow in Knowledge Garry
O' Neil, N3GO [1], forced us to already think a possible reconsideration of this
definition in the direction of an even more simplification; always facupov, of course

(3) "The LeastVNA measured Impedance" is * I N * F A C T * an * I N D I R E C T *
"measurement", that is a * C A L C U L A T E D * or * C O M P U T E D * result,
just an * O U T P U T * of the well-defined * M A T H E M A T I C A L * function
expressed by the well-known * F O R M U L A * [#52]:



in terms of the measurements of these * T H R E E * loads, made * D I R E C T L Y *
using that * A N Y * V N A *

(4) Obviously this is an * I N S E P A R A B L Y * A S S O C I A T E D * to * A N Y *
* V N A * mathematical expression, a so-called "(mathematical) model", of this
very instance LeastVNA of that AnyVNA.

(5) We did * N O T * invent this relation [#52]:



We just simplified the given one [#16]:



-
as, perhaps, they did that others before us, although we don't know if something
that was really happened.

This is easily verified by anyone who would like to use simple, high-school algebra
on these expressions, by ignoring their complex "nature" and substituting:

(i) g, G in Hellenic gamma, Gamma

(ii) -1, 0, 1 in A, B, C, and

(iii) s, l, o in a, b, c,

respectively, and proceeding with the resulting eliminations.

That's all.

(6) Now, since the 8 = 3 x 2 + 1 x 2 measurements s, l, o, and g, were indicated by
our VNA to us with a * F I N I T E *, * L I M I T E D * * A C C U R A C Y * of just
* T H R E E * 3 *, or * F O U R * 4 * at most, decimal * D * I * G * I * T * S *, it was
extremely natural in our sow to ask ourselves :

HOW BIG WILL BE THE EFFECT IN THE UNAVOIDABLY * C O M P U T E D *
IMPEDANCE, IF WE WOULD TAKE INTO ACCOUNT THAT *J U S T * O N L Y *
O N E *, THE LAST ONE, DIGIT OF THESE FOUR MEASURED VALUES WAS IN
DOUBT ?

THAT IS AS IT HAPPENS IN ANY OTHER MEASUREMENT, BY ANY OTHER
INSTRUMENT, SO WHY NOT WITH THOSE BY AnyVNA OR OUR VNA ?

That's all..

And, once again, definitely this has nothing to do with the perfectness or imperfectness
of AnyVNA itself. But, this definitely has to do with the unavoidably finite number of
reliable digits used by AnyVNA to indicate its measurements.

And this finite number of reliable digits in these four 4 measurements is only JUST
ONE source of error in the finally COMPUTED indirect "measurement".

(8) We emphasized in the above the COMPUTED character of the indirect
"measurement" because, if this INDIRECT "measurement" was a usual DIRECT
measurement, all the doubt would unavoidably restrict to just a few, perhaps even
only the last one, of its resulted digits - but, unfortunately enough, this is not the
case here.

(9) Also, and in addition to all that, the range of measured values (small, less than one
1 in modulus), as well as the particular form of the unavoidable mathematical
expression (ratio of differences of small, less than one 1, in modulus values) FORCED
us to attempt such a research
-
and it would be the GREATEST of OMISSIONS by us, if we did not act in this way,
as long as we declared ourselves not only as "researchers" but in addition as "scientific"
ones...

(10) After all that said, we think that we are ready to answer your question as follows:

- We are NOT interested to correct our "measurement" -in fact one of our VNA itself

- We are NOT interested if the errors to be corrected -in fact ones of our VNA itself-
are larger than the uncertainty in our "measurement" -in fact in the computed indirect
"measurement" of our VNA itself

- We are only * c u r r e n t l y * s u r e * about our currently in use method of estimation
of the above inaccuracy errors, which * U N A V O I D A B L Y * C O N T R I B U T E *
to the ENTIRE "MEASUREMENT" UNCERTAINTY of our two VNA systems
-
that is either of our VNA or of our * N a n o V N A *, * P L U S * our THREE Standards
in just this, the simplest of all the possible uses of these (also currently "the simplest"
use, after our reservation (2) above, that is after Garry O' Neil's comment

- We are * c u r r e n t l y * s u r e * about our currently in use general method of estimation
of all the errors we are currently in place to recognize as REALLY EXISTING in AnyVNA
measurements, that is (a) the above Inaccuracy Errors, PLUS (b) those, definitely larger
than these, Uncertainty Errors given to our three 3 Standards by their manufacturers
-
all together count to finding 28 (real) numbers at most, by taking into account that all
these are in general (real) intervals with two 2 end-point numbers, a lower and an upper one,
so that 2 x (8 + 3 x 2) = 2 x 14 = 28
-
contribute UNAVOIDABLY to the ENTIRE "MEASUREMENT" UNCERTAINTY at least of our
two VNA systems, if nobody's else.

And this is the reason we call this component of the entire uncertainty:

"The sine qua non Core Uncertainty of AnyVNA - incl. NanoVNA - System"

In conclusion:

We are currently sure for that:

Facupov, * UNCERTAINTY * LOWER * THAN* THIS * CORE * UNCERTAINTY *
* IS * ENTIRELY * IMPOSSIBLE * in AnyVNA - incl. NanoVNA - SYSTEM under
its LeastVNA application, as well as,

We are currently sure for that:

Our current method of estimation of this Core Uncertainty is the only known one
as an objectively existing one, even as an object of just our sow - that is it has
a deterministic character - for more than ten years now.

Others may have their own methods of estimation of other types of uncertainty
components, as objects of their subjective worlds - that is they have a statistical
character.

However, facupov, currently we are definitely not interested either on those
uncertainty components or on their estimating methods - fullstop.

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

* You * Have * Been * Warned *

REFERENCES

[1] Gary O'Neil , N3GO - 4 November 2019 :
/g/nanovna-users/message/6432

[#16] : 27 September 2019 :
/g/nanovna-users/message/3161


[#24] : The Main Frame of a Possible Communication - 1 October 2019:
/g/nanovna-users/message/3649

[#34] : Trying to Limit the Misunderstanding up to its Removal - 5 October 2019:
/g/nanovna-users/message/4108

[#52] : Update : The compact SLO formula for [AnyVNA] - 17 October 2019:
/g/nanovna-users/message/5100


With the Best of our Regards,

73

Nikolitsa, OE3ZGN/SV7DMC and Petros, OE3ZZP/SV7BAX

:73'#

Hi Rudi
Understood, thank you.
UPS about the R&S TR-Check have you tried to run in W95 compatibility mode and as administrator ?
Kind regards
Kurt

-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af reuterr@...
Sendt: 5. november 2019 22:38
Til: [email protected]
Emne: Re: [nanovna-users] T-Check for my nanoVNA - Results look excellent below 150 MHz and acceptable up to 300 MHz

Hello Kurt,
Yes I know that the curve is not so very good.
But it was just a priciple test for the procedure chain:
NanoVNA-saver .S2P file save to a T-Check curve with minimal effort, with free tools.


The optimizing starts now :-)
73, Rudi DL5FA

p.s. the T-Check Software from R&S no longer works under Windows 10.

Hi Sam,
you're welcome :-) I have considered interpolation; but my original idea
for the software was to allow more data points to avoid interpolation, and
instead provide better data resolution. For this reason, the default
behaviour of the application is to draw points, not lines - only showing
the actual data available.

If you need more data points, you can increase the "segments" settings to
tell the application to split the swept area into multiple segments of 101
data points each. I think this is in most cases the preferable way to go,
but I could of course be convinced by arguments for the opposite :-)

--
Rune / 5Q5R

Rune,

Thanks for the new version. Has anyone given any thought to using
interpolation to display the data between the measurement points when in
line mode? Sometimes more often than not there isn't a data point where you
would like to have an idea what the value is at the measurement marker when
it is place between points (which can not be done at present). I have used
DSO's that have this ability. Of course one must be aware of the possible
pitfalls.

Sam

Sam Reaves
ARS W3OHM
Owner and Moderator of:
LeCroy Owners Group on Groups.io (Current and Future Group)
LeCroy_Owners_Group on Yahoo! Groups (NOW DEAD Legacy Group)

hello, there is also the opensource project:
30mhz up to 6ghz, the project is around 300 euros.
I'm not saying to make it the same but it can be a starting point for version 2
---
IU4FPF (Pomelli P)

Hello Kurt,
Yes I know that the curve is not so very good.
But it was just a priciple test for the procedure chain:
NanoVNA-saver .S2P file save to a T-Check curve with minimal effort, with free tools.


The optimizing starts now :-)
73, Rudi DL5FA

p.s. the T-Check Software from R&S no longer works under Windows 10.