开云体育

On 8/18/23 8:15 AM, Brian Beezley wrote:

On Tue, Aug 15, 2023 at 09:25 PM, Jim Lux wrote:

Sometimes, I find the derivative of unwrapped phase (group delay) more useful,
too.

Jim, your comment inspired me to add group delay to my program. I don't see its relevance for ground probe data, but it provides a powerful diagnostic tool that can reveal anomalies otherwise invisible. The first two plots show an ordinary-looking phase plot and the corresponding group delay plot. The big group delay spike corresponds to a barely perceptible flat spot in the phase curve. It's easier to see in the third plot with a narrower frequency span. I think it's due to a VNA frequency stepping issue.

Yeah, derivatives do accentuate noise - but sometimes that's actually useful to spot a discontinuity in a system that should otherwise be "smooth" And when you have multiple resonances, is makes them obvious.

Make sure you are taking frequency steps that are small wrt to the DUT bandwidth. GD on a xtal filter is one example.

. . . and far, far, less portable (IE not an option for all, unlike Cube) . . .

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On Tue, Aug 15, 2023 at 09:25 PM, Jim Lux wrote:

Sometimes, I find the derivative of unwrapped phase (group delay) more useful,
too.

Jim, your comment inspired me to add group delay to my program. I don't see its relevance for ground probe data, but it provides a powerful diagnostic tool that can reveal anomalies otherwise invisible. The first two plots show an ordinary-looking phase plot and the corresponding group delay plot. The big group delay spike corresponds to a barely perceptible flat spot in the phase curve. It's easier to see in the third plot with a narrower frequency span. I think it's due to a VNA frequency stepping issue.

Brian

The STM32CubeProgrammer is good, I like it but, the app is more problem free...

did You saw this topics?


/g/nanovna-users/topic/100723284

/g/nanovna-users/topic/99570191

/g/nanovna-users/topic/100725961

Istvaan

While that is technically true, its only possible if you either made a backup of the firmware on the unit prior to flashing the new firmware or were able to find the firmware originally on the unit.

These things can't be bricked, in the worst case scenario you would
need a $2 ST Link clone to
flash the firmware.

Me as well.
I have 2 desktops
Both running windows 11
One is a custom built amd gaming system and the driver did not work.
The other is a customer built intel system functioning as a file server.
Drivers worked just fine.
both were done with the same downloads and exact same process was followed.
Same windows 11 build as well.

I've just been down this road, encountering many problems. My environment is MacOS Ventura 13.5 on a Macbook Air M1. I also run Windows 11 in a virtual machine with VMware Fusion. I could never get the drivers installed on Windows 11 for the VanoVNA software. In my case, there were too many variables: Windows 11, W11 running in a VM, and USB support with a thunderbolt dock. I finally am using STM32CubeProgrammer (which runs on windows, linux, and MacOS). I extracted my existing VanoVNA-H FW from the device. I couldn't reconcile the extracted FW's size, so I looked for another means of extraction, dbutil. It also runs on windows, linux, and MacOS. I installed on MacOS (easy install with homebrew). I then extracted my VanoVNA-H FW from device for safe keeping. I happen to have a spare VanoVNA-H, I have to return by early Sept. This turned out to be a good test device, although I have read in many threads that the NanoVNA-H is nearly impossible to permanently brick. I have flashed several different FWs and then returned to original. If you can get past the driver issue on windows, the rest is a breeze. I would still recommend STM32CubeProgrammer.

Peter

Hi,
Follow this guide:

If your not sure if your Nanovna is an official one or not, do not upgrade or risk bricking your unit.


Tim.
KD2YYI

Hello
Can someone please point me in the direction of instructions of how I can update the firmware of my nano VNA. The firmware is currently 1.0.45. I am new to the group and have searched the topic and there are many answers but no specific step by step instructions I can see. Can someone please point me in the right direction.
Thanks

Makes sense. I setup LTSpice for 0 dBm out of CH0 with 50 Ohm load. Then inserted 1k Ohm and got 20.7 dBm at CH1. Thanks for the explanation.

When you put a 1000 ohm resistor between CH0 (port1) and CH1 (port 2) of the NanoVNA you should measure an "Insertion Loss" of -20.8 dB if the NanoVNA was a perfect device. It is not for several reasons including impedance of CH0 and CH1 are not exactly 50 ohms and the way calibration is done. So your measurement of 20 db is pretty close.

Your LTSpice and Sig Gen experiment is off by 6 dB because you did not calculate correctly. Try calculating the power in dBm of the 50 ohm load resistor without the 1K resistor and with the 1K resistor. Subtract the two and you get a 20.8 dB difference.

Roger

Why for the same circuit is the NanoVNA (-20 dB), LTSpice (-27 dB), and Scope/Sig Gen (-27 dB) result in different answers. The circuit is a 1,000 Ohm resistor tied from CH0 to CH1. Based on some experiments the input impedance to CH1 is 50 Ohms so the circuit is a voltage divider (see attached Fig. 1 NanoVNA Circuit Setup).

The scope and signal generator were setup to mimic the NanoVNA circuit by using the signal generator to apply potential to a series 1,000 Ohm and 50 Ohm resistor network (see attached Fig. 2 Scope/ Signal Generator Circut Setup). The scope was used to measure the voltage of the applied signal (Vin) and the output across the 50 Ohm resistor (Vout).

The results:
NanoVNA LogMAg = -20 dB @ 1 MHz, Smith 982 Ohms @ 1 MHz,
Scope/Sig Gen @ 1MHz, Vin = 722 mVrms, Vout = 34 mVrms, -27 dB,
LTSpice @ 1MHz, Vin = 452 mVrms, Vout = 21 mVrms, -27 dB.

The Scope/Sig Gen and LTSpice are a good correlation. The NanoVNA is different, why?

Any thoughts?

Wes
W4JYK

On Wed, Aug 16, 2023 at 07:26 PM, Peter (WB3IZU) wrote:

The extracted file is 130K and most of the FWs I see online are under 100K.
That concerns me?

That is OK, because the upload to the PC reads the complete 128KByte from the flash including the unused bytes after the program at the memory end while the FW files of about 100K contain only the program bytes.

I have made some progress. I wanted to be able to extract the FW from my device for backup. I can't seem to find FW that matches mine online. This () seems to be the closest. However, if I download the DFU, convert it to BIN and compare using STM32CubeProgrammer, they do not match. I extracted the firmware using "dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -U /Users/USERID/DELETE/test.bin". The log is attached. The extracted file is 130K and most of the FWs I see online are under 100K. That concerns me? If I compare using STM32CubeProgrammer, they do match. I then flashed this back to my NanoVNA using STM32CubeProgrammer. The log is attached. If I compare the versions from the VanoVNA (config | version) pre and post, they are identical. I guess next I will flash an updated FW, maybe the one that removes SDcard support and allows for 8 saved calibrations. My only concern at this point is the discrepancy in file sizes. If anyone can explain, I would appreciate it?

73
Peter

On Tuesday 15 August 2023 06:56:54 pm W0LEV wrote:

I would strongly recommend buying from R&L Electronics. You won't get a
clone from them!! Here is the link to them for the NANOVNA-H4:




No connection to them other than having bought a number of NANOVNAs (too
many as they progressed) and TinySAs from them.

Dave - W?LEV

Seconded. I bought mine there, along with two sets of adapters. No complaints...

WD3WTF

--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin

On 8/16/23 8:18 AM, Jim Lux wrote:

On 8/15/23 11:57 PM, Leif M wrote:

After some use I noticed a couple things which could be better in NanoVNASaver.win.x64 software.

First, I posted this also to /g/NanoVNAV2 but after a couple of days it has not appeared there.

First the version text can't be copied to the clipboard. That would make it easier to talk about certain version. I think? mine is quite up to date.

Yeah, I do it by a screen cap of the window (attached, MacOS-X).

with the version screen cap

On 8/15/23 11:57 PM, Leif M wrote:

After some use I noticed a couple things which could be better in NanoVNASaver.win.x64 software.
First, I posted this also to /g/NanoVNAV2 but after a couple of days it has not appeared there.
First the version text can't be copied to the clipboard. That would make it easier to talk about certain version. I think mine is quite up to date.

Yeah, I do it by a screen cap of the window (attached, MacOS-X).

Calibration file should include also the frequency settings. If I have loaded a calibration file with 1MHz to 30MHz, the default frequency values (200MHz and 300MHz) do not make sense. The calibration file should include also averaging and segment values.

The calibration files do have the frequency range:
# Calibration data for NanoVNA-Saver
! SOL Calibration
! 27-30Mhz 101 Points
# Hz ShortR ShortI OpenR OpenI LoadR LoadI ThroughR ThroughI IsolationR IsolationI
27000000 0.948987136 -0.423713696 -0.862881088 0.584374208 -0.584138048 0.409614848
27030000 0.95050944 -0.421384544 -0.86482624 0.58150208 -0.58608 0.407054528
27060000 0.952427776 -0.419021984 -0.866214592 0.578889728 -0.587020096 0.405044192

It doesn't have the averaging or segment values, true.

I don't think the segmentation is captured - the cal file is basically the entire frequency span.. Take a look at a >1000 pt cal file attached.

Setting wrong values or data on the frequency range settings easily crashes the whole program.
Frequency axis of the plots is not good. Probably difficult to get it well, probably the user should do it..
Marker data should show on the text below the image. That would help with bad frequency axis too.
I attached plot of my balun, You can see the frequency axis. The marker value should be somewhere, like text below the image.

My original post (way back) was about how I used my Nano VNA to help make my 140 ft closed loop tune up better on 40m.
It was a simple post about the instrument, the Nano VNA.

I did not intend that post to then become a series of responses about antenna design.

Someone asked about my “vertical” on 40m and 80m.
It was a military surplus alum tubing (very light) that was tapered.
It came in two ft sections that closely fit.
So I put up about 35 ft of alum tubing and just lashed it to a taller fir tree.

I then ran two horizontal counterpoise wires, about 35 ft each, about 10 feet above ground.
So I only had two “radials”.
It was (is) so simple, but it is not ground mounted. Then I’d have to deal with multiple radials on the ground.

When I listen at night to DX stations, this vertical beats my dipole and loop by a few S units.
But it is pretty awful for a short skip (300 mile) daytime contact.

So it shows a simple low-angle propagation path, good for DX, but lousy for NVIS.

Now, getting back tothe Nano VNA.
How did I use the NANO VNA to tune my 140 ft loop? Look at the graphs.
I used it to first check the resonant (zero reactance) frequencies.
I used it to look at the PHASE graph.
I used it to double check the Smith Chart.
The SWR was as predicted, lowest at the low end of the 40 m band.

I really did not “need” the NANO VNA instrument to make my horizontal 140 ft loop work!
but it was reassuring that the graphs did not show me something unexpected.

de k3eui barry