What are the interface boundaries: how fast can the imp sample, what’s the maximum size/rate for sample transmission, etc.
Eg. could the Imp handle sampling voice/sound from a microphone?
If so, for how long of a sample period, before buffers overflow or some other limit is reached?
Can this data be transferred over the network to an independent server, via the ei servers?
My impression is that the imp is not suited for this kind of thing. Prove me wrong!
The feeling I get from the scraps of info available, is that this is intended for very small
sample sizes, very infrequent sampling and reporting. Eg. a thermostat.
But what are the limits, rough, imagined and/or real?
Thanks
Hey Mark, good to see you here.
I believe you're correct that in its current level of development the imp is not suited to real time audio or high data rate applications. I can see a few snags.
The ADC API is not too rich right now. Basically you can grab a sample in the foreground. You could set a timer to sample periodically, but you only get centisecond resolution for that, so no good for audio. You could run a foreground loop but the imp must sleep from time to time otherwise it'll get disconnected from the server. Sleep has a microsecond resolution but anything under 20ms isn't really a sleep in that server operations won't happen, so see above.
Sending the data back to the server is the next issue. You can create virtual connections between imps, which are serviced via the Planner. Actual data transfer happens while the imp is sleeping, so if you have a lot of data to send you need to sleep a lot, which means you can't be doing whatever you need to do to generate that data. The API is quite high level and the comms stack is hidden, so playing this balancing act is rather difficult at high data rates. I suspect they have or will have some flood protection on their server side also, since they'll be servicing in theory millions of imps at a time (let's hope!).
Another problem you touch on is memory. This is an unknown right now, as a couple of major memory optimisations are yet to happen - currently squirrel code is uncompressed and held in RAM. The plan is to compress it and hold it in flash. How much memory is actually free right now is anyone's guess but the total internal RAM is, I believe, 192KB and the OS working space, squirrel run time and your code must fit inside that. I would think it's fairly tight right now for any kind of audio application.
Sorry that's all a bit vague. If there was a compelling reason to process audio with an imp I'd bet they could make it happen by pushing a lot of the work into the firmware. Their (sensible) approach seems to be to provide a light API and augment it when a real need is identified.
I would add, when you say "very small, very infrequent" it's a matter of perception. The thing copes very nicely with the kind of real time events that happen several times, maybe dozens of times a second. That's with very impressive latency considering they haven't brought their European cloud online yet so I'm hopping the Atlantic twice for a round trip. It can be much more than a thermostat, but it's not going to be a video phone any time soon.
Regards
Rob
Fen Consultants, UK
One of the features on the roadmap is for the squirrel code to be able to set up pipes that are automatically serviced by the imp OS layer - this will be how audio sampling will work, and also how you can use the imp as a fairly transparent UART bridge.
Buffering will be minimal, but you will definitely be able to get 8kHz audio over this, and one of the reference designs we’re working on is for a walkie-talkie type application - or “super doorbell” 
Yes, the current API is designed for low data-rate, sensors/sampling types of application. But as always, the future API will depend a lot on what demand there is for using imps in various types of applications.
Answering the question more generally, the limits on a lot of the available interfaces (GPIO sink and source currents, SPI speeds, etc.) are those of the CPU we use: the STMicro STM32, specifically the STM32F205. The datasheet (PDF) is very comprehensive. The STM32 itself is certainly capable of real-time audio, though the ADC is max 12-bit, so you’re not going to get CD quality.
Peter
I’ve been reading over the documentation, and one thing that I was really hoping to see was the capability of connecting to other devices on the local network. Example: you have a DirecTV satellite receiver and you want to tune the receiver to a specific channel; this can be done by opening a connection on port 80 and sending an HTTP GET command.
At the moment, it appears that the imp cannot create a new socket connection to local devices. The capability to connect to a remote server is obviously there, so I’d assume opening up that class to the API wouldn’t be difficult. Has this been considered and will this feature be implemented in the future?
No, this is not something that will be implemented. The imp talks only to the imp service for many reasons, including security, resource use, and ease of configuration.
However, the service can pass data to and from other non-imp services/devices with HTTP.
That’s a major disappointment.
Thanks for the reply.
The critical difference is that the imp is a service that has a hardware aspect - we believe it really improves the process of making connected devices. You get lots of great things including lack of firewall configuration, plug and play operation, seamless software updates for devices, web programmability, easy smartphone control, etc.
What the imp isn’t is a plain wifi module; those have been available for years with full programmability … but they don’t address the core connectivity issues and really don’t make building connected devices any easier.
Hugo - while I’m disappointed, I completely understand.
What about other devices connecting to the imp / imp service? For instance, an advanced home automation system such as AMX or Crestron wanting to control an imp powered water heater or imp powered sprinkler system?
Absolutely no problem with anything talking, bidirectionally, to the service. They just need the API key.
The restriction of the imp connecting only to the service and not random other devices is not to make a closed system, just to make a more stable, easily evolved platform that works like people expect it should (ie - like magic!).
You have to imagine the imp as having a server attached invisibly. Think Marvin the paranoid android with a brain the size of a planet, conveniently located in hyperspace (though, I hope imps don’t have pains in their diodes).
Another interface limit question (probably fit’s in here):
Does the GPIO software handling permits callback on a change (1->0 or 0->1) with at least 1msec resolution.
We want to control output (another GPIO pin) depending from an input which changes with 1msec but we don’t want to sample the input GPIO, we would rather want to get interrupt/callback when this change happened.
The GPIO peripheral can fire a callback on both rising and falling edges, yes. The latency has been measured at about 600us, so your 1ms should be do-able.
At one point we were talking about a “pin-triggered pulse generator”, which would be set up by Squirrel code, but the actual implementation would be in the C++ firmware, or even the STM32 hardware. That would demolish the latency (maybe to ~100ns), but as with all of these things, it takes up its place in the “to-be-implemented” queue depending on how many people are actually going to need it.
Peter
@jwjames83 - This, or something similar, would work for your DirecTV application, although it’s a whole extra level of fun you might not be up for.
Rob
Fen Consultants, UK
@robv - I did think of something like that, though not with a Raspberry Pi as I cancelled my order - I didn’t want to wait 2-3 months to get it. While it would work, it seems a bit much and would rather just make the Pi responsible for what I needed, open up a few ports on a router and . . . oh, wait - that’s what I want to avoid. 
I’ll probably wind up using a Netduino Plus just to prototype / demo.
P.S. - I only chose the DirecTV example as that was the easiest thing I could think of without spoiling what I’m planning on doing. 
Hugo said: Absolutely no problem with anything talking, bidirectionally, to the service. They just need the API key.
Okay, one thing I might implement just to get familiar with things, is a wifi (imp) remote control device for my PVR. The imp would manage a keypad (and perhaps an LCD), passing input to the EI servers.
In order for that input to get relayed back to my PVR, I suppose the PVR itself will also have to establish a connection of some kind to the EI servers and either listen or poll for input from the imp. Right? How does one actually go about doing that?
Thanks (and Hi! to Hugo, Peter, Rob, and all of the others here who I have yet to meet in person)
You can use the HTTP API, and poll for input, or have the EI servers connect to you when there's input. The functionality is there, we're working on docs for the wiki with some examples.
Polling is less useful than some kind of push notification.
The “have the EI servers connect to you” has the teensy potential issue of firewalls to get through. I wonder how best so solve that one? It’s probably impractical to have millions of established connections all waiting for data – the servers would run out of TCP ports.
I’ve come up with an even better need for an imp here now, with the same issue: The UPS man was due to deliver a Nexus-7 “some time” today. This means either being tied to remaining indoors for the whole day, or having some way to know about the doorbell while out in the garden.
I figure I’ll wire the imp to the doorbell, and have it notify me by smartphone (exact method TBD) somehow when the bell rings. Ideally this would be over local wifi, but that’s not permitted with imp. So it has to relay to California and then somehow back again. SMS is probably too slow, so some kind of more live internet connection is likely needed. Mmm…
Solve this class of problems and the potential user base explodes in size!
Cheers
We’re architected to keep millions of connections open to every imp; this is not as hard as it used to be.
SMS was in our previous server setup, and will be coming back. Push notifications to the phone apps are also in the plan, which would solve your particular issue here
This means either being tied to remaining indoors for the whole day, or having some way to know about the doorbell while out in the garden.
At the pub last night Peter’s brother wondered what practical uses there were for the imp. One I suggested was having the doorbell send you an sms so you didn’t miss an important delivery. He thought that was pretty silly, preferring to stick a post-it on the door. I’m glad I’m not totally out of touch with reality 
Rob
Fen Consultants. UK
Of course it’s probably simpler to just hard wire a doorbell extension out in the garden.
But then SWMBO wouldn’t hear it because of the earphones on her mp3 player.
Substitute smartphone for mp3 player… problem solved!