›

CPro Power Consumption

MichaelGMichaelG
in Hardware
I've done some bench testing on the power consumption of a CPro with Sensor Fusion module. At idle, having just inserted the battery, the device appears to be consuming 75 microamps, with a periodic burst (assuming Bluetooth advertisment) of 175 microamps. The spec on the web page says average 10 microamps with 25 microamps at worst, why the huge difference?

Comments

  • EricEric
    What firmware is the board running and what is its hardware revision?  
  • MichaelGMichaelG
    The hardware version is 0.1. I was using Firmware 1.3.3 and upgraded to 1.3.4 but it did not impact the power consumption. The device was puchased only in the last few months and as mentioned, uses Sensor Fusion, how many hardware revisions have there been in that model? If there have been none, why would the hardware revision have an impact on the outcome?
  • LauraLaura
    There is no sensor fusion on MetaWear Cpro. Only MetaMotionC.

    You are looking at the wrong datasheet...
  • MattMatt
    @MichaelG

    Please confirm that you are running firmware revision r1.3.4, improvements were made to idle state power consumption of the magnetometer hardware.

    Bluetooth advertisement current is not included in the data sheet idle current spec -- operating modes are available which do not advertise at all times.

    I have a CPro unit on my lab bench which is registering 9uA at idle (on a calibrated Agilent 34401A).

    What is your measurement setup?
  • MichaelGMichaelG
    Yes Laura, that's correct. It is a MetaMotionC, not a CPro, my bad. The datasheet for the MetaMotionC has the 10/25 microamp specification for power consumption.

    Matt, I am using a HT63 multimeter. I have the battery connected in series with the multimeter and pins 5 and 6 on the MetaMotionC board. I am using the 600 microamp range setting which has a resolution of 0.1 microamps and an error of +/-1.5%rdg+5dgt.
  • MattMatt
    @MichaelG

    The HT63 will have issues measuring idle current on MMR/MMC boards.  The dynamic range is a problem because current consumption varies from ~10uA to ~10mA  at high frequency over the course of a second.  These models also have a DC/DC converter, which improves power efficiency, that consumes current in very high frequency pulses and is known to cause aliasing during measurement on all but the highest end lab grade equipment.

    You can read more about the aliasing issue for current measurement here:

    Adding significant capacitance (>150uA) to your measurement setup may help you get a more accurate reading.  You can also try using a power supply instead of a battery and vary the supply voltage from 2.25-3.3 until you get a minimum reading (the aliasing due to DC/DC is voltage dependent and will disappear at some supply voltages).  It will depend on the specs of your HT63 whether or not this works, but I can say that we do see the aliasing effect on our 34401A which is a very good multimeter.
  • MichaelGMichaelG
    Alright, assuming my measurements are defective due to aliasing and the device is consuming 10/25 microamps at idle, can you clarify what "idle" is? Is it an average consumption over time? Does it include the occassional Bluetooth LE advertisment. Does it include the power consumed listening for a connection.

    I ask as given the worst case idle consumption my battery life at idle should be far greater than I am actually experiening with a device that is just sitting there, never having been connected. Can you think of anything that might cause it to be draining a battery faster than the specified idle current.
  • MattMatt
    @MichaelG

    Idle current is the device running with all sensors in the minimum power state and advertising disabled.  It is an average.

    Advertisement is excluded from idle current, because current consumption is highly variable based on TX power and Ad Frequency.

    Connection "Listening" is part of the advertisement process in BLE and excluded from Idle as spec'd in the datasheet.


    How fast is the battery draining without user interaction?  Do you have more than one unit exhibiting this behavior?

    A new firmware was recently released as well as refinements recently made to our final QA checks on shipment.  We will pull a couple units off after this process to see if any new issues may have been introduced.
  • MichaelGMichaelG
    Matt, I have three units all exhibiting different current draws after battery insertion, one around 0.5 millamps. Even given the aliasing problem I would have expected them to exhibit the same values, however this does not appear to be the case. It is perplexing.
  • MattMatt
    @MichaelG

    We found an anomaly in the units we tested.  When a device is placed in close proximity to an AC noise source, such as the mains wiring, the idle current consumption increased up to 100-150uA as measured.

    This is root caused to a default pin setting for the LED, which was recently changed enabling a new feature in one of our models.

    A new firmware will be released which corrects this issue and brings the idle current draw back in line with specifications.

    Your measured magnitude is likely higher due to a noisier environment with 230V wiring.

    A device without measurement equipment attached is unlikely to be experiencing the full magnitude of this increase, as inductive coupling to noise sources in the measurement cables is eliminated.
  • MichaelGMichaelG
    Matt, just an FYI; our testing area is at least 6' from an AC power source. The multimeter itself is battery powered. There is also overhead fluorescent lighting. But if it will be addressed by a firmware update, that'll be awesome. Any idea how long before the update is released?
  • EricEric
    A release candidate to fix the power consumption is now available.  You can upload it to your board with the Android or iOS MetaWear apps.
  • MichaelGMichaelG
    Updating to firmware 1.3.5 hasn't produced any recognizable change in the results I am seeing.
  • MattMatt
    Please confirm the results of your experiment on at least 3 devices.

    If all 3+ devices report the same, then it is a problem with your measurement setup.

    I have 5 units on my bench straight off our final QA test.  All measure 15-18uA at idle running firmware 1.3.5.
  • MichaelGMichaelG
    Matt, having tested a number of units on firmware 1.3.5, multiple times (connect/disconnect), this is the method I'm using and results I am seeing.

    I connect a device to it's battery (CR2032) through the multimeter. The reading for several seconds after connecting appears to be 1.2 mA, which I assume is some startup period. After several seconds, this drops back into the microamp range. The default advertisment interval seems to be 1/2 a second which is too quick to see a steady reading on the multimeter. So, I connect to the device through the API (C++) and change the advertising interval to a 10 seconds so that I can see the current draw between advertisments and then disconnect from the device.

    Once disconnected, at idle, on one of the tested devices I saw between 45-55 uA between advertisments. Letting it sit for 10's of minutes this slowly drifted down to 25-26 uA. The second device exhibited similar values on the first few connects/disconnects and then after a few trials started to show a steady 75 uA which remained consistant over 10's of minutes. This is the value I was reading days ago that prompted the initial inquiry. On one trial the device showed 380 uA after disconnect which I assume was an annomaly of some kind. I know you don't include BTLE listening in your figure, which I can't exclude because it's always on, in a disconnected, idle device, but these are my results. Use them as you see fit. If there are any other details you need, I'll try to fill in the blanks.
  • MichaelGMichaelG
    edited October 2017
    Ok. Today I was sitting performing some current tests while trying to 'sleep' the device. The current was a steady 17.6 uA (between advertisments) which is within you stated spec for firmware for 1.3.5. Now the only difference between today and last week is that the blinds were drawn and I had the airconditioning turned on. So I thought maybe it's something to do with temperature so I killed the air-con and opened the blinds to let the sun warm the room. When direct sunlight hit the sensor, the current jumped up significantly. Rotating the sensor to move the component side in and out of the direct sunlight saw significant current draw while changing orientation. Performing the same tests with the blinds drawn in low light resulted in the current returning to 17-18 uA. So either heat, or bright ambient light appears to be causing some issue. Down-lights seem to raise the current draw to around 400 uA at about 8 inches. So still not sure if it's light or temperature.
  • BenOBenO
    https://mbientlab.com/faq/#collapse-1-17685

    Can someone please give detailed information about power consumption in the following states.

    Sleep mode as shipped from Mbient

    Sleep mode as stated in the FAQ section.

    Idle mode when you are not communicating to the device, as in sitting there waiting for me to connect with the Mbient IOS app.

    Connected to the IOS app with BLE and running Data Fusion.


    Thanks, this is because the terms used seem to change around a bit in different posts or specs.


  • EricEric
    Sleep mode, as in the state the boards ship in, is approximately below the idle current consumption.  

    FAQ `sleep` mode is the same as idle mode, see the OP for specific numbers and the previous post by Matt detailing what "idle" means.

    Sensor fusion probably consumes ~15mA.  This is just an estimate based on the BNO055 power draw and assumes you are not streaming the data.  You should measure the power draw yourself while using the boards in your specific use cases to get the most accurate results.
  • BenOBenO
    Eric,

    I wasn't cherry picking , i was just trying to make sense of previous posts and understand the different states that the board is in.

    1. To clarify what you have said above, would it make sense to change the FAQ page from "sleep" to "idle"?

    2. Can you clearly define what the differences are between the Sleep mode that you ship it in and the Idle mode?

    Yes I know the BLE is turned off in "sleep" mode and its on in "Idle".


    3. Can you state the  minimum and maximum consumption when running the BLE advertisement?



  • EricEric
    There is no mention of cherry picking in this thread.  Keep comments in their appropriate threads.

    1. Yes, "idle" is more appropriate in the FAQ
    2. Sleep mode puts the SOC in to a low power state
    3. No, these values are not specced.  The best estimate I can give is ~35uA.
  • BenOBenO
    What does SOC stand for?
  • MichaelGMichaelG
    I have done some additional testing and it definately appears to be the ambient light sensor. A bright LED light directed at the board causes the current draw to increase greatly. Issuing the 'stop' command to the Ambient Light sensor through the C++ API seems to have no impact on the light sensor. It continues to draw high current under bright conditions, regardless. Is there anything that can be done to address this or is it a hardware issue?
  • MattMatt
    @BenO

    SOC means system on chip, which refers to the main controller in the devices.  Sleep mode puts this chip in its minimum power state, which will reduce system current by 2-3 uA versus idle.


    Temperature will always affect current consumption -- battery chemical potential and thus voltage will change over temperature altering consumption, as well as the performance of active devices in the many semiconductors.  Generally this increases consumption at higher temperatures, but depends on the component.  For the system as a whole you should not expect more than 30-50% -- idle currents are generally affected more than active currents, because leakage current increases with temperature.  This is why the specification is generally looser than measured in typical conditions.

    We will investigate the photo sensitivity and root cause the source once reproduced.  It may not necessarily be the ambient light sensor.

    Will your use case involve shining a bright light directly on the device?
  • BenOBenO
    No, The case does not allow light in, but there might be some illumination inside the case caused by the LED.
  • MattMatt
    @BenO @MichaelG

    We were able to reproduce increased current consumption under a high intensity light source.  Shining a very bright light -- iPhone Flash LED at <1cm -- directly on the edge of the magnetometer chip scale package increased the current consumption.

    We are evaluating opaque conformal coating and epoxy potting compounds to block incident light from reaching the component.

    Under your use case, it is unlikely that incident light from the LED would cause much if any increase due to the low intensity.  Given your battery life targets, the LED will have a very short on time if there is a direct impact.

    We will perform some lab tests to see if current consumption can be impacted with LED/magnetometer cross coupling.
  • BenOBenO
    Thanks for getting onto this.

    We need to get the MetaMotion C's power consumption down as low as possible in "Idle" and "Sleep" mode, as well as any unnecessary power consumption during normal use.
This discussion has been closed.