• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 1488 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.

ADS1292 glitches?

Moran Shoeg
Prodigy 165 points
Other Parts Discussed in Thread: ADS1292, TMS320DM365

Hi experts, 

I inherited project that using ADS1292 with 1 lead. When I look at the samples coming from the sensor, it seem to have glitches in the ECG signal.

This is a record of the data coming from the sensor, after being filtered by 40 Hz low pass filter (ECG_ProcessCurrSample() - TI Function).

What may cause this glitched and how can I prevent them?

Thanks,

Moran Shoeg

  • 0
    TI__Guru**** 181021 points
    Hi Moran,

    Can you tell if the noise has some periodic frequency associated with it?
  • 0 in reply to Tom Hendrick
    Prodigy 165 points

    No, its random...

  • 0 in reply to Moran Shoeg
    TI__Guru**** 181021 points

    Hi Moran,

    Can you tell me what is going on with your ADS1292 system when these glitches occur?  Say for instance you have a board sitting on the bench connected to an ECG simulator, do the glitches show up?  If so, there may be something in your software causing the issue - perhaps an interrupt to the CPU that causes loss or corruption of data.  Are there long cables between your ADS1292 and the CPU?  If so, there could be intermittent data loss over the SPI bus due to delays cause by cabling.  Whatever detail you can send along to us would be helpful to try and track down what/where the problem might be.

  • 0 in reply to Tom Hendrick
    Prodigy 165 points

    Tom Hendrick said:

    Hi Moran,

    Can you tell me what is going on with your ADS1292 system when these glitches occur?  Say for instance you have a board sitting on the bench connected to an ECG simulator, do the glitches show up?  If so, there may be something in your software causing the issue - perhaps an interrupt to the CPU that causes loss or corruption of data.  Are there long cables between your ADS1292 and the CPU?  If so, there could be intermittent data loss over the SPI bus due to delays cause by cabling.  Whatever detail you can send along to us would be helpful to try and track down what/where the problem might be.

    HI Tom,

    The ADS1292 is in the same boards with TI DaVinci processor (TMS320DM365) with Linux 2.6.32 OS.

    1.  There is a thread that takes the data from the spi (SPI RX), and another thread that processing and sending the data to some mobile device. I noticed that most of the times, it takes +-2000 uSec to read data by the SPI RX thread, which is perfectly fit with the configuration of 500 sps, BUT part of the times, it takes much more time to get a sample (by 2-5 time longer), and few samples are lost. Is loss of some samples can cause such reactions?

    2. Also, I started checking the STATUS BITS, and noticed that part of the time the first 4 and the last 13 bits are not " 1100 ....13x'0' ", And it appears to be some correlation between these STATUS BITS errors and the glitches. Do you have any idea or suggestions for the reason of these errors?

    Thanks,
    Moran Shoeg

  • 0 in reply to Moran Shoeg
    TI__Guru**** 181021 points

    Hi Moran,

    Yes - if you are loosing samples, and especially if it seems related to STATUS BIT errors, this could be the cause of the glitches you see.  If it were just a matter of loosing a sample, the waveform would look essentially 'normal' with perhaps a slight jump between a couple points where a sample was lost.  If you notice that the status bits seem corrupted, chances are that you have lost synchronization with the ADS1292 and you are not interpreting the returned results correctly - that could be the cause of the large delta in magnitude you see in the waveform.  It sounds like there is some system level interrupt causing this data transfer corruption.  Have you been able to narrow down what makes the 2ms transfer jump to 4 or 10ms? 

  • 0 in reply to Tom Hendrick
    Prodigy 165 points

    The CPU jumps to interrupt every time it gets DRDY signal from the sensor, and change some flag in the system. The OS monitor this flag and if it up, the system does content switch to the thread that is currently waiting (sleeps while waiting) for that flag, and then the the thread reads the data from the sensor. If the CPU is currently is busy with other threads, it wont jump on time.

    Yesterday, I tried to solve this by setting RT scheduling (SCHED_FIFO) with high priority to the thread which reads the data from the sensor, and it seem to work, and now the reading is occur in  between time gaps less than 4 ms.

    Still, I keep seeing these STATUS BITS errors. When I receive error, I try to read the data again few times, but the same error in the bits repeats. Also, it seems to me that even before and after the STATUS BITS error, a lot of the data samples are corrupted.

    Currently, When there is a STATUS BIT error, I use the previous sample before filtering, but i doesn't  seems improve the results...

    Can you please give me more details about how loss of synchronization might occur,  and explain how "some system level interrupt" can cause data transfer corruption.

    Thanks, 

    Moran Shoeg

  • 0 in reply to Moran Shoeg
    TI__Guru**** 181021 points
    Hi Moran,

    Is it safe to assume that you are running in continuous mode? One way to get out of sync is by not getting all data transferred from the ADS1292 between DRDY signals. What is the speed of your SPI interface? You mentioned above that you changed your scheduling to make the sensor a high priority thread, this is what I was referring to regarding 'some system level interrupt'.
  • 0 in reply to Tom Hendrick
    Prodigy 165 points

    Yes, continuous mode. I tried to set the SPI interface to 1Mhz and 19Mhz, but didn't see any difference.