After several years of doing workarounds for this problem, I have finally decided to post this, in hopes that this will encourage a solution.
The problem arises when I try to acquire data using libiio, using a number of active channels that is not a power of 2 (1, 2, 4, 8, etc.) For instance, if I am using an AD9081, I can acquire data with 1 or 2 or 4 active channels, but not with 3. When using 3 channels, there is actual data returned, but the assignment between the channel and the data returned varies with each acquisition. The workaround that I do in my software, is to either 1) notify the user that 3 active channels is not allowed, or 2) turn on a fourth channel, but not use its data.
For two channel devices like the AD9361, AD9371, ADRV9002 or ADRV9009, this problem does not occur, because 1 and 2 active channels always works.
When we move to 4 channel devices, like the AD9081, AD9084 or ADRV9026, there are 3 configurations that work (1, 2, or 4 channels) and 1 that does not work (3 channels). So, the problem only occurs with 25% of the potential configurations.
When we move to 8 channel devices, like the ADRV9040, there are 4 configurations that work (1, 2, 4 or 8) and 4 that do not work (3, 5, 6 or 7). Thus, 50% of the possible configurations do not work.
Finally, when we move to 16 channel devices, like QuadMxFE, there are 5 configurations that work (1, 2, 4, 8 or 16), and 11 configurations that do not work (3, 5, 6, 7, 9, 10, 11, 12, 13, 14 or 15). In this case about 70% of the possible configurations do not work correctly.
I have built into my software the ability to handle this problem in IIO. I turn on additional channels to get the channel count up to an acceptable number, but just ignore the data in the returned buffer. However, ADI should seriously consider fixing this issue for the sake of others wanting to use devices with 4, or more, channels.
I assume this problem may also exist on the transmit side, but I have not verified this.
Don
