Older(?) Canon(?) DSLRs also used a 2.5mm jack to control the shutter release, so some people realized if you just spammed data into it from the TI-83 you could trigger it. Add a crude BASIC script and you have an extremely basic timelapse setup.
var header = sampleRate; // 1 sec to charge/discharge the cap
var bufferSize = samplesPerByte*data.length/*samples*/ + header*2;
This implies 2 seconds of overhead per message sent from smartphone to microcontroller, 1 for the light to turn and 1 second of clearing time before the next transmission. This explains why the lights toggle so slowly.
To top it off, he uses 2 stop bits. The signalling rate may be 9600 baud but do not expect to be transmitting 9600 DATA bits a second! I think such claims need to be backed up with a demonstration full loopback capability without either side dropping a byte, with no pauses between serial bits.
There is a demonstration there of full loopback, without the 1 sec delay. The delay is purely so you can send a command using a totally normal audio API that only uses the sound card when needed.
I could probably get away with 1 stop bit... I didn't try. To be honest if the transfer speed matters so much, it might be better to use some other means of communications :)
This is neat, of course. And it also goes back to old Commodore 64 (and before) days of using audio for data in/out, including mass storage on audio tape.
I've always been bothered by Apple and the other tablet maker's choice not to include an openly usable simple serial port on their devices (or the ability to use a USB<->serial adapter). I understand the Apple "control everything" mentality. Their sandbox, their rules. Still, I can only imagine how neat it would be if all of these devices had a simple two wire serial port available without limitations. As a result of this we have to go backwards in technology by some 30+ years for simple little projects.
On the android side I use an app called blueterm once I connect. Its pretty boring, it just does its thing. I would imagine writing an app on the android side that does something useful and gets it on the tablet would be quite a challenge. So the BT link itself is not really the limiting factor.
Ironically in an article about programming devices, there is some weird funkiness with linux and various desktop environments and OSes such that its non trivial to wirelessly reprogram arduinos, something about toggling the DTR at the right speed and time, although the RX/TX work just fine.
I have no extensively experimented with range.
Looking at "radio shack type price markups" I think a DB-9 and hood and some cable would be a significant fraction of $20, its not like we're comparing a 5 cent solution to $20, more like $7 wired vs $20 bluetooth. On the other hand it bothers me a little to connect a $20 BT dongle to a $15 mini.
Yes, it'd be really handy... Having said that, to be truly useful you'd need to be able to access whatever it was from some API that was common across platforms. Sadly I think it's very unlikely that any simple communications protocol will get exposed to webpages, because of potential security concerns.
This remind me of the days of debugging an 8bit micro with only one spare IO left. I had to write a big-banged UART with a half-duplex serial protocol over it. Thank goodness that I was debugging anything approaching real time.
http://robots-everywhere.com/re_wiki/index.php?n=Main.AudioS... If anyone wants the android serial output app (I did this in 2010, one way only though, fwiw) it's here. Their circuit is simpler, though - this was designed to work with a Parallax Prop or an Arduino. However, my app will work with this.
