The author should look into DTMF, they were quite popular in packet radio and you got a 1200 baud datarate. Haar Wavelet transform would probably be a lot less CPU-hungry than FFT.
BTW, with the new Bluetooth Low Energy protocol, you don't need a $100K license to interface with iOS devices anymore: http://www.mkroll.mobi/?page_id=386
While its fairly nice, android support is all over the place. Each manufacturer has their own library. Then you need to factor in all that time spent hooking into the various native code libraries.
With something like micIO all you'd need is a 4 pole minijack and an HTML5 browser. Aka all smartphones minus windows phone (http://caniuse.com/audio-api).
For low bandwidth applications this can be pretty useful. Think about all those wearable electronics.
Obviously work still needs to be done to get micIO to a stable state.
Android has a standardised API for BLE as of 4.3, so you can target that instead of HTC and Samsung's proprietary APIs. But that only covers 12% of Android devices, which is really pretty awful given iOS basically has support across the board since 2011.
Despite their claims it is not really open source, but you can buy the official dev kit for $100 and it gives you access to the SDK, Soft devices and an SWD programmer (SWD is like JTAG but for ARM).
Great hardware though. The only alternative I've seen is the TI chips and they require the purchase of a $3k compiler!
Stereotypically those were FDM so you'd send precisely two cycles of 1200 Hz or one cycle of 600 Hz and then a simple zero crossing detector would sync up and read the bits out.
I figured thats where he was going and was kind of surprised to see the multi-tone setup.
The more advanced ham radio guys are experts at using vaguely communications width bandwidths at often very lot signal to noise ratios to send as much error corrected data as possible.
20 years ago you'd demo something like PSK-31 using two COTS laptops just singing out the speakers and it would work pretty well. Newer modulation schemes are obviously faster / lower SNR / better error recovery / better PAR (peak average ratio) etc. A smart telecom engineer can run right up against the Shannon limit and flexibly trade off against limitations, either SNR or audio bandwidth or transfer speed or synch / preramble time...
This is interesting. Another clever way of doing this that I just saw this morning is being done by the BlinkyGrid. It uses two flashing areas on the PC/smartphone screen to send optical Clock & Data signals to two photosensors on the microcontroller board to configure it.
I really like this since it's trivial to implement and adds less than $1 to the BOM cost of the hardware even in single units. There are quite a few devices I've wanted to build that only need a very simple UI to configure them and this would be perfect.
And for a plus, it's Open Source Hardware so you can use it without guilt.
I do worry that the frequency of their flashing may be in the zone to trigger seizures in those that are susceptible, though, but this is an easy problem to work around. Maybe using a single NRZ signal like 110 bps serial transmission.
Cool project; I'm working on something similar. But I'm using BFSK, which means two frequencies instead of 16.
You don't really need an FFT (expensive) to decode these 16 frequencies. Instead, you can shape them into square waves with a software Schmitt trigger, then measure time between transitions. When n successive transitions indicate the same frequency, you emit the corresponding nibble.
The more frequencies you use in your encoding, the longer it takes to discriminate in the receiver. I think this is why real-world FSK systems are usually BFSK.
For I client I designed a UART<->Microphone adapter. It supports bidirectional communication at ~1kbps, almost 0% error rate at full volume (~15% error rate at half) and has a terribly unoptimized analog interface. I didn't really think there was much interest in creating these kinds of interfaces, but if anyone has any good ideas I am all ears.
I wonder if this could have gotten the Peachy Printer out the door sooner? If memory serves they had to spend several cycles working out noise and levels issues with the soundcard-to-microcontroller interface. Although, it isn't clear that MicIO has worked through those issues already, and Peachy is perhaps a naturally analog project.
My understanding from a few conversations with the peachy guys is that they started out with a really simple idea of what it was going to do, but in the process of getting it production ready they kept discovering problems that needed yet-another-hack to work around. It sounds like a lot of clever engineering has gone into it, but I personally probably would do USB and digital processing instead of analog (you can get crazy powerful USB-capable micros for pretty cheap, e.g. mchck.org)
I get what you're saying. However, one advantage of leaving the digital-audio conversion in the sound card is that modifications to this process are just a new software install on the host, rather than a new firmware install on the device. That presumes they eventually get the device in a "good enough" state, however.
Very nice idea. Of course one can think of more sophisticated modem signal protocols, but keeping it simple is potentially beneficial for those folks (including me) who might want to implement the slave using a low-end microcontroller. Something that could use the UART built into most MCU chips would be a nice thing.
From the article, it seems that the problem is on the iOS side, not the PC side. Having a converter doesn't change the protocol you have to speak on the device itself.
Perhaps I didn't make my point clear, but what I meant by a converter cable involved converting Lightning signals to USB signals within the cable itself (i.e. there's a microprocessor within the cable that converts the signals from one form to another).
Your point is fine. But the limitations on the iOS side are more significant than you seem to realise. things that I'm aware of that apps can take advantage of:
* midi signals
* plain audio signals
* looking like a usb flash drive to the built in photos app
That's the whole list. The only one that seems vaguely useable for something like raw IO is midi signals!
I find the author's claim that most smartphones lack USB interfaces quite surprising. You'd think, since USB devices are incredibly common, smartphone manufacturers would include at least one USB port.
http://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signa...