PCs, Test Equipment

Some PC Software for NanoVNA

As regular readers are well aware, my main PC runs Linux Mint, and has for many years. I do run a Windows 10 PC as well, in order to build code for that platform as well as to play games, but it’s my preference to do nearly all of my work on my Linux box.

There exists an “official” NanoVNA PC program that runs in the .NET environment on Windows PCs. I’ve tried it out on my Windows box and it works alright, but has some annoying bugs that make it difficult to use. The big problem is that this program is closed source, so no one in the community can help to improve or fix the code. Naturally, I turned to the interwebs to look for an open source alternative that could run on Linux. I figured there had to be one or that one would be released soon, since the virtual serial port protocol for the NanoVNA had already been documented by people on the NanoVNA mailing list.

I eventually found the NanoVNASaver program by Rune B. Broberg, 5Q5R. It’s a Python 3.7/Qt program that is cross-platform and was very easy for me to install and run on my Mint box:

git clone https://github.com/mihtjel/nanovna-saver
python3.7 nanovna-saver.py

Of course, YMMV, since you may have to install some dependencies before you can get it to run. Also, it requires Python version 3.7, so be sure you have that specific version installed if you are not running a precompiled binary.

NanoVNASaver has pretty much all of the features of the “official” program, plus more. You can select from a variety of S11 and S21 plot types, and the markers work as you would expect (unlike the “official” program). It will export Touchstone files for use in SPICE and other modeling tools. You can also save and display reference traces, which is of course quite useful.

NanoVNASaver also has a neat TDR function along with a window for the graph so that you can measure cable lengths.

Perhaps the most useful feature in NanoVNASaver is how it handles the sweep. Instead of only doing a single 101 point sweep, you can specify an arbitrary (up to a point, I assume) number of sweeps, so that you can collect 101 * number of sweeps points of data, which is something that my current NanoVNA firmware doesn’t do.

Development has been proceeding at a very fast pace, and I would assume that the version that I’ve reviewed for you (0.0.9) will be deprecated very quickly, if you happen to be reading this very long after the publication date. The great thing about getting it via git clone is that it’s as easy as issuing a git pull origin master to update it.

All in all, I’m really happy with this free and open source software which complements the NanoVNA nicely. Hats off to Rune for providing such a valuable resource to the community.


VOACAP For Linux

During some discussions with AA7EE regarding a seeming lack of 20 meter propagation between us at any time right now, we both decided to do a bit of research into what was even feasible according to predictive software. Dave went to the VOACAP web service from OH6BG to get some nice plots which showed that indeed it would be nearly impossible for us to make a 20 meter QSO right now.

The web site is nice, but being a Linux nerd, I wanted to see if I could find comparable software for my PC. A small bit of searching led me to VOACAPL from HZ1JW, and the matching package pythonProp, which gives a GUI frontend to the CLI VOACAP interface.

The installation of the VOACAPL software is quite easy if you are using Ubuntu. Just download the .DEB file and install using your favorite package manager. Installing pythonProp is a bit more involved, since there are a fair number of dependencies to install first, but as long as you closely follow the instructions on the website it shouldn’t be much of a problem.

If you are like me and the thought of tackling VOACAP through the command line was a little bit daunting, then the voacapgui tool (in the pythonProp package) is just what you are looking for. The GUI has three main tabs for interacting with the program: one for the site information (transmitter and receiver QTH, antenna, and power), one tab to execute point-to-point channel analysis, and one for generating area propagation maps.

As you can see above, the P2P tab can get you a nice plot of the probability of making a QSO over a certain path with the specified antennae and power levels. And since this is a Linux port of the program that Dave used on the web, the data we got back was nearly identical. No 20 meter QSOs for us right now.

Here you can see an area map showing circuit reliability for 7 MHz at 0300 UTC during Oct 2011 using 5 watts. That doesn’t look very good! (Sometimes I wonder if the predictions for low power are a bit out-of-whack. This software was originally written for VOA, so I wonder if it’s really calculating the reliability for a 5 W AM signal. I am a total novice at this, so I expect some VOACAP expert will probably put me some knowledge on this, as the kids say).

Any way, it’s a neat package to play around with if you have a Linux box. Many thanks to HZ1JW for taking the time to port VOACAP over to Linux in a easy-to-use package.


Sure enough, I made a mistake. Had I read the documentation more thoroughly, I would have seen that parameter Required SNR was set to a default suitable for SSB. At least I was onto the right idea a few paragraphs above. Here’s the same area plot as before, but with the Required SNR set for a suggested value of 24 for CW operation.

That looks better!

Ham Culture, Operating

Ham Radio Hits Linux Journal

cover189The January 2010 issue of Linux Journal is hitting the newsstands, and this one has the theme of Amateur Radio and Linux. One of the featured articles was written by none other than the local Linux guru, KK7DS. I haven’t purchased the issue yet, but I got a sneak peak at this particular article, and I know that Dan does a nice overview of the ways in which you can integrate Linux into your ham radio activities. There’s also a podcast that the magazine has launched with this issue. The hosts talk about the ham radio stuff, although they are not hams, so they have a bit of a difficult time doing a good job of describing what’s going on with the ham radio stuff. It would have been nice if they would have brought Dan or another ham on as a guest. But it’s worth a listen if you are curious about what’s in the magazine, and it’s only about 20 minutes of program. Check it out if you currently use Linux in your shack or might be interested in doing so.

Cool Stuff

You Got Your Linux in My Ham Shack!

No, you got your ham shack in my Linux!

I’ve been grumbling to myself about the lack of active ham radio podcasts (sorry but the usual generic ham radio news shows don’t count as podcasts in my book). Lo and behold, I see that KB5JBV and K5TUX have just launched a new podcast, Linux in the HAM Shack. This is right up my alley! The first episode just dropped tonight and I’m exicted to see where the podcast goes in future episodes. This first one is mostly an introduction, so there’s not a lot of meat in it, but I’m sure that will be remedied by episode 2. If you run a Linux box in the shack, or even use open source software like Firefox, I recommend that you subscribe to the podcast feed. Let’s support these guys in a worthwhile effort!

Coding, FPGA

Configuring the Avnet Spartan-3A Eval Board on Linux (Alpha)

As I mentioned on the Avnet Spartan-3A Eval Kit Google Group, I’ve created a C program that will allow you to configure the FPGA via your Linux box. I don’t have a lot of time to elaborate on how to use this program, but the basic steps are listed below. These instructions assume that you are at least moderately familiar with using the shell in your distribution and building a program from source code. This code is in an alpha state and I have only tested this on my Ubuntu Hardy Heron box, so your mileage may vary. I’m sure there’s much I can do to improve it (clean up, refactor, etc.), but it seems to do what it needs to for now.

Right now, the program is controlled by three command line switches. I’ve created these options with a mind for expansion in the future (at least the serial flash part). Here’s the help printout from the program:

Usage: avs3a [options]
  -b, --bitstream=BITSTREAM	Bitstream used to configure FPGA
  -p, --port=SERIAL-PORT	Serial port connected to eval board
  -s, --slaveser		Configure FPGA in Slave Serial mode
  1. Download the source code here.
  2. Unpack the archive in the location where you intend to use the program.
    tar xzvf avs3a.tar.gz
  3. Change to the avs3a directory.
    cd avs3a
  4. Build the program from source.
    make all
  5. Make sure that your eval board is plugged into a USB port.
  6. If you don’t know the serial port of the eval board, then find it. I’m not sure what you will see, but on my Ubuntu Hardy box, my board enumerates as /dev/ttyACM0 or /dev/ttyACM1
    dmesg | grep tty
  7. Make sure you have a bitstream file to use.
  8. Issue the command to program the board
    ./avs3a -s -p /dev/ttyACM0 -b sample_bitstream.bit

If you try this and find it useful, or find a problem with the program then please, please, let me know in the comments below (or e-mail me). Thank you for testing this!


Learning DSP Concepts with BasicDSP

Completely by accident, I happened to stumble upon a program that gives you an easy way to learn DSP techniques by focusing on the underlying algorithms and not the hardware details. The program is called BasicDSP and is available as a Linux source tarball or Windows executable. BasicDSP was created by PA3FWM and PE1OIT as a tool to allow you to experiment with signal processing algorithms from basic building blocks such as filters and mixers, up to complete receiver systems in code. The program can take its input from a variety of sources, such as the soundcard, a file, or an internally generated signal. A simple scripting language is then used to manipulate the input data using a variety of DSP techniques (including some built-in functions). The resulting audio is them piped back out to the soundcard, as well as optional spectrum and oscilloscope displays.

BasicDSP running on my Ubuntu Hardy notebook

The source tarball didn’t want to compile on my Ubuntu Hardy machine on the first try. It threw some cryptic errors about some of the wxWidget objects in the code. A bit of Googling and some lucky guessing enabled me to figure out that the code wanted to compile with wxWidgets 2.6, not the version 2.8 that is standard on Hardy. I forced the linker to use 2.6 and managed to get the code to compile (although it was still complaining about a few warnings). Once I got over that speed bump, the program seemed to work as advertised, with one exception. As you can see in the attached screenshot, something is seriously wrong with the spectrum display. For some reason, the program is drawing vertical lines across the entire spectrum where there should be nothing. Since I had access to the code, I thought that maybe I would give a shot a locating any glaring problems that might be causing this. I know a bit of C++, but have very little experience in coding for *nix machines, and know virtually nothing about wxWidgets. However, the code to draw the spectrum display seemed fairly obvious and I couldn’t find anything wrong with it. You can still see a signal on the display if you look hard enough, but its very difficult to tell with all of the offending vertical lines. My best guess is that something is wrong in the array which holds the FFT data plotted by the spectrum display, but that’s only a guess. I just don’t have the expertise or the proper tools to properly debug this type of problem.

Ignoring that flaw, this is otherwise a really neat program. The syntax is very simple and allows you to easily try different processing concepts in just a few lines of code. There are two special variables that get used in every script: in and out. The in variable represents the data flowing into BasicDSP from the chosen source, while out is the variable that you send your processed data to in order to output it to the speaker. The simplest script that you can write for BasicDSP is a passthrough function, where no processing of the data is performed:

out = in

In the above example, each sample is directly passed to the output. If you could not hear the output very well, you can amplify the signal by performing multiplication with a constant.

out = in * 100

By multiplying the sample by 100, you are increasing the signal level by 40 dB.
$$!20\ \log\ 100 = 40\ \text{dB}$$

There are four slider controls which are accessible via variable (slider1slider4). These allow you to dynamically alter variables in the script. For example, if you wanted to be able to change the signal level with a slider, it’s a simple as:

out = in * slider1

There are other special variables and functions included in the scripting language that help to enable common DSP tasks. These can all be put together to create simple circuit blocks like low-pass filters, up to more complex tasks like quadrature receivers. A basic direct conversion receiver can be put together quite simply using these functions. The following code (taken from a reprint of a SPRAT tutorial) implements the DC receiver in code by creating a sawtooth oscillator (in lines 2 & 3), mixing the input signal to baseband (just a simple multiplication at line 4), then sending the signal through two stages of low-pass filtering (lines 5 & 6).

samplerate = 48000
sawtooth = mod1(sawtooth+slider1)
osc = sin1(sawtooth)
mix = osc * in
lpfa = lpfa + slider2*(mix-lpfa)
lpfb = lpfb + slider2*(lpfa-lpfb)
out = lpfb

There’s some more information on the program and some good example code on the website of PE1OIT. If you have even a small bit of interest in the inner workings of a SDR receiver, you owe it to yourself to download this software and try it out.