ADS1294 -- spikes in acquired data

Hey Ron,

When I've seen this before, it was been because someone was using RDATAC mode and waited too long to retrieve a sample and a new conversion overwrote their value mid-acquisition. You shouldn't have trouble with that since you are in SDATAC mode which means data won't get loaded until the device decodes the RDATA command. So I have nothing I can point to immediately and say that's what I think it is.

I can, however, help you debug. I'd like to determine whether this is an interface issue or if maybe your simulator is actually producing the spikes at the input for whatever reason. The way we can tell is that this device will filter data with a 3rd order sinc filter which will actually take 3 sample periods to settle. That means that if the input data actually had a spike in it that it would take another 2 conversions for the output to settle to the levels it was at before. Is that what you see?

If not then it is probably an interface issue and I we can investigate that further.

Regards,
Brian Pisani

Thanks for the quick response, Brian.  I don't see any settling in channel 2 value of the subsequent sample.  Here are the three samples for channels 2 and 3 from the logic analyzer traces:

0xFFE3BA, 0x002B62

0x4FDED5, 0x002F95   <- bad channel 2

0xFFDED5, 0x002F95

The third sample is almost identical except for 3 bits of channel 2.  That suggests to me that the ADS was loading the same acquired sample as the second sample so no intervening data update.  Is it possible the second latch in the sequence latched incomplete data?  The documentation says its not possible to load corrupted data though with RDATA so I didn't think I needed to synchronize with _DRDY.

Ron

Hey Ron,

Out of curiosity, if you are synchronized to DRDY, does the problem persist? I will check with a colleague who will know more than me.

Even if unrelated to this issue, I could see problems with not being synchronized with DRDY exactly. If the timing is off be even a little bit you can imagine a scenario where you would not actually collect the device's output correctly. For instance if your clock is slightly faster you collect two of the same sample or if you clock a little too slow you might miss a sample every once and a while.

Brian

I don't know if the problem goes away when synchronized to DRDY. We are in a very time-sensitive loop at 1 ms intervals, trying to reduce power consumption and waiting for DRDY will consume that time. Our updates are triggered by an external clock not synchronized to DRDY. Reading the same sample again or missing a sample is not really an issue for us but getting a bad value is. We can also sample at 2 Ksps in the ADS if we need less latency in the acquired values. The ADS documentation indicates we should not get corrupted data using RDATA. Is that true?

Hi Brian,

I am another engineer working on this project and would like to add that we have used different ECG simulators and have seen the spikes consistently on all of them. In my mind, this would eliminate the simulator as the culprit. 

Thanks,

-Konstantin

Hi, Brian. Have you heard back from your colleague? We're still looking for any suggestions you might have.

Ron

Hey Ron,

Sorry for the delay! I haven't forgotten about you. Just give me a little more time to consult with him. He was very busy yesterday.

Brian

Brian, I tried a few alternatives today.  I tried reading all channels instead of 3 but that didn't make a difference.  I now read the data twice in the same SPI bus transaction.  In the logic analyzer capture you can see that channel 3 has a large value, 0xBAD034 in the first read but 0x001E74 in the second.  Of interest is that DRDY is not asserted anywhere in my capture spanning 3 ms.  Fortunately we can impose thresholds for the detection of these anomalies and use the second reading if necessary.  It seems that there is some small window where the acquired data is not yet valid when the RDATA issued.

Ron

Thanks for clarifying that, Brian. You may want to revise section 9.5.2.8 of the data sheet. This is a bit misleading: "When reading data with the RDATA command, the read operation can overlap the occurrence of the next DRDY without data corruption." It implies to me that the data results are double-buffered but apparently that is not the case.

Ron