Realtime serial communication...is it possible?

Hello electric imp community!

At the moment I would really appreciate your experience and insights whether the following is doable with Electric imp:

I’m working on the topic of “remote presence” (link and photos here: dasein-tokyo.tumblr.com) and have so far built a set of tangible objects that talk to each other via Bluetooth.

In a nutshell, analog-in (pressure or heartbeat) in one location causes an effect in another (ex. sculpture-leds gradually light up). I have used different Arduinos (Uno, Fio and Lilypad), programmed with Arduino IDE and connected to each other with Xbee-modules (of Series 1).

Locally communicating objects – check! But I have almost lost hope with upgrading from Bluetooth to Wi-fi (which would allow the actual use in real life…)

The problem seems to be the speed in which the analog input can be sent; most wifi-solutions (that I’ve found) allow only periodic measurements instead of real-time analog serial. (With xbees the baudrate was as high as 115200, which maybe be not necessary…)

Do you know if this kind of object-to-object serial communication is even possible with wi-fi (for a beginner like me)?

All ideas and suggestions welcome :slight_smile:

Emilia

There are systems out there that appear to offer high analog data rate over wifi with low latency, such as the Sonos home audio system which uses wifi but manages synchronised in-phase stereo signals over separate wifi links. All through the local router of course, not going on to the internet.

You do not ask about the electric imp, but it will not communicate to any other local device, everything must go to the cloud servers then back to the other device. I find this gives a latency of about half a second where I am in the UK, it may well be shorter on the west coat of the USA.

From the description in your blog, it sounds like you’re interested in WiFi + Internet communication (as opposed to WiFi + local communication)… Latency is always going to be tricky, and largely dependent on the networks on either end.

It may be worth thinking about alternative approaches to this project. Since “true” real time isn’t ever going to be possible (you’ll always have some latency because of transmission) - you might be able to do neat things if instead of trying to send data in realtime, you send it in chunks large enough to account for the latency…

So if you wanted the ambient light side to react at 60 FPS (which should be more than enough for people to not notice it ‘flicker’) - instead of sending 60 requests per second, you could send 1 request with 60 readings every second.

The light side will always be a second or two behind the heartbeat, but this is likely to happen regardless because of latency - and this way you can manage it a bit better (especially if you do some clever things like send a window of 2 seconds of data every second)…

…and if you’re not in the same location, you’d not notice the second or so delay…