Posted on

Hacking a Reflow Oven

After spending the last three years building small circuits here and there and doing so using the skillet reflow method, I decided it was time to step up my game and bought one of those cheap, Chinese reflow ovens: a T-962.

T-962

Now, let me start off by saying that I knew what I was getting into. I’ve been reading the reviews on all three styles, the T-962, T-962A, and T-962C (apparently the Chinese don’t believe in having a ‘B’ version.) Just about every review would talk about the poor heat distribution as well as the poorly designed display. So I knew what to expect (or not to expect.) But it’s an oven, electronically controlled. This meant that I could also hack it and potentially fix some of its problems, or at the very least improve upon them.

After unpacking the thing and looking it over for any obvious signs of stress, the next step was to tear it open. One of the things everyone is complaining about is some horrible smell coming from the unit while it’s working. That smell got attributed to it having a layer of what appears to be masking tape on the outer insulation blanket. So I wanted to see if this unit also had it. Sure enough. Over the insulating blanket is a metal shield and then the electronics. Because the shield comes rather close, the manufacturer decided it was okay to use masking tape to cover a portion of the shield and therefore protect the electronics from touching and shorting out. The adhesive on this tape is what’s causing the horrible smell. After a few minutes of peeling it all off and replacing it with Kapton tape, I buttoned the thing back up and fired it up. Hey, it’s still working!

Of course the next step was to reflow something. And I had a few boards that I hadn’t done yet, so why not throw them into the fire. Looking through the pre-loaded profiles, “wave3” turned out to be the closest for the lead-free solder paste I’m using. After populating the boards, I placed them in and went for it. According to the display, a little under 8 minutes later, it was done. The boards came out and voila, done. I let them cool, connected my trusty Atmel AVRISP mkII and much to my satisfaction, there they were. They were properly read by Atmel Studio, I was able to set the fuses and even upload a test sketch and watched a 48-pixel LED strip come to life. Yay!

Considering the boards were a mere 21×10.5mm, it was obvious that wasn’t a “good enough” test. I decided to go for broke and populated one of my custom LED strips and tried reflowing those. Half way through the process I realized something’s wrong. Something’s definitely wrong. I waited till the cycle was done and pulled the board out:

LED Strip

After all that I’ve read about these ovens, this wasn’t a total surprise. The center LEDs are cooked. This clearly indicates a hotspot problem. And since the oven doesn’t have any way of circulating hot air, this is to be expected. I have also since discovered that while the profile was “okay” for the paste I’m using, it’s too high for the LEDs themselves. I need to lower the temperature by some 20-30 degrees!

On to hacking! After cooling, I tore the oven open again in preparation to perform a hack as explained by this awesome instructable. Basically it allows you to control the cooling fan that’s in the back of the oven and use it to get some air circulating while it’s going through a cycle. I had one burning question but I decided to just proceed with the hack. It’s not like it’s a permanent thing nor that I can’t disable it once it’s in place. So really I had nothing to lose.

First things first: every single possible screw and connector was covered with hot glue! What’s up with that? I understand the need to keep things from disconnecting but except for two connector, everything has a lock on them, whether it was a friction lock or actual latch. And of the two connectors that didn’t have them, one was a dual-row one for the LCD connected to a shrouded header. Friction alone will hold it in place. And the other was the connector for the panel buttons. With the ribbon cable as short as it was, it too wasn’t going anywhere. There’s no vibrations going on so it’s not like any of them could simply vibrate loose. So again, what’s the hell?? It took me a little over an hour to get the hot glue removed just enough to unscrew the board and to carefully pick and peel away more glue so I could remove the connectors. What a pain!

Once I finally got the board out, it was time to identify all the bits and pieces on it. I was surprised to find the “brains” to be an LPC2134 ARM micro controller. A bit of an overkill if you ask me. You can also see the shoddy craftsmanship, if you can call it that, on at least two of the components:

Since I haven’t done anything for an ARM micro controller yet … or ever, and seeing as I don’t have any tools to either write or hardware to upload code to one, I don’t think I’ll be doing any reprogramming on this. I will likely either buy a different controller, or roll my own. There are advantages to both. That’s a post in and by itself.

Anyway, now that I know what this thing has for brains, and studying the internals, I have a better idea of how this oven is put together and what makes it tick. After following the instructable I had the necessary connections made and wired up on an external AVR micro controller. I was ready to start messing with the fan!

20140712-003

After making a few cosmetic changes to the provided code and loading it onto the external microcontroller, I fired up the oven and waited to see what would happen. There was nothing in it and I just ran the same “wave3” profile. Oh dear! It could not reach its target temperature, no matter how hard it tried. By the time it reached reflow stage, the target temperature was somewhere around 220°C while the actual temperature was hovering around 185°C. The fan was sucking in too much cold air. Again, no surprise there. The hack is to gain control of the cooling fan. So it’s doing what it’s designed to do: cool the oven! The OP of that instructable talks about running the fan at a really low speed, just enough to get it spinning so you can get air circulating in the oven. But by doing so, it’s sucking in cold air from the outside. But I digress, I changed the settings and slowed the fan as much as I could without causing it to stall. After all it’s a heavy, all metal fan. It needs some umph to get going. After dialing in the numbers, I decided to plot the results:

20140713-Profile

(Heat ON/OFF, Fan ON/OFF, and PWM Fan ON/OFF are simple indicators of when they were ON or OFF)

Not pretty. It’s loads better than the original code which has the fan spinning even more, but still. It never reaches the target temperature during the reflow stage. It has a very slow ramp up and crazy overshoots every time the heating elements (and therefore the fan) would shut off. I needed to do more testing to figure out what would work. The circulating air needs to be of the same temperature as what’s already in the oven, not cold outside air. But I needed a baseline first. I made some changes to a custom profile and decided to run that. First as-is, without fan control. Then a second time with fan control and the intake vent open (sucking in cold air), and a third time with the vent covered up. Et voila, the charts:

The first one gave me what I was expecting, a “close enough” cycle, except no air circulation. The next one, also expected. It’s sucking in cold air causing all kinds of fluctuations and not reaching reflow stage. Then I ran the third setup and was pleasantly surprised. While the ramp up is still somewhat slow (which is probably because the vent wasn’t completely sealed), it still way better than the previous run. Even the cool down phase has less spikes on it. Or at least, less prominent. We’re getting somewhere!

Next step is to adjust the profile so it doesn’t take 12.5 minutes of real time, but the actual 8 that it’s supposed to. The display says 8 minutes, however it’s actually running much slower, a ratio of about 1:1.5, meaning 1 minutes of real time is more like 1:30 on the oven. I will blame the programming for that. Just watching the display you can tell it’s not running “on-time”. And since I don’t plan on reprogramming the thing from scratch, I will have to adjust the profile itself. That will cut down on the length of time spent in the reflow stage. Right now it’s spending 50-55 seconds above 212°C which for the LEDs is not good. It should be in the 30 seconds range.

There are other issues, like the LCD not properly getting cleared when characters move. There are left over pixels that aren’t cleared. And the panel “buttons” don’t register properly. Sometimes you have to hold them down for 2 or more seconds for them to register. A ready-made replacement controller will run roughly the same price as the oven but the advantage is that I can have it now. Rolling my own means I can custom make it, but that will take time …

So there’s the first adventure. On to the next …

Posted on

FastLED & ATtiny85

Disclaimer: There are numerous ways of programming any one of the many AVR families of ICs, including custom programmers made by many vendors as well as using another Arduino in ISP mode. What I will talk about here is how to use Atmel tools in conjunction with the Arduino IDE for programming an ATtiny85. This is not limited to just that specific AVR though. By installing different cores for the Arduino IDE, one can write code in the IDE, taking advantage of the various libraries available for it, and then use Atmel Studio to upload it to the AVR itself. A process that can also be achieved if one uses a regular Arduino in ISP mode. However, using Atmel Studio goes much further than that. Ultimately, one can write code in Atmel Studio for any one of the AVRs in the entire family of AVRs, something the Arduino IDE can not do. This is just scratching the surface of what one can do with Atmel Studio.

This will be a long post. You’ve been warned.

With the recent release of FastLED (formerly known as FastSPI_LED), support for Adafruit’s Trinket hardware was added. The Trinket runs on an ATtiny85 which is a small, 8-pin PDIP package, or even smaller MLF package (4mm x 4mm.) Ideal for those small projects where you don’t need a massive ATmega to run just a few random patterns on an LED string. Olimex has a similar product called the OLIMEX-85. While I don’t have a problem with either products, they’re both excellent platforms, I do tend to work with bare ICs in my designs. In this case, I could’ve wired one up with a USB connector and installed the bootloader and all, but not having one handy, I choose the “other path” which is what I will describe below. The end result is that you will end up with a programmed ATtiny85 without it needing a USB connection nor the bootloader, which takes up space anyway. The ATtiny85 only has 8K worth of Flash memory.

Let’s start with what I have available to me, and where you can get them should you want to do the same thing:

  • First things first, I work on a Windows 7 64-bit machine. If you’re on something else, you’re going to have to figure out a couple of things for yourself, though the overall process should be relatively the same.
  • Bare ATtiny85 PDIP ICs: Mouser: http://goo.gl/aLcxLB – Digi-Key: http://goo.gl/iRiRQm. I use the ATtiny85V because it can run on a lower voltage than its counterpart. You’ll also notice it’s a little bit more expensive. If you don’t need to run it on very low voltage, you can get the cheaper one.
  • AVRISP mkII: Mouser: http://goo.gl/okQJns – Digi-Key: http://goo.gl/dIqNNs. I discovered that my Olimex AVRISP500 does not support ATtinys, so I had to get the AVRISP mkII since I wanted to work with some of the AVRs from the tiny family.
  • Atmel Studio 6.1: Free download from Atmel’s web site: http://goo.gl/ZYD6e. Yes, it’s a free download. You’ll have to register with Atmel’s web site before you can download it, but that also gives you access to free samples, should you want to request some.
  • Arduino IDE 1.0.x: Free download from the Arduino web site: http://goo.gl/F3iH. Somewhat of a given … Do yourself a favor and stick with the 1.0.x version.

And then the usual bits and pieces, a single 10K Ohms resistor, a single 0.1uF decoupling capacitor for the IC itself and I always use a big 1000uF capacitor for the LED strip I’m going to use, a breadboard, jumper wires, the LED strip itself which in my case is a 48 pixels per meter LPD8806 strip. Lastly you’ll need a 5V source and I use an old computer power supply for that. It outputs 30A on the 5V rail so that’s plenty to run a few meters of strip (500 pixels max, with no room for anything else.)

Since we know that FastLED will work with the Trinket, we need to grab the core files for the Trinket; the Arduino IDE does not have them. There are two ways of doing this and Adafruit would tell you ‘the fast way or the slow way‘. Since I have several other core files, I didn’t want to take Adafruit’s easy way, I didn’t want to end up with yet another copy of the IDE. But you certainly can. Either way, the instructions are all posted with the appropriate links to the various downloads. (http://goo.gl/4idT0F) As of today, 01/25/2014, there’s an error on the page regarding the installation of the linker file. It needs to go inside of the hardware\tools\avr\avr\bin folder – notice ‘avr’ listed twice in that path! I already sent them a note about it. Assuming you followed the instructions, you now have the core files for the Trinket installed in your Arduino IDE.

Now comes the fun part. The way you wire up the IC is very straight forward. You can follow its datasheet from Atmel’s web site. NOTE: I always save local copies of the datasheets so I don’t have to constantly go back to the manufacturer’s web site to look it up.

ATtiny85 Hookup

Put an 0.1uF decoupling capacitor across VCC and GND and a 10K Ohms pull-up on the RESET line to avoid it from floating. The other pins that I labeled are the MOSI, MISO, and SCK pins which is what you are going to connect the AVRISP mkII programmer to. The programmer comes with a 6-pin ribbon cable and the layout of those pins are:

ISP Connector

You’re going to connect all six of those pins to the matching pins on the ATtiny85. I use jumper wires for this: plug one end into the respective hole on the plug, and plug the other end into the breadboard.

You MUST supply an external voltage to the AVR. The programmer does not do this. All it does is read the voltage being supplied. So make sure you do that otherwise you will run into errors later. NOTE: I always use the same exact color wires for the same signals, so SCK is always going to be green, RESET is always white, etc., etc. Easy to remember as I tend to leave them plugged in to the programmer’s plug, and when I’m building several bare ICs on breadboards, I leave the wires there too, so it’s just a matter of matching up colors.

Next step is to open the Arduino IDE and load up a test sketch, or write one. First thing you need to do is pick the proper board once the IDE is up. I choose the 16MHz version for this example:

Arduino IDE

 

Why would one pick the 16MHz versus the 8MHz? That has to do with voltage. Page 168 of the datasheets gives us the following speed vs voltage ramps:

Speed Ramp

 

What this tells us is, the faster you want it to work, the more voltage you need to apply. And since I know my external power supply is feeding 5V, I can safely push it to 16MHz, however if you are only going to be working with 3.3V or lower, then pick the 8MHz option.

Next, either open one of the FastLED examples, or just write something to test out a string. If you decide to use one of the examples, make sure you adjust it to your specific setup, your LED strip type and which GPIO pins you’re using. I choose to first try the Blink example but honestly, it’s kinda boring (nothing against Daniel Garcia nor Mark Kriegsman.) So I quickly wrote a color cycle for the full strip:

#include "FastLED.h"

#define NUM_LEDS 48
#define DATA_PIN 0
#define CLOCK_PIN 2

CRGB leds[NUM_LEDS];

void setup()
  {
    FastLED.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, BRG>(leds, NUM_LEDS);
  }

void loop()
  {
    static uint8_t hue = 0;
    for (int px = NUM_LEDS - 1; px > 0; px--)
      {
        leds[px] = leds[px - 1];
      }
    leds[0] = CHSV(hue++, 255, 255);
    FastLED.show();
    delay(10);
  }

As you can see, I have the DATA_PIN defined as pin 0 and the CLOCK_PIN defined as 2. Frankly, they can be any of the GPIO pins, but I choose those two because they coincide with the ATtiny85’s MOSI and SCK pins. And the pin numbering comes from the way Adafruit created the core for this specific AVR. You can read more about the GPIO pins on their web site. (http://goo.gl/rT2yPP)

Once you have your code in, whether it’s a library example, or you wrote your own, click on the Compile icon in the IDE. Do not click on the Upload icon as that will try to upload code to a non-existing Trinket. All you want to do here is compile the code, nothing else. First to make sure there are no errors in your program and second because you need the final HEX file that it generates. We’re not using the Arduino IDE to upload to the ATtiny85.

Next step is opening Atmel Studio 6.1 (hereafter referred to as AS6.1). If you’ve never used it before, it may seem kinda daunting to look at the welcome screen. All we care about is it’s Device Programming method for now. Click on Tools and select Device Programming. A new window should pop up. Make sure you have your AVRISP mkII already plugged in to a USB port (you may have had to go through a driver installation process when you did that, I don’t remember.) If your programmer is not plugged in, the window will be devoid of information, the drop down will be empty and there’s nothing for you to do. If your programmer is plugged in, you’ll be able to see all the AVRs listed under the drop down menu. Under Tool, make sure you’ve selected the AVRISP mkII if it’s not already selected for you. Under Device, select the ATtiny85, and under Interface, pick ISP and hit the Apply button. It should now refresh the lower part of the window with more options:

Device-Programming

To the right of those options, you should click on the Read button to verify the programmer can actually read the AVR. At this point, if there’s a problem, it will give you an error message. Unfortunately, the error will simply tell you to check your wires. More often than not, that is the problem, your wires are reversed or just not connected correctly. Verify them and try reading again. If all is well, it will pop up both the Device Signature as well as the measured voltage. If for example you forgot to supply an external voltage to the AVR, you’ll get an error message telling you that the measured voltage is outside of the 0V-5.5V range required. You can probably guess how I know this … With everything working properly, the Device Signature should read 0x1E930B and the Target Voltage should be at or near the 5V that you’re supplying.

First, we need to set the correct fuses. Remember where you installed the Adafruit core files for the Trinket? Go back to that folder and find the boards.txt file. In my case, they reside in hardware\trinket\ because I renamed the folder. If you didn’t, it should be under hardware\attiny\ instead. Inside of that folder, you should find a boards.txt file. Open it. NOTE: Opening this file in Notepad won’t work because of the way the file gets translated. I recommend using Wordpad instead.

You’ll notice three distinct blocks of text in the file: gemma, trinket3, and trinket5. We’re only working with the Trinket here, and since I specifically picked the 16MHz version in the IDE, I’ll focus on the trinket5 block of text. Obviously if you picked the 8MHz version, you’ll be reading the trinket3 block of text. The lines of interest here are the fuses:

trinket5.bootloader.low_fuses=0xF1
trinket5.bootloader.high_fuses=0xD5
trinket5.bootloader.extended_fuses=0xFE

You’ll need those values for the three sets of fuses. Back in AS6.1, in the Device Programming window, on the left hand side, click on the Fuses option. Ignore the check boxes, just enter the values on the bottom half of the screen, matching what the boards.txt file told you, hit the Program button and watch the output:

Device-Programming-02

Hopefully it will program the registers and you’ll get an OK back. Now move up to the Memories option. This is where we are finally going to upload the code that you compiled in the Arduino IDE earlier. Where it says Flash (8KB), below that there’s a blank field with a browse button at the far right. It just has three dots on it. Click on that. Now for a neat trick: when you’re working with the Arduino IDE, it will always compile files in the Windows environment temp folder, always. And it will always have some obscure name. So how do you find your compiled program? Easy, use a variable that’s defined within the Windows environment. When you click on the browse button, a standard browse window pops up. At the top, in the address bar, type the following ‘%temp%‘ (without the ‘s) and hit return. It should’ve refreshed the window straight into the Windows temp folder. Tadaa! Now, if you sort the right panel by date, the last Arduino build folder should pop up at the top:

temp

Sorry, I have to blur things out. You know, NSA and all. 🙂 Anyway, dive into that build folder and you should see a HEX file. If you didn’t save your sketch in the Arduino IDE, the file name will be the current date. For example, in my case it’s called sketch_jan25a.cpp.hex. Select that file and click Open (bottom of the window.) Now all that’s left to do is click on the Program button in AS6.1 Device Programming window and watch the output again:

Device-Programming-03

And if you didn’t get an error, congratulations, you just programmed the ATtiny85! Grab a glass of wine … OH WAIT, the actual LED strip! How to connect that?

Remember my code specifies the DATA_PIN as 0 and CLOCK_PIN as 2? Following Adafruit’s pinouts, that coincides with the MOSI and SCK pins on the ATtiny85. So, for my LPD8806, the data pin goes to pin 0 and the clock pin to pin 2 on the AVR. Connect VCC and GND to the strip. I also connect a 1000uF capacitor across the VCC and GND. You can go ahead and disconnect the programmer because you don’t need it to run anything, or you can leave it connected if you’re going to be actively developing and re-uploading code. At this point your strip should be doing a pretty color cycle, assuming you used the code I posted above. NOTE: If you left the programmer connected, maybe because you plan on coding some more, be aware that when you power cycle the ATtiny85, the programmer will cause a subsequent reset to follow. So while your sketch will almost instantly start running when power gets reapplied, the programmer will reset it about a second or so later. This is expected behaviour. Don’t get caught up in it thinking something’s wrong with your code. If you’re not sure, just disconnect it entirely from the circuit.

Congratulations! You did it! Sit back and enjoy that glass of wine.

Now, you may wonder, why go through all this trouble when you can just as easy buy a Trinket from Adafruit and use it with the USB connector. After all they’re pretty cheap at less than $8 plus a couple more for shipping. Well, that’s certainly a possibility. In my case, I design and build custom boards. I also like having all of the memory available as opposed to having the bootloader take up part of that. In a minimalist design, all I would need is the ATtiny85 (which I would use in either the SOIC or MLF packages), a decoupling capacitor and pull-up resistor and pads or mounting holes for the programmer. Adding a strip would mean adding a single 1000uF capacitor (some folks don’t bother with this either, your mileage may vary) and a row of mounting holes to go with it. Add a button and a power LED and that’s it! That’s a pretty tiny design, much smaller than the Trinket, 10mm x 23mm (at current design.) Especially since it’s specifically designed to drive an LED strip, I don’t need the additional breakout pins nor mounting holes that the Trinket offers. And I also don’t need the bootloader installed, which saves ~2.75K on memory.

So there you have it. Take it or leave it. This is by no means my final word. It’s simply another method of programming an ATtiny85 to work with FastLED. Should you do this or buy a Trinket? That’s 100% entirely up to you. If you don’t want to, or can’t do what I did here, then I would highly recommend you get a Trinket (or equivalent.) They’re really nice, robust, and will have more options available for you. Chances are I will get one myself just to play with and add to my collection. On the other hand, if you want to do some hardware tinkering, let me know how it goes for you!

Posted on

Remembering Things

In the process of cleaning up and organizing my office, which also functions as my development and coding area, I came across several bits and pieces of past and present projects.  Some of which I forgot what they are or why I made them, at least till I went back to the original schematic to try to decipher what I was doing.  A couple of things became obvious:

I need a way to keep track of what’s what.  This goes for the several dozens of PCBs I have.  All of them were for some project or another, some of which became reality, and others that didn’t.  Regardless of their state, I need to figure out a way to catalog them.  Who knows, some day I re-purpose them for something similar to the original project.

A lot has changed since the very first design I created, which was a strobe light unit for a quad copter I had planned on building but never actually did.  I have all of the PCBs, possibly even the components to actually build them.  They’re generic enough that all you’d need is apply a signal to toggle them on and off.  But, when I say ‘ a lot has changed’, I’m referring to how things, or mainly I, have progressed.  The simplicity in the circuit i would build then, versus the stuff I make now.  The lack of knowledge then compared to what I know now (which really is only a tiny bit more.)

I have a lot of components and parts!  This is partly due to me buying things in bulk because it’s cheaper.  Why buy 50 of something for $2 when you can buy 1,000 for $7?  Unfortunately that also means I don’t have enough storage or organizer boxes for them.  Most of my through hole parts are sorted into bins, but the SMD devices is a whole different game.  Part of the issue with them is the type of packaging they come in; normally a reel, or a long strip.  that’s not very conducive to storing in organizer bins.  And while I’ve seen those tiny bins specifically for SMD, I question the need to be separating the components from their strips to begin with.  I’m not convinced that’s the way to go.  I’d rather keep them the way they came, rolled up neatly.  So then the question becomes, ‘Why not store them as-is?’  That’s certainly an option, especially if I spend the time to re-roll them all to be about the same size.  Then I can fit them in a bin and call it done.  Now if I can find a bin that has thin slots, one for each reel/roll, that’d be awesome.  My guess though is that I won’t find one.  Too specific.

Oh well, back to the topic of remembering things:

  • Finish POV poi design!
  • Work on Xmas window lighting
  • R&D (flag) pole design
  • Strip lighting for track frames, to be used with acrylic sheets

There’s a few more, but these are the biggest ones for now …

Posted on

Long Overdue

Having been busy for the past several months, I’m just now able to refocus on all of my projects, including the POV Poi one that’s been sitting idling.  Every day I stare at the two batons, yearning for me to pick them up and do some work.  Alas, the time has finally come.

Unfortunately, while I haven’t been able to work on them for months, I have been able to toss around ideas with other folks and one thing became rather apparent: we are in dire need of a specific development board.  For me the whole problem is that for any kind of developing that I want to do, I need to have one of the batons connected to the computer as I work.  This gets annoying, having to rip them open every time, especially since they are also still in the R&D stage.  And recreating the circuitry on a breadboard each time is a pain, not to mention having to deal with a bunch of jumper wires, any one of which can get snagged and pulled out, causing testing to stop to figure out why all of a sudden things stopped working.

So I thought, why not make a permanent development board?  One based on the current hardware, plus the ability to add more later.  Things like an accelerometer, an RTC, card reader, Bluetooth, RF, battery charging circuit, a buck/boost circuit, etc., etc.  I’m sure over time more people will come up with more ideas.

With that in mind, I started working on the current hardware being used for my specific project, the POV poi batons.  What are all the items that are currently in them, and what remains to be added still:

  • Atmega 328p (change)
  • Li-Ion charging circuit (add)
  • Buck/Boost circuit (add)
  • Micro SD card reader
  • ADXL345 Accelerometer (add)
  • DS3231 RTC (add)

From there, others have suggested adding support for Bluetooth as well as RF, with the latter being the most requested right now.  Someone also asked for a pony but that just isn’t going to happen.

First thing I wanted to change was the micro controller: switch it out for an Atmega32U4 for its native USB capabilities.  However I soon discovered it doesn’t have enough interrupts for all of the peripherals.  While the Arduino bootloader supports five interrupts, four of those are on pins that are being used for communications such as Serial and I2C, leaving me with just one.  Both the ADXL345 as well as the DS3231 have interrupt capabilities.  So does the more common nRF24L01+ RF device.  While one can certainly use them without the interrupt, why limit the end-user?  All of a sudden, using the 32U4 became impossible.

Enter the new AT91SAM3X ARM series!  Those things are massive!  With all kinds of capabilities, including an interrupt on up to 103 IO lines.  103!!  It also has native USB capabilities, as well as USB OTG, meaning it can also act as a host to other USB devices.  This opens up all kinds of options.  Now I only need to convince myself that I can indeed work with these controllers, maybe build a breakout board first, see if I can even get that working correctly before moving on to a larger system.

Remember when in an earlier post I mentioned how ideas flow in my head?  Just as I started writing this post here, I came up with another thought: a multi processor development board.  Why have a development board that’s specific to one processor?  Why not make it so one could swap out processors and continue developing?  I know it’s possible, after all Atmel already did it: the STK600!  Taking a cue from that, I thought, “Why not build a development board where one can swap out the processor to whatever they’re using, or want to use?”  It would mean making a “motherboard” onto which you can plug in daughter boards with the processor of your choice.

Dear Brain,

Please stop thinking long enough for me to catch my breath.

Yours Truly.

Posted on

The Flow of Ideas

New ideas never stop lighting up my brain.  In an attempt to come up with some way to still have a functional POV Poi system when there is no SD card present, I thought why not program them in.  There are several poi systems that already do that: you get the ability to select different patterns, set different modes on each, and then run them as a sequence.  So, I came up with the following which I may still do on the current v1.0 release – after figuring out how or where I’m going to add the additional button:

  • single chase along the stick; option to set color, speed, and direction
  • multiple chase along the stick; option to set color, speed, direction, and how many pixels
  • single fading tail chase; option to set color, speed, and direction
  • flashing pixels; option to set color, and flash rate
  • simple shapes like squares, circles, star, triangles; option to set color, flash rate, filled or transparent
  • “Knight Rider” chase; option to set color and speed (this would create a wave pattern when spun)

As I keep thinking about it and once I start writing code, I may come up with additional patterns.  The idea is that if a unit does not have an SD card in it, it will automatically default to the build-in patterns.  When there is an SD card present, the unit will also allow the end-user to use the build-in patterns, either exclusively, or mixed in with the patterns on the SD card.

The build-in pattern sequences that the end-user create will be stored in EEPROM when the unit is running without an SD card, or the user can set the various options in the same control file that the SD card would use if present.  One example would be to do something similar to the following:

<img name>|<refresh rate>|<timeout>|<delay between images>
<pattern#>|<color>|<speed>|<direction>|<optional>
  • color can be one of the seven defaults, or an r,g,b decimal value from 0 to 255 for each
  • speed will be a value between 0 and 5 and will map to 0=25ms, followed by 50ms, 75ms, 100ms, and 150ms for refresh values
  • direction is simply -1 for backwards, 0 for stand still, and 1 for forward
  • the optional value will be used for those patterns that have a fourth value
  • The running code will have to determine whether what it’s going to display is a build-in pattern, or an image from the SD card.

Something else I ran into this past weekend as I was testing and demonstrating the prototype was data corruption after running for a while.  I’m not entirely sure it actually is data corruption, or whether the voltages are just too low for the drivers to latch the data.  So I’m going to push the voltage to 5V instead of running at 3.3V.  The MCU will still remain at 8MHz though.  And I am seriously considering keeping the output down to 1/8 power, or at the very least use a button to adjust the output.  Running at full brightness is just way too much.  Anyone attempting to take a picture will get it all washed out.  So I’m thinking the settings will be 32, 64, and 128.  Right now I’m running with a brightness of 32 and it’s plenty bright, even with moderate stage lights.  The only issue with lowering brightness is that you also lose the full color fidelity.  Meh!

Posted on

Code Freeze!

I’ve come to realize that I have too many ideas in my feeble little brain to add to this project.  However, I also realize that if I continue to develop and incorporate them, I will never get to a product I can call “final”.  So, as of today, I have frozen the current code.  It is what it is, and it will remain as such.  I will continue to work on what’s currently there, bug fixes, small improvements, however I won’t be adding anymore features.  Anything left on the list will remain there for the next revision.  There’s just too much to be working on right now and I continue to push the project further back because of that.  No more!

Freeze

So, with that said, here’s where the project stands:

  • Four strips of 48 full color LEDs arranged in a square tube shape, inside of a round polycarbonate tube.
  • Final tube length will be somewhere around 18″, though we are diligently working to make that shorter by an inch or two.
  • One Li-Ion battery to power the whole unit, which also includes a charging circuit for the battery.  Charging will be done via a USB connection.
  • The light stick can use full color images, stored on a micro SD card which is inserted into the stick.
  • Images will require pre-processing into a custom file for now, which is limiting this design from going into full production.  (Future development will switch to a standard BMP image format.)
  • A control file is used to arrange the images in the order in which they are to be displayed.
  • This control file will also allow the user to set the speed in which each image repeats, how long each image is displayed, and how long to wait before the next image is displayed.
  • A three-way switch will provide the unit a way to power just the control board for updating of the firmware, or both control board and LEDs for a running show.
  • A trigger button will allow the performer to turn the unit on but not have it display anything till the button it pressed.  The same button also stops the display and resets it back to the beginning of the control file.
  • A soft glowing LED will be the indicator of the unit being powered and waiting to start the display.
  • Upon first power up, the unit will display a red-to-green gradient chase indicating battery voltage.
  • During a show, if the battery voltage drops too much, the unit will simply stop displaying anything.  (Future development will allow the unit to lower its brightness and continue to run before ultimately cutting out completely.)
  • A swivel will allow the unit to rotate freely while being spun.
  • Future firmware upgrade is possible, as will minor hardware changes.

That’s it for now.  The rest has all been pushed to a next revision (or I’ve forgotten about it here.)

 

Posted on

Procrastination

Did some hardware shopping after practice today.  I’ve been trying to figure out how to attach things to the tubes and what not.  For now, I’ve settled for a simple bolt and nut arrangement with a plastic plug.  By drilling a hole through both the tube’s sidewall as well as through the plug, the bolt will hold both of them together and there’s no risk of the plug flying out.  The top bold has a small (fishing) swivel attached which protrudes through the plug.  This will then get attached to whatever chain I can find.  Looked around for that too but I wasn’t happy with what I found.  I don’t like open-ended chains, those where the ends are simply curled in, as opposed to welded in.  Over time they expand and when you’re spinning something, that can spell disaster.  I’ll have to go back to the hardware store and see what other options there is that’s small and doesn’t weight fourteen tons.  I still need to grind the protruding bolt and get it flush with the nut, but for now this’ll do.

After spending some time making a new video clip (in other words, procrastinating on doing other stuff), I decided to do some code fixes while the video was processing.  We now have the ability to control each image in terms of how fast the same image will loop and repeat, how long it will be displayed, and whether there is a pause before moving on to the next image.  Had to squash a bug while at it too!

Opted to use some more traditional images for testing.  These all came from the original PixelPoi source files, which also happens to be the design I’m improving on.

[click on each image for a larger popup]

Tomorrow is “hardware day”.  I’m going to try and focus all of my attention on the controller part so I can get that done and maybe send it off for manufacturing.

Posted on

Color Adjustments

After all the testing done so far, I decided to play with some image manipulation.  All images get shrunk down to 48 pixels tall from whatever size they originally are.  This poses a problem with sharpness.  So I spent the evening doing some testing with a little bit of re-sharpening of the image.  I say a little bit because any tiny change will be too much.  Ultimately I settled for some values that were just enough to get some details back.

The next step was lowering the image gamma.  With the LEDs being so bright, just about anything I put up was getting washed out.  Normally on a computer you’d set a gamma value of 1.2.  Here, I had to lower that to 0.4.  Big swing.  But, the results are much better:

[click on each image for a larger popup]

Posted on

To Do Lists

I used to be a “list” writer, do this, do that, remember this, get that … But then you ask, when is it too much? I know people who write lists about lists. That, to me is overkill. When you get to the point of needing a list just to keep track of your other lists, you’ve got a problem.

However, that doesn’t mean that having a list is a bad thing.  For me, it’s a way of keeping track of both ideas as well as what needs to be changed, added, or otherwise putz with.  Having said that, this is the current list of things:

  • Plan for a thicker PCB – Done, 7/31
  • Check height on LED – Done, 7/31
  • Move control board to wedge inside of LEDs boards – No longer pursuing this idea, 8/1
  • Add solder joints for VCC, GND, and control lines.  One in each corner? – Sort off, original idea won’t work, need to think of something else, 7/30
  • Add solder joints for control board to pass to LED boards – See above, 7/30
  • Move battery connection to other side of control board.  Order will be: battery, control board, LED boards
  • Check tube diameter with new arrangement of LED boards – Switching to 1″ tube, 7/31
  • Check a three tier setup; will require some way of inserting board with switch(es) protruding out and then wedging it into place, or
  • Consider adding a clear cap/plug that holds the PCB in place with the battery pressed against it – this will make access to the switch trickier
  • Add battery check with proper pull down and series resistor – Done, 8/1
  • Add brightness button
  • Separate VCC to LEDs from VCC to drivers, to allow drivers to be turned on with the switch, and LEDs with MOSFET after a short delay to prevent instant white when first turned on
  • Switch to 24bit BMP images – This is being pushed to a future revision.
  • Code extra control in control file:
    • Add individual image display length – Done, 8/4
    • Add individual image display speed (this can be calculated when image is created) – This will be calculated and put in the file.
    • Add ability to pause between images – Done, 8/4
    • Add loop refresh rate (how fast will an image loop back to the beginning of itself) – Done, 8/4
  • add ability to use folders on uSD card
    • add a 4-way switch so a user can navigate (Up, Up, Down, Down, Left, Right, Left, Right, B, A)
  • come up with a way to send music cues wireless and trigger changes, RF?  Bluetooth?  XBEE Wire mesh?
  • alternatively, come up with a way to change based on music cues written to the control file
    • This would require a way to get those cues from the music somehow – reading a wave form perhaps?
  • add a gyro/accelerometer for static images (way, way out in the future perhaps)
Posted on

Capture Time

I decided to cobble together one baton.  A couple of things were immediately obvious:

  1. It’s a bit of a pain trying to solder *inside* of a square tube
  2. Thin PCB warp too much
  3. Small pads coupled with thin traces tend to break or lift off of the PCB very easy
  4. Need to find a better way to interconnect the PCBs, both while daisy chaining, as well as sideways to its neighbor

Despite all of that, I did manage to attach the battery to the PCBs, and left it tethered to an external controller through a very long ribbon cable.  I don’t have the design for the actual controller done yet, so I had to use an external one.  This was actually advantageous.  Especially since I realized that I could easily go up to a 1″ diameter tube and still be okay.  I’ll have to rework the PCBs for the LEDs a bit, but that’s not a big issue, in fact it may be a bit cheaper in the long run.  But, more importantly, it gives me an additional 3mm to work with for the controller.  That may not seem like a lot, but 3mm translates to 118mils, which means I can place seven 8mils thick traces in that space.  That is important!

Other things that became apparent after I started playing with it:

  1. Need to reverse the placement of the battery and controller – this may be the solution to having wires connected to the LEDs
  2. Need to make changes to the code and put the image delays in the control file, not the image file itself *
  3. Taking video capture just doesn’t work as well as watching the real thing
  4. Taking pictures however, works beautifully. 🙂

20130730-001

This is what the video looks like, when captured at 30 frames per second.  It’s nowhere near as awesome as seeing it with your own eyes.

* Besides storing delays, there are other items on the list:

  1. Add proportion calculator for images of various widths
  2. Switch to a 24-bit BMP format instead of the arbitrary RGB storage engine used now
  3. Add the ability to have a (longer) delay between images