MicIO – HTML5 to MicroController Communication through a headphone jack | Hacker News Reader

MicIO – HTML5 to MicroController Communication through a headphone jack

colinbookman.com

194 pointscobookman33 comments

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.

http://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signa...

The history of the modem [1] is also probably a relevant read. That's basically what the author has recreated.

[1] http://en.wikipedia.org/wiki/Modem

Nice!

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

I've used BLE in the past.

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.

Surely if it's a protocol, there exists the possibility to provide an abstraction over all the different native libraries?

This is better IMO:

http://www.rfduino.com/

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!

Technologies go around and around. This is just like storing my Sinclair Spectrum programs on a cassette recorder.

Good stuff!

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.

That's also how the Bloomberg Terminal connects with the B-Unit authentication device ("Bloomberg Screen Sync")

http://www.bloomberg.com/professional/files/2012/10/b-unit_2...

Electric Imp's BlinkUp tech [1] just flashes the whole screen. It's used for sending WiFi settings to the Lockitron.

[1] - http://electricimp.com/docs/gettingstarted/1-blinkup/

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.

I also created project like this in my school days http://blog.sodhanalibrary.com/2013/09/clocker.html#.UzEjx9L...

This can be an interesting side channel for browser-device communication before we have proper USB access in browsers.

I'm sure it can be fully duplexed using the "mic jack"

Also epic use of WebAudio. :)

I don't often say this, but.. this is genius. Congrats!

That said, is there no such thing as a Lightning-to-USB converter cable? You'd expect such devices to exist.

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).

The closest we have to this right now is the Lightning to USB Camera Adapter, which has a fair number of limitations, but I see no reason that a more general device couldn't be made: http://www.imore.com/playing-around-apple-lightning-usb-came...

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 think the 4-pole plug diagram is wrong? It seems to label the insulating rings, rather than the plug terminals.

So does this mean we're going to have QAM-X or QPSK codecs written in JavaScript soon?

One day i will retake all this and start all my childhood dream projectd

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.

Very few smartphones offer USB Host support other than mass storage. And when they do, device support is fraught. It is a truth.

+1 for using the mbed, my new favorite micro controller!

Nice

Btw this is generally how cheaper rc controllers talks to simulators.

Nice project, but the wire routing in the schematic makes my eyes bleed.

"IE will not work under any circumstances as it currently does not support...(fill in the blank)"

This is a given when it comes to any current technology and need not be mentioned as it is well known.

Reply on news.ycombinator.com