• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 51 subscribers
  • Views 194 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

intermittant Battery reading problem

Nigel Whitehead1
Prodigy 50 points
Other Parts Discussed in Thread: CC2541

Dear TI

We are having an intermittent problem when reading the ADC on the CC2541  

Our application requests an ADC value one time 10 seconds after the CC2541 is powered.  

Then, after 1 minute, 3 more readings are requested by our app and the results averaged to give us our battery level.

Subsequent readings are taken every hour.  3 measurements are requested and then averaged.

The battery level is consistent over a long period of time but every now and then a value is returned that is very low.  

this value recovers one or two hours later but can also be corrected by resetting the CC2541

The battery has been measured and is around 2.90V when we first start to see the problem.  This could just be a coincidence.

Our set up is reasonably straight forward in that there is no components external to the CC2541 involved.

The battery is wired directly to the VDD pin and measured using the ADC

 in our application our setting is:

                uint16 adc;

                HalAdcSetReference( HAL_ADC_REF_125V );

                adc = HalAdcRead( HAL_ADC_CHANNEL_VDD, HAL_ADC_RESOLUTION_10 );

So the ADC is set up to use the internal voltage reference and looking at the VDD/3, 10 bit resolution 

We have run our look up table through a through a test harness that simulates all the possible I/P’s

we have put a 2.90V battery under load by advertising every 160ms and requesting battery measurements. This did not reproduced the problem

Thanks

  • 0
    Expert 1035 points

    Ah the old battery problem.  I'd been dealing with a similar issue and was using a similar method to solve it.  In order to get a clean measurement you have to make sure that when you measure the battery is during a slow connection parameter and that the MCU is disabled during RF events.  This assures that the MCU wakes from sleep and measures the battery so that the only thing putting load on the Battery is the MCU (~8mA).   This is your most repeatable scenario.  It seems you are doing this.  So a few questions:

    1) What is your steady state connection parameters?

    2) Do you allow Battery measures when the GATT characteristic storing the Battery Level is read?   By default the ReadCB measures the battery.  This data exchange is not controlled by the application and thus may provide skewed results if read/measured at the wrong time from the Central.

    3) Are you using the a regulator which you bypass?

    Its always possible that a measure happens just after a Connection Ping of other high consumption events.  It may be best to throw out an outliner and average the remaining two measurements. 

  • 0 in reply to Kevin Lockwood
    Expert 1035 points

    I should note however that the downfall of this method is that if you have any particularly high current consumption events (fast advertising, LED's, etc) then this Battery reading method can fail at lower Battery capacities.  What I mean is that if you have designed your application well to the point where at steady state it is very power efficient, for example, the battery could reading 60%,  but then if a high current event occurs, this could cause the voltage to drop enough to cause a restart.  This is due to vast different in loading between this high current event and battery reading.   I still have not found a method that provides consistent battery reading and accurate shows a battery drain down to 20% and below.  It always seem to bottom out and cause restarts around 40%  sometimes 60% if the battery chemistry is corrupted (which is a whole new can of worms).