¿ªÔÆÌåÓý

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

Re: NanoVNA V2

London Calling
 

On Tue, Sep 24, 2019 at 11:35 PM, Dave Daniel wrote:

A second violation gets you put under moderation. A third violation gets you
removed from the list.
Others here agree with Michael.
That includes myself, others who have posted on this forum as well as personal feedback that I have personally received.

The ridiculous self aggrandizement takes the piss, and is not suited to a hobbyist group.
You wanna put Michael on a watch list, or ban him, then please add me to your list.

73 de Andy


Re: List of NanoVNA Console Commands

 

Folks,
I have just uploaded an updated Console Command document to the Files section.
It now references Erik's last build 0.1.1 with TDR and battery.

However, there are a few items that I am not sure of at this point:
Markers: outputs: marker#, index#, frequency. What is the 'index' number referencing? It changes as I move the marker along the trace.
Capture: this is a new command. What does it do? If you run it in the console, the Nano locks-up.
Sample: samples gamma, ampl or ref - how is it used?
Time: is still there and increments the counter - but how can it be set to current time?
DAC: does the dac variable control the DSP gain?
Test: is still there but what does it do?

As always, a Thank You to all that have helped with this document previously!

Regards,
Larry


Re: R + jX ?

Lapo Pieri
 

08:06 Wed 25 Sep 19 , Steve London wrote:
I will apologize if this has already been covered. I didn't find it in a search.

I see that, by default, NanoVNA reports R + L/C . Is there a way to change that to R +- X ?

Yes, I know the PC software can display it both ways, but my primary use for the NanoVNA is up on the tower, to make measurements at the feedpoint. The NanoVNA is a lot more convenient than carrying up a bulky and expensive antenna analyzer.
I faced the same problem and I've modified a bit smith chart presentation
to show R+jX. I think my patch will not apply to current fw but if you want to
try to adapt it to newr fw I'll attach below.

When I'll find a bit of time I'll try to integrate in actual fw.

Lapo, IK5NAX

diff --git a/plot.c b/plot.c
index 10074c3..c5c92e5 100644
--- a/plot.c
+++ b/plot.c
@@ -576,16 +576,22 @@ gamma2imp(char *buf, int len, const float coeff[2], uint32_t frequency)
// float z = sqrtf(zr*zr + zi*zi);
int n;

- n = string_value_with_prefix(buf, len, zr, S_OHM[0]);
- buf[n++] = ' ';
+ n = string_value_with_prefix(buf, len, zr, '\0');
+ if(zi<0)
+ buf[n++]='-';
+ else
+ buf[n++]='+';
+ buf[n++]='j';
+ string_value_with_prefix(buf+n, len-n, fabs(zi), S_OHM[0]);

- if (zi < 0) {
- float c = -1 / (PI2 * frequency * zi);
- string_value_with_prefix(buf+n, len-n, c, 'F');
- } else {
- float l = zi / (PI2 * frequency);
- string_value_with_prefix(buf+n, len-n, l, 'H');
- }
+
+ /* if (zi < 0) { */
+ /* float c = -1 / (PI2 * frequency * zi); */
+ /* string_value_with_prefix(buf+n, len-n, c, 'F'); */
+ /* } else { */
+ /* float l = zi / (PI2 * frequency); */
+ /* string_value_with_prefix(buf+n, len-n, l, 'H'); */
+ /* } */
}

void


Re: on the comparisons

 

Hello,

Allow us, please, to inform the interested reader and/or contributor that in order to we
stay on- and continue on this subject, we had to copy our messages from this topic
to that one:

[errors of "error" models]:
/g/nanovna-users/message/3004

as well as that we shall also copy -"just in case"- sometime later, all of our messages
to out there:



Thank you for your attention.

Farewell !

Sincerely,

yin&pez@arg

9


Re: Saver with Win7

 

With totally different software (National Fire Information Reporting System),
installing on Windows 7 you need to ignore the default install location and go direct to the C: drive.
With the default location you're in permissions hell.

I don't know if this is relevant but it might be.

Bear W5VZB


Re: Trying to understand the T-Check outcome of the nanoVNA

Dr. David Kirkby from Kirkby Microwave Ltd
 

On Wed, 25 Sep 2019 at 18:47, Dr. David Kirkby <
drkirkby@...> wrote:

On Wed, 25 Sep 2019 at 15:53, <erik@...> wrote:

Using a not too good BNC Tee I performed a T-Check
The T-check theory assumes that the T is lossless.

--
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: Trying to understand the T-Check outcome of the nanoVNA

Dr. David Kirkby from Kirkby Microwave Ltd
 

On Wed, 25 Sep 2019 at 15:53, <erik@...> wrote:

Using a not too good BNC Tee I performed a T-Check
Attached the measurement (.s2p) and the excel file (.xlsx) in which the
T-Check is calculated.
Next to the T-Check calculation the excel also calculates the
abs(Zin-Zout)/Z0 (the percentage absolute distance of the two impedances as
another estimate of error)
The frequency is denoted in MHz
Do ignore anything above say 500MHz

The T-Check suggests the error quickly increases to substantial levels but
the abs(Zin-Zout)/Z0 suggests there is a very systematic error in my
measurement where the absolute distance of the two rotating impedances
grows very linear with frequency.

What do you connect on the the third port of the T? Most people connect 50
ohm loads, but personally I am skeptical of the logic of that, as it means
both ports see a constant 25 ohms.

BNC calibration kits are as rare as rocking horse dung, so I doubt that the
calibration kit is working correctly.


What am I doing wrong?

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


Calibration bug in newer firmwares?

 

Could someone repeat my tests? I have described the issue here:


Carlos


Experimental 256 point FFT Firmware

 
Edited

XENOMORPH, who I believe first introduced the 1500 MHz, tdr, and battery icon firmware mod, has just released a firmware mod that adds additional 256 point FFT capabilities versus the current 128 point FFT. He posted a photo showing the new firmware being used to perform a tdr measurement on a 65 meter length of RG-6U (0.89) see attachment. The measurement was accurate to 0.07 meters. I have also attached his DFU file in-case someone wants to play with it. I am going to order another nanoVNA to experiment with all the new firmware mods that have started to appear. My current firmware works so well that I hesitate to muck with it.


Re: R + jX ?

 

Yeah, I thought that would do it as well, BUT it gives reflection coefficient.

Alan


Re: R + jX ?

 

Hi Steve,

Others have asked for this as well. And I think as far as I know, the short answer is NO.

Unless there is a plan to update the firmware to do that calculation and provide a touch key to bring up that format.

May I ask... when up on the tower, so you know in advance what range of X your supposed to see. Pre- calculate the expected value and go with that? Not the ideal answer, but that's sort of what I have done with my simple wire antenna.

Alan


Re: R + jX ?

 

Did you try polar output?


Re: NanoVNA Saver

 

Bruce
Have a look here
Cheers
Al

On Wed, 25 Sep 2019 at 12:17, Bruce KX4AZ <bruce@...> wrote:

Rune,

Wanted to add my thanks for all the work you have done with the software,
and I really appreciate the features added to the latest version.

I've never been able to do a calibration within the software, no doubt I
am doing something wrong with the key sequence. Calibration works fine
with the touch screen, so not really an issue...but I do wonder if someone
has ever written a calibration "tutorial" about how it is done in the
NanoVNA Saver software.

73,
Bruce




R + jX ?

 

I will apologize if this has already been covered. I didn't find it in a search.

I see that, by default, NanoVNA reports R + L/C . Is there a way to change that to R +- X ?

Yes, I know the PC software can display it both ways, but my primary use for the NanoVNA is up on the tower, to make measurements at the feedpoint. The NanoVNA is a lot more convenient than carrying up a bulky and expensive antenna analyzer.

Thanks,
Steve, N2IC


Re: Firmware font size - 2 versus 4 trace

 

I have seen a technique where the font is "enlarged" simply by outputting each scan of the character font twice. This makes the character appear taller. It can make the text surprisingly more legible with no more font RAM and just a small hit on the code space. Of course you still will need screen space. Because the characters, while more legible, are a bit ill formed, this might be available as an selectable "ZOOM" mode unneeded by those who purchase the reading glass option.


Re: Firmware font size - 2 versus 4 trace

 

There are two flash parts, one 96k and one 32k
Assuming the 32k flash holds the data store (did not analyze yet), the 96kByte flash has maybe 1kByte left. (code + initialized data is in total 97440 Bytes)
But I am not very familiar with the memory layout


Trying to understand the T-Check outcome of the nanoVNA

 

Using a not too good BNC Tee I performed a T-Check
Attached the measurement (.s2p) and the excel file (.xlsx) in which the T-Check is calculated.
Next to the T-Check calculation the excel also calculates the abs(Zin-Zout)/Z0 (the percentage absolute distance of the two impedances as another estimate of error)
The frequency is denoted in MHz
Do ignore anything above say 500MHz

The T-Check suggests the error quickly increases to substantial levels but the abs(Zin-Zout)/Z0 suggests there is a very systematic error in my measurement where the absolute distance of the two rotating impedances grows very linear with frequency.

I did calibrate using the Tee without (OSL) and with (T) the outgoing cable connected but maybe that did result into the error.

What am I doing wrong?


Re: Firmware font size - 2 versus 4 trace

 

On Wed, Sep 25, 2019 at 09:26 AM, <erik@...> wrote:


Indeed, larger fonts need more memory. Prefer to spend memory on more useful
features.
Erik,
Thanks for confirming memory capacity is a factor in the font sizes. My progressive bifocals work fine with the smaller fonts, but I imagine it's just a matter of time before someone releases a new firmware "flavor" with two traces & 1500 MHz extended range.

With the newest firmware versions, can you give us any sense of how close we are the memory capacity "ceiling"?
Thanks,
Bruce


Re: Saver with Win7

 

Thanks Alan! See, I didn't even figure out it was an S21 measurement :D

--
Rune / 5Q5R

On Wed, 25 Sep 2019 at 16:37, alan victor <avictor73@...> wrote:

Hi Rune,

The group delay (GD) is obtained from the transmission phase, S21. The
negated value of phase shift calculated as the small change in phase shift
occurring with a small change in frequency. The difference in phase with
difference in frequency (the aperture) taken small enough to arrive at an
accurate value for GD.

The site below is a good reference and provides a useful calculator so you
can test your routine:



Regards,

Alan




Re: Saver with Win7

 

Hi Rune,

The group delay (GD) is obtained from the transmission phase, S21. The negated value of phase shift calculated as the small change in phase shift occurring with a small change in frequency. The difference in phase with difference in frequency (the aperture) taken small enough to arrive at an accurate value for GD.

The site below is a good reference and provides a useful calculator so you can test your routine:



Regards,

Alan