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: Strange bug with 5 kHz span
Thanks Erik,
I admit I was puzzled because its obvious that the nanoVNA has only limited memory storage and can only accumulate so many data points. I was guessing by Hugen's use of "segments" that he meant the scan command would allow collecting more data in additional segments of 101 points each. Herb |
Re: Strange bug with 5 kHz span
Erik,
The latest edy555 release says the scan command supports more than 101 points: 0.2.0-20190928 edy555 released this 4 hours ago in-device TDR support (contributed by @cho45) add scan command for multisegment scan excess 101 points fixed invalid sweep at the narrow span (<5kHz) fixed failures caused by a race condition between USB and measuring loop find device automatically in python script Herb |
Re: nanoVNA compared (at HF) to Keysight N9913A
John,
Thanks for the comparisons. Until I can afford a Fieldfox N9913A (like never!), based on comparative results like yours and my own end user tests, I'll trudge along happily with the NanoVNA for my hobbyist needs. Even if I could afford a Fieldfox it would probably sit on the shelf out of fear of accidently damaging it and having repair costs approaching my monthly house payment :) Herb |
Re: VSWR-Plot interrupted
Hello Norbert,
toggle quoted message
Show quoted text
thank you for trying out the software! The VSWR plot is set by default to only show values up to a max of 25 - and the "draw lines" command isn't *yet* clever enough to draw a line to a point that doesn't exist :D So for that reason, it shows as interrupted, because the values are far too large. If you set the VSWR data axis max to 100, it should draw bigger values, if I recall correctly. It's a feature, not a bug! .. but I'll probably fix it anyway ;-) -- Rune / 5Q5R On Sat, 28 Sep 2019 at 16:42, <norbert.kohns@...> wrote:
Hi Rune, |
Re: NanoVNA-Saver 0.0.12
Hi Peter,
toggle quoted message
Show quoted text
after much popular demand, it's now hiding at the bottom of the readme on the GitHub page. Also available at the bottom of the "project homepage" (which is a nice looking version of the readme): I don't expect *anyone* to donate to me for making this. I've had a lot of fun making it, and I'll keep working on it as long as I'm having fun. But the option is there for those who feel such an obligation. :-) -- Rune / 5Q5R On Sat, 28 Sep 2019 at 15:59, peter_pc2a <pc2a@...> wrote:
Its time to give Rune a cup of coffee! |
Re: NanoVNA-Saver 0.0.12
Sounds good! If your firmware has similar / compatible commands, there
toggle quoted message
Show quoted text
shouldn't be any problems with it. I can't vouch for future releases, of course, as I develop for the NanoVNA I happen to have :-) But I am happy if my software also works for your community! -- Rune / 5Q5R On Sat, 28 Sep 2019 at 18:05, BH5HNU <hlimapla@...> wrote:
It may be that there is a problem with my statement. We are currently |
Re: NanoVNA-Saver 0.0.12
It may be that there is a problem with my statement. We are currently testing nanovna-saver and nanovna-f, and it seems that they do not need to be modified to be compatible.Of course, we don't want to release a software that has the same name but different functions as nanovna-saver.
|
Re: NanoVNA V2
I do wonder whether with all the changes being proposed, you'll end up with something so expensive and esoteric that no-one will be able to afford it! Multi-board, plug-in processors, exotic materials. Probably have to be made by HP or whatever there's called today!
Nice to dream, though. Cheers, David -- SatSignal Software - Quality software for you Web: Email: david-taylor@... Twitter: @gm8arv |
Re: NanoVNA-Saver 0.0.12
I'd have wished they'd contact me about it instead, but as it's open
source, they are of course free to use the code. I may need to make sure they don't reuse the name, though, so there isn't confusion about which version is which. Thanks for letting me know :-) -- Rune / 5Q5R =============================== Rune, Yes, as a user of the nanoVNA and with a nanoVNA-F on order, I would hope that only ONE NanoVNA-saver program was required and that it would adapt to either hardware. Duplication and different (potentially incompatible) versions are the last thing we need! Looking forward to more cooperation. 73, David GM8ARV -- SatSignal Software - Quality software for you Web: Email: david-taylor@... Twitter: @gm8arv |
Re: errors of "error" models
Dr. David Kirkby from Kirkby Microwave Ltd
On Fri, 27 Sep 2019 at 20:00, yza <yzaVNA@...> wrote:
19 : "true value" - also : @Dr. David Kirkby : /g/nanovna-users/message/3207 I am interested. As an undergraduate student I spent some of my time at a calibration laboratory run by the Ministry of Defence in the UK. That placement got me interested in metrology, so measurement uncertainly. However, I am *not* a metrologist. I have an interest in the subject, but are not an expert.
I can assure you that I am *not* trapped into assuming that the calibration standards need to be open, short & load. I have designed and sold waveguide calibration kits, where it is totally impossible to make a ¡°open ¡°. In fact, I wrote an explanation of why an open can not be used for waveguide calibrations about a year ago. You almost certainly know why, but I will post the link, hoping to convince you I am not stuck into this open/short/load procedure, and perhaps it will be useful to others However, I am trying to bring to your attention the fact that in the English speaking world, your use of ¡°loads (A, B, C)¡± is *very confusing.* Many people will interpret that as meaning three resistive devices. Instead I believe that you should use the term ¡°*calibration standards (A,B,C)¡±* Personally, I would write something like ¡°calibration standards (A, B, C), where typically A, B and C are a short, open and a load, but A, B & C can theoretically be any combination of three devices which have a different reflection coefficient at every frequency over which they are used¡° Although I admit that it is longer to write, it has several advantages. * It avoids the use of the word ¡°loads¡± which is confusing in the English language. * Making a reference to the three calibration standards typically being a short, open and load will help the reader understand more. * Stating that theoretically the calibration standards can be any combination of three devices having different reflection coefficients, will educate some readers who may not know this. * By stating that theoretically any combination of three devices can be used, will allow you to address the problem I stated earlier, that if the phase of the calibration standards are too similar, the calibration will be poor. I am really trying to help you, but unless you address some of my concerns, in particular the need to write your work in one document that at least some English speaking readers will be able to follow, I fear nobody on this group will understand your work. I have a Fortran compiler (gcc), and probably could compile your Fortran code. However, I am not going to do this unless you can give me a clearer explanation of the scope of your work. Dave -- Dr. David Kirkby, Kirkby Microwave Ltd, drkirkby@... Telephone 01621-680100./ +44 1621 680100 Registered in England & Wales, company number 08914892. Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United Kingdom |
Cal-Kit Standards' Definitions
The NanoVNA firmware (as I understand it) assumes that the SMA Short, Open, and Load standards are ideal, with the single exception of defining the Open to have a C0 50 femtofarads.
I was wondering -- is this a sufficient definition for these standards, given the NanoVNA's frequency limit of 900 MHz? Or should we also be including values for C1-C3, L0-L3, Offset Loss and Offset Zo? So I wrote some Matlab code to calculate a standard's Reflection Coefficient (Gamma) based on Keysight's "Full" model (using C0-C3, L0-L3, Offset Loss, Offset Delay and Offset Zo), and compared this to a simplified model in which all of these values were set to 0 except for C0 and Offset Delay. I've attached a table of results. My conclusion is that the simplified model (C1-C3, L0-L3, and Loss are set to 0, and Zo is set to 50) is perfectly adequate for use with the NanoVNA. But my math could be wrong. Do my results seem correct? (A detailed explanation of what I've done is in the top post of this blog: ) Thanks, - Jeff, k6jca P.S. I did NOT zero-out Offset Delay in my simplified model (I believe (but have not verified) that this delay IS assumed to be zero in the NanoVNA firmware). If the actual Offset Delays for the Open and Short standards are defined by their supplier to be non-zero, then the net effect of zeroing out these delays is to simply move the reference plane of each -- i.e. rotate the Open and Short's reflection coefficients around the Smith Chart circle. However, note that zeroing out the two delays could become an issue if the Short's delay is NOT equal the Open's delay -- you would then lose this difference in delays (should this delta be large enough to be important)). |
Re: NanoVNA does not want to start -solved
DMR
I conducted a small test with IP5303.
IP5303 does not work longer than 30 seconds with a load that consumes less than 65 milliamps. Nanovna consumes 90-110mA. With such a current consumption, IP5303 should power the device for a long time, until the battery energy is depleted. Test with the new IP5303, connect a 47-38 ohm resistor parallel to the capacitor C47. If IP5303 will turn off at a load current of 100mA, then IP5303 is fake, or the elements in its bundle are faulty, although there are few of them. |
to navigate to use esc to dismiss