Current consumption study

Home Forums mDot/xDot Current consumption study

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #16756
    kaz ola
    Participant

    Dear,

    I have prepared the following code in order to study the current consumption of both mDot (Jumper in the middle of UDK devel board) and xDot (JP30 in mtxdot USB small board).

    I have mixed feelings, while I see differences between mDot and xDot, I am clearly misunderstanding something, as you can see in the “RESULTS” section below.

    For mDot measurements, I’m using:
    – mDot/xDot examples package for mBed.
    – libmDot-dev-mbed5, rev: 79
    – mbed-os 5.3.2 as required by previous “libmDot” lib.
    For xDot measurements, I’m using:
    – mDot/xDot examples package for mBed.
    – libxDot-dev-mbed5, rev: 33
    – mbed-os 5.3.2 as required by previus “libxDot” lib.

    Here is the code (without #includes).

    
    #define SECONDS_SLEEP   20
    #define DEEP_SLEEP      0
    int main() 
    {
        mts::MTSLog::setLogLevel(mts::MTSLog::NONE_LEVEL);
        pc.baud(115200);
        dot = mDot::getInstance();
    
        // main sleep bucle
        while(1)
        {
            pc.printf("\r\n> mDot/xDot gonna sleep for %d seconds w/ DEEP_SLEEP flag = %d.\r\n", SECONDS_SLEEP, DEEP_SLEEP);
            if(dot->getStandbyFlag()) 
            {
                pc.printf("\r\n    > Waking from deepsleep.\r\n");
            } 
            else 
            {
                pc.printf("\r\n    > Fresh boot or normalsleep.\r\n");
            }
    
            // going to sleep for "1st par" seconds, "2on par" deepsleep
            sleep_wake_rtc_only(SECONDS_SLEEP, DEEP_SLEEP);
        }
    
        return 0;
    }
    

    RESULTS are:
    mDot NO DEEP_SLEEP —————> 40.2 uA, says “normalsleep”
    mDot W/ DEEP_SLEEP —————> says “this mDot HW does not deepsleep”
    xDot NO DEEP_SLEEP, JP5 open —–> 6.5 uA, says “from “deepsleep”
    xDot NO DEEP_SLEEP, JP5 closed —> 6.5 uA, NO UART OUTPUT
    xDot W/ DEEP_SLEEP, JP5 open —–> 500 uA, says “from deepsleep”
    xDot W/ DEEP_SLEEP, JP5 closed —> 500 uA, NO UART OUTPUT

    What I do is to test mDot/xDot with same code playing with the two #defines. For xDot, the guide says to close JP5 for lower current consumption.

    With these, my question is threefold:

    Q1) mDot seems to detect when entering deepsleep or not, even if it can only really enter “normal” sleep. Why is my xDot only entering “deepsleep”?

    Q2) xDot seems to consume less, even if should consume 2 uA. Why is 6 uA instead of 2 uA? Why JP5 seems to not have any effect for me?

    Ok, hopefully, my data and questions will be useful for others. Please, let me know your opinions and any advice about what am I doing wrong 🙂

    Have a really nice day!

    #17524
    Mark Ruys
    Participant

    Dear Kaz Ola,

    I have more or less the same questions. JP5 on the xDot seems to have no impact on the current measurements. What is the purpose of JP5?

    Furthermore, I measure 8 uA in deep sleep, instead 2 uA from the datasheet. Did you manage to lower your power consumption to 2 uA? Do you know what explains the difference?

    Best,
    Mark

    #17528

    For the question about deep sleep not being supported on the mDot, please see the section “Deepsleep functionality change” on page…
    https://developer.mbed.org/platforms/MTS-mDot-F411/

    I believe the hardware team designed in JP5 in order to ensure the xDot could be isolated from the developer card prior to having a complete understanding of what could be accomplished in software. In software, we are programming the IO as analog no pull. So leaving the connections in place (JP5 removed) has no impact on power draw.

    I have tested a couple xDots using the AT command application and I am measuring 1.6uA in sleep. The AT command application can be downloaded here: http://www.multitech.net/developer/downloads/#xdot
    Can you try that and see what you measure?

    Kind regards,
    Leon

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.