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 Reply
  • 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?

Children
  • 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