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.

ADS7868: I see some data that is different from the voltage source

Part Number: ADS7868

Hello TI experts,

My customer made a PCB with ADS7868 for monitoring voltage of battery.

Here is the schematic.

as you see, we use 1.8V VDD and used resistor divider for 4.2V-full-battery. so it can represent 4.2V as full.

and we set the SPIO as mode 3 (CPOL=1, CPHA=1), and MSB first, 8bit data size.

then we attached a battery to the sample PCB, then checked the debug message in MCU.

I think 96 is real value. but I can see 64 and many 0.

as normal operation, i think it have to show only one value. (96 in this case)

is it normal operation that i see some meaningless data? or do I miss something in schematic or SPI communication?

Please check this issue. Thanks.

Best regards,

Chase

  • Hi Chase,

    The voltage on the ADC's input should be 4.2V*(15k/(15k+20k)=1.8V, thus the code you should is ~255(0xFF) because the ADC's input range is 0-1.8V(VDD).

    1. Are you testing a 4.2V battery voltage?
    2. Can you measure the actual voltage on the ADC's input pin?
    3. Can you provide a timing plot with an oscilloscope including SCLK,/CS and SDO?

    Best regards,

    Dale

  • Hi Dale,

    Thank you for your reply.

    today I visited my customer, and got some information.

    1. Yes they are testing a maximum 4.2V battery voltage.

    2. today I used DC power supply instead of battery.

    3. I took photos for analysis. (skyblue is CLK, yellow is CS, pink is SDO) 

    attached zip file is the picture I took, and here is the status with DC input and SPI debug message.

    (DC input) -> (SPI value on debug message)

    1.8V -> 255 (I started with maximum voltage)

    1.7V -> 255

    1.6V -> 192

    1.5V -> 128

    1.4V -> 0 (I saw SPI value 0 in this time, and I raised the DC input value)

    1.5V -> 128

    1.6V -> 224 (this is little different value compare with above)

    1.7V -> 2551.8V -> 255

    and here are my questions;

    1. why are the same SPI value with 1.8V and 1.7V?

    2. why are the different value with first 1.6V and second 1.6V?

    3. why 0 SPI value is appear with 1.4V? I thought that 0 value is appear with around 0V.

    4. attached log file is the data while testing today. I can see some different value like 63 and 0.

    especially I cannot understand with 255 to 0 directly. how can it happen?

    If I did something wrong, please let me know, and check also other issues. Thanks.

    Best regards,

    Chase

    SPI_Log_29Dec.txt
    model_ver : TP100PCQL_1.0.1
    dev->chip_id = d1
    GPIO_PIN_11 ...!!!!
    fall fall fall ~~~~~~~~~~~~~~~
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 63 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 192 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 63 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 63 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 0 0 0 
    spiBuf = 255 0 0 
    spiBuf = 0 0 0 
    spiBuf = 255 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 255 0 0 
    spiBuf = 0 0 0 
    spiBuf = 255 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 255 0 0 
    spiBuf = 0 0 0 
    GPIO_PIN_11 ...!!!!
    fall fall fall ~~~~~~~~~~~~~~~
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    spiBuf = 0 0 0 
    KEY_POWER_KEY~~
    PWR_Key osKeyTimer_Callback
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    KEY_POWER_KEY~~
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 128 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 192 0 0 
    spiBuf = 224 0 0 
    spiBuf = 224 0 0 
    spiBuf = 224 0 0 
    spiBuf = 224 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 0 0 0 
    spiBuf = 128 0 0 
    spiBuf = 224 0 0 
    spiBuf = 224 0 0 
    spiBuf = 224 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 128 0 0 
    spiBuf = 224 0 0 
    spiBuf = 224 0 0 
    spiBuf = 224 0 0 
    spiBuf = 224 0 0 
    spiBuf = 224 0 0 
    spiBuf = 224 0 0 
    spiBuf = 224 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 
    spiBuf = 255 0 0 

    201229.zip

  • Hi Chase,

    1. A precision DC signal generator is always recommended for testing, we never used DC power supply as input for ADC's testing. When a 1.7V DC is applied, you should get ~240 code because the FSR is 1.8V and the ADC is 8-bit ADC.

    2. Your 2nd measurement for 1.6V is correct (~226 code for 1.6V voltage input). I checked the timing/pictures you provided for both 1.6V input (13 and 17), the data output on the SDO are same but your controller got different codes, something is incorrect with your timing or controller. what's your SPI's CPOL and CPHA configuration? Also, your code for 1.5V is incorrect, were these voltages measured on pin 3 of ADC's input? What's your actual sampling rate on the ADC? What's your SCLK frequency?

    Also, your front-end circuit should be available to drive the ADC and settle the signal during limited acquisition time, usually an amplifier is needed. Your battery voltage is a slow change signal so I supposed it's okay for your ADC without a driving amplifier. However, when you switch your signal quickly, your circuity is not able to settle the signal on sample-and-hold circuit of ADC during acquisition time. Check TI's Precision Labs ADC - Driving ADC without amplifiers for the details. If you are using an ADC to monitor a fast-moving signal with a higher sampling rate, you will need an amplifier to drive the ADC, check TI's Precision Labs ADC - SAR ADC Input Driver Design for more information.

    3. If you look at the timing in the picture 15 for 1.4V input you captured, the code/data have been shown on the SDO line. However, you got 0 value, so definitely something was wrong in your code either issue of capturing the data from SDO or reading the code from buffer in your controller. You should check your code and the details about your controller.

    Best regards,

    Dale 

  • Hi Dale,

    1. You mean using DC power supply is inappropriate for testing. and when the input is 1.7V with 1.8V FSR, SDO should be about 240.

    in the picture the SDO waveform are the same between 1.8V and 1.7V. that mean there is an error whatever it is VDD or power supply.

    what do you think about it?

    2. I understand 2nd situation. same 1.6V, same SDO, but different SPI message.

    the setting is CPOL=1 / CPHA=1 (SPI mode 3), MSB first. and these voltages are measured on pin 3.

    and we are connecting the Li-ion battery to the system.

    3. I understand 3rd situation too. i will talk with my customer about this.

    and here is my new question;

    1) how about using larger FSR voltage, like 3.3V? is it effective for accuracy? of course I should change the divider resistors.

    2) I can only found that SPI baud rate is 16Mbits. I think it is same as SCLK frequency.

    we will decrease this baud rate under 5MHz, and see there would be any changes.

    but we could not find the parameters about sampling frequency. there is no code for it in firmware source.

    but sampling frequency parameter exists, and even i control it. could you tell me where can i find it?

    and let me know the connections between SCLK and sampling frequency. (ex. it should be same, or double the SCLK will be sampling frequency...)

    3) How can I explain the different values among the stable values in SPI debug message? (ex, 63 between many 128)

    is it the fault of reading buffer or something?

    Please check these issues. Thanks.

    Best regards,

    Chase

  • Hi Chase,

    1. This is part of the reason. the power supply should no be used as a input signal. Also, the power supply is usually not stable and it may have noise and ripple. A precision signal generator is always recommended as input for test. Also, use a bench multimeter to check the input voltage instead of handheld multimeter, for example, Agilent 34401A.

    2. Your SPI configuration is correct and your controller can capture the data on the rising edge of SCLK.

    Answers or comments to your questions:

    1) Larger FSR helps with consistent noise. However, your current 1.8V FSR should work if the issues are solved.

    2) I could not see the 16Mbit baud rate in the datasheet as you mentioned. However,  3.4MHz maximum SCLK frequency is specified and recommended in the datasheet, see the table below.

    The maximum sampling rate is 298ksps for VDD>1.6V on ADS7868, see table 1 below. Your /CS is actual conversion start signal to achieve the actual sampling rate, make sure that it's less than 298kHz.

    For reading buffer on your controller, that's my doubt because your controller got 0 code but actually there are available data on the SDO.

    My suggestions will be reducing your SCLK frequency to 3.4MHz, using a precision signal generator as input, also make sure your actual sampling rate is less(or equal to) than 298ksps, then check again. The timing plots with new conditions will be helpful to address the issues.

    Best regards,

    Dale

  • Hi Dale,

    I understand almost of your saying, now I am discussing this issue with my customer.

    here is one more question,

    could you tell me how can I change the sampling frequency?

    I cannot find any source code about it, because ADS 7868 has output only.

    please check this issue. Thanks.

    Best regards,

    Chase

  • Hi Chase,

    As I said in previous post, "Your /CS is actual conversion start signal to achieve the actual sampling rate", the falling edge of /CS will initiate a conversion and the device will enter sample and conversion phase then 10ns minimum setup time is required, so the time between the falling edge of /CS and the next falling edge of /CS is the cycle time(tcycle) and it determines the sampling rate, make sure it does not exceed 298kHz. See the tcycle in the timing below:

    Best regards,

    Dale