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.

ADS1248 Conversion Result is Always 0 or 0x7FFFFF

Other Parts Discussed in Thread: ADS1248

Hello,

I am interfacing with an ADS1248 ADC using an Arduino Mega 2560 via LINX (the current LabView interface for Arduino). The chip is currently mounted on a TSSOP 24 breakout board and peripherals to the chip (capacitors, resistors ect) are breadboarded. 

I have established that I can read and write registers. I do however suffer a leading 0 after every register result read back and have to read a second byte to retrieve the last bit. This, however is due to the LINX firmware being buggy and only having SPI mode 0 functional (reading on the rising edge rather than falling).

In reference to the attached schematic, here are register values I have set:

MUX0: Burnout current off, Positive: AIN3, Negative: AIN2

VBIAS: Off for all pins

MUX1: Internal oscillator, Internal reference always on, REF0 Pair selected, External REF0 measurement

SYS0: PGA:128 SPS:5

IDAC0: only DOUT function, 1000uA

IDAC1: First current source: IEXC1, second current source: Disconnected

GPIOCFG: All are AIN

The remaining registers have their default values.

My pseudo-code for reading data is as follows:


1) Start brought high

2) SPI opened and wakeup command given

3) 16 ms delay for start up

4) Stop reading data continuously (SDATAC)

5) Read Data (RDATA)

6) wait for conversion to complete

7) send 32 SCLKs (four NOP commands) -> four instead of the usual three as I have the previously mentioned bit shift of one - so the final bit of the third byte is contained as the first bit of the Fourth byte

The result is now either 0 or 0xFFFFF.

I would be very grateful if you could assist me in locating the issue.

Jack

  • Jack,


    There are two things that I want you to check and both are problems in the communications.

    1. First make sure the /CS is selected low for the entire communication transaction and not low byte-to-byte. It's possible with the latter case, there are problems with the SPI getting reset.

    2. You need to make sure the data is being read on the falling edge of the SCLK. You'll get errors from reading on the rising edge, like the shifting that you describe, but there may be other hold time errors. I think you'll just have to get the SPI mode to work.

    After that I want you to read all the registers and report them back. Just in case, I'll want to see the Offset and Full-scale calibration registers as well.

    If neither hint pans out, then get an oscilloscope or logic analyzer and get a scope plot of /CS, SCLK, DIN, and DOUT. With a logic analyzer, you'd be able to grab /DRDY as well. Once you get the plots, post the results back here and we can look through it.


    Joseph Wu
  • Hi Joseph,

    Thanks for the reply. I will address all of your points in order:

    1) The same thing still happens even if CS is tied low

    2) There is little I can do about the SPI mode problem. This is a problem with LINX which I could theoretically correct but lack the programming knowledge to do so very quickly. The best I can do is accept that I have this bit shift and compensate for this in software.

    Regarding register reports: as stated previously, all registers are being writeen correctly as subsequently reading that register returns the expected result.

    I have just got a logic analyser and will have to work out how it functions today. I will then report back with a screenshot.

    I have made some progress however. I saw that I was violating the first inequality in table 17 of the data sheet due to my gain value being too high (128). Having set this lower I now get seemingly random results!

    Could you also link to how to convert this ADC output into the resistance of the RTD? I know there is some formula that I found but I now cannot find it.

    Regards,

    Jack

  • Jack,


    You really should solve the SPI mode problem. If you don't, you'll get errors in the communication. Some errors may not involve the entire transaction, but imagine getting a single bit error. It would be difficult to take any reading and trust the value. I had originally suspected that your read problem was because the device was not properly interpreting the RDATA command.

    Also, I wanted to you to report the register contents for several reasons. Granted, the first was to make sure the transaction could be done properly (which you've stated you can). However I wanted to make sure that any writing was in the correct place in the registers. Lastly, there are a few other registers like the offset and full scale calibration registers that affect the measurement. If these are wrong, the you might get very large errors. Either way, really wanted the hex readout of all 15 registers.

    Now that you've gotten some data, can you report back the data you get. Often it helps to see what the ADC is reading. If you can send back the ADC code for about 100 measurements. That way we can see if the data has periodic noise or if there is some other pattern in the data that we can see.

    For the RTD measurement, makes sure the excitation current comes through RTD and then goes to the reference resistor. Make sure the proper reference input is selected (across the reference resistor).

    What value of RTD are you using? What value of reference resistor are you using?

    Using the a known resistance as a reference, the excitation current goes through the RTD and then to the resistor alone. In this case the measurement is ratiometric, meaning that you don't care what the absolute voltage is, only what the ratio from the measurement to the reference is.

    In this measurement, equation becomes:

    (RTD/reference resistor) = (ADC code)/2^23

    I put some links about the ADS1248 and RTD measurement in a previous post that you can find here:

    e2e.ti.com/.../1534239


    Joseph Wu
  • Hi Joseph,


    I've made some progress today. The voltage reference is now detectable and the excitation current is being sent. the solution stranglely came from reversing the order in which the registries were written. Odd.


    The measured temperature now does vary as you would expect but there is a huge offset (about 400 degrees C) in the reading which is equivalent to about twice the expected resitance in the RTD.


    Is there a particular manner in which I should send calibration commands?


    The values for the Bias resistor and RTD are as per the original schematic (PT100 and Rbias = 850ohm)

    Thanks for your continuing help

    Jack

  • Jack,


    It still worries me that you had to reverse the order in which you write to the registers. I'm just concerned that you don't have the communications completely correct and it might lead to some bad data later on. If you want to look into it, post a scope shot or logic analyzer output, and I'll look it over. However, if you're sure that you able to read and write to the register directly, I'll move on to the next thing.

    You say you have a large offset that is about 400C. To track that down, I'll need some more information. First, how much resistance does that equate to? What excitation current are you using? How do you have this set up (two wire? three wire? four wire? How do you route the excitation currents?). I want to know what ADC output codes that you are getting and to relate this back to the voltage value you would get for the measurement and for the error that you have now.

    There are two things to be concerned with. First is that the excitation current should only go through the RTD and then the reference resistor. There shouldn't be any other current paths out of these two devices or any leakages or there may be an offset. Second, you have to be concerned with any series resistances with the inputs. This would include any filter resistances that the excitation current goes through. This latter problem is very common and I would suspect this is what you are seeing.

    It might help to have a schematic of what you are doing in your system. At this point I'm just making guesses. It also might prove out the problem you are having.

    When it comes to calibration I generally only do a self offset calibration only. There is a PGA in this device and there is a gain calibration coefficient that is trimmed into the device at final test. Every time the PGA gain is set, the gain calibration coefficient is set to the factory value which is accurate. If there is a large systemic offset error, I prefer not to use the system offset calibration and just try to find and remove the error.

    However, if you do use both a system offset calibration and a system gain calibration, perform the system offset calibration first.


    Joseph Wu
  • Hi Joseph,

    The Setup is exactly as the first schematic I had posted, has this not appeared for you?

    There is 1 mA passing through the PT100 and I observe a voltage drop of 0.85V across the reference resistor as expected.

    The only resistance that the analogue inputs suffer is that from the wire resistance (about 6cm of solid core) which I am skeptical to have any effect.

    I still can't get this logic analyser to work so please wait out on the Logic shots.

    A temperature of about 400 degree corresponds to about 220 Ohms resistance for a PT100, which, as I said, is about twice the amount you would expect a a PT100 typically has a resistance of about 110 Ohms at room temperature.

    As for the writing of registries in the reverse order, I only thought to do this as It was the solution for a few people encountering communication problems on this forum! It apparently worked for me too.

    Please let me know if you wan't see the schematic. You have asked for one a couple of times now and I posted in on my first post.

    Jack.
  • Jack,

    Sorry, I look through so many questions that they get a bit mixed together. I can see your schematic. However, I noticed on your schematic that you have the positive and negative input of the RTD both tied to AIN3. Assuming that you are really measuring from AIN3 and AIN2, you route the current through IEXC1 and do a 4-wire ratiometric measurement. Since there isn't any filter resistors or other series resistance, it should be clean.

    Is it possible that you've accidentally set the PGA to a gain of 2? That would answer this question quickly if you're measuring 220 Ohms and should be seeing 110 Ohms. If this isn't the case, I'd measure the RTD directly and see what voltage really is there.

    Another thing to try would be to replace the RTD with known resistor values. See what value comes up when the resistor is 200 Ohms, then 400 Ohms and then 800 Ohms. Just measuring a few different input values would determine if the error is a gain error or a large offset. You'll also need to measure the resistance directly to make sure the voltages are correct.

    Joseph Wu

  • Hi Joseph,

    Yes, the analog input thing is just an error.

    I will try and follow what you say.

    So does the PGA gain have an effect on the reading other than reducing noise? How does this come into the equation converting from the ADC code to resistance?

    Jack

  • Jack,


    The PGA is just a programmable gain amplifier, so it will scale the output code upward with the gain. Note that the gain will be defined by the SYS0 register as gains in factors of 2 to 128.

    So the way you have it set up, the reference resistor is 850 Ohms. Since the excitation current is going through the RTD and then the reference resistor the output code is representative of the ratio of the RTD and the reference resistor. So for a PGA=1:

    (RTD resistance/Reference resistance) = (ADC output code/2^23)

    So if you have an 850 Ohm reference resistor and the RTD is at 110 Ohms, the output ADC code might read about 1085585d or 109091h.

    With the PGA, the output code scales. Adding in the PGA into the equation:

    (RTD resistance/Reference resistance) = (ADC output code/(2^23*PGA))

    So if PGA=4 and the same resistances you would get 4342338d or 424242h. I would note that your reference resistor accuracy is directly related to the accuracy of the measurement. Any leakages out of the RTD/reference resistor path and any series resistances in the measurement path can be errors too.


    Joseph Wu
  • Hi Joseph,

    Figured out the problem. The breadboard was decaying a bit and the two resistors in series we were using for the precision resistor were not adding correctly. We now get the measurement we expect.

    Thanks for all the information you have given.

    I do have one (probably) final question;

    In reference to the reduction of noise with lowering the sample rate; is this because the ADC is converting at the same speed so producing 5SPS includes a lot of averaging whereas 2000SPS does not? Could you clarify this for me?

    Jack

  • Jack,


    The ADS1248 is based on a delta-sigma (also known as oversampling) ADC. At the core, there is a modulator that is repeatedly sampling the input, using many samples to generate one data output. I wrote a blog a few months back generically explaining how a delta-sigma ADC works combining a modulator and digital filter. If you want, you can peruse the links below:

    e2e.ti.com/.../delta-sigma-adc-basics-understanding-the-delta-sigma-modulator

    e2e.ti.com/.../delta-sigma-adc-basics-how-the-digital-filter-works

    With 5SPS, you will get far more samples to generate the ADC data than you would at 2kSPS. In a sense, it is like averaging more to get a lower noise floor, but it's a bit more involved.

    A second consideration is that with lower data rates you get lower noise because of the bandwidth of the digital filtering. At 2kSPS, there is a fairly wide bandwidth, while at 5SPS, you filter out any nearby line cycle noise at 50/60Hz based on the digital filter.


    Joseph Wu