Archive for the ‘electronics’ Category

Uzebox – AVR Gaming console

UZEBOX

So lately I have been fiddling with Uzebox. It’s a game console from just a ATMega644 mcu and a AD725 (RGB-to-NTSC converter) chip. Thats the whole idea. The RGB signal is created by a manual 3:3:2 resistor based DAC, and audio is pure PWM signal.

The awesome part of this console is the “kernel”, written by Uze (Alec Bourque), which has several video modes available, and a 4 channel audio mixer, all done in interrupts, so that when you code stuff to this console, you don’t have to think about the clock cycles of your code, as the interrupt will always update the screen and audio output “behind the scenes”.

The project is now also supported well by a small but great community, that has helped Uzebox with more video modes, games, and even a realtime emulator!

I have made a few additions to the emulator (uzem), adding threading to split the SDL screen blitting from the MCU emulation in seperate threads, a funny RAM/Progmem visualizer, and a SD card FAT16 emulator. (The emulator already had SD card emulation, but I have added the FAT16 emulation)

You can buy yourself a Uzebox at Adafruit, or just download the emulator from the code.google.com repository.

Games and demos(with or without source code) can be downloaded from the wiki.

My additions can be found in the SVN repo.

Big timecode display

So, in the last blog entry I told you about the perl DMX backend that we are doing for the party project of ours.

We have concluded that we will have a bitchin’ intro show. And it will be timecode controlled. Every little audio / DMX / Video effect will be timed to the millisecond.

To do this, we have (for now) concluded that we will use Ardour as the audio platform, and use jackd as the timecode server.

The nice part about this, is that it’s very easy to code a jack client that fetches the timecode in realtime, and then transmit it via UDP to our external timecode display. And thats where this blog post comes in place; we are creating a cool 8 digit 7-segment display to display our timecode.


William got 8 of these modules from Kay, who agian bought them for almost nothing at eBay. :D (in Norway they cost about $25 each at the time of writing)

Anyways. As you see in the picture, william has glued the 8 digits together, wich we will put inside a box, and wire up with some pic18f4520 and some ENC28J60 for ethernet connectivity. Yes, the module will be stand-alone, only connected to ethernet, and display the current timestamp/timecode in Ardour/our DMX system.

Do we _really_ need it? no. Is it really cool? yes.

So, so far we have finally gotten the box for the device. It’s acctually a image frame, with an exceptionally deep frame on the backside to contain the whole shebang.

Here are some more “under construction” photos:

In the first photo you can (almost) see the PIC18F4520 on a vero board, with a connected prototype board with the ENC28J60 chip, which works perfectly and successfully outputs data to the (soon to be connected) displays when it receives timecode UDP data on port 1337 ;P

This project has not been the easiest, even though the concept is simple. I’m not the greatest engineer in regards to analog electronics. The problem is that the 7segment displays needs 7.2v, and uses common anode. This means that I cannot use the displays directly from the PIC processor. So i went on using a ULN2803A to drive the display. This solves the “common anode” problem. Now on to solving the 7.2v problem. I have as I said, not very much to say in the analog electronics world. So I went on, and found the first PNP transistor I could find. Kay was kind enough to donate them to us.

He had a bunch of 2N3906 transistors, wich seemed to be “workable”. So i set them up on a breadboard and after some fidling with resistors and pulling up the signal, to let the PIC pull it down, to enable the flow trough collector and emitter. This seemed to work great, so I soldered the whole shebang together.

Everything works great now, except that the display “fluctuates”. Seems like either the 5v regulator is too weak (it gets pretty hot, but I can’t check it, because my multimeter doesn’t want to measure current), or the transistors are a bit too sensitive. Sometimes, when there is traffic on the network the display fluctuates when the ethernet-leds light up. So something is not at it’s fully potential yet. But I’ll measure a bit when I get a working multimeter.

So here are the latest images(only thing missing is the 4 dots at the bottom):

13 Input USB Temperature Sensor for PC

I love doing statistics of everything, because data is power. So we thought we would put a temperature sensor in every server-rack in this server housing facility, and I checked the prices of some standard components. First I thought of the DS1820, which is fine, but two drawbacks. It’s somewhat expensive, and takes a full second to read value from. So if you wire a lot of sensors serially, you’ll need to wait one second for each sensor on the same line. Do not hesitate to contact Kaizen Technology if you need manufacturing services like Surface Mount Assembly, Prototype PCB Assembly, or Fast turn PCB Assembly.

Then I found these cute analog temperature sensors, called MCP9700A. And they cost only €0.37 each. Or if you buy larger quantites, you’ll get even lower prices. So I thought.. the PIC18F4520 has 13 analog ports. Why not create a small pcb with a pic18f4520, and some connectors, and wire it to the computer via RS232. Having those same issues? Contact New Jersey IT Support and get your computer like brand new.

The problem then, is that i’d have to buy max232 chip, and then I’d need a RS232->USB cable, and thats pretty expensive. But then I found the life-saver chip FT232R. This awesomeness in a chip enclosure is a RS232(or any serial data in TTL levels)-to-USB ‘converter’. It has drivers for windows *, Mac, Linux. And you can even modify the eeprom inside it, to make it use a different VID and PID or just change the device description of it. And it also have two GP pins, which you can connect to LEDs to show when it sends or receives data. The BEST part about this already awesome chip, is it’s price. Here in Norway a RS232->USB cable costs from €42 an up. But this device, practically the same (except for missing RS232 level converter), costs only €2.87. And thats with all the leetnes of being able to change the device description and all, included.

So I wired it all up in Eagle, and it came out to be like this.
Schematics:

Board:

So here I have a PIC18F4520 processor, 20Mhz XTAL for it (because I had some laying around), FT232R chip, 100K Resistor pack, and a few LEDs. All in all, about €20 worth of components.

So, now that I had designed the board, how to get it made, and cheap? Well, I found this site called [link]www.batchpcb.com[/link]. Which is fabulous. They collect PCB boards for a bunch of people who need cheap prototype boards, and send everything together to China, where they produce the boards, and return them in about 12 days. They often set up your board several times, in case some of them should be bad. (bleedout on the copper). And the best part. If more than one of your boards are ok, they even send you the extras, with no extra charge. So I received two pcs of the PCB I ordered, and couldn’t be happier :)

Here’s the result, (image quality courtesy of iPhone 3G)

Then we add all the components. And bobs your uncle: (image quality courtesy of iPhone 3G)

And it even works! ;)

The software I have uploaded to the PIC18F4520 sends all the temperature info, and the 8 general purpose inputs to the computer via a virtual com port on the computer, 20 times a second.

LEDDisplay games

So.. We can’t have a “screen” without pong or snake, can we?
When I completed the LED Displays abillity to be controlled from the computer via RS232, I wrote a nifty little module in Perl, which I called: Acme::LEDDisplay.With this module I am able to use the display just as a.. well… display :)
But ’till today, I haven’t made anything really cool. Just some small things like live Network-graph and live IRC log ;p

But today I wrote two games for it, and I’m pretty pleased about the result :)

The new scripts for today are Snake/Nibbles, Pong, and a little meaningless bouncy-script.

Nibbles

Source:
nibbles.pl
Video:
MOV00332.avi

Pong

Source:
pong.pl
Video:
MOV00334.avi

Meaningless script
Also made this little ball-bouncing script, which pong is built upon. It uses pretty much the same “ball” module. You can start it with as many balls you want. And it bounces them randomly about.

Source:
bballs.pl
Video:
MOV00331.avi

LEDDisplay / BlinkenLed

My newest project; LED Display.

Youtube video of it

The idea came from germany, where the group “CCC” or Chaos Computer Club, created a matrix of lights in the “Haus des Lehrers” building at Alexanderplatz in Berlin. They installed computer controlled lights in 144 windows spanned over 8 floors (18 windows per floor). This was done first in 2001. You can look at their webpage at BlinkenLights.de.

If you search for Blinkenlights on video.google.com or youtube you will find a really interesting documentary about the Blinkenlights project. I saw this video a few years ago, but when I saw it again now recently, I ignited on all my sparks. I had to make my own small scale version.

So I surfed the web, and I found, amongst others, BlinkenLEDs. These guys had done almost exactly what I wanted to do. I saw that they were using a 4094 Bit-shift register. I myself would have used a 74xxx series chip, but since they had done it perfectly with this chip, and since it looked like it worked perfectly even without resistors for each LED, I incorporated the 4094 chip in my plans.

My plan differs from theirs in two ways. I wanted mine to be able to run without a computer connected. For this I planned using the PIC16F628. Someone might wonder why I wouldn’t use the cheaper “less cmos” version PIC16F84. But the answer is also the answer to the other way my project differs. I wanted to use the serial port, instead of the LPT(read: printer) port. And the PIC16F628 has hardware USART capability, which makes RS232 connection simple.

The part-list for mye circuit is as follows:

  1     PIC16F628
  1     18-PIN socket (for the PIC)
  1     MAX232
  1     95128 SPI controlled EEPROM (128KB memory)
  1     20MHz Crystal for the PIC
  1     33uF electrolyte capacitor (noise reduction for PIC)
  2     22pF capacitors for 20Mhz crystal
  2     Veroboards (prototyping boards)
  3M    Flat cable
  4     1uF electrolyte capacitors (for the MAX232)
  18    4094 Bit shift registers
  144   Red 3mm Leds (I've got 4000 spare :P)
  misc  Wires

The circuit was planned live inside my head ;) I have regretted this a bit as the project evolved, but all in all, I’m pretty happy/proud about the result.

Here you can see a picture of the controller-card when I had completed the wiring of 3 bit-shift registers, the PIC16F628 and the MAX232. I were planning on having two rows of bitshift registers filling the whole left side of the board, spacing just enough to have 8 wires up to the LED board from each register.

Here you see how I wired the first 4 bit-shift registers. I found out later, that I wanted the first register to be on the next row. Even though here you can see that I have connected the first register on this “second row” to the PIC16F628 processor. If you are really observant, you can tell that I have changed my mind a few times on the wiring of the bottommost row ;P
It also prooved later that I should have thought it over just one more time. Because here lies the root of all evil! I wired up all the STROBE pins to +5v, and wired together all the OUTPUT ENABLE pins, to one of the ports of the PIC processor. This was not what I meant to do. Because of this, my display will flicker a bit each time it updates the screen. But since it is a 20MHz processor, it’s hardly noticable.

This is a picture of all the 18 Bit-shift registers wired up.

This is all the registers wired up. You can see I have moved the control-cable from the processor to the leftmost registers. I tested the circuit with a program on the processor that lit one row by one, and all of them worked at the first try! :D

It was then over to the LED card. Here I have drilled out 144 holes. Pretty boring work I can tell you…. You see that I have wired the ground from the 9 first LEDs.

This is how it looks when all 144 LEDs are connected. This took very long time, especially afther the first few rows. Since my friend had to leave, and so I was two hands short. But I got it done at the end. I wish this board was pre-tinned like the controller-vero board, since this made it even harder to solder the LEDS with only my own two hands.

Then I started wiring up the leds to the shift registers. I am glad that I saw how terrible the wiring looked at the projects at BlinkenLEDS. So that I bought flat cable for my project. I’m pretty satisfied with how I wired up the leds to the flat cable. Even though it took quite a long time. After each new row, I powered up the circuit to check if there were any “dead pixels”. There were a few (read: totally 4-5), mostly since the board wasn’t pre-tinned, and I don’t have flux other than what the tin provided. But since I was in lack of hands, the flux evaporated before I got to actually solder the leds to the board.

Here you see the board running a program that alternates between all the leds. The display works! It was time for celebration with a “blm” movie from the BlinkenLights project. So I wrote a parser in perl that converted a .blm file to .c code for my PIC16F628.

#!/usr/bin/perl
use strict;
 
my $ttl=100;
my @arr;
my @outarr;
my $out;
 
while(<>) {
  if (m/^@(\d+)$/) {
    $ttl = $1;
  }
  if (m/^[01]{18}$/) {
    push @arr, $_;
  }
  if (scalar(@arr) == 8) {
    print " PORTB &= ~SHOW; // Hide display\n";
    for my $pos (0..17) {
      for my $ari (0..7) {
        push @outarr, substr($arr[$ari],$pos,1);
      }
      print " sendbyte(0b".join("",@outarr).");\n";
      @outarr = ();
    }
    @arr = ();
    print " PORTB |= SHOW; // Show display\n";
    print " delay_ms($ttl);\n\n";
  }
}

The result was a moving version of this:

Source of the BLM file, and moving GIF of the animation can be found here.

I have now coded the RS232 support and I first modified the above code to send the animation directly to the display. And then I coded myself a perl module to control the display live. I called it “Acme::LEDDisplay” and using some quick hacks. I have support for pset (pixel set), pget (pixel get), line, circle and text.

With this I can create live output from just about everything. The sky is the limit :D

Here is a video sample of “spin.blm” on my display: MOV00315.avi

The project is almost done. I have made it possible to send blm movies directly from the PC, and control the display in simple perlcode. But the “offline-playing” part is not done. I had a few problems getting the SPI<->EEPROM communication to work, so I have ordered some more EEPROMs to check if the one I have is broken. I really hope that, because it would be fun to be able to upload a few “movies”, and let it run for itself on batterypower. Maybe show off a few christmas greetings for example ;)

I also might wire it to my recently bougt Bluetooth module, so I can control it without any wires whatsoever :)

If you want more info about how I wired things up, sourcecode, etc. Give me a reply!