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.

ADS1298: In high speed data sampling rate, what is required analog signal stabilization time, and SPI clock speed.

Part Number: ADS1298

Hello,

I'm currently using ADS1298, and having a trouble in using it in high speed sampling rate.

I'm currently converting analog signal, slightly differently from regular usage.

In order to reduce power consumption, I'm trying to make analog signal occur only at a time when converting is carried out ( since my system requires using high current LED to acquire analog signal, it takes a lot of current)

After finding out the time consumed for converting depends on the data sampling rate, (e.g. it takes whole 4ms in 250 SPS mode)

I changed the SPS to 8K mode, even though I didn't need that much speed (about 100 SPS is enough for my system).

And, I tried to ignore 79 conversion results out of 80, turned on the analog signal before 80th conversion begins ( right after 79th conversion DRDY occurs), and then, only retrieve 80th conversion results, which would result in 100 SPS. 

I checked the analog signal stabilization time with oscilloscope, which was about 10us. Given the sampling frequency (8K), I think 10us can be ignored since conversion time is 125us. 

But, the result was failure. Data rate was 100SPS, however conversion didn't work, and was different from oscilloscope waveform.

I tried turning on my analog signal a little bit earlier, like turning on at 78th conversion, 77th conversion, and so on, and turns out when I turned it on at 76th conversion, I got the right ADC results.

With turn of at 76th conversion, I could only reduce power to 4/80 of original power consumption. Still need more reduction. 

One more problem is when using ADS1298 in high speed data rate, it seems I don't have enough time to retrieve the data. 

I'm using 5CH (1~5ch), but I only got 3ch's right data, and rest of 2 CHs(4~5) were not properly converted. 

If I took the SPS down to 4K, 2K, 1K, and all conversions were getting done well. (From at 2K, all coversion started to work well)

My system clock is 1.8M, and I'm having a suspicion that my system clock is low, so SPI communication is not fast enough to retrieve 5ch data with in 125us.

However, with simple math, given SPI speed (system clock/2), it would only take about (3(conversion header)+3(byte per one conversion)*5(# of channel))(total byte)*8(bit per byte) = 144us, assuming that the rest of 3ch are ignored.

The system MCU processed the data retrieval first right after DRDY signal occurs, so I guessed, with the current clock speed, the current system is enough for 4K SPS (250us per one conversion). But, still the last CH(#5) was not properly retrieved. 

In summary,

1)In high speed conversion rate, how early should the analog signal be stabilized before the conversion?

My guess was in 8K mode, just 125us eariler before DRDY signal occurs is enough.

2)In high speed conversion rate(8K), to retrieve multi channel data (5ch) without data corruption, how fast the system clock(SPI clock) should be?

Why the results like these are happening? Am I doing something wrong? or Am I misunderstanding operation of ADS1298?

Please, help me out.

Thank you in advance.

  • Hello Jonghyun,

    Thanks for your post.

    There's a lot of information here, so I'll start with a couple recommendations and we'll progress from there.

    For starters, your system clock input (fCLK) of 1.8 MHz is out of spec for an external clock frequency. The nominal clock frequency is 2.048 MHz with a minimum of 1.94 MHz and a maximum of 2.25 MHz. Also, can you please clarify whether you are using Continuous Conversion Mode or Single-Shot Mode?

    Jonghyun Park said:

    1)In high speed conversion rate, how early should the analog signal be stabilized before the conversion?

    When there is a sudden change in the analog input signal (known as a "step"), the output of the digital filter will take some time to settle to the new value. This is explained on pages 51 - 52. Figure 57 shows the settling time (tSETTLE) as a function of the master clock period (tCLK) following a low-to-high transition on the START pin (or following the START SPI command). /DRDY will idle high until settled data is read for retrieval.

    Figure 58 shows how you need to ignore 3 samples after an input step that occurs while the ADC is already converting. The 4th /DRDY falling edge after the input step occurs can be considered as settled data.

    Jonghyun Park said:

    2)In high speed conversion rate(8K), to retrieve multi channel data (5ch) without data corruption, how fast the system clock(SPI clock) should be?

    The minimum SCLK speed can be calculated as fDATA * (n+1) * 24, where n is the number of channels. For 5 channels at 8 kSPS, you need a minimum SCLK frequency of 1.152 MHz. You should run the SCLK a little faster than that in order to account for the required timing specifications outlined on page 17.

    Let me know if you still need more clarification.

    Best Regards,

  • Hi Ryan,

    Thank you for answering the questions.

    For more clarification, the more details about my configuration is as follow:
    I'm currently using internal clock mode, which I think, means system clock has nothing to do with nominal clock of ADS1298.
    Also, I'm using continuous conversion mode, which I think, means Tsettle depending on master clock doesn't affect much other than first time conversion.

    From your replies, I think first question has been solved. I guess other than first time conversion, the rule I need to follow is when there is step input during continuous conversion, 4th /drdy falling edge after step input should be retrieved. For example, for 8K SPS and continuous conversion mode, when there is step input, 125us*(3~4?) of time should be waited after input step occurs.

    Regarding second question, if I read data with RDATA mode ( I was using RDATAC mode) with opcode, does that SCK speed minimum still apply to my configuration? Because I want to make my SPI clock as low as possible, lower than the time needed to retrieve whole channel output data within Tdr, and I don't need every conversion result, I'm thinking RDATA mode is more suitable  than RDATAC mode for my usage. Is it correct way?

    Best,

    Jonghyun Park

  • Hello Jonghyun,

    Thanks for clarifying. Originally, you were using SCLK = system clock / 2 = 1.8 MHz / 2 = 900 kHz. For 8 kSPS, this will definitely be too slow.

    In RDATA mode, you must account for one extra byte when calculating the minimum SCLK frequency, assuming you wish to read every sample. The minimum SCLK frequency for 8 kSPS will be (RDATA + STATUS + n*24)bits * 8e3 = 1.216 MHz. However, RDATA allows you to read the most recent conversion on-demand and you do not have to read every sample. If your SPI transaction overlaps the next sample, the data will not be corrupted.

    Best Regards,
  • Hi Ryan,

    Thanks for additional information and the replies.

    What do you mean by my SCLK is system clock/2 ?

    As far as I know, SCLK is dependent on master clock(system clock), and not necessarily half of the master clock.

    Actually, I set the SPI clock by half of master clock, though. 

    Anyway back to your mention, I'd like you to clarify the comment that for 8kSPS, 900KHz is too slow. 

    My knowledge is SCLK is not related to operation of ADS1298 since ADS1298 is set to be operated by internal clock. 

    Are you saying 900KHz is too slow to retrieve data within output rate?

    If so, it doesn't matter to me since I won't retrieve every conversion sample, rather I will retrieve once every 40~80 times of conversions using RDATA command. 

    Best,

    Jonghyun Park

  • Hello Jonghyun,

    Jonghyun Park said:
    What do you mean by my SCLK is system clock/2 ?

    You mentioned in your first post "However, with simple math, given SPI speed (system clock/2),..."

    Jonghyun Park said:
    Anyway back to your mention, I'd like you to clarify the comment that for 8kSPS, 900KHz is too slow. 

    900 kHz is too slow to read the data within the output data rate period. Earlier, you were using RDATAC mode and your data was likely corrupted whenever an SPI transaction overlapped the next /DRDY falling edge. In RDATA mode, this is not a concern. You can issue the RDATA command at any time and read the most recent conversion.

    Best Regards,