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.

ADS1256 synchronization and multiplexing in a parallel system

Other Parts Discussed in Thread: ADS1256

Hello

I am working on a measurement system with multiple ADS1256 (one channel each). They are all running at the same clock frequency and are synchronized with the external SYNC signal. As soon as I get a dataready-Interrupt from all the Chips (outputs are connected with an AND-gate) all the measured values are read sequentially from all the ADS1256. So far, everything works as expected. Next, I would like to use the multiplexer to measure all the channels of the ADCs. I am a bit worried that I cannot do that without getting out of synchronization, because the multiplexer requires a SYNC and a WAKEUP command after writing to the MUX Register.

The datasheet says:

"the most efficient way to cycle through the inputs is to change the multiplexer setting immediately after DRDY goes low. Then, after changing the multiplexer, restart the conversion process by issuing the SYNC and WAKEUP commands, and retrieve the data with the RDATA command.", datasheet p.21

To me it sounds like I would lose the synchronization between the different ADS1256 Chips because SYNC and WAKEUP is necessary. Is this true? Is there another way to cycle through the channels without lowing the synchronization?

Thank you for your inputs.

  • Hi Yves,

    Welcome to the TI E2E Forums!

    Sending the "SYNC" and "WAKEUP" commands to multiple ADS1256 devices should keep them synchronized as long as there is not much propagation delay (on the SPI bus) between devices. In other words, if you have devices at various distances away from your SPI controller, it is possible that the SPI command received by the device furthest away is delayed enough to lose synchronization.

    Alternatively, you do not have to use the SPI commands to re-synchronize all devices. You can still use the /SYNC pin to restart conversions after switching multiplexer channels! The PCB traces used to connect to all /SYNC pins should also be matched such that there is not an excessive difference in propagation delay between devices -otherwise you run into the above problem that devices are out of sync by a few master clock cycles.

    For either synchronization method, you will have the best results if all devices run off the same master clock, and if the master clock traces to each device are matched in length.

    Best Regards,
    Chris

  • Hi Chris

    Thank you for your answer.

    If I understand you correctly, I can keep the ADCs synchronized with sending a broadcast command to all ADS1256s (all chip select lines are low). Is that correct? Because if I send the commands sequentially they all get slightly out of synchronization, because the start of the conversion is triggered by the first rising edge of the WAKEUP commands, right?

    I am asking this question because my system is a bit more complex and I have multiple ADS1256, multiple SPI busses and multiple MCUs. :-)

    What happens if I do not SYNC after changing the multiplexer? Will I get a mix of the different channels because the internal filter is not resetting?

    I thought about the external SYNC signal as well, but it is used by an additional COM-module which synchronizes the whole system. If I would toggle it every cycle I would always synchronized the complete system. I try to avoid this..

    Cheers

    Yves

  • Hi Yves,

    Correct, broadcasting the SYNC and WAKEUP commands to all devices will keep them synchronized (as long as the previously mention criterion are meet).

    NOTE:
    One thing to be aware of when all devices are active, it that it is possible to have a contention on DOUT. To prevent issues when this happens, it is a good idea to have series resistors on all DOUT pins between each ADC and the DOUT bus. There may still be an increase in digital current (As some devices are sourcing current on DOUT, while others are sinking current on DOUT), but he resistors will limit the current and prevent latch-up or damage.

    Regarding your second question...

    If you do not issue SYNC after changing the multiplexer, you will need to ignore the next five data conversions (as this data will be unsettled). The digital filter is a SINC5 filter that averages the last 5 conversion results. Some applications might not want unsettled data.

    By telling the ADS1256 to synchronize, the digital filter is reset and /DRDY will not go low until settled data is available. As a result, when you multiplex channels the data throughput is reduced. However, this is also what would be expected when a step change occurs on an input.

    If you must write to all devices sequentially in order to switch the input channel, then you would need to ignore the next 5 conversion results after you finishing switching all devices.

    As a side note: Some delta-sigma ADCs automatically restart conversions when you write to a register that changes the input multiplexer or PGA gain. The ADS1256 does not do this. However, I bring this up because such an operation would mess up synchronization.

    Best Regards,
    Chris

  • Hi Chris,

    That was a helpful Input. Thank you for that. I am going to write sequentially to all ADS1256 and reduce the data rate. I will proof sychronization with logging changes on the DRDY signals.

    Thank you

    Yves

  • Hi Yves,

    You're welcome! I'm glad to help!

    Best Regards,
    Chris

  • Hi Yves,

    I recalled another important requirement with the ADS1256 that will impact your application...

    If you decide to use the "/SYNC" pin, then you will have to meet the strict "t16B" timing requirement. The way we've recommended doing so is to use a D-Flipflop to re-clock the "SYNC" pulse to synchronize with CLKIN.

    There is another forum thread that discusses this issue. It can be found here: http://e2e.ti.com/support/data_converters/precision_data_converters/f/73/t/218644.aspx

    Best Regards,
    Chris