ADS1291: Random invalid conversions

Hi John, 

Welcome to the E2E design forums!

Just to confirm, are you getting these erroneous readings using the ADS1291EVM, or using your own board? If it's on the EVM, it's easier for us to look to replicate it. 

Kind regards,
Nick Z

Hi Nick, this is using our own board. I have confirmed that this happens with all of our boards, not just one of them.

Hi John,

In addition to Nick's question, Please check your timing diagram meet the requirement and constraints stated in datasheet sections 6.6 Timing Requirements and 8.5.1.10 Settling Time.

Are your CLK and SCLK stable over time without jittering or glitches?

Also, Which channel and what are the signal sources are you injecting or trying to read? Have you tried the internal Test Signal and see if this large ADC code reading still exist?

Would you please clarify what you mean by "what decimation filter oversampling ratios yield which precision"? Do datasheet page 25, 26 provide the info you need?

And, please note that 

"After a START signal
rising edge, the filter takes tSETTLE time to give the first data output. The filter settling times at various data rates
are discussed in the START subsection of the SPI Interface section."

Thanks.

I will review the SPI timing requirements in detail to verify them, though I will say I don't notice any SPI issues.

As for the settling time, as far as I understand this only applies to the first reading - the START pin is tied high. This section mentions that the filter needs some settling time for step changes when START is held high, but I doubt this is the issue because the filter should at least be outputting data divisible by its internal step width during this settling time, and reading during this settling time should only be degrading analog characteristics.

We're using channel 1 (channel 2 is powered down with the PD bit), in normal electrode input mode. I just tried changing the channel 1 source to the test signal, and the occasional invalid measurements continued. E.g. -2096432, 5285496, -185355. Meanwhile typical outputs from the test signal at this gain are in the -5000,5000 range.

CLKSEL is tied high, CLK is floating to use the internal clock. I can try to scope SCLK to see if it has any glitches, but I doubt it, as it's being generated by a SERCOM on an ATSAMD just about 2mm away on the PCB.

I've reviewed page 25 and 26 again and I'm still unclear on how oversampling impacts precision; it seems to mostly discuss analog frequency response. I just know that, based on observation, the filter only outputs readings divisible by 20 at this oversampling ratio, and the datasheet says "tradeoffs can be made between resolution and data rate." That the filter is stepping by 20 is my best guess for what this means.

What is your DVDD voltage?

Please take a look of Section 6.6 Timing Requirements with respect to the DVDD column to check your tCSSC, tDIST, tDIHD, tDOPD, tSCCS meet the requirement/constraint.

Reasons for that is to make sure the relevant digital signals have enough time margin relative to each other.

May I ask do you use RDATA or RDATAC?

Please refer to

Figure 53 for RDATA

Figure 52 for RDATAC; note (1) tUPDATE = 4 x tCLK. Do not read data during this time.

Did you change any any register settings between any RDATA command? Are you always reading the same register without changing between each RDATA? If yes, which register address is that?

Can you refer to Table 15, RREG and let me know what are your RREG's FIRST BYTE and SECOND BYTE?

Yes, it would be nice if you could probe and get a screen shot similar to one of the figures above; you may ignore START signal if you tie it to high.

Also, curious whether you see this issue in just RATA or RDATAC  or both?

Thanks.

DVDD is 3.3V. tCSSC and tSCCS are both 1us. tDIST/tDIHD/tDOPD are in the 100s of nanoseconds because the SPI bus is being driven by a peripheral configured for SCLK rate of 1MHz. I believe these should be well within spec. (I have tried taking the SCLK down to 250kHz just to really make sure it wasn't SPI timings; the issue persisted.)

We are using RDATA; I always issue a SDATAC command during power-on setup. No settings are changed between RDATA commands; after setup, the only commands issued are an RDATA every 1ms.

I can't test with RDATAC because I don't have access to the DRDY pin. We may spin a board revision to run DRDY to the MCU so that it can use it, but I can't test that at the moment.

I'm not sure what you mean by RREG's first and second byte; I use the RREG command several times during setup to check that the values I place in the registers are successfully set. E.g. after setting CONFIG1 I send RREG with 0x21, 0x00 and read the CONFIG1 val. (List of those register values in my first post.) But like I said, RREG is only used during setup, not during data reading.

Hi John,

Thanks for detail explanation and you say this issue happens on all of your boards.

So, if I understand correctly that the large values occur every 30 second ~ 1 min when you read the ADC value data from Channel 1, is that right?

You tried reduce the SCLK frequency and the issue is still there.

You tried use the internal test signal, the issue is still there.  May I ask when you tried using the internal test signal, did you remove your external signal source while doing the test?

Have you tried different Data Rate(DR) SPS, both high and low? If not yet, could you try it to see whether the issue is there?

Could you do one more test? Keep reading ID: ID Control Register (Factory-Programmed, Read-Only) (address = 00h), and see if this issue occurs or alter the Bits[1:0] REV_ID[1:0]: Revision identification?

Would you want me contact you through email to bring this to private email discussion and you may share your schematic or board layout design for us to take a look? Over there, I may ask what might be your host/master and how you read/show/display the data and any aggressor components adjacent to the ADS1291 chip.

Thanks

All these tests have been performed without an external signal source, the measurement leads have been floating. (The analog filters are still present.)

I tried lowering the data rate - the issue decreases in frequency as the data rate goes lower. We normally run at 4000; at 2000 the issue becomes less frequent, at 1000 I've only seen the issue once in several minutes of testing. At 8000 (the only higher DR) the issue also persists. As expected, the resolution changed at the different DR - at 8000 all measurements (except erroneous ones) were divisible by 320, at 2000 all were divisible by 5, at 1000 all were divisible by 1.

I am worried about lowering the SPS to 1000 however, as that is the required data sampling rate, and there's a lot of risk of us reading before data is ready if we have any variability in the read timing.

I tried continuously reading the ID register, and did not see the issue come up in those readings. It always reads as 0x52, correct for the ADS1291.

I'd be happy to review over email.

Hi John,

I will reach out to you through email regarding to this ticket.

Thanks