• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 53 subscribers
  • Views 283 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2652RB: Internal Temperature Sensor Accuracy

TylerWitt
Intellectual 810 points
Part Number: CC2652RB
Other Parts Discussed in Thread: MSP430G2333

Hello - 

We're hitting some inconsistencies in the accuracy of the internal temperature sensors for the CC2652RB units we are installing in our product.

We've designed a "selfTest" which includes reading the internal temperature sensor registers, converting the value to degrees Celsius, and then checking that this value is within 5C of 20C. We run this "selfTest" twice in production - once at our contract manufacturer's facility when the PCBs are still panelized for parallel testing and once when the product is built up completely and at its final testing stage. We've had a lot of fallout at our final testing stage (350+ in the past few months) in our facility as compared to our contract manufacturer's facility (11 failures, all retested to PASS), so we've started to investigate this specifically. 

I've taken a few failed units off the line and compared it to a personal test unit which was successful throughout testing. Even with employing the Temperature driver and ensuring the AON_BATMON was ready to provide a new temperature value, there is still a large difference in output values from these failing units and my passing one.

Essentially - I've written special firmware which runs the below code in a loop 10x, then reports the averaged value out by beeping it audibly on a buzzer.

    while(!AONBatMonNewTempMeasureReady()); // Wait for temp sensor to be ready
    temp = Temperature_getTemperature()*10; // x10 to report value in 0.1*degC

The two units which failed are consistently reporting and reading values 5-8C lower than the passing unit, which is well outside the tolerance given in the datasheet. We've tested this down at -20C and up at 50C with very similar results. Retesting the product gives consistent numbers per unit, but precision between units is the issue.

Is there an offset value that is defined/measured in production that isn't being applied by the driver software? Why is there such a discrepancy between these parts?

  • 0
    TI__Genius 15590 points

    Hi Tyler,

    Looking at the temperature driver, it looks like the measurement is already returned in degrees C. Do you think doing an extra conversion could be throwing off the data/accuracy? 

    I'm not aware of any offset value like the one that you're describing, but I will check.

    Thanks,

    Alexis

  • 0 in reply to Alexis Crandall20
    Intellectual 810 points

    Alexis - thank you for the reply, but I think there may be a misunderstanding here.

    We run two temperature checks on the device as it's being built with the assumption that both test environments will be well controlled around the 20C temperature mark. However, after noticing the discrepancy in failures, we pulled data from our PCB manufacturer and saw that they are in fact operating a bit warmer on average than we are.

    Since we are seeing a majority of our failures in our product manufacturing area, and our temperatures here are lower than that of our PCB manufacturer, this all tracks with the fact that the product which fails tends to fail for the temperature being too low.

    That being said - I've been using a few units to test this specifically, and two of our failing units are (when tested at room temperature around 20C) consistently reading 5C lower than the passing unit. When tested across temperature, this can be a bit worse, with the worst case of around 8C lower than what we consider an "acceptable" unit which is within the 3C limitation from the datasheet.

    So to the original question - why are we seeing units with such a wide variance from each other? Is this expected?

    As far as an offset value is concerned, the driver function within Temperature_getTemperature (part of the AON_BATMON driver) applies a slope correction factor from the FCFG1_O_MISC_TRIM register location. I was curious if the driver was intended to also incorporate an offset factor that was forgotten.

  • 0 in reply to TylerWitt
    TI__Genius 15590 points

    Hi Tyler,

    Thanks for the clarification. I will look into this and get back toy you next week.

    Thanks, 

    Alexis

  • 0 in reply to Alexis Crandall20
    Intellectual 810 points

    Alexis - it's been close to a week with no response, have you had any success in getting clarification on this issue?

  • 0 in reply to TylerWitt
    TI__Genius 15590 points

    Hi Tyler,

    I apologize for the delayed response. I reached out to a few folks internally and this is what I've gathered:

    • What you're measuring isn't out of the norm. The datasheet gives a typical value, but some devices may exceed this (no min/max assured). 
    •  During production, we do a 1 point calibration which compensates over voltage. This is already taken into account when using driver lib for the measurement.
    • part-to-part variation is expected

    With that being said, I was hoping to get some more information from your side.

    • When re-testing your failing units, are you comparing against the results from your passing units or against the ambient temperature? 
    • I also want to clarify whether you are using driverlib to read from the sensor or whether the special firmware you're referring to is reading from the register directly? 

    Thanks,

    Alexis

  • 0 in reply to TylerWitt
    Guru 735455 points

    According to my experiences with Internal Temperature Sensor, it usually very inaccurate and I would suggest you to use external temperature sensor such as TMP116 if you need to get accurate temperature for your application.

  • 0 in reply to Alexis Crandall20
    Intellectual 810 points

    Alexis - OK so the temperature sensor is very low quality. It also sounds like there is no want from the factory to improve the sensor accuracy with multi-point calibrations like are done with MSP430's - which seems silly to even have the sensor available if it is going to be so useless.

    Regardless of shortcomings, we do have an ancillary board in our design with an MSP430G2333, so we can utilize it's internal temperature sensor and TLV calibration constants to give us our temperature. This was not our ideal solution since it complicates the firmware of the MSP430, and the CC2652RB must query the device over I2C for its own temperature.

    To assess your questions:

    1. We are using a temperature chamber to set a precise set point temperature, then taking measurements and logging them internally to be read out over Bluetooth to verify our results. Ambient temperature tests were done as a baseline to check the part-to-part variance initially, while high and low temp tests were done to confirm the results.
    2. Our original application code interfaced directly with the AON registers, but this code was written before the temperature sensor code for driverlib existed (written originally with SDK 3.10.00.53). Before posting to this thread, I updated the code to use driverlib to apply the slope error correction. This did not cause any appreciable part-to-part improvement when implemented. 

    YiKai - I appreciate the suggestion of an external sensor, but we are limited in options for cost, power consumption, and especially IO pin usage - hence why an internal sensor was the go-to if we could keep it within an acceptable tolerance.