ADF5355 modification doesn't work properly

HI Joaquin567 

Thanks for your query.
This looks like some integration issue in linux, if it is happening intermittently then pls check on the version and check initial bootup log if all the devices are initialized successfully.

Also, if you have power or clock issues on the board. we need to check if the PLL clock is locked or not, also similarly check for AD9361 PLL lock status. if you try with internal PLL or some external clock are you seeing this behavior.

Regards,

SJ

Hi, same person with different account. I will delve into the problematic I'm having a bit further.

First of all, I'm using pyadi-iio in order to access the FMComms5 parameters and modify them. In order to configure the adf5355 frequency which will then be distributed to each of the ad9361 I do the following:

ctx = sdr._ctx
adf5355 = ctx.find_device("adf5355")
ch= adf5355.find_channel("altvoltage0",True)
ch.attrs["frequency"].value="4000000000"

After changing the frequency, in the same zcu102 I verify it through:

iio_attr -c adf5355 altvoltage0 frequency
iio_attr -c adf5355 altvoltage1 frequency

And I get:

altvoltage0 = 4000000000
altvoltage1 = 8000000000

Which I understand that is working properly.
Afterwards, I check the PLL status of the adf5355. Since it does not have any attribute to acces to in order to check it is LOCK, I do the following:

cat /sys/kernel/debug/gpio | grep adf5355

gpio-476 (                    |adf5355             ) in  hi

The second line is the output of the command, which is hi for any given frequenct. Does this output correspond to the PLL LOCK or not?

Other thing I have noticed is that when I execute the commands

iio_reg ad9361-phy 0x247
iio_reg ad9361-phy-B 0x247

which correspodn to the register of the PLL status, both of them return 0x00, but since the frequency and PLL stability is governed by adf5355 this shouldn't matter, or both do have to be locked, which is, 0x01?

Also, I saw in FMCOMMS5 Use ADF5355 as ext LO - Q&A - Support AD9361/AD9363/AD9364 - EngineerZone that the adf5355 wasn't working because of the missing E507 resistor, but in my case it is present in the fmcomms5, could it be another component?

Still. the same keeps happening, the correct functioning of the system depends on the frequency of the adf5355, which shouldn't be happening.

Best regards,
Joaquin.

Hi JoaquinTh ,

Just injecting a tiny question to your discussion: Do you take the RF input signal from a RF signal generator?

I've never used the setup in question, but it sounds like there is a possibility that the PLL is in integer mode. With a PLL frequency setting where you are not getting any input, try dialing the RF generator's frequency up and down to see if there is a frequency nearby that the system is able to receive.

Cheers, heke

Hi Heke,

No, I'm using the set-up in analog loopback mode before using a RF signal generator.

Greetings,
Joaquín

Hi JoaquinTh ,

Does the board offer an option to probe the loop-back signal with e.g. a spectrum analyzer? It would tell whether the TX signal is available and on the correct frequency.

Cheers, heke

Hi Heke ,

Yes it does, analog devices provides an app called iio-oscilloscope which allows to control FMComms5 parameters and control TX signal. Precisely with this app I could determine that after including adf5355 in the device tree, depending on the LO frequency, the received signal suffers more or less attenuation.

Cheers, Joaquin.

Hi JoaquinTh ,

OK. Thank you. 

I assume that the iio-oscilloscope probes the RX baseband signal, which means that it is not possible to tell whether the problem lies in TX or in RX. That information would be extremely useful. You would need to cut the loopback and use a spectrum analyzer and an RF signal generator to test each direction separately. 

It is possible that the loopback path is not properly matched. 

Cheers, heke