- Wed Mar 30, 2016 4:13 am
#44505
Oldbod wrote:Hi. I'm looking at temperature reporting, and need to run some units battery powered. One alternative is just to use commercial Oregon Scientific units, which just bash some values every 40 secs or so out on 433mhz . The batteries on these last quite a long time,possibly because they transmit on lower power but also because the transmit sequence is short (no handshaking).
I have seen somewhere that it takes the esp8266 a while to wake up and transmit a value, possibly partly to dowith reestablishing communication with the receiving AP after a sleep.
So - I'm wondering If power consumption might be lower if rather than a complete deep sleep (which from reading the spec for 8266basic and the spec for the chip Im assuming is the standard deep sleep/reboot) followed by restart and reestablishing a link, it might be lighter on power to keep the link alive.
Problem I have is twofold - firstly I have no facts to support this nor knowledge of the protocol that keeps the 8266 - ap link current, and secondly I don't know how/if basic supports the lighter sleep modes. I'm also wondering if basic uses the 512bytes of user rtc ram for its own purposes? Eg variable/chaining info.
Or if im barking up completely the wrong tree?
Btw - came across another version of basic for 8266 the other day, based on a mature product tree. This one is many streets(probably cities!) ahead in terms of ease of use. Great achievement!
The meaning of "connection" varies alot.
Connection on the Network/Transport layers is very different from Application layers. (You might wanna check OSI standarization before continuing reading).
Connection on Network/Transport layers requires what we call a "heartbeat", or "keepalive". If two machines want to keep connection, they must send a signal before the keepalive time. For example, if machine A doesn't send a signal in 2 seconds, machine A is considered disconnected.
Connection on Application layer is a whole other thing. The easiest example to give would be sessions on Facebook. If you've read about MQTT, it would be the persistent session option.
Anyway, what you could do is :
- Using a static IP instead of DHCP : DHCP being the protocol used by the AP to give an IP adress to each connected machine. A machine with a static IP wouldn't require DHCP.
- Keeping your AP open (with no password, nor encryption) : Now we're talking about WEP, WPA stuff ... Using such protection is not only about having a password so to connect; all data keeps being encrypted before sending.
- Keeping visibility between AP and the chip
- Avoiding the use of mobile phones as AP : sure it would work using it as an AP but a mobile phone is not as fast as a router.
Applying all of these might make you gain up to 2 seconds.
You could reduce the duty time (I call it this way :p the time while the chip is waken-up) by managing delays in your program. Try installing some sort of pseudo-threading. By using pseudo-threading, I succeeded in bringing the duty time from 22 seconds down to 9 seconds.
I hope that helped, and please, if I made any mistakes, lemme know.