Hello,
I have issues with trembling (peaks) on S11 phase characteristic increasing up to 100MHz. It is seen on VNA-qt and NanoVna Saver. It is mostly evident when using 1024points from 20kHz to 150MHz.

On Sat, Aug 15, 2020 at 05:31 AM, ok1vaw wrote:

..I have issues with trembling (peaks) on S11 phase characteristic increasing up to 100MHz. It is seen on VNA-qt and NanoVna Saver. It is mostly evident when using 1024points from 20kHz to 150MHz.
========================================
The SAA-2 does not transfer corrected data as the NanoVNA does. That means if you are using NanoVNA-Saver or VNA-QT you need to perform an external SOLT calibration and apply it in those programs or your measurements will be off.

This is particularly noticeable below 200 MHz where the correction factors are higher.

- Herb

Herb,

Do I understand your comment to mean that I will need to do a SOLT on
both the SAA-2 and again in Saver to see proper measurements?


On 8/15/2020 2:55 PM, hwalker wrote:

> On Sat, Aug 15, 2020 at 05:31 AM, ok1vaw wrote:
>
> ..I have issues with trembling (peaks) on S11 phase characteristic increasing up to 100MHz. It is seen on VNA-qt and NanoVna Saver. It is mostly evident when using 1024points from 20kHz to 150MHz.
> ========================================
> The SAA-2 does not transfer corrected data as the NanoVNA does. That means if you are using NanoVNA-Saver or VNA-QT you need to perform an external SOLT calibration and apply it in those programs or your measurements will be off.
>
> This is particularly noticeable below 200 MHz where the correction factors are higher.
>
> - Herb
>
>
>

Is that not easy to try?
Best regards, Robert, 360 774 2736.

On Saturday, August 15, 2020, 05:01:40 PM PDT, John Clark <johnwclark@frii.com> wrote:

Herb,

Do I understand your comment to mean that I will need to do a SOLT on
both the SAA-2 and again in Saver to see proper measurements?


On 8/15/2020 2:55 PM, hwalker wrote:

> On Sat, Aug 15, 2020 at 05:31 AM, ok1vaw wrote:
>
>  ..I have issues with trembling (peaks) on S11 phase characteristic increasing up to 100MHz. It is seen on VNA-qt and NanoVna Saver. It is mostly evident when using 1024points from 20kHz to 150MHz.
> ========================================
>    The SAA-2 does not transfer corrected data as the NanoVNA does.  That means if you are using NanoVNA-Saver or VNA-QT you need to perform an external SOLT calibration and apply it in those programs or your measurements will be off.
>
>    This is particularly noticeable below 200 MHz where the correction factors are higher.
>
> - Herb
>
>
>

On Sat, Aug 15, 2020 at 05:01 PM, John Clark wrote:
Do I understand your comment to mean that I will need to do a SOLT on both the SAA-2 and again in Saver to see proper measurements?
=======================================
John,
Its a pain, but unlike S1P and S2P files, each application tends to save their calibration files in different formats. Best to name your calibration files so you will remember which application created them (i.e. Saver_SAA2_20k-1000M_801pts or QT_SAA2_20k-1000M_801pts).

I'm pretty sure once you do the calibrations your "wiggle" issues will not be noticeable anymore, especially in the native VNA-QT application.

- Herb

On Sat, Aug 15, 2020 at 05:01 PM, John Clark wrote:

Do I understand your comment to mean that I will need to do a SOLT on both the SAA-2 and again in Saver to see proper measurements?
================================
John,
I thought I was replying to the original poster in my previous post. But in answer to your question. The calibration you perform on the SAA-2 cannot be used in Saver and you have to perform another SOLT calibration in Saver in order for your measurements to be accurate - especially at the low end of the frequency range.

Its not a bug. Its just the way the SAA-2 firmware was designed.

- Herb

(Putting words into Gabriel's mouth) Specifically, the firmware is pretty limited in function (it's very ram-limited and comparatively slow and do you really want to enter correction factors into a 2.8" lcd touchscreen?) so the designer felt that a PC-based correction method would usually be more accurate than the firmware method (and it is...). In that case, receiving firmware-corrected data points is a waste of resources and imprecise since they would need to be de-corrected first.

-Mark

use a bigger cpu

dg9bfc sigi

Am 17.08.2020 um 11:10 schrieb MarkZ:

> (Putting words into Gabriel's mouth) Specifically, the firmware is pretty limited in function (it's very ram-limited and comparatively slow and do you really want to enter correction factors into a 2.8" lcd touchscreen?) so the designer felt that a PC-based correction method would usually be more accurate than the firmware method (and it is...). In that case, receiving firmware-corrected data points is a waste of resources and imprecise since they would need to be de-corrected first.
>
> -Mark
>
>
>

On Mon, Aug 17, 2020 at 04:10 AM, MarkZ wrote:

>
> (Putting words into Gabriel's mouth) Specifically, the firmware is pretty
> limited in function (it's very ram-limited and comparatively slow and do you
> really want to enter correction factors into a 2.8" lcd touchscreen?) so the
> designer felt that a PC-based correction method would usually be more accurate
> than the firmware method (and it is...). In that case, receiving
> firmware-corrected data points is a waste of resources and imprecise since
> they would need to be de-corrected first.
>
> -Mark
>
Yes and no. For made correct calibration need calibration table. V2 allow send up to 1001 points, so need 1001 calibration points (no resources for this). Internal calibration use 201 points and can`t interpolate it as V1.
On CPU connect, no calibration use (it for allow send up to 1001 points) for solve RAM and speed problem

PS (i test H4 and it allow use up to 401 points, if made some calibration optimization up to ~501 points), also i test interpolation for V2, it work, but need understand 201 calibration points not allow work in all range 1-3.5GHz, need made more calibration ranges.

Hello,
I suppose that the discussion is going away. I would be happy, if someone could confirm my results (problems) when using PC programs and doing sweeps with more points between 50MHz and 100MHz. I have two different USB cards with different chipset. In the meantime, I have intstalled the LiPol battery inside to eliminate the problem origin from weak USB supply.
The peaks are visible before any calibration, so it comes from uncertanity of the measurement. What is interesting, that in the debug.txt(attached) there are repeated errors of the type:
ERROR - expected 3232 bytes, got 3072
the got values are different but repeats. This happens on every USB port, which I have.

I have other opinion with the NanoVna Saver (I use 0.37) and the Calibration data. My experience shows, that if you calibrate (or load calibration) , which covers the measurement band, it interpolates during measurement. It can be easily proved in the 1MHz up to 10MHz region, where due to imperfection of the SWR bridge the uncalibrated Nanovna V2 has a +3dB peak, when measuring open, so the data are going outside of the Smith Chart.
The trembling appears or in segment sweep (10 segments 101 points) or 1 segment (1021 points) and much more when using continuous sweep.

I use still the NanoVNA V2 firmware v2.0.2 from June, a newer official one I have not found.

I haven't worked on -saver in a while but it looks to me as if you are timing out. While this is fixable if that's what it is, you seem to be sweeping 5 segments of 101 points, and there's just no reason to do that. Instead it's twice as fast (and I'd bet, more reliable) to sweep 1 segment of 501 points and get exactly the same resolution.

The first time you sweep a frequency range the firmware does an internal calibration of stuff. This takes about as long as a sweep. So, when you sweep multiple segments each segment internally recalibrates every time (because the range has changed to a new segment) and takes twice as long as it should. It wouldn't surprise me if there are other externalities (like I'd bet calibration works best with a single segment).

Just my 2 cents.

-Mark

I have tested, if the number of segments have any influence on the measured data. It has no difference, if I do 10 segments of 101 points or 1 segment of 1021 points. If you think it is faster, I have not the same opinion. I can do both measurements and we can see the results in the debug.txt, there is time information.
I have tested the measurement on the NanoVNA v2 running from internal battery and from my first tests it seems, that the phase data are not trembling, so it seems, that the problem is in the USB communication timing.
Is there any newer firmware for V2 available?

Hi,

I tried running 10 segments at 101 points and 1 segment at 1021 points and the timings were:

10 segments @ 101 -> 25 seconds
1 segment @1021 -> 11 seconds (after the first run)

So, there is a significant timing speed difference and indeed inside the firmware very different things are going on.

I'd check the github site ( https://github.com/NanoVNA-Saver/nanovna-saver/releases ) to see about newer firmware.

-Mark

I have made the following observations. I have tested the same V2 on multiple computers (one laptop with I3, one very new I5 six core), but the results are more or less the same.
1)doing multi segment sweep (for example 10x 101) is problemati. It leads to erratic data, very often there are errors EXPECTED.... GET ....... This error sometimes leads to freeze the Saver itself, command disconnect does not work and I have to switch off the VNA2.
2)selecting 1021 points sweep is problematic and the data (mostly seen on phase of s11) have strange peaks. This does not happen when selecting 501 points. I firstly thought, that the problem concerns the 100MHz range, but it seems to not depend on frequency. I have tested sweep 20 to 120MHz, and 80 to 81MHz.
My Nanovna reports Firmware v1.0.1 and I use the newest NanoVNASaver version 0.3.7. (exe version without any rc).

If there is any newer firmware for V2, let me know.
As far as from my point of view it seems, that there is communication problem between the V2 and PC on virtual serial port, there is a question, if there is not a problem in a driver. On one PC I have used the reccomended Cypress COM drivers from the QT installation package, on the second PC with the I7 windows 10 have identified the V2 and downloaded drivers for virtual serial port automatically and I have not seen any difference.

Let me know if you have similar results (trembling data) and the communication problem ERROR - expected xxxx bytes, got yyyy (xxxx and yyyy are numbers) in the python window and debug.log
I have added pictures and debug logs.

What are you measuring s11 of? Also, could you show the magnitude data? I'm not sure it matters, but it may. I do not get the missing data messages that you get so that's almost certainly at least part of your problem.

I'm including images of my Device Manager view of the emulated serial port in case that could be part of the problem.

-Mark

I just ran a dozen sweeps in various ranges at 1021 data points and never saw the 'expected data' message that you are getting. It sure looks like a USB issue. Do you have an external noise source somewhere nearby that could be corrupting data packets? Have you tried other usb cables? Maybe a firmware person could chime in - I haven't even looked at the firmware code.

-Mark

I have tested it on various computers at different locations, on one computer I have two different usb cards and USB3 and USB2, multiple cables, so noise or cable is not the issue. I measure open port (with SMA saver). Attached are few additional pictures. Which firmware do you have?
Attached you have more screenshots.

I just copied your sweep settings exactly and was able to replicate the usb problem. So, the good news is I also saw it... which means it's repairable by the -saver or firmware team - once we figure out what's going on. I also tried this with vna-qt to try to figure out root cause and I can't tell if it's losing usb (my guess is no) but it definitely has the 'trembling' issue in the ~100MHz range.

If I sweep 80-100MHz it has lots of spikes. If I sweep 180-200MHz it's a perfect flat line, so this must mean something - almost certainly in the firmware or hardware design. Though, in the US we have a lot of FM transmitters in the 80-100MHz band so maybe it's interference.

At this point, give me a day or so to take a longer look.

-Mark

So, I walked through the firmware a little and took a look at the schematic. Apparently the Saa2 uses two different oscillators depending on frequency range. It won't surprise you to hear the range flips at 140 MHz. So, it appears that's the root cause. Why the si5351 (the low freq oscillator) is causing more irregularities than the high frequency oscillator I don't know. It does appear, though, that the sweep is slower on the low freq oscillator - which may help explain the timeouts.

I have more investigating to do.

-Mark

Ok, here's the first part - your timeouts. I'm including part of your debug.txt dump at the bottom of this for you to look at.

We apparently are setting the timeout to #datapoints/32 seconds (so, for 101 points that is about 3 seconds). Looking at your multisegment 101 point scan we can see that the first segment took almost exactly 3 seconds (and worked) whereas the second segment timed out at just over 3 seconds. So, we specifically need a longer timeout would be my guess. This is easy to change in the code and to test if you can run from the Python source.

On line 130 of nanovna_v2.py is this line:
self.serial.timeout = min(8.0, (pointstodo / 32) + 0.1)
Change it to
self.serial.timeout = min(12.0, (pointstodo / 20) + 0.1)

and see if your timeouts disappear. If you need a test exe I can make one for you.

-Mark

Here's part of your original debug.txt dump.
Reading from 96031730 to 103968230. Averaging 1 values
**** 2020-08-16 12:46:30,389 - NanoVNASaver.Hardware.NanoVNA_V2 - INFO - NanoVNAV2: set sweep start 96031730 step 79365
2020-08-16 12:46:30,452 - NanoVNASaver.SweepWorker - DEBUG - Read 101 frequencies
2020-08-16 12:46:30,452 - NanoVNASaver.SweepWorker - DEBUG - Reading data 0
2020-08-16 12:46:30,569 - NanoVNASaver.Hardware.NanoVNA_V2 - INFO - reading values
2020-08-16 12:46:33,583 - NanoVNASaver.SweepWorker - DEBUG - Read 101 values
2020-08-16 12:46:33,584 - NanoVNASaver.SweepWorker - DEBUG - Averaging 1 values
2020-08-16 12:46:33,588 - NanoVNASaver.SweepWorker - DEBUG - Saving data to application (505 and 505 points)
**** 2020-08-16 12:46:33,588 - NanoVNASaver.SweepWorker - DEBUG - Sending "updated" signal
2020-08-16 12:46:33,588 - NanoVNASaver.SweepWorker - DEBUG - Sweep segment no 3
2020-08-16 12:46:33,588 - NanoVNASaver.Settings.Sweep - DEBUG - get_index_range(3) -> (104047595, 111984095)
2020-08-16 12:46:33,588 - NanoVNASaver.SweepWorker - INFO - Reading from 104047595 to 111984095. Averaging 1 values
2020-08-16 12:46:33,589 - NanoVNASaver.SweepWorker - DEBUG - Reading average no 1 / 1
2020-08-16 12:46:33,590 - NanoVNASaver.SweepWorker - DEBUG - Setting sweep range to 104047595 to 111984095
2020-08-16 12:46:33,595 - NanoVNASaver.Hardware.NanoVNA_V2 - INFO - NanoVNAV2: set sweep start 104047595 step 79365
**** 2020-08-16 12:46:33,651 - NanoVNASaver.SweepWorker - DEBUG - Read 101 frequencies
2020-08-16 12:46:33,651 - NanoVNASaver.SweepWorker - DEBUG - Reading data 0
2020-08-16 12:46:33,768 - NanoVNASaver.Hardware.NanoVNA_V2 - INFO - reading values
**** 2020-08-16 12:46:37,075 - NanoVNASaver.Hardware.NanoVNA_V2 - ERROR - expected 3232 bytes, got 2848

Hello Mark,
I have tested the change in Python. It seems to be significantly better, but the "peaks" on the phase are still there, but in the small quantitity. The communication error appears too, when during sweep I have changed the load from open to short and it froze the communication fully. So it seems better, but still not perfect. 51x20points is perfect, 10x101 is worse and 1021 too. See the attachment and last debug.txt. Look at the polar plot, all the peaks plots are away in the same back direction, it seems that they are located where the sis changes the prescalers or similar?
There are new errors when changing the number of points per sweep (Index out of range), it concerns the low limit value 1MHz.

Hi,
There were two separate bugs. The timeout value was just slightly too low and on timeout it wasn't correctly recovering the data. I created a pull request (code change) to fix those bugs in nanovna-saver for the next release.

I'm looking into the peaks stuff next.

-Mark

Apparently I didn't set quite enough of a timeout (although it now recovers data correctly so you won't notice in normal operation) but after looking at the si5351 code I can well believe it has small errors along the way. Calibration seems to take care of them quite handily but if you expect to be able to sample different frequencies while using the same calibration data (as some folks want) the calibration is almost certainly not going to work well.

Some firmware work, which is out of my domain, might help with this. I don't understand the 5351 PLL resetting but there is almost zero documentation so I'm not alone there. Until then, if you calibrate the frequency range you plan to sweep it should work well.

-Mark

Although I have tried to download the "latest" firmware (cw_fix_03_sept_2020.bin), I have still the problems with the trembling data between 50MHz to 100MHz but it appears when using 1021 points, not 512. I use the patched 0.37 version with the elimination of EXPECTED...... error.

I have opened an issue too on GitHub. I am not sure, where is the better place for solving this bug.