Adalm Pluto RX inconsistency

The TX and RX PLLs inside the transceiver have a random phase relationship. This is randomized each time the radio's sample rate is tuned/set, the LOs are updated, or the filters are loaded. The Pluto blocks do this each time they are initialized. If you want to skip this you need to either modify the blocks or use the generic IIO Source/Sink blocks.

-Travis

Thanks for the quick response. So I can consider that TX&RX PLLs are in phase when I am seeing responses like in fig 2.  

What do you mean by modifying the block? Modifying source code of pluto sink and source?

Is there any material for IIO Device Sink/Source blocks like: https://wiki.analog.com/resources/tools-software/linux-software/gnuradio

Regards,

dea

dea said:

So I can consider that TX&RX PLLs are in phase when I am seeing responses like in fig 2.  

No, this can never be assumed.

dea said:

What do you mean by modifying the block? Modifying source code of pluto sink and source?

Yes the source if you want to still use the PlutoSDR blocks. You would need to prevent it from performing sample rate, filter, and LO updates. I more recommend just using the IIO Source/Sink blocks.

To control Pluto from the generic blocks would require the specific assignment:

Source:

- IIO Context URI: Same as Pluto

- Device Name/ID: cf-ad9361-lpc

- PHY Device Name/ID: ad9361-phy

- Channels: ['voltage0','voltage1']

Sink:

- IIO Context URI: Same as Pluto

- Device Name/ID: cf-ad9361-dds-core-lpc

- PHY Device Name/ID: ad9361-phy

- Channels: ['voltage0','voltage1']

-Travis

Appreciate for your help Travis.

I have one last question in terms of the parameters of these blocks. By " iio_info -u ip:192.168.2.1" command from the terminal I can see the attributes. As far as I understand from similar posts altvoltage1 (TX), altvoltage0(RX), and voltage_0(output-TX, input-RX) are important for us. Using "IIO Attr Updater" and "IIO Attr Sink", I can assign the attributes of source and sink blocks.

However, when I redraw the flowgraph with generic blocks and set parameters, I didn't get the expected result, I did get RX freq response around 0dB. I have added the flowgraph below, what can be wrong?

Thanks,

dea

I'm also getting "Unable to push buffer: Resource device". I have set float to short scale 0x8000 but this didn't help.

dea said:

I'm also getting "Unable to push buffer: Resource device". I

Please make sure there are not multiple flowgraph running or other tools running like IIO-Scope to control the radio.

dea said:

I have set float to short scale 0x8000 but this didn't help.

Was this done on the TX side? If you use the Pluto TX blocks with the Generic IIO receive blocks do you get the expected result?

-Travis

Thank you. I actually did it on both sides. I have first scaled the TX side and the received signal was around again above 0 dB so I did scale the RX also. Since the "Unable to push buffer" warning is not disappeared, I can't see anything with the configuration that includes 2 generic blocks. SS is added, note that I have changed the scale on RX side to 3.27k to scale amplitudes. 

I have also tried Pluto TX block with generic RX. Unfortunately, I didn't observe the correct waveform. The received signal is added as figure 2. It is showing some correct pulses but then I am receiving corrupted signals then showing corrects etc. In the configuration which has 2 Plutos, when it captures the correct waveform it always shows in the monitor.

Moreover, in your first answer, you said that "The TX and RX PLLs inside the transceiver have a random phase relationship. This is randomized each time the radio's sample rate is tuned/set, the LOs are updated, or the filters are loaded." Is this issue related to my problem? Because I am not changing anything on the fly so PLLs only set once. 

Regards,

dea

dea said:

Because I am not changing anything on the fly so PLLs only set once. 

If you use the Pluto blocks at all they update the PLLs. This happens when the flowgraph starts and when tuning settings. If you are using the Attribute blocks to update the radio you will have the same issue as the phase randomization is specific to the hardware.

If you want to maintain a phase relation (not this is still random just not changing). Run the flowgraph once with the pluto blocks with the setting that you want then switch to the Generic blocks (and do not use the Attribute blocks).

dea said:

then I am receiving corrupted signals then showing corrects etc.

You will not get the exact waveform. It will have a phase shift and random delay. Note that since you are using fast attack the waveform will tend to saturate early then ramp down. You are better off manually setting the gain.

-Travis

Thank you, Travis, "Run the flowgraph once with the pluto blocks with the setting that you want then switch to the Generic blocks (and do not use the Attribute blocks)." this idea is working for me but I am still getting unable to push buffer warning. Therefore, I saw the received signal once and then receiving noise.

I have tried to;

1- reducing vector size: nothing happened.

2- Putting the throttle block before the sink which has value of 0x8000: nothing happened.

3- Trying different buffer size: 1.04858M. With larger buffer size I can see multiple received signal but after approximately 10 seconds again buffer warning appears and nothing is shown on RX side. Also, when I increase the buffer size, the received signal amplitude dropped drastically. Isn't the scaling thing related to ADC-DAC resolution? Why buffer size is affecting the received signal amplitude?

After all, I am not able to solve the problem...

Regards,

dea

Can you disable cyclic mode on the Sink Generic block and try again?

-Travis