I was looking around for nanovna-saver and found this https://github.com/zarath/nanovna-saver which almost worked. I think it was not reinitializing well when I also ran nanovna-qt and it had a strange printf bug on error so i made a couple of small changes and it seems to work just great. I also bumped the number of data points from 101 to 255 - which as far as I can tell is the maximum to easily implement.

in my opinion it's a bunch nicer than the QT application because you have way better charting controls and improved calibration. Anyway, including a zip. To run it unzip it anywhere and then in the nanovna-saver folder double-click the nanovna-saver.py file (or run it manually in python). There are some python requirements, listed in the requirements.txt.

Mark

Hi

I uploaded a V2 compatible nanoVNA-SAVER, with also H, H4 and F, with the addition of a "db offset" if you want to add resistor loss to measure balun loss and get the correct reading in the charts.

https://groups.io/g/NanoVNAV2/files/Computer%20Software/nanovna-saver%20db%20s21.zip

You still need to compile it.

On Fri, Jun 5, 2020 at 07:21 AM, MarkZ wrote:

I was looking around for nanovna-saver and found this https://github.com/zarath/nanovna-saver which almost worked. I think it was not reinitializing well when I also ran nanovna-qt and it had a strange printf bug on error so i made a couple of small changes and it seems to work just great. I also bumped the number of data points from 101 to 255 - which as far as I can tell is the maximum to easily implement.
============================
Mark,
Have you noticed that the SOL calibration works fine but the thru calibration never zero's properly when calibrating out to 2 GHZ or more? I'm talking almost 10 dB off at 2 GHZ for my through calibration.

- Herb

Hi Herb,

I'm using these mainly at 900MHz and for now not really using the through other than cable checking, which is kinda easy. I did try an experiment with 4 different calibrations. I calibrated 2 port and 1 port and then just measured the through standalone.

The first experiment used two not-great pieces of coax, one on each connector. The second used a good quality 1M of coax and just a barrel connector on port 1. I'm including the plots for all four...

It's pretty obvious which charts have through calibration since the S21 becomes flat. The first two are the coax on each side, the second two are the good coax on one side.

As usual, tightening the SMA connectors made a lot of difference in the measurements (I didn't include the 'not tight enough' charts) and that is something to make sure of while you test. I'm not a VNA expert but these look ok to me. I don't have any circuits to test the through with at this time but nothing obvious popped out to me.

Fwiw I've run this test all the way to 4GHz and it runs ok up to about 3.4GHz or so then really starts losing it. I'm sure not having a metal case doesn't help, and my environment is full of 2.4GHz wifi and bluetooth signals.

As far as the V2 support for nanovna-saver, the only change to the code is how to read the measurement data, so any calibration stuff should be the same for all devices. I'd have expected complaints from the nanovna owners long ago if the software couldn't calibrate. On the other hand, this code does have some new calibration stuff in it (the isolation calibration just showed up from somewhere...).

Regards,
Mark

On Sat, Jun 6, 2020 at 06:15 AM, MarkZ wrote:

The first experiment used two not-great pieces of coax, one on each connector. The second used a good quality 1M of coax and just a barrel connector on port
1. I'm including the plots for all four...
=========================================
Mark,
Thanks for replying. My thru calibration on the V2 itself is almost perfect, no problems at all.

When using the modified NanoVNA-Saver for the V2, the S21 sweep after the calibration wizard finishes (apply selected) looks like your first plot, but if immediately afterwards I run a s21 sweep on the same thru cable it looks similar to your second plot. For the same thru cable the s21 sweep should still be flat.

I've been trying to figure it out but haven't made any progress. The native NanoVNA-QT application doesn't have this issue on my V2.

- Herb

Hi Herb,

Hmmm, I tried this again with a 20dB attenuator (the one uhf non-coax i've got lying around) and it looked very good - plus I then ran sweep a dozen times and kept getting the same results. Image attached.

The two applications deal with calibration a bit differently. It may be that you need to manually click the Apply button? Also make sure the sweep settings are the same as when calibrated since there's no interpolation going on.

We seem to be doing the exact same tests and getting different answers so likely we're not really doing the same steps or using different programs. You are using the code I uploaded I hope?

Btw for this test I loaded the calibrations that I'd saved to do the earlier tests and applied them - i didn't run the calibrator wizard or anything...

Regards,
Mark

Mark,
Thanks again for taking the time to look. Are you running Linux or Windows? I'm beginning to believe, under Windows, the V2 version of NanoVNA-Saver doesn't like s21 measurements.

VNA-QT gives the same accurate s21 measurements that the V2 alone does. I use the Saver calibration wizard the same way with the V2 that I do with my -H4, which calibrates fine for s21 using Saver.

I'll stick with VNA-QT for s21 measurements for the time being. Yes, I am using your 255 point version (which makes collecting more points with less segments easier). And I always do "apply" after running the calibration wizard.

- Herb

This might seem silly but there's a timeout value that i had to bump up. If your system is slower than mine maybe it needs more time? On line 46 is this line:

self.serial.timeout = 6 # for this much data we need a longer timeout

maybe try a longer timeout? I'd think it's a function of the baud rate but who knows. GL

-Mark

On Sat, Jun 6, 2020 at 04:41 PM, MarkZ wrote:

This might seem silly but there's a timeout value that i had to bump up. If your system is slower than mine maybe it needs more time? On line 46 of nanovna_v2.py is this line:
>
> self.serial.timeout = 6 # for this much data we need a longer timeout
>
maybe try a longer timeout? I'd think it's a function of the baud rate but who knows. GL
======================================

Mark,
I submitted this s21 issue to Zarath when he first posted the V2 branch of NanoVNA-Saver and it was only 101 points back then, so I don't believe its a timeout problem. Zarath has a Linux operating environment so he couldn't confirm my s21 issues.

I also have a problem with the 255 point branch causing Python to hang when I use multiple segments with a large frequency span (i.e. 5 segments, 1 - 1000 MHz). That could possibly be a timing problem and I'll test changing the serial timeout value to see if it helps.

Until someone else running Windows confirms there is an issue with s21 calibration, I have to assume there is something particular about my system (Windows 10, x64, i7).

- Herb

Hi Herb,

On 07.06.20 03:13, hwalker wrote:
> Mark, I submitted this s21 issue to Zarath when he first posted the
> V2 branch of NanoVNA-Saver and it was only 101 points back then, so I
> don't believe its a timeout problem. Zarath has a Linux operating
> environment so he couldn't confirm my s21 issues.
>
> I also have a problem with the 255 point branch causing Python to
> hang when I use multiple segments with a large frequency span (i.e. 5
> segments, 1 - 1000 MHz). That could possibly be a timing problem and
> I'll test changing the serial timeout value to see if it helps.
>
> Until someone else running Windows confirms there is an issue with
> s21 calibration, I have to assume there is something particular about
> my system (Windows 10, x64, i7).

I'll try it on a Windows machine soon. It's possible that the changes
that are done in the serial port setup which are done in linux / macos
but sadly incompatible with Windows have to be implemented in a
different way.

@Mark, can you Issue a PR of your patches to my branch?

73
Holger

On Sun, Jun 7, 2020 at 01:41 AM, Holger Müller wrote:

I'll try it on a Windows machine soon. It's possible that the changes that are done in the serial port setup which are done in linux / macos but sadly incompatible with Windows have to be implemented in a different way.

@Mark, can you Issue a PR of your patches to my branch?
=============================================
Holger,
on my Windows system, I believe something else is going on with the s21 ecal for the V2 branch of NanoVNA-Saver because I don't have any issues with the SOL portion of the calibration. A serial port issue seems like it would affect both the SOL and T calibration. I don't have an understanding of how the s21 ecal works to troubleshoot my problem. There's no way to perform a thru calibration by itself to isolate the problem.

I know on the other NanoVNA variations, Rune warns that NanoVNA should be started with a valid calibration. Since the V2 only transfers uncalibrated data I'm not sure if that impacts anything.

I don't have the s21 ecal problem using VNA-Q, it gives me a perfect SOLT calibration.

Mark's patch for higher points works fine other than the issue I have with the s21 ecal. I had a problem with multi-segment transfers which went away after I increased the serial time out as Mark suggested (a timeout value of 10 worked for me). I was wondering why Mark chose 255 points rather than 201 points, but after looking at his patch for writing the data transfer points to the V2 register, I can see 255 is an easier binary value to handle than 201.

Ideally, the user would be able to select the number of data points rather than having a hard coded number. Maybe a dropdown box of values with a default value at start-up? It would only apply to the V2 or maybe also the -H4 with DiSlord's firmware.

- Herb

Hi Holger,

I'm happy to do that. I didn't really write any code, but instead fixed a couple of small bugs in the Zarath fork but I'll merge them and see what happens.

Mark

Hi Herb,

The 255 data point count is because the Vna2 supports up to 1024 (according to the spec) but you can only program the count with a 1 byte value so... I picked the biggest possible.

-Mark

Mmm.

I'm using this
buf[0] = 0x21;
buf[1] = 0x20;
buf[2] = (unsigned char)(((unsigned short)numPoints));
buf[3] = (unsigned char)(((unsigned short)numPoints)>>8);
and write it with a 4 byte write
so 16 bit supporting 1024 points

Sweet! Thanks for the info. I just tried it.

I had assumed it wouldn't work because the fifo transfer limit is 255 but I tried it and if you loop reading the fifo until the count is fulfilled it works just fine and the looping seems to incur no performance penalty, although it does take 22 seconds on my system to read the entire 1024 element fifo.

-Mark

On Mon, Jun 8, 2020 at 02:45 PM, MarkZ wrote:
.... although it does take 22 seconds on my system to read the entire 1024 element fifo.
==========================
22 seconds? I would have thought my system had hung. Seems like 4 segmented scans of 255 datapoints takes less time.

- Herb

Gabriel or some other firmware guy can step in but given that nanovna-saver empties the fifo before reading it I’d guess this is pretty much the same time as segmented scans. I did test my 255 scan and it took just a bit less than 5 seconds.

Mark

On Mon, Jun 8, 2020 at 04:50 PM, MarkZ wrote:

... given that nanovna-saver empties the fifo before reading it I’d guess this is pretty much the same time as segmented scans. I did test my 255 scan and it took just a bit less than 5 seconds.
===================================
Mark,
You're right, I just ran a 1024 point sweep on VNA-QT and It took 20 seconds or longer to finish. Given that VNA-QT is written in C++, NanoVNA-Saver's performance isn't too shabby.

One other question,
Gabriel's UG1101 manual says only "..sweepStartHz, sweepStepHz, and sweepPoints together set the sweep parameters of the VNA".

I notice your modified NanoVNA_V2 script in addition to, sweepStartHz, sweepStepHz, and sweepPoints, also uses valuesPerFrequency to set up the sweep parameters, and writes the valuesPerFrequency value to registers 21..22 instead of registers 22..23 as documented in Gabriel's manual.

Just curious.

- Herb

Hi Herb,

I do set the valuesPerFrequency because originally I was convinced that either nanosaver-QT was conflicting or nanovna-saver was setting it somehow elsewhere - either way this seemed benign and it seemed to help. I had the same issue of it only working once and then not working.

What a polite bug report. So, I'm pretty sure that 0x21 is the op-code and 0x22 is the address so this does write two bytes to 0x22,0x23 as documented. Let me know if that's not true since I am totally winging this.

-Mark

On Mon, Jun 8, 2020 at 06:17 PM, MarkZ wrote:

... I'm pretty sure that 0x21 is the op-code and 0x22 is the address so this does write two bytes to 0x22,0x23 as documented.
==================================
Thanks for replying Mark. I'm more of a applications person and just trying to work my way through the code. The b"\x21\x20" you write for sweepPoints match up to the addresses in Gabriel's manual, so I thought the same would be true for 0x22,0x23. I didn't see any documentation for op codes, I just thought a 0-23 binary value was being built up to write to the appropriate register.

On my system just using sweepStartHz, sweepStepHz, and sweepPoints to set the sweep parameters works well with your 255 point mod. Saver also seems to start filling in the default frequency values quicker without setting 0x22,0x23. All the datapoint values I've tried below 255 work with your mod and without setting 0x22,0x23.

Sometimes I have to cycle power on the V2 to get the modded V2-Saver to start-up on Windows. That never seemed to happen with Rune's original saver for the NanoVNA.

- Herb

Hello,
would it be possible for us non-programmers to compile beta version of the NanoVna saver with V2 supported to have it for testing? I hope there will be only one version of the NanoVNA saver on the end, I have to say that having multiple branches of the same software is a bit unlucky.

Vojtech, OK1VAW.

Hi,

I totally agree with the concept.

I have already submitted my (updated) changes to Holger's fork of the code here: https://github.com/zarath/nanovna-saver (you can see the pull request). I tried to make a binary a few days ago but I've never done that before and failed miserably at it since I couldn't find any doc on it. I don't like having multiple versions either but as far as I can tell the original developer at https://github.com/mihtjel/nanovna-saver is no longer maintaining the program since it has a dozen undiscussed pull requests pending and has no code changes for 3 months.

My changes are minor and with one tiny exception are all in the V2-specific driver file. If there's any failure-mode that I've added it would simply be in taking longer to read the data (since I bumped up the number of data points) and I just guessed at the appropriate timeout value. I'm virtually certain that setting the internal number of data points per sweep is a good thing as a startup init and pushing two bytes to the device is not adding to the sweep time. Fwiw I've run 'my version' repeatedly in the last few days with zero failures but ...

-Mark

NanoVNA-QT defaults to an averaging factor of 2. The sweep rate is
around 100 points/s, so 22 seconds for 1024 points is about right.

A segmented scan will be FAR slower than a continuous scan. Every time
you write to any of the sweep parameter registers (start/stop/step
frequency, points count) ecal is reset, and the first sweep following
that is several times slower. That's also why when you turn on the
device you see a slow sweep that takes a few seconds. The recommended
usage is to set sweep params once (and whenever the user changes it),
and then continuously read from the FIFO. When you are not reading from
the FIFO the sweep is still happening and the FIFO overflows (while
still being filled with old data). That's why you need to clear the FIFO
to do single scans. Ideally you should have a background thread that
continuously reads the FIFO, and on-demand scans can simply wait for the
correct number of points and return the last full sweep.

Without trying to hijack this thread, this other pull request its a good
addition, so anyone providing the binary (exe) please also include this one:

Add the posibility of use an attenuator inline with the S21 (CH1) input #145

https://github.com/mihtjel/nanovna-saver/pull/145

This is great because an offset can be added, making S21 charts correct,
lets say if you add a resistor inline trying to measure balun loss or an
attenuator.


*73 de Luís, CT2FZI*



On Tue, 9 Jun 2020 at 12:01, MarkZ <mzachma@gmail.com> wrote:

> Hi,
>
> I totally agree with the concept.
>
> I have already submitted my (updated) changes to Holger's fork of the code
> here: https://github.com/zarath/nanovna-saver (you can see the pull
> request). I tried to make a binary a few days ago but I've never done that
> before and failed miserably at it since I couldn't find any doc on it. I
> don't like having multiple versions either but as far as I can tell the
> original developer at https://github.com/mihtjel/nanovna-saver is no
> longer maintaining the program since it has a dozen undiscussed pull
> requests pending and has no code changes for 3 months.
>
> My changes are minor and with one tiny exception are all in the
> V2-specific driver file. If there's any failure-mode that I've added it
> would simply be in taking longer to read the data (since I bumped up the
> number of data points) and I just guessed at the appropriate timeout value.
> I'm virtually certain that setting the internal number of data points per
> sweep is a good thing as a startup init and pushing two bytes to the device
> is not adding to the sweep time. Fwiw I've run 'my version' repeatedly in
> the last few days with zero failures but ...
>
> -Mark
>
>
>
>

Wow, nothing like having the designer online. Thanks, Gabriel.

So, I took a longer look at the code and added a couple of debugging options so I could more precisely time it. The existing code does only reset sweep values when you change the sweep range.

Here's what I saw:

2020-06-09 08:27:30,746 - NanoVNASaver.Hardware.NanoVNA_V2 - INFO - Updating sweep values
2020-06-09 08:27:30,892 - NanoVNASaver.Hardware.NanoVNA_V2 - INFO - **** Starting to read data
2020-06-09 08:27:53,715 - NanoVNASaver.Hardware.NanoVNA_V2 - INFO - **** Finished reading data
2020-06-09 08:27:55,931 - NanoVNASaver.Hardware.NanoVNA_V2 - INFO - **** Starting to read data
2020-06-09 08:28:06,345 - NanoVNASaver.Hardware.NanoVNA_V2 - INFO - **** Finished reading data
2020-06-09 08:28:07,555 - NanoVNASaver.Hardware.NanoVNA_V2 - INFO - **** Starting to read data
2020-06-09 08:28:17,967 - NanoVNASaver.Hardware.NanoVNA_V2 - INFO - **** Finished reading data

I added a line to say when the sweep was being updated and start/stop lines for timing, then I did three sweeps at the same settings.

The first sweep takes 23 seconds (as I had timed) but the second and third sweeps take 10 seconds because there's no reset of the sweep values, exactly agreeing with what you/Gabriel have said. So, there you go - using the entire 1024 sweep is very efficient.

-------

Running for non-programmers.

If you want to try this as a non-programmer it's just a few steps.
1) install python 3.8.3 from python.org, turn on the "Add Python to my path" option
2) run "pip install -r requirements.txt" which will install the required modules into the python library set
3) run "python nanovna-saver.py"

-Mark

Hi Gabriel,

What is currently the limiting factor in the sweep rate? PLL settling
time? CPU speed, UART datarate, analog circuitry settling time? IF
frequency?
Can you shed a light? Is there some improvement possible, maybe with
reduced specs?
Thanks,
Reinier

Op 9-6-2020 om 13:46 schreef Gabriel Tenma White:
> NanoVNA-QT defaults to an averaging factor of 2. The sweep rate is
> around 100 points/s, so 22 seconds for 1024 points is about right.
>
> A segmented scan will be FAR slower than a continuous scan. Every time
> you write to any of the sweep parameter registers (start/stop/step
> frequency, points count) ecal is reset, and the first sweep following
> that is several times slower. That's also why when you turn on the
> device you see a slow sweep that takes a few seconds. The recommended
> usage is to set sweep params once (and whenever the user changes it),
> and then continuously read from the FIFO. When you are not reading
> from the FIFO the sweep is still happening and the FIFO overflows
> (while still being filled with old data). That's why you need to clear
> the FIFO to do single scans. Ideally you should have a background
> thread that continuously reads the FIFO, and on-demand scans can
> simply wait for the correct number of points and return the last full
> sweep.
>
>
>
>

--
IDcircuits - RFID & Electronics
Het Halster 40
6581 JL Malden
The Netherlands
+31 633702492
www.idcircuits.com
r.gerritsen@idcircuits.com

It's trace noise. Looking at the code the time taken per frequency point is:

+ 1.6ms synthesizer wait

+ 7ms acquisition (2.3ms * 3 channels)

+ 0.5ms RF switch wait (0.16ms * 3)

(All timings are fixed, they are specified as number of "periods", each
period being 0.1666... ms which is two IF periods.)

That adds to 9.1ms, but ecal measurements happen once every 5 points so
the average time is around 10ms. Synthesizer wait can probably be
reduced to 0.5ms, but reducing acquisition time will increase noise. IMO
the best way to increase sweep rate is to switch to 3 separate lower
cost mixers (IAM-81008) so the 3 channels can be acquired
simultaneously. Having a simultaneous reference path also means
synthesizer phase noise can be canceled out, meaning less noise to begin
with.

You can reduce MEASUREMENT_NPERIODS_NORMAL in the code to reduce
acquisition time (more noise), and increase MEASUREMENT_ECAL_INTERVAL to
reduce ecal overhead (causes slower response to thermal drift).

On 09/06/2020 21:41, Reinier Gerritsen wrote:

> Hi Gabriel,
>
> What is currently the limiting factor in the sweep rate? PLL settling
> time? CPU speed, UART datarate, analog circuitry settling time? IF
> frequency?
> Can you shed a light? Is there some improvement possible, maybe with
> reduced specs?
> Thanks,
> Reinier
>
> Op 9-6-2020 om 13:46 schreef Gabriel Tenma White:
>> NanoVNA-QT defaults to an averaging factor of 2. The sweep rate is
>> around 100 points/s, so 22 seconds for 1024 points is about right.
>>
>> A segmented scan will be FAR slower than a continuous scan. Every
>> time you write to any of the sweep parameter registers
>> (start/stop/step frequency, points count) ecal is reset, and the
>> first sweep following that is several times slower. That's also why
>> when you turn on the device you see a slow sweep that takes a few
>> seconds. The recommended usage is to set sweep params once (and
>> whenever the user changes it), and then continuously read from the
>> FIFO. When you are not reading from the FIFO the sweep is still
>> happening and the FIFO overflows (while still being filled with old
>> data). That's why you need to clear the FIFO to do single scans.
>> Ideally you should have a background thread that continuously reads
>> the FIFO, and on-demand scans can simply wait for the correct number
>> of points and return the last full sweep.
>>
>>
>>
>>
>

I looked into the # of samples thing given Gabriel's latest comment about Vna-QT using 2 samples and found that ->

Without the reset of the # of samples in the code, if you run Vna-QT and then run nanovna-saver the nanovna-saver will never run correctly. You'll get messed up data sets.

Adding this line

cmd += b"\x21\x22" + int.to_bytes(1, 2, 'little') # number of samples

back into the python code and thus correctly initializing the number of samples setting is enough for nanovna-saver to run correctly after running Vna-QT.

-Mark

Yes, worked. My horizons enhanced. Thanks.

You can look on my message here:

https://groups.io/g/NanoVNAV2/message/345

with some real measurements, what is happening there. I think that it is
due to  the calibration. My opinion is, that is not necessary to be done
on every measurement of every sweep, it is enough to be done only in
certain interval. This will clearly speed up the measurement 3x.

Vojtech

Dne 09.06.2020 v 15:41 Reinier Gerritsen napsal(a):

> Hi Gabriel,
>
> What is currently the limiting factor in the sweep rate? PLL settling
> time? CPU speed, UART datarate, analog circuitry settling time? IF
> frequency?
> Can you shed a light? Is there some improvement possible, maybe with
> reduced specs?
> Thanks,
> Reinier
>
> Op 9-6-2020 om 13:46 schreef Gabriel Tenma White:
>> NanoVNA-QT defaults to an averaging factor of 2. The sweep rate is
>> around 100 points/s, so 22 seconds for 1024 points is about right.
>>
>> A segmented scan will be FAR slower than a continuous scan. Every
>> time you write to any of the sweep parameter registers
>> (start/stop/step frequency, points count) ecal is reset, and the
>> first sweep following that is several times slower. That's also why
>> when you turn on the device you see a slow sweep that takes a few
>> seconds. The recommended usage is to set sweep params once (and
>> whenever the user changes it), and then continuously read from the
>> FIFO. When you are not reading from the FIFO the sweep is still
>> happening and the FIFO overflows (while still being filled with old
>> data). That's why you need to clear the FIFO to do single scans.
>> Ideally you should have a background thread that continuously reads
>> the FIFO, and on-demand scans can simply wait for the correct number
>> of points and return the last full sweep.
>>
>>
>>
>>
>