AnsweredAssumed Answered

Double the expected sample rate of AD9361 in CMOS mode (Ettus E310)

Question asked by njp on Aug 1, 2015
Latest reply on Jul 24, 2017 by at8923

I've successfully done an RX-only project based on the Zedboard/Fmcomms2 platform and moved it to a custom board with success. I'm now trying to port the key parts (i.e. not the HDMI, sound, etc) of the fmcomms2 reference design (2014_R2) to the Ettus E310. A big difference from the Zed/fmcomms2 is that the E310 uses the CMOS interface. I appreciate their GNU Radio work but I prefer ADI's approach.


I have SPI comms up and running with the AD9361, and have double checked and had a colleague make sure I don't have any typos in my XDC.


I'm attaching my RX-only CMOS interface code.


I'm also only interested in using 1 of the RX ports, so I've removed 2r2t-enable from my devicetree.


Here's what I'm seeing:

  • it's failing RX tuning (none of the delays give a pass)
  • using Vivado's Chipscope, I can see that the adc_valid out of the axi_ad9361 library component is asserted at double the frequency I'd expect. For example, if the ad9361 sample rate is set to 50MHz, I see adc_valid set at a 100MHz rate. The I and Q are also changing at 100MHz, and their magnitudes same reasonable (low when terminated, increase with a signal)
  • the Ettus E310 uses an external LO. I'm pretty sure the clock frequency is 40MHz (I'm trying to confirm with Ettus). But I get the same results of Tuning failed and double expected data rate with both the ext LO disabled and it enabled/40MHz.
  • Just as a test, I enabled the ext LO in the devicetree and defined it as 80MHz. In this case, Chipscope showed data at the expected data rates. However,  RX tune still failed, and I get the following additional errors:
    • ad9361 spi32766.0: Calibration TIMEOUT (0x5E, 0x80)

      ad9361 spi32766.0: Calibration TIMEOUT (0x247, 0x2)

      ad9361 spi32766.0: Calibration TIMEOUT (0x287, 0x2)

I'm leaning towards it being an error in my devicetree setup or the ad9361 driver mode more so than it being an FPGA bug. This design has worked very well on LVDS platforms and the only change now is the axi_ad9361_dev_if.v file.