I ran a battery life time test in the last week. It ran for 3days. It went to sleep and woke up 30 thousand times. The test started Mon 20 Oct 5pm and ended 23 Oct 5pm. The average time to connect was 1.6s. It is interesting to see that for a long period the minimal time to connect is 1s, then 2.25s and later1.8s. Here at the hackerdojo we have a couple of accespoints so it may have switched from one to another. Maybe there was another reason. I just wanted to share that if you have a battery powered device that is active for a couple of seconds and sleeping for hours, a large part of the battery is wasted in just connecting.
In our program we read the battery voltage before we connect to wifi. This function is ussually called 11ms after imp start up. However 8 times this code was called between 2.2-3.5(5x), 17-25s (2x) and 450 seconds(1x)! I think something went wrong in the IMP OS. At those times the boost converter was active because I read the 3.30V in stead of battery voltage (2.2-3.6V). So a lot of battery power was wasted. I hope the radio was off.
I’m afraid there’s not a lot that we can do about this; connecting does take time. The wifi chip has to be booted, it has to associate (time will depends on AP, how busy the network is, what the interference levels are, etc), DHCP (depends on all the wireless variables PLUS the DHCP server), DNS (same), TCP connect (very network dependent) and TLS connect (again, network dependent).
I’m interested in the exact time you saw the connection times change; I suspect this was related to the server deploy, as we also moved server location, but as it’s still west coast 0.8s seems excessive even for several round trips (ie, the issue could have been with a server-side change too).
Got the exact times?
Are you sleeping or doing programmatic connect? Would be interested to see how you found 22s/450s after boot if there are no non-deterministic code paths between wake and sampling the voltage.
I saw connection time change on 22 oct 10.08 and 22 oct 17:15 PTZ.
In our program we wake up, read battery voltage, sample a sensor, connect to wifi (it starts with a server.log call), send sample data, and then go to deep sleep for 3 hours.
Using hardware.micros we log timing of events in our code (when we read battery voltage, when we connect, when we are connected, when samples are uploaded and right before going to sleep).
Normally battery voltage is read after 11ms. 5 times it was after 2-3s. 2 times around 22s, and 1 time 450s. The weird thing was that all these times the boost was enabled and we could read rssi(between -50dB and -61dB). Normally radio is off (rssi=0)at this time.
Very strange; could you email us your test code? Could this be the micros counter not resetting to zero?
If the wifi is up when Squirrel starts, then either it was a cold boot (the imp had lost power altogether) or a Squirrel run-time error (but in that case it should have logged the error in the IDE).
Peter