NanoVNA – DiSlord NanoVNA-D v1.1.00 & NanoVNA-App-v1.1.209-OD10 calibration

This article explains the interworking of DiSlord NanoVNA-D v1.1.00 firmware and NanoVNA-App-v1.1.209-OD10 with respect to calibration.

This applies to the specific combination of versions of firmware and software client, do not assume it applies to other combinations.

DiSlord NanoVNA-D v1.1.00 firmware supports a scan_bin command where bit 3 of the outmask field is used to request raw measurement data, ie uncorrected measurements.

NanoVNA-App-v1.1.209-OD10 supports exploitation of that capability when it recognises that firmware version and command support.

Above, NanoVNA-App-v1.1.209-OD10  has a dropdown list to choose calibration mode.

  • If you choose None or APP, it makes requests raw measurements.
  • If you choose APP, it requests raw measurements and applies the current software calibration data set to correct the measured data.
  • If you choose VNA, it requests corrected measurements from the NanoVNA using the current calibration set.

If you use NanoVNA-App-v1.1.209-OD10 to make a calibration set, when you measure each of the calibration configurations, it requests raw measurements from the NanoVNA (you do not need to disable correction in the NanoVNA). Further the calibration dataset is independent of the calibration setting on the NanoVNA, or future calibrations performed on the NanoVNA.

For avoidance of doubt, the calibration files made in NanoVNA-App-v1.1.209-OD10 are specific the the hardware and firmware in a specific NanoVNA and cannot be safely applied to another hardware instance, or a repaired or modified instance, or a firware upgrade (which may alter the inherent raw measurement calibration).

It appears that NanoVNA-App-v1.1.209-OD10 is adaptive and will work in this way with any NanoVNA (V1) firmware that returns “scan_bin” or “scan” in the list of commands given by the help command as in the following log excerpt, but the firmware needs to honor the outmask NO_CALIBRATION bit (b3).

16.133 tx: help
16.201 rx: help
16.201 rx: Commands: scan scan_bin data frequencies freq sweep power offset bandwidth time sd_list sd_read sd_delete saveconfig clearconfig dump touchcal touchtest pause resume cal save recall trace marker edelay capture vbat tcxo reset smooth usart_cfg usart vbat_offset transform threshold help info version color
16.201 rx: ch> 
16.201 tx: version
16.201 rx: version
16.201 rx: 1.1.00

Demonstration of outmask raw bit

The following is a trace of scan commands for corrected and raw data from NanoVNA-App’s comms monitor, only the  first five lines of each response are shown. The response is freq,s11.r,s11.i,n and outmask.

The load is an open circuit, theoretically s11 should be 1+j0.

53.810 tx: scan 29000000 300000000 51 3
53.819 rx: scan 29000000 300000000 51 3
53.899 rx: 29000000 1.000473261 0.004341440
53.910 rx: 34420000 0.999537408 -0.008618354
53.919 rx: 39840000 0.998404224 -0.023998050
53.929 rx: 45260000 0.996850176 -0.038681508
53.939 rx: 50680000 0.995249920 -0.052829040

48.150 tx: scan 29000000 300000000 51 11
48.150 rx: scan 29000000 300000000 51 11
48.270 rx: 29000000 0.661236416 -0.055518208
48.280 rx: 34420000 0.659682816 -0.064852924
48.280 rx: 39840000 0.658275584 -0.073653920
48.280 rx: 45260000 0.656932800 -0.082290024
48.280 rx: 50680000 0.655571648 -0.090402656

The response is freq, s11.r, s11.i, n and outmask.

  • When the outmask has bit 3 false (the first group), measurement is corrected and the s11 result is close to 1+j0.
  • When the outmask has bit 3 true (the first group), measurement is raw (ie not corrected) and the s11 result is not at all close to 1+j0.

You could do the same thing with a terminal emulator, here is Putty.


In summary, for the specific combination of DiSlord NanoVNA-D v1.1.00 and NanoVNA-App-v1.1.209-OD10:

  • NanoVNA-App is able to request raw (ie uncorrected) measurements;
  • it does so when it uses its internal calibration mode APP or when calibration mode is None, or when building a new NanoVNA-App internal calibration data set;
  • NanoVNA-APP reads corrected measurements from the NanoVNA only in the VNA calibration mode, and it uses whatever profile is active at the time on the NanoVNA.

Some other firmware versions and PC client programs would seem to use layer on layer of calibration, interpolation, correction in some situations, and recalibrating the NanoVNA makes all the software based calibrations that depended on it invalid (they probably still work, but produce errored results).