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.

ADS1282: SYNC and pulse-sync mode acquisition

Part Number: ADS1282

hello, we plan on using 1 ADS1282 in pulse-sync mode (non-continuous mode).  I'm having a hard time understanding the datasheet on how to drive the SYNC pin, or if I even need it.  

assuming that CLK is 3.125 MHz and SCLK is 1.5625 MHz.  when I want to do a conversion, do I need to assert SYNC and do a RDATA command, or just one of those?

Is SYNC even needed? I'm looking at section 8.3.23.2 in the ADS1282-SP datasheet and it seems to indicate that a RDATA command will start the conversion.

if SYNC is required, do I still need to do a RDATA command?  if Yes, when is the RDATA command supposed to happen?

In general, is there more information somewhere on how to properly do acquisition in pulse-sync mode?  the datasheet needs to be revised. 

thanks

  • Hi Mike,

    The ADS1282 SYNC pin (or SPI command) is really only required if you need to synchronize ADC conversions to a specific point in time, for example if you want to synchronize multiple ADCs to begin converting at the same time. Otherwise if the device is powered, clocked, and not held in reset or power down mode it will always be converting. I agree, the purpose of this feature could be more clearly defined in the datasheet.

    The RDATA command is only used to fetch the ADC data after a conversion completes (indicated by the signal /DRDY going low). Typically, you would want configure your MCU to interrupt on the /DRDY falling edge and to read the data soon after the interrupt to avoid losing data (which can happen if you do not read this data before the next /DRDY falling edge).
    - In SDATAC mode, you must send the "RDATA" command byte each time you want to read data.
    - If you are using the RDATAC mode, then you do not need to send the "RDATA" command byte before clocking out data, therefore you can read the data with 1 fewer SPI byte.

    I hope that helps,
    Chris
  • hi Chris, we have a 32 channel mux as the source for the analog inputs, so we are assuming that we won't be in RDATAC mode. the order of operations is to: [set the mux channel] --> [wait] --> [send the RDATA command] --> [read in the data]

    what I'm still confused about is what initiates a conversion: the SYNC pin, the RDATA command, both, or neither.

    I think you comment implies: [do something to initiate a conversion] -> [wait for DRDY to go low] --> [send the RDATA command] --> [read in the data]. is that right?

    BTW, there is a typo in the datasheet: table 11, RREG row, 1st command byte column: should say 001r rrrr
  • Hi Mike,

    Mike Valvo said:

    what I'm still confused about is what initiates a conversion: the SYNC pin, the RDATA command, both, or neither.

    I think you comment implies: [do something to initiate a conversion] -> [wait for DRDY to go low] --> [send the RDATA command] --> [read in the data]. is that right?

    RDATA doesn't initiate the conversion, but the SYNC command will. Technically, writing to the device registers will automatically restart the ADC conversions, so you don't even need to send the SYNC command to initiate conversions.

    So your program would [configure the device registers] -> [wait for DRDY to go low] --> [send the RDATA command] --> [read in the data].

    Does that make sense?

    Please note that the FIR filter has a very slow time-domain response, so if you plan to multiplex between 32 channels, you'd probably want to use the SINC5 filter with a much faster settling time (~5 conversion periods compared to the ~63 conversion periods of the FIR filter).

    Also, the fastest data rates of the ADS1282 do not leave enough time for the SPI peripheral to clock in all of the data, so unless you are okay with truncating the data, I would recommend using the slower SINC5 filter data rates (8-32kSPS).

    Best regards,
    Chris

    P.S. Thanks for pointing out the typo, you are correct!

  • still a little confusion, but I'm getting there...
    sending a high pulse to the SYNC pin does the same thing as the SYNC command, yes?
    (assuming yes) and assuming that I'll use the SINC5 filter, my program would:
    [set the mux channel] --> [wait] --> [assert SYNC pin high for at least 1 SCLK period on the falling edge of SCLK] --> [wait DRDY to go high and wait 5-6 clocks] --> [send the RDATA command] --> [wait until DRDY goes low] --> [read the data in].
    Is that correct?

    can I do the same thing in continuous mode? (do the same procedure without sending the RDATA command)

    also, because there is a filter involved, is it recommended to take several/many samples per (external) mux channel, or would it be ok to only get 1 sample per mux channel? assuming the former, how many samples would I need to get properly filtered data?

    I'm not sure what you meant in your last sentence, can you explain?
    thanks
  • Hi Mike,

    Yes, the SYNC pin and "SYNC" SPI command both restart the ADC conversions; however, I should point out that there is a very strict timing requirement on the SYNC pin, so unless you have the ability to finely control when the SYNC GPIO signal changes, I would recommend using the "SYNC" SPI command.

    Refer to the following thread for more details on the SYNC pin timing:

    Mike Valvo said:
    (assuming yes) and assuming that I'll use the SINC5 filter, my program would:
    [set the mux channel] --> [wait] --> [assert SYNC pin high for at least 1 SCLK period on the falling edge of SCLK] --> [wait DRDY to go high and wait 5-6 clocks] --> [send the RDATA command] --> [wait until DRDY goes low] --> [read the data in].
    Is that correct?

    /DRDY is an active low signal so you would want to wait for the /DRDY signal to go low and then read in the data. When reading data you simply send the "RDATA" byte, wait 24 fclk periods, and then follow it with additional "00h" command bytes to clock out the data (no need to wait for /DRDY again). Other than that your program sequence looks correct.

    Mike Valvo said:
    can I do the same thing in continuous mode? (do the same procedure without sending the RDATA command)

    Yes you can, but you would need to send the "RDATAC" command before /DRDY goes low to enable this mode. Their probably isn't much benefit to using this mode unless you are really time constrained when trying to read out all of the data before the next /DRDY low pulse.

    Mike Valvo said:
    also, because there is a filter involved, is it recommended to take several/many samples per (external) mux channel, or would it be ok to only get 1 sample per mux channel? assuming the former, how many samples would I need to get properly filtered data?

    The ADS1282 will wait until the digital filter has settled before /DRDY goes low, so you do not need to count conversions or throw away the first few results. The first /DRDY pulse will just appear to have a period that is about 5 times longer than normal (5/fdata between SYNC high and /DRDY low).

    Mike Valvo said:

    I'm not sure what you meant in your last sentence, can you explain?

    "Please note that the FIR filter has a very slow time-domain response, so if you plan to multiplex between 32 channels, you'd probably want to use the SINC5 filter with a much faster settling time (~5 conversion periods compared to the ~63 conversion periods of the FIR filter)."

    ...You can equate the FIR filter to a digital filter with 63 taps, and the SINC5 filter to a filter with 5 taps (there is a bit more to it than that, but I'll make this comparison for sake of this conversation). Therefore, the first settled ADC conversion occurs after 63 or 5 conversion periods (respectively) when all of the digital filter taps have been filled with data. Again, the ADS1282 won't set /DRDY low until all of these taps have been filled with data, but when multiplexing this can drastically reduce your overall effective data rate.

    Each time you issue the SYNC command, the digital filter will reset and the filter taps will need to collect additional data. Therefore, for the SINC5 filter operating at 8kSPS, your effective data rate will be just under 8kSPS / 5 = 1.6kSPS. And for multiplexing between 32 channels, each channel will only be sampled at an effective data rate of 1.6kSPS / 32 channels = 50 SPS / channel.

    Best regards,
    Chris