Show HN: Program Microcontrollers from Your Headphone jack | Hacker News Reader

Show HN: Program Microcontrollers from Your Headphone jack

forum.espruino.com

107 pointsgfwilliams19 comments

This reminds me of the days of transferring data using the 2.5mm jack on the TI-83.

I didn't realise how common it was to multi-purpose these jacks until recently.

Nexus 4 and 5 have their UART via the headphone jack - you need a TRRS headphone cable with the correct resistor wired up to one of the pins.

Kenwood even came up with a standard for it: http://www.miklor.com/COM/UV_Technical.php#progcable

A popular series of VHF/UHF

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.

There are two troubling lines in his code (from https://github.com/espruino/EspruinoOrion/blob/gh-pages/seri...)

  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.

I always assumed, based on my tiny amount of knowledge of the Square credit card reader, that this was possible on iOS?

https://squareup.com/reader

I think it's using the analog audio hardware, similarly to this project.

"the other tablet maker's choice"

I assume you mean android and not microsoft phone or something.

I use these for BT with android and an arduino mini. And some other devices.

http://www.adafruit.com/product/1588

aka the famous $20 Bluefruit EZ-Link

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.

USB OTG, which I gather is becoming quite common on Android devices, should allow for USB-to-serial adapters with relatively trivial effort.

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

Whatever the device or manufacturer, why compromise the design to include something which almost no one will ever care about, much less use?

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.

Direct link to their new Kickstarter campaign for the Espruino Pico: https://www.kickstarter.com/projects/gfw/espruino-pico-javas... (4 days left)

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.

Thanks! I'd seen your post when I googled to see if it could be done. It's just nice not to have to wire up so many components, or to need a battery!

Is it Hayes compatible? ;)

Just remembered I've had an Espruino controller in my drawer for like...a year. Whoops.

wow this brings a new set of possibilities to the table!

http://www.slideshare.net/Sudar/transfering-data-using-audio...

New? http://en.wikipedia.org/wiki/Compact_Cassette#Data_recording

Reply on news.ycombinator.com