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

Precise timing on a multiplexed ADS1248

Kyle Blay
Prodigy 130 points
Other Parts Discussed in Thread: ADS1248, ADS1274, ADS7924, ADS1258

Hi,

My application:

3 channels, each sampled at 250 Hz (so 750 Hz aggregate sampling rate or 1.33 ms period).

Having the correct sampling rate is very important for my application. (I want to start a conversion every 1.33 ms)

At first I thought I could simply sample continuously at 1000 SPS and discard 1 channel, but I then I realised that if you want to multiplex, you need to write MUX0 which slightly lengthens the time between samples and I'd have an effective sampling rate slightly less than 1000 Hz.

So my planned approach now is:
 - have a reliable timer-driven interrupt on the START pin that initiates a conversion
 - wait for DRDY to assert (after ~ 1 ms at 1000SPS)
 - Send the RDATA command
 - Send the WREG command to update the MUX0 while reading out the 24 bits of data  (*)
 - Deassert the START pin
 - loop.
By my reading of the datasheet, leaving the start pin high while updating the MUX0 will start a new conversion (see *).  If I deassert the start pin then re-assert it a short time later, before that conversion is to complete, will the ADC restart the conversion ?

e.g. at 1000 SPS, it takes 1 ms to perform a conversion and I'd deassert the START pin shortly after the conversion then re-assert it ~0.33 ms later (for the next measurement at 750 Hz).

So my question - will this work?  

If I had it running at 2000 SPS, the first conversion would complete @ t = 0.5 ms, and it'd get  another conversion at t ~= 1.0 ms (which would have to be discarded because at 750 Hz sampling rate, the next conversion shouldn't start until t=1.33 ms).

Secondly, in the datasheet it talks about sending an RDATA command in the last 8 bits of the readout of the previous RDATA command.  I understand it's possible, but I fail to understand why this example is given - why would you want to read out the same data twice in a row, it'd be identical?  This question is just my curiosity getting the better of me, have I missed something?

Cheers,

  Kyle

  • 0
    TI__Guru** 113765 points

    Hi Kyle,

    We do have parts that reset the filter with Start even if the device is converting, however I'm pretty certain that the ADS1248 does not work in this way.  I would have to do some further investigation to know for sure.  However, if you really need to be precise, then I think there is a few other things to consider. 

    One thing to note is the internal oscillator runs typically at 4.096 MHz.  However, this can vary as much as 5% either direction.  As far as resetting the device, there are other ways to do this.  One is by using the SYNC command.  Instead of pulsing the Start pin, you could just send a SYNC command.  Another method would be to adjust the SCLK speed so that when you read the data you adjust the register write command to fit the desired timing.  This is the type of thing that is being referred to by the multiple RDATA commands that can be sent in succession.

    Let's say your data rate is 1000 sps.  That means new data is available every 1ms.  The first data will take the RDATA command and 24 clocks of data.  If you set the SCLK rate to 24kHz, then you can successfully transfer new data every 1ms (1/24000 * 24 clocks = 1ms.)  The RDATA command will not be included in the cycle as it is always given in the last portion of the previous cycle's read.

    For your particular case, I would also set the data rate to 1000 sps and keep SCLK at 24kHz.  In this case you change things up a bit.  You still have the RDATA command, but this time you base the timing on the mux write.  The mux write command is issued at the same time as you clock out the data.  Your total transaction time is 32 clocks (1/24000 * 32 clocks = 1.333ms.)

    You may remind me that there is time asscociated with resetting of the filter.  The required time is 1.014 ms and not 1 ms as designed.  That is actually ok as you are basically sending continous clocks to read the data every 1.33ms.  The problem here is that it is not very practical as you really don't have time to process the data in any way.

    As you can see it would be more practical to send the SYNC command at higher SCLK speeds, or set a timer interrupt to write the mux register at the proper interval.  Really though, how important is it to make measurements at precise intervals?  If it is very important, you might want to consider using a device like the ADS1274 that has simultaneous sampling converters.  There are also devices that autoscan like the ADS1258 (delta-sigma) or ADS7924 (SAR).

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 130 points

    Just to follow up on this in case anyone was wondering, I've tested out my technique and it appears to work quite well:

    to recap, I want to sample 3 channels, each at 250 Hz.  (So 750 Hz aggregate).

    I set the SPS to 1000.

    I have a timer-driven start-pin at 750 Hz  (T=1.33 ms) and an interrupt routine for the data ready pin.

    So the start-pin asserts (t=0), and a conversion starts.

    A short time later (slightly more than 1 ms), the data_ready pin asserts.

    My ISR queues up the SPI peripheral to read the data out and switch to the next channel, after the SPI transfer is complete it de-asserts the start pin. (t < 1.33 ms)

    This cycle then repeats, at t = 1.33 ms, the start_pin is asserted again..

    This appears to give me a nice stable 750 Hz sampling rate.

    Thanks!

  • 0 in reply to Kyle Blay
    TI__Guru** 113765 points

    Hi Kyle,

    I'm glad to hear you were successful!

    Thanks for the update,

    Bob B