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

Wrong reading from time to time in a multi-channel application

Mauricio Moroz
Prodigy 20 points
Other Parts Discussed in Thread: ADS1248, ADS1247

Hello,

I´m using a ADS1248 in a multi-channel application. There are three diferent readings: Input A, Input B and Internal temperature.

The registers for Input A are:

MUX0: 0000 1011 (BCS = off, MUX_SP2: AIN1, MUXSN2: AIN3)

Vbias: 0000 1000 (Vbias3 = on)

MUX1: 0011 0000 (Internal ref always on, Onboard ref selected)

SYS0: 0000 0010 (PGA = 1, 20SPS)

 

The registers for Input B are:

MUX0: 0010 1011 (BCS = off, MUX_SP2: AIN5, MUXSN2: AIN3)

Vbias: 0000 1000 (Vbias3 = on)

MUX1: 0011 0000 (Internal ref always on, Onboard ref selected)

SYS0: 0000 0010 (PGA = 1, 20SPS)

 

I have been using the sequence:

1 - Configure for internal temperature reading

2 - Send the SYNC comand

3 - Read the internal temperature after DRDY = 0

4 - Configure for Input A reading

5 - Send the SYNC comand

6 - Read the Input A value after DRDY = 0

7 - Configure for input B reading

8 - Send the SYNC comand

9 - Read the Input B reading after DRDY = 0

10 - Back to step 1

 

This sequence normaly works fine, but from time to time a wrong reading cames up and mess with my process. The signal AD_START is always ON. Could anybody suggest a better sequence for multi-channel operation?

Thanks in advance.

Mauricio

 

  • 0
    TI__Guru 55466 points

    Hello Mauricio,

     

    If the device is running in ‘continuous read’ all the data should be retrieved before the falling edge of the DRDY signal.  Basically, successful read operations in the continuous read mode require the knowledge of when the DRDY falling edge occurs.  (RDATAC is the default mode when the device is powered up with the start pin high; unless an SDATAC command was issued).  If the data is not retrieved before the next falling edge of the DRDY signal, a erroneous reading may occur.

     

    Another change on the sequence is to not re-write to the SYS0 register unless you are changing PGA gains or data rates.  In your example, writing only to the MUX0 register is necessary.

     

    A potential issue is that when cycling through channels, care must be taken to ensure that settling occurs within one cycle.  For a simple change in channel, the user only needs to write to the MUX0.  The section ‘Channel Cycling and Overload Recovery’ in the datasheet (page 34) explains that a brief overload condition can occur during the transmission of configuration data after the completion of the MUX0 byte and before the completion of the SYS0 byte.   To ensure that overload does not occur, it may be necessary to split the communication into two separate communications (SYS0 register first and then a second communication to the MUX0 register).  In the setup above, only writing to the MUX0 register is necessary.

     

    Also, in the sequence above, it is not necessary to send a SYNC command after configuring the device; however, I don’t believe issuing the SYNC command is a problem.

     

    There are a few options on how to write to the registers to change mux channels.  If the device is already in RDATAC mode; as the conversion result is being retrieved, the input channels can be switched by writing to the MUX0 register. (full duplex communication).

     

    Please let me know if this helps,

     

    Thanks and Regards,

     

    Luis Chioye

  • 0 in reply to Luis Chioye
    Prodigy 20 points

    Hi Luis,

    I forgot to mention that I´m not using continuos reading (I never send the RDATAC comand). On my project, it's more interesting to keep multiplexing the channels for every read. So far, I have used the RDATA comand, not the RDATAC. Despite the fact that the START signal is always ON.

    About only changing the MUX0 and not change the SYS0, on my project, the channel configuration (AINs, PGA & Idac) are user selectable. So this situation (changing the PGA between readings) is probably the most common. But is a good suggestion to improve quality and response.

    About the Channel Cycling, the manual I have read before, has not the sections Channel Cycling and Overload Recovery and Single-Cycle Settling, and the page is 30. The file is ADS1247.pdf . Now I have the ADS1248.pdf witn those sections! I´ll try to switch the registers (SYS0 first).

    Two questions:

    1 - Is Over load condition when the AINs x PGA > Ref ?

    2 - Is One cycle the conversion cycle at a SPS selected?

     

    Thanks for your help!

    Regards,

    Mauricio

  • 0 in reply to Mauricio Moroz
    TI__Guru 55466 points

    Hello Mauricio,

    On your first question,  the digital filter needs to reset when the SYS0 register write is issued and also when the MUX0 register write is issued.  The new settings become active after the end of each byte sent, Therefore the recommendation is to split the communication into two commands: first a communication to the SYS0 register and then another communication to the MUX0 register; in this way the digital filter is not overloaded during the time between the completion of the MUX0 byte and while writing the SYS0 byte. Splitting these commands into two communications, allows the digital filter to settle.

    The other matter to keep in mind is to not saturate the chopper-stabilized PGA; i.e. changing data rates while the PGA is saturated can cause the chopper to be unstable.

    On the second question, the data conversion times are given on Table 20, page 35.  The data conversion times are given for an fosc =4.096MHz.  Also, please notice that the first conversion time after a digital filter reset is slightly longer than the second and subsequent conversions times; the table shows the conversion times that correspond to different set up changes.

    Also, I wanted to mention that I believe that if you powerup and start pin is set high and kept high, by default the device is on "continuous read mode" unless the user explicitly have sent a "SDATAC" (stop reading continuously command).  It is also possible to be running on the RDATAC mode and use the RDATA command.  If you already have sent a SDATAC command, then you are not running on continuous read mode.  If you are running on continuous mode, it is important to read all data before the next DRDY; otherwise the user may obtain an erroneous reading.

    Please let me know if this answers the questions.

    Thanks and Kind Regards,

    Luis