Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P1 Stop mode using too much power #1098

Closed
wesner0019 opened this issue Aug 23, 2016 · 1 comment

Comments

@wesner0019
Copy link
Contributor

commented Aug 23, 2016

Im using a P1 with the 0.6.0rc1 firmware, system threading enabled and semi-automatic and am having an issue with the stop mode sleep drawing too much power. When stop mode is working as expected the power draw of my system is 2mA, but when its not working the power draw is 17mA.

I think I have narrowed down the issue to a particular case. Stop mode works as expected when particle.connect is called and actually connects to the cloud. But when particle.connect is called and the device is not within the wifi network, the system tires to connect (flashing green) and never connects to the wifi (because it cant). In this case when it goes into stop mode is when the power draw is 17mA.

I do call particle.disconnect, wifi.disconnect and the wifi.off prior to going into stop mode, but it seems like something is not getting powered down correctly due to the P1 trying to connect to wifi that has creds but it out of the wifi network.

Is there a way to force stopping the P1 from trying the wifi.creds?

does wifi.disconnect do anything if wifi.connecting is true?


Completeness:

  • Minimum test case added
  • Device, system and user firmware versions stated
  • Particle confirmed

BUGFIX

  • [Fixes #1098] [Photon/P1] Previously, when entering Sleep-stop mode: System.sleep(D1, RISING, 60); while in the process of making a Wi-Fi connection resulted in some parts of the radio still being initialized, consuming about 10-15mA more than normal.

@technobly technobly added this to the 0.6.x milestone Sep 6, 2016

@sergeuz sergeuz self-assigned this Sep 6, 2016

@technobly

This comment has been minimized.

Copy link
Member

commented Sep 6, 2016

Here's a simple test case that exploits this issue:

#include "application.h"

SYSTEM_THREAD(ENABLED)

unsigned long lastTOGGLE;
unsigned long lastSLEEP;
#define now() millis()
#define elapsedLED() (now()-lastTOGGLE)
#define elapsedSLEEP() (now()-lastSLEEP)
#define toggleLED() (digitalWrite(D7, !digitalRead(D7)))

void setup(){
    pinMode(D7,OUTPUT);
    lastTOGGLE = now();
    lastSLEEP = now();

    pinMode(D1, INPUT_PULLDOWN);

    // could erase credentials here in code, but I just did this manually with the setup button so that I could see the effects before and after credentials easily.
}

void loop(){

    // Toggle LED every 1 Second
    if( elapsedLED() >= 1000UL ) {
        lastTOGGLE = now();
        toggleLED();
    }

    // Sleep (turn off Wi-Fi) after every 10 seconds of runtime
    if( elapsedSLEEP() >= 10000UL ) {
        WiFi.disconnect();
        WiFi.off();
        System.sleep(D1, RISING, 10);
        lastSLEEP = now(); // should be the time we wake up (unless D1 is used)
    }
}

@technobly technobly modified the milestones: 0.7.x, 0.6.x Sep 13, 2016

@technobly technobly added the bug label Oct 13, 2016

@technobly technobly modified the milestones: 0.7.x, 0.6.1 Nov 29, 2016

@technobly technobly modified the milestones: 0.7.x, 0.6.1 Dec 20, 2016

technobly added a commit that referenced this issue Dec 20, 2016
technobly added a commit that referenced this issue Dec 20, 2016
@avtolstoy avtolstoy referenced this issue May 10, 2017
6 of 6 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.