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

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

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.