Can cf-ad9361-lpc work with AD9361 in 1rx-1tx mode?

We are trying to write a small piece of code to record RF samples received by E310. The reference example code we use is ad9361-iiostream.c from the libiio/example. We setup the receiving stream channel for I and Q via device cf-ad9361-lpc. The code works well when AD9361 is in 2rx-2tx mode. However, if we change AD9361 to the 1rx-1tx mode, function iio_buffer_refill returns an error code -110. 

What might be the issue here? Thanks!

Top Replies

    •  Analog Employees 
    Nov 5, 2020 in reply to c3commsystems +2 verified
    Michael, It's still a puzzle here. My initial problem happened on the RX path, not TX. So if the AXI-ADC driver is internally connected and will automatically configure for AD9364, why…
Parents
  • 0
    •  Analog Employees 
    on Nov 4, 2020 7:08 AM

    When enabling 1rx-1tx mode in the AD9361-phy device you also need to declare 

    compatible = "adi,axi-ad9364-dds-6.00.a" on the cf_ad9361_dac_core_0 phandle in the device tree.

    otherwise the AXI-DDS-DAC driver will create two TX channels, and you won't feed/push enough data.

  • I am working with to implement this change. Do I need to enable the adi,axi-ad9364-dds-6.00.a driver in the kernel as well? 

  • Hi Micheal, 

    We didn't remove the adi,2rx-2tx-mode-enable; we simply set it to 0.

    debug attr 167: adi,2rx-2tx-mode-enable value: 0

    Is there are programmatic way to remove the attribute or does this need to be done by modifying the device tree file? 

    -Josh

  • Michael, 

    This option is of value 0, which, in our understanding, that 2rx-2tx mode is being disabled. Why it has to be removed?

    As an example, we may want to switch between SISO and MIMO transmissions during operations. So we need to configure that above debug attribute during testing.

  • 0
    •  Analog Employees 
    on Nov 5, 2020 3:46 PM in reply to jmonson

    You must do this in the device tree. Otherwise it won't work.

    -Michael

  • Michael, It's still a puzzle here. My initial problem happened on the RX path, not TX. So if the AXI-ADC driver is internally connected and will automatically configure for AD9364, why I have the problem in the the first place?

    In other word, why the receiving chain problem needs to be solved by changing the configuration on the transmitter. The problem was time out trying to receive data. Why it matters that the DDS core only register one output IQ channel pair?

  • 0
    •  Analog Employees 
    on Nov 5, 2020 7:44 PM in reply to c3commsystems
    Michael, It's still a puzzle here. My initial problem happened on the RX path, not TX. So if the AXI-ADC driver is internally connected and will automatically configure for AD9364, why I have the problem in the the first place?

    Well - let me explain.

    The ad9361 driver stack consist of 3 devices. 

    The ad9361-phy, cf-ad9361-lpc and cf-ad9361-dds-core-lpc.

    The AXI-DAC-DDS driver is totally standalone. That's why it needs it own compatible string.

    Based on the compatible it registers different number of channels, sample sizes, etc.

    The number of channels are important for the IIO buffer DMA to calculate buffer sizes, transfer counts, etc.

    The ad9361-phy driver and the cf-ad9361-lpc instantiate separately since it uses different buses (SPI, platform_bus). However at some point during probe the cf-ad9361-lpc defers probe until the ad9361-phy driver is via SPI fully probed. At this point the cf-ad9361-lpc driver registers the number of IIO buffer channels configured by the ad9361-phy. And here is the issue.

    The ad9361-phy driver has the concept to set parameters with similar names as the dt attributes via debugsfs. When the initialize attribute is written, it reconfigures the device via SPI for the new mode.

    However it does not unregister the IIO devices. So the IIO core still thinks the device has 4 channels.

    And actually this attribute is the only one that doesn't work when set via debugfs!

     

    In other word, why the receiving chain problem needs to be solved by changing the configuration on the transmitter.

    Both iio_buffer_push and iio_buffer_refill can timeout (-ETIMEDOUT ERRNO:110).

    Most of the time people forget to update the compatible string on the independent DAC/DDS device.

    -Michael

Reply
  • 0
    •  Analog Employees 
    on Nov 5, 2020 7:44 PM in reply to c3commsystems
    Michael, It's still a puzzle here. My initial problem happened on the RX path, not TX. So if the AXI-ADC driver is internally connected and will automatically configure for AD9364, why I have the problem in the the first place?

    Well - let me explain.

    The ad9361 driver stack consist of 3 devices. 

    The ad9361-phy, cf-ad9361-lpc and cf-ad9361-dds-core-lpc.

    The AXI-DAC-DDS driver is totally standalone. That's why it needs it own compatible string.

    Based on the compatible it registers different number of channels, sample sizes, etc.

    The number of channels are important for the IIO buffer DMA to calculate buffer sizes, transfer counts, etc.

    The ad9361-phy driver and the cf-ad9361-lpc instantiate separately since it uses different buses (SPI, platform_bus). However at some point during probe the cf-ad9361-lpc defers probe until the ad9361-phy driver is via SPI fully probed. At this point the cf-ad9361-lpc driver registers the number of IIO buffer channels configured by the ad9361-phy. And here is the issue.

    The ad9361-phy driver has the concept to set parameters with similar names as the dt attributes via debugsfs. When the initialize attribute is written, it reconfigures the device via SPI for the new mode.

    However it does not unregister the IIO devices. So the IIO core still thinks the device has 4 channels.

    And actually this attribute is the only one that doesn't work when set via debugfs!

     

    In other word, why the receiving chain problem needs to be solved by changing the configuration on the transmitter.

    Both iio_buffer_push and iio_buffer_refill can timeout (-ETIMEDOUT ERRNO:110).

    Most of the time people forget to update the compatible string on the independent DAC/DDS device.

    -Michael

Children
No Data