Current draw on WIFI off

Hi what sort of current draw can we expect for forthcoming WIFI off feature?

Thanks as always

Right now we’re seeing about 3.5mA, but it’ll depend on which peripherals you configure. This will improve over time.

You can wake from pin1/rtc into wifi-off mode in about 60ms, which means you can do very low power polling, only waking up wifi when you need to send something or check-in with the server.

It’s going to be amazing! We will be able to sample and send at any rate with only a few lines of code! Take that Arduino…

Hugo that is good news I’ve got multi sensor with reed switch, PIR & temp sensor. I’m having to resort to very low power (5ua) 555 timers to provide wake-up pulses on open/close of reed sw & to ensure I don’t block the PIR from waking up the imp. Feels like very low power polling will simplify things for me.

Keep up the amazing work!

To further get you excited, here’s some example code for it which our embedded guys came up with:
`// Log an ADC value each minute, only tell the server once an hour

t <- time();

function hourly() {
local output = OutputPort(“data”, “string”);
imp.configure(“Logger”, [], [output]);
output.set(nv.data);
server.log(nv.data);
nv.data = “”;
server.expectonlinein(3600);
}

function log() {
local min = (t/60) % 60;
hardware.pin9.configure(ANALOG_IN)
nv.data = nv.data + format(" %d", hardware.pin9.read());
if (min == 59) {
hourly();
}
imp.deepsleepfor(60 - (time() % 60));
}

if (!(“nv” in getroottable())) {
nv <- { data = “” };
hourly();
}

imp.onidle(log);`

Sweet, so now have’ta ask a cupla questions

// server.expectonlinein();
Can the Agent gets access to this? so as to know if his.Imp rendezvous has been missed? Agent definitely ‘masculine’ feminine just don’t sound right.

// imp.deepsleepfor()
This fela replaces server.sleepfor/until() does it do anything different?
Can it have a handler so as to distinguish between pin & RTC wakes?

//imp.onidle(log);
There is subtle change here no?

Thanks for tantalising us we know it’s only weeks away :slight_smile:

expectonlinein() tells the server you’re going away, and when you’re expected back. Yes, agents will have access to this, but it looks identical to a sleepfor() as far as the agent is concerned - the imp is offline with an expected checkin time. If it misses that, it’s then offline.

deepsleepfor/until() is like sleepfor/until, but does not contact the server (hence the explicit expectonlinein call above). If you’re sleeping/waking with wifi off, you’d be using these.

There’s no change to imp.onidle. This is just queuing a call to log() when the imp is idle.

An Imp that misses its rendez-vous, counts as “disconnected” and the agent’s device.ondisconnect handler, if any, is called. (This is already the way it works with server.sleepfor/until.)

The server.expectonlinein/imp.deepsleepfor calls don’t really replace server.sleepfor/until: they just subdivide it. A call to server.sleepfor has exactly the same effect as a call to server.expectonlinein (“tell the server we’re going to sleep”) followed by a call to imp.deepsleepfor (“actually go to sleep”). But for applications like the one posted above, it’s helpful to have the two separate halves: that way, you can fib slightly to the server, telling it you’re having one long sleep – when in fact you’re having a collection of shorter ones.

There isn’t a “handler” for waking from deep sleep – the imp code is re-entered at the top. Anything else would be too confusing, as the handler might expect stuff set up in the main program to be active. However, if it’s leaking-new-features day here on the forums, then yes you will get hardware.wakereason() that lets you distinguish pin and RTC wake-ups. (With the usual proviso that, if a pin-wake-up pulse narrower than about 20ms happens to coincide with an RTC wakeup, the hardware itself doesn’t let us distinguish them.)

Peter

Thanks again to you both for it being “leaking-new-features day” it just get’s better post by post! Are all of these treats in the next release?

By chance does hardware.wakereason() allow for wake-ups on other pins than pin1? That would really help me

Yes, all in the next release. It’s a big one! (has the fixed rate DAC, wifi off mode, shutdown handling, new wifi code and many many bug fixes)

Wake up is only on pin 1 - this is a hardware limitation. Wake reasons are:

WAKEREASON_POWER_ON Powered on
WAKEREASON_SW_RESET Restarted due to a software reset
WAKEREASON_TIMER Woken up after sleep time expired
WAKEREASON_PIN1 Woken up due to wakeup pin being active
WAKEREASON_NEW_SQUIRREL Restarted due to new squirrel code being loaded

Wifi off e.g server.disconnect() >>Right now we’re seeing about 3.5mA, but it’ll depend on which peripherals you configure. This will improve over time.

Hugo would it make sense to re-configure a pair of I2C pins to digital outputs write a 0 to them to conserve power? And re-configure I2C when need to a read?

I2C doesn’t lock the clocks up as I remember, it’s things like UART (which need to be listening with clocks ready to receive a byte at any time).

If you did want to try it, you’d configure the pins as digital_in, and let the external pull-ups maintain their high state. If you wrote 0 to them then you’d be burning power in the external pull-ups.