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.

ADS131M02: Synchronus Clocking

Part Number: ADS131M02

Tool/software:

Hey team,

A customer is using the ADS131m02 and running into an issue where things are going great until they receive a very low data reading.

They noted section 8.3.5 of the datasheet that state the master clock must be synchronous with SCLK. In their application they use a default crystal on the board to generate the master clock and then using a clock from the processor the generate the SPI SCLK. This results in the clocks being asynchronous.

Are they correct in this being the main issue?

The input signal to the ADC is a DC voltage that varies from 0.1V to 0.5V.  They are using this to validate the firmware before stitching to AC voltage inputs. The OSR is set to 256 for 16kHz sample rates.

Thanks,

Cam

  • Hi Cameron Perl,

    Can you please help us track this opportunity by posting the customer name in the Notes section of the Thread Tracking Toolkit?

    -Bryan

  • Done, please let me know your thoughts on this question.

  • Hi Cameron Perl,

    I doubt this is the issue, the ADS131M0x devices were characterized using a crystal oscillator as the clock source. Therefore, SCLK and CLK were asynchronous, yet the performance is as shown in the datasheet. So it is possible, but unlikely

    Can you describe what is meant by a "low reading"?

    How often does this happen?

    Is it random or systemic i.e. predictable?

    Any other helpful information you can think of, please provide to us. If this is a digital communication issue, please be prepared to provide logic analyzer captures of the communication

    -Bryan

  • Customer was mainly interested in the clocking question and will work to resolve the issue separately. I'll close this for now!

  • Hi Bryan,

    Quick follow-up question on this one related to clocking. Not sure if it is caused by our device or some other issue - let me know your thoughts! I've attached some weekend email communication - it seems the main question remaining is how his clock is getting halved!

    -------

    I think I’m coming to the end of my questions.  I have stable data coming from the A/D using C code that I ported from the TI code.  My hardware setup with the external micro had a lose wire which was giving me the periodic zero values.  That has been corrected.

    I have embedded timing into the code to make sure I have everything working correctly.  I noticed that I set the OSR to 256 therefore I expected to get a sample rate of 16kHz.  The timing that I’m capturing with the micro tells me that it is set for 8kHz.  I’m getting exactly 125usec. in between data ready interrupts from the ADC. 

    This is the TI code that sets the clock:

    writeSingleRegister(CLOCK_ADDRESS, (CLOCK_DEFAULT & ~CLOCK_OSR_MASK) | CLOCK_OSR_256);

    I thought maybe one of the defines may be wrong so I set the individual bits directly using the following, but nothing changes, still 8kHz

    writeSingleRegister(CLOCK_ADDRESS, 0b1111111100000110);

    Any ideas on where I should look?

    ------------------

    Just adding a little more information to my last email.  When I read back the CLOCK register after I write to it I get a hex F06.  I only have 4 channels enabled.  The 06 indicates (….0110) indicates that I have set the OSR to 256  (4:2 001), which should get me a sample rate of 16kHz if I’m reading the document correctly.  I’m going to check the scope timing next week to make sure the micro is giving me the correct timing.  I have used this micro for timing on several occasions, but I just want to make sure I can confirm the timing from the scope. 

    ----------

    I tried other OSR settings and the clock changes.  The sample rate changes.   It is behaving like I have a 4.097MHz crystal instead of a 8.192MHz crystal.  I verified the jumper is set to 8.192MHz. 

    When I drop the OSR setting to 128 I get the 62.5usec conversion which is the expected time for a 16kHz sample rate.

    I have a setup now that I can verify synchronization, just may need to get to the bottom of this.

  • I forgot we oversample on this device. That is the answer.