开云体育

I replied to your other topic by mistake! The link is there.

--
Mike

Hi Phil, you can download NanoVNA-app from here:



It's pre-compiled for Windows.

--
Mike

Hi guys, Thank-you for your emails! This is extremely embarrassing... where can I downlaod this sftwr, like ready-to-go, i.e., already compiled? Do I need C++ to conmpile? 73Phil, WF3W

On Mon, Jun 21, 2021 at 10:13 AM, Gordie 2M0IRR wrote:

So RIP to my little VNA.? I have now ordered another from Amazon and as
soon as it comes, I will remove the battery to stop the same issue
occurring in the future.

I'm a bit late to this topic and was going to recommend Mirfield Electronics for your replacement, as they sell good quality NanoVNAs.

Anyway, I hope your Amazon one is OK.

As for storing equipment with LiIon batteries, they don't like to be discharged for long so charge them up before you put them away. I have a DS Nano scope which I only use once or twice a year but it never fails to start up.

--
Mike

Hmmm, I have just received a spam mail purporting to coming from this group, indeed copying previous text from it too

Has anyone else received such an email?

Plus 1 on the NanoVNA-App

Muggs KC3UDZ

My Windows 11 laptop installs updates every Tuesday so that could be a factor in your problem.

Try NanoVNA-App instead. IMHO it's a much better and more stable piece of software.
--
Mike G8GYW

On Tue, Dec 13, 2022 at 05:27 AM, buck (eizner23) wrote:

I am using 2.8" SeeSii
NanoVNA. I am pointed here for updates
but I am conflicted with different
information found on the web.

This is the wrong location for firmware updates. Download the latest -H SI dfu version from this site.


Roger

OK, there are a few possibilities here. Based on what you wrote, I think
the two most likely are:
1 - Your computer updated overnight (windows does this from time to time),
and something became incompatible. But ver. 0.5.3 is very recent, so that
shouldn't be an issue.
2 - Your nanovna had a failure. Please share with us which specific
NanoNVA you have. I am worried when you say it shows a pastel blue screen
when you plug it into the USB port - the nanovna's I am acquainted with
should not do that - the nano screen stays with a normal operational
display when plugged in.

Hi VNA-savers,

Im in the process of trying to save my sanity and, if I appear to be a tad pissed, I beg your forgiveness.

Yesterday, I had zero problems, with NANOVNA-Saver. Worked perfectly. The program even found a port I had never seen before - hidden or otherwise - Com Port 8.

Just now, the sftwr wont even recognize the VNA, yet when I unplug the USB connector, Device Mgr notices the hardware change.

I have tried combinations & permutations of opening & closing the sftwr, disconnecting and reconnecting the USB cable, with zero luck and I aint joyed.

DM lists Ports 3, 4, 5, 6 & 7 but no Port 8, hidden and in plain sight, for all the world to see. The VNA screen goes to a beautiful, pastel blue, when connected via USB cable, without a connection.

I have the USB cable, from the VNA directly into the motherboard.

I have version 0.5.3 and was notified, today, there is an update. I can find no ver 0.5.4, which must remain another issue. The program also loves to close, with unknown keystrokes, to me. Please note: not crash, just close.

73
Phil, WF3W

Disregard, i found the Beginners guide v1.6 pdf and it answered my questions.

"(A very small amount of reading on your part could reduce the amount of time that others take to voluntarily help you.)"

..on the other hand, repeatedly mentioning this fact could reduce the volunteered time for assistance could set the time spent helping to zero as a limit.

Patience and gratitude and good manners go a long way on most of of these groups.
--
William, k6whp
--------------------
"Cheer up, things could get worse. So I cheered up and things got worse."

Hitting the sweep button gets me an error "Failed reading data 0 10 times". My firmware NanoVNA-H v1.1.0 maybe is out of date. I am using 2.8" SeeSii NanoVNA. I am pointed here for updates
but I am conflicted with different information found on the web.
I find some examples of using DfuSe_Demo_V3.0.6_Setup.exe but cannot locate the .DFU file necessary.
Then I read there is perhaps an easier way to flash firmware. Maybe I am barking up the wrong tree.

I would appreciate a hand updating my NanoVNA. Kind regards.

Sounds plausible to me. I have done it hundreds of times, tuning my
2m/70cm antennas before shipping. Every time I run the 420-450 scan, I
have to reboot the VNA to get accurate readings on the next scan in the
test set. Upgraded the firmware and upgraded saver, I have three versions
of saver, including the latest, and they all suffer from it when running
NanoVNA Saver. Also, does not matter what firmware I am running, be it
from Dislord, BN5HNU, or edy555. However, I do not see the problem when
running Nanovna Software based on edy555's version. But it is not pretty,
nor does it show the data in quite the same way.
Jim Barber
*N7FZ*
Phone: 503.547.9524
<>

I think those who have been around longer, find the better sites for documentation. When they are posted, GREAT!

A side issue to this quality/source, can be the QUANtity/source.

I.E., I used to suggest 2 books for any given computer topic. One ought to be through, maybe even a reference. But the other, while far more than a Quick Start Guide, shod be far far simpler, not much more than an overview.

And ideally, they should be from different authors and publishers. This way, you don't get an abridged version or expanded version, in the same words and from the same point of view, but you get an, "IOW," viewpoint and vernacular.

I've no idea if such a thing is remotely possible w VNA's, and then, there are so many versions now.

If so, the instructions and/or a link to them, per version, would make a good set of list-files. I do download instructions. (So many are not well written.) They can be handy and may be searchable... but I really dislike lack of a printed set, and will print them out myself, sometimes. YMMV...

BillSF9c

On 12/12/22 1:53 PM, Jim Barber wrote:

Good afternoon,
I have had the same experience. I have t to calibrate and save the
calibration for the exact width I am looking for to one of the memories.
Then, after scanning with one of the calibrations, save those results.
Then, disconnect the saver, reboot, and manually load the other
calibration. Reconnect. For some reason, the back-to-back scan results get
wonky without a reboot on the higher frequencies. I never have this problem
below ~200mhz.

I wonder if it's the result of an inconsistency in how the multiple sweep ranges interact with the discontinuity when stepping across the harmonic boundary. Both NanoVNA and NanoVNA-Saver do linear interpolation of the calibration coefficients. If the "threshold" is 300 MHz, and you have a sweep that spans 300 MHz (e.g. from 290-310) there might be some wonkiness.

Good afternoon,

I have had the same experience. I have t to calibrate and save the
calibration for the exact width I am looking for to one of the memories.
Then, after scanning with one of the calibrations, save those results.
Then, disconnect the saver, reboot, and manually load the other
calibration. Reconnect. For some reason, the back-to-back scan results get
wonky without a reboot on the higher frequencies. I never have this problem
below ~200mhz.

Jim Barber
*N7FZ*
Phone: 503.547.9524
<>

On 12/12/22 7:34 AM, Tim Dawson wrote:

5v power should *always* be available on a USB port,

Not necessarily - there are USB hubs that if they get a request for high power, and can't supply it, just shut down the power and disable that port, other than some microamps to tell if there's a unplug/plug event.


so slow charging can

happen even on a dead device. What is negotiated are faster charge rates,
so, as you noted, a dead device will need to slow charge to the point that
it can power up before it can take a fast(er) rate of charge.
(FWIW, I have never charged my NanoVNA H4 on anything *but* my laptop USB
port (no external hub - just plugged it in. Seems to work fine.)
- Tim
On Mon, December 12, 2022 9:13 am, Anne Ranch wrote:

I was going to quit this thread, but...
I left the nanoVNA running overnight , connected to my PC and I did
"shutdown" and turned the PC power source off.
Turned off the D_link power source too.

In the morning I got no LCD and no LED's.
Turned all AC power on (PC , D-Link) and run "lsusb".
Still no LCD and LED's and no nanoVNA USB device.

Unplugged nanoVNA from USB port.
Unplugged "wallwart " from AC !!!
Plugged nanoVNA to dead wallwart and - LCD came on, so did both LEDs -
BUT briefly

Plugged wallwart to AC and have normally operating nanoVNA
LCD on, charging LED on , sweep LED flashing,,,

My conclusion / opinion

in my interpretation of USB "standard operation"

...when a USB device is first plugged into its controller
it runs kind of "here I am " sequence and the controller should
acknowledge that and respond ...

How does supposedly dead nanoVNA manages to do this when plugged in DEAD
power source ?

On 12/12/22 7:13 AM, Anne Ranch wrote:

I was going to quit this thread, but...
I left the nanoVNA running overnight , connected to my PC and I did "shutdown" and turned the PC power source off.
Turned off the D_link power source too.
In the morning I got no LCD and no LED's.
Turned all AC power on (PC , D-Link) and run "lsusb".
Still no LCD and LED's and no nanoVNA USB device.
Unplugged nanoVNA from USB port.
Unplugged "wallwart " from AC !!!
Plugged nanoVNA to dead wallwart and - LCD came on, so did both LEDs - BUT briefly
Plugged wallwart to AC and have normally operating nanoVNA
LCD on, charging LED on , sweep LED flashing,,,
My conclusion / opinion
in my interpretation of USB "standard operation"
...when a USB device is first plugged into its controller
it runs kind of "here I am " sequence and the controller should acknowledge that and respond ...
How does supposedly dead nanoVNA manages to do this when plugged in DEAD power source ?

Dead might not be really dead. For instance, your device might have dropped below minimum battery voltage threshold, so it shuts down. But upon detecting a change in state of an external interface (e.g. the USB), it might wake up, just enough to probe the interface.

Most USB hubs will pass *some* current downstream, even if their wall wart is plugged into the device, but not the wall. That is, they alter their behavior depending on if external power is supplied.

I have a 4 port hub that will support high current downstream either if it's connected to a wallwart, OR, it's connected to a high current upstream USB. BUT, if the upstream device changes its mind, the downstream device doesn't always figure that out.


And the whole chain/tree can be partially or fully renegotiated. So it's not just "first plug in sets the behavior".

The overall behavior is really complex, partly because you can be compliant with the USB spec, and not do full negotiation. That is, there's allowance for implementations that don't do all the functionality, but part of it, but in a safe way.

And, of course, there are "almost compliant" devices out there too.

I spent months debugging a battery powered system that used USB for custom modules we built, driven by an upstream PC and a Dlink 7 port hub.

If you're on Windows:




From another document


In some cases, Windows will “forget” that the port exists (as documented in a Microsoft Knowledge Base article 817900) , probably due to the device disappearing and reappearing as the microcontroller changes modes. This can confuse the power management logic implemented in Windows. The problem is also known as the “USB root hub power management issue”. The fix is to disable the selective suspend behavior for USB devices, which can be done from the Power Management options in the control panel. There is probably a way to do this using registry keys as described in the MS knowledge base article, but the instructions given there specify registry keys and areas that do not exist.

Figure 2 - Windows Power Management Dialog


Figure 3 - Showing USB selective suspend enabled (undesirable)


Figure 4 - Showing USB Selective Suspend disabled (desirable)




(There's a reason Win NT didn't support USB when it first came out, and why USB support in Linux was really sketchy and unpredictable, 10-15 years ago)

On Mon, Dec 12, 2022 at 10:25 AM, Anne Ranch wrote:

I am planning to ask directly in github....

Good plan; now execute it and you should be all set!