开云体育

"(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!

I am not really sure what kind of problem you are running into....( did not
bother to read)
But if it looks like a software issue, smells like a software issue and
quacks like a software issue, but the user refuses to update.
Then the problem might very well be sitting in front of the screen.

-John




Op zo 11 dec. 2022 om 15:41 schreef Anne Ranch <anneranch2442@...>:

5v power should *always* be available on a USB port, 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

--
Tim Dawson (tadawson@...) Owner/Engineer
TPC Services Bellnet: (972)-221-7385
Lewisville, Texas 75067
"The world is complex. Sendmail.cf reflects this...."

Up front - few years back I got involved with nanoVNASaver and soon
realized this is not a right group to ask about nanoVNASaver software.

BUT - if there is a remote possibility that has changed

Does anybody (here) has an interest in hacking the nanoVNASaver software?

I have managed to clone it as QT project , but since I do not do "python" I am pretty much stuck...

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

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/11/22 8:07 PM, Anne Ranch wrote:

My PC is "open architecture " ASUS motherboard in old desktop case. nanoVNA USB port is via powered D_Link " USB hub.
It has not been powered for about 6 months ,,,, I am going to let it fully discharge overnight.
It looks as setting to "continuous sweep" drains the battery pretty fast - perhaps the flashing
"sweep LED" is "too much load "?

The OS still controls (or at least manages) the hub's power as part of the whole USB tree, even if the hub itself receives external power. That is, the hub can decide if it wants to turn power on to a downstream device or not, and the OS (in theory) can find out. The OS can also force a downstream hub to turn off a device.

Considering that (almost) all USB hubs are 4 port devices at the "building block" level, the interlocking state diagrams up and down the chain can be really complex to figure out exactly what is going on.
(Note that this four-ness, is why you see 7 port hubs. It's actually a cascade of two 4 ports, with one hanging off one of the 4 ports of the other).

There's an equally complex negotiation and state machine for data rate through a USB hub.

Interesting question.

I mostly use my Nano VNA on HF bands.
It has never failed in any aspect - one port antenna, 2 port filter tests, over all of the HF bands anyway.

But when I did the 440 band calibration, I did it over a 20x sample, so the number of data points on the 1-port calibration was about 2000 data. You want to be sure the CAL file does what you need.
Plug your 50 ohm standard into the port (in place of your 440 antenna) and test the VSWR from 430 to 450 MHz and see if you get what you expect: 1 to 1.


I suspect that the coax you use to connect this Nano VNA socket to your 440 antenna matters a bunch.
First, I would try a very simple 440 MHz ground plan using just a few feet of coax, just to verify everything is working.
Do you have an SMA to UHF coax socket adapter?


I usually plot the Reflection Coefficient (0 to 1) and the RETURN LOSS (dB) as well as the VSWR, the Resistance and Reactance, the PHASE, and finally a Smith Chart on ALL of my HF antenna checks.
They should all agree.

Where is the resonant frequency/frequencies (where the reactance is zero)?
Where is the VSWR minimum?
Where does the phase change from net to pos?

My Nano VNA is three years old and my SAVE software is something like V0.5

I’ve never used it with the internal battery, nor the internal 101 data points.
I always use it connect to usb port, power with usb port, and to a Windows 10 desktop.
The DRIVERS are fine.

It is one amazing device with superb (free) software.
I can share some of my 70 cm antenna plots if that would help.

I would bet problems you have are due to bad connectors and/or faulty coax when you get up to 440 MHz band.
So try your 50 ohm dummy load and be sure it is behaving.

So explain in detail your calibration procedures.

Hope you solve your question,

K3eui barry

My PC is "open architecture " ASUS motherboard in old desktop case. nanoVNA USB port is via powered D_Link " USB hub.
It has not been powered for about 6 months ,,,, I am going to let it fully discharge overnight.
It looks as setting to "continuous sweep" drains the battery pretty fast - perhaps the flashing
"sweep LED" is "too much load "?

I charge my NanoVNA from my PC's usb port every time I use it, work fine. Are you using a laptop, or a tablet maybe?

N0NC

On 12/11/22 9:47 AM, Anne Ranch wrote:

...to be continued
there is more
when the "charge LED" is off and I plug the USP cable to wallwart - it starts flashing...
hence it is charging
after coupe of minutes
when I unplug the wallwart - the LED goes steady - charged (?) / not charging
if I plug the cable into PC USB port (powered DLink) the LED
stays on for a minute or so then LED goes blank
My OPINION / conclusion
my battery is weak and PC USB port has not enough "umpf" to actually charge
such dead battery ..

Or it's not responding to the request for more current.

ask and yea shall receive

the original post answer in in the manual under Specification

and that is why it won't work - in theory

Supply current 500 mA NO CHARGING

Battery current charging 1.2A


NORMAL , not setup for "charging " USB port is LIMITED to 500mA

if the batter charging current is 1.2 A

DEAD battery cannot be safely charged using NORMAL USB port.


Besides - rule of thumb - battery charging current is limited by
capacity (in Ah) of the battery and USUALLY about 10% of such
capacity is considered safe charge current.

I am not going to go into nanaoVNA battery technology - in is NOT Lead Acid -
however , improperly charged LiPo batteries have been source of few fife causing "accidents"

CASE CLOSED

PS
How is dx?

This make no sense
you pause the sweep, or after a single-sweep, the LED is steady on.

hence there is no flash ?

DO I understand this correctly ?

Calibrated and maybe even not calibrated (?) nanoVNA should sweep automatically - by design
( it can be calibrated for single or continuous sweep ??)

When I use nanoVNASaver I can control the sweep

so if set for "single seep" the "sweep LED" should come on - no flash-
and then stay on?

or

if set for "continuous sweep" should it keep flashing ?