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: DRDY signal not Occurring continuously

Part Number: ADS1298


Hi,

I'm not able to get continuous DRDY signals after the RADATC command in ADS1298.

	  ADC1298_START_HIGH();//pull start high
		HAL_Delay(1);
	  EcgSendOpCodeADS1298(ADS1298_RDATC);//after this DRDY is toggled when the converiton has finished
		HAL_Delay(2);

I have configured DRDY pin as interrupt to read the ADC results but the interrupt occurs once or twice only.

The sampling rate is 500 SPS (0x86) and the SCLK has  a baud rate of    FpClk/256 , (FpClk = 80Mhz);

  • Hello Arun,

    Can you record the START, DRDY, and MOSI pins with an oscilloscope or logic analyzer to see what is happening? Table 12 in the datasheet shows how much time it should take from when START occurs to when DRDY begins toggling.

    Brian
  • Hi, I used an Oscilloscope to to see the output form MISO,CS,DRDY and CLK.
    After the configurations are finished and when the START pin is pulled high, the DRDY is toggling as per the frequency(500)that was set.
    I also checked the DOUT , it gives out data along with the clock when DRDY is low,Everything works fine until I connect the DOUT(MISO)
    to my controller(DRDY signal stops here). Everything works fine when I connect the MISO to the Oscilloscope.
    What could be the reason for this?
    Power to the ADS1298 is taken from the MMB0 board with a common ground b/w STM Controller and MMB0.
    I'm using SPI Mode0(hope that this is correct since I'm able to access and modify the registers).
  • Arun,

    Let me make sure I understand. DRDY stops toggling when DOUT is connected to MISO on your microcontroller, but when you connect the oscilloscope to the same line, it begins working again? Can you take a screen capture of this behavior? There must be something happening to either the START pin or the PWDN or RESET pins during the time when no DRDY toggling occurs. Have you observed these pins?

    Brian
  • Hi, Braian

    The Issue is solved , it was the problem with the SPI library that I was using, I rewrote the library in a loop that runs 27 times to send a dummy data and receive one ,now it does't stops and lead off status is coming correct.
    I was trying to acquire the channel data and plot it ,It would be grateful if you could help me with the conversion of the 24bit signed data to millivolt.

    #define ConvertToMicroVolt(code) (int)(((((code^0x800000)-1)*0.2862)/ADS1298_CHANNEL_GAIN)-2400000)

    This is the macro that I use now, can you please verify it?
  • Hello Arun,

    That macro should work to convert the codes to uV.

    Brian
  • Hi,The conversion is working fine and I'm also able to plot the value, but seems like I got a new problem now.
    When I uncomment some part of my code (a digital filter) the DRDY toggles at a lower rate (100Hz) with invalid data o/p and
    when the electrodes are connected(or touched)the DRDY stops toggling immediately.
    Alternately when I comment some portions in the processing(like Heart rate detection,Digital filter etc) , the received data
    are accurate and DRDY do not stops when I connect the electrodes and toggles at exactly 500Hz that was set in both the cases.

    I have connected the STM32 micro-controller with the EVM board, the GPIO pins are not connected,START and DRDY pins are connected apart from the SPI pins. I did not made any changes in the jumper configurations .
    The STM micro-controller is running in 80Mhz .
    As per my observations in the Oscilloscope, the processing is not creating any extra delay.
    What could be the reason or this strange behavior?
  • Arun,

    The best way to debug these issues is to observe the digital communication signals on an oscilloscope or logic analyzer when the strange behavior takes place. This will show you exactly what is occurring in the communication and will point you to the error in the code. If you'd like me to take a look at them, take a screenshot of the communications when the strange behavior takes place and I can help you to analyze it.

    Brian