Heaps more free memory for most applications: both the efficiency of Squirrel’s RAM usage and the efficiency of the impOS have been improved to give typically ten’s of kB more free memory for Squirrel applications
Run code at cold boot: will now run cached squirrel code even if the imp cannot connect to the server on a cold boot. The imp will try to contact the server to verify it has the latest code for up to 10 seconds at boot before running the code anyway - this is to protect against bad code having been loaded onto the imp in error.
More aggressive connection maintenance: deals better with more scenarios that could cause an imp to become disconnected.
Pulse triggered pulse generator: can be used to generate microsecond-accurate triac dimming controls
Improved Android blinkup performance: trilevel blinkup is now more resilient against misbehaving phones.
Expanded LED codes: finer-grained detail on connection failures now provided.
WiFi scanning API: enables programmatic joining of open networks or indoor geolocation features
Improved fixed frequency DAC: audio flag enables popless playback with smooth ramping
Is there a way to tie hardware.lightlevel() to an Imp wakeup? That would be pretty handy for battery powered projects like the mailbox project that @JerryW is working on.
Yeah, I didn’t ask that correctly. My thought process is to connect the phototransistor to a wakeup like pin 1. Seems like that might be easily done on a module, but perhaps not on a card, unless there is a way to tie them together internally.
What is the minimum voltage required to wake the imp on pin 1?
don’t know. I use the Smartmaker imp002 evaluation kit, but blink-up does work (kind of).
Maybe because I am still on release a9d96b0 - release-27.6 - Fri Nov 15 09:29:21 2013?
Can I buy that Amber board (PCB) somewhere?
You are my friend. Thanks. hardware.voltage() works as well now
–edit–
looking at my log at Xively (https://xively.com/feeds/1339461031) I noticed that the imp started reading at 2:30 this morning…
strange
I have two of the Smartmaker imp002 breakouts, and though I haven’t noticed anything odd, there 4 capacitors that also should be in place, if you look at the spec sheet and reference designs. (That aren’t on the breakout) I believe they help stabilize and increase imp performance. I’ll probably pull those modules off and put them on a proper impee at some point.
hi, should the update be automatic? I’ve had a number of Imp001’s update, but not my Imp002?
I’m particularly interested in the hardware.voltage() as I’ve got Vanlg/Vref=2.048V so interested to have it measure the Vcc which is LiFePO4 battery voltage and will gate the rest of the activity.
Ah. It turns out that hardware.voltage() always measures VDDA/Vref+ and not VDD. Due to an oversight in the hardware designs of both IMP-001 and IMP-002, it is not possible to measure VDD internally if it’s different from Vref+. Sorry about that. Your best bet is to use the circuit someone posted the other day, to measure your battery voltage on a separate pin.
@neilh it’s a staged rollout; as you quoted your mac address there I’ve forced it for that unit but generally we’ll complete the rollout over (I suspect) the next week barring anything unforeseen happening.
Peter: Bummer on hw voltage, Thanks for the explanation, I was hoping it was a sw issue.
Hugo: Thanks - its upgraded.
I noticed something interesting - but its not an issue for me - at the end of downloading OS code, it looks like imp.getpowersave() is still valid - that is a soft restart. I would have assumed a cold restart with imp.getpowersave() == false.
I have a the beginning of my module - and it didn’t seem to be executed after the OS Upgrade.
`
local wakeReason = hardware.wakereason()
if (false == imp.getpowersave()) {
if (WAKEREASON_TIMER !=wakeReason) {
imp.configure(“WaterDepthImp002”, [], []);
server.log(format(“impMac %s impId %s SwVer %s”,imp.getmacaddress(), hardware.getimpeeid(), imp.getsoftwareversion() ));
`
2013-12-03 08:39:54 UTC-8: [Exit Code] imp restarted, reason: wifi outage
2013-12-03 08:39:54 UTC-8: [Power State] Power state: asleep=>online
2013-12-03 08:39:54 UTC-8: [Status] Downloading new code
2013-12-03 08:39:54 UTC-8: [Status] Downloading new code
2013-12-03 08:39:54 UTC-8: [Status] firmware update triggered
2013-12-03 08:40:14 UTC-8: [Power State] Power state: online=>offline
2013-12-03 08:40:30 UTC-8: [Exit Code] imp OS upgraded
2013-12-03 08:40:30 UTC-8: [Power State] Power state: offline=>online
2013-12-03 08:40:30 UTC-8: [Status] Downloading new code
<<is there a cold or warm code restart here after an imp OS upgrade?>>
2013-12-03 08:40:31 UTC-8: [Device] Vbat=2.060V Temp= 10.5C(0.307 0.3072V 0.308) Depth1=0.410Ft(0.233 0.2336V 0.235) Depth2=0.542Ft(0.244 0.2444V 0.246)
2013-12-03 08:40:31 UTC-8: [Agent] TsPush:(array : 0x7fe80efa1100) field4=10.4573 field3=2.06 field6=0.541921 field5=0.40968 field2=1 field1=1386088830
2013-12-03 08:40:31 UTC-8: [] sleeping until 1386089100000
I just implemented imp.scanwifinetworks() at the beginning of my wakeup which gave some very nice results local scanResults = imp.scanwifinetworks(); foreach (idx,val in scanResults) { server.log("SSID="+ scanResults[idx].ssid +" Ch="+scanResults[idx].channel + " rssi="+scanResults[idx].rssi +" Open=" +scanResults[idx].open ); }
An improm upgrade probably counts as WAKEREASON_TIMER, so your code wouldn’t be executed because the secondif is false – not the first. This seems to have confused people, though, so in the future we might invent a new WAKEREASON specifically for improm upgrades.