Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Nanovna-Users
- Messages
Search
Re: Owen Duffy on improvised test fixtures
#test-jig
On Thu, Oct 17, 2019 at 12:54 PM, Bilbo wrote:
Because in my experience he is usually correct in what he says, and his blog postings lead to greater understanding of various subjects, mainly due to him challenging what others may take for granted, or worse still, may be inadvertently propagating as false information. There is a lot of misinformation on the internet, and there are very few who seem to be bothered to try and correct it when uncovered. Owen is one I'd always listen to, even if personally challenged by what he has said or written. It's happened to me, I've learnt a lot in the process, and continue to respect him. Regards, Martin - G8JNJ |
Re: Owen Duffy on improvised test fixtures
#test-jig
The question is, why would anyone care what Mr. Duffy has to say?
|
Owen Duffy on improvised test fixtures
#test-jig
While Mr. Duffy was rather unkind to both the NanoVNA and Mr. Broberg, he does have an interesting blog. Here he talks about improvised test jigs
Jim, KA6TPR |
Re: NanoVNA V2 - I vote for a larger instrument...
From: necessaryevil86@...
What I want is a slightly larger display, a 3.2" or a 3.5" is not that much more expensive... But I also know: the most dangerous thing in the world beside a programmer with an soldering iron is a user with an idea... ========================================= There's the NanoVNA-F: Works with Rune's NanoVNA-saver software too. Cheers, David -- SatSignal Software - Quality software for you Web: Email: david-taylor@... Twitter: @gm8arv |
Re: NanoVNA-Saver 0.1.3
Hi Rune,
I have a suggestion. If one tries to adjust a homebrew filter of any kind it would be very helpful to see the result of the adjustment at least for S21 and S11 simultaneously on one plot. In other words, could you please make a flexible window where one could select various data to be displayed on that window simultaneously? Kind regards Norbert, DG1KPN |
Re: NanoVNA-Saver 0.1.3
Hi Gary,
toggle quoted message
Show quoted text
I am aware of the scaling issues. It occurs primarily (only?) when values grow "quite large" or "quite small", and thus can't fit in the assigned fields. I haven't made the fields fixed size, in order to allow for example very large values, but that does mean they can sometimes end up scaling. I am looking to make functions that make sure the values get scaled reasonably, for example using k/M/m/¦Ì unit prefixes. Thanks for the feedback! :-) -- Rune / 5Q5R On Thu, 17 Oct 2019 at 00:50, Gary O'Neil <n3go@...> wrote:
I'm observing that the Text window (left side of the display) resizes |
Re: errors of "error" models
Hello again GIN & PEZ
I wish to have some clarification that I am interpreting the test configuration correctly. What were the Putty commands you used to extract data from the NanoVNA? Can you confirm the data as raw (uncorrected) or post calibration corrected measurements? Your VNA data (blue) appears to have been taken at a significant offset from the reference plane. If this is uncorrected raw data it makes sense in an automated VNA environment. It is also my expectation that you used raw data from both VNA's when producing your full final report 1 results. I am interpreting your full final report 1 as follows: 1. The measurement data given and shown plotted is the independent raw magnitude and phase data collected for each of your set of fully characterized S. L, and O standards on your (Blue) VNA, and the (Red) NanoVNA. 2. The fourth is also measurement data, but it is the raw magnitude and phase data for your fabricated example DUT identified as " Our Standard [ref2007box]" and labeled as gamma. This is the raw measured data of the DUT, and not corrected or modified in any manner to yield a gamma value. 3.The data to this point are inputs to the nominal gamma equation and concludes part 1 of 3 parts (I / III) 4.Part 2 of 3 exercises the equation shown: to yield the corrected value for the DUT with respect to the implied (absolute) accuracy of the characterized SOL standards employed without regard to measurement uncertainties... including any uncertainties embedded within the bounds of the characterized calibration standards employed. - - - For clarification please: The variables used in the gamma equation shown are assumed to be the complex values of the measurements as displayed graphically as magnitude and phase pairs. There are no numerical values or constants in the equation... i.e. the o is symbolic of the open measurement values, the 1 is symbolic of the load standard measurement values, and the lower case gamma is symbolic of the DUT measurement values, etc. There are no calibration correction coefficients used in producing any of this data, nor in any of the computed results plotted in this report. To that point, the calibration standards used are considered ideal and perfect. The upper case gamma is the computed complex result of this equation representing the corrected measured value of the DUT, and is interpreted as the reflection coefficient of the DUT at the measurement frequency. The result of these computations performed at each of the measurement frequencies is then plotted as the corrected "nominal" reflection coefficient of the DUT for both magnitude and phase. This then enables one to graphically visualize the nominal result differences between VNA performance under exactly identical measurement conditions, independent of the standards and DUT used for the comparison, and completes part 2 of 3 (II / III). The inference that one can observe at this point is that the two VNA's being evaluated differ in performance and/or measurement accuracy. If performance and accuracy were identical, one would expect the blue and red data points to overlay precisely. Evident here is that the two VNA's in fact disagree within yet to be defined uncertainty boundaries, revealing the fact that this full final report 1 will be followed by a full final report 2. The NanoVNA is clearly shown, not surprisingly, to be inferior in performance. It doesn't disclose any explanation for the differences shown, but those skilled in the art could quickly and easily identify a number of contributors, as well as quantify the consequence of the performance tradeoffs that the differences imply. The assumption here of course is that trace smoothness versus frequency equates to goodness in performance, but is not an unreasonable assumption.. As to whether or not the nominal measurement differences are a compromising concern is perhaps the intent your work; which I anticipate to next be presented in the context of a mapping of the uncertainty boundaries surrounding this pair of nominal VNA measurement exercises. Part 3 of 3 (III / III) is simply the computed complex impedance derived algebraically from the the equation for expressing reflection coefficient in complex impedance form. This is all quite encouraging. I believe that I am now following your process up to this point. If any of my interpretation to this point is in error, I trust you will correct me where needed. -- 73 Gary, N3GO |
Re: Abbreviated documentation for more simplistic tasks?
On 16.10.2019 19:01, N9KDY wrote:
Not, "Is there?" but what are some of the more simple functions of this thing which might benefit beginning users, so that as I run into them I can perhaps write some?That is great idea. Most people need nanoVNA for quite simple tasks. That said, there are number of useful tutorials on YouTube. Listing them would also help new users. -- 73, Pedja YT9TP Checkout: |
Re: Test fixtures
#test-jig
Oristo, I also ordered two if those, and a couple of 10 db attenuators. They look like a good test jig for experimenting with small components or transformers. I have one of the $9.00 eBay bridges, and a noise source. With a SDR as a detector I can do some Nano to Bridge comparisions, I hope.
|
Re: Possible Issue with ttrftech firmware (0.2.3-11) above 300 mhz
KE8CPD6,
I had the same issue as you. After clearing the config data and recalibrate, it seems to work OK. Here is what I did. - Plug in the USB - Use putty or any terminal software to connect to NanoVNA - At shell interface, type "clearconfig", then "saveconfig". This is equivalent to load "CLEAR_MEMORY_DFU.dfu". - Redo calibration. |
Re: NanoVNA WebApp USB question
Larry Rothman wrote:
I use a hot air gun to loosen the parts.I have a full surface-mount hot-air soldering system with a reasonably accurate temperature control and a set of half-a-dozen or so tips of various diameters. Tooling is not the problem. Actually seeing 0402 size parts well enough to stick them on a circuit board in the correct place, well, now that is a problem. Old age is not for the weak or timid. I had considered modding a cable. Might be worth a try, rather than destroying a mostly-working piece of decent kit trying to solder on something I can't see any longer. -- Wes Will N9KDY |
Re: NanoVNA WebApp USB question
On 10/16/19 4:13 PM, n2msqrp wrote:
I hate paying ten bucks shipping for fifty Well if you can stand the wait, ten bucks (in total) could get you a (small) boat load assortment of sma resistors in maybe 30 +/- values (prob. 10-20 each) from China. Might as well grab some caps, too. BTW love that little 4.3'' microscope! For sma work I prefer my binocular regular optical, but in a pinch that thing might come in handy! Bill |
Re: errors of "error" models
Hello again GIN & PEZ;
Your #51 full final report is a much improved compilation but as mentioned earlier, it is quite difficult to read and follow, much less comprehend, when it requires navigating through numerous links. This report answers some of my questions, and is helpful toward identifying questions that remain for this to be understood. Some of my questions may fall out as I digest this more; based on inferences borne out of my current sense of understanding. As such; I will summarize and then start with some of the more obvious questions needed to fill in some details as I digest more of what you have presented. I believe you presented, in one of your earlier "final" posts, the raw data files used to generate the plots in your "full final". I was frustrated by not having a means to perceive or evaluate that data in my journey toward understanding what is being presented. To that end; I attempted to download and install the software you identified in an earlier post on this topic as an effort to replicate your results. This appeared to be the only means you were providing as a vehicle to our understanding. My attempt at this was abruptly terminated upon my discovery that the link you provided to your Fortran complier openwatcom-fortran][1.9] went dark a few years ago, and further research turned up on shadowed versions. It should be obvious why this is a major issue, but I will explain why it is for me in order that you understand the magnitude of the handicap it presents and the disconnect we have with respect your intentions of presenting your project FACUPOV. 1) Fortran is a powerful programming language, and much high quality legacy code requires it (the compiler) to be supported to ensure that the legacy programs can be maintained and remain relevant. Your source dictates this. 2) Fortran comes in many forms, versions, etc., including the compiler you use or have been using. It must be made available in order to ensure that your source code compiles accurately as you intend it to compile. 3) Fortran source code is quite readable by most skilled programmers who, out of necessity, have become multi-lingual coders as a consequence of making programming their career. A few appear to be on this list. 4) Using any compiler to create an executable product from a source not written for it, as its native compiler and version, is likely going to yield errors. Some errors may be minor and easily corrected; some may require new code and/or structure changes; any and all of which will likely require a seasoned programmer. I may be a bit off of the mark on the following; but I don't believe Fortran is likely the language of choice taught to freshmen programmers recently. 5) FACUPOV; most seasoned RF designers, and many RF technicians are familiar with, and can hack at code in various programming languages; and their skill level may vary from novice to advanced. This may be a Common User asset, but their POV may be vastly different. Any derivative of your work will take on as many different forms as there are attempts made to get it up and running. You might even cringe at some of their craftsmanship, because their interpretation of your work doesn't quite pass muster. 6) Either attempting to work through the above while holding fast to the notion that the tasks will yield legitimate results, or writing independent software to manipulate and exercise your equations in a manner consistent with our very limited understanding thusfar, are both significant tasks, either of which are prone to misinterpretation, miscalculation, and false conclusions about what you wish for us to understand, and I trust you would agree that doing so if far beyond the expectations of being FACUPOV. If I may suggest and recommend a relatively straight forward solution that may advance your progress, whether or not you are successful toward reaching your goal here. I believe your requirements here can be fulfilled by the ambition and skill set of an undergrad, or freshman graduate studant. As I described earlier; I think the entire process you describe in your final report can be coded into a single executable which then could be distributed to clients of interest to you. If I am incorrect in this assessment; it must be concluded that I remain far away from understanding your project. If your passion about your work that comes through in your writings is being correctly interpreted, then I would expect that you would concur such a task is both worthwhile and warranted. You would first have to mentor the student on how each of the component modules interact, from data input to graphical output. Allow them to pursue the task of learning the Touchstone format as the desired format for the input data of the executable. This will greatly mobilize your ability to gather data from competing sources as test cases. If you wish to maintain your automated data collection system as your own and ongoing source of input to the executable, the student could also be tasked to write a separate format conversion module in Fortran to ease the task of reducing the data it provides into a format compatable with the more universal Touchstone format used as input to the executable program. It may be of further benefit to give the student the freedom of choice for the programming language used with the caveat that it needs to yield both a Windows and Linux version. - 73 Gary, N3GO |
Re: NanoVNA WebApp USB question
Well, what is wrong with making a dedicated cable by cutting it, use a small elongated perf board (or etched board? wiring it one to one with the resistors on the board and heat shrinking it all back together?
toggle quoted message
Show quoted text
On 10/16/2019 6:38 PM, N9KDY wrote:
Jacon Zar wrote:socket pitch distance seems to be 0.5mm,I was kind of hoping for something like "0603" or "0402" - standard name for the sizes of passive components.? I'll just open it up and have a look, thanks anyway. |
Re: Possible Issue with ttrftech firmware (0.2.3-11) above 300 mhz
Good Evening Everyone,
It looks like this thread has kinda died a bit. I am still without a fix for my issue. I tried again to updated the firmware this evening and still ran into issues above 300mhz. I calibrated it (see photo of correction turned on) and the photo of the version. Anything beyond the 0.2.x firmware is causing the issues, since 0.1.1 works just fine. I have seen other people have similar issues with the new firmware on this group. |
to navigate to use esc to dismiss