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.

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.

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.

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.

OMG A NEW POST

Hey everyone! Very long time, no posts! This will hopefully be the beginning of a revival of my blog, since I will probably have more time after finishing high school and starting college. Where am I going? Michigan Tech! Yes, that place in Michigan that’s pretty much as far as you can go before you hit Canada and where summer is about a week long. As you can probably guess, I’m studying electrical engineering. I really like it there and have met some great people that share my obsession for electronics.

Updates. The quadcopter is not done :/. It probably won’t get done either. I was quite close to getting it flying, but it would just sit on the ground and spin in circles. I built another(!) LED cube, this time with blue LEDs. I made a nice set of circuit boards for driving it, with the circuit still copied from the Instructable I followed for the first one.

Running the test program to verify everything is good.

A (not very good) picture of the cube running the main program.

Well that’s all I have at the moment. I’m working on a big LED installation for our dorm room next semester. All I’ll say right now is it involves ethernet, a teensy 3.1, and 12 meters of Adafruit Neopixel LED strip.

Quickie Post

This isn’t going to be a full post, but I wanted to mention that my PCBs for my power supply came. I’ve got the OLED display working, and will get the other peripherals working shortly. There will be a full post in a couple day’s time.

The front and back of the power supply PCBs.

Power Supply Revision C

Sorry for not posting in a long while, but I’ve been busy with school. First, the quadcopter is still not finished, but my goal is to have it finished before next year.

Now onto the main topic of this post. As you probably know, I have a power supply project that I’ve been working on for quite some time. When I started my quadcopter project, it got pushed to the backburner, but I still kept slowly tweaking it. It’s back now, though, and better than ever.

While working on my quadcopter, I started using the Xmega series from Atmel. I really like these now, and their power and amount of I/O available make them great candidates for many projects. For Halloween, I built a 10-channel light controller that can be chained together with other control boards to greatly expand the number of channels. I didn’t finish it in time, but now I might be able to use it for Christmas (light shows anyone?). Since I wanted a large number of PWM channels per board without using something like a TLC5940, I used an Xmega A4.

One of the problems with the old power supply design was the display size and update rate. Adafruit stocks some OLED display modules, both in monochrome and color. OLED displays are known for their amazing contrast and sharpness, due to the fact that the pixel itself is light-emitting. A traditional LCD relies on either a backlight or reflected light to provide contrast. The LCD I was using previously communicated over I²C, which is a slower interface than SPI. It could have been the library I was using to control it, but I was not happy with the update rate I got with it. The OLED display that I got from Adafruit uses SPI, allowing me to push more data to it, faster. The physical size is smaller that my previous display, but since this is a graphical display, I can make the text as big (or as small) as I want.

While probably a bit overkill for the task, I also chose to use an Xmega A4 for my power supply. One of the Xmega’s advantages, besides the clock running at 32MHz at 3.3V, is the multiple SPI ports. Now I can update the DAC / read the ADC or update the display at the same time. This will hopefully give me a huge performance boost in update speed. Using the Xmega also gives me more pins to use, so I don’t need to use an I/O expander like before.

The rest of the design is pretty much the same as before, but with a couple improvements. Instead of using buttons, my rotary encoders are going to be the kind with one built in. This will help me create a more intuitive menu system than I could have in the past. Also, the tolerance of the critical resistors has been increased to 0.1%, which is more possible and cheaper now that I’ve switched to SMD parts. Hand assembly would take longer this way, but I can also just put down solder paste and stick the whole thing on my reflow skillet.

The boards and parts have been ordered, so here is a rendering done with eagleUp and Google SketchUp and a screenshot from Eagle.

Board layout and schematic. Available on GitHub

Render done using eagleUp and Google SketchUp

tinyCopter Updates

I finally got the revision C control boards in the mail, along with a Ponoko order for some lasercut acrylic. I won’t go into detail over the new boards, because I did that in a previous post, but the new ones have USB for debugging and uploading new programs from Xmegaduino.That was the goal, at least. I figured that the RTS line on the FT232 would be used as reset, like normal. This is not the case, however. The DTR line is. Oh well. Luckily, I can use my AVRISPmkII clone to upload programs just as easily. There is also one other issue, and that is that I used some 0402 resistors accidentally. You can see in the first picture by the headers that I had to improvise with some 0603’s.

The acrylic plates that I got from Ponoko are great. They don’t serve any real purpose, but I figured that it would look cool and protect the control board from flying debris in the event of a crash. To get the shape exactly the same as the PCB, I exported only the dimension layer in EAGLE, brought it into SolidWorks to clean it up and create a .dxf file that Inkscape would like, and imported into it the template from Ponoko.

I’m also (finally) starting to work on modifying the AeroQuad code for use on my Xmega. For someone new to actual AVR programming (setting up registers and bit-level operations), work is going slowly, but I’m getting there. I hope to be flying in a week or two.

I was also on Adafruit’s weekly show-and-tell. You can watch the video here.

Revision C Updates

Along with any revision comes along changes, and this one is no different. First off, let me start off by saying that I am not abandoning the MPU-6050. It is a excellent chip, but it is not all-powerful. I am moving to a more traditional setup with this revision, with a separate accelerometer, gyroscope, and magnetometer. The accelerometer will be an ADXL345 from Analog Devices, the gyroscope will be the venerable ITG-3200 from InvenSense, and the magnetometer will be the HMC5883 from Honeywell. The reason for the switch to this setup is because of the lack of examples for the MPU-6050, and because I found out about the AeroQuad project.

The Xmega is also getting downsized. I finally came to the conclusion that I don’t need ALL of the pins on an A3, so an A4 will be replacing it. This is both to help reduce the size of the board, and to become compatible with the Akafuino X, an Arduino compatible powered by an Xmega A4. Also, just for kicks, I am going to overclock it. I’ve heard of people going as high as 80MHz with the Xmega, so I might as well give it a try. The specific one that I plan on using is the version with USB capability, but I will just use a FT232 for communication.

There will also be multiple ways to power the board. All options go through an AP1117 3.3V regulator, but now there is more than one way to get there. The main input is through a standard JST connector. The secondary input comes from the BEC circuit on one of the motor ESC’s. The third option isn’t useful during flight, but is there anyway, and that is through USB.

So, quite a big turn in the project at this point, but I think these changes will be for the best. I (and many of my friends) want to see this thing fly, and fly well. Development will continue on Rev B, as I want to get that MPU-6050 up in the air.

This thing is looking to be quite a dense bugger.

tinyCopter Updates

Whoops! This was supposed to be posted almost a week ago! Ah well…

So, time for some updates on tinyCopter. I finally ordered propellers! The ones I got are GWS 3-blade 7×3.5 in both normal and reverse rotation. I ordered them from RC Dude Hobbies, and they shipped all the way from Nevada to Michigan in just 2 days! And that was standard shipping! I am really happy with their service, and will order from them in the future.

Once I got the props installed on the motors, I fired one up, using my Arduino to generate the servo signals. I had the copter in my vice, so I loosened it up and upped the throttle. The end started to pull upward, indicating that with all four motors going, there will be plenty of lift.

You can also see in the picture a purple PCB next to the battery. That is a 2 cell LiPo charger based on the LT3652 from Linear. I have it set to the full 2 amp charging current it supports, and my 1300mAH battery says it is rated for a 5C charging current – which seems quite high if you ask me – so I should be good to go there. Still, I might charge it outside the first couple of times, just to be extra safe. You can find the files for it up on GitHub.

Revision C Design

I’ve started to work on revision C of the tinyCopter control board. There are a couple changes that I’m making, so I’ll go over those.

First, I moved the GPS module out from under the xmega. This way I shouldn’t have to deal with interference issues. Since I had trouble with my on-board power supply, I replaced the TPS61200 boost converter with an AP1117 3.3V linear regulator. I also added two LED’s to be used for status indicators. I’m also shrinking the main part of the board to reduce weight a little.

Re-routing the board for revision C. The board shape is also different.

Some tinyCopter Pictures

I figured I’d take some pictures of tinyCopter so that you people can see what I’m actually building (these are on Flickr, so you could just add me as a contact there and see all of my cool pictures).

There. As you can see, the frame is made from aluminum u-channel. I am using Turnigy 1811 2000Kv motors because they were inexpensive, but I probably should have bought more powerful ones. By my estimates, these should hover tinyCopter at anywhere between 30 and 60 percent throttle. I recently (as in today) just bought some HobbyKing brand 6 amp ESC’s and a Turnigy 1300 mAh 2S battery. I’ve also built a 6 DOF IMU board just in case I can’t get the MPU-6050 working.

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.