-->
Page 2 of 3

Re: Wake Up ESP8266 with WiFi Packet

PostPosted: Sun Jun 12, 2016 10:36 am
by Cap
@schufti: The ESP8266 SDK allows for registering for TCP/UDP receive callbacks. So, would it be possible that when the ESP wakes up periodically (300ms sleep/3ms wake cycle) in modem/light sleep, that that implementation underneath these API detect the pending traffic (DTM3), and receive the traffic from the AP and invoke the callbacks?

The question then is : does this actually work, are there any 'gotcha's?

Re: Wake Up ESP8266 with WiFi Packet

PostPosted: Mon Jun 13, 2016 2:47 am
by schufti
@Cap:
sorry, no experience to this topic on my side.

I suggest starting up with a small sketch that establishes a WiFi connection in the setup, then goes into "light sleep"; intermixed with some serial.print to see how far we come (even beyond "light sleep"?).
The loop just being a serial.print to see if sth happens, with another call to "light sleep".

Re: Wake Up ESP8266 with WiFi Packet

PostPosted: Mon Jun 13, 2016 2:33 pm
by Cap
@schufti In general if Espressif claims the implementation is per the 802.11 standard, as they do per copy-paste of their spec in your first post, then the only way for it to work seems to be the TCP/UDP callbacks. If it does not work as they claim then it would be a bug in their implementation, and likely harder to demonstrate reliably.

I wonder why JohnSmith999 mentions that modem-sleep look like the fit. I think it would seem to depend on the application needs. Light sleep would give better power savings depending if acceptable for the application by a large margin, yet DTIM handling would be same. It would be interesting to know the reasoning he applied, and I really am curious to know that.

Re: Wake Up ESP8266 with WiFi Packet

PostPosted: Mon Jun 13, 2016 2:53 pm
by schufti
If you are programming the esp in plain c(++) and the sdk, then I am with you. If you are using arduino, how do you know that igrr hasn't implemented sth clever allready?
Btw, dtim is only valid for broad- and multicast transmissions. For unicast connections this 'marker' is packed into the beacon. But that is ok since the description mentions 'beacon' too.

But nobody is keeping you from extending my suggested sketch by adding the callback routine, garnished with another Serial.print