An oft cited advantage of the nanovna are choices:
- hardware (several clones of the basic thing, the ‘improved’ -H series, the coming -H with bigger screen, the -F with bigger screen… and the future v2);
- firmware (lots and lots of forks, some hardware targeted);
- external clients (PC clients, web interfaces, Python / Octave / Matlab code etc).
There is not necessarily interoperatibilty between all instances of each level of this tree. For example, nanovna-F may not share firmware images with the original nanovna and its clones, and vice versa due to a different display protocol.
Some PC clients support features not implemented in all current firmware versions, eg screen capture.
There are common traits, like the hammy sammy presentation of Smith chart markers with equivalent series R and L or C values, probably a concession to hams who don’t understand operator j. (Yes, I know that ttrftech v0.5.4 now does that, but it does not save the setting across power down).
I wrote up a number of practical applications of the -H, mostly with -Q software (which I have now abandoned) and it certainly is quite capable… but there were measurement applications where it disappointed (though I did not write them up).
Ah, did I say I have moved on from -Q firmware? -Q v4.4 added an averaging feature to reduce measurement noise by averaging each scan point over 10 measurements which should reduce the random measurement noise by two thirds, not a huge improvement (say 75% reduction from an average of 16 would have been in my mind… but never fear, I am not about to fork it get create such a variant)… but on my test it does not work. Indeed the measurement noise is worse, so not only is it slower, but the results are worse. Well, that was a month ago, and no sign of a fix, so the firmware contains a broke feature which users might just be using on good faith, and it degrades measurement accuracy.
I have tried a bunch of different firmwares, and mostly the tinkering with fonts etc does not really improve the practical usefulness of the thing (I say that as an OF, but an OF who fortunately still has good vision, albeit corrected for these things).
Above is one of the ‘improved’ screens. Note the damaged text on the bottom of the screen, and the back-to-front µ symbol in the capacitance value on the second line.
The original ttrftech firmware has a long history of continuing development, and is compatible with the -H hardware, so I have been trialing v0.5.4-20191210 with good success.
So, there is more than lots of choices, there is a surfit of choices, more choices than needed, and none of them stand out above all others in almost every respect. It is a case of more being less than less.
In all of this, little respect is paid to conventional meaning, eg that a Smith chart is fundamentally a polar plot of the complex reflection coefficient Γ which Philip Smith labelled more than 70 years ago with the principle set of scales being circles of normalised resistance and reactance (R±jX). Of course these is no capacitance or inductance scale on a ‘real’ Smith chart as the relationship of those values the plotted reactance is frequency dependent. This stuff joins the ham tradition of striking out independently.
I was asked about the suitability to a recent project based on measurements of an MFJ-1786. My nanovna-H is capable of the basic measurements stand alone and with some fiddling and likely rework, the measurements can be saved with one of the PC clients as an s1p file. None of the nanovna spawned PC clients contains the analysis tools that were used in Rigexpert’s Antscope software to open and analyse the original measurement s1p file. But whilst I would not reach for the nanovna for that project, it did acquit itself well on a number of projects I wrote up.
I did have a mind when buying this to evaluate it and sell it whilst it remained current. Well, an intermediate step was that I diagnosed and fixed a design deficiency that degrades all nanovna-H prior to v3.4, and in the event, no one made an offer to buy in two weeks. I will keep the thing, it is an interesting ‘play thing’, and the main line firmware looks like the best prospect of a usable solution and if the s parameter files can be exported, then other analysis tools can provide solutions. I am less interested in operation to 1.5GHz, or 3GHz, but practical things like ability to work with much larger scan set, so store man large calibration sets for measurements, to store multiple large scans… but these will never be a feature of the basic nanovna which is severely storage constrained.