开云体育

Hi Herb
You wrote
3. I ran a SOLT calibration on the V2 using NanoVNA-QT and the through calibration was spot on (see attachments).

Indeed I have same sort of trace, but the thru calibration is ideal and even when using touchstone files for thru with insertion loss and delay. There is no reflection to delay or insertion loss by the NanoVNA-QT.
So button line what ever you use for thru adaptor (even a rusty nail) it will provide this result for NanoVNA-QT. Thus S21/S12 measurements are a bit off by insertion loss (not a serious problem) and for delay by the thru adaptor delay and the phase sync between S11 and S21 are lost.
Gabriel have promised to look into the code. NanoVNA-saver does not suffer from these limitations.
Else it works great see attached responses for a WiFi channel filter measured from 100KHz to 3.5GHz imported as a S2p file generated by NanoVNA-QT to NAnoVNA-saver and from 2.3 to 3.5GHz where the calibration runs less than 1 dB outside the Smith chart. For the wide sweep it stays inside the Smith chart up to 3GHz.
I used two Sucoflex 100 SMA male to N male test cables of 2 meter each, and calibrated by Touchstone files for the HP85032B N kit.
Kind regards
Kurt

-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af hwalker
Sendt: 19. april 2020 18:31
Til: [email protected]
Emne: Re: [nanovna-users] NanoVNA-V2 from Tindie

Holger Müller wrote:
I've figured out, that the USB driver of S-A-A-2 delivers an incompatible hwid for pySerial on Windows. If fixed it in my branch.

.....The CH2 through calibration never normalizes (zero out) after applying an SOLT calibration, however; the CH1 SOL calibration is fine. Have you encountered this issue on your Linux set-up when using the S-A-A-2? ....

I'll try it out soon, but I think I've seen that someone complains the same issue with NanoVNA-QT.. can you confirm this?
=====================================================

Holger,
I have most of the NanoVNA variants and was able do some beta testing of your nanovna-v2 branch using each:

1. Your fix for the blank VID/PID returned by the V2 using pyserial on the Windows OS worked on my Windows 10 x64 set-up. The NanoVNA-Saver V2 branch now auto-detects the V2, -H, -H4, and -F under Windows 10.

2. I ran a SOLT calibration on the V2, H4 and -F using the NanoVNA-Saver V2 branch and the through calibration was off for the V2 and -F, but was zero for the -H4 (see attachments). I haven't checked Rune's release version to see if the same difference occurs between the -F and -H4.

3. I ran a SOLT calibration on the V2 using NanoVNA-QT and the through calibration was spot on (see attachments).

4. I tried your screenshot module for the -H4 and was surprised to find that, other than the color mapping being off on my captured image, it worked fine. I had been stumped by NanoVNA-F returning 4 small images instead of one and asked the NanoVNA-F designer about it. He said that it was a hardware problem that has been corrected in the current version but would require a hardware fix on versions prior to 2.3. I let him know that you had figured out a software solution for unpacking the four images that would probably make its way into Rune's next release.

5. The screenshot module for the -H4 does not work in the NanoVNA-Saver V2 branch. Gyula Molnar previously commented that screenwidth and screenheight constants are incorrect for the -H4. I think the " getScreenshot" function may also need to be overrode in the H4 class as you did for the -F.

Thanks for allowing us the opportunity to beta test the NanoVNA-Saver V2 branch. BTW I noticed that above 1 GHz, the thru calibration for Erik's TAPR application for the V2 also deviates from zero.

- Herb