feat(unstable): add VNA category and NanoVNA driver

[arsenovic]

Summary

adds vna support. adds a driver the nanovna_v2clone. adds tests.

Type of change

• Bug fix (fix)
• New feature (feat)
• Breaking change (feat! / fix!)
• Refactor (refactor)
• Documentation (docs)
• Chore / tooling (chore)

Verification

see tests

Tests

• Unit tests added or updated
• Existing tests cover this change
• No tests — explain why:

Checklist

• PR title follows Conventional Commits (e.g. feat(driver): add support for Keysight E36300)
• I have read CONTRIBUTING.md
• Documentation updated if user-facing behavior changed
• Code follows the style/conventions of the surrounding code

Notes for reviewers

Optional — call out specific files, edge cases, or decisions you'd like eyes on.

[greptile-apps]

Greptile Summary

The PR introduces an experimental VNA abstraction, NanoVNA serial driver, network serialization and storage, publishing wrappers, and simulated tests. Several first-pass correctness issues remain:

• The base frequency builder scales hertz values as gigahertz.
• Invalid NanoVNA port selections fail with an unintended UnboundLocalError.
• Default storage is shared across instrument instances.
• The new scikit-rf dependency is missing from the workspace lockfile.

Confidence Score: 1/5

The PR is not yet safe to merge because common VNA operations can produce incorrect frequency axes, fail with unintended exceptions, collide in shared storage, and fail lockfile validation.

The implemented hardware driver reaches a frequency-construction path that treats hertz values as gigahertz, invalid port handling reads an uninitialized variable, default instrument instances share one storage object, and the dependency manifest is inconsistent with the committed lockfile.

Files Needing Attention: packages/instro-unstable/instro/unstable/vna/vna.py, packages/instro-unstable/instro/unstable/vna/drivers/nanovna_v2clone.py, packages/instro-unstable/pyproject.toml, uv.lock

Important Files Changed

Filename	Overview
packages/instro-unstable/instro/unstable/vna/vna.py	Adds the VNA abstraction and publishing wrapper, but misconstructs frequency units and shares a mutable default storage backend.
packages/instro-unstable/instro/unstable/vna/drivers/nanovna_v2clone.py	Adds serial NanoVNA acquisition, but unsupported port selections do not raise the intended exception.
packages/instro-unstable/instro/unstable/vna/storage.py	Adds a simple local storage abstraction used by the high-level wrapper.
packages/instro-unstable/instro/unstable/vna/external.py	Serializes one-port scikit-rf network and frequency properties into measurement-compatible lists.
packages/instro-unstable/pyproject.toml	Declares scikit-rf for the new VNA feature without synchronizing the committed lockfile.
tests/unstable/vna/test_vna.py	Covers wrapper, network, save, and serialization paths, but the simulator override bypasses the faulty base frequency implementation.
uv.lock	Does not contain the newly declared scikit-rf dependency or updated instro-unstable dependency metadata.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  App[Application] --> VNA[InstroVNA]
  VNA --> Driver[VNADriverBase]
  Driver --> Nano[NanoVNAv2Clone]
  Nano <--> Hardware[NanoVNA serial interface]
  Driver --> RF[skrf Network]
  RF --> Measurement[Published measurement]
  RF --> Storage[DiskStorage / Touchstone]

Loading

Prompt To Fix All With AI

### Issue 1
packages/instro-unstable/instro/unstable/vna/vna.py:124-130
**Frequency units are misapplied**

When a driver such as `NanoVNAv2Clone` inherits `get_frequency`, its start and stop values are returned in hertz but interpreted as gigahertz, causing returned, measured, and saved networks to have frequency axes scaled by 1e9.

```suggestion
            frequency = skrf.Frequency(
                start=self.get_freq_start(ch=ch),
                stop=self.get_freq_stop(ch=ch),
                npoints=self.get_freq_npoints(ch=ch),
                unit="hz",
            )

            frequency.unit = unit
```

### Issue 2
packages/instro-unstable/instro/unstable/vna/drivers/nanovna_v2clone.py:151
**Invalid ports never raise**

When `get_network2` receives an unsupported port selection such as `[1]`, this branch constructs but does not raise `ValueError`, so execution continues with an unassigned `s` and crashes with `UnboundLocalError` instead.

```suggestion
            raise ValueError("nanovna only supports the following ports values: [0], [0,1]")
```

### Issue 3
packages/instro-unstable/instro/unstable/vna/vna.py:219
**Default storage is shared**

When multiple `InstroVNA` instances omit `storage`, they receive the same definition-time `DiskStorage` object, so equal network names resolve to the same temporary path and later saves overwrite or conflict with earlier instruments' files.

### Issue 4
packages/instro-unstable/pyproject.toml:10
**Lockfile omits scikit-rf**

The manifest adds `scikit-rf`, but the committed `uv.lock` still records `instro` as the only dependency of `instro-unstable`, causing the repository's `uv lock --check` job to fail and frozen environments to omit the package required by the new VNA modules.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "add tests" | Re-trigger Greptile}

[semgrep-code-nominal-io]

Legal Risk

The following dependencies were released under a license that
is currently prohibited by your organization. Merging is blocked until this is resolved.

Recommendation

Reach out to your security team or Semgrep admin to address this issue. In special cases, exceptions may be made for dependencies with violating licenses, however, the general recommendation is to avoid using a dependency under such a license

non-standard

• scipy 1.15.3
• scikit-rf 2.1.0

[semgrep-code-nominal-io]

Legal Risk

scipy 1.18.1 was released under the non-standard license, a license that
is currently prohibited by your organization. Merging is blocked until this is resolved.

Recommendation

Reach out to your security team or Semgrep admin to address this issue. In special cases, exceptions may be made for dependencies with violating licenses, however, the general recommendation is to avoid using a dependency under such a license.