OMG LED POST

K. I’m done with the all-caps post titles ;).

As I mentioned at the end of my last post, I am working on a fairly large project involving LEDs and a Teensy 3.1. Well, here are the details. Last year, I bought two meters of Adafruit’s Neopixel LED strip and put it up on the wall in our dorm room. People (and me) seemed to like it, so I decided to go all-out for this upcoming year and do a full circle around the ceiling. Mind you, our room does not have a perimeter of 12 meters (although it doesn’t seem a whole lot bigger), but I don’t want to spend too much money and do the entire room. The ceiling is divided into two sections by a metal box around the fire sprinkler pipe, so I’m only doing half.

Two meters was easy enough to control with just an Arduino, which is what I used. Twelve meters probably would also work, but I would not have enough resources left over to do additional things with the Arduino. That’s where the Teensy 3.1 comes in. These guys are so cool, with a 32-bit ARM processor running at 72 MHz (overclockable to 96!), 256K of flash memory, 64K of RAM, DMA, and full-speed USB support for only 20 bucks!. You can still use the familiar Arduino IDE for programming, and many of the standard libraries are supported. For LED control, I’m using the OctoWS2811 library, which uses highly efficient DMA data transfer within the ARM for updating up to eight individual strips with minimal CPU usage.

The Teensy runs at 3.3V, but the LED strips want a 5V signal. To solve this, you can use a buffer IC such as the 74HC245, which is what I’m doing. The data for the LEDs is running at a fairly high-speed 800KHz, so you can’t just run any length wire you want to your strips without getting undesired results. CAT5/6 ethernet cable is designed for much higher bandwidth signals, and has four twisted pairs for data and ground to four separate LED strips. 100 ohm resistors are used on the outputs of the 74HC245 for impedance-matching to the cable, and two separate cables are used in my installation to fully utilize the OctoWS2811’s capabilities to drive eight strips. I designed a custom circuit board (as I do with everything is seems) to host the Teensy, the buffer chip, resistors, and ethernet jacks. It also just happens to be the same shape as an Arduino, to accommodate the ethernet shield I have.

Neopixel Control Board

Neopixel Control Board

Oh, an ethernet shield? Are you planning on putting this contraption on a network? Yes. I want an easy way to manage the LEDs once everything is put together, and I want my roommates to have control over the LEDs as well. I may even make it publicly accessible for a short time so anyone can play around with the lights in our room! I can also use this for getting the current time or weather (like it would be anything but snow) and somehow display that data on the LEDs for an actually useful purpose.

Some time ago, I decided I wanted a piece of carbon fiber laminate, so I bought some from McMaster. Well, it sat around without a purpose (besides looking awesome) until I needed to make a nice platform to mount a terminal block for power distribution, a big-ass capacitor, and my new control board for this project. I could have just used a piece of plywood like I did for my LED cube, but I wanted this to look nice. Plus, this is lightweight, because weight saving on something like this is very important. Yeah… OK.

Neopixel Control and Power

Neopixel Control and Power

Mhmmmm… Carbon fiber. Actually, the red power wire looks really awesome against it.

I started to make the data cables by cannibalizing a 50? foot ethernet cable I had. I probably should have just bought a hundred feet or so of CAT5 cable, connectors, and a crimper to make my own cables, but ah well. I have one cable done, so I hooked it up to the LED strip and fired it up.

Neopixels!

AHH! Its bright! Well, this was before I ran 12 gauge wire every three meters to better power everything, so the LEDs at the end are dimmer and shifted red a bit.

That’s all I’ve got right now, as I had to order more power cable because 50 feet wasn’t enough for how I’m running power to everything. I also had to order some additional hardware to attach the terminal block to the carbon fiber mounting plate (I had screws holding it for the picture, but there were no nuts on the other side) and a buttload of 3M mini command strip hooks for putting everything up in the fall.

Advertisements

tinyCopter is ALIVE! (sorta)

Progress! This is exciting. After struggling with a pesky compiler issue, I managed to get an LED blinking on my tinyCopter control board. Yes, I managed to get a 32MHz microcontroller with 256K of flash and 16K of RAM to blink an LED. Good use of resources there folks.

Anyway, the issue that I have been having – and it is still there, trust me – is in the creation of a custom board definition for Xmegaduino for my specific setup. Xmegaduino comes with a couple of options for boards, but all of them use the xmega A1. I have a xmega A3. I didn’t think that there would be any issues because the devices in the A series all have the same basic peripherals, just different pin-counts. The problem, however would soon show up.

I got the board definition finished and just copied the pins_arduino header file from a Sparkfun variant just to see if my variant would compile. Cue the obscure compile error! I looked at the error and it said ‘TCF1’ undeclared. What?! The blink sketch I tried compiled just fine for the Sparkfun board, why won’t it work for mine?!  I went back and took a look at the only thing that I changed in my board defintion from the Sparkfun one. It was the MCU type, obviously. I had changed it to atxmega256a3, because that is the device that I am using. When I changed it back to atxmega128a1, which is what the Sparkfun board has, the code compiled perfectly. Then I went digging through the avrdude header files for various devices and found the one for my xmega a3. I searched ‘TCF1’ and it was RIGHT THERE! I don’t know what the issue is, so if anyone else does, please let me know.

You probably read that and though that I never got anything to work. The issue is still there,  so what I did was set the board in Xmegaduino to the Sparkfun one, found the compiled .hex file, and burned it to my chip using AVR Studio. It’s a pain in the butt, but if I can’t get the ‘TCF1’ undeclared issue sorted out, this will have to do.

The point of this post is to say that now I can work on the code for my quadcopter.

74C922 Emulator

So, while I am waiting on parts to build my quadcopter, I am also working on building a 7400 series drum machine. That’s right, 7400 series drum machine. I wish I had designed this, but I am _very_ slowly building this: 7400 Drum Machine. Why the sudden interest in 7400 chips? My grandpa stopped by a couple days ago with some real goodies. An entire tackle-box PACKED with mostly 7400 chips. There are also some 4000 series and several LM566 VCOs, EPROMS, and various other chips. It turns out that I now have most of the chips needed to build that drum machine.

There are a couple snags, though. Matt (the creator) used a couple (nowadays) rare chips in the design. One of them is the 74C922 16-key encoder. Yes, you can still buy these from some places, but they go for about twenty bucks a pop. Ouch.

Since I’m not entering any contests, like Matt did, I figured I might cheat a little bit. The 74C922 is a pretty simple chip; all it does is scan a 4×4 switch matrix and output BCD – binary coded decimal. It stores the last key pressed and toggles a “data available” output when a valid entry is made. This sounds like the perfect task for an AVR with some custom code.

Thus the 74C922 Emulator was born. My goal is to create an *almost* drop in replacement using an ATTiny2313. It will not be perfect, because the ‘tiny is 20 pins and the 74C922 is 18, but one should easily be able to make an adapter to plug my chip in.

There will be some people who call this “dirty” or “uncool” because I reverted to a microcontroller to replace basic logic chips. Okay, get me a 74C922 for 5 bucks – shipped. It isn’t cheating when you have to use modern technology to replace things that are no longer available.

You can take a look at the code on github as I develop it. I just started before I typed up this post, so it is not even close to being done, but it is there anyway.

Digital PSU Update

If you are subscribed to me on YouTube (if you aren’t, why not?), you know that a little while ago I started work on a power supply project. It is based off of the one that Dave Jones of the EEVBlog is building. Mine is slightly different, but has the same major components.

After I wore out(!) the first set of rotary encoder with my constant testing of the firmware, the new encoders didn’t work anymore. I tried everything with my code. I tried countless examples on how to get rotary encoders working on an Arduino. I tried changing the interrupt type, the interrupt routine, and the constants that define my pin setup.

The project sat on my desk for a while, getting nowhere. Suddenly, I had the idea to look at the datasheet again for the encoders I was using (EN16-V22AF15 ‘s) to see if I had missed something while wiring them. Lo-and-behold, there was my problem! When I wired the new encoders, I had (wrongly) assumed that all encoders had a standard pinout, and wired them the same as the old ones. Once I switched things around, they started working!

Now I can get the code finished, so the rest of you can build your own as well!