• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 641 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

ADS1299: Noisy data in Single Shot Mode AND No data in continuous conversion mode

Navdeep@Turiya
Prodigy 20 points
Part Number: ADS1299

Setup - We are using 8-channel ADS1299 on a custom board to acquire data from an EEG-Simulator (NETECH MiniSim EEG). The custom board houses an ATMEGA328P-PU to acquire digital data with SPI connections to ADS1299. The MCU is attached to an FTDI Serial to USB converter, which in turn, is attached to a Macbook pro. The code is written in Arduino IDE and uploaded to MCU. The ADS1299 is being supplied with 5V unipolar supply. The Analog input pins of ADS1299 are connected to RC filter before connecting to the analog input. We are using two modes of ADS1299 to fetch data: In the single shot mode, we are acquiring data at 125 Hz and in continuous mode, we are acquiring data at 250 Hz. The input signal is a sine wave of 30 μV amplitude at a frequency of 5 Hz.

Problem - In the single shot mode, the FFT of the signal reveals a noise pattern comprising of multiple ripples. In the time domain, this noise has an amplitude of approximately 5-10 μV (and even more at times), which obscures a signal of 30 μV generated by the signal generator. In continuous mode, however, no signal could be appreciated. We wrote a code to check the toggling of DRDY (Data ready) Pin, but it doesn’t seem to toggle.

Questions:

  1. What is the source of the noise in single shot mode? Datasheet mentions that in single shot mode, the SinC filter resets and takes some time to be functional. During this time, aliasing might be causing noise. Is that so?

  2. Why are we not able to fetch data in continuous mode? Are we correct in inferring that DRDY is not toggling?

  • 0
    TI__Guru 52752 points
    Hi Navdeep,

    Thanks for your post and welcome to the forum!

    I am not familiar with your simulator, but is there a connection for the RLD to reject the common-mode noise from the mains power?
    Is it possible for your to verify the frequency of the noise in the time domain?

    If you are collecting data before the SinC filter resets, then yes the system is more susceptible to noise. Additionally, since the datarate drops in single-shot mode, the rate that the ADC is decimating decreases, and more noise will make it through to the conversion result.

    I am not sure why you are unable to see /DRDY toggle. Have you confirmed that /DRDY is not toggling by probing the device pin with an oscilloscope?

    This post: e2e.ti.com/.../2727329 contains my standard SPI interface debug checklist. Please take a look and verify that you can correctly use the SPI interface.
  • 0 in reply to Alexander Smith
    Prodigy 20 points
    Hi Alex,

    Thanks for the elaborate reply. The simulator doesn't have a RLD connection. We checked the DRDY pin on oscilloscope. We found that it was not toggling. However, when we removed the SDATAC command from the code, the DRDY started toggling. Once that happened, we collected the data in continuous conversion mode and found that the noise has substantially reduced and we could replicate the properties of simulated signal in frequency domain. Previously, after writing registers, we were giving both START and RDATAC command, but it seems that SDATAC given just after RESET is overriding the effect of START and RDATAC given later.
    Could you throw more light on why this could be happening?

    Thanks and Regards,
  • 0 in reply to Navdeep@Turiya
    TI__Guru 52752 points
    Hi Navdeep,

    Please review figure 67. in the datasheet and section 9.4.2.

    This might be the issue: After issuing a /RESET the minimum pulse duration must be set before taking /RESET back high. The RESET command takes effect on the 8th falling edge of the command, and after /RESET is issued, 18tCLK cycles are required to complete initialization of the configuration registers.

    More than likely there is a timing issue of some sort - it could be on power up or most likely initialization. (figure 67)

    Happy to hear that the device is functional! Let me know how further testing goes.