• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 46 subscribers
  • Views 492 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ADS1148 MUX not switching at published rate.

Devon Mahn
Prodigy 140 points
Other Parts Discussed in Thread: ADS1148

I am working with an ads1148, 2-wire RTD setup. I have been able to get stable valid reads with the chip, but when I set my driver up to cycle through the input channels via MUX, I have not been able to meet published MUX switching times, and I must send the MUX commands several times for it to work correctly.


When switching channels in the driver, I write to both the IDAC and MUX register. Interestingly I can immediately read these registers after I write them, and the read will come back correct, but the changes take several seconds to actually switch, and not at a consistent rate. Not only that, but I must write the registers several times before the changes will take effect (even though after the first write they will read correctly).


We are running 2kSPS, and not in continuous data mode. When running at a slower SPS rate and in continuous mode, the behavior is the same but more severe.

Thanks for any help. I will be happy to provide any more information to help get to the bottom of this issue.


-Devon Mahn

  • 0
    TI__Guru* 97425 points
    Devon,


    It could be that you are seeing the settling time of the measurement. If you are changing the IDAC current value or the location where it is sourced, there could be some RC time constant in the measurement. If you have a large capacitance across the RTD or the reference resistor has a large capacitance with a change in current, it may take time to settle.

    Additionally, if you are powering on and off the device including the internal reference, there may be time required for the reference to settle (which may be a function of the capacitance on REFOUT).

    I'd recommend reporting back the data as you had done in one of the previous posts. Include the data rate and data that you've gotten from switching between channels. Also include what you are measuring (RTD value and other passives on the input). I'd also like to see how long it takes to get the right value. If you need to use an excel file to report back the data, that's fine.


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 140 points
    Joseph,

    Thanks again for your responsiveness. It seems I have already solved this issue though.

    My delay after the last SLCK low and before CS high, seemed to be directly proportional to how long it takes the MUX to switch.

    It seems my assumption that If i could read the register correctly, then the MUX should switch was wrong. Even though I could read back the register, the MUX would not switch consistently without a longer delay there.

    Interestingly it also seems this was the only command that required a longer delay (not longer than published spec, but longer than I had).

    Anyways I now have a fully functioning driver. Thanks for all the help!

    -Devon
  • 0 in reply to Devon Mahn
    TI__Guru* 97425 points
    Devon,


    Thanks for posting back. I wouldn't have expected the hold time for /CS to affect the MUX switching in quite that way.

    If you have any other questions, let me know.


    Joseph Wu