Beware of cheap underperforming clones

As of 2022 there are many badly performing clones on the market. V2/3GHz NanoVNA uses parts like ADF4350 and AD8342 which are costly and clones have been cutting costs by using salvaged or reject parts.

See official store and look for V2 Plus4/V2 Plus4 Pro versions only to avoid getting a bad clone. We have stopped selling V2.2 versions since October 2020, so all V2 hardware that are not Plus or Plus4 are not made by us and we can not guarantee performance.

NanoVNA V2 Forum

Note: this page is a mirror of https://groups.io/g/NanoVNAV2.
Click here to join and see most recent posts.

NanoVNA V2Plus4 requires extra sleep nanovna-saver on Linux #nanovna-saver


sumpster 2021/08/10 14:08

Hi,

for a couple of days I have had serious problems connecting to my NanoVNA. Once I got the device connected, it worked flawless and I could even disconnect and reconnect without any problems.
Asking google only showed that some people had similar problems which were blamed on the OS or where the problem simply disappeared after unspecific changes.

On a day where I could not get it to connect withing 30 minutes, I started looking into the nanovna sources in combination with debugging output and found the following behavior:

1. program sends a command to read the firmware version number, waits for 50ms before trying to read it
2. It fails to read it
3. It continues to read the hardware revision number and again waits for 50ms
4. This time it reads something, but it actually reads the firmware version that was requested in 1.
5. Program crashes because firmware version is None

So I made a simple test and increased the waiting time in 1. & 3. to 500ms. After this change it now connects on the first attempt two days in a row. (This was like a lottery win before)
What makes it even more interesting. If it has been connected once, I can set the timeout back to 50ms and restart nanovna-saver and it will continue to connect without problems.
There clearly is something either on PC or VNA side which causes some unexpected delay on the first command(s?).

I am wondering now if I should create a pull request where the version read is retried for a certain amount of time to cope with this situation.
So what is your opinion?

Regards

DiSlord 2021/08/10 22:03

I see strange delays if connect over USB 3 (read screenshot for example need near 6 sec).
Over USB 2 for read need about 1 sec.
This all on Windows

Try use USB 2 port for connection

Jim Lux 2021/08/11 07:24

On 8/10/21 10:03 PM, DiSlord wrote:
> I see strange delays if connect over USB 3 (read screenshot for
> example need near 6 sec).
> Over USB 2 for read need about 1 sec.
> This all on Windows
>
> Try use USB 2 port for connection
> _._,_._,_
I've noticed similar things not with the NanoVNA, but other USB serial
devices. I wonder if the device driver allocates bigger buffers or
longer timeouts for a USB3 physical interface, in anticipation of higher
speeds.  The overhead from a 16 character buffer is fine on a mouse or
keyboard on a USB 1, but is going to be pretty painful with a gigabit
rate external drive or network interface.

To reply to this topic, join https://groups.io/g/NanoVNAV2

View this thread on groups.io