NanoVNA-V2 from Tindie
|
On Fri, Apr 10, 2020 at 01:56 AM, Holger M¨¹ller wrote:
as I don't have a windows test system, can you try if the serial port behaves sane on windows without setting it to raw? I've patched my code not to use tty.setraw on windows. ===================================== Holger, Thanks for replying. With your patch the branched NanoVNA-Saver runs fine with a NanoVNA-H4 under Windows (see attachment). It cannot detect the NanoVNA-V2 under Windows (see attachment). For some reason the "getPort()" function always returns an empty tuple for the NanoVNA-V2. I believe it has something to do with the Cypress virtual serial driver on Windows. If I manually type in the comport number the program exits with the following exception: serial.serialutil.SerialException: Attempting to use a port that is not open. Hope the additional info helps. - Herb |
|
Hi Holger,
At 0.2.3, hardware identification and screen size are not correct at -H4. Hardware ERROR, unknow VNA type ... In 0.2.2 nanovna-saver it does not give an error message for identification. I found these discrepancies in Hardware.py: It does not belong to the above topic, but it is incorrect data. -- *** you can read more info on my website ( ) *** |
|
Holger,
Since the GetInterfaces() function (Not GetPorts() as I previously responded) does not detect the S-A-A-2 on my Windows system, I manually appended my comport to GetInterfaces() so I could test your branch of NanoVNA-Saver for the S-A-A-2: # Get list of interfaces with VNAs connected def get_interfaces() -> List[Tuple[str, str]]: return_ports = [] for d in list_ports.comports(): for t in DEVICETYPES: if d.vid == t.vid and d.pid == t.pid: port = d.device logger.info("Found %s (%04x %04x) on port %s", t.name, d.vid, d.pid, d.device) return_ports.append((port, port + " (" + t.name + ")")) return_ports.append(("COM8", "COM8" + " (" + "NanoVNA-V2" + ")")) return return_ports The branched NanoVNA-Saver then started up and I was able to connect to my S-A-A-2 and test a 46dB attenuator from 50 kHz - 1.5 GHz (see attachment). The S-A-A-2 does not transfer corrected data, so calibrating is no longer an option when used with NanoVNA-Saver for accurate measurement results. That can be seen in the 46 dB attenuator sweep I attached without first performing an in-program SOLT calibration. Your NanoVNA-V2 class should make it easier for Rune to port the S-A-A-2 into his future NanoVNA-Saver release after he receives his own S-A-A-2 and works out a few Windows related issues. Its good to verify that a familiar face will be available for S-A-A-2 owners who have previously grown to appreciate NanoVNA-Saver over the past year. Out of curiosity, what is the AVNA type in your branch? Regards, - Herb |
|
On Fri, Apr 10, 2020 at 01:56 AM, Holger M¨¹ller wrote:
" as I don't have a windows test system, can you try if the serial port behaves sane on windows without setting it to raw? I've patched my code not to use tty.setraw on windows. =============================================== Holger, As I previously commented, I was able to run your branch of NanoVNA-Saver for the S-A-A-2 on Windows 10 after you bypassed tty.setraw and I manually appended my comport to GetInterfaces(). I have encountered an issue on Windows when performing an SOLT calibration using your NanoVNA-Saver for the S-A-A-2 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 have attached a screen shot of a through sweep after an SOLT calibration was applied. - Herb |
|
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 |
|
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 |
|
Hi Herb
toggle quoted message
Show quoted text
Thank you for the info. I envy you guess which are capable on programming. Over many years I have bought books and developement kits and so on. I normally get stuck when reaching to the point I see "hello World" on the screen. ? My brain is hardware oriented. Indeed we owe Gabriel a lot of credit for this fantastic product. The NanoVNA -QT work also great for a full S11/S22/S21/S12 measurement by capture S*1. and swapping the DUT direction while capture s*2 and then exported to a S2p file. Both the s1p and s2p files are to import in NanoVNA saver as a measurement of a background so the limited scale settings for the NanoVNA-QT are easy to cope with. I will do some more test when done with some investigation of BNC adaptor as seen on the image. It is nice to have enough HP adaptors - the lasted purchase the HP11854A 50 ohm N to BNC kit ? Kind regards Kurt -----Oprindelig meddelelse----- Fra: [email protected] <[email protected]> P? vegne af hwalker Sendt: 20. april 2020 01:30 Til: [email protected] Emne: Re: [nanovna-users] NanoVNA-V2 from Tindie On Sun, Apr 19, 2020 at 02:28 PM, Kurt Poulsen wrote:
... 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 ... ========================================================================= Kurt, I've been very impressed with the stand-alone measurement capabilities of the S-A-A-2. Gabriel did a top-notch job in designing it. Just a year ago I wouldn't have expected a 3 GHz VNA with a display and USB control to be available for less than $100. Both S-A-A-2 production runs have sold out within a couple of weeks of being offered for sale. There have been a couple of firmware bugs that Gabriel has said she will address, but overall she hasn't made any major mis-steps. I sometimes entertain myself by writing small Python scripts to pull in data and manipulate it using the numpy library. My primary beef with the S-A-A-2 is you lose the display when you start communicating with it remotely. Not a problem with NanoVNA-QT or NanoVNA-Saver because of their graphical displays, but a major pain when you are writing scripts and just want to remotely change operational parameters without using a stylus or onscreen keyboard. My other minor beef is after you quit NanoVNA-QT or NanoVNA-Saver you have to cycle power on the S-A-A-2 to regain manual control of it. That seems a little wonky to me. Measuring 60 dB down on a 2.4 GHz filter surpasses my expectations for a sub $100 VNA or SNA. I've measured some 20 dB and 40 dB HP attenuators with the S-A-A-2 and they were spot on up to 3 GHz. The same attenuators measured using the NanoVNA-H4 and NanoVNA-F began to deviate around 1.3 GHz. I haven't tried importing any touchstone files created by the S-A-A-2 into NanoVNA-Saver. I've currently been beta testing Holger's branch of NanoVNA-Saver for the S-A-A-2 and have not been able to achieve a accurate through calibration. All other NanoVNA-Saver functions appear to be working as expected on my Windows 10 set-up. Holger works off of a Linux set-up so trying to trouble shoot any Windows related issues are problematic for him. Regards, - Herb |
Gyula Molnar
Kurt Poulsen
