开云体育

On Wed, 18 Sep 2019 at 19:54, <erik@...> wrote:

Ah. Correct. He did not refer to the model structure but used direct
numbers in the code.

That

c = 50e-15;

needs to be replaced by a function

C(f)=C0 e-15 + C1 e-27 f + C2 e-36 f^2 + C3 e-45 f^3

where C is in farads, and f in Hz.

That's the format used by all HP/Agilent cal kits, which are by far the
most common on the market. Copper Mountain use the same, and others use
something similar.

where for a constant 50 fF, it would be

C0=50, C1=C2=C3=0.

The values of all the Keysight cal kits can be found at



Many kits have different values for male and female parts.

The very common 85033D or 85033E (3.5 mm kits) have identical values for
male and female, but the common 85032B N cal kit does not, and neither does
my 85054B N cal kit. Obviously for APC7 kits it is irrelevant.

It would be good if the user could define a few cal kits, and name them.
For example, the kits I have are

* 85050B (APC7)
* 85052B (3.5 mm)
* 85054B (N)
* 85038A (7-16)
* 85039B (F)

None of those kits are going to be common on the use market at a price hams
are likely to be able to afford, although the 85052B does share the same
coefficients as the 85033D and 85033E, which are quite common. The 85050B
(APC7) can often be found cheaply, but it is not a kit most people are
going to want.

I personally intend building cal kits for every connector I can think of
into a box that the NanoVNA fits in. That's partially out of the
practicalities of never have to carry a cal kit, but partly out of the fact
that I can do it.


--
Dr David Kirkby Ph.D C.Eng MIET
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, CHELMSFORD,
Essex, CM3 6DT, United Kingdom.
Registered in England and Wales as company number 08914892

Tel 01621-680100 / +44 1621-680100

Hi David,
I haven't considered it closely yet. A quick numerical average would be
obvious for doing just a few sweeps, while a more complex look at the data,
including for example showing some form of error bars, might be useful for
more in-depth analysis. I don't necessarily intend to break new ground
here, and I haven't yet looked at what's the industry norm for averaged
display.

Do you have suggestions?

--
Rune / 5Q5R

On Wed, 18 Sep 2019 at 22:15, Dr. David Kirkby from Kirkby Microwave Ltd <
drkirkby@...> wrote:

On Wed, 18 Sep 2019 at 20:30, Rune Broberg <mihtjel@...> wrote:

Hi Bruce,
good to hear that it works! Averaging is on the roadmap, probably for
0.0.11 (or 0.1.0 or 1.0.0, however I name it)

What sort of averaging do you intend doing?

The HP 8753/8720 VNAs use an Infinite impulse response (IIR) filter. It
means that one can take 1000 averages, without storing data for the last
1000 readings, so it is very memory efficient. However, I personally find
annoying as it always concerns me how long to wait before it's safe to take
a measurement, results from previous measurements are still in the output
data. I should sit down one day and read the documentation, or find out the
exact formula used, and work out a time for it to settle to 99% or
something. In practice, I rarely use averaging, but prefering to just
reduce the IF bandwidth.

But of course, averaging has its place - especially if doing an isolation
measurement during the calibration, but on the professional VNAs I never
feel the need to do that. On a profesional VNA, the only use of an
isolation measurement is if there is leakage *outside* the instrument, as
the isolation inside the instrument is good enough to make an isolation
measurement of no benefit. Of course the NanoVNA is different, and
isolation measurements and averaging probably play a greater role.

--
Dr David Kirkby Ph.D C.Eng MIET
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, CHELMSFORD,
Essex, CM3 6DT, United Kingdom.
Registered in England and Wales as company number 08914892

Tel 01621-680100 / +44 1621-680100

I just released 0.0.10:


It's not the most exciting release, but it offers some quality of life
improvements, such as the ability to choose the font size (particularly
useful for Linux users, whose default is a massive 11 pt font).

It also adds debug logging: -d to get log messages to the terminal, or -D
filename.txt to log to a file. Useful if you see crashes!

Additionally, it now supports importing magnitude/angle touchstone files,
and there's been a number of little bugfixes.

As ever, I look forward to hearing what bugs you find, and what new
features you want! :-)

--
Rune / 5Q5R

Dear members,



I can't seem to connect to my usb serial port on my NANOVNA. I want to be
able to use the TAPR Vector Network Analyzer software Version 4.3 and when I
plug in my NANOVNA into my computer's USB port I comes up on the Device
Manager

As: Other Devices > ChibiOS/RT Virtual COM Port.



How do I get it to come up as a USB COM port. Do I have the WRONG Firmware
installed in my NANOVNA? None of the information I have been able to find
tells me how to cure this problem. Can someone on this website tell me
what I have to do to get this running?



Any suggestions on how to get this running appreciated.



73 Dave Hassall WA5DJJ Las Cruces, New Mexico

Website:

QRSS SUPER GRABBER WEBSITE:

On Wed, 18 Sep 2019 at 20:30, Rune Broberg <mihtjel@...> wrote:

Hi Bruce,
good to hear that it works! Averaging is on the roadmap, probably for
0.0.11 (or 0.1.0 or 1.0.0, however I name it)

What sort of averaging do you intend doing?

The HP 8753/8720 VNAs use an Infinite impulse response (IIR) filter. It
means that one can take 1000 averages, without storing data for the last
1000 readings, so it is very memory efficient. However, I personally find
annoying as it always concerns me how long to wait before it's safe to take
a measurement, results from previous measurements are still in the output
data. I should sit down one day and read the documentation, or find out the
exact formula used, and work out a time for it to settle to 99% or
something. In practice, I rarely use averaging, but prefering to just
reduce the IF bandwidth.

But of course, averaging has its place - especially if doing an isolation
measurement during the calibration, but on the professional VNAs I never
feel the need to do that. On a profesional VNA, the only use of an
isolation measurement is if there is leakage *outside* the instrument, as
the isolation inside the instrument is good enough to make an isolation
measurement of no benefit. Of course the NanoVNA is different, and
isolation measurements and averaging probably play a greater role.

--
Dr David Kirkby Ph.D C.Eng MIET
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, CHELMSFORD,
Essex, CM3 6DT, United Kingdom.
Registered in England and Wales as company number 08914892

Tel 01621-680100 / +44 1621-680100

Hi Bruce,
good to hear that it works! Averaging is on the roadmap, probably for
0.0.11 (or 0.1.0 or 1.0.0, however I name it)

--
Rune / 5Q5R

Hi again Erik;

My apologies for misspelling your name on my earlier post. :-O

I re-flashed the 1500 MHz firmware this morning, and have observed no change in behavior. To ensure I'm not on a different page, the firmware build date I'm working with is Sep 14, 2019 - 10:38:20.

The re-flash also confirmed that the DFU software switch works fine, so the update was effortless. I also like that you implemented it as a two step process. I seem to have a propensity to accidentally touch something I shouldn't touch and send the device chasing its tail to places unknown. I often experience many restarts before I get to where I need to be. LOL! The Touch screen cal routine seems to work OK also.

I've been trying to get a better handle on the errors I'm seeing here, so it might be useful if I share what I think I have found that might help with debug... or maybe inspire some definitions to ensure my measurements are valid.

I reduced the display to a single trace... Only to keep my wits about me and not lead me off onto a tangent.... I stepped through each of the display formats in both cal and uncal modes and for both channels to verify expected results.

In channel O, LogMag and phase look fine. CH1 LogMag looks like indeterminate reflection data rather than gain (i.e. S22 vs S21).
Delay is not functional at all (in either CH0 or CH1 and the display is fixed at 1.0 seconds in both channels .
Smith, SWR, Polar, and linear all look OK.

I began to get inconsistent data when I began investigating the Real and Imag displays, so I tried a number of things to establish a starting point and baseline. Too much variability in those results to attempt mapping the process and incremental results here. The net of what I think is contributing to this is that the data is somehow getting corrupted when making display changes. I also discovered that Recall/Save now supports Recall only. Save is no longer an option perhaps? I am able to navigate to the Cal setup menu to initiate a Save when I wish to move stored data positions (Store 3 to Store 0 for example). This works OK so far, and as long as I don't modify the recalled data display in any manner prior to initiating the re-save. Since all results are computed from the corrected set of reflected and transfer coefficient data, I assumed that changing the saved display configuration would have no impact on the calculated results. Is this assumption incorrect? Are there post measurement display changes that invalidate the measurement results?

--
73

Gary, N3GO

Hi Herb,
the .exe releases will continue to be made, and the next one will be out
"soon" (maybe tonight, though it's getting late.)

--
Rune / 5Q5R

Ah. Correct. He did not refer to the model structure but used direct numbers in the code.

On Wed, Sep 18, 2019 at 07:35 AM, <erik@...> wrote:

Are you referring to the "open_model" data in the firmware?
I could not find any reference to that model in the firmware so I guess it is
not used.

Erik, I'm not sure if the NanoVNA-H code at
is the firmware you are referring to, but there is a 50 femtofarad capacitor in
the eterm_calc_es() routine in main.c.

I've attempted to hightlight (sort of) the specific line, below:

- Jeff, k6jca

eterm_calc_es(void)
{
int i;
for (i = 0; i < sweep_points; i++) {
// z=1/(jwc*z0) = 1/(2*pi*f*c*z0) Note: normalized with Z0
// s11ao = (z-1)/(z+1) = (1-1/z)/(1+1/z) = (1-jwcz0)/(1+jwcz0)
// prepare 1/s11ao for effeiciency
float c = 50e-15; <<<<<< 50 femtoFarad capacitance
//float c = 1.707e-12;
float z0 = 50;
float z = 6.2832 * frequencies[i] * c * z0;
float sq = 1 + z*z;
float s11aor = (1 - z*z) / sq;
float s11aoi = 2*z / sq;

// S11mo鈥?= S11mo - Ed
// S11ms鈥?= S11ms - Ed
float s11or = cal_data[CAL_OPEN][i][0] - cal_data[ETERM_ED][i][0];
float s11oi = cal_data[CAL_OPEN][i][1] - cal_data[ETERM_ED][i][1];
float s11sr = cal_data[CAL_SHORT][i][0] - cal_data[ETERM_ED][i][0];
float s11si = cal_data[CAL_SHORT][i][1] - cal_data[ETERM_ED][i][1];
// Es = (S11mo'/s11ao + S11ms鈥?)/(S11mo' - S11ms鈥?)
float numr = s11sr + s11or * s11aor - s11oi * s11aoi;
float numi = s11si + s11oi * s11aor + s11or * s11aoi;
float denomr = s11or - s11sr;
float denomi = s11oi - s11si;
sq = denomr*denomr+denomi*denomi;
cal_data[ETERM_ES][i][0] = (numr*denomr + numi*denomi)/sq;
cal_data[ETERM_ES][i][1] = (numi*denomr - numr*denomi)/sq;
}
cal_status &= ~CALSTAT_OPEN;
cal_status |= CALSTAT_ES;
}

David.

Given the big leakage at high frequencies, would iisolation calibration work there anyway?

On Wed, 18 Sep 2019 at 15:07, <erik@...> wrote:

setting of the adc, the noise floor shows a very different pattern

suggesting the biggest impact on the dynamic range of the NanoVNA is
leakage and NOT noise on CH1.

If you have a NanoVNA with no screening, it would be interesting to know if
some wire wall, in a plastic bag, could be used absorb rather than reflect
RF. Wire wall should be fairly lossy.

In the professional VNAs I have used, are generally best used *without* an
isolation calibration. However, if isolation is used in the calibration, it
needs to be averaged averaged over at least 4 times the number of averages
of the DUT. I wonder if the effectiveness of the isolation could be
improved by averaging a number of isolation measurements.

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

You can use the TAPR PC SW for averaging . See File section of this group
It will not improve directivity or dynamic range

I tried the 1500 MHz firmware yesterday and was happy to see that nanoVNAsaver worked with the extended range. Of course, with the very weak signal levels above 900 Mhz the data plots are quite noisy. It would be wonderful if the software could be set to average multiple scans in order to increase the S/N ratio.

erik@, if you want to get deep measurement for S21, I suggest you to disconnect NanoVNA from PC and perform measurement from the battery. The result will be significantly better. I don't know what is the source of noise with connected USB cable, but USB cable connection has significant influence on measurement.

Interesting measurements!
On my own build VNA using exactly the same principles as the NanoVNA (SI5351 and 3*SA612) but using a PC audio input instead of an on board adc and a PC processor for the dsp work instead of the STM I observed the audio output of the transmission SA612 using a realtime 16k points FFT. This makes the noise versus the 5kHz signal very visible, it clearly shows the frequency dependent leakage where the real noise is independent from the LO signal to the SA612.
The pictures I get are similar to what you get but due to the much longer FFT and thus much smaller bucket size the noise is at -110dB and the leakage signal varies between below noise (sub -110dB) below 100MHz till -50dB when around 900MHz. A full thru signal is at -10dB.
Of course a dead bug style bridge will have lower performance compared to the well done PCB layout of the nanoVNA but the leakage amounts are very similar

On Wed, Sep 18, 2019 at 04:39 PM, Kurt Poulsen wrote:

It also depend what the NanoVNA user gets delivered or purchase later on. If
it is one with a disk, then throw it away

I got this open load with NanoVNA, is it bad?

I received my NanoVNA yesterday. I purchased from this ebay seller: Took about 3 weeks to receive the unit. A friend of mine ordered from the same seller and he got his in less than 2 weeks (he only lives about 50 miles from me) so shipping time varies.

Seems to work fine, as many have mentioned, the toggle switch is not the best but it does work OK. Here's a few pictures of the packaging and NanoVNA I received.

Steve_WB8GRS

On Wed, Sep 18, 2019 at 04:34 PM, Andy G0FTD wrote:

If we also consider a previous statement that the input amp is best measure
with the correct load,why was there no difference between
doing a calibration routine with a SHORT or an OPEN with regards to the noise
floor ?

Just performed test. I disconnected PC to avoid interference and performed measurement from the battery.

SHORT load on CH1: noise floor almost -50 dB above 600 MHz

OPEN load on CH1: noise floor -55..-60 dB

No load on CH1: almost the same as OPEN load

50 ohm load on CH1: noise floor below -70 dB up to 900 MHz

So, the SHORT terminator has most worse case
OPEN terminator is better than SHORT, but worse than 50 ohm.

The best result acheived with 50 ohm terminator on CH1.
It is 10 dB betten than OPEN load and 20 dB better than SHORT load.

I've been looking into what could be done to improve the nanovna's
dynamic range at the +900MHz frequencies, and so discussions about noise
and leakage are very relevant.

I've started my analysis as close as possible to the raw data. The nanovna
already gives the option to read the raw sampled data (command "dump 3"),
which replies with the "Reference" & either "Reflection" or "Through" ADC
signals for each of the 48000KHz samples in a 1 millisecond interval (i.e.
48 samples per channel).

I've temporarily tweaked my firmware for the dump command to instead give
96 consecutive "Through" samples. The following results use this modified
firmware.

*Graph 1 - 190MHz Thru with a cable connecting the 2 ports*
The results of the two sequential sets of 48 samples readings are overlaid,
together with a pure 5KHz signal regenerated from the FFT of the combined
96 samples. What I find astonishing is that the results of corresponding
readings 1 millisecond apart are with in 1 or 2 of each other - the codec
is giving very highly repeatable results. "Samp" and "Samp + 1ms"
completely overlay each other in the graph. The pure wave doesn't exactly
match because of the presence of the 3rd harmonic, which is more easily
seen in the PSD display. Ignoring the 2nd and 3rd harmonic peaks, the noise
floor is around -25dB.

*Graph 2 - 190MHz Thru with Port 2 terminated in 50 ohms*
As expected, the "Thru" input signal is virtually non-existent (although it
has a negative DC bias). The PSD shows no signal, apart from the DC
component. The noise floor is around -45dB

*Graph 3 1.3GHz Thru with a cable connecting the 2 ports*
At this frequency there is still a strong thru signal, but it is visibly
noisier. The PSD shows a noise floor at around -6dB, This is much higher
than at 190MHz, presumably because the codec has been programmed to give an
additional 47.5dB gain at this frequency.

*graph 4 1.3GHz Thru with Port 2 terminated in 50 ohms*
The raw data is showing considerable noise (particularly in comparison with
the equivalent measurement at 190MHz in graph 2), again likely because of
the additional gain. The PSD shows no evidence of any peaks at any
frequencies, although there is a gradual downward trend at higher
frequencies. The "pure" wave overlaid in the upper graph is the result of
the FFT & therefore just reflects the noise at 5KHz.

*graph 5 - as for graph 4, but with "offset 7000"*
The noise levels look very similar to graph 4.

I've included all these results to build some confidence in the approach.

I've only sampled a few frequencies, but cannot explain why I get different
results from Erik's. Further study required!

Rgds,
Dave
[image: 190MHz-Thru.png]
[image: 190MHz-Terminated.png]
[image: 1_3GHz-Thru.png]
[image: 1_3GHz-Terminated.png]
[image: 1_3GHz-Terminated_7KHz.png]