Post Go back to editing

Clarification on AD9371 initialization using IIO interface

I had asked a question in this thread: MYKONOS failing due to missing device file 

and was referred to this forum for this question.

I have an SD card which contains a bitstream built from your HDL source, and using the kernel available on github.

My understanding is that you cannot use the userspace Mykonos API which is used on the evaluation SD card, but that Mykonos API is instead compiled into the kernel as a static driver. Furthermore, I was given this reference: AD9371 highly integrated, wideband RF transceiver Linux device driver [Analog Devices Wiki] 

and told that the "standard IIO interface" is used to control the AD9371 on this device.

===========================================================================================

I have taken this to mean that an acceptable means of controlling the AD9371 in Linux is to write to the attributes listed under /sys/bus/iio/devices/iio:device3, as this is what is done in the examples shown on the device driver page. So to change the the local oscillator for the transmitter to 2.5 GHz, for example, an acceptable method would be in C code to perform a system call to write 2500000000 to '/sys/bus/iio/devices/iio:device3/out_altvoltage0_TX_LO_frequency'. Testing this method seems to validate that it works.

===========================================================================================

However, this has led me to confusion, as I have seen conflicting information which led me to believe until now that such a control method was not supported/not possible. An example is in this thread: Re: AD9371 Rx AGC gain table 

where a user asked about the 'gain_table_config' attribute in the standard IIO interface. The responses seem to indicate that the gain_table_config attribute is NOT intended to be used to load the gain tables, and that it's inclusion was a mistake. This also seems to be the case due to the fact that an example "ad9371_std_gaintable" file is listed in the driver documentation, but no such file exists on github, only a 9361 example. The post states that the AGC gain table is now "maintained in source code", which I believe means it now exists as part of the static kernel driver, but if that is the case I am uncertain of how to modify this gain table if required.

===========================================================================================

Additionally, I am still somewhat unclear as to what the expected startup procedure is when using the standard IIO interface. In my previous post to the Wideband API forum, I was asking how to perform the MYKONOS_initArm and MYKONOS_loadArmFromBinary functions which are necessary to initialize the AD9371. Theres is no explicit mention of this initialization in the device driver wiki page, so I do not know if these are automatically performed upon driver probe or if some user action must be done in order to setup the device.

===========================================================================================

Finally, the reason I have been concerned that the AD9371 has not been initialized properly is due to this query: TX Output alignment 

where I am unable to transmit data clearly from the AD9371. Since the digital data being sent looks clean within my FPGA, my suspicion was that the distortion I was seeing was due to my not properly calibrating the AD9371. The recommendation given to me in that query was to use Mykonos API functions to test the state of the JESD interface, but again, I do not understand how to do this via the IIO interface, and I cannot use the Mykonos API directly, so I am at a loss.

===========================================================================================

So to summarize, my questions are as follows:

1. Am I correct in my understanding that the "standard IIO interface" you mention refers to the /sys/bus/iio?

2. At what point are the Mykonos functions 'MYKONOS_initArm' and 'MYKONOS_loadArmFromBinary' called via the kernel driver, and how can I confirm that these were performed successfully?

3. What methods are available to debug the transmitter problems I have encountered using the standard IIO interface?

4. Can the 'gain_table_config' attribute in /sys/bus/iio/devices/iio:device3/ be used to configure the AD9371 gain tables, and if so where is a suitable example of the gain table format?

5. In IIO Oscilloscope, there is an option to switch between DDS mode and direct DAC mode on the transmitter. How would you set this option using the standard IIO interface?

I have been struggling to get this product working for several months now, so any information you can provide would be greatly appreciated.

  • Hi,

    sorry for the long delay. Sometimes I don't receive email notifications. Anyways before I answer your questions.

    Let me comment on the other issues you raised.

    Loadable gain table support: This functionality has always been in the driver. If you have a question about the AD9371 Linux IIO driver, it should be asked on this forum. The Linux driver uses the AD9371 API driver, however it adds a Linux SYSFS interface to it.  The confusion was between the internal default gain table and the dynamic loading option. You're right that the example gain table was missing but I created one last week and it was uploaded.

    1) Yes - IIO communicates with user space via sysfs (/sys/bus/iio) and a character devices. From a plain user interaction point of view this is quite intuitive, since everything is just a file. However when controlling the device from software, this can be quite painful, since you simple want to call a function or method, instead of doing string manipulation and file IO. LibIIO fills this gap, provides all sorts of device abstraction and handles all kind of IIO internals. LibIIO is cross platform and also provides different language bindings, so that you can control IIO devices from C, C++, C# or Python.

    2) In case things fail -

    a) The driver might not instantiate

    b) You would see some error messages on the kernel log buffer

    and

    c) The sysfs interaction will return an error code.

    3) I'm not aware of a transmit issue with the Linux IIO setup. However if you run into issues, the BIST TX->RX loopback option is your best friend. It uses the API functions MYKONOS_setRxFramerDataSource() and MYKONOS_setObsRxFramerDataSource() and allows you to internally loopback your TX data into your RX or OBs while bypassing the entire RF section.

    See below screenshots I took today:

    Some LTE waveform loaded via the OSC AD9371 Plugin and its DAC Buffer Settings:

    TX1 -> Spectrum Analyser

    TX2 -> RX2 external loopback with a straight SMA cable:

    The capture below is now with this aforementioned TX->RX digital loopback.

    (Noise floor is way down)  

    4) Example gain table can be found here: https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/firmware/ad9371_std_gaintable

    5) You would use LibIIO - There is a basic RX example here:

    https://wiki.analog.com/university/tools/pluto/controlling_the_transceiver_and_transferring_data

    For TX you simply use iio_buffer_push() instead of refill.

    -Michael

Before You Switch


Switching languages will make ADI Explorer unavailable. Resume your session by switching back to English and reopening ADI Explorer.