The Second Generation of IOIO is in the Works

It's been a little over a year since IOIO has been released. During this period it has been used by thousands of users world-wide, who published tens of amazing projects. IOIO has become the first and leading product for interfacing Android with external hardware. Several software / firmware upgrades have been successfully rolled out, which added new features and fixed bugs. Two different manufacturers (SparkFun, Jaycon Systems) currently make IOIOs and an alternative form factor boards from SeeedStudio are just starting to sell. A book has been published on making Android accessories with IOIO. I've given a few workshops on IOIO, one of which at the MIT Media Lab, which has always been a dream place for me. Quite a trip! I was expecting something much more modest when I started, but happily jumped on the train.

Why a New Version?

During the whole time, I've been constantly gathering user feedback and looking at other products in the same field and have kept asking myself "what is the most important thing to do next?". Eventually, two main points started to emerge, that could not be addressed by software alone:

1. I find that the paradigm of controlling I/O pins remotely (i.e. from an off-board processor) using a high-level Java API works really well. It has proven really great when you can seamlessly move your connection from wired to wireless or when you can easily integrate the capabilities of the host (Android) with the capabilities that IOIO adds. It has proven great when users with Java-only background could now easily be able to communicate with hardware, without needing to write any embedded code and without needing to develop a communication protocol themselves. I believe this paradigm can be just as useful for the PC world. Currently, the standard way to control I/O from a PC is to use an Arduino or a similar board, and having to write two separate programs which communicate with each other. The bandwidth in this case would be typically limited to 115Kb/s, which is far less than what USB is capable of.
2. IOIO is too expensive. Not for business reasons, because there's hardly any competition, and making it cheaper might actually decrease net revenue. But my goal is increasing the number of units sold and the number of happy users. I'd consider this project a success if IOIO became something everybody knows and loves, and considered the standard and obvious solution for enhancing a host computer with I/O capabilities.

It became apparent that there's enough motivation for a second generation. And so I started! SparkFun were as great as always, and have been very supportive on both goals.

So... What's New?

The next generation of IOIO will be a USB on-the-go (OTG) device. What this means in practice, is that the new IOIO will be capable of acting either as a USB host (like the current IOIO) or as a USB device (allowing it to connect to a PC as well as be powered by it). Moreover, it will be able to auto-detect which is the right role, according to whichever cable is connected to it (a micro-A or micro-B).

Making the IOIO an OTG device required some modifications to the power-supply module. While I'm at it, I've managed to design a module that is both cheaper and beefier (2A) than the current one. It will also have a resettable protection fuse and will handle current limiting more elegantly than the current IOIO (which simply has a resistor on the VBUS line).

I considered upgrading the microcontroller, but was happy to find out after searching a little, that the current one (PIC24F) is one of the most peripheral-rich micros out there if not the richest. Since this is the most important aspect of the microcontroller for this application, I decided to leave it alone. Other than that, I've made a few more nice-to-have changes, such as reducing the noise on the analog inputs and reorganizing the power supply pins in a more accessible way (having GND next to each supply).

The Development Process

In order to save time and money, and according to my beloved tradition, I made the first prototype by home-etching. In this case, I took an old IOIO and gave it a heart transplant to replace all that needed replacing. I wish there was an "ugly but works" contest...

Then it's software time! The firmware took some time to develop, but it is now close to completion. The IOIOLib part was the most fun. It ported from Android Java to PC Java totally smoothly. Finally, just in time for Maker Faire, I finished a fully functional demo, in which I'm running HelloIOIO on a PC, and controlling the IOIO LED over USB or Bluetooth!

SparkFun also moved quickly, and provided me with the "pretty but doesn't work" prototype pictured at the top of this post. The "doesn't work" part is probably the fault of my soldering, though :D. But it was working enough for demonstrating the new USB device functionality at Maker Faire.

So we're probably a couple of months away from production and official launch. It is possible that the initial release will ship new hardware, but with software only capable of USB host and I'll release the device mode in Beta first. Not sure yet. We shall see depending on my estimate of the risk at the time of launch.

Thanks!

I'd like to thank all of the users for their trust, support and feedback; to thank SparkFun for being the most awesome partners on the planet and most of all to thank for my family for putting up with my crazy hobbies and excessive work hours.

IOIO Over Bluetooth (or: Who Needs Cables Anyway?)

Pheeeew.... a few long weeks of crunch-mode right about when I moved to California and then to a new house. However, I felt I had to get this done and the Android Open conference in San-Francisco seemed like a good target date. I made it. Barely, but definitely made it.

OK, now that I got it off my chest, I can tell you what it's all about.

The Short Story

With a firmware upgrade on the IOIO, it now supports connecting a standard Bluetooth dongle into its USB jack and is able to establish its connection to the Android phone wirelessly! This actually makes IOIO one of the cheapest, simplest and most powerful Bluetooth-enabled prototyping platforms out there. And some more good news: your application code stays exactly the same. That's the way it should be as far as I'm concerned. End-users should care about what they want to do with their hardware for their project, not about how the heck (or how the hack) to communicate with it. So you only need to write the application-specific code (the source code for the application demonstrated above takes less than 30 lines of Java for the IOIO-related stuff), and it seamlessly works on any kind of connection and can even switch from one to another while running. I don't know of any existing platforms that will let you do that so easily and cheaply. The closest one probably being Amarino. Keep in mind that IOIO is also capable of USB connectivity to Android of course (ADB or OpenAccessory), giving superior reliability latency and bandwidth compared to Bluetooth. You do the comparison.

The Long Story

Although I think there is some real kick-ass little revolution here, this post is going to be more of a story than my usual bunch of technical specs. I'm just in this kind of mood more than the check-out-this-awesome-stuff mood.
Back when I published my original announcement on IOIO, one of the commenters (Inopia, thanks, man!) cleverly noted that since IOIO is a USB host, using a standard Bluetooth dongle in order to make the connection wireless is just a matter of writing the right firmware. He was right! And I immediately fell in love with the idea and with the challenge it presented. I felt that from all the million features I could develop next, this one will be the real killer. Just imagine: a couple of bucks (cheapest dongle I found is $1.80 including shipping from DealExtreme) and you have yourself a whole new range of possibilities: home automation, R/C toys, and much more.

Slowly I began to realize some really cool side-effects that this will have. First, the current inability (or more precisely, complexity) to use IOIO and debug your Android at the same time would go away. Second, we're no longer limited to an Android - control IOIO from any Bluetooth-enabled device: IOIOLib is just a bunch of Java code that can easily be ported to other platforms (or rewritten if need be). Third, we're no longer limited to just one IOIO controlled by a single host application.

You get the point. I just had to do it. One problem: I don't know Jack about Bluetooth. Only know enough to know that it's definitely doable. That's where the second key actor in this story comes in. I'm digging the Web for open-source Bluetooth stack implementations. Pretty soon I come across btstack, developed by Matthias Ringwald. I also found other options, and at that point, I was not completely sure which one to choose. So I contact Matthias and I start checking out the code of several projects, and throw some of them away for lack of maintenance and others for having Spaghetti code. But btstack turns out to be just perfect. Easy to port, very clean code, doesn't use the memory heap (embedded heaven), active maintenance and great discussion and support forum. Matthias really got it right (at least my idea of getting this sort of things right). Two nights later (mostly struggling with implementing the USB driver for the dongle), and I'm able to open an end-to-end connection from my phone to the IOIO. Then a few weeks of finding these tiny, cruel bugs and getting everything nicely packaged and documented, etc.

And as I said, not a moment too soon! I got to Android Open two days after having a working demo. There I met Aaron Weiss from SparkFun face-to-face for the first time. Aaron is the engineer from SparkFun's side that worked on IOIO from day one. Meeting him and having him stand next to me while presenting was really great!
At the conference, I attended a keynote by Massimo Banzi, one of the two founders of Arduino. I really admire his work, especially after having taught a course on Arduino that enabled non-techie designers build the most awesome stuff. Quite a great keynote he gave, and a little later I've had the honor of presenting myself and inviting him to see my demo. And he came, and was so kind and positive and that really meant a lot to me.

Next exciting event was an interview by Make magazine folks. Needless to say I admire their work too. I think they honestly liked my Bluetooth demo and agreed that this is a little breakthrough in the field.

The moment I came home after the conference I fell ill for a few days. Totally exhausted. Haven't had a decent sleep in a few weeks. I took a few days off, and then back to work: a demo is nice, but I gotta get this thing released. Fortunately, when preparing the demo I wasn't playing quick 'n' dirty. So I just needed some polish, but no throw-away code. And finally, I'm happy with it and feel confident enough releasing it. It's not perfect-perfect, as multi-device support still needs some care. But it's reliable and definitely useful as-is. I made a video explaining users how to upgrade their IOIO to the new feature, building on top of the firmware upgrade capabilities that I previously enabled. Some have already reported success.

Links

More information (and the instructional video) can be found here.

IOIO can be purchased from SparkFun (about $50) here.

The cheapest ($1.80 incl. shipping) Bluetooth dongle I found and tested is here.
Questions are happily answered on the ioio-users discussion group.

What's next?

There are several possible directions I'm considering (your comments welcome):

• Supporting the multi-IOIO use-case properly.
• Supporting WiFi dongle (imagine that!).
• Releasing OpenAccessory support in non-Beta mode (now the ground is properly laid, with new bootloader and connection abstraction layers).
• Adding long overdue features that users requested such as infrared remote control protocol, synchronous parallel I/O, quadrature encoder, PPM output, etc.

Tough choice. All seem to add great value. We shall see...

IOIO over OpenAccessory (ADK) Available

About two months ago, I've announced IOIO on this blog. About a month later, in Google I/O, Google announced the OpenAccessory and the Accessory Developer's Kit (ADK), which enables connecting your Android device (version 2.3.4 and higher) to external peripherals. Today, I'm announcing IOIO's support of the OpenAccessory protocol!

This new feature is currently released in Beta mode. Technical information available on the IOIO wiki. The way this works is that IOIO will attempt to communicate with the Android device with the OpenAccessory protocol. When this is not supported, it will seamlessly fall back to ADB. This enables you to connect the same IOIO board to both new and old devices. Your applications can be very easily be ported to the new mode, requiring only a few non-intrusive modifications to your application's metadata.

What is this all about? What is the relation between this new technology, IOIO and the other boards out there? I will try to provide some answers and clear some of the confusion that was caused as result of the proximity of all these announcements.

What is OpenAccessory?

OpenAccessory is a new Android feature, which enables connecting external peripherals to an Android device over a USB connection. This feature exposes a standardized interface on the USB bus, as well as a Java API that enables an Android application to communicate with the accessory on the other end. This feature is supported on Android 2.3.4 and higher. The OpenAccessory protocol allows the Android device to act as either a host or a device on the USB bus (the host mode is only supported on Android 3.x and higher and only on certain devices).
OpenAccessory is a low-level protocol: it features a single full-duplex communication channel between the Android device and the accessory, over which arbitrary bytes can be sent back and forth - much like a UART connection. It leaves to the accessory designer to design the higher-level protocol, i.e. what messages to send and what their meaning is to the Android application and to the accessory.
Read more about OpenAccessory here.

What is ADK?

The Accessory Developer's Kit (ADK) is a reference implementation of an OpenAccessory-enabled board, developed by Google and announced together with OpenAccessory. This board is essentially an Arduino Mega with an on-board USB host shield. It comes with an Arduino-side C++ library, which implements the protocol. Following Google, several vendors have released compatible boards.

The term "ADK" is often used synonymously with "OpenAccessory", i.e. one might say "this new board supports ADK" when they actually mean it supports the OpenAccessory protocol.

In my personal opinion, the ADK has been released mostly for promoting the OpenAccessory protocol and providing a quick-start and demo board, rather than intended to be a consumer product.

How Does OpenAccessory Compare to ADB?

The Android Debug Bridge (ADB) is a debug protocol which existed on every Android device since the early days of Android. Technically, this protocol allows a host connected over USB to open various kinds of communication channels to the Android device. On the Android-side of these communication channels are different services, such as debug, file-system access, Linux shell access. Another note-worthy service (on which IOIO has been based) allows forwarding of the data sent over the channel to a TCP socket. This allows an Android application to listen on a certain port and accept connections coming from the outside world, and do so without the need to modify the OS.

ADB's main advantages over OpenAccessory are:

• Available on any Android device.
• Provides useful features, such as file-system access (IOIO uses this for firmware upgrades).
• More mature, does not suffer from some problems currently existing in OpenAccessory.
• Simpler to work with on the Android application side - just listen on a TCP socket.

OpenAccessory's main advantages over ADB are:

• Better throughput and latency.
• Does not require the user to enable USB debugging.
• More secure (IOIO takes its own measures to guarantee that the power of ADB cannot be exploited by a malicious firmware).
• Allows applications to be notified upon connection of the accessory. The user can choose which application to launch when the accessory connects. This might be doable with ADB too, but IOIO doesn't do that.

See Inopia's excellent in-depth comparison here.

How Does IOIO Compare to Other OpenAccessory-Enabled Boards?

• Supports All Android Versions - since IOIO works with both OpenAccessory and ADB it can communicate with a very large variety of existing Android devices, leveraging OpenAccessory when it exists and leveraging the additional features of ADB when they exist. Other boards, which do not support ADB, are limited to all but the newest Android devices out there.
• Functionality - IOIO is almost exactly identical to the Arduino Mega in terms of pin counts and functions. The only difference I could spot is in the number of PWM channels (IOIO-9, Mega-16) and TWI channels (IOIO-3, Mega-1).
• Cost - at $50, IOIO currently seems to be the cheapest available commercial board out there. A close alternative is a DIY version offered here, costing $55 and requires some work.
• High-Level Software - the other boards out there expect you to write both an Android application and embedded-C code for the board, designing your own communication protocol. IOIO does all that for you, leaving you to write only the Android-side code, while using a high-level Java API for controlling the board's functions.
• Support Forum and Wiki - IOIO has an active discussion group and an extensive documentation wiki, which continues to grow quickly. The IOIO project is committed to the hobbyist community, and to the hobbyist community only!
• Size - IOIO is probably the smallest board out there - almost as small as you could get with 48 I/O pins, numerous supply pins and a USB connector. It is much smaller than the ADK board.
• Bootloader - IOIO's firmware includes a secure bootloader, which enables firmware upgrades to be performed through the Android device.
• Power Supply - IOIO has an on-board 5V switch-mode regulator capable of delivering up to 1.5A. This allows for simultaneous charging of the Android and powering two standard servos without problem. Some of the other boards will require an external 5V supply to support this use-case. In addition, IOIO has an on-board trimmer which allows limiting the Android's charging current. This is very useful for battery-operated setups, when you don't want the Android device to drain your battery.
• Open-Source - Unlike some of the other alternatives - the IOIO's hardware, firmware and software are completely open-source with a FreeBSD license (very permissive). This approach has been chosen because I believe this is what works best for the hobbyist community, and allows people to customize the product for their needs, contribute to it, understand it best, compete on its pricing.

In conclusion, despite my obvious bias, I believe IOIO is very competitive with other OpenAccessory-enabled platforms. To be fair, here is another view.

IOIO Open-Sourced

The first batch of IOIO's has started shipping these days! I'd like to thank the patience and support of those who bought it in back-order.  I can't wait to see what users are going to make of it.
If you make a cool project with IOIO, please let me know about it in the comments, on email or in the discussion group. If there's enough volume, I'll open a page on this blog dedicated to such projects.

As promised, I'm opening the source-code, under FreeBSD license.
The project's documentation, including a partially complete user guide is here:
https://github.com/ytai/ioio/wiki
I'm now working on filling the missing parts, but there should be enough Javadocs to get those of you who can't wait going. The project's source code is there too, available for download as a tarball or using git.

SparkFun have recently release a beginner's guide to IOIO here:
http://www.sparkfun.com/tutorials/280

I opened a discussion group for IOIO users, where I'll try to answer questions and get feedback. Feel free to subscribe there if you want to know what's going on:
http://groups.google.com/group/ioio-users

If you want to take part in IOIO development, please introduce yourself and submit a request for membership in:
http://groups.google.com/group/ioio-dev

Meet IOIO - I/O for Android

I'm very excited to announce the launch of a new product I've been working on for the past months!
IOIO (pronounced: yo-yo) is a product which lets you connect electronic circuits to an Android device and control them from an Android application.
It is comprised of a small (2.7x1.2" = 7x3cm) PCB that connects to an Android device with a USB cable and a software library (Java .jar file) that you use in your Android app which handles all communications with the board.
No firmware programming is required - only Android application authoring with a very simple API (see examples below) for controlling the pins on the board. No modification of the Android device is required - you avoid the complication of modification and the voiding of warranty.
IOIO is available for purchase online from SparkFun on this page.
The first few boards will ship within a couple of weeks. Around that time, the entire software and hardware are going to be 100% open-source with a permissive license.

Main features:

• 48 total I/O pins - all of which can function as digital inputs and outputs.
• Up to 16 analog inputs (10-bit).
• Up to 9 PWM outputs.
• Up to 4 UART channels.
• Up to 3 SPI channels.
• Up to 3 TWI (I²C-compatible) channels.
• On-board switch-mode regulator providing up to 1.5A of 5V supply. Can charge the Android device as well as power a couple of small motors.
• Bootloader on the board pulls firmware off phone, enabling OTA firmware upgrades and application-specific firmware.
• Pulse-width measurement, capacitance sensing and more (will be pushed with first OTA firmware upgrade).

Example Code

Just to give you a hint of how simple it would be to write apps using IOIO, here is a small snippet from an app, which controls a single servo motor (on pin 12) and reads a single potentiometer (on pin 40). Exception handling and proper closing have been omitted for clarity.

ioio.waitForConnect();
AnalogInput input = ioio.openAnalogInput(40);
PwmOutput pwmOutput = ioio.openPwmOutput(12, 100);  // 100Hz
while (true) {
  float reading = input.read();
  pwmOutput.setPulseWidth(1000 + Math.round(1000 * reading));
  sleep(10);
}

Example Projects

The Retroid

The Retroid is a retro-designed alarm clock hacked to be controlled by an Android phone.

Once connected, the phone's alarm, incoming call and incoming text message notifications appear as different ring and LED patterns on the clock.

Thanks to the amazing The Gifts Project folks for hacking this wonderful project over one weekend!

The Visual Charger

The Visual Charger is another take on a cool docking station for your phone. It charges your phone while presenting charge level percentage (0-9 or "F" for full) on a large 7-segment LED display. It also uses the dot on the display to signal for pending notifications (e.g. missed calls, unread text messages, etc.).
This project has been done by Misha Seltzer who is also taking a crucial part in IOIO development.

Wall Printer

The Wall Printer is inspired by old-school pin printers. It has 7 markers in a row, each individually controlled by a servo such that it can go up (not paint) or down (paint). When you manually slide it over a wall, the servo motions are carefully timed to produce text messages. These can include manually entered text, SMS messages, GPS coordinates and more.
The project is not yet complete, and the video above just demonstrates a simple pattern from an early experiment. I'll post an update once there is progress.
This project has been done by my wonderful friend Liat Segal.

Why?

Android phones are powerful mobile computers having internet connectivity and a rich variety of built-in sensors (camera, GPS, IMU, touch screen). They are also very easy to write applications for, thanks to the great work done by the Android SDK developers. For many applications, all they are really missing is connectivity to external peripherals. This is exactly where IOIO fits in: it enriches the inherent capabilities of the Android device with the ability to communicate with external circuits.

From a study of existing solutions, they all suffered from one or more of the below:

• High cost.
• Complicated. Especially so for complete beginners.
• High latency.
• Low bandwidth.
• Required replacement of the Android device OS.
• Large physical size.

IOIO does not suffer from any of the above. Its cost (~$50 from SparkFun) is competitive with existing solutions, dead-simple to use, ~3ms one-way latency, ~300KB/sec throughput, works with stock OS, small in size.

Credits

I would like to thank Google for supporting this project with people's 20%-time. This project would never have come to life without their help.
Mostly I would like to thank Ryan Hickman, Arshan Poursohi and Misha Seltzer.
All the rest of the guys from Google that contributed to this project with coding, organization of the hackathon event, and providing critical feedback early in the process. You all know who you are :)
Aaron Weiss from SparkFun helped a lot with the hardware and taught me how PCB design is done in the real world.
My dear friends who took on the task of being the first adopters and built fantastic first IOIO projects.
And last but not least, my beloved wife and kids who were patient and supportive of their tired dad.

PICMAN

For a long time now I've been wanting to make my own microcontroller-based prototyping board. My original motivation was the unjustified high costs for even the simplest boards (a basic Arduino for $30 - why???) and the challenge of designing something that anyone can make at home within a few hours, with parts that can be cheaply obtained on eBay.

Eventually, I came up with the PICMAN. It is:

• Based on Microchip's PIC18LF4553 - a 12MIPS microcontroller with 12-bit A/D, plenty of I/O, built in USB transceiver and tons of other coolness.
• A single-layer PCB design - ideal for DIY toner-transfer etching fabrication.
• Small form-factor that nicely fits on a solderless breadboard.
• Can be powered by USB/external 5V/external 8V-35V using on-board 1.5A regulator.
• Has a reset button, a user button a power LED (blue) and 3 user LEDs (red, yellow, green).
• Needs zero external components to work.
• Programmed with a bootloader, making it possible to download a program via USB.
• Can implement any USB device using Microchip's USB stack.
• Less than $7 total with easily obtainable parts (not including shipping costs, which are usually low if not free, and assuming that some of the small parts are bought in quantities).

I made two pieces so far, each took a couple of hours' work, requiring some SMD soldering experience. I did the initial programming (bootloader image) with a PICKit2 programmer, after having to struggle a little with the Microchip provided bootloader firmware code. It really works nicely - I like it much better than most Arduinos that cost 5+ times as much and it was really fun to build.
Some ideas that I used in the design:

• Mount the PIC at the bottom of the board, between the header pins.
• Use the copper layer for text to make it easier to locate individual pins.
• Use a mini-B USB connector for smaller form factor (than B) and availability of cables.

Some assorted design/fabrication tips:

• Edit the final PostScript file generated by Eagle with a text editor, replacing the last number in every line ending with "h" with 2000. This effectively resizes all holes to 0.2mm making them perfect for centering the drill bit.
• Add a cool logo on the final PDF with Illustrator.
• Print in 1200DPI on a transparency with a laser printer.
• Cut board with a large paper Guillotine.
• Use lamination machine for toner transfer. Let fully cool in air before gently removing transparency. Verify before etching, or otherwise scrape off toner and retry.
• 1 part HCl, 2 parts 3% H2O2 for etching.
• Final cutting of the board to shape with tin snips.
• 0.6mm holes for PIC and ceramic capacitor, 1mm holes for L7805 and all mounting holes (switch and USB jack), 0.8mm holes for the rest.
• 1k resistor for the green LED makes it just as bright as the other ones with 330 resistors.
• Solder USB jack first. Have a lot of patience ready.

Here is the schematic, the layout and the final artwork (mirrored). The Eagle files, firmware images and programming software can be downloaded from here. I'll happily share eBay links, where all these components can be bought cheaply, just ask if you can't find any of them.
If anyone has any constructive comments, or has built one and wants to share it, feel free to comment below.