ESP8266 Developer Zone

Re: Light Sleep unexpected Behaviour.

2016-12-16T22:13:51+08:00

Maybe Lars i am not following best practice.

Statistics: Posted by Mdb — Fri Dec 16, 2016 10:13 pm

Re: Light Sleep unexpected Behaviour.

2016-12-16T21:24:56+08:00

Very disappointing in comparison to what is stated in the data sheet and in comparison to what is stated here viewtopic.php?t=133

Thanks for investigating.

Statistics: Posted by Lars R. — Fri Dec 16, 2016 9:24 pm

Re: Light Sleep unexpected Behaviour.

2016-12-15T23:30:08+08:00

After further investigations i got Light Sleep working , the problem at startup remains, it is a matter of trade off :
- Mandatory in my case is to request light sleep only AFTER first tx/rx cycle, otherwise even after sdk enables the sleep mode, the current consumption between beacons or operations ( tx/rx managed by spi ) stays high most of the time.
- Slow down beacon at least at the frequency of the task i use to request to my module. I use to tx/rx every 500 ms and i set beacon intervals at 500 ms ( when beacons arrive during hi consumption periods tend to enlarge the hi consumption time )
- Using NON OS SDK 2.0.0 , RTOS version seems less efficient.
- Accept the fact i need to about 18/20 seconds after reset for Light Sleep to operate efficiently.

Attached my best light sleep sequence, labels contain some Italian terms but you can translate them easily.

Legend :
- Purple is the current consumption ( calibrated in mA but it contains consumption of a micro, i.e. a fixed offset ! )
- others are communication signals

I can get the first tcp transmission after 3,3 second ( best case with good power signal and in a free channel ) .
The pm ( power manager ? ) system commute to light sleep after 12.8 seconds ( but is requested at time 3.3s).
The system is stable after 18.8 seconds.

Edit : with 200 ms beacon interval ( rtos does not produce 100 ms beacon intervals...) using right sequence i got Light Sleep still working but the period of high consumption is wider..best case from 90 ms to 145 ms.

Statistics: Posted by Mdb — Thu Dec 15, 2016 11:30 pm

Re: Light Sleep unexpected Behaviour.

2016-12-05T23:59:39+08:00

So, light sleep is not working reliably even with today’s SDK 2.0?

Best regards,
Lars

Statistics: Posted by Lars R. — Mon Dec 05, 2016 11:59 pm

Re: Light Sleep unexpected Behaviour.

2016-12-05T17:07:31+08:00

Some facts after a set of experiments with NON OS SDK 2.0.0 :
- Beacon interacts with the 'active part' after Light Sleep wake up : beacon just after wake up => more time needed to go back to sleep ( from 90 ms to 175 ms )
- Beacon interact with stack heavily : slowing beacon time frame to 500 ms ( and i cannot go below 200ms ) even mixing up light sleep starting sequence i got no more the previously depicted max consumption result.
- To be sure to have lowest consumption at start up i need to call for light sleep after pm open succeeded : is there a way to sync task with this message ?
- If i don't call for modem sleep just after the wake up from light sleep i can go back light sleep again but with a mysterious task running with 3 s period with consumption equal to model sleep that lasts between 2 or 3 beacons

To be honest this is too much Emprical, i'd prefer more detailed infos on it through docs .

Statistics: Posted by Mdb — Mon Dec 05, 2016 5:07 pm

Light Sleep unexpected Behaviour.

2016-12-01T21:59:04+08:00

Good afternoon guys,
Here's the situation :
- station mode, tcp socket
-RTOS SDK V1.4.2
- Light sleep after every data transmission
- wake up from Light Sleep with connected ISR on GPIO0
- task waiting a semaphore to be released by wake up pin call back
- my code wait for a semaphore so is not doing anything between the next external trigger
- after every wake up transmits a bunch of data through tcp socket
- wake up time 1 second
- station and soft ap are close to each other in a relatively clean channel.

Facts :
- call back got called after external signal became high
- light sleep works ( just for a while unfortunately )
- data received correctly from esp server ( built with at binary )
- After a bunch of seconds of correct behaviour power consumption start to stay really high, though system works correctly => REALLY UNEXPECTED.
- WHY ???
- with a shorter wake up time , let's say 0.5 seconds max consumption start even earlier!

Attached a snapshot of transition to high current consumption :
- purple is current consumption
- yellow is external trigger to wake up Light Sleep
- blu is light sleep wake up gpio call back ( it toggles at every wake up)

After more or less 20 seconds working the system cannot exit from maximum consumption at the end of a dealing with a beacon ( purple peaks ).

Does anyonone experienced good results with the same approach? maybe with another sdk ?
This way the system is totally unreliable in embedded system attached to batteries as my requirements ask!

A bit of code :

Task sending data after wake up controlled with a semaphore .

Code:

      case SEND:
             if ( xSemaphoreRd ) {                
               sprintf(localStr,"Debbio::WAIT_SEND::Sem releleased, executing op..\n");
                DebbioPutStr(localStr);
                //vTaskDelay(5/portTICK_RATE_MS);         
               if (connected){
                  if ( send ( sta_socket, pData, strlen(pData) + 1, MSG_DONTWAIT ) < 0){ /* Non blocking con DONTWAIT */
                      close(sta_socket);
                      sprintf(localStr,"Debbio::WAIT_SEND::Error not connected\n");
                      DebbioPutStr(localStr);   
                      connected = false;
                   }                
                  }
                   _xt_isr_unmask(1<                  waitCb = true;
               while( ! wifi_set_sleep_type(LIGHT_SLEEP_T) ) {}
                xSemaphoreTake( xSemaphoreRd , portMAX_DELAY );
            }                             
             break;

EDIT :

I tried with NON OS SDK 2.0.0 and i got the same result.
Here i wake up light sleep with gpio, with another ext interrupt on a different gpio i post a message to a task for data transmission, after data sent call back i ask the system to go back to light sleep, without result after 15/20 seconds.
No Bueno!

Statistics: Posted by Mdb — Thu Dec 01, 2016 9:59 pm