开云体育

qrp.ddc

Thanks for your reply. I agree it would be very detrimental to the our measurements to put a diode in place that has 10-15 pF of capacitance. I would never recommend that.

Apparently you did not look at the data sheet for the PGB1010603 device I attached above. I did not assume it was 0.06 pf. On page 1 of the data sheet the measured capacitance for the device is 0.06 pf when measured at 250 MHz. At that frequency this corresponds to a reactance of a little over 10,000 ohms. Surely this won't have much impact on measurements in a 50 ohm system at that frequency. Therefore, it appears that this device is substantially different from those with which you are familiar.

I agree we should not use typical voltage suppressor diodes to protect the input to VNA devices. They produce large non-linearities which can really screw up measurements.

Please follow my thinking for a minute. The first page of the data sheet for the device says that the "leakage" current through the device will be less than 1 nano amp at 6 volts. I would think that the current will be even less when we apply ~-10 dBm or 0.1 v pk signals to it. 0.1 v is approximately 35 dB smaller than 6 V. But, let's assume it is still 1 nano amp. This corresponds to a power level of about -100 dBw or -70 dBm peak power. This is approximately 60 dB below the signal being applied to the circuit we are testing. This still seems like a very low power in the diode for creating mixing products. I don't think any mixing products can be larger than this amplitude, in fact, I think they have to be smaller.

Perhaps I did not ask my question above regarding assumptions clearly. I am not an expert on how VNA calibration works. I hope you are. If there is variation in stray capacitance on the VNA input of a fraction of a pF for any reason (manufacturing tolerances, component variations, etc.), will the OSLT calibration we commonly use with devices such as nanovna compensate for it in our measurements after calibration? Is some other action required on my part? I thought this is one of the very purposes of OSLT calibration in all VNAs.

--
Bryan, WA5VAH

0.0.10a is Rune's pre-release at . This is the location for his latest commits prior to final release as executable.

hwalker,

Where do you find NanoVNA Saver 0.0.10a.exe ? I went here: and see 0.0.10 but not 0.0.10a. Would love to have the whole screen fit in my 1366X768 screen.

Rune,

Thank you so much for fitting the whole screen into a 1366x768 screen. That will really make the NanoVNA Saver software so much easier to use.

Thanks,
Steve_WB8GRS

Maurizio,
Rune's latest commit 0.0.0a adds an averaging option. Check it out and let him know what you think.

Hi , I found some info about the smoothing and average on Keysight network analyzer at this link :



Best regards
Maurizio

Hello tinhead,
Thank you very much about the hint with the terminal, to ask about the nanoVNA version.
I did not know that.

As you can see in the attached screenshot, the "version" command answer is *empty*.

I am using Erik's nanoVNA version with "scan" command and upper frequency of 1500 MHz.
It would be nice to read that out, because, at least for me, after a few weeks you (me) no longer remembers
which version was flashed.

It should be not too difficult for Erik to edit file ui.c in function show_version(void) (line 387)
the VERSION text e.g. "0.1.1 + scan 1500MHz".

73, Rudi DL5FA

Thanks Larry

I will pull it apart and have a look. regardless if the replacement switch is sent I will replace the switch with SMT switches as in your mod.

Andy "thats buying from China" As the saying goes buy the first model for your enemy, the second for your friend and the 3rd for yourself. But you dont even have these options from China since these units I believe are bulk manufactured and are mostly distrubuted by anyone and anything. I dont know why Ebay allows these people to tell lies when stating they in your home country when they clearly shipping from China.

Thanks all

Rune,
I just checked out your Latest commit, 0.0.10a and loving the fact that on my 1366x768 display I can see the whole screen without needing scrollbars. All the charts size very nicely at font size 7, even with show data turned. I think the pop up windows for Files, Calibration, Display setup, and About are nicely thought out. I wish at some point in the future you could add a setting under "Display setup" that would allow the user to add a centered caption at the top of the graphs for documentation purposes. Keep up the great work!

On Sat, Sep 21, 2019 at 09:46 PM, Ken Buscho wrote:

Any special calibration considerations to minimize other signals coming in? If
I don't have a test device hooked up, whatever Ref sees is outside world, can
it be calibrated or filtered out someway?

Use the zero span option.
That way the display only reports your "channel"
I think that would work.

73 de Andy

Rune,
Thanks for all of your work on this. I know from personal experience the effort and dedication that something like this requires. When I bought my NanoVNA, I had no idea that I was "surfing" the early adopters wave. I am a recently retired electrical engineer and the intellectual stimulation has been welcome, especially when dealing with a well designed software application like yours. The "bleeding edge" apps are not always this well thought out. It is quickly getting to the point where the first digit of the version number can be an integer greater than zero.

I do have a suggestion....

I have a 4k UHD monitor and one of the issues that I have is that most apps use fonts that have a single pixel stroke width which can be quite hard to read. I know that you have a font size option, which helps, however, I found that simply going to the Bold version of a font can widen the font stroke width and make big improvements in readability on a UHD monitor without changing the font size. Perhaps, you could put this option on your to do list for a future version.

73
Logan, KE7AZ

Warren,
Thanks for the kudos, I always try to figure out a way to find new uses for existing things, Sadly, these ideas usually pop in when my mind is idling right before bedtime, and then I'm up for another hour or two testing it out. Sleep is overrated, that's why they invented coffee

Thanks for all the comments and suggestions. For current batch of the tests, my reference antenna has been a normal car 2m/440 mag mount car antenna on top of a metal file cabinet with about 2m of coax, so we are out of nearfield for both of the ranges I care about for now. Any special calibration considerations to minimize other signals coming in? If I don't have a test device hooked up, whatever Ref sees is outside world, can it be calibrated or filtered out someway? Seems there should at least be a software way to acknowledge that value as a floor/base value and kick it to the curb.

73,
Ken

Hi Rune,

Attached is the calibration File.

Thanks Again.

Jim K. K8SLC

Hi all,
just for your records, attached is a VNWA plot of the NanoVNA RX input impedance.

73, Norbert, DG1KPN

if nothing there in your firmware (no info in boot logo or no version menu) try simply "version" or "info" via serial terminal. But honstly, who cares? just download the latest version and enjoy latest features, no need to care about someone programmed once in your nanovna

Hello,

Allow us, please, to we report that in order to be adequately
prepared to estimate the uncertainty in NanoVNA
measurements using complex differential error regions
and real differential error intervals, that is to attempt for the
first time scientific measurements using NanoVNA with the
only available method we know and with the currently
available software tools, we need, in addition to a correctly
working version of the interpreted foss [maxima-cas] to run
the /f/l/o/s/s/ [derdei.mc], a foss compiled language to we
be able to independently cross-verify the computation
results, and as a such one we intend to use for now the
[openwatcom][fortran].

Also, allow us, please, to we report that in a correctly working
operating system [wxp64p&sp2] we know that the following
versions of these two languages are respectively the last
ones which are correctly working under the 32-bit emulation
mode of an AMD x86-64 cpu:

[maxima-cas][5.38.1]:


[openwatcom-fortran][1.9]:
ftp://ftp.openwatcom.org/install/open-watcom-f77-win32-1.9.exe

Sincerely,

yin&pez@arg

2

The FFT assumes that you have a perfect fit of the (co)sinus in the sample range.
At higher frequencies the 5kHz start to deviate so the samples may no longer fit perfectly in the fft and you may get spectral bleeding.
This bleeding will vary with the error of the 5kHz signal
Can you apply a window to the input of the fft and see if that clears out the spectral bleeding?

Ok, looked at the source code and it seems that 2mA is used in fundamental mode and 8mA for harmonic (above 300MHz). This should make a big difference in Si5351 output impedance, isn't it? The question is, it's the bridge excitation source and detector impedances matched at least while in fundamental mode?

Carlos

What is the Si5351 drive strength being set? 2mA? Is it being increased at >300MHz harmonic bands? It's output impedance may not be 50ohm, and it could be even changing depending on the band. Also older Si5351 revisions specified 85 instead of 50ohm output impedance at 8mA. AFAIK, this excitation source impedance and detector impedance should be matched in order for the bridge to work correctly.

Receiver port is also badly matched above 600MHz. I don't understand the atenuator arrangement, although looks partly copied from DG8SAQ VNWA. A friend's VNWA3 shows a much better port match than nanoVNA.

BTW, one month ago i characterised the SA612 input impedance up to 900MHz and it's much higher than specified 1.5K||3pF. The circuit model i extracted from each IN_x to ground is:
o----[3.5nH]---------------[2.5K]---------->
L-----[1.2pF]----[50R]--->

Carlos

I've been continuing my investigation into improving the nanovna's
dynamic range above 900MHz, and have some further results to share.

Theory tells us that dynamic range can be improved by increasing the number
of readings that are correlated in the DSP - every doubling should increase
the dynamic range by 3 dB.

At the moment the firmware processes just one "frame" of 48 readings, 1
millisecond's worth at 48KHz sampling rate. It's astonishing that the
nanovna is so accurate with so few samples at frequencies below 300MHz.
It's almost trivial to modify the code to perform the correlation over a
number of frames; indeed there are vestiges of code there to do just that.
However, when I implemented the changes to correlate over 8 frames, which
should have improved the dynamic range by around 9dB, it actually got
worse! This surprise has led me to look further at the raw data.

My earlier investigation and work-around to the usb command instabilities
has been serendipitous in that I discovered a large chunk of memory that's
used only for screen-display. My stability workaround disables updates to
the screen, allowing this memory to be re-used. I've therefore created a
firmware version that dumps 10 consecutive frames worth of raw data via the
usb port. I run a FFT on this data. The FFT's 5KHz bucket tallies exactly
with what the firmware dsp calculates (apart from scaling).

What follows are some results.

*Attachment 1 - 190MHz with a cable connecting the 2 ports (48 samples
only)*
This is a "benchmark" reading showing normal operation. The upper graph is
of the raw data returned from the nanovna. The lower graph charts the
results of an FFT on the raw data what is plotted is logFFT =
10*log10(abs(FFT)). The Peak above noise floor calculation is max(logFFT) -
mean(logFFT). This calculation is a bit crude because the average also
includes the peak value, so understates the dynamic range.

*Attachment 2 - 190MHz with a cable connecting the 2 ports (48*10
samples)*
The same charts are displayed as in attachment 1, but with all 10 frames or
480 samples.
Note that the peak for both ref and sample is improved by ~9dB, and that
the noise floor remains at a similar level. This results tallies with
theory.

*Attachment 3, 4 - 1.23GHz with a cable connecting the 2 ports 48 samples,
and 480 samples*
These attachments are same as the first two, except at 1.23GHz. The
increased number of samples shows approx 8dB improvement (from 23dB to 30
dB for ref, and from 21dB to 30 dB for sample). Again this is about what is
expected. However the FFT shows some strong peaks at 1KHz rate (the frame
rate), hinting at one possible source of noise.

So far this is as expected. The problem arises a different frequency is
chosen:

*Attachment 5, 6 - 1.29GHz with a cable connecting the 2 ports 48
samples, and 480 samples*
The peak improvement here is negligible at only 3 dB and 0 dB. Note also
that the peaks are now very spread.

*Attachment 7, 8 - 1.29GHz, 6KHz offset with a cable connecting the 2
ports 48 samples, and 480 samples*
The same as the previous result, except with a 6KHz offset. The underlying
cause of the frequency spread appears to be unrelated to the offset value.

Different frequencies give a range of results, with the two at 1.23GHz and
1.29GHz appearing to be at two extremes.

I have no explanation for what causes these results, only guesses. However,
if we want to improve the dynamic range we need to get to the root cause -
no amount of averaging is going to help.

Any thoughts appreciated.

Rgds,
Dave




[image: 1_190MHz_48_samples.png]

[image: 2_190MHz_480_samples.png]
[image: 3_1.23GHz_48_samples.png]
[image: 4_1.23GHz_480_samples.png]
[image: 5_1.29GHz_48_samples.png]
[image: 6_1.29GHz_480_samples.png]
[image: 7_1.29GHz_48_samples6KHz.png]
[image: 8_1.29GHz_480_samples6KHz.png]