¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Yet another NanoVNA PC app


 
Edited

This afternoon, I discovered what caused the "Invalid input string format" message. TAPR requires .NET v1.1, which must be searched for and installed in a language appropriate for the PC operating system. DfuSe and ST-Link Utility were previously installed on the machine, so the driver was not missing.
My computer has a Hungarian operating system installed, and the keyboard is Hungarian. First, you need to change the Default Input Language to English (US) International. This is because the input string error occurred because the dot and comma are reversed relative to the English international. In Control Panel-> Region & Language-> Formats-> English (US) and then in Advanced Options-> Numbers-> Decimal Point. Thousand preselected commas. List separator comma.
Then I connected the nano via USB and turned it on and loaded VNAR3.exe.
I have previously configured it, recognized the port and selected nanoVNA so it was logged in immediately. I went to the calibration menu and connected with the Short terminator, checked the Start-Stop frequency and did the operation. You can monitor the calibration process on the nano display because it continuously indicates the frequency. It takes some time to finish, then the next Open closing and so on. Finally, with Save Cal Results, you save the calibration with a well-selected name and a suitable folder. You can do this for multiple domains.
I hope I could help for others.

73, Gyula HA3HZ


 

Wine does not support USB so you cannot install a USB windows device driver
I am currently without a linux box to verify, but expect these instructions to work:


 

Nanovnasharp /VNAR4 require a kernel mode windows driver to be installed to emulate a COM port ...



Nanovnasharp /VNAR4 and Wine run in user mode. Wine can only use linux kernel mode drivers.

There is no equivalent linux kernel mode driver to emulate a COM port for those apps.

However the standard instructions for mapping COM ports to a linux serial device provided in the link you quoted and here...



...will work to allow a windows terminal program to communicate with a nanovna because linux automatically provides a serial device /dev/ttyACM0, and the linux kernel includes a serial device driver.


 

Nanovnasharp will run on Linux Mint 19.2 using virtualbox, which emulates everything right down to the hardware, so it is possible to install a Windows kernel mode driver.

Here's the steps...

- create a new 32 bit virtual machine running Win7+SP1
- enable USB on the VM for the STMicroelectronics Virtual COM Port
- run the VM
- install dotnet40
- install VCP_V1.5.0_Setup_W7_x86_32bits.exe which created COM3
- run NanoVNA.exe
- switch on the nanovna
- hit Connect - worked first time!
- hit Get Data - it sort of works.

Unfortunately there is some corruption of the data as received by the application. There is no corruption on the screen of the nanovna itself.

Attached 2 pictures; good shows what it should look like, bad is what it looks like 9 out of 10 scans. The anomalous spikes appear in apparently random places and in varying number on the scan.

There is a 7MHz BPF connected to the nanovna.

Has anyone seen anything similar with this app?


 

I'm not trying to convert anyone, but is there any particular reason you're
not using NanoVNA-Saver, which runs natively on Linux? :-)

--
Rune / 5Q5R

On Sat, 12 Oct 2019 at 18:09, Nick <g3vnc@...> wrote:

Nanovnasharp will run on Linux Mint 19.2 using virtualbox, which emulates
everything right down to the hardware, so it is possible to install a
Windows kernel mode driver.

Here's the steps...

- create a new 32 bit virtual machine running Win7+SP1
- enable USB on the VM for the STMicroelectronics Virtual COM Port
- run the VM
- install dotnet40
- install VCP_V1.5.0_Setup_W7_x86_32bits.exe which created COM3
- run NanoVNA.exe
- switch on the nanovna
- hit Connect - worked first time!
- hit Get Data - it sort of works.

Unfortunately there is some corruption of the data as received by the
application. There is no corruption on the screen of the nanovna itself.

Attached 2 pictures; good shows what it should look like, bad is what it
looks like 9 out of 10 scans. The anomalous spikes appear in apparently
random places and in varying number on the scan.

There is a 7MHz BPF connected to the nanovna.

Has anyone seen anything similar with this app?




 

I am of course using nanovna-saver for serious measurements! Were it not for your excellent app the nanovna would be gathering dust in my desk drawer by now.

I started this somewhat academic exercise with nanovnasharp to see if a native windows app that depends on a windows device driver could be made to run on linux using Wine.

What I found of course is that it will not work if there is no equivalent driver available in linux.

So this gave me an excuse to try out virtualbox.

Do you have any theories as to why there is lost scan data? I saved .s1p and .s2p files and opened them with nanovna-saver and the corruption was still there. There's nothing useful in the virtualbox logs so am at a bit of a loss to explain it.


 

there is some corruption of the data as received by the application
Have you tried inserting a USB 2.0 hub between nanoVNA and Linux PC?


 

Some firmware versions, 0.2.0 to 0.2.2, could show some problems with
repeated "sweep" commands with no or short delay between them. It should be
fixed in 0.2.3, so maybe that's it?

There were some older firmware versions that had significant data transfer
problems, I think back in August or so. Could be it as well. But if you're
not seeing it when using other software, it's not obvious what the reason
is.

--
Rune / 5Q5R

On Sat, 12 Oct 2019 at 17:44, Nick <g3vnc@...> wrote:

I am of course using nanovna-saver for serious measurements! Were it not
for your excellent app the nanovna would be gathering dust in my desk
drawer by now.

I started this somewhat academic exercise with nanovnasharp to see if a
native windows app that depends on a windows device driver could be made to
run on linux using Wine.

What I found of course is that it will not work if there is no equivalent
driver available in linux.

So this gave me an excuse to try out virtualbox.

Do you have any theories as to why there is lost scan data? I saved .s1p
and .s2p files and opened them with nanovna-saver and the corruption was
still there. There's nothing useful in the virtualbox logs so am at a bit
of a loss to explain it.




 

Hi Rune -

I'm not trying to convert anyone
Any consideration of mobile (iOS / Android) versions?
QT5 and Python are both supported on both, after a fashion...

Imagining that nanoVNA evolution forks,
a low-end Bluetooth dongle (picoVNA?)
could be cheaper with longer battery life
and UI focused on hosts where UI rules.


 

Well, I believe there is already a mobile app available for the NanoVNA?

Having a mobile version would be fine, and I'm not doing anything to
actively prevent it - ;-) - but I'm also not spending time actively working
on it while I have a long list of things I want to do with the PC version.
At least for now, I think supporting Windows, Mac and Linux is going to be
it for me personally.

--
Rune / 5Q5R

On Sun, 13 Oct 2019 at 15:35, Oristo <ormpoa@...> wrote:

Hi Rune -

I'm not trying to convert anyone
Any consideration of mobile (iOS / Android) versions?
QT5 and Python are both supported on both, after a fashion...

Imagining that nanoVNA evolution forks,
a low-end Bluetooth dongle (picoVNA?)
could be cheaper with longer battery life
and UI focused on hosts where UI rules.




 

/g/nanovna-users/files/NanoVNA%20PC%20Software/TAPR%20VNA/VNAR4.3.zip

Hi Erik
I have latest dotnet and vc++ on W10 32. 2 nano's Huygen 0.2.3 and DMR 2.5.5.
Both same issue;
Start VNAR4.3 - finds correct port - To Calibration - press 'short' - changes frequencies on nano - Then nothing - nano still running at that frequency - IF I PAUSE SWEEP ON NANO, VNAR4.3 CONTINUES! - completes cal. - same in run - if I pause nano sweep, VNAR4.3 completes, but marker data says NaN, as nano is paused....
So, how can I run nano with VNAR4.3 together? - Both nano's fine with nanoVNA Saver etc.
Cheers
Colin


 

On Sat, Oct 12, 2019 at 05:49 PM, Oristo wrote:

there is some corruption of the data as received by the application
Have you tried inserting a USB 2.0 hub between nanoVNA and Linux PC?
Thanks Oristo, I tried that but no difference.

Thanks Rune, you were correct. Upgraded original GEN111 02.08.19 firmware to edy555 0.2.3 07.10.19 and problem fixed.

Nanovna# 1.03 now runs on 32 bit Win7 guest on 64 bit Linux Mint 19.2 host using virtualbox 6.

The recent Mod3 variant also works. It can capture a screenshot direct from the device.

73
Nick


 

On Sat, Oct 12, 2019 at 07:09 PM, Nick wrote:


Unfortunately there is some corruption of the data as received by the
application.
This data corruption happens due to errors in the NanoVNA firmware. You're needs to upgrade to more fresh firmware, it has less errors.
First versions of NanoVNAsharp just hide these errors, so you don't know that the data is corrupted.
MOD V3 shows you warning, because you're needs to know, that the data is corrupted and you cannot believe it.


 

On Sat, Oct 12, 2019 at 07:44 PM, Nick wrote:


Do you have any theories as to why there is lost scan data?
There is no theories, this is well known bug of NanoVNA firmware.
The latest firmware version has significantly improved, so these errors happens not so often, but it is still possible.


 

this is well known bug of NanoVNA firmware.
Is some GitHub issue logged?


 

On Fri, Oct 25, 2019 at 08:17 PM, Oristo wrote:


Is some GitHub issue logged?


 

On Fri, Oct 25, 2019 at 05:24 PM, QRP RX wrote:

This data corruption happens due to errors in the NanoVNA firmware. You're
needs to upgrade to more fresh firmware, it has less errors.
First versions of NanoVNAsharp just hide these errors, so you don't know that
the data is corrupted.
MOD V3 shows you warning, because you're needs to know, that the data is
corrupted and you cannot believe it.
Thanks for confirming that. Both edy555 and Hugen79 0.2.3 are fine with Mod3.