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 Delayed reading

Other Parts Discussed in Thread: ADS1248

Hi, all.  This is a rather strange problem, and I've not seen any questions similar to it in the forum.  I'm using an ADS1248 communicating with a TM4C123 processor via the ROM_SSI commands. Everything appears to be working fine. The readings are solid, and I can switch through the multiplex inputs fine.  However, it take three readings of the data before I get the value of either the input of the channel or any other input.  At 5SPS, that means it can take upwards of 1/2 second or longer before a change in input value is reflected in the reading.

For example, I'm reading 1,000,000 counts at a specific input voltage. Cutting the voltage in half, when it should show 500,000 counts, takes three readings before the 500,000 appears. It remains at 1,000,000 counts for those first two readings after the change. I'm thinking the two delays are the conversion buffer (first delay) and the transmit register (second delay).  Once those two items have the proper readings in them, the third read gives me the value I'm looking for. 

So, is this normal operation for the ADS1248?  And if so, is there a way to circumvent these delays so that I can get the proper reading right after a change in input occurs (with corresponding sample delay times, of course), and not delayed by three read actions?  Thanks!

  • Bob,


    Generally, it should not take 3 readings to settle to the final value. The ADS1248 is single cycle settling so the value should be settled within 1 reading.

    However this still requires some explanation. You need to know when the input changes with respect to the start of the conversion. Note that the ADS1248 does not have a sample and hold. Let's use your example of a 1,000,000 count output changing to 500,000 counts. If the input changes instantaneously and changes at exactly the same time as the start of a conversion, you would read 1,000,000 and then 500,000 at the completion of the conversion.

    However, the input is being continuously sampled through the conversion interval. If the input changed at the middle point of the conversion, you would be get read of 1,000,000 and as the input changed in the middle, the next conversion data would be put together when the input was being read at 1,000,000 counts and 500,000 counts. This would give you 750,000 counts as the data. After this conversion completes and the input is at 500,000 counts, you'd 500.000 counts in the next conversion. Since the change in input is asynchronous with the sampling, you may need two conversions to get to the final value.

    In the ADS1248, if there is a change in the input configuration (channel, data output rate, PGA, etc) the converter restarts as soon as the change is implemented and starts a new conversion so that the data is reading from a single configuration. If the input change is something that you can synchronize, the input could change and then you could restart the conversion with a pulse on the START pin, or through a SYNC command issued to the device.

    I would also note that because the input is being continuously sampled through the entire conversion interval, it does give the data a frequency response depending on the output data rate. This frequency response is defined in Table 9 on page 26 of the datasheet. This may also contribute to the delay. However, it shouldn't be a factor in DC changes.

    For your problem, I'm not sure what the problem could be. Exactly what is it that you are measuring? Is it possible that the input change is being delayed because of input capacitance? What values are you getting before and after the change (I'd like to know what the ADC data is and not converted data)? What configuration are you using (data ouptut rate, PGA setting, input channels, reference settings, etc). Do you have any scope photos of the input and how fast it settles?

    Regardless, let me know if any of these comments are of help. If you give more details about the system, I can better answer your question.


    Joseph Wu
  • Thanks for the quick response, Joseph.  Yes, I'm familiar with what you're saying, but I'm fairly sure this isn't caused by what you're describing.  We're measuring fairly small voltages like those of a load cell.  Ratings are typically in the mV/V range, with a full scale differential input of 15 mV. We're using the default input channels of AIN0 and AIN1 set as positive and negative inputs respectively, a conversion rate of 10SPS, PGA gain set to 128, external reference (REFP0 & REFP1). Our prototype board is currently in development testing, so we're using a mV/V load cell simulator as input on our test bench. The 1248 is set for continuous conversion with the START pin held high, leaving the 1248 in its default RDATAC mode. The read data command is three NOPs sent to the ADS1248 with the resulting three bytes returned assembled into a single 24-bit value, sign-extended to 32 bits. This value is what we're expecting for the input voltages applied to the ADS1248.

    What made me suspicious was a delay I was seeing from a change in the input mV/V setting (rotary switch selected in 0.2 mV/V steps) to a change in the displayed reading. It appeared to be taking upwards of 1/2 second or more to update. We update the displayed reading 5x a second, so a 1/2 second-plus delay is quite noticeable. I modified the program so that I could single step the entire process.  I could then change the input value, and manually trigger the read input/update display. A specific input, say 5 mV, produces a stable output count expected for that value with just minor digit bauble easily attributable to noise. The input value is then changed to 6 mV, and the read/update is triggered again. It returns a value similar to the that prior to the input change, again with minor digit bauble for noise.  That tells me this is a new conversion still using the old input voltage before the input was changed. As mentioned in my first post, the output of the ADS1248 again repeats (with minor bauble again) for a second read/update. So two definite conversions on the old input voltage. On the third read/update I get the reading expected for the new input value. I would interpret that to mean the ADS1248 is remembering two conversions prior to the change in input, and it doesn't appear to be updating its output until the third read data sequence.

    The amount of time between input voltage change and the manual read/update trigger makes no difference.  I've worked from fractions of a second up to several seconds between actions, it still takes three read/updates to get the proper reading while the ADS1248 maintains old readings for the first two.

  • Bob,


    In RDATAC mode, once the conversion is complete, the data is immediately uploaded to the DOUT register to be clocked out. That's why I think it shouldn't be the ADS1248 giving you the latency. In other ADCs, there are higher order sinc filters and the latency can stretch to several conversions, but not in this device.

    I would start by reporting back the data you get from the transition. It might help to see how the data changes with the change in input. If you can, post the output data from the ADC. I'd prefer raw data and not something converted to a value.

    I would also look at any input filtering that you have on your schematic. This would include any TVS diodes that might be in the input path, as they may have significant capacitance and increase any time constant for the change in the input.

    Another thing to try would be to increase the data rate to something much faster to see if the delay in time is constant. This is similar to the comment on filtering I mentioned previously.

    What model of load cell simulator are you using? I don't suppose you have the schematic for it? It is possible that this device is the cause of the delay. I assume that it's based on a set of switches and resistor dividers, but there may be capacitance used to filter out the noise and it's possible that the delay comes from output filtering. As it is, the ADS1248 is running at 10SPS, which has a -3dB bandwidth of 4.76Hz.

    Is it possible to record the input change with an oscilloscope along with the data output? This would require a scope with a large amount of memory, but it would show the data exactly where the change happens. Also, you can get rid of the load cell simulator and use some sort of simple divider. This would give you a large enough signal to measure and trigger off of with the scope.

    Let me know if you can share any data or schematics.


    Joseph Wu
  • That's just it, Joseph. The data isn't being immediately loaded to the DOUT register. We're reading the output of the 1248 directly at this point. It's what the chip is sending to the TM4C123 controller. So if there is any delay, it's in the controller's ROM_SSIDataGet and ROM_SSIDataPut routines that we're not aware of. As far as we know, they're supposed to supply the latest information received. This is our read routine for the 1248:

    uint32_t * prcvdata;
    uint32_t i32RcvdValue;

    (Manual trigger to arm for a reading, waits for the *DRDY line to go high then low to assure a new conversion before the reading is taken.)

    //ADS1248 read data routine
    //Read MSD
    ROM_SSIDataPut(SSIBase, 0xff);
    while(ROM_SSIBusy(SSIBase) {
    }
    ROM_SSIDataGet(SSIBase, prcvdata);
    i32RcvdValue = i32RcvdValue | ((*prcvdata) & 0xff);
    i32RcvdValue = (I32RcvdValue << 8);

    //Read MD
    ROM_SSIDataPut(SSIBase, 0xff);
    while(ROM_SSIBusy(SSIBase) {
    }
    ROM_SSIDataGet(SSIBase, prcvdata);
    i32RcvdValue = i32RcvdValue | ((*prcvdata) & 0xff);
    i32RcvdValue = (I32RcvdValue << 8);

    //Read LSD
    ROM_SSIDataPut(SSIBase, 0xff);
    while(ROM_SSIBusy(SSIBase) {
    }
    ROM_SSIDataGet(SSIBase, prcvdata);
    i32RcvdValue = i32RcvdValue | ((*prcvdata) & 0xff);

    From this point for testing, the i32RcvdValue is sent to an RS-232 terminal (Hyperterm) for display. As I mentioned in my last post, I've set the system up to manually trigger this routine. The simulator uses only 0.01% resistors. There are no caps in it. The input to the 1248 has 100 pF caps to ground on each input, and a 10 pF cap across the input terminals. Each input also has a 1.5K resistor in series. The simulator's effective resistance is 350 ohms. Here is an example of what we're seeing:

    The simulator is set for a 5 mV output (AIN0 - AIN1)
    The absolute voltage of both inputs is very close to the middle of the reference voltage.

    After the power-on reset delay, the registers are configured, and the 1248 counts (raw data) are taken as follows:
    Input i32RcvdValue (in counts from the ADS1248)
    5mV 0 <== Note after power on we get two readings with zero counts
    5mV 0
    5mV 1074067 <== Proper reading for a 5 mV input
    5mv 1074082
    5mV 1074081
    5mV 1074057
    6mV 1074013 <== Here the input was changed to 6 mV before the reading was taken
    6mV 1074032
    6mV 1288766 <== It took two readings before the change to 6 mV was reflected in the ADS1248
    6mV 1288837
    6mV 1288798
    6mV 1288783
    5mV 1288840 <== Switched back to 5 mV
    5mV 1288798
    5mV 1073987 <== Again, two readings before the change was seen in the ADS1248 output
    5mV 1074029

    These are the proper counts for the input voltage value. Switching to any input voltage takes two readings before the change is shown in the ADS1248 output. We ran a test on the complete scale from 0 to 15 mV input and found the linearity to be better than 0.01%, well within our acceptable tolerance. So the 1248 is converting properly. It's just those two reading delays that are a problem as it delays system response. Added information, we've tested six ADS1248s, and all of them exhibit the same behavior.

    I tried turning off RDATAC and went to a manual START for the 1248. The effect was to add another reading to the delay. So, conversion ==> conversion buffer ==> transmit register ==> readout?

    I'm really at a loss here. Any light on the matter would be appreciated.
  • I am an idiot.  Public admission.  Joseph, you were right. The problem was NOT the ADS1248. It was the TM4C123 microcontroller's SSI routines.  More precisely, the fact that there is an 8-byte FIFO in both the TX and RX side.  As it turns out, I send the ADS1248 a six byte configuration...which filled the RX FIFO with six characters. Six characters equals two value data reads of three characters each.  That was the 2-reading delay.

    The fix: Add a RX FIFO read routine after each configuration character sent to the ADS1248 to keep the RX FIFO empty. The reading now updates following the first conversion after a change in input value, as it should.  Sorry for putting everyone out for what was my oversight...definitely learned more about the ADS1248 and TM4C123 today.

  • Bob,


    I'm glad you were able to solve the problem. Based on what I know about the ADS1248, I was pretty sure that the ADC wasn't the source of the delay. Thanks for posting back with the solution.


    Joseph Wu