开云体育

I did notice that there was a couple Allen set screws holding the whip portion to the base coil unit of the antenna. I loosened the screws and was able to pull the whip out a bit further. By doing so, I was able to bring the sweet spot down a couple of MHz. Not a dramatic difference, but some none the less. I'm starting to think the best idea would be to start off with a 2-meter amateur antenna and cut it down until covers the spot I use the most; easier than adding length. True, my antenna seems to work fine now regardless, but I'm just playing with it because I can.
.

On Fri, Sep 13, 2019 at 12:56 AM, <norbert.kohns@...> wrote:

Hi George,
I did some comparison with a 100R in parallel with 100pF and 50R in serial
with 100nH.
Plot 1-3 are the s1p files from the NanoVNA.
What is your opinion?

Best regards
Norbert

Hi Norbert,

Today is a very busy day here but I did find a few minutes to look at your study.

My initial impression is that the NanoVNA is very close to the VNWA in these two cases. For the inductor/resistor combination, the SWR never exceeds 7 so that gives me confidence in the results.But the capacitor/resistor has high SWR, increasing with frequency. So, while the two units agree, I would be a bit wary of the results at the very high SWR.

I'm not sure how you constructed the test objects, Can their values be traced back to some standard? That may be hard to do.

One of the things that would be nice to have is a set of standard test objects to help verify the NanoVNA operation, in addition to the SOL.

Hi Larry -

RFpro, Firmware 10KHz-1500MHz.
/g/nanovna-users/attachment/2391/1/DFU_M_10KHz.rar

ORISTO - with this release of alternate firmware, might you be able to create a new, updated guide as you did for the original F/W?

Funny you should mention;
I just added a DFU switch to my nanoVNA
to facilitate musical firmware evaluations.
Where is source for 10KHz-1500MHz version?

As with much open source activity, chaos accumulates...

Can anyone confirm that the above 900 MHz there is actually RF being output from the CH0 connector... i.e. use a receiver or spectrum analyzer to observe the RF?

YES!! - You da Man, Bryon!

You've added just about everything that was missing from the menu - FANTASTIC!

Thank you very much.

ORISTO - with this release of alternate firmware, might you be able to create a new, updated guide as you did for the original F/W?

73
Larry

RFpro, Firmware 10KHz-1500MHz.
By default, when turned on, 50KHz-900MHz.
Expand the boundaries in the frequency setting menu.
Added dfu menu item, now it is not necessary to close the jumper with tweezers. This assembly is based on source codes EDY555 & Hugen. At one's own risk. Work with other software is not guaranteed.
The display measures the reference capacitance 15nf, Port S11.

Herb, I blush. Thank you very much for your appreciation :-)

--
Rune / 5Q5R

Hi Holger,
For each of the standards, you first need to sweep them in the main window,
then press the corresponding button in the calibration window. This allows
some more control over what area you are doing the calibration for.

(though I should really integrate that better)

If you already did that, then you may have found a bug! Please let me know
if my suggestion doesn't work :-)

--
Rune / 5Q5R

Hello Rune,
thank you for your work. I had trouble with the calibration Routine.
Doing the calibration procedure for open, short, match, isolation and trough and save the results. i can recall them but in the command window i get following message: "Division error - did you use the same measurement for two of short, open and load?".

any idea?

73 Holger, DF6DBF

Rune,
I just took a look see at NanoVNA-Saver 0.0.9 and I'm very impressed with all the improvements you have made in just the course of a month. Your efforts are especially noteworthy since you have not asked for any compensation. You are a credit to the open source community concept.

Herb

It's Friday, and that apparently means NanoVNA-Saver 0.0.9:


This edition has focused a lot on the markers: You can now pick which
marker to control using the mouse by radio buttons; and if you hold shift,
you can drag around the nearest marker on the charts. The markers have
their own data readout panel, which can be hidden, if you want more room to
marvel at the charts. They also now have more data display options,
including Q and parallel equivalent R and C/L. Additionally, when you enter
a marker frequency manually, the markers are updated immediately, without
needing to press enter.

Sweep controls now include a center/span option, and both start/end and
center/span update the other fields as you update them.

Some of the TDR functionality has been moved to a separate window
(selecting cable types), and now also shows a graph of response vs distance.

An icon was added, and in the true tradition of VNA software, it features a
Smith chart. Of course.

Lastly, support for high-resolution monitors was improved.

Feedback, suggestions and bug reports welcome as always!

This list has provided a lot of good suggestions already, and while I know
I'm probably disappointing some of you by not having gotten your changes in
yet, I promise I'm still working on the app, and you should definitely feel
free to send me an email if you want to help out.

We have a Discord server for anyone who's so into this app, they want to
hang out on Discord with us (?). Send me an email if you want the invite.

--
Rune / 5Q5R

On Tue, 10 Sep 2019 at 20:56, Rune Broberg via Groups.Io <mihtjel=
[email protected]> wrote:

The other thread was getting long, and seemed to have branched a lot, so as
a new one:

I just released NanoVNASaver 0.0.8. It now saves settings, and has
continuous from the NanoVNA, both as single spans of 101 points, or across
multiple spans if you want both high resolution and continuous updates.

There's a few other improvements as well - I started work on a quality
factor graph, as someone had requested that.



There's a .exe for Windows, and for other platforms (Mac OS, Linux,
BSD(?)), run it using pip/python, described in the README.

I welcome all feedback, bug reports and suggestions!

--
Rune / 5Q5R

I have an SO-239 to SMA male adapter for my SpyVerter up-converter. Somehow, I broke the SMA pin off in the SpyVerter SMA female connector. While troubleshooting the problem using an SMA male-male adapter, the center pin got pushed through the adapter so it was zero length at one end and double length at the other end. (I hate SMA connectors.)

Hello,

This email message is a notification to let you know that a file has been uploaded to the Files area of the [email protected] group.

File: NanoVNA Jog Switch Modification.pdf

Uploaded By: Larry Rothman

Description:
Remove the jog switch and replace with front panel buttons from scrap electronics

You can access this file at the URL:
/g/nanovna-users/files/Hardware%20Mods/NanoVNA%20Jog%20Switch%20Modification.pdf

Cheers,
The Groups.io Team

Jerry,

I stay away from Chinese connectors because of questionable quality and use Amphenol 132171 M to F adapters.
Here is the mouser listing:

<>

Mike N2MS

No

Hi Ron,

So (you probably know this) if you want to lower the resonant freq of your antenna you need to make it longer.
There may be an inch or so of adjustment if you loosen the set screw at the base of the antenna.

Although I might add that you have swr of 1.5 at 155 which is still quite good. And if you are rx only you likely would not notice any gain or improvement at all.

73
dwight

To Erik, Hugen, ttrf (de facto code "owners")

*The Command Stability Issue:*

Some people have reported some stability issues with the usb command
interface, including the screen going white.

I have also noticed this issue with my own python experiments, and have
been investigating it over the last few days. I've found an easy and
reliable way reproduce the issue: I use putty to repeatedly type the "freq"
command with different frequencies, and monitor the result on the tx port
with a frequency counter. Although the usb interface continues to work, the
frequency stops changing after 4-8 "freq" commands. The screen will also
randomly go white, but much less frequently.

Once the nanovna gets into this state it needs to be powered off and on
again to restore normal operation; the usb reset command isn't sufficient.
I've reproduced this issue with Hugen's Aug 2nd firmware, and with a build
today based on Erik's firmware (here:
).

*The Temporary Workaround:*

In investigating this issue I have found that the problem is somehow
related to the UI thread calling draw_all_cells() in parallel to the usb
command thread running. Stability is improved by restricting when this
function is called. See the code snippet (just 4 lines are moved)(
)

This is a temporary fix until we find what the underlying cause of this
interaction is.

As described below, Hugen's firmware also needs stack size changes to
improve stability.

*Stack Size Issues*

The symptoms we see are typically associated with a thread's stack
overflowing the allocated area and trampling on adjacent memory. Indeed the
command thread makes function calls at least 12 deep to process the "freq"
command, and together with the parameters passed and local variables in
each function, consumes a lot of stack!

However I've eliminated this as a cause (at least for Erik's version). I
did so by following the chibiOS guide re. stack sizes (here:
). The default
nanovna build already set sets the mentioned build variables
CH_DBG_ENABLE_STACK_CHECK and CH_DBG_FILL_THREADS. I implemented a simple
memory dump command to let me do this testing (code also in the gist linked
above).

My conclusion is that Erik's firmware version has just 4 bytes spare stack
space. This could easily be accidentally "blown" by a future simple
software change (adding a parameter or another local variable). I therefore
recommend increasing the usb thread's stack size by 64 bytes, (and reducing
the UI stack size by the same amount, since it's stack is larger than
needed and there's no other memory left). The two lines to change are also
in the gist above.

I also believe Hugen's version has the usb thread far too small - the
"freq" command will definitely overwrite the UI's stack and cause
instability - this needs fixing.

We already have a proliferation of firmware versions, so I won't add to the
problem by adding my own. Instead I suggest the existing owners investigate
and take these changes forward as they see fit.

Rgds,
Dave

I'm new to the group. Do I have to use special firmware in the nanaVNA to use the TAPR application?

Mike N2MS

On Fri, 13 Sep 2019 at 04:47, Gedas <w8bya@...> wrote:

One other point is that most coaxial cables have a fairly constant
characteristic impedance above around 5X the shield cut-off frequency which
is around 1000 to 2000 Hz. So above around 5 kHz - 10 kHz most coaxial
lines show a fairly constant Zo.

Do you have any references to this? It is certainly not the effect I meant.
I am talking about something quite different.

I will have a play later today with my 4284A LCR meter (20 Hz to 1 MHz) and
a length of coax. The meter uses 4-wire sensing and I also have a Simpson
microohm meter with some ridiculously low resolution.

The problem is, although the basic accuracy of the LCR meter is 0.05%, in
just about any set of circumstances, that increases - often dramatically.

I guess what you may be asking really are what the possible differences may

be between a very short O, S or L vs. an actual physical length of coaxial
cable low frequencies below 5 kHz to 10 kHz. An OSL at very low frequencies
maybe would not be best to be modeled as a coaxial line but just a discrete
lumped element.

Yes, I believe that’s so.

Any attempt to measure at such frequencies with a VNA calibrated with the
standard short, open load, will lead to erroneous results, as the
calibration standards will have been improperly defined.

Gedas, W8BYA

This is an interesting topic.

Dave G8WRB.
--
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

problem solved by David F4HTQ



a better software than the ones proposed by sellers

Tks David

73's John F5VLB

--
Jean-Marie Polard
F5VLB