ADS1262 Errata?

Pushpal Sidhu26

Other Parts Discussed in Thread: ADS1262, ADS1263

Hi All,

I'm going through the steps of finalizing the configuration of the ads1262 that we're using in our system. However, I noticed that there is no errata on this year old part. The reason this concerns me is because of this post I found: https://e2e.ti.com/support/data_converters/precision_data_converters/f/73/p/453978/1636164#1636164

I was able to reproduce this issue, which is a shame because I had moved our system to using one-shot mode (required for my application) and was now starting to look into noise-reduction (meaning I would most likely want the sqrt(2) reduction of chopping).

Because I can't find any errata on this part, and the workaround for this specific issue was never verified (and in fact, I can't make work at all) leaves me to wonder if this issue will be fixed in a future part rev or an errata will be released to publish this (and potentially other) issues with the ads1262/ads1263.

over 9 years ago

0 Christopher Hall over 9 years ago

TI__Mastermind 44680 points

Hi Pushpal,

Currently, TI only does Erratas for microcontrollers and processors. If there is an issue with one of our analog devices we usually try to include a note in the datasheet. Therefore, the datasheet and E2E are probably our best resources for working around issues...On the TI.com product page you can click the "Alert Me" button to know when updates are made to any of the documentation.

Regarding the problem in single-shot mode, you said that you can't get the device to work at all... What kind of behavior (or lack thereof) are you observing?

I believe the proposed workaround for this issue should work... I was the one who looked that the issue, and I'm usually pretty good about testing out any workarounds before I propose them as a solution. If needed I can go back and at look at that again.

Best Regards,
Chris

0 Pushpal Sidhu26 over 9 years ago in reply to Christopher Hall

Prodigy 60 points

Hi Chris,

Thanks for responding. I now understand TI's Errata policy, but I still do not see a Pulse Mode Conversion + Chop Mode note in the Rev. B Datasheet for this part (maybe I just glanced over it).

About my not getting the device working at all, that was a poor choice of language, sorry. The device works fine in one-shot mode so long as I have chopping disabled. With chopping enabled, I send a STOP1, then START1, but fail to receive data back (Note, I'm using software polling to receive data, I have no hardware access to the DRDY line). I also don't believe it's an SPI communication issue as you suggested in the other post.

Along these lines, do you believe chopping mode adds 2x latency (if using Sinc1, what about Sinc2+?)? If that's the case, I probably won't want to use it anyways.

- Pushpal Sidhu

0 Christopher Hall over 9 years ago in reply to Pushpal Sidhu26

TI__Mastermind 44680 points

Hi Pushpal,

That issue still needs to get added to the datasheet. I've made a note of it, so it should get included in the next cycle.

In the meantime, I'll double check on my workaround...

Yes, chopping adds latency... With the SINC1 filter, you'll only see a delay on the first conversion result; however, with SINC2 or higher filter orders, you'll notice that the effective data rate decreases significantly. What happens is the digital filter must re-settle each time the input polarities are switched. So, the effective data rate will be about 1/2 the nominal data rate with SINC2, and it will be close to 1/4 the nominal data rate with the SINC4 filter.

Best Regards,
Chris

0 Pushpal Sidhu26 over 9 years ago in reply to Christopher Hall

Prodigy 60 points

Chris,

Thanks for checking your workaround. If you can, please software poll by requesting data via RDATA1 and checking the status bit for new data as opposed to watching the DRDY line.

Thank you for the information about the chopping latency, it seems that using Sinc1 + Chopping would be ideal for me if delay is only on first conversion result.

- Pushpal Sidhu

0 Christopher Hall over 9 years ago in reply to Pushpal Sidhu26

TI__Mastermind 44680 points

Hi Pushpal,

I was checking out the workaround yesterday and found that it did not solve the problem; however, there is another alternative solution to this issue...

Original Workaround
Sending the STOP1 followed by START1 commands allows me to restart conversions; however, reading the status byte shows that the conversion never completes, when using global chop AND pulse convert modes. Therefore, global chopping cannot be used in pulse convert mode. (Note that chopping could still be performed manually in pulse convert mode by switching the MUX inputs and performing the math in software).

Revised Workaround
Global chopping can be use in continuous conversion mode. To perform only a single conversion in continuous mode, set the START pin low and then issue consecutive START and STOP commands (with either the software or hardware commands). The software routine would look like the following:

setOutputLowOnPin(START_PORT, START_PIN);	  // Set START pin LOW - Required when using START1 SPI command
configureADC();					                  // Configure ADS1262 (continuous conversion mode, global chop enabled)

loop:
{
	sendCommand(START1);			          // Send START1 command - alternatively, use HW command here
	sendCommand(STOP1);			          // Send STOP1 command - alternatively,use HW command here
	WaitForDRDY();				                  // Wait for nDRDY hardware interrupt or poll STATUS byte for "NEW1"
	readData();				                  // Read data
}

Certainly, the ideal solution would be that global chopping would just work in pulse convert mode; however should you decide to use global chopping and perform single conversions at a time, I hope this helps save you the time of having to troubleshoot this issue.

Please, let me know if you have any other questions about the ADS1262!

Best Regards,
Chris

0 Pushpal Sidhu26 over 9 years ago in reply to Christopher Hall

Prodigy 60 points

Hi Chris,

Sorry for taking a bit of time to respond and thank you for taking the time to come up with another workaround.

While this works, the only issue is latency increases on each conversion (which makes sense because data isn't pipelined anymore I believe). I have a requirement to complete each adc capture from the moment of a start at <1ms, with fairly 'low' SPS.

At 2400SPS + Chop + Sinc1 in this new configuration, I get a conversion rate of about 1.6ms. Without Chop, it's roughly .824ms.

The minimum I can change the SPS to get to a <1ms conversion rate with Chopping is 14400SPS, which is unfortunately too high.

It appears that I cannot use this part's chopping abilities with the set of requirements I have.

Thanks,
- Pushpal

0 Christopher Hall over 9 years ago in reply to Pushpal Sidhu26

TI__Mastermind 44680 points

Hi Puspal,

With the nominal 7.3728 MHz clock and no additional conversion start delay, you might be able use chopping down to 7200 SPS and still get data in just under 1 ms. Otherwise, you could consider increasing the clock frequency, which would allow you to create data rates between 2400 and 7200 SPS. If those options don't work in your application, then chopping will probably slow you down too much.

Below are the minimum times from conversion start to /DRDY low (for the nominal clock and DELAY[3:0] = 000). With chopping you would need to double these times. However, you would also need to consider how often you poll /DRDY and add the polling period, plus the time it takes to clock out the data, (if that is part of your 1 ms requirement).

Best Regards,
Chris

0 Pushpal Sidhu26 over 9 years ago in reply to Christopher Hall

Prodigy 60 points

Chris,

You bring up an interesting point that I was curious about, actually. Maybe you can help me answer it. In section 9.4.8 of the datasheet, it states that "Good line-cycle rejection requires an accurate clock frequency that is best provided by a crystal oscillator." Can this statement be qualified? That is, how much better is line-cycle rejection when adding an external xtal osc? Sorry for being a little off topic here.

- Pushpal

0 Christopher Hall over 9 years ago in reply to Pushpal Sidhu26

TI__Mastermind 44680 points

Hi Pushpal,

Not a problem...The datasheet is pointing out the relationship between the clock frequency and the digital filter response. Power line frequency noise can be significantly reduced by operating at a data rate that includes a notch a 50 or 60 Hz. However, the accuracy of the clock will have a direct impact on the data rate and the location of the digital filter notch in the frequency-domain...

In general, "crystal-based" clocks will have better accuracy than "RC-based" clocks, which will vary in frequency due to "R" and "C" tolerances. For example the internal oscillator of the ADS1262 is specified with a typical initial accuracy of 0.1% and max error of 2%. The ADS126xEVM includes an ECS-73-18-10X crystal with a typical error of +/- 50 ppm (0.005 %).

The clock accuracy may or may not be a critical issue in your application... It's impact can be lessened by using a higher-order filter, such as a SINC4 filter, which has wider filter notches than the SINC1, SINC2, and SINC3 filters (the notch width increases as the filter order increases).

Best Regards,
Chris

0 Pushpal Sidhu26 over 9 years ago in reply to Christopher Hall

Prodigy 60 points

Hi Chris,

I'm toying with the idea of increasing the Fclk so I could maybe use a higher order sinc filter and still obtain my <1ms conversion rate requirement. The datasheet states a max of 8MHz crystal osc. I'm not sure of the tolerances allowed there, but would using an 8MHz xtal be too high of an input, or should I step down to a 7.68Mhz?

I would prefer to use an 8MHz xtal due to higher stock, but I would like to verify this with you. An xtal such as the following:
* www.digikey.com/.../2624229
* www.digikey.com/.../2001454
* www.digikey.com/.../5875589

Data converters

Data converters forum

ADS1262 Errata?