I needed a way to transfer data to AVR
This blog post is about my adventures in implementing a stupidly simple way of transferring data over audio to AVR (and why not other embedded chips too), reaching speeds up to 12kbps with really tiny code and memory footprint, using the internal oscillator of Tiny AVR, with hardware parts that cost next to nothing.
How it started
Once I got an idea of a wearable message badge made out from Tiny 8-pin AVR chip and an LCD-screen (you can buy one NOW: TagsuTag@IndieGoGo), I wanted to make it really easy to update the contents of it, from any device you usually carry with you (not just your laptop/desktop-computer).
Some constraints of course are set up by the Flash size (8192 bytes) and the RAM size (512 bytes) of the Attiny85 chip.
I spent hours pondering about different transfer methods USB, UART, Bluetooth and so on, but all of those had downsides:
- USB: Needs 2 pins, Firmware takes 1/4th of the Flash space.
- UART: Modern computers lack serial port and you have to have an USB adapter.
- Bluetooth: All that pairing, price and code size… argh!
- WiFi: Too expensive and complicated for a small device like this.
And on top of that, USB and UART are either simply missing or at least very hard to get to your phone or tablet.
I even made some tests in the spirit of those Timex watches and screen blinking, but that was painfully slow.
I then spent few minutes to think what kind of common output devices exist in cell phones, tablets, laptops and desktops and soon realized they all can play audio! Good old memories with Commodore 64 and Datassette came flowing back. I needed to try that.
Ok, simple, just code the modem!
After heavy Googling I found out there exists plenty of different audio modulations for data-transfer purposes, it was hard to choose one. For Arduino there was ready-made FSK-audio transfer implementation, which I also tried – unfortunately it proved to be both unreliable, slow and quite a code bloat. I wanted something really simple, because my goal was to transfer data using cable from headphone-connector, not over the air. As the world wasn’t ready yet, I had to do something about it!
I also wanted something that doesn’t suffer from the usage of internal (not so accurate) oscillator instead of external, as I wanted to save pins. So I spent days and days fiddling with different modulations, polled pins at different intervals, used timers for frequency detection and even got some slow data transferred to Attiny85, but the speed and reliability still left a lot of space for improvement. I tried adding Manchester encoding but it still wasn’t good enough. Simple solutions are usually the best and my solution wasn’t simple enough, it seemed.
Surfing through Wikipedia I even stumbled accross the article about Morse code and that actually gave me an idea, why even play with detecting frequencies when you can just detect pulse length! I just needed way to efficiently clock the signal and tell short pulse apart from long one. A Simple way.
I also got my first oscilloscope at this point, which was tremendous help at looking inside the signal.
I decided to try something really simple, the transfer should begin with a “sync pulse” that’s long enough to tell apart from zeroes and ones, and which can also be used to calculate the “midpoint” between zero and one length. I made the sync pulse to be 4 times the length of the midpoint, so I could easily calculate the midpoint by using bit shift.
Using the Timer running at 125kHz to measure pulse length and INT0 on rising edge of the signal I actually got the data transfer working, with really simple hardware and good reliability. I generated the audio signal manually from python script, 16kHz 8bit mono audio, making the pulse go from 0x00 to 0xFF straight away and then dropping slowly. The results were promising and the speed was already around average of 2kbps, which was my original goal.
For more detail: 12kbps simple audio data transfer for AVR