|
Re: Cal-Kit Standards' Definitions
Hi Oristo
Thank you for your lingual suggestions I have printed your input for picking up any more suggestions. Kind regards Kurt -----Oprindelig meddelelse----- Fra: [email protected] <[email protected]> P? vegne af Oristo Sendt: 30. september 2019 11:32 Til: [email protected] Emne: Re: [nanovna-users] Cal-Kit Standards' Definitions I am still puzzling thru this. On page 3: "As seen the trace is not flowing the circumference off the Smithchart which must spiral inwards in a progressive way." .. evidently "flowing" should be "following" and "off the Smithchart" should be "of the Smith chart". I >>guess<<: " which must spiral inwards in a progressive way" should be understood "but is spiraling inwards", e.g. "Instead of following the Smith chart circumference, the trace is seen spiraling inward." .. where this trace is from an unterminated non-ideal cable (not airline), and changing (50 Ohm) LOAD shunt capacitance value C from 51.8 to -108.2 improves "calibration". |
|
Re: NanoVNA V2 - I vote for a larger instrument...
I wonder how many actually wants a small form factor.Me, for one; * not much space next to PC keyboard * hands are usually full when going to work elsewhere, making pocket-size VERY handy. * with more secure connectors, I could hang small, light, wireless nanoVNA V3 on e.g. antenna connector, then access UI from smartphone (carried in belt pouch or another pocket). |
|
Re: errors of "error" models
23 : On the Uncertainties of the "Standards" - Part I
@ Jeff Anderson : /g/nanovna-users/message/3294 Hello, Thank you very much for your most encouraging message ! We much appreciate your interest in our work - thank you. We also thank you for your most valuable * s p e c i f i c * inquiries regarding it, by which you give us the chance to explain it, from a common user's point of view, facupov, as we always try to do. Regarding your first question: JA : "... you mention that the S and O standards have 2 uncertainties each (while the load has 1 uncertainty). How are you defining these uncertainties? " - (c) gin&pez@arg (cc-by-4.0) 2019 : start - allow us, please, to answer its last part as follows: We are not defining the uncertainty of any "standard". If the manufacturer of a "standard" is a decent one then he defines its uncertainties, so we could reservedly adopt it as a 'standard' and proceed in our measurements with it. A "standard" without uncertainties is nothing else than a load with a nominal value, that is one named with a value: e.g. a "standard" of 50 Ohm is just a load of which its "true value" is somewhere near by 50 + j0 Ohm. How much near by? As much as it is defined by its manufacturer. If he did not define how much it is, then we don't know how much. In this, most reasonable way, we could reservedly adopt as a 'standard' at DC any common resistor part on which its manufacturer has put -usually by coded colors- its nominal value in ohms and its tolerance as an implicitly minus/plus percent of its nominal value in ohms, that is : its nominal value and its uncertainty, e.g. as 47 Ohm and 10%, which results, instead of a single "true value", in unaccountably many values, which they lie between the lower value or bound of: 42.3 Ohm = - 10% x 47 + 47 Ohm = - 4.7 + 47 Ohm and the upper value or bound of: 51.7 Ohm = 47 + 10% x 47 Ohm = 47 + 4.7 Ohm or which they lie in the true closed interval of values [ 42.3 , 51.7 ] Ohm Therefore, allow us, please, to think that this example is most than adequate to show the way in which the Uncertainty is defined facupov for this resistor in DC: This is exactly these two 2 values or two 2 errors in the "true value" of 47 Ohm: the lower error or value -4.7 Ohm and the upper error or value of +4.7 Ohm where, also notice that, please, in this case these two 2 errors lie symmetrically to the center value of 47 Ohm. It is very important for our duty of supporting the true -without putting it between double " " or single quotation marks ' '- understanding of our work to conclude the subject with this "footnote": This resistor can be also be considered as a 'standard' with a "true value" of 50 Ohm and an uncertainty expressed by the two 2 error bounds of -7.7 Ohm and +1.7 Ohm, for the lower and upper ones, respectively, and especially : non-symmetrically, simply because its "true value" of 50 Ohm with its unsymmetrical Uncertainty [ -7.7 , +1.7 ] Ohm results in exactly the same invariant interval for the values of this resistor : [ 42.3 , 51.7 ] Ohm, as it is defined by the initial "true value" of 47 Ohm and its symmetrical Uncertainty [ - 4.7 , + 4.7 ] Ohm. Finally, a Warning Sign in capitals for the Common User: THE DECENT MANUFACTURER HAS THE KINDNESS TO SUPPLY THE UNCERTAINTY INFORMATION IN ORDER TO BE USED BY THE COMMON USER So, if either a "common user" feels happy or a Common User feels unhappy when he ignores this uncertainty then this is just another matter of taste - he has been warned. - end : (c) gin&pez@arg (cc-by-4.0) 2019 - Sincerely, gin&pez@arg |
|
Re: Cal-Kit Standards' Definitions
I am still puzzling thru this. On page 3:
"As seen the trace is not flowing the circumference off the Smithchart which must spiral inwards in a progressive way." .. evidently "flowing" should be "following" and "off the Smithchart" should be "of the Smith chart". I >>guess<<: " which must spiral inwards in a progressive way" should be understood "but is spiraling inwards", e.g. "Instead of following the Smith chart circumference, the trace is seen spiraling inward." .. where this trace is from an unterminated non-ideal cable (not airline), and changing (50 Ohm) LOAD shunt capacitance value C from 51.8 to -108.2 improves "calibration". |
|
Re: Issue with Live USB Ubuntu running NanoVNA-Saver
in <module>FWIW, I see this error, but not consistently, on 64-bit Windows 8.1 while running trivial tests of pyqt5 As a Python newbie, 3 possibilities occur to me:without NanoVNASaver even installed.<< 1) I read that some versions of pyqt5 have been more stable than others 2) Just as Windows uses your %PATH% to find executables, Python has its own equivalent, which may be screwed up, e.g. incompatible versions of stuff being found earlier: 3) relative import bug:import sys [ A similar problem can occur in C with #include "foo.h" vs #include <foo.h>, but static C builds force that to be resolved once at build time..] |
|
Re: NanoVNA-Saver 0.0.12
I wrote Jim, W4EME, about implementing S-file data in Elsie. It is there already he told me. However, I get this error when trying to load the file: 2019-09-30 07:53:56,084 - NanoVNASaver.Touchstone - WARNING - Read line without having read header: 3E+08 -.0273661 -94.79335 -89.91359 -7.727735 -89.91359 -7.727735 -1.876088E-02 -108.5768
Attached is the top of an Elsie file. Perhaps I am doing something wrong when trying with Elsie and RFSim99 files? Bo |
|
Re: Cal-Kit Standards' Definitions
Mr. Poulsen, very nice pages and work. Great primer explaining reference planes and delays. I think I'm going to have to read it a few times to absorb everything. I hope someone will modify the calibration instructions in the group files section to include your suggestion and reasoning for not using the open load during calibration.
Jim KA6TPR |
Kurt Poulsen
Oristo
Gyula Molnar
gin&pez@arg
Bo, OZ2M
Starsekr