Microcontrollers, Electronics & Robotics

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

2011-10-28T10:35:00.000+02:00

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 Manager Unleashes the Power of Firmware Upgrades

2011-07-13T01:05:00.005+03:00

Exciting news once again, folks!
Since the original design of IOIO, it was planned to make it capable of upgrading its own software, by pulling updates from the Android device it is connected to. This gives a lot of flexibility for where the upgrades come from, be it the Web, a file containing custom firmware that a user has built or even embedded inside an Android application that needs the IOIO to behave in some non-standard way.
To achieve that, the IOIO firmware included a bootloader, which kicks in on every IOIO restart and checks for new firmware. For security purposes, it has been decided that the bootloader will only get its upgrades from a single application, called the IOIO Manager, and check that this application is authentic by enforcing it to be signed be the official IOIO key (i.e. by me). Alas, this IOIO Manager had not yet been born when IOIO was first released, and this cool feature, although available on every IOIO firmware, remained dormant. Until yesterday, that is!
The IOIO Manager application is now available on the Android Market. Install it by scanning the QR code below or by clicking it:

Installing New Application Firmware Using the Bootloader

This is the most common use case: the IOIO Manager application lets you maintain a library of application images, and then choose the one you want installed on the IOIO at any point in time. Once selected, the IOIO will pull this image after its next restart. This takes less than two seconds and does not require any additional hardware (such as a programmer).

To remove all doubt: this upgrade mode works great with the existing bootloader version, which all current IOIO owners have. At least in the near future, the bootloader is not expected to change, and those users are able to use IOIO manager to receive upgrades!

Upgrading the Bootloader

The bootloader cannot upgrade itself by design. This is in order to protect the user from accidentally bricking the board by installing a faulty image that renders the bootloader invalid. My original thought was that the bootloader will never have to be modified anyway. Errrrr, wrong! When designing the bootloader I figured that since the bootloader already contains all the code for establishing an ADB connection to the phone, it might as well provide this service to the application and save the code duplication. While this seemed reasonable enough back then, I overlooked something important - what if the application wants to use some other protocol over USB? One example is of course Open Accessory. Moreover, what if I found a bug in the bootloader, or want to introduce an optimization? Bottom line - we need a way to upgrade the bootloader from time to time and for that we must have a programmer.

Wait, what?

But the SparkFun page specifically used to say "you'll never need a programmer", until we figured out this is true only 99% of the time. And yes, we could just fix the bootloader design bug and have the new units shipped with a better bootloader, but what about the users that already bought it and don't have a programmer? I wanted to be as fair as possible to these people who were first to believe in my product, so I decided to go the extra mile...

So you need a programmer, no doubt about that, but who said you need an off-the-shelf programmer? Let's make one out of a IOIO! And so I did. And it works! So right now, if you want to reprogram your IOIO's bootloader, all you need is another IOIO, be it your friend's or your fellow hacker. Well, people can still argue this is not a free solution in all cases, but I hope they will appreciate I really did anything I could to make things better for them.

Here's what it looks like when one IOIO programs another:

Simply connect 5 wires (two of which are supply and ground) between them, select the image and go!

New Possibilities

First, this new feature opened the gate for me to start pushing new features to IOIO on a regular basis. Some of which have been itching me to release for quite some time.
Next, this allows people interested in modifying the code running on the IOIO to do so very easily as well as to distribute the firmware they are producing for others to install with no trouble. I'm really curious to see what will come out of this.
For more information, read the detailed guide to the IOIO Manager on the IOIO Wiki.

P.S. in retrospect I realized this is a homage to an older project of mine: AVR programmer using the PICMAN (the great-grandfather of the IOIO)

IOIO over OpenAccessory (ADK) Available

2011-06-05T10:37:00.004+03:00

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

2011-04-30T23:06:00.002+03:00

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

2011-04-08T00:32:00.001+03:00

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.

POV Globe - Part IV - Software & Data

2010-08-09T09:15:00.001+03:00

This is in continuation to: POV Globe - Part III - Electronics

The data layout on the SD card and the software are rather technical and trivial, but still worth a mention.

Data Layout

I'm using the SD as a raw block device (i.e. no file-system). This is in order to reduce read overhead, as well as to make sure that all image data is in consecutive blocks (as mentioned in the previous post, jumping between non-consecutive blocks takes an eternity of 380us). Since reads are always in blocks, the format is block aligned. Some numbers:

One block of data = 512B = 4096bit = 16 columns.
One revolution (or "frame") = 512 columns = 32 blocks = 16KB.
One second of animation = 50 frames = 800KB.

A quick calculation shows that 1GB of data can hold a little over 20 minutes of 50FPS animation. My card has 2GB, and it is easy to find cards with more.
The format is as follows:

First 4 bytes are the total number of blocks in the image, followed by 508B of padding.
Then the image itself follows, column-by-column, where the bytes in each column are ordered from top 8 LEDs to bottom 8 LEDs, and the bits in each byte are ordered so that the MSB is the top LED and LSB is the bottom LED.

In order to write the raw data to the SD card, I'm using a USB card reader and the Linux dd command, directly to the device.

Software

I will not get into all the details - most of them are just technicalities.
The only part worth mentioning is how the main loop synchronizes the drawing of the columns to the physical location of the LED row, designated by a pulse from the IR sensor, once per revolution. It also needs to take into account possible out-of-sync situations, and "catch-up" if we're late.

A timer keeps the time elapsed since the beginning of the column.
The variable col_dur holds the duration of a single column (1/512 the duration of a revolution) - it is updated every time we get an IR pulse.
The variable pos keeps the current (estimated) physical position of the LEDs, between 0..511.
The variable cur_col keeps the last column that has been drawn, between 0..511.

And the main loop looks something like this:

while (true) {
  // draw all the columns until the current position
  while (cur_col != pos) {
    draw_column();
    if (++cur_col == 512) col = 0;
  }
  while (TIMER < col_dur);  // wait until the end-of row time
  // advance position according to how much time elapsed
  do {
    TIMER -= col_dur;
    if (++pos == 512) pos = 0;
  } while (TIMER >= col_dur);
  // check position sensor and make adjustments
  if (pos == 0) {
    ... wait for rising edge of the sensor ...
    ... recalculate col_dur (make it longer or equal), and reset TIMER ...
  } else if (sensor_rising_edge()) {
    // got a premature signal - we're falling behind
    ... force pos = 0, recalculate col_dur (make it shorter), and reset TIMER ...
  }
}

The draw_column() function just streams 32B of data from the SD to the LED board, pulses the latch line, and then prepares the next column (i.e. issues a SD command to get the next block and waits for it to become ready, if needed).
In practice, because of the SD latency-related problems described in my previous post, this function currently takes care of skipping the first block, while the second is fetched, and in the future it will also take care of streaming the first block from flash.
The last video in the previous post demonstrates this algorithm in action, taking button presses in lieu of IR switch signals.

POV Globe - Part III - Electronics

2010-08-09T08:19:00.004+03:00

This is in continuation to: POV Globe - Part II - Mechanics

The first concepts I had were:

Keep the hardware modular in order to be able to design & test small components separately.
Stream the image or animation to the LED display from a micro-SD card, so that: there's plenty of storage for rich animations, I will not need to worry too much about complicated compression schemes, and it would be really easy for anyone to deploy new animations.

I started designing the electronics by drafting the following specs:

256 LEDs per column, 512 columns per revolution, 50 revolutions per second = 6.55 Mbit/second = 39us per column.
Serial communication between the motherboard and the LEDs to avoid having to run lots of wires and use a lot of IO on the microcontroller.
Daisy-chain several LED boards, so that I can create an (almost) arc-shaped row of LEDs.
Synchronize LEDs with rotation angle by using an IR LED on the base of the globe and an IR sensor on the motherboard.
In circuit programming and UART connections on the motherboard for development & debug.

LED Boards

I started by designing the LED boards. I needed 16 boards of 16 LEDs each, which can be daisy-chained. My idea was one 16-bit serial-in parallel-and-serial-out shift register, one 16-bit latch and 16 LED drivers (transistors) per board. Apparently, this wasn't only my idea, and I soon found that there are off-the-shelf ICs that do just that, leaving me mostly with designing a very simple board that does little more than routing. A simple survey found that the TLC5927 of TI is a perfect match. I'll take this opportunity to really thank TI for being very generous with free samples - 20 pieces of this IC got to my home with a courier within 3 days!
Here is the circuit schematic and (double sided) layout for the LED boards:

And a picture of the home-etched board (these are actually two pieces connected):

BTW, this board has a shiny silver finish, as I finally managed to get my hands on Liquid Tin, after a trip to the US. No more rusty copper look...

Once built, I quickly hooked it to my loyal PICMAN for testing. I'm really starting to like this guy...
As it turns out, the best way to output a stream of bits out of a microcontroller is by using the SPI hardware. With the PICMAN's PIC18F4553, you can reach an effective rate of 12MHz.
Here's a video of the first experiment I did, a simple blinking pattern on 5 LEDs:

Then it was time to have some fun with POV effects, so I wrote a simple program that would display a Smiley pattern when the board is wiggled from side to side. It worked! Unfortunately the camera doesn't capture the effect as nicely as the human eye, but in this video you could still see the idea:

Motherboard

First issue to tackle was communication with the SD card. After searching the Web for information, it turns out these devices support an SPI-based interface of up to 25MHz. I took a micro-SD to SD adapter to use as a socket, and soldered pin headers to it. Than I stuck it on the breadboard, connected it to the PICMAN and started playing around with it. Careful! SD-cards are 3.3V devices, so when working with a 5V microcontroller a simple voltage divider on the output pins is needed. After some messing around with the software, I was able to read data blocks from the device.

Now, how do you stream data from a micro-SD card to the LED boards at 8MHz (cheaply)?
A simple cycle of read-from-card -> write to LEDs would naively take at least a few cycles per-bit, which would require a rather fast microcontroller to support 8Mbit/sec. Fortunately, both the SD card and the LEDs speak SPI, so I had an idea to connect the serial input of the LED board directly to the serial out of the SD card, have the microcontroller initiate a read and then send a latch signal to the LEDs at the right time. This way, the microcontroller doesn't have to bother looking at the incoming data. It turned out to be a really neat trick, and I was able to easily stream data directly from the SD card @8HZ, using a cheap ATmega8A clocked at 16MHz!
From this point the design was rather simple: I added a reset button, UART and programming connections and a connector to the IR sensor. I also used a couple of fast MOSFET gate drivers (TC4427) to function as line drivers for the long lines driving the LEDs.
Here is the schematic and the (double sided) layout of the motherboard. Ignore some 0 resistors in the schematic, used solely as "bridges" above traces for solving layout constraints:

A micro-SD to SD adapter is soldered "standing" to the side of the board and reinforced with some hot melt glue.

I used the PICMAN as an AVR programmer to program the ATMega, as described in my earlier post.
Hurray! A few long nights later, and I had a working system, able to stream data from the SD to the LEDs while synchronizing the rate to the input from the position sensor. In the video below, I'm using a push-button to simulate the IR sensor input. I generated a simple image file which generates a 32 LED scan pattern. You can see that the scan rate adapts to the rate of button pushes:

Caveats

The motherboard has several problems that I'm intending to fix in the next version. The first problem is related to SD card latencies. After performing some timing measurements here's what I found:

Operation	Duration [us]
From issuing read command and until the first block is ready	1340
End of block until the immediately following block is ready	6
End of block until non-following block is ready	380

Note: A block is 512 bytes. All read operations are always done in full blocks.

The first value is not very interesting, since it only happens once when the program starts running.
The second value is interesting, because it happens every time we move from one block to the next - every 512 bytes = 4096 bits = 16 columns. This means that when we display a column that is in the beginning of a block, it will take us 6us (latency) + 32us (256 bit @8Hz) = 38us. Just below our spec of 39us/column!
The third value is problematic, because it means that every time we reach the end of the image, if we want to jump back to the beginning of the image we'll be late by about 10 columns. So my idea for solving this was to copy the first (or last) block of the image to the microcontroller flash when the program starts, and then stream this block from flash while the next one is fetched. Alas, I suddenly realized that the way my hardware is built, the LED serial-in is hard-wired to the MISO line, i.e. the SPI input of the microcontroller, and thus I can't stream data out of the microcontroller to the LEDs, only from the SD! As a temporary workaround, I'm just skipping the first block altogether and in order to make sure that those missing 16 columns don't happen too often, I'm just replicating the image many times on the SD.

Some other problems with the current design are not as bad, but I might as well address them on the next version. Those include: the translation from the microcontroller's 5V to the SD's 3.3V creates a really messy layout; the ability to stream data directly from the microcontroller is nice-to-have regardless of SD latency; ATmega8's are no longer cheaply (under $2.5) available; I really regretted not putting a general purpose button and LED on the board for some basic user interface and debug.

To address the first problem, the next version will include a mux to select between MOSI (microcontroller output) and MISO (SD output) as LED inputs.
To address the second problem, I'm moving to PIC18F23K20, which is $1.70 from Digikey, works on 3.3V, 16MIPS and 16MHz SPI, does not need an external crystal/resonator to operate at full-speed. In addition, the PICs don't suffer from some of AVR's annoyances, such as the ability to brick the chip by setting wrong fuse values and the sharing of the serial programming lines with the SPI. So much goodness that I just had to buy 10 of those...
I intend to first run a full system (with the said workaround) before designing the new motherboard, since I might encounter a few more problems down the road.

Power

Q: How do you transfer power to a circuit that's turning?
A: A slip ring.
A slip ring is simply a conductive ring attached to the rotating shaft and a stationary conductive "brush" the keeps in contact with the ring, but slips on it with minimal friction. For transferring power, you would need at least two of these.
Due to the nature of this connection, it is very noisy, and thus not generally suitable for data transfer. This is, by the way, why I put the motherboard on the rotating side. To filter out any noise, or short discontinuities in power, I used a big capacitor (2200uF) on the motherboard, in addition to 0.1uF decoupling capacitors close to each IC. Hopefully, it will do (haven't tried yet).
I made the slip ring myself: turned 2 aluminum rings and a plastic isolating sleeve on the lathe. Then I found that soldering to aluminum is really hard, so I used a conductive glue instead, and buried everything under a lump of hot melt glue.
Here's what the finished module looks like:

And this is me, making this ring, in a really beautiful panoramic photo taken by Omer Calev:

Next: POV Globe - Part IV - Software & Data

POV Globe - Part II - Mechanics

2010-08-09T08:18:00.000+03:00

This is in continuation to: POV Globe - Part I - Introduction

Initially, I completely underestimated the complexity of the mechanics. "Yeah, let's take a 60cm hoop with LEDs and turn it at 50 RPM..." Then, one night I did the simple kinematic calculations, only to find that this means about 3000G(!). Yes, that's right: 3000 times gravity, or simply put, each gram of mass (on the widest part of the hoop) is going to pull the hoop outwards with a force of 3 kilograms. Now that takes a rather rigid structure to support. I started thinking bicycle wheels and the like, but I reckoned that building a machine that is beautiful enough to justify potential killing of a few people is rather challenging. So I started re-thinking the structure, trying to find a way to make is both light and suitable for the kinds of forces that operate here. I also figured that drag is going to be rather substantial, so I'll need a rather sturdy motor to support that.

Eventually, I came up with this structure:

There isn't really any hoop - just "wings" with lengths and spaces chosen carefully that comprise a frame for mounting boards with white LEDs on one side (16 boards, 16 LEDs each) and a single board with the RGB LEDs on the other. Those wings will be made of a strong and light material, preferably transparent, probably poly-carbonate or similar. This part has not yet been built (waiting for a friend with a laser cutter to rescue me).

Turning a shaft fast enough with the ability to resist friction and vibrations is also not a simple matter. The solution that has been chosen is to mount the shaft on a washing machine bearing and drive it with a washing machine motor. This part has been really fun, since I have never worked with motors of this size or with AC. The controller has also been taken from the same washing machine (it even included a pot for speed control!), so I was only left with some wiring and mounting. I also needed to build a pulley and belt system to achieve the desired transmission ratio and a case to keep everything in place. My friend Shachar contributed his golden hands for this task.
Here are some photos of the build process:

Currently, it is very noisy. I'm still considering my options: possibly I'll fill the case with some acoustic isolating material.

Here's a video showing the turning mechanism working slowly:

And this video shows some fast spinning and variation of the speed:

Next: POV Globe - Part III - Electronics

POV Globe - Part I - Introduction

2010-08-09T08:13:00.002+03:00

PO-WHAT??

For those who don't know, POV stands for Persistence of Vision, and in this context it describes a technique that people developed for creating LED-based displays of various forms that appear to be floating in the air.

The basic principle is rather simple: you take a row of LEDs, spin it very fast while switching the LEDs on and off at very precise timings, carefully synchronized with the location of the LED row. The motion is quick enough that our eyes cannot detect it, and the illusion that is created is of a 2D image composed of the circular paths created by the LEDs.

Many people have mounted such LED rows on HDD spindles, mostly for creating clocks, such as this one.

In other variations of this basic idea, the rotation axis can be parallel to the row of LEDs to create a cylindrical display, and going from cylindrical to spherical is a simple matter of using an arc rather than a straight row of LEDs. People have used the spherical version mostly for displaying of globes.
Yes. Everybody seems to be building those recently. I got my inspiration from this YouTube clip. So why build another one, and what's so different about mine?
First, I wanted my globe to be rather big (60cm in diameter), spin fast for a smooth image (up to 50 revolutions per second), have high resolution (256 LEDs) and be very versatile in terms of what it can display - one could easily load complex animations for it, and change them frequently (more on that later). Second, while taking no credit whatsoever for the idea, the build is still really fun, and coming up with elegant solutions to the various problems that arise still needs a good amount of innovation.

To make it more interesting, the display is actually comprised of two layers - a sphere made of white LEDs, and a cylinder, of slightly bigger diameter made of RGB LEDs surrounding it. That would enable displaying an animated black and white globe with a colorful text or animation around it.

In the next series of posts, I intend to document the process of building this installation. At the time of writing this, it is still a work in progress, and I intend to update the posts every once in a while when I'm having some interesting progress. Don't hold your breaths, I'm investing only a few hours a week on this project, so it takes a lot of time and patience.

Next: POV Globe - Part II - Mechanics

AVR Programmer Using PICMAN

2010-05-18T14:00:00.001+03:00

For a new project I'm working on I needed to program an ATmega-8. Alas, I didn't have an AVR programmer, nor the will to build one.

I decided to make one using the PICMAN. After searching on the internet for a while, I found out about AVRUSB500 from Guido Socher. The software is well-written and open-source, so I decided to port it to PICMAN. A few hours later I had a working USB programmer, STK500v2-compatible, which enables it to work from AVRStudio.

I used the Microchip CDC device code from the Microchip USB framework in order for the PICMAN to appear as a COM port on the PC.
Source code and hex available here, under GPL.
Now I can get on with my life...

PICMAN

2010-04-13T00:09:00.011+03:00

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.