Hello,

I'd like to ask confirmation that the NanoVNA firmware does not implement the "Enhnanced Response" for T/R VNAs (es described by Agilent and others) when it calculates the receive port tracking error coefficient (during calibration with thru) and then that it does not use the same enhanced scheme during calculation of S21 DUT coefficient. This scheme is referred (but not fully explained) in "https://www.keysight.com/upload/cmc_upload/All/BTB_Network_2005-1.pdf" at slide 62 and following.

I've tested this scheme in excel and the reduction in mesurement uncertainties (reduction of S21 oscillations) is sensible from 1.5 GHz on.

I think that it should be quite easy to integrate in NanoVNA FW the "Enhanced Response" calculation and it should also be possible to integrate the same scheme in NanoVNA-QT (including the more complex handling of calibrations with non-ideal thrus).

Best Regards, Marco.

Right now it's just a simple response calibration. I'll see if I can implement enhanced response.

This is a good proposal.

I must admit that I frequently use use the SAA2 all the way up to 4.4 GHz even though it gets a bit noisy and
the uncertaincy probably increases.

When here. How do you in the best way give proposals for improvement for SAA2 and the NanoVNA-QT Software ?

What I lack the most is in the NanoVNA-QT:
1. Calibration delay coefficients for SOLT that are put there and saved between sessions and deembedded. (Touchstone does not seem to work and it's the wrong way around
as you have to do a calibration to be able to use them...)
2. The Scaling of Y-axes. You can just scale one of the two axes. (The whole user interface could be a lot smoother, easier to use)
3. Beeing able to save Referenses. It is very common to do a mesurement, do some changes do a new measurement and then compare.
At the moment you have to export Touchstone files and compare in another program.

There is a lot more to say but I leave that for now.

But in general this is a fantastic product !!!

)) Best regards, Per

You can open a github issue on the nanovna-qt repository. (2) and (3)
are known problems with the current UI design, so I'm most likely going
to rework the UI and also add proper marker support like in
nanovna-saver. For (1) you can try Calibration > Fine tune.

Hello,

For the implementation of Enanced Response in NanoVNA FW, this should be quite easy since the NanoVNA only supports ideal thru. In this case the maths is the following: during calibration of thru, save both S11mt and S21mt, the S11 "m"easured with t"hru on port 1 (reflection ratio) and S21 "m"easured with "t"hru on port 2 (forward ratio). Then calculate the port 2 tracking error (e10e32) as:

e10e32 = S21mt * (e10e01 / (S11mt * e11 + e10e01 - e11 * e00))

being the values:
e10e01 the backward tracking error on port 1
e11 the port 1 match error
e00 the port 1 directivity error
(above three errors were previously calculated with the open/load/short measurements).

I guess you now just use e10e32 = S21mt

During the measurements of DUTs, you have just to use:

S21 = S21m * (1- S11 * e11) / e10e32

being
S21m the forward ratio measured
S11 the DUT S11 just calculated as usual with Port 1 S11m measurement and Port 1 error model
e11 and e10e32 as calculated above during calibration

The terminology above is similar to the Agilent VNA error model description.

For the NanoVNA-QT, formula for e10e32 is a bit more complicated since you need to use also the thru S parameters (in case the thru model is provided).

I'll describe such formulas in a following mail.

Best regards, Marco.

On Sun, Sep 6, 2020 at 12:41 PM, OwO wrote:

>
> You can open a github issue on the nanovna-qt repository. (2) and (3) are
> known problems with the current UI design, so I'm most likely going to
> rework the UI and also add proper marker support like in nanovna-saver.
> For (1) you can try Calibration > Fine tune.

Thank you for the answers !
As for the Calibration. What I try to say is that it would be a lot better if the Parameters for the SOLT-Kit were calculated for and included in a saved Calibration.
(There might be others that are of a different opinion :)
As it is now, yes you can fine tune, but the Software never remembers this so every time you start the program you have to redo this, and when not inlcluded
in the calibration calculations you don't get a flat phase respons if fine tuned. It is nice to be able to put e.g. your Short in place and see that it looks good.
I will work this through and put it on GigHub.

)) Best regards, Per

Hello all,

I'd like to share with the group the explaination of the formula given above for the "Enhanced Response" and the formula to be used in case the thru is not ideal (NanoVNA-QT case).

First let's start with a common reference error model to describe the Forward VNA configuration (see the attachment 1). Just forget about e30 (isolation error) that is not used and will be considered zero for this discussion).

A T/R VNA (one TX port with reflection bridge and one RX-only port) makes only two measurements per frequency: *b0/a0* (we can call it S11m or "raw S11") and *b3/a0* (S21m or "raw S21"). Even knowing all the VNA error coefficients (e00, e11, etc.), the T/R VNA cannot solve, with only *two* measurements, the *four* S DUT unknown parameters. An assumption shall be made here and the most used one is to put *e22=0* (i.e. neglet port 2 mismatch). In this way the node a2 becomes zero and DUT S12 and S22 becomes irrelevant for the solution: the T/R VNA can now use the two measurements to solve for the only two remaining unknowns S11 and S21.

During the T/R VNA calibration, you initially use the three Short/Open/Load measurements to solve for *e00* , *e11* and *e10e01* errors of the port 1 model (solving a system with three measurements and three unknowns). Then you put on the thru and if you just apply the same assumption to have e22=0, the value of the last needed unknown error coefficient *e10e32* is simply S21m (as I guess the NanoVNA does now).

But in reality, when you perform the thru measurement the S parameters of this "DUT" are all known (both for ideal or not ideal thrus) then you actually have two measurements (S21m and S11m) and exactly two unknowns (e10e32 and e22). You do not need to make the assumption that e22=0 since the system with two measurements and two unknowns is exactly solvable. If you try to solve this network system with an ideal thru and without zeroing the e22 coefficient you should easily obtain the formula for e10e32 given in my previous mail. This tracking coeeficient does not include any error coming from the e22=0 assumption and then it reduces considerably errors in the subsequent measurements of DUTs performed with this calibration.

The thru calibration network can be exactly solved for e10e32 also in case of non-ideal thru with a bit more maths. If you do that you should obtain the following formulas (please, try to check them because I did not test them so I'm not 100% sure):

Being:
S11, S12, S21 and S22 the known thru S coefficients
e00, e11, e10e01 the error coefficients of port 1, calculated in advance with SOL measurements
S11mt and S21mt the raw measurements, obtained during calibration with thru (b0/a0 and b3/a0)

Calculates:
Dt = S11 * S22 - S21 * S12
De = e00 * e11 - e10e01
e22 = (S11mt * S11 * e11 - S11mt + e00 - S11 * De) / (S11mt * e11 * Dt - S11mt * S22 + S22 * e00 - Dt * De)
*e10e32* = S21mt * (1 - S11 * e11 - S22 * e22 + e11 * e22 * Dt) / S21

Of course, if you use S11=S22=0 and S21=S12=1 (ideal thru), you obtain the simple formula given in the previous mail.

If you need any additional detail or if you spot any error, please just ask.

Hope this is useful.

Best regards to all, Marco.

Hello Marco,
only a question concerning the s22. The assumption s22=0 is not valid, as far as measuring of the matching of the port 1 (receiving)  above 2GHz is not perfect (see the attached picture). Both are after SOL calibration of the s11. I it is a question, if there are place for hardware improvement of the matching of the s21 port.

Hello ok1vaw,

a *full 2 ports VNA* makes *four* measurements per frequency (2 in forward and 2 in reverse direction) so it is able to solve for all *four* unknowns S parameters of any DUT. A *T/R VNA* is simpler and makes only *two* measurements (in forward direction only, i.e. port 1 is always the TX port and port 2 is always the RX port and they never swap their TX/RX role) and then the *four* unknown S parameters of a generic DUT are unsolvable. One assumption must be done to measure an *unknown DUT* and the assumption made is *e22=0* (i.e the VNA RX port mismatch is neglected): this turns the unsolvable problem in a solvable system of two equations. This is exacly the assumption currently done by NanoVNA V2 and all other T/R VNA. This is the little price to pay for this (nice) kind of simpler instruments.

The Enhanced Response approach just removes this assumption during the THRU calibration measurement since during that initial measurement the *DUT is known*.

Note that your NanoVNA RX port Return Loss appears much better than mine... I must have a very bad clone...

Best Regards, Marco.

Yes, only a full two port VNA is able to correct for port 2 match error.
I think I talked about this before on nanovna-users, you have to know
the S12 of the DUT to know how reflected signals from port 2 of the VNA
will affect measurements. However, if you do two measurements, one with
the DUT reversed, it is possible to calibrate out port 2 match error,
this is called two port one path calibration I think in scikit-rf.

Hello OwO,

very good advice: on scikit-rf site, all is explained much better than what I tried to do...

In fact, in " https://scikit-rf.readthedocs.io/en/latest/examples/metrology/TwoPortOnePath,%20EnhancedResponse,%20and%20FakeFlip.html " is well explained that a T/R VNA can be calibrated and then used mainly in three forms:

* *EnhancedResponse* : no assumption on DUT, only S11 and S21 can be calculated, VNA RX port (port 2) mismatch is neglected during measurement, but it is not neglected during calibration. This approach is always valid, but some errors occurs due to the neglected mismatch of port 2. This strategy could be seamlessy implemented in NanoVNA FW and NanoVNA-QT SW with minimal effort.
* *FakeFlip* : the DUT is assumed symmetric and reciprocal (S11=S22, S21=S12). All DUT S parametes (reduced by the assumption to only two unknowns) can be then calculated with only two measurements done by T/R VNA. RX port mismatch is corrected in both measurement and calibration. This aprroach is very good but is only valid for "symmetric/reciprocal" DUT (like cables, some attenuators, etc.). It could be a nice "Push Button" e.g. in NanoVNA-QT SW just saying "Hej, I know this DUT is symmetric: apply FakeFlip approach!".
* *TwoPortOnePath* : no assumption on DUT, two independent measurements performed with same DUT mounted first in normal and then in reverted direction (the operator swaps the DUT ports between the two VNA measurements), all 4 DUT S parameters can be now calculated with 2x2 VNA measurements, VNA RX port (port 2) mismatch is corrected in both measurement and calibration. This option is perfect but implies a double work for the operator and is not usable in real-time but only in post-processing. I think post processing is not a task for NanoVNA FW or NanoVNA-QT SW, but I'd like to be able to save on file the raw data of calibration and DUT measurements to simplify post-processing.

Note that the simplified calibration and measurement strategy currently implemented in NanoVNA FW and NanoVNA-QT SW is not taken into consideration by scikit-rf since with just a more precise formula and with exactly the same measurement/calibration raw data, the EnhancedResponse gives just better results.

Best Regards, Marco.

Enhanced response is now implemented in 20200916. See attached for
comparison (DUT is a very small capacitance between the 2 ports).

enhanced response or smoothing??

for higher resolution i use scaling ... so what does this function do??

dg9bfc sigi

Am 16.09.2020 um 13:57 schrieb OwO:

> Enhanced response is now implemented in 20200916. See attached for
> comparison (DUT is a very small capacitance between the 2 ports).
>
>
>
>

It uses a more accurate calibration algorithm for transmission measurements, partially correcting for port mismatch error (full correction is not possible because the NanoVNA cannot measure S12 and S22).

On Wed, Sep 16, 2020 at 04:54 PM, Siegfried Jackstien wrote:

>
> enhanced response or smoothing??
>
> for higher resolution i use scaling ... so what does this function do??
>
> dg9bfc sigi
>
> Am 16.09.2020 um 13:57 schrieb OwO:
>
>> Enhanced response is now implemented in 20200916. See attached for
>> comparison (DUT is a very small capacitance between the 2 ports).
>>
>>
>>
>>
>
>

Where can I find this firmware?

I checked under the nanovna2 group wiki and file directory and did not find a link.

Appreciate your work.

Mike N2MS

> On 09/16/2020 9:57 AM OwO <owowowowo123@outlook.com> wrote:
>
>
> Enhanced response is now implemented in 20200916. See attached for
> comparison (DUT is a very small capacitance between the 2 ports).
>
>
>

Here it is
https://github.com/nanovna/NanoVNA-V2-firmware/releases
Kind regards
Kurt

On Wed, Sep 16, 2020 at 08:09 AM, n2msqrp wrote:

>
> Where can I find this firmware?
>
> I checked under the nanovna2 group wiki and file directory and did not
> find a link.
>
>

https://github.com/nanovna/NanoVNA-V2-firmware/releases

- Herb

On Wed, Sep 16, 2020 at 06:58 AM, OwO wrote:

>
> Enhanced response is now implemented in 20200916.

The new Stimulus->ADF4350 TX POWER menu is also appreciated.

- Herb

Hello,

I've to say that my NanoVNA V2 (actually a clone) sadly died today while updating to latest FW... NanoVNA-QT stopped the updating process at 3 KB... Now just a white screen and no way to do anything else (even shorting S301 at power on).

Unfortunately I will not be able to contribute to this group for a while due to lack of "testing platform" (even if I've a lot of data saved from NanoVNA measurements in the last weeks and maybe I can use them for some testing).

I definitely enjoied this little intrument that was for me mainly a good excuse to study and explore in deep the interesting topic of the VNAs. I'll see if I will buy a new one to continue to play with it.

Best Regards, Marco.

Kurt,



Thanks!



Mike N2Ms

> On 09/16/2020 11:30 AM Kurt Poulsen <
[kurt@hamcom.dk](mailto:kurt@hamcom.dk)> wrote:

>

>
>

>

>
>

>

> Here it is

>

> <https://github.com/nanovna/NanoVNA-V2-firmware/releases>

>

> Kind regards

>

> Kurt

>

> \

Marco,

have you tried holding the left button on power on to enter DFU mode?

If this doesn't work, you will probably need an SWD programmer to reflash. If you don't have one there are lots of cheap options, like Discovery/NUCLEO board, ST-Link (clone), J-Link edu mini. I don't think S301 will help, the microcontroller used doesn't seem to have USB support in the ROM bootloader.

On Wed, Sep 16, 2020 at 09:11 PM, mce66 wrote:

>
> Hello,
>
> I've to say that my NanoVNA V2 (actually a clone) sadly died today while
> updating to latest FW... NanoVNA-QT stopped the updating process at 3
> KB... Now just a white screen and no way to do anything else (even
> shorting S301 at power on).
>
> Unfortunately I will not be able to contribute to this group for a while
> due to lack of "testing platform" (even if I've a lot of data saved from
> NanoVNA measurements in the last weeks and maybe I can use them for some
> testing).
>
> I definitely enjoied this little intrument that was for me mainly a good
> excuse to study and explore in deep the interesting topic of the VNAs.
> I'll see if I will buy a new one to continue to play with it.
>
> Best Regards, Marco.

On Wed, Sep 16, 2020 at 06:58 AM, OwO wrote:

>
> Enhanced response is now implemented in 20200916.

Has anyone else experienced an ~2dB low s21 reading when using v20200916 versus v20200909?  My configuration is Tindie v2_2 with 4"display added.  This is after a regular SOLT calibration.  I haven't tried the enhanced response calibration yet.

The results are for two different attenuators measured before and after updating.  The straight through calibration looks good.

- Herb

Hello @switchabl,

left button does not work. For SWD reprogramming, do you mean an object like THIS ( https://www.amazon.it/ICQUANZX-Programmazione-ST-Link-Emulator-Downloader/dp/B07YX83NSL/ref=pd_sbs_107_1/257-0262107-5050819?_encoding=UTF8&pd_rd_i=B07YX83NSL&pd_rd_r=bf5eac56-66cc-45ba-b76e-b8ec2dc0fa2b&pd_rd_w=SsgQr&pd_rd_wg=bBsQ1&pf_rd_p=85d7fa16-9140-48a8-92c7-6a88c9b2bb49&pf_rd_r=F1SWE4C5GAGT60T0VYXV&psc=1&refRID=F1SWE4C5GAGT60T0VYXV ) ? Is it a compex process? I guess I'll have to solder 3/4 wires (GND, SWDIO, SWCLK, NRST(?)), then install some SW (which?) on my PC to reprogram the Nano, and then ... ???

Best regards, Marco.

Hi Gabriel
I have update to the 16092020 version and tried to se if the added enhanced function did cure the one dB step error I have reported previously.
I have made a video in uncalibrated mode showing exactly what is going on and I hope you or someone else can fix this bug.
It is independent if I calibrate thru or not and the enhanced function has no impact either. Changing the power level now possible does only change the level slightly at which the toggling is taking place.
The video is at
http://www.hamcom.dk/SAA-2N/00190.MTS
Kind regards
Kurt

Marco,

if the left button doesn't work (NOTE: there is no indication on the screen, it stays white, but normally after power on with left button pressed you should be able to reflash with NanoVNA-QT), there is definitely something wrong. Reprogramming the boot loader MIGHT help. I don't know the particular device you linked, but it should do the job. I tried with the ST-Link on a Discovery board and I think that is more or less the same.

Yes, you connect GND, SWDIO, SWCLK and optionally NRST. I'd probably prefer soldering a pin header, but of course soldering the wires is fine.
This is the software you want: https://github.com/stlink-org/stlink/releases/tag/v1.6.1
(on Windows you may need the STM drivers as well: https://www.st.com/en/development-tools/stsw-link009.html )
The bootloader is here: https://raw.githubusercontent.com/nanovna/NanoVNA-V2-firmware/master/bootloader/binary.hex
Check if the programmer and the chip is recognized with
>
> st-info.exe --probe

Flash with
>
> st-flash.exe --reset --format ihex write binary.hex

After that hopefully the left button works and you can flash the firmware normally. HOWEVER, the USB firmware update shouldn't touch the boot loader at all, so even if the update fails it shouldn't brick the device. So something else may be wrong.

On Wed, Sep 16, 2020 at 11:16 PM, mce66 wrote:

>
> Hello @switchabl,
>
> left button does not work. For SWD reprogramming, do you mean an object
> like THIS (
> https://www.amazon.it/ICQUANZX-Programmazione-ST-Link-Emulator-Downloader/dp/B07YX83NSL/ref=pd_sbs_107_1/257-0262107-5050819?_encoding=UTF8&pd_rd_i=B07YX83NSL&pd_rd_r=bf5eac56-66cc-45ba-b76e-b8ec2dc0fa2b&pd_rd_w=SsgQr&pd_rd_wg=bBsQ1&pf_rd_p=85d7fa16-9140-48a8-92c7-6a88c9b2bb49&pf_rd_r=F1SWE4C5GAGT60T0VYXV&psc=1&refRID=F1SWE4C5GAGT60T0VYXV
> ) ? Is it a compex process? I guess I'll have to solder 3/4 wires (GND,
> SWDIO, SWCLK, NRST(?)), then install some SW (which?) on my PC to
> reprogram the Nano, and then ... ???
>
> Best regards, Marco.

Maybe he tried right button?? Some users prefer connectors up... Flip
display... And then you have to press the right button instead of left...

Dg9bfc sigi



Am 18.09.2020 00:57 schrieb switchabl@mailbox.org:

> Marco,
>
> if the left button doesn't work (NOTE: there is no indication on the screen,
it stays white, but normally after power on with left button pressed you
should be able to reflash with NanoVNA-QT), there is definitely something
wrong. Reprogramming the boot loader MIGHT help. I don't know the particular
device you linked, but it should do the job. I tried with the ST-Link on a
Discovery board and I think that is more or less the same.
>
> Yes, you connect GND, SWDIO, SWCLK and optionally NRST. I'd probably prefer
soldering a pin header, but of course soldering the wires is fine.
> This is the software you want: <https://github.com/stlink-
org/stlink/releases/tag/v1.6.1>
> (on Windows you may need the STM drivers as well:
<https://www.st.com/en/development-tools/stsw-link009.html>)
> The bootloader is here:
<https://raw.githubusercontent.com/nanovna/NanoVNA-V2-firmware/master/bootloader/binary.hex>
> Check if the programmer and the chip is recognized with

>

>> st-info.exe --probe

>

> Flash with

>

>> st-flash.exe --reset --format ihex write binary.hex

>

> After that hopefully the left button works and you can flash the firmware
normally. HOWEVER, the USB firmware update shouldn't touch the boot loader at
all, so even if the update fails it shouldn't brick the device. So something
else may be wrong.
>
> On Wed, Sep 16, 2020 at 11:16 PM, mce66 wrote:
>

>

>> Hello @switchabl,
>
> left button does not work. For SWD reprogramming, do you mean an object like
[THIS](https://www.amazon.it/ICQUANZX-Programmazione-ST-Link-Emulator-
Downloader/dp/B07YX83NSL/ref=pd_sbs_107_1/257-0262107-5050819?_encoding=UTF8&pd_rd_i=B07YX83NSL&pd_rd_r=bf5eac56-66cc-45ba-b76e-b8ec2dc0fa2b&pd_rd_w=SsgQr&pd_rd_wg=bBsQ1&pf_rd_p=85d7fa16-9140-48a8-92c7-6a88c9b2bb49&pf_rd_r=F1SWE4C5GAGT60T0VYXV&psc=1&refRID=F1SWE4C5GAGT60T0VYXV)?
Is it a compex process? I guess I'll have to solder 3/4 wires (GND, SWDIO,
SWCLK, NRST(?)), then install some SW (which?) on my PC to reprogram the Nano,
and then ... ???
>
> Best regards, Marco.



_._,_._,_

* * *

Many thanks to the group. At the end, it was a false contact (of my bad NanoVNA clone) that prevented the pushed left or right button to arrive to the CPU. I shorted to ground directly the cpu pin 22 during power-on and the bootloader entered DFU mode. I could then re-flash latest FW and the Nano came back alive and kicking... Good good good.

OK. Now, back to the topic: Enhanced Response.

I had the chance to explore the FW source code and actually I found the implementation of the formula to be used during the S21 Measurement "S21 = S21m * (1- S11 * e11) / e10e32". Unfortunately I did not find the formula and the logic to be applied for the Enanced Response during the calibration of THRU "e10e32 = S21mt * (e10e01 / (S11mt * e11 + e10e01 - e11 * e00))". This means the new FW seems to implement a partial Enhance Response (calculation of S21 is OK but calculation of RX port tracking error e10e32 is still simplified). This is finally confirmed by the measurement I just performed with latest FW: a 10 dB attenuator still presents a quite large ripple (up to +/- 0.5 dB) on the S21 measure.

I also understand reading the code that Nano FW does not memorize S11 during thru calibration so I believe that implementing the full Enhance response may be more difficult than I thought. Anyway, I'd like to show the improvement in measured S21 that can be obtained, just to let you verify if this additional improvement worths the effort.

Fist of all: my HW is bad and is about at the limit of the Nano V2 spec (it has about 13 dB TX port return loss and 13 dB RX port return loss, both peaking around 2.5 GHz and then they improve up to about 15/16 dB at 3.5 GHz), so my measurements can represent *the worst case*.

The first figure attached is the S21 of a 10 dB attenuator rated 6 GHz used here to show the case of a pretty large attenuation DUT, quite well matched. The RED curve is the original Nano response and you can see the ripple +/- 0.6 dB that maximise at 2.5 GHz. The ORANGE curve is the partial enhanced response implemented in latest FW and the ripple is about +/- 0.5 dB (a small improvement). Finally the GREEN curve represents the measure if the full Enhanced Response would be applied to the raw measured data. The ripple would reduce to +/- 0.05 dB. The second figure is the S21 of a 3 dB (non resistive) splitter rated 690-3000 MHz to test a low attenuation DUT, medium matched. Also in this case the RED/ORANGE/GREEN curves show the advantage of the full enhanced response. Ripple is very similar to previous figures: +/- 0.6 dB, +/- 0.5 dB and finally +/- 0.1 dB for full enhance response.

I also attach the excel with all raw data and formulas (columns B-K are the raw *calibration* measurements, columns M-P are the raw *DUT* measurements). First TAB is the attenuator, second the splitter. The excel shows also the errors coefficients of my Nano VNA (e00=Directivity, e11=TX match, e10e01=TX tracking, e10e32=RX tracking and e22=RX match). It also shows the difference of *e10e32* calculated in the current FW and the one calculated with the Enhanced Response formula: it is clear that this coefficient in current implementation contains the large part of the ripple that is then added to all subsequent S21 measurements.

Just for fun, excel third tab is the application of FakeFlip formulas to the attenuator raw data (big improvement of S11 measurement here) and last TAB is the TwoPortOnePath on two measurements of splitter raw data (Forward/Reverse measures): again, big improvement of S11 *and S22*. These last two tabs maybe worth a different topic on this discussion group.

I remain available to give any additional detail or to correct any error that may be present.

Best regards and thanks again to all. Marco.

Thank you!

FW 20200926 seems to implement the Full Enhanced Response. I quickly tested it and seems to work exactly as expected. Very good!

Now I hope also NanoVNA QT will be improved and will implement Enhanced Response...

Best regards, Marco.

Looks like NanoVNA QT didn't get the Enhanced Response yet.. On GitHub I see that there's source code modifications (looks like Python) to update NanoVNA-Saver (issue #349):

https://github.com/NanoVNA-Saver/nanovna-saver/issues/349

I might have to figure out how to compile it to try it out (never installed or compiled Python before so perhaps a frustrating learning opportunity beckons!)

On 5/6/21 3:43 PM, martin.thornber@gmail.com wrote:
> Looks like NanoVNA QT didn't get the Enhanced Response yet.. On GitHub
> I see that there's source code modifications (looks like Python) to
> update NanoVNA-Saver (issue #349):
>
> https://github.com/NanoVNA-Saver/nanovna-saver/issues/349
> <https://github.com/NanoVNA-Saver/nanovna-saver/issues/349>
>
> I might have to figure out how to compile it to try it out (never
> installed or compiled Python before so perhaps a frustrating learning
> opportunity beckons!)
> _.



No compiling - Python is interpreted. Bring the new file in, and run
NanoVNA-Saver.py

Just clone this branch and run it:
https://github.com/galileo-pkm/nanovna-saver/tree/PA0JOZ

On Fri, 7 May 2021 at 00:43, <martin.thornber@gmail.com> wrote:

> Looks like NanoVNA QT didn't get the Enhanced Response yet.. On GitHub I
> see that there's source code modifications (looks like Python) to update
> NanoVNA-Saver (issue #349):
>
> https://github.com/NanoVNA-Saver/nanovna-saver/issues/349
>
> I might have to figure out how to compile it to try it out (never
> installed or compiled Python before so perhaps a frustrating learning
> opportunity beckons!)
>
>
>

On Fri, May 7, 2021 at 12:56 AM, Dragan Milivojevic wrote:

>
> Just clone this branch and run it: https://github.com/galileo-pkm/nanovna-saver/tree/PA0JOZ
>

Thanks, Yes I did that (well downloaded the 'zip' folder of all the files) and installed Python 3.7.7, but no go yet (when attempting to run NanoVNA-Saver.py) - I'll install a later version of Python and give that a go.

Ah, there is a readme file in the NanoSaver root directory that suggests I need some Python addons - maybe that is the problem..

scipy
cython
pyqt5
pyserial
numpy

Will investigate further!

On Thu, May 6, 2021 at 11:50 PM, Jim Lux wrote:

>
> No compiling - Python is interpreted. Bring the new file in, and run
> NanoVNA-Saver.py

I think the fact that the Windows version of NanoSaver I have runs from a single .exe file led me to think that..

On 5/7/21 12:30 AM, martin.thornber@gmail.com wrote:
> On Thu, May 6, 2021 at 11:50 PM, Jim Lux wrote:
>
> No compiling - Python is interpreted. Bring the new file in, and
> run NanoVNA-Saver.py
>
> I think the fact that the Windows version of NanoSaver I have runs
> from a single .exe file led me to think that..

I'm not sure then - I use Windows and MacOS, but I also do a lot of
python development, so I just downloaded the python version and use that.

Thanks - all sorted.

This is what I did for future non-python windows users like me - note, follow at your own risk!

Downloaded the GIThub files(selected button 'Code', downloaded project files & folders as zip file) for the unreleased but updated nanovna-saver code: https://github.com/galileo-pkm/nanovna-saver/tree/PA0JOZ
Unzipped the python program files into a new folder on my PC somewhere - but didn't have python so:
Installed latest Python 3.9.5 for Windows 10 in my case (must select or allow PATH changes at install otherwise cmd prompt can't find python or pip!). https://www.python.org/downloads/
Downloaded the following required python libraries - note, choose specific versions for python 3.9.5:

Cython: Cython-0.29.23-cp39-cp39-win_amd64.whl https://pypi.org/project/Cython/#files
numpy: numpy-1.20.2-cp39-cp39-win_amd64.whl https://pypi.org/project/numpy/#files
PyQt5: PyQt5-5.15.4-cp36.cp37.cp38.cp39-none-win_amd64.whl https://pypi.org/project/PyQt5/#files
pyserial: pyserial-3.5-py2.py3-none-any.whl https://pypi.org/project/pyserial/#files
scipy: scipy-1.6.3-cp39-cp39-win_amd64.whl https://pypi.org/project/scipy/#files

Saved them to a new directory.

If you download the wrong .whl version (I did scipy cp38 by mistake), it won't work with the pip command!

Then at windows command prompt, for each file above, I typed in 'pip install F:\python_whl\Cython-0.29.23-cp39-cp39-win_amd64.whl'  where 'python_whl' is folder where I saved the .whl files.
Python's pip program should acknowledge each library as it is installed at the command prompt. Then closed the cmd prompt window.

Then all being well, python & required libraries are all installed. If you go to where the nanavna-saver files are and double click on 'nanovna-saver.py', the program should now start up as expected and be able to communicate to the NanoVNA

I can confirm that, as stated, this new un-issued version of Nanovna-saver gives much better s21 response (ie. looks at first glance same as on-screen with enhanced response activated on the device - no ripple on a filter's skirts for example).

On 5/7/21 6:40 AM, martin.thornber@gmail.com wrote:
> Thanks - all sorted.
>
> This is what I did for future non-python windows users like me - note,
> follow at your own risk!
>
> Downloaded the GIThub files(selected button 'Code', downloaded project
> files & folders as zip file) for the unreleased but updated
> nanovna-saver code:
> https://github.com/galileo-pkm/nanovna-saver/tree/PA0JOZ
> <https://github.com/galileo-pkm/nanovna-saver/tree/PA0JOZ>
> Unzipped the python program files into a new folder on my PC somewhere
> - but didn't have python so:
> Installed latest Python 3.9.5 for Windows 10 in my case (must select
> or allow PATH changes at install otherwise cmd prompt can't find
> python or pip!). https://www.python.org/downloads/
> <https://www.python.org/downloads/>
> Downloaded the following required python libraries - note, choose
> specific versions for python 3.9.5:
>
>   Cython: Cython-0.29.23-cp39-cp39-win_amd64.whl
> https://pypi.org/project/Cython/#files
> <https://pypi.org/project/Cython/#files>
>   numpy: numpy-1.20.2-cp39-cp39-win_amd64.whl
> https://pypi.org/project/numpy/#files
> <https://pypi.org/project/numpy/#files>
>   PyQt5: PyQt5-5.15.4-cp36.cp37.cp38.cp39-none-win_amd64.whl
> https://pypi.org/project/PyQt5/#files
> <https://pypi.org/project/PyQt5/#files>
>   pyserial: pyserial-3.5-py2.py3-none-any.whl
> https://pypi.org/project/pyserial/#files
> <https://pypi.org/project/pyserial/#files>
>   scipy: scipy-1.6.3-cp39-cp39-win_amd64.whl
> https://pypi.org/project/scipy/#files
> <https://pypi.org/project/scipy/#files>
>
> Saved them to a new directory.
>
> If you download the wrong .whl version (I did scipy cp38 by mistake),
> it won't work with the pip command!
>
> Then at windows command prompt, for each file above, I typed in 'pip
> install F:\python_whl\Cython-0.29.23-cp39-cp39-win_amd64.whl'  where
> 'python_whl' is folder where I saved the .whl files.
> Python's pip program should acknowledge each library as it is
> installed at the command prompt. Then closed the cmd prompt window.
>
> Then all being well, python & required libraries are all installed. If
> you go to where the nanavna-saver files are and double click on
> 'nanovna-saver.py', the program should now start up as expected and be
> able to communicate to the NanoVNA
>
> I can confirm that, as stated, this new un-issued version of
> Nanovna-saver gives much better s21 response (ie. looks at first
> glance same as on-screen with enhanced response activated on the
> device - no ripple on a filter's skirts for example).
> _

This long sequence of install this, install that is why I use Anaconda -
it takes care of the dependencies automatically in a python environment.
(well it also does more - I like Spyder as a python IDE, and Jupyter
notebooks are nice)

Windows is pain ...

If you find this feature useful, or if you find any bugs,
please leave a comment on the original issue,
this needs to be tested before the NanoVNA-Saver
maintainer includes it into the developer version.

On Fri, 7 May 2021 at 15:40, <martin.thornber@gmail.com> wrote:

> Thanks - all sorted.
>
> This is what I did for future non-python windows users like me - note,
> follow at your own risk!
>
> Downloaded the GIThub files(selected button 'Code', downloaded project
> files & folders as zip file) for the unreleased but updated nanovna-saver
> code: https://github.com/galileo-pkm/nanovna-saver/tree/PA0JOZ
> Unzipped the python program files into a new folder on my PC somewhere -
> but didn't have python so:
> Installed latest Python 3.9.5 for Windows 10 in my case (must select or
> allow PATH changes at install otherwise cmd prompt can't find python or
> pip!). https://www.python.org/downloads/
> Downloaded the following required python libraries - note, choose specific
> versions for python 3.9.5:
>
> Cython: Cython-0.29.23-cp39-cp39-win_amd64.whl
> https://pypi.org/project/Cython/#files
> numpy: numpy-1.20.2-cp39-cp39-win_amd64.whl
> https://pypi.org/project/numpy/#files
> PyQt5: PyQt5-5.15.4-cp36.cp37.cp38.cp39-none-win_amd64.whl
> https://pypi.org/project/PyQt5/#files
> pyserial: pyserial-3.5-py2.py3-none-any.whl
> https://pypi.org/project/pyserial/#files
> scipy: scipy-1.6.3-cp39-cp39-win_amd64.whl
> https://pypi.org/project/scipy/#files
>
> Saved them to a new directory.
>
> If you download the wrong .whl version (I did scipy cp38 by mistake), it
> won't work with the pip command!
>
> Then at windows command prompt, for each file above, I typed in 'pip
> install F:\python_whl\Cython-0.29.23-cp39-cp39-win_amd64.whl' where
> 'python_whl' is folder where I saved the .whl files.
> Python's pip program should acknowledge each library as it is installed at
> the command prompt. Then closed the cmd prompt window.
>
> Then all being well, python & required libraries are all installed. If you
> go to where the nanavna-saver files are and double click on
> 'nanovna-saver.py', the program should now start up as expected and be able
> to communicate to the NanoVNA
>
> I can confirm that, as stated, this new un-issued version of Nanovna-saver
> gives much better s21 response (ie. looks at first glance same as on-screen
> with enhanced response activated on the device - no ripple on a filter's
> skirts for example).
>
>
>

Ok a few plots with the official release version 0.3.8 vs. the unreleased version https://github.com/galileo-pkm/nanovna-saver/tree/PA0JOZ

Hardware - 2.8" V2 with metal case
Firmware - 20201013 (latest)

I did two identical solt cals using the 'calibration assistant' each time.

For each s/w version I took 3 screen grabs - first sweep after cal, then a 6dB attenuator then a high pass filter.

First, on this post the results of the official v0.3.8 s/w - lots of ripple on the cal and measurements of parts.

Then the same calibration but with the newer unreleased version.. ripple much reduced/gone. Same 3 plots - thru (first sweep after cal), 6dB attenuator and high pass filter.