• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 46 subscribers
  • Views 497 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ADS1293: Auto-increment address not working on ADS1293

Albertas Mickenas1
Prodigy 205 points
Part Number: ADS1293

I have hard time using an auto-increment feature for reading ECG registers. If I specify to read 3 registers for one channel, I get correct data, but if I specify to read 9 registers, I get proper data for the channel 1 and random-ish noise on channels 2 and 3.

If I make three separate calls to read 3 bytes from 0x37, 0x3A and 0x3D, I get correct data for every channel.

I have tried configuring output of 3 ECG channels via DATA_LOOP register, but the result is the same - values are correct for the first channel and bogus for channels 2 and 3.

Do I have to configure the chip in some special way to make this feature work? Do I have a buggy revision of the chip? My configuration is as follows:

		{FLEX_CH1_CN, 0x11}, //0x01 //IN2 - IN1
		{FLEX_CH2_CN, 0x13}, //0x02 //IN2 - IN3
		{FLEX_CH3_CN, 0x0B}, //0x03 //IN1 - IN3
		{LOD_CN, 0x00}, //0x06
		{LOD_EN, 0x00}, //0x07
		{CMDET_EN, 0x07}, //0x0a
		{RLD_CN, 0x04}, //0x0c
		{AFE_RES, 0x3f}, //0x13
		{AFE_SHDN_CN, 0x00}, //0x14
		{CH_CNFG, 0x70}, //0x2f
		{R2_RATE, 0x01}, //0x21
		{R3_RATE_CH1, 0x80}, //0x22
		{R3_RATE_CH2, 0x80}, //0x23
		{R3_RATE_CH3, 0x80}, //0x24
		{R1_RATE, 0x00}, //0x25
		{DRDYB_SRC, 0x20}, //0x27
	{FLEX_PACE_CN, 0x00}, //0x04
	{FLEX_VBAT_CN, 0x00}, //0x05
	{LOD_CURRENT, 0x0a}, //0x08
	{LOD_AC_CN, 0x00}, //0x09
	{CMDET_CN, 0x00}, //0x0b
	{WILSON_EN1, 0x00}, //0x0d
	{WILSON_EN2, 0x00}, //0x0e
	{WILSON_EN3, 0x00}, //0x0f
	{WILSON_CN, 0x00}, //0x10
	{REF_CN, 0x00}, //0x11
	{OSC_CN, 0x04}, //0x12
	{AFE_FAULT_CN, 0x00}, //0x15
	{AFE_PACE_CN, 0x01}, //0x17
	{DIGO_STRENGTH, 0x00}, //0x1F
	{DIS_EFILTER, 0x00}, //0x26
	{SYNCB_CN, 0x00}, //0x28
	{MASK_DRDYB, 0x00}, //0x29
	{MASK_ERR, 0x00}, //0x2a
	{ALARM_FILTER, 0x33}, //0x2e

  • 0
    TI__Guru 66446 points

    Hello Albertas,

    Thank you for your post and welcome to our forum!

    Could you provide more details about the bogus data that you are reading? How are the analog inputs configured and how do you know the data is invalid?

    When using the auto-increment feature, you only need to specify the R/W bit and the starting address in the command field, followed by enough SCLKs to read from all the registers that you require. /CS can remain low throughout the register read.

    Keep in mind that the entire SPI operation must be completed before the next /DRDY (which appears to be driven by ECG_CH3 at 1.067 kSPS in your setup).

    Can you tell us what your SCLK frequency is? Also, it might help if you could share a capture of your SPI transaction with /DRDY, SCLK, /CS, and DOUT.

    Best Regards,

  • 0 in reply to Ryan Andrews
    Prodigy 205 points
    Thanks for the answer Ryan,

    I believe I am capturing at 100 samples per second - seems to be enough time to transfer 9 bytes.

    I will capture some traces tomorrow.
  • 0 in reply to Albertas Mickenas1
    TI__Guru 66446 points
    Hi Albertas,

    OSC_CN = 0x04 means that you are using an external crystal as your clock source, which should be 4.096 MHz by default. Can you verify this is what you are using?

    The crystal frequency is divided by 10 to produce nominal internal clock of 409.6 kHz and a modulator frequency of 204.8 kHz. Your decimation ratios of 4, 4, and 12 (R1, R2, R3, respectively) would produce a final output data rate of 1.067 kHz.

    Best Regards,
  • 0 in reply to Ryan Andrews
    Prodigy 205 points

    My R3 rate is 128, making it 100 SPS -- just checking that I understand the datasheet correctly.

    Regarding my problem - it is solved right now as I have noticed an error in my code - NRF spi driver puts input read during transfer of the command byte into response, I was interpreting it as the first byte of my data. After fixing this issue I am receiving data properly. Thanks for your help again.

  • 0 in reply to Albertas Mickenas1
    TI__Guru 66446 points

    You know what - you're absolutely right, my mistake. Somehow I read "0x08" as the register value. My apologies for causing any confusion.

    I'm glad you solved your issue! Please let us know if you have any other questions.

    Best Regards,