Post Go back to editing

Libiio buffered measurements are not working with the Max11617 when the device has 12 channels.

Category: Software
Product Number: L
Software Version: 0.21

Hi,

We have a two setups where we're using the MAX11617 device with libiio. With the first setup, we have an 8 channel device and we're able to buffer and read all 8 channels correctly. When we switch to the 12 channel device, using the exact same code, we are unable to read the same 8 channels correctly. What comes back appears to be just garbage. If I only enable one channel, the values in the buffer look to be correct. If I disable the buffer and read each channel, the values look correct in that case as well. 

The strange thing is, the only thing that has changed is the device package. In both cases it's the MAX11617, it's just that in the second case there's 12 channels available rather than just 8.

Thanks,

Rory

  • A little more information:

    I've upgraded libiio to V1.0. This hasn't resolved the issue.

    We're attempting to read 10 channels at 1kHz and this is with SCL running at 400kHz. I'm wondering if we're going to fast for the device? Even so, it works on the first setup and it doesn't work on the second setup no matter how much I slow down the sampling rate. 

  • I've been reading the buffer by acquiring the address of the first sample and the address of the last sample and then looping through it. I just tried using the 

    iio_channel_read_raw() to do this more easily but I'm finding this function just hangs on the second setup. On the first, it seems to work as expected. 
  • Is there anyone from ADI who can help with this?

  • Hi  ,

    Sorry about the late reply. When you said the only thing changed is the device package, it means you switched from an 8 channel MAX11617 to a 12 channel MAX11617? I am not aware of an 8 channel MAX11617. 8 channel devices in the family are MAX11614/MAX11615. Could you double check if that is the case?

    Thanks,

    Kevin

  • No worries,

    Now that you've mentioned it, I took another look at the data sheet and realized I was confused. The (N.C) markings on the QSOP package through me off. I thought the QSOP package we had on our test bench (first setup) had a reduced number of channels and our HW team had placed a different package with all channels connected on our board (second setup). Now I realize we have the QSOP on both setups and this has all 12 channels. So then the only difference between the two is that channels 8, 9 and 10 are connected to an analog stage.

  • Hi,

    When you said the only difference between the two setups now is that the problematic one has channel 8, 9, 10 connected to an analog stage. Are you trying to read from these three channels then?

    Previously you mentioned you are not able to read from the same 8 channels with the same code. Does that mean your problematic setup is still reading from the same 8 channels as your working setup but with channel 8~10 connected?

  • Hi, 

    Yes, sorry I have to revise what I said a little more.

    Setup 1: I'm using libiio to read from channels 0 through 10 on the MAX11617. This is on a breakout board so I've been testing channels individually meaning some will  be floating some will not but I've never tested channels 8, 9, 10 on this setup so they were always floating. All of the channels I tested returned values that matched my test signal.

    Setup 2: I've deployed the same image that uses libiio with a buffer to our custom hardware that is also using the MAX11617. Channels 0 through 10 are all connected to a signal and now the buffer no longer returns values that make sense. If I disable all but one channel, the enabled channel returns the correct value. If I disable the buffer and read channels individually, the values make sense. 

  • Hi,

    After I discussed this with my team, we think this is very likely a libiio problem. None of us are familiar with the platform, so I recommend contacting technical support first and see if they have any knowledge on libiio: Support | Analog Devices

  • Hi again,

    So after some investigation, we think the issue is because our hardware is using an isolator with a monodirectional clock. It looks like the ADC needs to provide some clock stretching when we scan channels and it's unable to do this because of the isolator. If we could setup the device to use an external clock for the conversions, our problems possibly could be solved as it will no longer need to stretch the clock. It seems the MAX1363 driver by default configures the device to use an internal clock. Is it possible to use the driver to configure the device for using an external clock?

    Thanks

  • Just to add to the above comment, selecting a different isolator might not be an option for use. It's difficult to find a part with a bidirectional clock that fits are creepage/clearance requirements.