While doing some further testing, I came across the following observation and am curious if this is an expected behaviour and if there is a way to solve the issue.
First, an explanation of my procedure: For three different scenarios (top,middle,bottom rows) and 50 different instances of DUT (horizontal axis), I measured the single-frequency rssi and phase.
I repeated each measurement (red = first run, blue = second run).
As you can see, top and bottom row match nicely both in terms of rssi and phase. For the middle row, rssi matches nicely, but phase occassionally displays a huge jumps as well as differences between the first and second run. Notice that for the scenario in the middle row, the phase (by chance) fluctuates for different DUT instances around 180° - can the issue be related to this?
The phase range is limited to ± 180 degrees.
Consequently, if the phase is close to 180 degrees, as is the case for middle row, it could wrap to -180 deg.
In other words, instead of measuring 182 deg, you would get -178.
I guess that this is happening.
Sure, although there seem to be a few occasions on which it jumps to close to 0°, e.g. DUT instances #8 or #31 - I canât guarantee that it is not due to the experiment but no such large phase jumps occurred in the top and bottom line. Iâll keep checking the other parts of my setup and get back to you.
I know I asked about single-frequency measurements (and that is what I ultimately aim to use), but for some preliminary tests, I now think I may find multi-frequency measurements useful. [Experiments donât always go exactly as plannedâŠ] Again, they donât need to be particularly well calibrated, a phase and/or amplitude prefactor is fine as long as it is the same for all repeated measurements.
I tried to take the original measureVNA.py code and loop the last part of it; I tried a sanity check by making repeated measurements of the same DUT. However, I find that in particular the phase yields a significantly different value in repeated runs even when the DUT is the same.
Here is an example in which I fixed lna and pga gains for all frequency points, and measured the same DUT 5 times (never mind the calibration - in fact DUT was connected all the time):
Is there anything I can try to improve measurement reproducibility in the multi-frequency case? It looks like a phase-unwrapping issue mainly - but once DUT varies I wonât know how to unambiguously unwrap, I think. Unwrapping is relative to the phase of the lowest frequency pointâŠ
Edit: I think unwrapping solves most of it, except the fact that the first run is different from the others which are in themselves consistentâŠ
I have done further single-frequency experiments, and every so often measurements that are close to +/-180° jump, but like I said they jump by 180 and not by 360°. So that is a big source of error if not detected and treated properly.
Itâs been some time but I am still struggling with the phase error and was hoping you had any insights on how to deal with it.
I repeat the exact same measurement 10 times. If everything goes well, the phase values I get fluctuate by a few degrees. I also understand that there can be unwrapping which takes a value from close to 180 to close to -180 and vice versa, i.e. a change by 360°.
My issue, however, is related to occassionally occurring phase differences of 180°. You can see two examples thereof in my post from Decâ18 in the middle right figure:
There are a couple of typical 360° jumps from obvious unwrapping issues, but for DUT instances #8 and #31 there is a 180° jump.
Any idea where these 180° jumps come from and how to mitigate them? They trouble me a lot, for instance, if I want to take a measurement multiple times and average to improve the SNR, if such 180° jumps occur, the average is 0 instead of the true value.
The problem with phase jumps is that every time the PLL locks (e.g. changing the frequency) you have random phases of TX and RX frequency dividers which drive the quadrature mixers, so the phase difference can be n*90 deg.
The software tries to correct this, but in some cases it is not working.
As I see it, the only way to get consistent phase measurements is to lock PLL once and perform all measurements on a single frequency.
PLL is locked when you change frequency.
So, set the frequency once and donât change it.
It should work even for hours, but I havenât tried it for so long.
I just went through the code to see at which points the variable âmeasurementFrequencyâ is used.
I found the following:
lms7002.SX[âTâ].setFREQ(measurementFrequency)
and
limeSDR.configureAntenna(measurementFrequency)
But these lines are both before I start the loop for repeated measurements at the same frequency. So that means the PLL has not been locked properly if I observe phase jumps?
If so, when you start it, donât interrupt it and make measurements.
If you still encounter phase jumps, then I donât know how to fix it.
Guess that would be the limitation of a simple setup.
Proper way of measuring the phase would require using two couplers and two receiving channels, as real VNA does.
Then you could sample incident and reflected wave and determine the phase regardless of TX/RX PLL phase relation.
If phase_measured = phase_true + n*90, n being an integer, one solution for me to get reliable data could be to consider the measured phases modulo 90 - that sacrifices a bit the physical meaning of the phase value but at least it would be well-defined despite the phase jumps.
I have been struggling with the same problem that @Time2Lime had. Mine error is " no module named âSoapySDRâ.
WHEN I am running the measureVNA.py
Mine is windows 10 and PYTHON VERSION 3.7 AND I have installed pylms7002Soapy as asked to do like running python setup.py in the package root directory.
Also do I have to install soapysdr separately after installing latest pothosware. And SoapySDRUtil --info works, from pyLMS7002Soapy import * also works
please help.
I just stumbled across this thread and found it very interesting because I am trying this code out for S21 phase measurements in an attempt to determine just how well I can measure phase only using an SDR (directional couplers if necessary). Unfortunately, my measurements provide unreasonable results suggesting a possible bug in the code. I am just getting into the investigation now; debugging will follow experiments to determine what is actually wrong. If I find something that may be of value to others, Iâll post it here.
