Based on my own experiments and those of Aram and another friend, it looks like the speed limit on this blinking screen block to photo detector idea is about 200 bits per second. That is using an I2C type system were there are 3 transitions per bit over two block-sensor "wires". 

Speed demon it aint. 

But... there are several ways to work around this:

1. Parallel: Use multiple channels. There is a lot of room on a screen and photo sensors are tiny. With good alignment, it would be easy to run 8 data blocks and one clock over the bottom edge of a phone screen and so xfer byte at a time or 1600 bps. Still not fast, but, not horrible. 

2. Analog: e.g. shades of gray. Probably more than 50 even. We see this in the super simple robot linked in prior log entries. This is probably what I'll use for my robot design for left and right wheel control, combined with a digital link to control reverse and other devices like a laser line or gripper. So that is just 4 blocks-sensors and should provide very responsive control of the robot. 

I've never had any illusions that this thing would be fast. I did expect it would be faster than 200 bps, but even with that slow speed, given parallel and analog expansion, and the relatively slow speed of motors and physical devices, for the application of driving a robot, it's perfectly usable. The speeds of data processing and control between the phone sensors and code running on the phone are unaffected. And the data link is still there and is wide and fast.