analogdevicesinc / TransceiverToolbox

MATLAB toolbox for ADI transceiver products

Home Page:https://analogdevicesinc.github.io/TransceiverToolbox/master

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

FMComms5 Multichip Synch

Codedial06 opened this issue · comments

Hi,

  1. )
    The Multichip Synchronization that is called within the init-function of Rx.m does not seem to work:

https://github.com/analogdevicesinc/TransceiverToolbox/blame/d1a745221f759e2a483cdb45cf2bf7a79961961e/%2Badi/%2BFMComms5/Rx.m#L297

I tested it with a power splitter and length matched cables, manual fixed gain, all tracking mechanisms off, every time I start my script to fetch a few samples, I get a changing and totally random phase offset between both devices. I even installed libad9361-iio, no changes.

2.)
Please provide a short public method for MCS, as it must be done after each change of the LO-frequency. I tried adding this, but it doesn't work either:

function MultiChipSync(obj) setupLibad9361(obj); calllib('libad9361','ad9361_fmcomms5_multichip_sync',obj.iioCtx,uint32(3)); end

I called it after each change of the RX-LO, but every time there is a different random phase offset between the samples of the devices.

Thank you very much

MCS does not address phase differences related to the LOs. It simply aligns the converter sampling times. AD9361 has no built in mechanism to fix phase differences. This was only introduced in the ADRV9009 family of transceivers.

So what you are observing is expected.

Thank you, Travis, for your quick answer. I think there is a misunderstanding here: since I am using FMComms5 (Rev C), which utilizes an external LO, the phase mismatch between the devices after the MCS should be 0 or 180 degrees (according to https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms5-ebz/phase-sync).

I understand that FMComms5 doesn't provide any RF-synchronization, but only baseband synchronization.

I used NO-OS before and each time I did a MCS the phases were perfectly aligned under the testing circumstances that I described, namely after each startup and also each time I changed the RX-LO and called MCS, no issues.

There must be something wrong with the MCS provided by the Transceiver Toolbox.

Also, could you quickly review the function I wrote above for the MCS please?

Yes the MCS usage is fine. This is basically what the FMComms5 class does.

Are you using No-OS with Transceiver Toolbox? Can you explain what software you are using?

Hi, thanks for your quick answer again.

Right now I am using the AD Kuiper Linux image on ZC702+FMComms5 together with the MATLAB (R2023b) Transceiver Toolbox on Win10 PC. Everything is updated just a few days ago again.

Before that I was using the HDL reference design together with bare metal NO-OS without IIO-support, no Transceiver Toolbox. The command for MCS I used was "ad9361_do_mcs(ad9361_phy, ad9361_phy_b)" the same as it is used here:

https://github.com/analogdevicesinc/no-OS/blob/c91c1282568d4078721495311037cc65b06675ad/projects/ad9361/src/main.c#L655

The MCS worked perfectly fine with the setup before, therefore I am so confused why the MCS of the Matlab Toolbox doesn't seem to work.

So I doubt this is a Transceiver Toolbox issue. Can you verify you get the correct behavior through IIO-Scope? There is a MCS Sync button part of the FMComms5 plugin.

The Linux driver may have different behavior than the No-OS setup. Also have you verified use of external LO with Kuiper?

Thank you very much, I think this should be the root of the problem. The MCS button in IIO-OSC has never been working, and after checking the device status - internal LO was set by default. Unfortunately, there is no devicetree for Linux with ZC702 where the ADF5355 PLL-syntheziser is used, so I have to manually change it. I will report after I have done that but now everything makes a lot of sense.

Issue is solved, no problems after using the external LO