This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS130E08: Configure and read data in Daisy Chain Mode

Part Number: ADS130E08

Hello everyone.

I'm currently working on a project that makes use of multiples ADS130E08 in daisy chain mode. I was able to setup and read data when utilizing just one board, but, when i try to setup multiple boards (each one with a separate ADS130E08) in daisy chain mode, I'm not able to capture the data corectly.

My setup:

- CS, SCLK and MOSI pins are shared between boards.

- CLK_OUT bit enabled.

# First board:

- MISO pin is connected to the microcontroller.

- CLK_SEL pin tied to high logic level (clock is generated internally and outputed to CLK pin).

# Second board

- MISO pin is connected to the DAISY_IN pin of the first board.

- CLK_SEL pin tied to low logic level (external clock source from the first board).

Thanks in advance,

Weslley Duarte

  • Hello Weslley,

    Thank you for your post.

    Are you taking into account the extra "don't care" bit between the LSB of Device 0 and the MSB of Device 1? This is illustrated in Figure 36 of the ADS130E08 data sheet.

    I presume you have the CLK pins shared between the two devices, correct? Once you have configured both devices with the same register settings, you must also pulse the START pin or send the START command to restart conversions and synchronize the DRDYn interrupts to the same CLK edge.

    Regards,

    Ryan

  • Hello Ryan,

    Yes, I'm taking into account the extra "don't care" bit. Also, the CLK (external crystal) is shared between devices and I send the START command after configuration/before reading data.

    When in daisy mode, I'm able to read the data correctly from the first device, my problem is capturing the data from the second one.

    My code for shifting the bits:

    #define UPPER_1_BITS 0x80 // 1000 0000
    #define LOWER_7_BITS 0x7f // 0111 1111
    
    uint8_t rx[40] = {0};
    
    /*
     * rx[0] = empty
     * rx[1 - 3] = status bits (device 0)
     * rx[4 - 19] = data (device 0)
     * rx[20 - 39] = "don't care bit" + 3 status bytes + 16 data bytes (device 1)
     */
    
    uint8_t aux_rx[19] = {0}; // 3 status bytes + 16 data bytes
    
    for (size_t i = 0; i < sizeof(aux_rx); i++)
    {
      aux_rx[i] = ((uint8_t)((rx[20 + i] & LOWER_7_BITS) << 1) | (uint8_t)(rx[20 + i + 1] & UPPER_1_BITS) >> 7);
    }

    Best regards,

    Weslley

  • Hi Weslley,

    When you say you cannot read the data correctly, what does the data look like from the second device? Are you seeing random bits or all 0x00? 

    Let's check a couple other things:

    1. Can you confirm that DRDYn on both devices are synchronized?
    2. Can you share a logic analyzer capture showing one complete frame with STATUS + CH1-8 + "don't care" + STATUS + CH1-8? There should be 305 bits total (2x (24 + 8x16) + 1).

    If you can share a partial schematic showing the ADS130E08 connections, that may be helpful as well.

    Regards,

    Ryan

  • Hi Ryan,

    When I capture the data from the second device, it's all random bits.

    I dont' have a logic analyzer, but I connected the oscilloscope to both DRDY outputs (the second device DRDY is left floating).

    When just the first board is connected to my backplane the DRDY signal of the first board appears every 125us. When I connect the second board, the DRDY of the second board also appears every 125us but then the DRDY of the first one appears every 75s, so they are not synchronized.

    Regards,

    Weslley

  • Hi Weslley,

    Thanks for clarifying. In that case, it may be that the data from the second device is being overwritten with new conversion results while you are reading from both devices. At some point in the middle of the frame from Device 1, you might notice the 0xC00000 STATUS word again.

    Are you able to synchronize the two devices by issuing a common pulse to the START pin?

    Once the data rates from both devices are synchronized, you will need to ensure that your SCLK frequency is fast enough to read all 305 bits within one data rate period. At 8kSPS, you will need an SCLK frequency slightly faster than 2.44 MHz to account for timing specifications.

    Another way to confirm that synchronizing the devices will work is to configure both devices for RDATA mode (not RDATAC mode). In this mode, new data is only loaded into the output shift register when the RDATA command is sent. This allows you to read the most recent conversions results from both devices without concern of new data overwriting the old data in the middle of the frame.

    Regards,

    Ryan

  • Hello Ryan,

    Last week I tried to synchronize the devices with a pulse to both START pins but the result is the same as issuing the START command, the DRDY interrupt occurs at every 75us.

    I also increased to frequency to 3Mhz and was eventually able to capture data and read both boards correctly with RDATA command, but wasn't able to fix the interrupt to occur every 125us as expected.

    In conclusion: sometimes I'm able to read the data correctly, sometimes not.

    Best regards,

    Weslley

  • Hello Ryan,

    I increased the SCLK to 4MHz and I'm now able to always read data from both devices with RDATA command. The weird thing is that the data from the first device (blue) is not clear as the second device (orange).

    The DRDY keeps happening at every 75us. Do you think that can be related to the bad signal quality when reading the first device?

    Edit: Both signals come from a signal generator (separate channels, same amplitude and frequency) and are only phased in 180° from one another. When reading individually, both signals are ok.

    Thanks in advance.

    Weslley

  • Hi Weslley,

    The DRDYn signal from each device is not related to the quality of the signal at the ADC inputs. It is strictly dependent on the master CLK (internal or external), the internal oversampling ratio (OSR) and the START pulse or START command. In order to synchronize devices with the START command, you must first issue STOP (0Ah). Otherwise, the START command has no effect.

    If DRDYn from either device is not matching the expected data rate, and you've confirmed that both devices are receiving the same CLK signal, then the only explanation is that the data rate is not programmed correctly. Can you write to both devices, then disconnect CSn from one device and read back the register contents? Do this for each device to confirm they are the same. Remember - in order to write registers, you must issue the SDATAC command first. Are you doing this already?

    It may also help if you can share a partial schematic of the two ADCs and a scope capture showing the CLK and DRDYn waveforms.

    Regards,

    Ryan

  • Hello Ryan,

    I was able to fix the issue and read data correctly. The problem was happening due to a faulty wiring on my circuit.

    The only thing that I'm stiil trying to solve is the DRDY pulse at every 75us.

    Best regards.

    Weslley

  • Hi Weslley,

    Thanks for the update and glad that you found the wiring issue!

    Regarding DRDYn internal, might I suggest trying to configure both devices to use the internal oscillator? If both devices are then configured for the same register settings and issued a START pulse at the same time, then both DRDYn pulses will be synchronized to within one tCLK period. Can you see if this works?

    Regards,

    Ryan

  • Hello Ryan,

    It worked.

    I used the internal oscillator as you suggested and was able to synchronize both devices in DAISY mode to output the DRDY signal every 125us.

    Thank you for all the help.

    Best regards,

    Weslley

  • Hi Weslley,

    Thanks for letting us know this worked. It would seem that originally, the two devices were not using the same clock frequency. For the most accurate synchronization, either both devices must receive the same external clock, or one device must output its internal clock to the other device. If synchronizing to within one clock period is sufficient, then both devices can use their own internal clock and we can close this thread. 

    Regards,

    Ryan