• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 46 subscribers
  • Views 944 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.

Correct way to "scan" multiple input channels with ADS1243

Panu Tuominen
Prodigy 90 points
Other Parts Discussed in Thread: ADS1243

Hello,

I am looking for "the correct" way to accomplish the following task with ADS1243:

  • 4 differential input signals
  • the voltage of all four inputs signals should be measured in about 600 ms (i.e. 7.5 Hz data rate is enough)

To fulfill these requirements with slowest possible 7.5 Hz data rate, I have to change the MUX after each conversion (resulting in one conversion per channel only).

1) The main question is that do I need to do DSYNC always after changing the the channel, or can I just wait for DRDY, read the DOR, and then change the MUX to the next channel and wait for the next DRDY? (I.e. is DSYNC always needed after MUX change to ensure that no data is left in the digital filter from the previous channel? )

Naturally I want that the converted value is not affected by which channel was converted just before. Which is better of accurate conversion results: DSYNC always after MUX change or DSYNC never?

2) Another issue was that when I tried to use 7.5 Hz mode (DR=01 with fosc=4.9152 MHz and SPEED=1) and put DSYNC after each MUX change, the first conversion result after DSYNC was about the half of the expected value. The conversion results after the first one had the correct value. When I tried to use 15 Hz mode instead, all conversions (including the first after DSYNC) produced correct values. What is wrong? Or should be first conversion be always discarded after DSYNC in 7.5 Hz mode?

  • 0
    TI__Guru* 98215 points

    Panu,



    Some of the problem may come from an error in this device, but I'll address the questions as you've asked them and add details to the explanation.

    1. First, I think that you generally would want to use the DSYNC to synchronize the conversion. DSYNC is meant to hold the modulator in reset and reset the digital filter in the start of a new conversion. This would most often be used in the manner that you are showing, in the change of a mux so that the conversion results are not combined samples from older configurations.

    2. The issue you describe is something I have not specifically seen, but is similar to something that was noticed recently. When the SYNC command was used in the 7.5Hz or the 3.75Hz mode, the first data completed in half the time, and subsequent data occured in the regular time period. For example in the 7.5Hz mode, the first data took 66.6ms to complete, while the subsequent samples took 133.3ms to complete.

    In your setup, you can check on DRDYn pulse to see if this is the case. If this is correct, then the data you get may be an error from this same problem.

    If this is the problem,  I can only recommend a few solutions. First would be to set the data rate to the default of 15Hz mode. This seems to work fine, and the lower data rates (and their performances) can be achieved through averaging. The other recommendation would be to throw away the first piece of data.

    Another recommendation would be to eliminate the SYNC command but this may require specific timing. If you have the ability to monitor the DRDY pulse, you could make the mux change command just before the DRDY occurred, then you could wait for the second DRDY indication to clock out the data. You would still have lost one data period upon the start, and it doesn't give you exact timing to initiate a conversion, but it does minimize the some of the thrown away data.

    If the error outlined above is not the problem, there are only a few things that can I can recommend to check. I would check on the statuses of bit 6 and 2 of the Analog Control Register (Address 02h). Bit 6 sets the data format to either be bipolar or unipolar. In unipolar mode, the data only reads positive inputs, with a scale from 0V to Full-scale from 000000h to FFFFFFh. This can make the inputs seem like half the range. The other bit (bit 2) sets the range of the ADC so that it becomes +/-VREF or +/-0.5VREF. A bad setting here can also make the input reading seem half the size.

    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 90 points

    Thanks a lot for your comments.

    1. This is exactly as I guessed. It is not mentioned directly in the data sheet; actually I felt the DSYNC description to be slightly too short to understand it completely.

    2. I checked the DRDY pulses, and you are correct: the first conversion after DSYNC completed about half of the expected time (fdata = 7.5 Hz). It is likely the reason for the wrong values. ACR register bits took some time to understand but I have set them correctly; otherwise all data would have unexpected values, not only the first after DSYNC.

    Because the reason is now confirmed, I felt safe to switch to taking two 15 Hz samples and averaging them - it takes the about same time, so I not messing up the timing of this legacy product.

    The device I am working on is a measurement device that has been used successfully for several years. Beside other things I noticed strange spikes in the measurement data, which occurred rarely, once or twice a year. I pin-pointed the problem down to one raw ADC data value, which looked like doubled. - The original developer was simply always using the first data after DSYNC and multiplying it by 2 to get a valid value (obviously a result of trial-and-error).

    However, in some cases, I guess, the software had not time to read the first data after DSYNC and read the second one instead. In such rare occurrences, extra multiplication by two resulted in huge error in the calculated voltage value. The final consequences of this depended on which voltage the software was measuring: for example, if a Pt-100 sensor, which is about 108 ohm in room temperature, was measured, the software got a value of 216 ohm, which is more than 310 °C. Such one-second spike in logged room temperature data is something that you do not expect.