• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 1296 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.

Issues with ADS1248 using RDATA

George Benko
Prodigy 50 points
Other Parts Discussed in Thread: ADS1248

I'm using an ADS1248 and am sending the following commands:

Setup:

send SDATAC (turn continuous read off)
wait for ready

send WREG reg=1,2 len=2 values=0x00,0xa0
wait for ready

send WREG reg=0xa,0xb len=2 values=0x04,0x89
wait for ready

These settings appear to work as we are more or less getting the correct readings most of the time.

Once a second:

wait for ready signal
send WREG reg=0 len=1 value=0x05 (Ain0)

wait for ready signal
send RDATA

wait for ready signal
send WREG reg=0 len=1 value=0x0D (Ain1)
* keep the 3 bytes that come back as Ain0 reading

wait for ready signal
send RDATA

wait for ready signal
send 3xNOP
* keep the 3 bytes that come back as Ain1 reading

I'm seeing spikes on the first channel (should be reading 2.048 V (correct)) - but i occasionally get ~1.7408 (85% reading).
The second channel isn't seeing spikes and that is reading around ~0.819 V (correct).

Time timing for my SPI transmission is as follows:

wait for ready signal
select ADC (chip select on (low))
delay 2us
interrupts off
push command bytes into SPI queue
interrupts on
wait for response back from SPI (when bytes tx == bytes rx) - all done via interrupts
delay 4us
deselect ADC (chip select off (high))
delay 3us
keep the rx bytes if relevant (ie. take a reading)

The SPI driver is not running at highest priority - there is potentially another task that can interrupt it (except where
interrupts are off).

  • 0
    Prodigy 50 points
    Oh yeah - if anyone could help point out what i'm doing wrong? Why am I getting the spikes and how do I fix it?
  • 0
    TI__Guru* 97465 points
    George,


    You've given some good information, but offhand I don't see anything that would be a problem.

    Are you able to share a schematic? What are you measuring? What are you using for the reference?

    From the digital side, it's good that you started with the SDATAC command and subsequently use RDATA to get data. This means that you don't have to be as careful using the /DRDY, and that new data won't interrupt the readout of the device. Note that there could still be some sort of occasional error in the SPI communication, like noise on the SPI line.

    It might help to get a logic analyzer to make sure that the ADS1248 is putting out what you think it is. If there is an error in the data transaction, it might to help to capture the error from the digital communication coming directly from the ADC.

    With the first channel you say you read something near full scale (2.048V) is this 7FFFFF? Are you over-ranging the input? The occasional error is about 1.7408V. This would be about 6CCCCD. Is this correct? It might help to record a long string of data, and report back the results. I'd prefer the hex data and not the voltage conversion.

    How often do you take data (is it really about once a second)? How often does this error happen? Is the error periodic?

    From the analog side of things. Could there be a problem with the input? If the input is clean, is there a possible problem with the reference? If the input measuring low by about 15%, then it's possible the reference is 18% high (from 1/0.85). One last thing would be that maybe there's an error in the power supply that translates to either the input or the reference.

    Again, I don't see anything that is outright wrong and would give this error. Hopefully I've given a few ideas things to try and check.


    Joseph Wu
  • 0 in reply to Joseph Wu
    TI__Guru* 97465 points
    George,


    One other thing - what data rate are you using? If you are at 2kSPS, there are some unusual restrictions on the SCLK rate to get single-cycle settling for the ADC. This is outlined in the section titled Single-Cycle Settling on page 34 of the datasheet.


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 50 points

    OK - I'll go through my settings for you:

    initialisation - SYS0 register (0x03):

    • PGA is set to 0 - which gives a gain of 1
    • Output data rate set to 8 - which should give 1000SPS (so no we aren't going at 2kSPS)

    initialisation - VBIAS (0x01) - zero - bias voltage not enabled

    initialisation - MUX1 register (0x02):

    • external oscillator in use (bit 7 = 1)
    • internal voltage reference - internal reference always on
    • reference input from ADC - REF0 input pair selected

    initialisation - IDAC0 register (0x0A) (value=0x04)

    • DRDY MODE - DOUT/DRDY functions only as Data Out
    • IMAG2 - current source DAC - set to 500uA

    initialisation - IDAC1 register (0x0B) (value=0x89)

    • output pin for first IDAC is IEXT1
    • output pin for second IDAC is IEXT2

    OK so now to answer your questions:

    The schematic is below - I hope it works. We're looking at the first ADC on the schematic.

    We're measuring 4 wire RTD and analog voltages - check the schematic. But at the moment for this test we're only looking at 2 analog inputs.

    The reference is on schematic.

    Full-scale: 2.048 is full scale yes - and this would be equivalent to 0x7FFFFF - you are correct 0x6CCCCD or round about is what we are reading when we get the spikes.

    We're sampling only once a second at this stage yes.

    OK - so we've done a few fixes since but the error was happening maybe 1 in 10 to 20 samples - the error was random in nature. We put an extra wait Ready and NOP before doing the RDATA and this seems to have fixed the problem - however we would still like to know why it is/was happening. One thing to note is that the measurements were more reliable previously before I cleaned up and sped up the code we were getting random spikes very occasionally - 99.9% good. Also a few other things we found:

    • we tried other in range measurements (<2.048V) and we were getting similar results.
    • the spike was either up or down based on the previous measurement (AIN1) (even if the measurement was a second ago). So a high previous measurement would cause a spike upwards - a low would cause a spike downwards.
    • nothing is happening with the ADC in between the sampling.

    We think it unlikely there is a problem with the input - we're feeding them from the reference. Peak to peak noise is one part in 20000 *(~100uV).

    We think the reference is good (check schematic).

    ADS1248_partial_schematic.pdf

  • 0 in reply to George Benko
    Prodigy 50 points
    Just to clarify the reading was jumping around a bit - so we were not getting 0x6CCCCD exactly (1.7408 ) - I too thought there might be something about the bit pattern - I worked backwards from 1.74079 - which was giving me 0x6CCCA3 using some python code. But sometimes it was lower.
  • 0 in reply to George Benko
    TI__Guru* 97465 points
    George,


    I've looked through your schematic, and I don't see anything that is obviously wrong.

    I see that you have gas discharge tubes on the inputs, so I'm a bit concerned that there are transients that come up that the ADC has a hard time recovering from. I don't have much experience with these and I'm not sure what type of recovery time these have when they are tripped (to be honest, I don't imagine this is the problem). Aside from those, the rest of the schematic looks pretty normal.

    At this point, I'd say that there are two ways to track this down.

    First, I'd verify that the data is correct. Perhaps there's an error in the python code in capturing and sorting the data. I'd try to get a scope capture of the communications and get the MISO, MOSI, SCLK, /CS, and DRDY coming out of the ADC itself. A logic analyzer would really be handy, but you might be lucky enough to capture it with an oscilloscope. Regardless, I think it's important to verify that this is the data coming out of the ADC itself. I'd also check to see if there are any resets issued that turn off the SDATAC mode. If that happens, then you will update the DOUT with new data each time a new data becomes available. If that's the case, then you might have new data interrupting the read. It's unlikely that you'd get the same error each time, but it depends on how you have the system setup. Since adding the extra ready and NOP seemed to help, it's possible you've changed the read timing to miss the /DRDY indication.

    If you are able to capture this data error and it still reads this 0x6CCCCx result, I'd start looking at the different possible problems associated with settling in the analog channels. I know you cycle through different inputs and have different settings for what you read. You could try to vary some of these settings. With the extra NOP, you add a small wait time, but you could also try different data rates or reading multiple reads from the same channel. You could even use the START pin to initiate each of the ADC reads. All of these would test to see if there's settling issue in the analog read. Also, If inputs are over-ranged then there might be some recovery time involved. It could be changes in any input or the reference, or if you change to a very high PGA gain without changing the input to something smaller first.

    Regardless, that's how I'd approach the debugging. Hopefully this might lead you to where the problem came from.


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 50 points
    Thanks for your suggestions. I’ve got it going well at present with a NOP before the RDATA command and no problems, so moving on to other tasks for now. May revisit later...
  • 0 in reply to George Benko
    TI__Guru* 97465 points
    George,


    Thanks for the update. If you have any follow-up on the readout, feel free to post back.


    Joseph Wu