For a computer that debuted in the early 80s the MSX was a very respectable machine. Of course  these were the days that superimposing graphics over a video was an amazing feat, but  [Danjovic] and [Igor] are still having fun with their boxen. They designed a software interface for the Wii Nunchuck (translation) on their trusty MSX computer.

The plug coming out the back of a standard Wiimote is just a simple I2C bus. Many things can be done with this port from plugging in ancient controllers to controlling robots. [Danjovic] and [Igor] managed to write a routine in Basic that converts the I2C data coming out of the Nunchuck to data the MSX can understand without any modification of the hardware whatsoever.

All the guys needed to plug the Nunchuck into the MSX was a voltage divider and a few pull-up resistors between the computer and controller. They got data from both buttons, the joystick and the accelerometer in the Nunchuck and made a small program to display some sprites on the screen to demonstrate this. Check that out after the break.

I²C as many of you know, is a simple serial interface for many peripheral devices to micro controllers, but it can quickly become confusing to people who may not be accustom to it. Because of that, I²C tutorials are always welcome, and this new tutorial by [Embedds] does an excellent job of how to use I²C with an AVR with a 24C16 2Kbyte EEPROM.

The first half of the tutorial provides a clear explanation of how I²C works, including its signal structure, addressing, and data packets. It then moves on to AVR territory showing how to setup the I²C in an AtMega micro controller. The author uses a pretty standard to most of us Arduino, with software written in AVR C and a nifty little GUI programming application which eases the hassle of dealing with AVRDude directly.

Plenty of code samples follow from twiddling registers to a full blown application reading and writing bits from the EEPROM to a serial terminal on a PC.

You’ve got several devices which communicate via the I2C protocol, but some of them can only operate at 3.3V while the rest are hungry for a 5V connection. What to do? [Linux-works] built this I2C level converter to solve the problem.

The circuit comes from an NXP app note (PDF) on the issue. You can take a quick peek at the suggested schematic from that document. The design uses two MOSFETS for each side of the adaptor. Perhaps a better way to explain this is that you need one for the higher voltage and one for the lower voltage on each of the two data lines for a total of four parts. This allows for both of the buses to communicate as one, while still having their own 3.3V and 5V pull-up resistors.

[Linux-works] concedes that there are chips designed to do this for you, but he was able to source the BSS138 MOSFETs locally and for about ten cents a piece. Not a bad alternative to putting in a parts order.

You might already have the hardware on hand to easily interface I2C and SPI devices with Python scripts on your computer. The board seen above is an FT-2232 breakout board. These chips are often used to facilitate JTAG programming via USB, but they have other features that might be useful to you as well. The chip has a Multi-Protocol Synchronous Serial Engine (MPSSE) which can speak the I2C and SPI protocols, you just need to know how to active them in your code.

[Craig] makes this easy with his MPSSE Python wrapper. Simply install his module, and you’ll be able to import all the commands you need. He demonstrates reading the data out of a 1 MB SPI flash memory chip. This could be used for a lot more, including debugging peripherals à la the Bus Pirate, or reprogramming chips to add to your projects (we’re thinking font arrays and sprites for displays, or look-up tables).

If you’re not aware, these FTDI chips were the go-to for USB support for a long time. We’ve got a guide for bit-banging using this hardware. Lately more chips have become available with USB hardware built-in. They’re quite useful and cost-effective, especially with the availability of open-source stacks like the LUFA project.

Bigtime is a simple way to create an auxiliary display for the Beat707 MIDI controller. The right half of the display shows the beat pattern that the drum machine is using, while the left half keeps track of the current measure.

Just a few components went into the extra hardware. A four-digit seven segment display is fed data from an ATtiny85. Since that microcontroller has only eight pins, a 595 shift register and CD4067 take care of translating serial data into the outputs necessary to light the display. The entire thing connects to the Beat707′s I2C bus, which means you don’t need to make hardware alterations to the original, and this leaves plenty of room for more addons.

The code package includes a Fritzing file, but for your convenience we’ve embedded a PNG of the hardware connections after the break. You’ll also find the demo video where [Guilherme] explains how this works.

There are times when you don’t need much processing power for your project but you do need a lot of I/O pins. It often doesn’t make economic sense to choose a larger microcontroller just to get extra pins so the answer is to use a port expander chip. [Raendra] posted a guide for using one of these chips, it’s a Microchip MCP23008 chip that uses the I2C protocol for communications.

You are probably already familiar with using shift registers like the 595 series for port expansion. There can be benefits to using an I2C device instead. One of them comes when using multiple port expander chips. With cascading shift registers you must always shift in the data for the entire chain of chips. But I2C devices are individually addressable, so you only need to push data over the I2C bus for the chips that need to be changed, the others will remain unaffected. It is especially easy to use these if you already have another I2C device in your project design as the addition only requires the connection of the SDA and SCL lines. Keep them in mind for future undertakings.

[Wayne] wrote in to share an item he just finished working on, an I²C GPS shield for the Arduino. While other GPS solutions have existed for quite some time, his caught our eye due to its feature list.

The shield removes a good bit of the hassle associated with parsing raw NMEA data from traditional GPS addons. While you have the option to communicate with the GPS module over serial in order to obtain the raw data, the use of the I²C interface makes getting the most commonly used GPS data a breeze. The GPS module itself can be set to update at anywhere from 1 to 10 Hz, and [Wayne] says that the I²C bus blows away the oft-used 9600 baud serial interface. While I²C is primarily used for receiving data, it can also be utilized to configure the GPS via its control registers, allowing for on the fly settings tweaks.

While he does sell the units pre-assembled at a competitive price, [Wayne] also provides a full schematic, making this an easy afternoon project once you have sourced the proper components.

[Johngineer] found himself in need of an I2C sniffer, but didn’t have one available. Necessity is the mother of invention, so he put together this I2C sniffer sketch for Arduino. The arduino will record what is going on for a set time interval, then dump the data via serial as a .csv. You then have to plot it to see what is going on. [Johngineer] recommends Livegraph, since it is portable and easy. As you can see in the code, the time interval is adjustable, but you have the physical limitations of the RAM on the board to consider. This seems like a pretty handy piece of code stored around, effectively giving you a passable I2C sniffer in a pinch.

Embedded Labs has come out with a very detailed I2C 101  tutorial, that you should check out if you have any questions on the system. I2C is a short distance serial interface that only requires 2 bus lines. Keep in mind that as wires go down complexity goes up. While there are more than a few I2C devices out there in the wild, and the 2 wire system does make wiring a breeze sometimes, the information required to make use of it often seems confusing to someone who is just starting with it.

The tutorial covers basic theory, stop / start conditions, addressing, data transfer, and acknowledgment plus illustrations. A couple of specific examples are given in the form of a 24LC512 serial eeprom, and a DS1631 digital thermometer complete with code.

A little while back I attended the largest east coast gathering of folks from the ever popular social news site, Reddit.com. Those of you familiar with Reddit already know that it is all about link aggregation. Users post links to interesting websites and material, and can then vote up or vote down content based on interest or relevance. Through the magical site algorithms original and interesting content is, as implied, aggregated up to the front page.  The whimsical nature of this big DC event lead many people to furnish signs of all types based on the culture of the site, internet memes, etc… The signs that really caught my attention were based primarily on the stylistic site layout, blowing up mail icons and other Reddit specific graphics.

The concept of using site graphics gave me the idea of being able to personally vote up or down other peoples’ signs. It was far too easy to just make a cardboard arrow, and I don’t have a color printer. I happened to have a shelved coffee table project involving orange and blue LEDs. Same colors as the arrows! Sweet. To make this project work I would have to work entirely from my project pile, there simply was no time to order anything from the internet. I managed to crank out a functional up/down voting sign in 3 days leading up to the gathering (and the morning of), here is what I did:

What I Had Around The House:

• Orange and Blue LEDs – 124 each. Extras from a coffee table project that is currently shelved.
• Breadboard – I have tons of this stuff lying around, surface mount friendly square flavor!
• MOSFETs – Another shelved project, an electric motor controller so these could handle many amps.
• Resistors – I only had SMD resistors in the values I needed, this turned out to be a huge hassle.
• Arduino Nano – I keep this one kicking around project free for just such an occasion.
• Trippe Axis I2C Accelerometer – I built a little breakout board and toaster oven soldered the thing a long long time ago. We only really need one of the three axises for this project.
• SPDT Switch.
• Voltage Regulator – The Arduino could technically make enough 5v to power everything, I decided to not risk it though.
• A knife worthy of foam core board, I used a pen knife.
• Tweezers, solder, soldering iron, wire, a steady hand, patience.

Stuff I had to get:

• Poster Board – Craft store!
• Hot Glue – Craft store!
• 9V battery clips – This was a snap decision, I got these the day of the event!

Layout The LEDs:

Now its time to recreate the pixel graphics. The site has a very simple low res graphics, below is a close up of the activated voting buttons.

Since I have far more LEDs than sense, I decided to place an LED at the intersections of the pixels.  All these great ideas on how to diffuse the light were tossed around,  wax paper and what not, they would have looked amazing but time intervened. I had to pick a strategy and go with it. I traced the pixel art onto peg board and used the holes as a guide, the total is 124 LEDs per arrow.  In order to fit in one inch squares the arrows overlap one another. The design was drawn out onto peg board (again the coffee table project) and then transferred to some foam core poster board.

This left a nice guide for all the LEDs. There are companies out there that make very specific foam board hole punches, but my local craft store had nothing like it. So I was forced to use the pen knife to spoon drill the holes, all 248.

Once all the holes were drilled I had to press the LED into its slot, this was pretty labor intensive. 5mm LEDs can really damage your fingers.

I tried to get the arrow gradient by spacing out the last couple LEDs in the pattern, it went okay. Some resistor tweaking could produce a more convincing fade out. Dual orange/blue LEDs would have been even cooler. To protect all the wiring and LEDs I glued an arrow shaped section of foam core to the back of the sign (left over from diffusion experiments), this let a bit too much light through the back of the edge LEDs. I’d recommended cutting a slightly larger backing and attaching it with a weak adhesive or Velcro to allow future access to the electronics.

The Circuit:

Now that all of the LEDs are mounted I plugged a few variables about my setup into an LED calculator. I had to determine some values experimentally since blue and orange are slightly different, and I long since have lost any data pertaining to them. My source voltage is 18v, I used a multimeter to find the voltage drop and a power supply with a current meter to measure the forward current of the LEDs.

The calculator told me I could string the oranges up in chains of 9, with a 1Ω resistor for each chain. The orange array would draw 448mA from the batteries. The blues each consume 4 volts and around 70mA (!!). The blues were wired in groups of four, with a 33Ω resistor on each chain. The blue LEDs draw 2.1A from the source. This is about when I decided on the heavy duty MOSFETs from an electric motor project.  The leads of the LEDs were then bent down to wire them together. Since I only had surface mount resistors I had to run ALL of the LED positive wires back to the PCB using some wire wrap wire I had lying around, this is one of those cases where a through hole resistor and some thick bus wire could have made life MUCH easier. The LED grounds were created with some low gauge bus wire, and separated for the up/down portions of the sign.

Switches are fun, people love a good SPDT. They are robust, can handle lots of current… they are really good at toggling LEDs. You know what people really love though? Accelerometers. People love accelerometers, and I happen to have a whole hand full of these buggers in my pile of goodies. Somewhere in the solder smoke and endless wire bonding I had the insane idea to use my spare Arduino to control the arrows, and trigger them off some sort of gesture.

Below is the final circuit. The 3 axis accelerometer is extreme overkill, Cheap analog accelerometers are easily found soldered and coded for and I would go with one of those were I to do this project again.  I also failed to include a potentiometer and code to fade the LEDs via PWM. Don’t judge me, I ran out of time! You may also notice that the voltage regulator is more or less tacked on haphazardly, I had a really nice switching regulator but the stupid thing had the audacity to explode! The nerve! At least it didn’t happen during the event.

Code:

The accelerometer I had on hand is the LIS3LV02DQ, which was offered by sparkfun back in the stone age. I found my own block of code to modify but the site is currently down, you can find a slightly more complete example of the original here and the sparkfun page also has code, this made life really easy. All I had to do was figure out what axis was vertical and set up a threshold to flip on either MOSFET. Gravity affects the axis facing down, so its threshold had to be offset by 1024. I also think the accelerometer was upside down since I wound up at a smaller negative number than positive, either way messing around with the serial output on really helps to dial in the values. 

Testing also revealed that I needed some kind of ‘lock out’ timer. When you flick the sign vertically acceleration peaks on one axis but then reverses on itself as you pull the sign back down. I used 1 second although this value could be shorter. Here is the code, don’t forget to check out [Troy]‘s code for more heavily commented accelerometer stuff:

#include <Wire.h>

// TWI (I2C) sketch to communicate with the LIS3LV02DQ accelerometer

// Using the Wire library (created by Nicholas Zambetti)
// http://wiring.org.co/reference/libraries/Wire/index.html
// This Code is modified to toggle two digital outs based on
// A sudden acceleration upwards or downwards on the Y axis
// -Jesse Congdon

//Modified code from http://research.techkwondo.com/blog/julian/279
//Thanks Julian.

#define OUTX_L 0x28
#define OUTX_H 0x29
#define OUTY_L 0x2A
#define OUTY_H 0x2B
#define OUTZ_L 0x2C
#define OUTZ_H 0x2D

#define XAXIS 0
#define YAXIS 1
#define ZAXIS 2

int downvote = 5; //pins 3 and 5 can handle PWM too
int upvote = 3;
int ledtoggle = 0;

int upgesture = 1800;
int downgesture = -1200;
int lockout = 1000;
boolean lockouttoggle = false;

void setup() {
Wire.begin(); // join i2c bus (address optional for master)
Serial.begin( 9600 );

Wire.beginTransmission( 0x1D );
Wire.send( 0x20 ); // CTRL_REG1 ( 20h )

Wire.send( 0x87 ); // Device on, 40hz, normal mode, all axis’s enabled
Wire.endTransmission();

pinMode(downvote, OUTPUT);
pinMode(upvote, OUTPUT);
}

void loop() {

int val[3];
// transmit to device with address 0×1D
// according to the LIS3L* datasheet, the i2c address of is fixed
// at the factory at 0011101b (0×1D)

Wire.beginTransmission( 0x1D );

// set the MSB so we can do multiple reads, with the register address auto-incremented
Wire.send( OUTX_L | 0x80);
Wire.endTransmission();

// Now do a transfer reading six bytes from the LIS3L*
// This data will be the contents of the X Y and Z registers
Wire.requestFrom( 0x1D, 6 );

while ( Wire.available() < 6 ) {
delay( 5 );
}

// read the data
for ( int i = 0; i < 3; i++ ) {
// read low byte
byte low = Wire.receive();
// read the high byte
val[i] = ( Wire.receive() << 8 ) + low;
}

//keep this in for testing
//Serial.print( " y_val = " );
//Serial.println( val[YAXIS], DEC );

//Now that we have a Y value, does it signify a jerk up or down.
if(val[YAXIS] > upgesture){
ledtoggle = 1;
lockouttoggle = true;
}

if(val[YAXIS] < downgesture){
ledtoggle = 2;
lockouttoggle = true;
}

//blue? orange? what are you trying to say to me toggle.
switch(ledtoggle){
case 0:
digitalWrite(upvote, LOW);
digitalWrite(downvote,LOW);
break;
case 1:
digitalWrite(upvote,HIGH);
digitalWrite(downvote,LOW);
break;
case 2:
digitalWrite(upvote,LOW);
digitalWrite(downvote,HIGH);
break;
}

//This allows me to pause the program to avoid debounce
//also you dont have to throw the sign and gently catch it to
//make it change.
if(lockouttoggle == true){
delay( lockout );
lockouttoggle = false;
}
}

Results:

Sucess! The batteries ran down on me several times (I learned four packs of 9v batteries are expensive). My battery issues stem from the long chains of LEDs. You can see in the above image that the oranges are already starting to die while the higher current blues are destroying the camera. Also note that the remaining 7 LEDs got their own chain and are, as a result, much much brighter. Therefore, smaller chains of diodes means that the LEDs can stay bright under lower voltages.  Silly of me to not realize this sooner. The orange LEDs would become tough to see after about an hour of continuous use.

This was a really fun project, everybody got a kick out of it and I think I have invented a new form of crowd control.

Thanks for reading!

[Ed Zarick] continues work on his NBA Hangtime pinball machine with the completion of the scoreboard and backglass. You should remember this project as we already covered the layer audio he developed for the system. Now he’s proving to be a protoboard master, using point-to-point techniques to build a pair of two and a half digit LED displays for team scores, as well as a shot clock timer and other status indicators.

The lighting board that controls it all is commanded via the i2c protocol, just like the three audio modules. It uses shift registers along with MOSFETs and [Ed] has taken the time to add pin headers and sockets for board interconnects. As is true with the audio system, one Arduino Mega acts as the master on the i2c bus and you’ll notice in the video after the break that the display works in perfect harmony with the sound effects.

We can’t wait to see what he comes up with for the play field!

[JB's] driving a Nokia 6100 LCD using an MSP430 with input from a Wii Nunchuck. He’s using the G2211 microprocessor that came with the Launchpad, and developing his code with MSP-GCC. As you can see in the video after the break, this works but there’s some room for improvement. That’s being said, he is bumping up against the code memory limit, with just around 500 bytes left to work with. The LCD screen is SPI and currently it’s hogging the pins that are used for the hardware i2c. Since he needs an i2c bus to talk to the nunchuck he had to go with software i2c which explains part of his program memory troubles.

We’re in no way experts on this, but it seems like he could save space (and improve the input responsiveness) by rewriting his LCD drivers in order to remap the pins. Then again, it might just be better to move up to a larger MSP430. If you’ve got some advice, make sure to share it by leaving a comment.

When it comes to using servos in projects, there is a definite distinction between the cheap ones and the expensive high power and precision models. The OpenServo project gives you a couple options for enhancing your servo experience. By replacing the control board with a new one based on a familiar microcontroller, a whole new set of features can be attained. For those of you out there with a need for servos like these, you can buy the pre-built replacement board (unfortunately sold out right now), or build your own from the provided schematic, BOM, and source code.

[Nulluser's] Zipit was fine, but it couldn’t go anywhere on its own. Adding some motors and a microcontroller fixed that issue, and now he’s got a little robot called the Zipitbot. That’s a dsPIC board on top which communicates with the Zipit over an I2C bus. Four servo motors provide plenty of power to the wheels,with some extra battery packs nestled between them.

Since the Zipit is running Linux, and already has WiFi hardware, it’s not too hard to add Internet control. With this in mind there’s a webcam on the front to broadcast a video feed for use when controlling it remotely. See a couple of videos of this hack after the break.

Desktop testing

Internet control with streaming video

[Thanks Rkdavis]

[Sebastian] is trying to improve the responsiveness of an electric keyboard. He was unsatisfied with the lack of adequate sensitivity to keystroke. The first step in his process was to measure how fast the quickest keystroke actually is. By setting up an LED and phototransistor and taking some measurements he found that sampling at 1 kHz would be more than adequate.

With initial testing complete he ordered some CNY70 transmissive/reflective light sensors that can be place below the keys. He measures the sensor with the ADC on an ATmega16 microcontroller. Running at 16 MHz he can sample each of the eight analog-to-digital converter channels at 1202 Hz. After doing a bunch of math he put together some lookup tables that are used to translate the ADC data into midi signals. We’ve embedded a video of one sensor controlling the midi program PianoTeq. [Sebastian] also sent us a schematic of one node in the sensor network (see it after the break).

When everything is said and done he plans to use eleven ATmega16 microcontrollers to address the 88 keys, with an additional microcontroller to act as the master using a two-wire interface for communications.

Update: [Sebastian] put up a webpage with a fairly verbose description. Reading it straight from the source really clears up a lot of questions.