Posted on 11 Comments

NanoVNA Saver on the Raspberry Pi

NanoVNA Saver is an excellent package that provides a host of useful featuers for owners of the NanoVNA V1 and V2. When looking around the Internet for Pi installation instructions, I found several conflicting and out-of-date posts, so decided to develop my own. I thought it might be helpful if I post my solution here.

NanoVNA Saver works well on the Raspberry Pi models 3, 4 and 400, but installation requires a few simple steps as shown here. These instructions assume you’re using the latest Raspberry Pi OS.

Open a terminal session (Ctl-Atl-T) and enter the following commands sequentially.

cd ~

sudo apt install -y python3-pyqt5 python3-scipy

git clone

cd nanovna-saver

sudo chmod +x ~/nanovna-saver/

You can now run NanoVNA Saver by entering: python3

To create a desktop link for NanoVNA Saver, use the following steps:

Create a new file called NanoVNA-Saver.desktop, add the following content and save it in the desktop folder.

[Desktop Entry]


Comment=Runs NanoVNA Saver from the nanovna-saver folder


Exec=python3 /home/pi/nanovna-saver/





11 thoughts on “NanoVNA Saver on the Raspberry Pi

  1. GREAT! Thank you very much! This was exactly what I was looking for.
    Best regards

    1. Hi Dieter,

      Pleased to hear it was useful. I went through a few iterations myself before I found a working solution.


      Mike – G4WNC

      1. I really appreciate people like you sharing their knowledge! My Linux skills were not at all sufficient to get NanoVNA-Saver to work on the Pi.
        I am considering building a standalone VNA with a NanoVNA 2plus4, a Raspi and a 10 inch touch screen.
        The alternative software would be NanoVNA QT. I found an AppImage that runs nicely on the Pi. It’s a quite slim but less powerful than Saver.
        Thanks again, Mike!
        Dieter DL5RDO

  2. Thanks for the instructions, Dieter, I got it installed immediately. However, connecting to the nanovna fails. If necessary, I can send you the error messages but they are the same when connecting to my W10-system when not having run de cypressdriverinstaller (sometimes W10 restores the standard ones out of itself). I have tried running it with sudo but that gives the same error apart from some more warnings. The system I am using is a RPi3 with the latest version of Raspian is 11.1, bullseye.
    To check that there is not an issue with the acm_cdc driver I also installed the Arduino IDE from scratch. That did not give any problem.
    I hope you have another idea I can check?

    1. I’ll run some checks today. I’ve been having problems building FLDIGI on Bullseye and it looks like there are several common dependencies missing in the new OS. I’ll be working on it today and will let you know how I get on.

      Mike – G4WNC

      1. Sorry, Mike, I mistakenly took Dieter for your name.
        Thanks in advance for the efforts.

        1. Following your remark concerning Bullseye, I tried Buster. Took a while to locate a working image but I got one. I dist-upgraded it completely. Unfortunately this gives the same result: crashes after pressing connect!

          1. Hi Ger,

            That’s odd. I’ve just setup NanoVNA-Saver on a Pi-4 with Bullseye and the latest updates and it’s working fine with a NanoVNA H4 and a NanoVNA V2 plus. I should make sure you have all the latest updates and fixes. There is usually a sharp increase in update activity after a new OS release.

            Let me know if that doesn’t fix it.



  3. Thanks Mike. I have played around a bit with the software itself, an interesting experience in itself. I already see to what complications in the software the different versions lead. Regarding the settings for the Serial port I am a bit surprised by how little is preset. The other values are assumed to have their default value and I wonder whether this assumption is correct.
    At this moment I have the strong feeling that there may be a timing issue. Further on in this week I have some more time to have a look into this.
    I will keep you posted.

  4. Well Mike, an intermediate result: success!
    I enlarged the WRITE_DELAY in the subroutine readVersion to 5 seconds (line 214) and now the errors are gone; 1 second did not work. Question is whether this is the issue or whether already a previous command required delay; as there is no response waited for I cannot tell yet.
    In the same file the WRITE_DELAY is set to 0.05 s.
    Continuing research, albeit slowly.

    1. Final messages: 2 seconds suffices for WRITE_SLEEP (used wrong term in previous email). No better place found. Issue posted on github #441.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.