June 23, 2009
about 2 years ago
The hardware is abstracted by the OS; if you ask on the forums, or look at the datasheet for the STM32F205 (the processor inside there) you can see the “hard” specs. As for software, user code runs within a VM, hence absolute characteristics of the underlying CPU aren’t really applicable - you can’t access it directly. If the cloud connection is lost, code continues to run (see the offline mode APIs). All I/Os are tristate when off, and when on until configured by user SW (the exception is pin1, which has a pull-down on it if you sleep with pin1 wakeup enabled).
The documentation is improving constantly, but if you have questions the best thing to do is ask - then we can answer and improve the docs further.
We’ve shipped well over 100,000 of these so far, so make your own judgement as to whether this is “a thing for toys” (though, yes, it will be in some commercial toys this christmas). It’s aimed at both manufacturers, who want to easily internet-enable their products, and also makers who want to connect things to the internet quickly and easily. The reason it works just with our cloud service is that it’s not a wifi module - there are plenty of those out there already - the imp is a physical manifestation of a cloud service (which will always be free for non-commercial use).
If you want a plain wifi module, this is not for you - there are cheaper solutions out there. If, however, you want to connect something to the internet securely, using very little power, and without spending weeks working on it, you ought to try an imp.
You can connect sensors to the imp, and have it send measurements to (eg) Xively for graphing and to (eg) Twilio for sending SMS alerts. There’s example code for both of these services on devwiki.electricimp.com and plenty of people doing fun things on the imp forums.
Not quite; though you require a live internet connection to communicate, release 25 (which has been out a couple of weeks now) allows you to connect/disconnect under program control. You can use it, for example, to collect data from a cycle and attempt to connect to upload the data periodically - so when you get home from a bike ride, the data is automatically pushed to the cloud.
Yep, we will be rolling out different zones inc asia-pacific during the course of this year. We have examples that use a SPI flash to store audio to eliminate connection latency as an issue when using the imp to play audio - see the lala reference design on the devwiki.
See reply to your same post in the threads above…
Not peer to peer, no; with the phone running a hotspot, yes (but the data goes up to the EI server then down to the phone). You could also make a sensor that works with sporadic wifi connection, collecting time-stamped data locally then uploading it when a connection was available.
You own the code you write, without any question. Using the service grants us a right to compile it and distribute it to devices that you have nominated to receive the code, obviously, otherwise the whole thing wouldn’t work.
We do our best to maintain backwards compatibility, and have not broken compatibility yet (almost a year) - there are legacy implementations in a few places, eg SPI, to ensure backward compatibility for user’s code.
Given that we’re shipping hundreds of thousands of these devices, I believe we will be around for a while :)
We started with Lua, but just couldn’t hack the syntax. Python would have been nice but with both Python and JS, there were no VMs we could find that would work with the resources the imp has.
There is no subscription for developers, this is free - but yes, commercial use (ie making and resale of imp-based devices intended for non-developers) requires subscription.
As of release23, you can run local code without a network connection, and connect/disconnect under program control.
about 2 years ago
You should also probably consider some other things:
The imp system can work anywhere with WiFi, ie all 20 imps could be at different sites. To do this with the Xbee requires multiple X2 boxes, making it much more expensive. Obviously, this is dependent on the topology of your installations (if you need a mesh, then obviously Xbee is the only way to go!)
No gateway = no additional box for someone to screw with, and no additional wall-wart either
The imp system can do local processing at a node level, and this code can be upgraded for devices in the field very easily. The X2 has some features like this, but not quite as flexible I believe.
The imp has much richer I/O; whilst the Xbee has more pins, the imp’s pins are much more flexible - analog, digital, 2x i2c, 3x uart, 2x spi, etc. You can even do audio sampling and (next sw release) playback with no additional hardware beyond buffering.
If you’re not making a commercial product here, ie you’re just connecting 20 nodes and pushing the data to cosm or whatever, you can use the (free) imp developer account.
Data rates/power/etc are hard to compare - the imp is much higher power (~75mW EIRP) and is a much higher data rate (1Mbps upwards) but also takes more electrical power… and that doesn’t guarantee range. This type of thing is very application dependent.
Definitely worth trying both solutions out for size, though. The imp is stronger in some areas, the Xbee in other areas.
There’s a reference design here: http://devwiki.electricimp.com/doku.php?id=flora
…or you can hook up a vegetronix sensor, eg this one http://www.vegetronix.com/Products/VG400/ …to an analog input on the imp.
No public wish lists :(
Forgot your password?
No account? Register one!