Our application is as follows. Deepsleep for 4 hrs, wake up, connect to wifi to get sample settings, disconnect from wifi and do sampling, reconnect and send the sample data, and then deepsleep again. Connecting to wifi takes 1-2s. I need to disconnect from wifi because our sensors sensitivity depends on power supply voltage and when wifi is ON, there is more noise on the power supply. Can we do the reconnect much faster? Or remain “connected” when radio is off?
There are some improvements to WiFi reconnect time on the roadmap, but they probably won’t help you much if you’re already connecting in only a couple of seconds.
But – serious question! – if you only connect once every 4 hours anyway, how come 2s isn’t fast enough?
Peter
It would be great if the connect time can be improved, and even beter when the reconnect (a few secs later) is much faster.
In a cycle where the device sleeps for 4 hrs and is active for a couple of seconds, 20% of the energy is spent on connecting and 75% is spent on sleeping. That 20% is worth trying to improve. Once the wifi is up, it takes very little time to send and receive data from the internet, so it takes only 5% of the energy spent.
Do you really need to get sample settings every time? Could you get them once then save them in nvram during the deep sleep?
Sounds like your scenario is very similar to mine, but I can’t get it working. Would you be willing to share code or review the code that I posted at: http://forums.electricimp.com/discussion/3128/deep-sleep-temperature-sample
Thank you.
I ran some tests for a couple of hours on different networks to test the connect time. On my home network (Comcast 25Mb/5Mb and good wifi strength) it takes on average 4.5s. On the wifi network in the Hacker Dojo in Mountain View,CA (1Mbit/1Mbit and good wifi strenght) it takes on average 1.1s. And on a portable Verizon 4G/LTE wifi acces point (4 out of 5 bars 4G and good wifi strength) it takes on average 2.0s to connect. I calculated (for our application) that in my home network 60% of the battery capacity I spent on connecting and in the Hacker Dojo network 35% of the battery capacity is spent on connecting . So it does make a huge difference.
Your home network sounds like it has a very bad DHCP server (or DNS server) for connects to take so long; what’s the setup there?
I have Technicolor wireless gateway TC8305C and speed is 25Mb/5Mb as expected. Wifi is set up for 802.11 g/n because all our devices support it. I pay $9/mo for lease. Is this a bad gateway?
Hugo, I accidently replyed to your comment while being logged in to the IDE with my colleagues username, montu17. I have the 25Mb/1Mb comcast and TC8305C gateway
Well, it just seems very slow. What blink codes are shown during the 4.5s?
red-orange-off-red-orange-off-red-orange-off, it means getting ip address. What can you say about this?
@montu17 This is the imp waiting for the DHCP server; usually this is a handful of milliseconds. There’s no reason this should take so long. Can you set up a DHCP address reservation on the router and see if this is any faster?
If it only takes a handful of milliseconds, you don’t have a very good DHCP server. They’re supposed to check that the address isn’t in use before handing it out; the standard ISC DHCP server, common on Linux, spends a second doing this before replying. That still isn’t four seconds, though: perhaps it’s having to try several times to find a free address. Do you have any devices with static IPs on your network, which are in the range that the DHCP server is configured to hand out?
Peter
Most DHCP servers in home routers don’t spend very long ARPing before handing out an address 
My gateway gives out IP addresses in the range 10.0.0.2 to 10.0.0.252. Lease time is 1 week. When I look at the list of connected devices I see IP addresses up to 10.0.0.27 have been assigned. I assigned static address 10.0.0.100 to the IMP. It still blinks three times red-orange-off before it turns green.
Setting the network to open (no password) and doing a monitor mode tcpdump/wireshark of it would give more detail, but the light pattern does indicate that DHCP is taking time.
Some DHCP servers will do a ping check before handing out an IP address as ARP’s are only good on a connected subnet, meaning there’s delay for the ping timeout. An ARP precedes a ping on a connected network and both take time to timeout.
Wireshark really is great for examining what’s happening on the ethernet and should give you an answer pretty quickly. It’s easy to see what’s happening on the wired side of the access point with this config; router <-> old Ethernet hub (not switch) <-> Access Point. The wireshark PC or laptop is also plugged into the old hub.
It is possible to sniff the wireless frames directly from the air but it’s harder to setup and very few wifi modules support it, but it’s great if you can swing it.
An old Cisco AP is cheap and can debug packets. For this use a proper 1200 series Cisco AP or better and nothing Linksys. Also make sure the power pack comes with the AP as they are worth more on ebay than the AP itself.
Macs are great for packet sniffing; the built in wifi will work in monitor mode, no messing around at all.
The ARP timeouts can be pretty short. Not seen an embedded router do ping checks before now, but I’m sure some must. Whatever dhcpd we run in the Los Altos office on our linux box does s DHCPOFFER essentially instantly.
Hugo: How did you set up the IMP with a static IP?
I’ve been searching for a way to do that but can’t find anything about it.
jrsikken assigned a static IP, by using a DHCP reservation (basically assigning a static mapping between a MAC address and an IP address, so that MAC will always get that IP).