ADS1299: Sampling problem or SPI comunication? TEST Signal having strange artifacts!

Hi Moises,

Thanks for your post and providing detailed information!

This looks like data corruption and you are certainly right that the MISO signal is behaving strangely. Can you provide some additional information on the commands being sent? Is SDATAC being sent prior to sending RDATA? Default is RDATAC mode.

Hi Alexander,

Thanks for the quick response.

First, I must say that I'm using the device in RDATA mode and  to answer fast  to your question, Yes the SDATAC command is sent prior to sending RDATA, here is how:

void ads1299_init()
{
    // ADS1299 Power up
    ads1299_PWRUP();

    // Stop Conversion for Configuration
    ads1299_SDATAC();

    // ADS1299 ID
   check_deviceID ();
    


    // ADS Register Configuration:
    ads1299_wreg(CONFIG1, 0X96);
    ads1299_wreg(CONFIG2, 0xD0);
    ads1299_wreg(CONFIG3, 0xE0);

// ADS CHnSET configuration:

       ads1299_wreg(CH1SET, ADS1299_PGA_GAIN01 | ADS1299_INPUT_TESTSIGNAL | ADS1299_INPUT_PWR_UP);
       ads1299_wreg(CH2SET, ADS1299_PGA_GAIN01 | ADS1299_INPUT_TESTSIGNAL | ADS1299_INPUT_PWR_UP);
       ads1299_wreg(CH3SET, ADS1299_PGA_GAIN01 | ADS1299_INPUT_TESTSIGNAL | ADS1299_INPUT_PWR_UP);
       ads1299_wreg(CH4SET, ADS1299_PGA_GAIN01 | ADS1299_INPUT_TESTSIGNAL | ADS1299_INPUT_PWR_UP);
       ads1299_wreg(CH5SET, ADS1299_PGA_GAIN01 | ADS1299_INPUT_TESTSIGNAL | ADS1299_INPUT_PWR_UP);
       ads1299_wreg(CH6SET, ADS1299_PGA_GAIN01 | ADS1299_INPUT_TESTSIGNAL | ADS1299_INPUT_PWR_UP);
       ads1299_wreg(CH7SET, ADS1299_PGA_GAIN01 | ADS1299_INPUT_TESTSIGNAL | ADS1299_INPUT_PWR_UP);
       ads1299_wreg(CH8SET, ADS1299_PGA_GAIN01 | ADS1299_INPUT_TESTSIGNAL | ADS1299_INPUT_PWR_UP);

    // Start the conversion PB6 START PIN HIGH
    GPIO_SetBits(GPIOB, GPIO_Pin_6);


}

As you can see in this part of the code, I have a function for the power up sequence, then shortly after send the SDATAC command which is shown below. Then I check for the device ID, configure some registers and then the individual channel registers, set the START pin high, and that's it.

void ads1299_SDATAC()

{

//  CS LOW
GPIO_ResetBits(GPIOD, GPIO_Pin_7);

// SEND SDATAC
SPI_send(_SDATAC);

// CS HIGH
GPIO_SetBits(GPIOD, GPIO_Pin_7);

// WAIT 2*TCLK'S = 888ns aprox 1us
delay(micro(1));
}

The RDATA command is sent in a different function used only for reading the data, like this:

void ads1299_rdata(uint32_t *statusDATA, int32_t *realDATA)//

{

    //CS LOW
     GPIO_ResetBits(GPIOD, GPIO_Pin_7);

    // SEND READ DATA MODE
     SPI_send(_RDATA);
          

 HERE is the code for reading the data for the 8 channels 
 and converting it from Two complement.


   //CS HIGH
   GPIO_SetBits(GPIOD, GPIO_Pin_7);

    // WAIT 2*TCLK'S = 888ns = 1us
    delay(micro(1));
}

I'm using an interrupt for  DRDY. Here I'm calling the ads1299_rdata function, then Every time I have 250 samples, I'm saving them in a buffer, and then triggering another interrupt that takes care of sending the data via UART to the computer.I believe there shouldn't be any conflict on how I'm sending the SDATAC and RDATA commands.

I hope you can help me out with this,  It has been  difficult to debug this problem.

Thanks again for your time, I'll be waiting for your answer.

Moises.

 

Hi Moises,

Try exploring the UART transfer. It could very well be that data is not being fully transferred before the next round of samples is produced. Try changing the sample rate as well to see if that has an effect or not.

Thanks Alexander,

I'll change the sample rate, check again my UART communication and come back to you.
However the MISO line and the SPI interface is still independent from what is happening with the UART communication and how I'm handling the data to send it via UART.

Best,

Moises

Hi Moises,

How is testing going?

Hi Alexander,

I've been playing around with the problem with the next conclusions:

-  I try changing the SPI port on the Master just to discard a port problem, but the behavior on the MISO line remains the same, regarding the Data Rate.

- I incremented the output data rate, and the result is even  worst, as you can see on the image more artifacts appear, when I utilize a higher Data Rate. This is at 500 SPS

Also, to discard that the UART is influencing somehow on the SPI, I took off all the UART code and let just the SPI COM resulting in the same data corruption on MISO line.

Just for checking, I connected an External Signal (a sin and a square wave) from a Signal generator in one of the channels, and let the internal signal on the other ones, and the signal looks fine (well reconstructed) , the frequency is fine, but the amplitude I'm not sure. However,  I just realize the frequency of the test signal is wrong, a complete duty cycle should be every 250 sps, which is not happening

There is a lot going on here, so right now I have no clue how to approach the problem, What could be causing this ?

Thanks in advance,

Moisés

Hi Moises,

Thank you for the detailed information and solid debug steps!

Take a look at your code to voltage conversion according to this post: e2e.ti.com/.../2856893
Since you only see the issue near the transition, perhaps there is something small in the loop that is causing the issue such as reading 25 bits instead of 24, starting the count from 1 as opposed to 0, etc.

In the mean time I'll ask a colleague about the behavior seen on the MISO line.

Hello Alexander,

I was just writing you when I received your message.

I've checked how I'm converting the data, basically is here:

void ads1299_RDATA(uint32_t *STATUS, int32_t *DATA)//

{


    // PULL CS LOW
     GPIO_ResetBits(GPIOD, GPIO_Pin_7);

    // SEND BYTE: 0x11 READ DATA MODE
     SPI_SEND_ND(_RDATA);


     uint8_t inByte;


     // Read STATUS register (1100 + LOFF_STATP + LOFF_STATN + GPIO[7:4])
     for (int i = 0; i < 3; i++)
     {
    	 inByte = SPI_SEND_ND(0x0);
    	 *STATUS = (*STATUS << 8) | inByte;
     }

	//  read 24 bits of channel data in 8 3 byte chunks
     for (int i = 0; i < 8; i++)
     {

         for (int j = 0; j < 3; j++)
         {
          inByte = SPI_SEND_ND(0x0);
          DATA[i] = (DATA[i] << 8 ) | inByte;
         }

     }

     // need to convert 24bit to 32bit; convert 3 byte 2's complement to 4 byte 2's complement
     for (int i = 0; i < 8; i++)
     {

    	 if (DATA[i] & 1 << 23) { //If MSB is 1 

    	 DATA [i] |= 0xFF000000; //Retain the sign 


    	 }
    	 else { 

    		 DATA [i] &= 0x00FFFFFF; //Retain the sign 
    	 }
     }

   // PULL CS HIGH
   GPIO_SetBits(GPIOD, GPIO_Pin_7);

    // WAIT 2*TCLK'S = 888ns = 1us
    delay(us(1));
}

I'm converting the 24 bits to 32 bits just retaining the sign, both positive and negative, I've followed some of the examples  found here: 
https://e2e.ti.com/blogs_/archives/b/precisionhub/archive/2016/04/01/it-s-in-the-math-how-to-convert-adc-code-to-a-voltage-part-1
and here https://e2e.ti.com/support/data-converters/f/73/p/699762/2587855#2587855 . After when calling the RDATA function I just multiply for the LSB, 

However, on the link you provide me, Is written If the MSB = 1, you must first subtract 2^n from the decimal equivalent, why this is necessary ?
After the conversion from 24 to 32 bits is it necessary to check again for the MSB again? 

Thank you for the guidance, Is really appreciated.
Best,

Moises

by the way, do you have any information about what I'm seeing on MISO line ?

Thank you again.

Hi Moises,

The code is ultimately up to the customer and I'm not familiar with your external MCU so I can only offer limited support here.

I don't understand why your 24bit data is being converted to 32 bit, I also question this line: if (DATA[i] & 1 << 23).

Something is incrementing your code strangely such that an MSB bit is flipped. This is only seen on the transitions, the issue is probably more apparent when measuring an AC signal.