¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Date

Re: errors of "error" models

 

#49 :
first details of our final report 1 :
nominal values comparison :
our [NanoVNA] ~ our [VNA]
-
#30 : our final report 1 - 6 October 2019 :
/g/nanovna-users/message/4179
-

Hello,

Allow us, please, to present the first details of our
final report 1 regarding the Nominal Values of Rho
for our [ref2007box], as they resulted by using
our [VNA] and our [VNA]:

Rho Magnitude:
[VNA] : CYAN - pre-calibrated
[VNA] : BLUE - Nominal Values
[NanoVNA] : MAGENTA - pre-calibrated
[NanoVNA] : RED - Nominal Values:


Rho Argument:
[VNA] : CYAN - pre-calibrated
[VNA] : BLUE - Nominal Values
[NanoVNA] : MAGENTA - pre-calibrated
[NanoVNA] : RED - Nominal Values:


Sincerely,

gin&pez@arg

49#


Re: Nanovna-F is here

 

I would be interested in finding that out also.

Thanks, Dick, W1KSZ

Sent from Outlook<>
________________________________
From: [email protected] <[email protected]> on behalf of David Hartley <dehartley@...>
Sent: Tuesday, October 15, 2019 4:11 PM
To: [email protected] <[email protected]>
Subject: Re: [nanovna-users] Nanovna-F is here

Warren, where did you purchase your NanoVNA-F?
Dave


Re: Am I Fixing my BNC Calibration using Calibration Standards Adjustments in nanoVNA-Saver 0.1.2

 

On Tue, Oct 15, 2019 at 05:26 PM, Kurt Poulsen wrote:


You missed to show us a sweep of the coax cable after tuning to celebrate the
victory ?
Kurt,

Please find attached below the Smith Chart after tuning the parameters. The S11 plot after tuning is the last chart in the first post #4963 above.

I think there is a misspelling in so far you used F for the inductance and H for the capacitance.

I was just reporting what is in the Calibration standards form on nanoVNA-Saver. I am not sure how these are implemented. The image of that form after tuning is attached as (LoadTuning.png) below as well. You may notice that I also did some minor tuning on the load and the Through offset delay.

--
Bryan, WA5VAH


Re: Am I Fixing my BNC Calibration using Calibration Standards Adjustments in nanoVNA-Saver 0.1.2

 

Hi Bryan

Congratulation. Tweeking parameters in NanoVNA-saver is great fun. You missed to show us a sweep of the coax cable after tuning to celebrate the victory ?

I think there is a misspelling in so far you used F for the inductance and H for the capacitance, anyway it does not matter it is the numbers and the sign in front which provide the results.

Kind regards

Kurt



-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af bryburns via Groups.Io
Sendt: 15. oktober 2019 23:28
Til: [email protected]
Emne: [nanovna-users] Am I Fixing my BNC Calibration using Calibration Standards Adjustments in nanoVNA-Saver 0.1.2



Folks,



Because of convenience and several other factors I usually use my nanoVNA through SMA to female BNC connectors. As a result, I calibrate both the nanoVNA and nanoVNA-Saver through the SMA to BNC connectors. One reason I do this is to avoid changing the connector mating to the SMA connectors on the nanoVNA.



I realize that BNC calibration kits are notoriously poor. Mine is no exception. The open I use is the female BNC to SMA adapter that is connected directly to the nanoVNA. Also, the BNC short that I use is likely to have some inductance because there is no insulation around the shorting pin. And, the shorting plane cannot be very close to the center pin of the female BNC even when it is properly connected to the mating connector. The 50-ohm load I am using is 50.0 ohms at DC based on a precision ohmmeter measurement. It does compare quite favorably with other terminations that are rated up to 3 GHz when measured on wider bandwidth VNAs.



With this cal kit, and doing both the nanoVNA calibration and the nanoVNA-Saver calibration, I get a nice clean dot in all of the right places. The short does register on the left side of the Smith chart, the load in the center and the open at the far right side as it should be after the OSLT calibration. However, we know that issues remain. The big question is: How to fix them or determine what errors may exist?



Some of the issues can be most easily observed by connecting a fairly short length of good, low-loss 50-ohm coax on the CH0 port and observing S11 on a Smith chart or looking at the return loss in dB over the frequency range from 50 kHz to 900 MHz. The cable used in the measurements shown in the attachments is a 20" (~0.5m) length of RG213 which has SMA connectors on both ends. It was connected to the BNC through a male-male BNC adapter and a female-BNC to female SMA connector. Yes, this is maximum adapter usage to connect the SMA cable to the SMA connector on the nanoVNA. But, the task here is to determine what is going on with the BNC calibration. My experience says that at frequencies below 900 MHz all of the connectors I am using should be pretty good. The first 2 plots I have attached show the result. I also used a commercially manufactured (surplus) piece of RG-233 with BNC male connectors with very similar results. So, this is definitely ans issue and most likely with the calibration.



Taking a careful look at the figure below contained in "Smith-RG213-WithoutCalTuning.png" I observe at least a few problems. 1) The plot should stay within the Smith chart but does not. 2) The circles which should proceed around the Smith chart in a counterclockwise direction are a) not circles and b) not centered on 50 ohms. Similar issues are observed when looking at the plot in the file "S11-RG213-WithoutCalTuning.png". Clearly their should be no positive values in the plot but there are. Furthermore, there is significant ripple in the plot caused by issues that are not likely the short cable.



So, I asked myself the question: "Can I manipulate the "Calibration standards" parameters in the nanoVNA-Saver application to fix what is wrong with the calibration?" I hasten to point out that I do not have access to high-quality measurement equipment and therefore I am left to figure out what is lacking in my BNC calibration kit. Here is what I did.



I began to try first of all to fix the open calibration by continuing to observe the Smith chart as I changed the "open" parameters C0 and the offset delay. Also by blowing up the scale on S11 phase I could see that using the BNC female as an open there remained a negative going and somewhat quadratically increasing phase ramp at frequencies above 500 MHz which could be due to the capacitance in the BNC female I was using as an open. I found that I could get rid of this negative going and quadratically increasing phase ramp by setting the "Open C0" value to 1100 e-15 H. With this setting the "hook" was removed and a linear phase trend remained. However, with that correction in place, the entire phase had a linear phase ramp. Adjusting the time-delay offset to -55 ps I found that I could then level the phase and get less than 0.4 degrees of phase deviation from zero degrees all the way from 50 kHz to 900 MHz. This seemed to me to be a big improvement. Clearly this is an empirical result but it could be a real description of the difference between a female BNC connector and a real open circuit. After these two adjustments the curve shown in "S11-RG213-WithOpenOnlyTuning.png" was collected. This is an improvement in that the trend in the S11 data is now approximately correct; however, large ripples remain,



During the adjustments of the open parameters, I continually looked at S11 in dB and S11 phase to make sure that what I was adjusting was making the phase more constant over frequency and S11 amplitude move in a correct direction (downward at the high end of the sweep.)



I then began to adjust the tuning parameter "L0" for a short. After a few guesses, I arrived at an adjustment for the short parameter of 1200 e-12 F. Said another way, this is like 1.2 nH of inductance is in the short I am using when compared to a real short. This is plausible for the short which is clearly not at the reference point which I consider to be the end of the center conductor for the female BNC center pin of the adapter to SMA. After this additional adjustment I created the chart shown below as "S11-RG213-WithCalTuning.png". I observe the following 1) There are no longer positive values - a definite improvement. 2) The trend is fairly monotonic out to 900 MHz but not perfect. 3) I haven't included the data for this, but the return loss out to at least 300 MHz is now almost exactly (within <0.02 dB) twice the measured S21 loss of the RG213 cable. Before the adjustments listed here, this was clearly not the case. Because there seems to be a limitation of 4 attachments in this forum, I did not include the S11 Smith chart below; however, the plot is now completely within the Smith chart, the circles get smaller as the number of times around the Smith chart increases, and everything is much more nearly centered on the Smith chart. These are all what I expect for this fairly simple measurement. I can put the Smith chart in a separate post if there is interest in it.



Is this really an improvement or am I kidding myself by tweeking parameters to improve the results of this simple measurement? My opinion is that it is a definite improvement and an approach that other may want to explore. I welcome your comments.



--

Bryan, WA5VAH


Re: Nanovna-F is here

 

Warren, where did you purchase your NanoVNA-F?
Dave


Cal Procedure Question

 

I would like to set up Cal Files for different parts of the
Spectrum. One procedure I have talks about doing that,
but one of the steps (after setting the Frequency Range)
is to hit "Reset".

Now doesn't that delete "All" Cal data ?? Or by setting a
different Frequency Span cause you to create a new Cal
data file while preserving the default Frequency Span
Cal data file ?

Thanks, Dick, W1KSZ
Sent from Outlook<>


Re: SOLT calibration vs. TRL

Dr. David Kirkby from Kirkby Microwave Ltd
 

On Tue, 15 Oct 2019 at 22:03, alan victor <avictor73@...> wrote:

True, however, I was thinking forward as I understand a 3 channel nano
receiver is under development. Further, the technique for obtaining true 2
port s data currently requires unbolting the test device and turning it end
for end. Not sure the calibration in that process would hold up. Thoughts?
Unless a simple after market S parameter test set is developed.

*There are several reasons I believe TRL calibration is not too practical
on a low-cost VNA.*

1) The length of the line section needs to be between 20 & 160 degrees
electrical length - ideally 90 degrees.



So to work at 1 MHz, where the wavelength is approximately 300 m, you need
a line section which is a *minimum* of 300*20/360=16.7 m long, and ideally
300/4=75 m long. This really makes TRL impractical below a few hundred
MHz.

2) As far as I an aware, TRL calibration requires a VNA with an S-parameter
set, and *4 independent receivers.* These are the a1, b1, a2 and b2
receivers. So you need one local oscillator split 4 ways to go to 4
different mixers The output from each mixer has to go to a different
receiver. You can¡¯t switch one mixer and one receiver to measure different
things.

I haven¡¯t looked at the block diagram of the NanoVNA, but I suspect it uses
just one mixer and one receiver, which is what all simple VNAs do to keep
the cost down.

I would not be surprised if the cheapest VNAs from Keysight don¡¯t have 4
receivers.

The real big advantage of a 4 receiver VNA is the ability to do unknown
thru calibration.



That would be the biggest advantage of a 4-receiver VNA to me.

I attach a block diagram of a 3-receiver VNA (top) and a 4 receiver VNA
(bottom). I believe that you will find it considerably more complicated and
so expensive than a NanoVNA.




--
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


Re: Are there any guidelines for hacking the firmware?

 

On Tue, 15 Oct 2019 at 04:16, Dr. David Kirkby from Kirkby Microwave
Ltd <drkirkby@...> wrote:
1) Download the firmware source code
Yes, that's easy enough
Go for it!
It will all make more sense after looking at ttrftech's Github and
downloading the source.
--buck


Re: Nanovna-F is here

 

But why do you have more than one NanoVNA?? Am I missing out on something?? (I understand getting a -F in addition to the original)...
Mike WY6K


"... somewhere in the distance, there's a tower and a light, broadcastin' the resistance, through the rain and through the night..."

On Tuesday, October 15, 2019, 05:50:39 PM CDT, mike watts via Groups.Io <wy6k@...> wrote:

Good information.? I have one mystery though - what do you do with 3 NanoVNAs?? Why multiples?
Mike WY6K


"... somewhere in the distance, there's a tower and a light, broadcastin' the resistance, through the rain and through the night..."

? ? On Tuesday, October 15, 2019, 04:38:23 PM CDT, Bilbo <bilbobaggins@...> wrote:

I got mine a couple of weeks ago, PC software support is sketchy at the
moment but will improve. I love it.


On 10/15/2019 5:04 PM, Warren Allgyer wrote:
Oh...... my....... GOODNESS!!!

I love Nanovna original. I have three of them. But Nanovna-F just arrived and it is simply fantastic. It is heavy, thick, completely encased in aluminum and it has a huge, gorgeous 4.3 inch screen that I can see easily without reading glasses. It feels like comparing an S Class Benz to a Prius. Both are fantastic vehicles but...... well..... who would take the Prius.

Easily a 50 dB dynamic range at 1 GHz. Comparison tests to come but I can already tell it is at least the equal of the little brother.

Did I mention the screen? Just wonderful and I got it for $116.

WA8TOD



Re: Nanovna-F is here

 

Good information.? I have one mystery though - what do you do with 3 NanoVNAs?? Why multiples?
Mike WY6K


"... somewhere in the distance, there's a tower and a light, broadcastin' the resistance, through the rain and through the night..."

On Tuesday, October 15, 2019, 04:38:23 PM CDT, Bilbo <bilbobaggins@...> wrote:

I got mine a couple of weeks ago, PC software support is sketchy at the
moment but will improve. I love it.


On 10/15/2019 5:04 PM, Warren Allgyer wrote:
Oh...... my....... GOODNESS!!!

I love Nanovna original. I have three of them. But Nanovna-F just arrived and it is simply fantastic. It is heavy, thick, completely encased in aluminum and it has a huge, gorgeous 4.3 inch screen that I can see easily without reading glasses. It feels like comparing an S Class Benz to a Prius. Both are fantastic vehicles but...... well..... who would take the Prius.

Easily a 50 dB dynamic range at 1 GHz. Comparison tests to come but I can already tell it is at least the equal of the little brother.

Did I mention the screen? Just wonderful and I got it for $116.

WA8TOD



Re: SOLT calibration vs. TRL

 

That is a nice solution. Who is the manufacturer for the relay? Quality SMA packaged relays are not cheap!

Thanks,


Re: Just got mine. Looking it over.

 

Hi Wes,
NanoVNA-Saver should work fine on whatever flavour of Linux you run,
assuming it has at least Python 3.7 (maybe even 3.6) and is 64 bit. PyQt5,
the user interface library used, isn't available for 32 bit Linux any more.

The Ubuntu instructions in the readme don't do anything Ubuntu specific -
it just hasn't been tested elsewhere.

If you don't want to clone from Github, you can download a zip file from
the "releases" section.

I look forward to hearing how it works :-)

--
Rune / 5Q5R

On Wed, 16 Oct 2019, 00:00 N9KDY, <n9kdy@...> wrote:

So far, loving it, rough spots in the documentation and all. I won't be
using it for deep and dark analyses, just getting ham antennae in-band
and centered where I want them, and co-ax troubleshoothing and the like.
If I am reading the docs right, it can do a whole lot more. Quite the
little gadget.

Just a couple of quick queries:

1) The Android NanoVNA WebApp downloaded and installed nicely. I
unwrapped a brand-new USB-C to USB-C cable (15cm long), plugged one end
into the Nano, the other into the phone with the Nano WebApp running,
and selected "connect" on the phone. "No Device Found." Same cable
works fine to connect two phones together to share a file. (I tried
it.) I guess I'm missing something, perhaps a setting on the NanoVNA
somewhere? Being able to use a phone instead of a laptop or even a
tablet while hanging off a tower would be quite the nice thing.
Pointers, anyone?

2) Any other Linux users out there? What shows up in a cursory pass
through is basically just for Ubuntu. (Sorry, I do NOT use Ubuntu
-anything.- I consider it the WinBlows (WinSucks?) of Linux
distributions. YMMV, of course.) Even the github write-up has nothing
much besides downloading and using an install shell script (which link
takes you to other than a shell script download...) on the cloned git
repository. With luck there will be enough Python stuff in the cloned
directory to get it compiled anyway; wish me luck. That's another
project for a sleepless night in the near future.

So, I'm looking to find the proper and best Linux software to use.
Having just joined this list about an hour ago, I have not yet had a
chance to do a deep dive into the archives to see what has already been
posted. That should happen tonight or tomorrow; replies in the form of
links to previous threads in the list would be appreciated, or new
thoughts if anyone has them.

Thanks in advance.

--
Wes Will
N9KDY




Re: Just got mine. Looking it over.

 

There was a USB c issue with NanoVNA devices up to a few weeks ago When hugen added 2 additional resistors on the connector that tell a USB c host device what is being connected.?
This was discussed in the past few days.?
The original units did not have those resistors.?
To get around this, try using a USB c to usb cable and then back to USB c.?
Also search the forum for the message from hugen about the resistors and USB c sensing.?


On Tue, 15 Oct 2019 at 6:00 PM, N9KDY<n9kdy@...> wrote: So far, loving it, rough spots in the documentation and all.? I won't be
using it for deep and dark analyses, just getting ham antennae in-band
and centered where I want them, and co-ax troubleshoothing and the like.
? If I am reading the docs right, it can do a whole lot more.? Quite the
little gadget.

Just a couple of quick queries:

1)? The Android NanoVNA WebApp downloaded and installed nicely.? I
unwrapped a brand-new USB-C to USB-C cable (15cm long), plugged one end
into the Nano, the other into the phone with the Nano WebApp running,
and selected "connect" on the phone.? "No Device Found."? Same cable
works fine to connect two phones together to share a file.? (I tried
it.)? I guess I'm missing something, perhaps a setting on the NanoVNA
somewhere?? Being able to use a phone instead of a laptop or even a
tablet while hanging off a tower would be quite the nice thing.
Pointers, anyone?

2)? Any other Linux users out there?? What shows up in a cursory pass
through is basically just for Ubuntu.? (Sorry, I do NOT use Ubuntu
-anything.-? I consider it the WinBlows (WinSucks?) of Linux
distributions.? YMMV, of course.)? Even the github write-up has nothing
much besides downloading and using an install shell script (which link
takes you to other than a shell script download...) on the cloned git
repository.? With luck there will be enough Python stuff in the cloned
directory to get it compiled anyway; wish me luck.? That's another
project for a sleepless night in the near future.

So, I'm looking to find the proper and best Linux software to use.
Having just joined this list about an hour ago, I have not yet had a
chance to do a deep dive into the archives to see what has already been
posted.? That should happen tonight or tomorrow; replies in the form of
links to previous threads in the list would be appreciated, or new
thoughts if anyone has them.

Thanks in advance.

--
Wes Will
N9KDY


Re: Can't update firmware

 

You need to install the st32 serial port drivers.?
There is a 24MB zip file on Hugen's Google drive with the drivers.?
Link to the drive should be in the wiki.?
After installing, connect device and wait for driver to load.

On Tue, 15 Oct 2019 at 5:57 PM, xltrader100@...<xltrader100@...> wrote:
I'm trying to install new firmware using DfuSeDemo.
When I start up NanoVNA in DFU mode (with the white screen), and then connect the device to a USB port, Device Manager shows a new Directory is added named "Universal Serial Bus devices", and inside that is a single file, STM32 BOOTLOADER.? But I was expecting a file named STM Device in DFU Mode.

When I start up DfuSeDemo, and Choose... the dfu file "NanoVNA-H_AA_20191009.dfu", the file gets loaded alright (green bar says "File correctly loaded"), but the Available DFU Devices in the dropdown menu at the top left is still blank.

I'd appreciate some help.? Right now, I can't make any changes to the firmware.

Here's another user with the same problem:
/g/nanovna-users/topic/firmware_update_smt_device/34522854?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,20,34522854


Just got mine. Looking it over.

 

So far, loving it, rough spots in the documentation and all. I won't be using it for deep and dark analyses, just getting ham antennae in-band and centered where I want them, and co-ax troubleshoothing and the like. If I am reading the docs right, it can do a whole lot more. Quite the little gadget.

Just a couple of quick queries:

1) The Android NanoVNA WebApp downloaded and installed nicely. I unwrapped a brand-new USB-C to USB-C cable (15cm long), plugged one end into the Nano, the other into the phone with the Nano WebApp running, and selected "connect" on the phone. "No Device Found." Same cable works fine to connect two phones together to share a file. (I tried it.) I guess I'm missing something, perhaps a setting on the NanoVNA somewhere? Being able to use a phone instead of a laptop or even a tablet while hanging off a tower would be quite the nice thing. Pointers, anyone?

2) Any other Linux users out there? What shows up in a cursory pass through is basically just for Ubuntu. (Sorry, I do NOT use Ubuntu -anything.- I consider it the WinBlows (WinSucks?) of Linux distributions. YMMV, of course.) Even the github write-up has nothing much besides downloading and using an install shell script (which link takes you to other than a shell script download...) on the cloned git repository. With luck there will be enough Python stuff in the cloned directory to get it compiled anyway; wish me luck. That's another project for a sleepless night in the near future.

So, I'm looking to find the proper and best Linux software to use. Having just joined this list about an hour ago, I have not yet had a chance to do a deep dive into the archives to see what has already been posted. That should happen tonight or tomorrow; replies in the form of links to previous threads in the list would be appreciated, or new thoughts if anyone has them.

Thanks in advance.

--
Wes Will
N9KDY


Can't update firmware

 

I'm trying to install new firmware using DfuSeDemo.
When I start up NanoVNA in DFU mode (with the white screen), and then connect the device to a USB port, Device Manager shows a new Directory is added named "Universal Serial Bus devices", and inside that is a single file, STM32 BOOTLOADER. But I was expecting a file named STM Device in DFU Mode.

When I start up DfuSeDemo, and Choose... the dfu file "NanoVNA-H_AA_20191009.dfu", the file gets loaded alright (green bar says "File correctly loaded"), but the Available DFU Devices in the dropdown menu at the top left is still blank.

I'd appreciate some help. Right now, I can't make any changes to the firmware.

Here's another user with the same problem:
/g/nanovna-users/topic/firmware_update_smt_device/34522854?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,20,34522854


Re: Am I Fixing my BNC Calibration using Calibration Standards Adjustments in nanoVNA-Saver 0.1.2

 

This looks very interesting, Bryan! I am happy that my little piece of
software has turned out to be able to do things like this ;-)

I am a little curious to see Smith chart measurements of your open, load
and short after doing this calibration adjustment - just to see how much it
changes how they look.

I have wondered a little whether allowing a pure resistive value for the
short would also be relevant?

I'm still looking for a good reference for the calculations for how to
compensate for a "load" standard that has a capacitive component: How does
that look? Is it just like the inductive phase shift with the sign
reversed? Could a load capacitance reasonably be represented by a negative
inductance?
--
Rune / 5Q5R

On Tue, 15 Oct 2019 at 23:28, bryburns via Groups.Io <bryburns=
[email protected]> wrote:

Folks,

Because of convenience and several other factors I usually use my nanoVNA
through SMA to female BNC connectors. As a result, I calibrate both the
nanoVNA and nanoVNA-Saver through the SMA to BNC connectors. One reason I
do this is to avoid changing the connector mating to the SMA connectors on
the nanoVNA.

I realize that BNC calibration kits are notoriously poor. Mine is no
exception. The open I use is the female BNC to SMA adapter that is
connected directly to the nanoVNA. Also, the BNC short that I use is
likely to have some inductance because there is no insulation around the
shorting pin. And, the shorting plane cannot be very close to the center
pin of the female BNC even when it is properly connected to the mating
connector. The 50-ohm load I am using is 50.0 ohms at DC based on a
precision ohmmeter measurement. It does compare quite favorably with other
terminations that are rated up to 3 GHz when measured on wider bandwidth
VNAs.

With this cal kit, and doing both the nanoVNA calibration and the
nanoVNA-Saver calibration, I get a nice clean dot in all of the right
places. The short does register on the left side of the Smith chart, the
load in the center and the open at the far right side as it should be after
the OSLT calibration. However, we know that issues remain. The big
question is: How to fix them or determine what errors may exist?

Some of the issues can be most easily observed by connecting a fairly
short length of good, low-loss 50-ohm coax on the CH0 port and observing
S11 on a Smith chart or looking at the return loss in dB over the frequency
range from 50 kHz to 900 MHz. The cable used in the measurements shown in
the attachments is a 20" (~0.5m) length of RG213 which has SMA connectors
on both ends. It was connected to the BNC through a male-male BNC adapter
and a female-BNC to female SMA connector. Yes, this is maximum adapter
usage to connect the SMA cable to the SMA connector on the nanoVNA. But,
the task here is to determine what is going on with the BNC calibration.
My experience says that at frequencies below 900 MHz all of the connectors
I am using should be pretty good. The first 2 plots I have attached show
the result. I also used a commercially manufactured (surplus) piece of
RG-233 with BNC male connectors with very similar results. So, this is
definitely ans issue and most likely with the calibration.

Taking a careful look at the figure below contained in
"Smith-RG213-WithoutCalTuning.png" I observe at least a few problems. 1)
The plot should stay within the Smith chart but does not. 2) The circles
which should proceed around the Smith chart in a counterclockwise direction
are a) not circles and b) not centered on 50 ohms. Similar issues are
observed when looking at the plot in the file
"S11-RG213-WithoutCalTuning.png". Clearly their should be no positive
values in the plot but there are. Furthermore, there is significant ripple
in the plot caused by issues that are not likely the short cable.

So, I asked myself the question: "Can I manipulate the "Calibration
standards" parameters in the nanoVNA-Saver application to fix what is wrong
with the calibration?" I hasten to point out that I do not have access to
high-quality measurement equipment and therefore I am left to figure out
what is lacking in my BNC calibration kit. Here is what I did.

I began to try first of all to fix the open calibration by continuing to
observe the Smith chart as I changed the "open" parameters C0 and the
offset delay. Also by blowing up the scale on S11 phase I could see that
using the BNC female as an open there remained a negative going and
somewhat quadratically increasing phase ramp at frequencies above 500 MHz
which could be due to the capacitance in the BNC female I was using as an
open. I found that I could get rid of this negative going and
quadratically increasing phase ramp by setting the "Open C0" value to 1100
e-15 H. With this setting the "hook" was removed and a linear phase trend
remained. However, with that correction in place, the entire phase had a
linear phase ramp. Adjusting the time-delay offset to -55 ps I found that
I could then level the phase and get less than 0.4 degrees of phase
deviation from zero degrees all the way from 50 kHz to 900 MHz. This
seemed to me to be a big improvement. Clearly this is an empirical result
but it could be a real description of the difference between a female BNC
connector and a real open circuit. After these two adjustments the curve
shown in "S11-RG213-WithOpenOnlyTuning.png" was collected. This is an
improvement in that the trend in the S11 data is now approximately correct;
however, large ripples remain,

During the adjustments of the open parameters, I continually looked at S11
in dB and S11 phase to make sure that what I was adjusting was making the
phase more constant over frequency and S11 amplitude move in a correct
direction (downward at the high end of the sweep.)

I then began to adjust the tuning parameter "L0" for a short. After a few
guesses, I arrived at an adjustment for the short parameter of 1200 e-12
F. Said another way, this is like 1.2 nH of inductance is in the short I
am using when compared to a real short. This is plausible for the short
which is clearly not at the reference point which I consider to be the end
of the center conductor for the female BNC center pin of the adapter to
SMA. After this additional adjustment I created the chart shown below as
"S11-RG213-WithCalTuning.png". I observe the following 1) There are no
longer positive values - a definite improvement. 2) The trend is fairly
monotonic out to 900 MHz but not perfect. 3) I haven't included the data
for this, but the return loss out to at least 300 MHz is now almost exactly
(within <0.02 dB) twice the measured S21 loss of the RG213 cable. Before
the adjustments listed here, this was clearly not the case. Because there
seems to be a limitation of 4 attachments in this forum, I did not include
the S11 Smith chart below; however, the plot is now completely within the
Smith chart, the circles get smaller as the number of times around the
Smith chart increases, and everything is much more nearly centered on the
Smith chart. These are all what I expect for this fairly simple
measurement. I can put the Smith chart in a separate post if there is
interest in it.

Is this really an improvement or am I kidding myself by tweeking
parameters to improve the results of this simple measurement? My opinion
is that it is a definite improvement and an approach that other may want to
explore. I welcome your comments.

--
Bryan, WA5VAH




Re: Nanovna-F is here

 

I got mine a couple of weeks ago, PC software support is sketchy at the moment but will improve. I love it.

On 10/15/2019 5:04 PM, Warren Allgyer wrote:
Oh...... my....... GOODNESS!!!

I love Nanovna original. I have three of them. But Nanovna-F just arrived and it is simply fantastic. It is heavy, thick, completely encased in aluminum and it has a huge, gorgeous 4.3 inch screen that I can see easily without reading glasses. It feels like comparing an S Class Benz to a Prius. Both are fantastic vehicles but...... well..... who would take the Prius.

Easily a 50 dB dynamic range at 1 GHz. Comparison tests to come but I can already tell it is at least the equal of the little brother.

Did I mention the screen? Just wonderful and I got it for $116.

WA8TOD


Re: SOLT calibration vs. TRL

 

On 10/15/2019 5:03 PM, alan victor wrote:
True, however, I was thinking forward as I understand a 3 channel nano receiver is under development. Further, the technique for obtaining true 2 port s data currently requires unbolting the test device and turning it end for end. Not sure the calibration in that process would hold up. Thoughts? Unless a simple after market S parameter test set is developed.


I use a 4 port (SMA) transfer relay and calibrate through that then when I want to switch ports for a 4 port measurement I simply activate the relays and it reverses the device under test as seen from the nano.I installed the relay into a box with rg405 cables and 2 input / 2 output jacks. It is always the same constant and doesn't change. My nano is fixed connected to it using semi rigid cables. If I ever need a portable one I just buy one, they are cheap enough to have several.




Am I Fixing my BNC Calibration using Calibration Standards Adjustments in nanoVNA-Saver 0.1.2

 

Folks,

Because of convenience and several other factors I usually use my nanoVNA through SMA to female BNC connectors. As a result, I calibrate both the nanoVNA and nanoVNA-Saver through the SMA to BNC connectors. One reason I do this is to avoid changing the connector mating to the SMA connectors on the nanoVNA.

I realize that BNC calibration kits are notoriously poor. Mine is no exception. The open I use is the female BNC to SMA adapter that is connected directly to the nanoVNA. Also, the BNC short that I use is likely to have some inductance because there is no insulation around the shorting pin. And, the shorting plane cannot be very close to the center pin of the female BNC even when it is properly connected to the mating connector. The 50-ohm load I am using is 50.0 ohms at DC based on a precision ohmmeter measurement. It does compare quite favorably with other terminations that are rated up to 3 GHz when measured on wider bandwidth VNAs.

With this cal kit, and doing both the nanoVNA calibration and the nanoVNA-Saver calibration, I get a nice clean dot in all of the right places. The short does register on the left side of the Smith chart, the load in the center and the open at the far right side as it should be after the OSLT calibration. However, we know that issues remain. The big question is: How to fix them or determine what errors may exist?

Some of the issues can be most easily observed by connecting a fairly short length of good, low-loss 50-ohm coax on the CH0 port and observing S11 on a Smith chart or looking at the return loss in dB over the frequency range from 50 kHz to 900 MHz. The cable used in the measurements shown in the attachments is a 20" (~0.5m) length of RG213 which has SMA connectors on both ends. It was connected to the BNC through a male-male BNC adapter and a female-BNC to female SMA connector. Yes, this is maximum adapter usage to connect the SMA cable to the SMA connector on the nanoVNA. But, the task here is to determine what is going on with the BNC calibration. My experience says that at frequencies below 900 MHz all of the connectors I am using should be pretty good. The first 2 plots I have attached show the result. I also used a commercially manufactured (surplus) piece of RG-233 with BNC male connectors with very similar results. So, this is definitely ans issue and most likely with the calibration.

Taking a careful look at the figure below contained in "Smith-RG213-WithoutCalTuning.png" I observe at least a few problems. 1) The plot should stay within the Smith chart but does not. 2) The circles which should proceed around the Smith chart in a counterclockwise direction are a) not circles and b) not centered on 50 ohms. Similar issues are observed when looking at the plot in the file "S11-RG213-WithoutCalTuning.png". Clearly their should be no positive values in the plot but there are. Furthermore, there is significant ripple in the plot caused by issues that are not likely the short cable.

So, I asked myself the question: "Can I manipulate the "Calibration standards" parameters in the nanoVNA-Saver application to fix what is wrong with the calibration?" I hasten to point out that I do not have access to high-quality measurement equipment and therefore I am left to figure out what is lacking in my BNC calibration kit. Here is what I did.

I began to try first of all to fix the open calibration by continuing to observe the Smith chart as I changed the "open" parameters C0 and the offset delay. Also by blowing up the scale on S11 phase I could see that using the BNC female as an open there remained a negative going and somewhat quadratically increasing phase ramp at frequencies above 500 MHz which could be due to the capacitance in the BNC female I was using as an open. I found that I could get rid of this negative going and quadratically increasing phase ramp by setting the "Open C0" value to 1100 e-15 H. With this setting the "hook" was removed and a linear phase trend remained. However, with that correction in place, the entire phase had a linear phase ramp. Adjusting the time-delay offset to -55 ps I found that I could then level the phase and get less than 0.4 degrees of phase deviation from zero degrees all the way from 50 kHz to 900 MHz. This seemed to me to be a big improvement. Clearly this is an empirical result but it could be a real description of the difference between a female BNC connector and a real open circuit. After these two adjustments the curve shown in "S11-RG213-WithOpenOnlyTuning.png" was collected. This is an improvement in that the trend in the S11 data is now approximately correct; however, large ripples remain,

During the adjustments of the open parameters, I continually looked at S11 in dB and S11 phase to make sure that what I was adjusting was making the phase more constant over frequency and S11 amplitude move in a correct direction (downward at the high end of the sweep.)

I then began to adjust the tuning parameter "L0" for a short. After a few guesses, I arrived at an adjustment for the short parameter of 1200 e-12 F. Said another way, this is like 1.2 nH of inductance is in the short I am using when compared to a real short. This is plausible for the short which is clearly not at the reference point which I consider to be the end of the center conductor for the female BNC center pin of the adapter to SMA. After this additional adjustment I created the chart shown below as "S11-RG213-WithCalTuning.png". I observe the following 1) There are no longer positive values - a definite improvement. 2) The trend is fairly monotonic out to 900 MHz but not perfect. 3) I haven't included the data for this, but the return loss out to at least 300 MHz is now almost exactly (within <0.02 dB) twice the measured S21 loss of the RG213 cable. Before the adjustments listed here, this was clearly not the case. Because there seems to be a limitation of 4 attachments in this forum, I did not include the S11 Smith chart below; however, the plot is now completely within the Smith chart, the circles get smaller as the number of times around the Smith chart increases, and everything is much more nearly centered on the Smith chart. These are all what I expect for this fairly simple measurement. I can put the Smith chart in a separate post if there is interest in it.

Is this really an improvement or am I kidding myself by tweeking parameters to improve the results of this simple measurement? My opinion is that it is a definite improvement and an approach that other may want to explore. I welcome your comments.

--
Bryan, WA5VAH