Troubleshooting

When something isn’t working right, start here. This page covers the most common problems and their quickest fixes. For deeper explanations, follow the cross-links into the relevant guides.

Quick Fixes

The five issues that come up most often, with one-line solutions:

Symptom	Fix
Device not recognized over USB	Try a different cable — many are charge-only with no data lines
Display blank after connecting	Press the jog wheel to wake from sleep, or try a data-capable cable
Calibration looks wrong	Clean the SMA connectors with isopropyl alcohol and re-calibrate
Traces are very noisy	Reduce IF bandwidth via `DISPLAY > TRANSFORM > BANDWIDTH`
Spike near 588 MHz	Known MS5351 VCO limitation — not a hardware defect

USB and Connection Problems

Device not recognized

Try a different USB cable. Charge-only cables are the single most common cause of connection failures. A data-capable cable will have four wires inside; a charge-only cable has two.
Try a different USB port, preferably one directly on the motherboard rather than through a hub.
On Windows, check Device Manager for an unknown device. On Linux, run dmesg | tail after plugging in.

Permission denied on Linux

The device appears as /dev/ttyACMx but your terminal program refuses to open it.

Add your user to the dialout group: sudo usermod -aG dialout $USER
Log out and back in for the group change to take effect.
Alternatively, create a udev rule for persistent permissions.

Multiple COM ports showing up

Windows sometimes assigns a new COM port number each time you plug in, or retains stale entries from previously connected devices.

In Device Manager, show hidden devices and remove old COM port entries.
Note the new COM port number each time you reconnect.
NanoVNA-H presents a single CDC interface — if you see two ports, one may be from another device.

Communication errors or no response

Verify the correct baud rate (115200 8N1) in your terminal program.
Disconnect and reconnect the USB cable.
Close any other software that might be holding the port open.
Try the info shell command to confirm the device responds.

See: USB Connection for full setup instructions.

Calibration Problems

Calibration gives poor results

Clean all SMA connectors and calibration standards with isopropyl alcohol.
Let the device warm up for 5-10 minutes before calibrating — the TCXO drifts slightly as it reaches thermal equilibrium.
Tighten connectors firmly by hand. Finger-tight is fine, but loose connections ruin calibration.
Perform calibration across exactly the frequency range you intend to measure.

S11 of LOAD standard worse than expected

Budget calibration loads are often -25 to -30 dB return loss, not the -40 dB you might expect. This is a standard limitation, not a device problem.
For better results, use quality calibration standards or compensate with known standard data.

S21 shows unexpected loss after THRU calibration

Check the test cables. Coaxial cables add loss, especially at higher frequencies. A 30 cm RG-174 pigtail can add 1-2 dB above 1 GHz.
S21 dynamic range degrades above the harmonic switching threshold (~290 MHz). Loss readings become less reliable beyond -50 dB.

Calibration drifts over time

Temperature changes are the primary cause. The TCXO shifts with ambient temperature.
Recalibrate if the environment has changed significantly since last calibration.
Store calibrations to dedicated save slots for different setups and conditions.

See: Full Calibration for step-by-step calibration procedures.

Display and Touch Issues

Display blank or garbled

Confirm the USB cable carries data (or use an external power supply). A charge-only cable may not fully initialize the device.
Press the jog wheel — the display may be in sleep mode.
If the display shows random pixels or artifacts, try a power cycle. Persistent garbled output may indicate a loose ribbon cable (requires opening the case).

Touch not responding

The NanoVNA-H uses a resistive touchscreen. It requires deliberate finger pressure, not the light tap you’d use on a capacitive phone screen.
Run touch calibration: CONFIG > TOUCH CAL and tap each crosshair target precisely.
If touch works but controls the wrong area of the screen, the calibration data is corrupted. Recalibrate.

Touch coordinates wrong after flipping display

After changing display orientation via CONFIG > FLIP DISPLAY, you must also re-run CONFIG > TOUCH CAL so the touch coordinates match the new orientation.

See: Touch Calibration | Flip Display

Measurement Accuracy

Traces are noisy

Reduce IF bandwidth. Lower bandwidth means slower sweeps but cleaner traces. Try stepping down from 4 kHz to 1 kHz or lower.
Check all connections for tightness. Even a slightly loose SMA can introduce noise.
Move away from strong RF sources (transmitters, switching power supplies, monitors).
Enable trace smoothing for visual clarity, though it does not improve the underlying measurement.

Frequency offset

The displayed frequency is slightly off from the actual stimulus frequency.

Run TCXO calibration using a known reference signal. Even a 1 ppm error shifts 1 GHz by 1 kHz.
Crystal aging and temperature cause gradual drift. Recalibrate the TCXO periodically.

See: TCXO Frequency

S21 shows positive gain values

Uncalibrated or improperly calibrated THRU reference. Re-run the full SOLT calibration.
Ensure the THRU calibration used the same cables as your measurement.

Phase jumps erratically

This is normal behavior when the signal magnitude is very low (near the noise floor). Phase becomes meaningless when there is no coherent signal to measure.
If phase jumps at moderate signal levels, check for connector issues or re-calibrate.

Time domain distance is wrong

Verify the velocity factor matches your cable type. The default is 1.0 (free space). Common coax values: RG-58 = 0.66, RG-213 = 0.66, LMR-400 = 0.85.
Ensure the calibration plane is at the cable input, not at the DUT end.
Wide frequency spans improve time domain resolution. Narrow spans give better distance accuracy.

See: Data Smoothing | Time Domain

Firmware Update Issues

Device not detected in DFU mode

Verify the cable is data-capable (same as above — charge-only cables are the top cause).
Enter DFU mode correctly: power off, hold BOOT0 jumper or bridge, then power on. The screen should stay dark.
On Linux, check with lsusb | grep 0483:df11. You should see an STM32 DFU device.
On Windows, install the WinUSB driver via Zadig if the DFU device shows as “Unknown.”

Flash command fails

On Linux, dfu-util requires root permissions. Run with sudo or set up a udev rule.
Ensure no other program (terminal, NanoVNASaver) is holding the USB device open.
Try disconnecting and reconnecting, then flash immediately.

Device won’t boot after firmware update

If the device is completely unresponsive, use the hardware BOOT0 method to force DFU mode and reflash.

See: Firmware Update

SD Card Issues

Card not detected

Remove the card, power cycle the NanoVNA, and reinsert the card while the device is on.
Try a different microSD card. Cards larger than 32 GB must be formatted as FAT32 (not exFAT).
Clean the card contacts gently with a dry cloth.

Files not showing in the browser

Files must be in the root directory of the SD card.
Filenames must follow 8.3 naming convention (8 characters max, no spaces, no special characters).
Use the sd_list shell command to verify the card contents if the menu shows nothing.

Write errors or corruption

Check that the write-protect slider on the SD adapter is not engaged.
Ensure the card has free space. The NanoVNA does not report “disk full” clearly.
If files are corrupted, reformat the card as FAT32 on a computer and try again.

See: File Browser

PC Software Issues

NanoVNASharp won’t connect

Select the correct COM port from the dropdown and click Connect.
Close any terminal program that might be holding the port open. Only one application can use a COM port at a time.
Restart the NanoVNA-H and try reconnecting.
Use the latest version of NanoVNASharp from the repository, as older versions may not support current firmware.

Remote desktop display not updating

Ensure “auto refresh” or continuous sweep is enabled in the software settings.
Check that the USB connection is stable (cable quality matters here too).
Some VPN or remote desktop software interferes with USB passthrough.

See: NanoVNASharp | Remote Desktop

Hardware Issues

Battery voltage reads 0 or fluctuates

The battery monitor relies on a calibrated ADC offset. If the reading is off, recalibrate via CONFIG > BATTERY OFFSET.
A reading of 0 mV when running on USB power (no battery) is normal on some hardware revisions.
Fluctuating readings can indicate a failing LiPo cell or a poor solder joint on the battery connector.

See: Battery Offset

VCO lock failure / spike near 588 MHz

This is a known limitation of certain MS5351 frequency synthesizer chips. The VCO cannot reliably lock across its full range, and the failure manifests as an anomalous spike near 588 MHz.
The spike corresponds to the boundary where the VCO divider ratio changes. It is not a defect in your specific unit.
If the spike interferes with your measurement, narrow the sweep range to avoid that region.

See: Synth Variants

Poor port isolation below 300 MHz

Port isolation depends on the mixer chip. Units with the original SA612A typically show better isolation than some replacement chips.
Hardware revision 3.7 (NanoVNA-H) and 4.4 (NanoVNA-H4) with the ZeeTK NE602A improve isolation in this range.
Calibration compensates for isolation error. Ensure you include the ISOLATION step during calibration if your firmware supports it.

See: Hardware Revisions

Recovery Procedures

Factory Reset via Shell

If your device boots but settings are corrupted (wrong touch calibration, broken config, garbled display settings), you can reset everything through the USB serial console.

Connect to the NanoVNA-H via USB and open a serial terminal at 115200 baud.
Send clearconfig to reset all configuration to factory defaults.
Send reset to reboot the device.
After reboot, run touch calibration via CONFIG > TOUCH CAL.
Recalibrate for your measurement setup — all saved calibrations are cleared.

See: Serial Console for connection details.

Emergency DFU Recovery

When the device will not boot at all — no display, no USB enumeration, completely unresponsive:

Disconnect USB and any battery power completely.
Locate the BOOT0 pads on the circuit board (you may need to open the case).
Bridge BOOT0 to VCC using a jumper wire or tweezers while connecting USB power.
The device should enumerate as an STM32 DFU device (no display activity is expected).

Flash the correct firmware binary:

# For NanoVNA-H (F072)
sudo dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D H.bin

# For NanoVNA-H4 (F303)
sudo dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D H4.bin

Remove the BOOT0 bridge and power cycle the device.