NanoVNA screenshot capture broken/dotted on 480x320 screen variants

[K4HEZ]

Problem

Screenshots captured via "Screenshot from AA" for devices reporting as model NanoVNA come out with all fine detail (on-screen text, dotted grid lines) broken up into scattered dots/noise, while large solid-color plot elements (trace lines, divider bars) stay roughly recognizable. The physical device's own LCD shows the correct image, confirming the corruption is introduced by AntScopeZ's capture/decode path, not the device.

Root cause

NanovnaAnalyzer::CAPTURE_WIDTH/CAPTURE_HEIGHT (analyzer/nanovna_analyzer.h) and the matching AnalyzerParameters entry for NanoVNA (analyzer/analyzerparameters.h) hardcoded 320x240, per NanoVNASaver's documented classic NanoVNA/NanoVNA-H screen size. The affected hardware here (an H4-class NanoVNA variant) actually has a 480x320 screen.

Confirmed by enabling the app's built-in NanoVNA Debug Logging (Settings > Analyzer) and capturing a capture command response: the raw payload was exactly 307200 bytes -- 480*320*2, not the assumed 320*240*2 = 153600. NanovnaAnalyzer::parseCapture() was slicing off only the first half of every frame and treating it as the complete image; Screenshot::on_newData()'s NanoVNA branch then reshaped that truncated data against the wrong 320-pixel row stride, misplacing pixels row by row. Long solid-color runs (thick trace lines, divider bars) survived the resulting misalignment more or less intact; small multi-row detail (text glyphs, thin dotted grid lines) did not -- which is what produced the "broken into dots" look while the overall plot shape stayed recognizable.

Per-pixel RGB565 decode (byte order, channel bit layout) was independently verified correct against the raw log (e.g. FF E0 decodes to pure yellow, matching the device's trace color) -- this was purely a frame-size/stride bug, not a color-decode bug.

Fix

Updated CAPTURE_WIDTH/CAPTURE_HEIGHT to 480/320 and the NanoVNA AnalyzerParameters entry to match.

Caveat / follow-up

The app has no live capability query to distinguish NanoVNA hardware variants by actual screen size -- NanoVNA is treated as a single fixed resolution. If a classic 320x240 NanoVNA/NanoVNA-H ever needs to be supported alongside 480x320 units, this'll need to become per-device (e.g. a separate model entry, or detected at connect time) rather than a fixed constant.

[K4HEZ]

Follow-up (commit 842c390): NanovnaAnalyzer::parseCapture() now resolves the capture width/height from the active Custom Analyzer profile (Settings > Analyzer) when CustomAnalyzer::customized() is set, falling back to the 480x320 default from this issue otherwise. This closes the gap noted above -- the Custom Analyzer LCD width/height already overrode the Screenshot dialog's own sizing, but the protocol-level byte count pulled off the serial stream was still hardcoded and deaf to it.

To support a NanoVNA variant with a different screen size, define a Custom Analyzer profile with prototype NanoVNA and that unit's actual LCD width/height.

[K4HEZ]

Fixed -- confirmed CAPTURE_WIDTH/CAPTURE_HEIGHT are 480/320 in analyzer/nanovna_analyzer.h, matching the AnalyzerParameters NanoVNA entry. Verified against real hardware per the writeup above. The auto-detection follow-up for classic 320x240 units was researched separately and declined (no such hardware on hand to support/test against) -- the Custom Analyzer profile is the documented path if that's ever needed.