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

Oscilloscope-image showing first implementation pulses. E-cursor being near the pin trigger point.

Even better and simpler idea for modulation

Then something made me try to make it even more simple, how about only using samples 0x00 and 0xFF in 8bit audio, effectively making it square wave with “clock” pulse for every bit! I also switched from INT0 to Pin Change Interrupt (PCINT) to measure both rising and falling edges of the signal. I shortened the pulses and got nice results until I got into sample lengths of 3, 5 and 16 samples – being zero, one and sync pulse respectively. I also decided to use both rising and falling edge to clock between bits, effectively detecting zero crossings. That averaged at around 4kbps and the code was now stupidly simple.

Boy, was I amazed when I just started to try with different sample rates, but same sample lengths, I got up until 44.1kHz and the data speeds just kept on growing, and the transfer still being reliable – and the code “auto adapted” to higher speeds automatically, as the sync pulses got shorter! Modifying the Interrupt Vector to output received data from other pin, I soon realised the obvious, ISR has short delay before it’s getting called, so the sample lengths aren’t exactly accurate and I finally ended up with sample lengths of 3, 5 and 17, and now I could use 48kHz sample rate with the transfer speeds averaging 12kbps and still with good reliability!

Audio excerpt, showing the single bits and sync pulse when sending data.

Also the sync pulses can be sent as often as you would like, if for some reason the transfer loses a bit, the rest of the data is out of sync. I tried transfer with several megabytes of data and sending 2 sync pulses after 16 bytes of data and not a single transfer error. The transfer should always begin with at least 2 sync pulses, as the timer is “running free” without data and the first sync pulse length might not be correct.

And the hardware part? Also stupidly simple.

It’s just a very basic biasing-circuit, the audio-signal is biased close to AVR pin trigger point (around 50% of VCC), with PCINT that basically acts as a Zero Crossing Detector. You don’t want to bias it exactly to 50% as there will always be some fluctuations in the signal and the AVR pin will be in “undetermined” state, consuming extra power, hence I decided to bias it to around 45% of VCC which seems to work fine. C2 is just added for some filtering, I noticed for example that some cell phones leak current to headphone connector while connected to charger, so this filters noise out.

Of course you could use analog comparator or Op-Amp to make a real Zero Crossing Detector, or even use AVR built-in analog comparator, if you wish.

The downside of the simple schematics is that with low volumes you get a lot of transfer errors, as sound cards generally can’t output square wave as such.

In Tagsu I wanted to get as little transfer problems as possible, so I added “standard” audio clipping circuit using 2 very basic signal diodes (1N4148) and series resistor to prevent “direct short” to ground.

This limits the voltage swing to around +-0.75 volts, making the signal look more like square wave, and it also prevents negative voltage to AVR pins when playing with high volume, which AVR chips don’t like that much. The circuit used in Tagsu requires high volume for the modem to work at all, but I find it generally nicer to inform people to “put volume to maximum” and have reliable transfer.

Shut up and take my money… and give me teh codes!

The code referred in this post can be found from GitHub.

The Following License applies to all code:

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this program. If not, see <http://www.gnu.org/licenses/>

If you would like to get commercial license instead of LGPL, please contact us.

The code example contains the modem code itself and also really really simple bitbanging SPI implementation, the main code just runs in loop and forwards any bytes received via modem to SPI as-is.

Code walkthrough

Okay, going through the code might explain the internals of the modem better. I will not go through the SPI-code in the repo, it’s just an example to get data out.

Let’s start with modem header modem.h:

7
#pragma once
8

9
#include <avr/interrupt.h>
10
#include
11

12
/* Modem ring buffer size must be power of 2 */
13
#define MODEM_BUFFER_SIZE 4
14

15
/* Modem defines */
16
#define MODEM_SYNC_LEN 42
17
#define MODEM_TIMER TCNT1
18
#define MODEM_PIN PCINT3
19
#define MODEM_DDR DDRB
20

21
/* Public funtions */
22
uint8_t modem_buffer_available();
23
uint8_t modem_buffer_get();
24
void modem_init();

Nothing fancy here, we set the size of the modem ring buffer, size should be power of 2 (2, 4, 8, 16…).

MODEM_SYNC_LEN is the sync-pulse minimum length, anything longer than this will get interpreted as sync pulse. We’ll get back to why this is 42 in a moment.

MODEM_PIN is now PCINT3 in the example, but it can be any pin that has Pin Change Interrupt -possibility (Attiny85 has them in all IO-pins, but other AVR chips might not).

Next let’s look at the code itself, modem.c:

Let’s start from bottom up, first the modem_init() -function:

Yksinkertainen 12kbps audiomodeemi AVR:lle