I am very new to The Electric Imp and cannot answer my own questions…can you help please. I want to use the Imp to stream H.264 / MPEG4 compressed 1080p video+audio from an Imp enabled portable camera (my design), over the internet, to a remote location to view. The compression etc is all done in a DSP SoC and the Imp just has to implement the WiFi connection. Two questions:
Assuming good 802.11n signal quality and good internet backhaul bandwidth, is the Imp system up to this task ?
One potential customer insists that the data cannot pass through a cloud server for security reasons…hence, once I have deployed the devices and loaded the firmware, is the “Cloud” still in the path of the data-stream ?
In my opinion, you have the wrong WiFi device for your project. You said that you already designed the imp enabled camera? I think we would all be interested in seeing that. Are there not already WiFi enabled cameras available?
Thankyou mlsein, I am designing the camera now - there is no off-the-shelf unit will do the job, this is a camera and portable DVR designed to very specific customer requirements and hence is a “custom job”. The design is not yet finished, but it is now time to select a Wifi component candidate. Is that clearer now ?
The imp isn’t suitable for this; it has only 128kB of ram in total, which limits the streaming speed (buffer-latency product).
Very few wifi modules will give you the type of performance you need there, for much the same reasons (they usually have embedded TCP stacks and limited ram). I suggest trying something like a raspberry pi with a USB wifi adaptor? That way you have plenty of ram and a big CPU… assuming you can get the image data into it.
Thanks Hugo, in any case I am having great fun with the Imp…its a very innovative concept and I am enjoying connecting things so easily. The Wifi module would actually be interfaced as an external peripheral to a TI DM368 which is a very powerful DSP with an integrated ARM926 so we are not short of horsepower (in fact its capabilities would be similar to a Raspberry Pi which used a similar Broadcom SoC) with loads of external DDR2. So not withstanding the “Cloud in the Loop” problem, do you think that it matters that the Imp only has 128kB?
Every network connections speed is limited by buffersize * pingtime. This is due to the fact that the sender must keep a copy of the data until its ACK’ed by the receiver.
If you could use the full 128k as transmit buffer, and have a pingtime of lets say 100ms, your max throughput is going to be 1000ms/100ms = 10 * 128k = 1280kbyte/sec
If you’re in australia, the pingtime to the cloud servers is gonna be closer to the 500 - 750ms range, meaning 1000/500 = 2 * 128k = 256kbyte/sec to 1000/750-1.333 * 128k = 171kbyte/sec
Is there any way to get the imp to use a UDP style packet protocol, that does not require acknowledgement? That means it would just post packets up to the server using UDP and not wait for any response.
The packets could be given forward error correction using something like a fountain code (proprietary I think), or Reed-Solmon (I wrote a free-software one at http://rscode.sourceforge.net/)
This might be useful for people who really want to stream as much data as they can, and don’t mind dropping it if it is delayed by more than a few moments.
An example would be if you wanted to have a microphone on your device to do some remote monitoring. Or had a telemetry data stream of realtime data from some sensors that would overrun the HTTP style of data message.
I understand that the electric imp servers would not like to have to proxy this kind of higher data rate, so maybe there could be an option to just send a UDP packet directly from the imp. It couldn’t be that difficult to add to the network stack I bet.
However, these are largely incidental because your code runs in a VM. More useful is the 60kB+ of free RAM and 128kB of bytecode storage available to the VM.
