pyLMS7002Soapy Problems

#21

@dgrujic

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).

This is what I got:

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?

I wonder why?

#22

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.

#23

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.

#24

Hi @dgrujic,

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…

#25

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.

#26

Hi @dgrujic,
Did you wrote the code for the VNA example ?
I have a few questions about the code.

Regards
Mauro

#27

Hi @dgrujic,

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.

Thanks.

#28

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.

#29

Thanks for the rapid reply.

Since I do all measurements at a single frequency, I could lock the PLL once and for all, even if the measurements run for hours?

How would I lock the PLL?

#30

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.

#31

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?

#32

Are you referring to this scipt?
https://pastebin.com/8V0s7jy

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.

#33

The link doesn’t work for me.

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.

#34

Sorry about that, I didn’t copy the whole link:
https://pastebin.com/8V0s7jyp