Wiki says “Nora uses a boost power supply which is only enabled when the imp is awake…” Is this an additional set of “boost” circuitry? If so any chance that you can add the Schematics to Nora ref design?
I’ve want to evaluate 2xAA Lithium & CR123 battery designs.
I’d like to see those too.
I bought a couple AA 3.6 V batteries from Saft LS 14500 (http://www.saftbatteries.com/Produit_LS_cell_range_303_6/Language/en-US/Default.aspx#DL2).
And some CR123. The problem with the CR123 was that the holder is hard to find.
Hi been using the Saft both C & AA but the design I have won’t stand the cost.
C123A holder from Rapid http://www.rapidonline.com/Electrical-Power/CR123A-Battery-Holder-PCB-Mount-18-0153/?source=googleps&utm_source=googleps
Nora ref design should be up soon. We use a line on the imp to enable the DCDC when necessary (otherwise we run directly from the battery, down to 2.0v).
We’ve been playing with CR123s and the imp runs from them quite nicely. We’ll be formalising this at some point (including correct wait state configuration on the SOC flash) but in our experiments without mods we run fine down to about 2.5v.
Just to be sure : The Saft LS 14500 supplies 3.6 ~ 3.67 volts, the max voltage of the imp is 3.6 V. Can the imp be powered by the Saft LS 14500 directly ?
The CR123S supplies 3 V, is that enough to run the imp with wifi on ?
Saft LS 14500 directly?
3 V, is that enough to run the imp with wifi on ?
My understanding is No to both imp max 3.3 but wifi needs 3.3 hence the boost thingy in the Nora ref design to take 3v to 3.3v for transmit receive.
You’ll find some details in this thread. http://forums.electricimp.com/discussion/comment/958#Comment_958
Max imp input voltage is 3.6v.
Nora is designed to take AAs to 3.0v - we need the boost as, eg, 2xNiMH AAs are typically 2.4v which is too low. The imp will run - including wifi - down to about 2.5v but right now you need to stay above 2.7 as the flash timings are not configured for lower voltage running.
Ok for a non-hardware guy could comment on the following
//Direct battery connection to Imp
2xAA Alkaline 3.0V - Yes/No?
2xAA Lithium Inon 3.0V - Yes/No?
2xAA NiMH 2.4V - Needs Nora’s boost to 3.0V
CR123/CR123a 3.0V - Ok
lithium-thionyl chloride 3.6V - Needs Low LDO for sleep & meaty LDO for Wifi
Thanks
2xAA: you need a boost DCDC in order to get decent life out of the cells. They start out around 3v, but are “used up” at about 2v, which is too low for the imp.
Note that alkaline cells are not good with high current peaks (high internal resistance). You’ll find they work when fresh but even with a boost DCDC you are likely to run into issues before the cells are used up. This is not an issue with AA lithiums (eg Energizer Lithium) or NiMH cells.
Resurrecting this thread…
I can’t find a Nora schematic, so I’ll just ask some questions.
Application: My impee will run on 2 AAs and have a switching supply and a separate microcontroller to handle I/O. The IMP will either be powered down or in a deep sleep waiting for a wakeup from pin 1.
I can control the power supply from the external microcontroller and simply power the IMP up and down, or put the IMP in deep sleep and wake it up and let it control the power supply. The deep sleep current of a few uA is close enough to zero that functionally it doesn’t matter which method is used. The end objective to maximize battery life is (to state the obvious) minimizing the IMP awake-time.
Q: Is there a substantial difference in elapsed time for cold boot / run / communicate / off vs wake up / run / communicate / sleep ?
Q: When the IMP wakes up, which pin is driven to enable the power supply? Is there a defined sequence for powering up and powering down? How does the IMP know when the power supply is up and stable?
Q: What voltage must be provided as a minimum to enable full IMP functionality? I’ve seen 3.3V, 3.0V, and 2.7V. So for a real production product, what is EI’s best guidance at this time?
Thanks.
On your Q’s:
Warm wake is better as it will just run your code immediately (without waking wifi). On a cold boot we will ALWAYS wake wifi because we need to see if there’s any new firmware. We do this in the background so it doesn’t impact when code is run.
The pin to drive and polarity is stored in the atsha, as it’s dependent on the hardware (and we need to be able to turn it on from the bootrom for upgrades). When we post the nora design we’ll tell people the API to program this (you do it with the imp). The imp waits 20ms for the PSU to become ready, though this could be made programmable.
Right now, you need to guarantee 2.7v to the imp when wifi is on. When wifi is off, it will run down to 1.8v. For running from single LiMnO2 cells with no PSU we’ll be adding an intermediate mode, as wifi is ok down to around 2.5v, but the flash timings need adjustment for this mode.
Nora rev2 is due shortly, Brandon’s just added the accelerometer wake to it 
With another microcontroller in the system, the imp will only be responsible for communication. So it will power wifi and phone home every time it wakes up. In this scenario, is there a substantive difference in runtime between a warm wake and a cold boot?
The main difference is that wifi will stay up longer if you do a cold boot. With the new code, we stay up 60 seconds on cold boot even if the squirrel code tells it to sleep (otherwise, you would have issues reconfiguring an imp if the code on it was misbehaving).
I think it’s worth distinguishing more clearly between what imps currently do, what the next release will do, and what our ultimate goal is.
Currently, imps always power up the wifi on every boot, even warm boot. On a cold boot, they won’t do anything until they’ve joined wifi, contacted the server, and verified that the Squirrel they’ve got is still the latest. On a warm boot, they start running Squirrel straightaway, but only bother joining the network the first time Squirrel needs to send any data, e.g. on imp.configure() or server.log().
In the next release, the Squirrel behaviour will be the same, but the wifi will remain powered-off until first needed. In cold boots, it’ll be needed straightaway to verify the Squirrel, but in warm boots, the wifi may not get powered on at all if the Squirrel goes to sleep again without ever sending any data to the server. (But for instance, it might have logged something to the nv table.)
Ultimately the goal is to run local Squirrel even on cold boot if the wifi can’t be found, but that will involve considerable care to avoid the situation where bad Squirrel “bricks” the imp so it can’t be upgraded again, part of which care will be the 60s sleep override that Hugo mentions.
Even when we’ve implemented all that, though, for your purposes warm boot is likely to remain faster.
Peter
Peter could you clarify
//Cold boot
Power up
//Warm boots
imp.sleep()
imp.wakeup()
IO event handlers()
//?
server.sleepfor()
server.sleepuntil()
IO wake pin
Are server.sleepXX() & IO wake treated as cold boots?
Thanks as always
It’s really about the reason Squirrel restarted.
Cold boot = power up
Warm boot = reawaken from server.sleepfor/server.sleepuntil (whether by timer or by wake-up pin)
The others (imp.sleep, imp.wakeup, IO event handlers) don’t count as boots at all, and have no effect on the wifi or Squirrel state.
Peter