constant phase measurements between the two inputs after switching frequency

[hanrod97]

Description of the setup:

• Device: Red Pitaya 122.88-16
• SD card image: red-pitaya-alpine-3.12-armv7-20200628
• Application: SDR transceiver compatible with HPSDR
• Other relevant information: I'm using GNU Radio to calculate and display my data

Description of the problem:

Hello Pavel,

maybe you remember me from my previous problem two weeks ago #979. I'm currently measuring the reflection coefficient s11 at different frequencies (0.3-200MHz) with two directional couplers at the two inputs of the Red Pitaya. At single frequencies, it works pretty well (first calibration and then measurement), but now i tried to more move into measurements with different frequencies (you could call it sweep, but it will be more single frequencies switching).

The Problem i encountered during that work is the following: if i calibrate at let's say 1MHz (im doing an Open-Short-Load Calibration), then switch the frequency to another value and back again, the calibration doesnt work anymore. The values i get for Open, Short and Load in the first calibration have the same magnitude as after switching frequency, but the phases of all three measurements are shifted by a random value (but at least it's the same for all of the three measurements).

I don't really understand how this is possible, since im only measuring the ratio between the two inputsignals, so i suspect the problem is the DDS, are there separate ones for both inputs? Or would you suspect another problem? Could you imagine any easy solution for that?

Thanks in advance and best regards, Hannes

[pavel-demin]

i suspect the problem is the DDS, are there separate ones for both inputs?

Yes, the down-converters and up-converters have independent DDS modules.

SDR transceiver compatible with HPSDR cannot be used as VNA. Please consider using the VNA project for VNA measurements.

[hanrod97]

Thanks for your answer.

ok, that's not really important for me since i don't use the Red Pitaya as a signal source. But i guess it's the same problem with the two inputs...

I'm not really familiar to the VNA project, but as far as i got that with the VNA program you can only measure certain frequency sweeps depending on the data you send via TCP and i don't want to limit my frequency range with the RP. Also i'm sacrificing a lot of freedom i have with GNU Radio.

i see the for-loop in your rx.tcl, which creates the two DDS modules. I first gotta work myself into tcl and FPGA stuff, but if i did, do think it would be possible to use the same DDS for both inputs?

[pavel-demin]

ok, that's not really important for me since i don't use the Red Pitaya as a signal source.

The first two RX DDS modules can be synchronized by setting rx_sync_data to 1.

This can be done by having the client code send a control command with the 'Common Mercury Frequency' bit set to 1. More details can be found on page 8 of the HPSDR - USB Data Protocol document.

If the client code can't control the 'Common Mercury Frequency' bit, then it's also possible to modify the server code and replace if(rx_sync_data) with if(1).

Also i'm sacrificing a lot of freedom i have with GNU Radio.

This freedom is illusory. It's limited by the available functionality of the components you are trying to combine.

[pavel-demin]

as far as i got that with the VNA program you can only measure certain frequency sweeps depending on the data you send via TCP and i don't want to limit my frequency range with the RP

It is possible to measure a single frequency per sweep by setting the start and stop frequency to the same value. The frequency range isn't limited.

BTW. I think a frequency lookup table could be added to the VNA project that would allow to scan an arbitrary sequence of frequencies.

[hanrod97]

The first two RX DDS modules can be synchronized by setting rx_sync_data to 1.

This can be done by having the client code send a control command with the 'Common Mercury Frequency' bit set to 1. More details can be found on page 8 of the HPSDR - USB Data Protocol document.

If the client code can't control the 'Common Mercury Frequency' bit, then it's also possible to modify the server code and replace if(rx_sync_data) with if(1).

Thanks! that is what i was hoping for. In my client code i don't see a suitable solution, so i'll probably go with the second solution. I see if(rx_sync_data) 3 times in the sdr-transceiver-hpsdr.c. So i suppose i gotta change all three? Do i also need to change other files?

This freedom is illusory. It's limited by the available functionality of the components you are trying to combine.

That's probably true, but since i'm not much of an experienced programmer it is much faster and easier for me to come along with it :-) Especially for little changes in the calculation of the data or parameters in Filters etc.

It is possible to measure a single frequency per sweep by setting the start and stop frequency to the same value. The frequency range isn't limited.

That's true. The Question would be for me how i'd also control another signal source, e.g. another SDR to get into higher frequency ranges.

BTW. I think a frequency lookup table could be added to the VNA project that would allow to scan an arbitrary sequence of frequencies.

that would be awesome, i'll first try my solution since i also already put a lot of effort in it, but if i encounter more such major difficulties i'd probably spend the days to get into MATLAB or something.