loading
Unless you've been living under a digital rock for the last few years, or just simply aren't interested in flashing lights, you'll already know about the awesomeness that is the BlinkM from ThingM. It's a very small PCB featuring a high power LED that responds very easily and cleanly to commands you give it. Devices like BlinkM's are often referred to as LED Pixels, because they can be linked together in fairly long chains, but still remain individually addressable (you can set the colour of each one to be different).

Right now, I'd like to give out mad props to ThingM and todbot, without whom there would be no BlinkM, and the world (or at least youtube) would be a much less colourful place. The aim of this instructable is not to take business away from ThingM, in almost all cases I would encourage you to buy a blinkM or two if you need them in your project, but there are some reasons why it's good to have alternatives and these are the ones I'm thinking of:
  • You need a lot of BlinkM's and can't afford to buy as many as you might need
  • You have all the bits needed lying around, and loads of free time and solder to make them
  • You like a bit of a challenge.
  • The form factor of the BlinkM doesn't meet your projects requirements (ThingM also do a variant called the MinM)
  • You are _really_ hung up about open source and want to stick it to the man.
For me, this project came about because of the first three in the above list. I needed 7 pixels, which is a few more blinkM's than my budget can stretch too, I had a bunch of parts already lying around and lot of spare solder (although the free time bit is always an issue) and yes, I'm a sucker for the impractical.  "Why buy something when you can spend hours and hours of your precious free time trying to work out how it's done and failing multiple times before finally suceeding, sort of, and ending up with something that is nearly, but not quite as good as you can buy."  I probably need to readjust my priorities in life.


So, The aims of this instructable will be to:
  • Introduce the reader to CYZ_RGB, an open source RGB Pixel firmware based on BlinkM
  • Show how to program the firmware onto a suitable Microcontroler
  • Suggest a way for building the pixel, that doesn't use Proto or PCB boards
  • Show how to use the Pixel.
From now on I'm going to stop using the name BlinkM to describe the product of this instructable, it's just not fair to ThingM. What I'm building isn't as good as a BlinkM, and I don't want people to think that the BlinkM is less awesome than it actually is, but it's been useful as an introduction because everyone is so familiar with the concept. From now on, I'm in the Ghetto Pixel building business.

Lets get started, gather your stuff.

Step 1: What You Are Going to Need...

The key components for a Ghetto pixel are an LED, a Microcontroller, and some current limiting resistors.  It doesn't get much more complicated than that.  I'm going to refer to the Microcontroller as a 'uC' from now on and if I talk about "the LED" I am probably referring to an RGB led.

The parts list (BoM) for one Ghetto pixel looks like:
  • 1x RGB LED (RapidOnline or ebay)
  • 1x Atmel ATTiny45 (or tiny 44 or 85, )  (RapidOnline  or ebay )
  • 3x Resistors as per specifications of your LED data sheet (RadioShack / Maplin / Rapid / or similar to these [ebay]) probably 1/2 watt or less if you can find them.  SMD if you are PRO ;)
  • Some wire to connect the Pixel to your controller, and to string pixels together if you have more than one

Notes on the parts:

LED
I would recommend getting an RGB led in a single plastic housing.  It would be possible to do this with three separate LEDs, but it would be more of a challenge to mix the colours well.  You must avoid the RGB led's that you buy on ebay that are described as 'Slow Flash', 'Fast Flash', or 'Fade' as these have there own uC's built in, and while pretty, allow us no control over the colour.  You can get 'manual control' RGB LED's that look like traditional 5mm domed LEDS, but with 4 or 6 legs, but these don't tend to be very bright.  I would recommend getting LED's that are labled 'SuperFlux' or 'Piranha'.  These are small square RGB LED's with four pins, and can be surprisingly bright for their size.
You also have a choice to make on Common Anode, or Common Cathode variants.  All four pin RGB LEDs are made up of three individual 'dies' all in the same plastic housing, each 'die' gives off one colour, either Red, Green or Blue. Each 'die' has a positive (anode) and negative (cathode) supply. A common Anode LED has all three anodes linked together, and the three cathodes are separate.  A Common Cathode LED has the opposite configuration, All three Cathode are linked together and the anode's are separate.  The firmware that we are going to be using makes use of Common Cathode LED's, and it's probably best that you use those.  However, I had a pile of superflux Common Anode LEDs, so I've modified the CYZ_RGB firmware to use common anode.  I'll talk about this later, but i've only compiled and tested this modification on a ATTiny45 uC, so if you are planning on using any other uC I'd push you towards common Cathode LEDs.

Phew!  Are you still with me?

Microcontroler (uC)
The uC is the brains behind the Pixel.  We tell it what colour we want, and it controls the LED. For this project, I'm going to suggest you use the Atmel ATTiny45, because that's what I used, and it's fairly easy to get hold of.  The CYZ_RGB project also supports the ATTiny 44 and 85, and other 4k+ uC's in the ATTiny range might work, It depends on how much time you want to put in modifying the code. I was lucky, I found the ATtiny45 on sale at Rapid Electronics (in the UK) for 90p each (about $1.50 US) so snapped up 10. 

Resistors
The resistors are used to limit the current that passes through each 'die' of the RGB LED.  When you buy the LED's you should get a datasheet that shows various details on the electrical characteristics of the LED, such as the forward voltage and current for each colour.  You will need to put these into a LED resistor calculator along with the supply voltage (I would recommend 5v, but it depends on your application). The results will probably end up around the 100 Ohm region, with the value for the red LED being a bit higher.  At this point I'd like everyone who knows anything at all about electronics to move onto the next section while I talk for a second about how I do things. Please don't shoot me for what i'm about to say.

LEDs and uC's are cheep.  You are going to blowup/melt/fry a few of them.  So buy extra.  I've never been SuperMathsMan and I don't have a lot of patience when it comes to numbers, I tend to design circuits by trial and error.  A current limiting resistor on an LED is there to stop the LED sucking so much current that it melts itself and/or the pin of the uC it's connected to.  But it's a balancing act, if you use a resistor that is too high in value, your LED is going to be dimmer than it could be, because you are preventing enough current getting to it and If you use a resistor that is too low in value, your LED might be really bright, but it will burn it's self out and probably take the uC with it.  Start of with what ever the LED calculator tells you to use, and then see if using a slightly less resistive resistor makes the LED brighter.   leave the LED on for a while with the lower value resistor in, and touch the uC with the back of your hand or the top of a finger to see if it's getting hot, if it is, use a higher value resistor. If stuff melts or you let the smoke out, then smile and recognise that you've found the lower limits of the resistor you can use. It's all part of the fun.


Well done for making it this far, but unfortunately, it's not quite over, there are some tools you are going to need.
  • Breadboard and breadboard wire
  • Arduino  - See note below.
  • (Optional) Programmer for flashing hex files onto the uC (I use this one from Adafruit
  • Soldering Iron (a good one), Solder, tip cleaner, solder sucker, wick etc...
  • Helping hands, or desk clamp thingy
  • Good Lighting
A note on the Arduino.

You are going to need an Arduino for a couple of different things. It's main job will be to control the chain of pixels you are going to build (why stop building at one?) but it can now also be used to flash firmware onto the chips using ArduinoISP, replacing the need for a dedicated chip programmer.  I don't use ArduinoISP, and it does sound like it's got a few issues it needs to work out before it's allowed to wear the awesome badge.  I don't think it works yet with the Arduino Uno, and if you have an arduino that uses a Mega328 chip, you need to use a resistor to change the auto reset function. However it's a good option if you don't have a programmer.

Lets move on.. It's time to program some chips!

Step 2: The Code - Project CYZ_RGB (no, I Don't Know What It Means Either)

The first thing we've got to do on the way to creating our Ghetto pixel, is to give our little computer (the ATTiny45 uC) some instructions.  This is called 'Firmware' and you load it onto the chip using a programmer. Hang in there, I explain all in a minute.  First I've got to make an introduction. You see, I'm not nearly clever enough to do any real embedded systems programming, so I'd like to introduce you to a project that (er?) is... CYZ_RGB.  Started by Matteo Caprari and more recently extended by John Laur, CYZ_RGB is a fairly direct replacement for the official BlinkM firmware. Of course, you don't have to run it on official blinkM hardware, you can load it onto any compatible uC and connect up a LED. 

If you head over to the CYZ_RGB google code page, you'll be able to download the firmware from the project. There are two different configurations, Master and Slave, I'm not even sure if Master works, or what it does, I use the slave builds which are fine for my needs, with one exception!

I think it is assumed that you will be running CYZ_RGB on the official BlinkM hardware, or some kind of direct clone of it, and therefore the code is written to support Common Cathode RGB LEDs (which BlinkM's use). I have a surplus of Common Anode RGB LEDs, so I had to make a small change to the code to support this.

If you care: in the cyz/io.h file, where the bits are set to turn on, or off specific ports, I've swapped the bit assignment.  When a colour comes on in the code, the pin goes low, so that it can sink current from the common anode.

I've included my common anode Hex file below, in case it's useful. Other than the change above, it's identical to the latest build of the slave config on the google code page.

Now you have the .hex file that you are going to burn onto your uC, so lets talk about programmers and programming.  There are many great instructables on the subject, but my favourite and the one that got me started with AVR's is this one, The Ghetto Development Environment. I use the same programmer, the USBtinyISP from Adafruit, and it's awesome.  I started out with a home made target board (cradle) but have now bought a tiny25/45/85 programmer board from TinkerStore, which is just made of awesome. You would be fine with a home made cradle, or just programming in a breadboard.

Follow the instructions on the Ghetto Development Environment for loading code onto the chips, but note that you are using an  ATtiny45, so your avrdude command needs to reflect that part (t45).  Obviously, you also specify the name of the CYZ_RGB .hex file that you are using too.

You should also be aware of fuses. These are settings in the chips that change how they behave. I use a piece of (windows) software called Burn-O-Mat from AVR8 to check my fuse settings (you can also use it as a GUI for avrdude).  It seems that from the factory, my Tiny45's have the "Clock Divide by Eight" fuse already set, this needs to be unset for the chip to run fast enough for smooth fades.  One chip i was using also had the ability to store data in EEPROM disabled, so I had to toggle that fuse to (you probably won't need to do that)

Now you've read the GDE instructable, the following line...

avrdude -c usbtiny -p t45-U flash:w:cyzrgb_slave_CA.hex

...shouldn't freak you out.  If you are a real keenie, you've probably all ready done it, If not, go ahead and program your chip now.

Assuming there are no errors in the output, you should be good to go.

While we are in the programming mood, you should grab your Arduino as we've got to load a sketch onto that too. The Arduino is going to be used to control the Ghetto Pixels, and forms a bridge between them and your computer. To start with, we can use the BlinkM communicator sketch for testing, but in time you'll probably want to write your own more suited to your application.  The BlinkM communicator sketch is here, and you should load it onto your Arduino now. While you are on the BlinkM site, download the multitrack sequencer, you'll need that for testing too. 

With your freshly programmed Chip and your Arduino by your side, it's time to get it on with Das Blinkenlights!...





Step 3: Bread and Butter

If you were paying attention in the last step, you may have got a clue from the photo there, about what we are now going to build. Grab yourself a bread board, and wedge your freshly programmed Tiny45 in the middle of it, straddling the divide.

Next, get your LED and give it's underside a good close looking at, with a magnifying glass if you need to. Inside the clear plastic, one of the four pins is wired up differently to the other three. (see the photo) This is your common pin (i'm assuming, like me, you are using common anode LEDs). Make a note of this pin, don't loose it.  Push the LED into the bread board, at an angle of about 45 degrees, this allows each pin of the LED to sit in a different track on the bread board. Now remove the LED again, because you've forgotten which pin is the common,  find it, and push it back in again.

Grab the Tiny45 datasheet, or specifically this image, and with a bit of wire, connect the Common Anode pin to the same track of the breadboard that the t45's Vcc pin is sitting in.

Next, use the your resistors to connect the other three pins of the LED to ports PB1, PB3 and PB4 of the chip.

Now Grab your Arduino, and connect the 5V and Gnd to the chip's Vcc and Gnd tracks. This provides power for your Pixels. Next, connect PB0 on the chip to the Arduino's Analogue port 4, and PB2 to the Arduino's Analogue port 5.  This is the I2C connections, the data bus down which instructions are sent to the pixels

Use the photos I've included as reference.

Now that everything is wired up, you should connect the arduino to a USB supply, and let the power flow!  If it all goes well, you should see... er... nothing. perhaps a little flash from the LED as you power it up, but otherwise nothing at all. Don't panic, we should be all right.

Load up the BlinkM sequencer you downloaded in the last step, and in the file menu, select "connect to arduino".  It will ask you what COM port, and you should enter whatever the arduino is on (help!).  When the status text in the very bottom right of the sequencer window tells you it's connected, hit any colour on the swatch panel.  Bask in the light of your own creation, as the LED glows forth.  Or not.  If it doesn't ( and it should) there is something wrong. Check these things:
  • You have the I2C lines plugged in the right way round.
  • Check the Fuses on the ATtiny45.
  • Reflash the BlinkM communicator Sketch onto the arduino and then connect the sequencer to the arduino again.
  • You are using the right code for the right kind of LED? (Common Cathode, or Anode?) 
  • Check all your cables.
Every time I built a new pixel and tested (admittedly, I've only built four so far) It didn't work.  But every time it didn't work it was because I'd either forgotten to unset the "Clock Div by 8" Fuse in the uC or I'd screwed up the wiring. (Once it was because I thought I'd been clever and made some mods to the BlinkM communicator sketch on the arduino.  Keep it fresh kids, use it right out of the tin until you know what you are doing.)

I'm going to assume that you've just spent five minutes cursing, quietly, and then suddenly low and behold the light shines on!

Awesomeness in the supreme! You have built a Ghetto Pixel!

Next up, lets look at making this a bit more permanent, grab your iron, we're going a solderin'...

Step 4: In Which We Try Not to Burn Our Fingers. Again.

You can choose any one of a million different ways to put a Ghetto pixel together, and I hope that you will. (keeping it on a Breadboard, Perfboard, PCB batch, DIY PCB, conductive thread, are all great options, please show us your builds in the comments!) However, if you need some inspiration, then this is how I built mine.

I knew from the start that what I really wanted to do was to mount the LED right on top of the Chip, but there are two problems with this. First, the legs of the LED don't line up with the Legs on the chip when you sit the LED on top, and Secondly, You need to put the resistors somewhere. Adding the resitors in, sort of solves the first problem because they can be used to extend the legs of the LED to reach the pins you need to connect too on the chip.  However, I had to be a bit careful with this, as I didn't want the LED 2cm above the chip, I wanted a close as I could get to make the whole package as small as it could be.

This meant some tight soldering, directly onto the legs of the Chip and the LED *gulp* these things don't like lots of heat! and what is worse, some heavy duty clipping of wires and legs so that only the barest amount of metal was left exposed.  If I had smaller resistors to hand, I would have used them, but I didn't and had to use some 1/2 watt whoppers.

You can sort of see the build process in the photos on this step.  I started with the LED in a "helping hands" croc clip. I bent one of the resistor's legs to 90o and soldered it as high as I could onto the LED leg, with the body of the resistor sticking out from the LED, not down. Once cooled, I clipped the leg of the LED off leaving only as much as I dared to in order to give the resistor enough mechanical strength to then be bent down so it can touch the pin of the uC.

This process was important because if the leg of the LED was left on, there is a chance that it could touch one of the pins of the uC, therefore bypassing the resistor.  Bad times. Clipping the legs off the LED was scary, but meant there was no risk of shorts.  Good times.

I found that there wasn't any really handy way of doing the resistor soldering, I had to hold the resistor in my fingers. Ouch, that sucker gets hot real quick. It's a constant reminder that no matter how hot your fingers are getting, the LED or uC is getting hotter, and you should use your Iron carefully and sparingly.

Once you have the 3 resistors soldered to the LED, and the LED pins have been shortened, put the Chip in the jaws of your vice and find the correct uC pins to solder the resistors onto. Do this carefully and more than once,  you need to be VERY sure you are soldering the right LED leg to the right uC pin.  Not taking enough care makes this into a very big and hot mess of solder and swearing.

Again, you should bend the legs of the resistors up and out (away) from the uC leg, so that they only just touch right at the base of the resistor and the top of the uC pin. YOU DO NOT WANT TO GET _ANY_ SOLDER ON THE THIN PART OF THE uC LEG (otherwise you won't get it to fit in a bread board or DIP socket again).

Get your pruning sheers out, and cut off the excess leg of the resistors so they are as trimmed as it is possible to be.   

Save one clipping of resistor leg, as you can use it to connect the common pin of the LED to the Vcc (or ground if you are rocking a common cathode) of the uC.  

stick your fingers in a cold glass of water. You are all done!

Stick the assembled Ghetto pixel back into the bread board, making sure you got it the right way round, and fire up the arduino, and sequencer, and let that lil'pixel glow.

If it doesn't work, then make sure:
  • You don't have any shorts, i.e. bits of metal touching other bits of metal that they shouldn't be.
  • You don't have any bad joints, i.e. bits of metal not touching bits of metal that they should be.
  • It's actually sitting in the breadboard properly. Now it has some solder on it, it's pretty difficult for it to actually make contact with the tracks inside the board.
I suppose if you've tried everything, then there is a chance that you've killed either the chip or the LED with heat, but I'm not the best dude in the world with the soldering iron and while i've burnt my fingers on this project, more times than I'll admit, I've not lost a component through heat yet. You could try reprogramming the uC with the LED still attached to see if it responds (should program normally), and you could try connecting a 3V coin cell between the pins of the LED (above the resistors) to see if that still works. I'll bet both are fine.

I'll (again) assume that you've got it working, I'm an optimist like that.

We could call it a day there, but I've got a couple of other things to show you.  Let's build it out!....

Step 5: A Joyous Multitude of Blinkenlights!


Of course, you don't need to limit yourself to only one Ghetto Pixel. The whole point of them is that you can sting a whole bunch of them together.  I have built four so far and would have built more, had this instructable not taken so much time to write!

You should still build and test each one in isolation, once you have as many as you need, then you can start playing with them all together.

First off, If you are still using the BlinkM communicator sketch on the arduino, you will need to comment out the line that resets the pixel's address every time the sketch is run.  The line is commented, and it's in the setup routine.

You need to change the address of the pixel away from it's default value of 0x09, and you can do this in the sequencer. Plug the first pixel in and set it's address to 0x01, then take it out and plug in the second, give that 0x02, etc. Give each pixel you've made it's own address.

Now you can begin to wire them all up together.  This requires nothing but wire, you simply connect up all the pins of the same type among all the pixels.  I built a harness with DIP sockets to do this, although you could solder directly onto the pins of the uC, or put them all in perfboard... whatever, it's up to you.  

Once linked, you can change the channel number on the left of the BlinkM sequence display for each track to control your pixels individually.  Of course, you can code your own programs to send either serial to the communicator sketch or a new sketch entirely that addresses the individual pixels.  (If you want to spend all your time playing with the cool BlinkM software tools, then you should be buying real blinkMs!)

I'm going to stop writing now and go and build more pixels.  I've got four so far and need another three. I'm building an multichannel extreme feedback device that illuminates a set of seven clear gem dice. After that I plan to build some more, try and get them solar powered, and string them up in the trees in my garden. I hope you all share your projects too! 

Happy making, and Shine on!

Jim
   


<p>So does this firmware work with all blinkM software BlinkMSequencer etc as i cant get anything working with the cyz firmware, whats the master firmware for? is that in place of communicator sketch?</p>
<p>You know ive been messing with electronics for years and never use resistors on my leds,never burned one out yet,honest i never use them,unless ime building a kit and there there ile use them but for breadboarding i never bother,i never use 5 v i use lipo wich is 4.20 most but thats enought people say but ive never melted any led,or blown an mcu and i conect them wrong way all the tme and my mcu still work,i must be just lucky lol</p>
Has anyone been able to upload a stand alone script to one of these ghetto pixels?
FYI : I've forked the original cyz_rgb project with a few fixes and extra functionality at https://bitbucket.org/Fanjita/cyz_rgb_fork.
Is it possible to run without an Arduno?
I could be wrong but I dont think the arduinoISP can be used to program a hex file. If it can then I have missed that :-)
Hello jimthree, <br> <br>I have been playing with this for the past 2 weeks... I have an attiny85 and im also using common anode but when I use the firmware that you have and also the one from CZY, it doesn't work. When I use the BlinkM flasher to burn... no problems and the works sequencer. I have no idea what im doing wrong. any insight? <br> <br>just attiny85 using avr burn-o-mate with the fuse off for the 8 divide. <br> <br>any information is helpful.
So, I've been eyeing this experiment for the past year, and this week, finally found enough free time to start playing. I'm not exactly having success quite yet, but I have the strange feeling I'm very close, and must be missing something. . . <br> <br>So I bought 20 of the ATTiny45, and some LED's. The LED's haven't come in yet, but the processors have. I thought I could start playing, using some LED's I had laying around. <br> <br>Okay, so after a little back and forth on the programming of the chip, I was able to get the Arduino as ISP working. I soldered a 8 PIN DIP to an Arduino Proto Board, and wired it up. I was able to flash it, and I had success. I disabled the CKDIV8 in the fuses. <br> <br>I hooked up the ATTiny45 to a breadboard, and then proceeded to wire it up. I loaded up the Arduino Sketch for the BlinkMCommunicator, and the Sequencer with no lights coming on. I crossed the Ground with each of the resistor legs to make sure I had power, and I did. <br> <br>So I dug into the sketch, and I was getting &quot;Looking for a BlinkM: No I2C devices found&quot; <br> <br>I loaded up the multi-track sequencer, and did a scan, and it didn't find any either. <br> <br>So, does this sound like an addressing issue? Anyone ran into this? Have any other ideas for me to check out? <br> <br>Thanks so much in advance. <br>
This is an awesome instructable, but I don't understand why you don't just use a WS2801 chip or similar, they are a fraction of the cost (About $0.10usd each) and they address themselves...There would be no need to burn each chip with firmware and an address..
As requested, here's a little demo of 7 pixels I have working. I would have had all 10 going but I ran out of resistors :( I just bought another 40 chips, so within a week or so I should have 50 pixels in all up and running (assuming none crap on me). I'll definitely post my final product when I'm done too! <br> <br>http://www.youtube.com/watch?v=IIGq40xvRec
Hey,<br>im using piranha common cathode LEDs, i can`t get it working :( <br>please help me <br>greets from germany.
No Problem! If you are using Common Cathode LED's then just use the original CYZ_RGB firmware from the downloads section of the website: http://code.google.com/p/codalyze/downloads/list<br><br>You don't need to use the firmware that I modified, because that's for the other type of LED's <br><br>Jim
what about the schematics ? still same ?<br>connect LED to PB 3/4/1 ? with resistors of course... cant get it workin :(<br><br>greets from germany!
Yea the schematics should be exactly the same. Have you checked that the LED is working? One thing I did when I was testing was to use individual LEDS and then you can bundle all the cathode's together to make a common cathode LED,. or all the anode's together for common anode. You really need to experiment with a breadboard. My guess is that if the LEDs you have are working, then the problem is going to (has to!) be programming the Chip. Make sure you know what you are doing with that. Tray and program a simple blinky light firmware on the chip. This might help: http://imakeprojects.com/Projects/avr-tutorial/<br><br>Jim
Hey,<br>AVR Studio 4 isn`t recognizing my USB tiny ISP.... what can i do ??? oO <br>if i flash the .hex via avrdude it gives me a &quot;success&quot; and a led lights up... <br>rgb led is connected to GND -- common cathode and the R, G,B with a resistor to PB 1/3/4<br><br>in BLinkM Sequencer, at scan I2C bus nothing is shown<br><br>help please!<br><br>greets from germany ^^
Sorry,<br>all working now :D Thanks a lot :D<br>but tell me, do i always have to connect ghettopixels--arduino--pc ??<br><br><br>greets
I'm having a similar issue with a common cathode LED except mine isn't even blinking when I connect it. I know i have the chip programmed correctly and fuses set, but I'm thinking it has to do with the common cathode wire, do you just have it hooked to ground? Maybe if you just told me what you did to finally get it working.
try giving the original CYZ_RGB firmware a spin, you don't need my firmware for CC leds. you can grab it from the downloads section of the website: http://code.google.com/p/codalyze/downloads/list<br><br>Jim
Yeah, I was using that one. I just finally got it working and wanted to post my findings. The current hex file must have the default address set to 0. So when starting the sequencer, you have to do this:<br><br>1. Open Edit &gt; Edit Channel IDs and change at least one channel #s to 0 (easiest to just do the top one). This will make one of the sequences on the main screen address 0 and now should be tied to your chip/LED. <br><br>2. If you want to change it, highlight channel 0 (the one you just set), select Tools &gt; Change BlinkM I2C Address, and enter the new address. The # along the left of the sequencer should change to.<br><br>3. If you go back to Edit Channel IDs, the LED should now glow the color of the channel ID in the list. If not...it's just a matter of continually trying to reset it. Some of them I had to close/open the sequencer, reconnect the Arduino, etc. but you'll eventually get it. The key though is to see if it glows the correct color when opening the Edit Channel ID menu.<br><br>Next I need to figure out how to run them from a single chip with pre-programmed sequences that I can control using like a push button switch to toggle through them! Any idea where I might find a tutorial on that? :)<br>
Oh, I also wanted to ask, do you know how to hook them up so that you can run a string of them at the same time? I know the Arduino can only supply about 40mA, which is technically probably not even enough for 1 RGB if you're doing bright white.<br><br>If doing common Annode, I would think you just connect that to an external power source, then tie in the ground to the ground on the arduino. But for common Cathode, I'm not sure how you'd do that.
Yes, you'll need to have something that translates the serial output from the PC into i2C for the pixels. An Arduino does this very well, but you may find it's possible to make a BareBones Arduino (http://bit.ly/nJd3Xx), or even some custom Attiny firmware(http://bit.ly/rmCf8x) that that does this job for you, rather than tying up and Arduino. <br><br>Post some pics of your builds!<br><br>Jim
Can you power them all from the Arduino or do we need to hook them up to another power source? I'm thinking of you want multiple pixels on at the same time. I think the Arduino Uno can only supply about 40mA.<br><br>If so, how would you hook it up?
Hi,<br><br>I'm trying to build one of these but I try to use it with my own arduino Sketch. I connect the RGB pins to pin 1,3,4 on my ATTINY45. But on Pin 3 and 4 the led simply blinks instead of fading on or of. On pin 1 the LED fades in and out like it should. If I have read the specs for the ATTINY45 correctly, only pin 0 and 1 support PWM. Is this the reason? But how does it work with this blinkm firmware then? They don't use PWM to fade the RGB leds in and out?<br><br>My source for my arduino sketch:<br>int redPin = 1; // Red LED, <br>int greenPin = 3; // Green LED, <br>int bluePin = 4; // Blue LED,<br><br>// Program variables<br>int redVal = 255; // Variables to store the values to send to the pins<br>int greenVal = 1; // Initial values are Red full, Green and Blue off<br>int blueVal = 1;<br>int i = 0; // Loop counter <br>int wait = 15; // 50ms (.05 second) delay; shorten for faster fades<br>int DEBUG = 0; // DEBUG counter; if set to 1, will write values back via serial<br><br>void setup()<br>{<br> pinMode(redPin, OUTPUT); // sets the pins as output<br> pinMode(greenPin, OUTPUT); <br> pinMode(bluePin, OUTPUT); <br> <br> <br>}<br><br>// Main program<br>void loop()<br>{<br> i += 1; // Increment counter<br> if (i &lt; 255) // First phase of fades<br> {<br> redVal -= 1; // Red down<br> greenVal += 1; // Green up<br> blueVal = 1; // Blue low<br> }<br> else if (i &lt; 509) // Second phase of fades<br> {<br> redVal = 1; // Red low<br> greenVal -= 1; // Green down<br> blueVal += 1; // Blue up<br> } <br> else if (i &lt; 763) // Third phase of fades<br> {<br> redVal += 1; // Red up<br> greenVal = 1; // Green lo2<br> blueVal -= 1; // Blue down<br> }<br> else // Re-set the counter, and start the fades again<br> {<br> i = 1;<br> } <br><br> // we do &quot;255-redVal&quot; instead of just &quot;redVal&quot; because the<br> // LEDs are hooked up to +5V instead of Gnd<br> analogWrite(redPin, 255 - redVal); // Write current values to LED pins<br> analogWrite(greenPin, 255 - greenVal); <br> analogWrite(bluePin, 255 - blueVal); <br><br> <br> delay(wait); // Pause for 'wait' milliseconds before resuming the loop<br>}
Hi there Mister A<br><br>So let me get this straight, you are using an arduino sketch compiled for the ATtiny45, probably using the core libs from the MIT group? That's very cool, I've been meaning to play with this for a while.<br><br>You are correct in both your points. Yes, the Attiny45 only has two PWM timers available, and yes the blinkM uses PWM to control all three colours.<br><br>The significant difference is that blinkM's and the CYZRGB code that we use here implement software PWM, rather than than using the hardware timers. (to be specific, I think they use the two hardware timers, and then the blue channel is done in software) . Read up on software PWM, that should give you some ideas.<br><br>Jim<br><br>
Hi,<br><br>I would just liek toknow if this could be applied in the same manner to a Luxeon III Star Led like this one: <br><br>http://www.seeedstudio.com/warehouse/index.php?main_page=product_info&amp;products_id=194.<br><br>i am kind of new to the whole electronics/led world and i've kind of hit a wall here.<br><br>im trying to get together an RGB LED preferably a luxeon or cree with super high light output and control the color sequences.<br><br>please advise,<br><br>Much appreciated.
Whooo there! Nope, i've not checked the link you sent, but i doubt it would work. The atTiny chip would not be able to provide enough current to power the Luxeon Led. You would need to get a &quot;led driver&quot; or make one yourself using transistors. It's beyond the scope of this instructable <br>Jim
Hi Scott. your breadboard looks fine to my eyes, but I can't verify that you have the -ve line from the tiny85 plugged into the cathode on the LED. You can tell the common pin from looking at the bits of metal inside the LED from underneath. don't rely on it being the corner with the flat edge.<br><br>The junk you are seeing in the serial monitor is almost certainly due to the eron baud rate. try changing the baud and seeing if you can get any sense out if it.<br><br>As you are using common cathode LED's your best bet would be to head over to the CYZRGB project and download their binaries, don't use mine. <br><br>Jim
Hi Jim,<br><br>Thanks. If by &quot;-ve line from the tiny85&quot; you mean PIN4 (GND) tied to the LED cathode, it's not. They're both tied to a common ground, but not each other.<br><br>And yes that's what you meant, I'm not sure exactly what you mean in terms of specifics... if I wire PIN4 to LED cathode, they'll connect but there won't be anywhere for GND to flow to.<br><br>Or maybe you meant something else by '-ve'?
no, you are right, by -ve I meant ground. as long as bit the LED cathode and tiny85's GND are tied to a common ground somewhere, you will be fine. I think you should work out what is going on in the serial monitor first, as we know there is def. some problem there. <br>Jim
OH you're KIDDING me, Arduino IDE.<br><br>The Arduino IDE defaults to 9600 baud. The ThinkM script initializes serial to 19200 baud. Apparently the Arduino IDE can't detect this, self-adjust, or warn and so the text is garbled.. once I set the serial monitor to 19.2 I can read the output fine. Hopefully this helps someone else.<br><br>The LED still isn't doing anything, but at least I can start debugging it. Maybe I missed a setup step at the end. Feeling better at least :-)<br><br><br>Thanks<br><br>
Hmm..<br><br>Serial console works perfect if I base a simple sketch around:<br> Serial.println(&quot;Hello World&quot;);<br><br>Let me ask this.. Are you using 0022 IDE?<br><br>I see in the BlinkMCommunicator sketch code, there have been past issues with it not working on a Arduino IDE release (there is a comment of 0012 incompatibility fixes in blinkM_funcs.h). It might be that again, or something else I just don't see.<br><br>
I took the suggestion to use common-cathode RGBs, and followed this tutorial, but I get no joy. Something's wrong obviously, but not sure what. Could a second set of eyes spot the problem?<br><br>The Arduino Uno has BlinkMCommunicator loaded. No errors uploading it. When I enable DEBUG in the sketch and open the serial console, each time I rese the Arduino it prints this junk: &not;&Ouml;„&Ouml;o&Egrave;g&divide;&atilde;&Atilde;O&thorn;<br><br>The ATtiny85 uses the type 85 firmware for CYZ_RGB. No errors when flashing it.<br><br> Arduino:<br>Analog IN A4 -&gt; ATtiny85 PB0/PIN 5<br>Analog IN A5 -&gt; ATtiny PB2/PIN 7<br>5V -&gt; ATtiny Vcc/PIN8<br>GND -&gt;ATtiny GND/PIN4<br><br> ATtiny85:<br>PB5/PIN1 -&gt; empty<br>PB3/PIN 2 -&gt; LED anode A<br>PB4/PIN3 -&gt; LED anode B<br>GND/PIN4 -&gt; Uno GND<br>PB0/PIN5 -&gt; Uno A4<br>PB1/PIN6 -&gt; LED anode C<br>PB2/PIN7 -&gt; Uno A5<br>VCC/PIN8 -&gt; Uno 5V<br><br>I saw in one comment that the schematic should be exactly the same if you use common anode or common cathode. So I did not change anything. <br><br>The LED is good.. if I move the 150ohm resistor to 5V, that color lights up. <br>At this point I can't tell if it's an issue with the controller on the Uno, my wiring, or an issue on the ATtiny.
Attached are some images (having trouble uploading them using Google Chrome.. second try..)<br>
Hey all,<br>i build 10 &quot;BLinkm clones&quot; aka Ghettopixels.<br>now i want to place them in my floor and i want to use cat5 cable to connect them... will this work ? i got about 15meters length...<br><br>Thanks for upcomming answers
Hi, first of all congratulations and thanks for such a great tutorial!!!<br><br>My question is regarding a PCB boards. i see on this link (http://sjalbers.nl/Atmel/BlinkM/BlinkM.htm) that he has his mounted on PCB's. Ques: has he made these him self? if so how?? i really want to make some of these..<br><br>thanks<br><br>
Nice. And you made h-a-d. :-)<br><br>I just ordered most of the parts I needed for this... going to start by cloning 10.<br><br><br>For folks that appreciate this, there was another clone attempt of BlinkM someone did recently. It too is a nice effort (and includes a batch of custom PCBs): http://sjalbers.nl/Atmel/BlinkM/BlinkM.htm<br><br>Blinky stuff == AWESOME
I should point out for readers - this article text does not specify if the ATTiny45 should be 10PU or 20PU model.<br><br>I expect the 10PU is all that is needed (and if you notice, the author's bit.ly links actually link the 10PU model).<br><br>However, Mouser charges much less for the 20PU model ($1.87) vs the 10PU model ($2.30). <br><br>There may be other differences between the 10PU and the 20PU, however I can not qualify that (read the spec sheet). <br><br>Would be interesting to hear from some readers who made this..<br><br>
Thanks Scottinnh!<br><br>Yes good point, I was using the 10PU version because they were on special offer at my supplier, The 20PU's would be just as good, and could even be a bit better. I too would love to hear from anyone who has got a comparison. <br><br>Jim
You are totaly correct! The glass wall project was a great inspiration for this project, and I used his build notes for reference. I certainly should have mentioned that in the instructable, thanks for linking it out.<br>Jim
great project. Couple of questions<br>!st how do I stop the flicker? some colors are solid and others flicker alot<br><br>I am using your firmware for the common anode and I finally got everything working alright. I am using the sequencer and everything works except when In upload to the blinkm. It doesnt seem to be holding the program. It just turns a solid color. Have you had this issue?<br><br>thanks<br>bryan
HI,<br><br>The flicker could be due to the 'Clock Div by 8' fuse being set, which would mean the chip is running 8 times slower than it could be. Read up on fuses and perhaps download something like AVR Burn-O-Mat to set the fuses using a GUI.<br><br>Yes, the firmware will only hold about the first 5 bars of a sequence generated with the BlinkM sequencer, but not the full sequence. If you want to use it in a stand-alone context, you'd probably be better of buying a proper blinkM. The guys who wrote the CYZ_RGB firmware sacrificed some (most) of the storage area for better colour interpolation <br><br>Jim
great work - very complete - and with that little extra most people need to be successful doing someone else's project.<br><br>Wonder if a large surface mount type resistors would make it a little more compact.
Yes. SMD resistors would be great, but I wasn't able to buy them in the small quantities I needed, and I'm not that hot with precision soldering ;)<br>
Would it be possible to skip the resistors completely and just rely on a small duty cycle and high enough PWM frequency to avoid flicker?
I've done this without resitors before, but only when powered by coincells (such as CR2032). It's all about the current. LEDs will allow as much current as they can to pass through them, they have no practical resistance of their own in effect, if you don't use resistors you are shorting out the uC's Pins. This isn't a problem with CoinCells because they have so much internal resistance, they can't 'release' enough current in one go to damage anything. It's a different story with USB which can source 100mA or even 500mA. Without resistors, you'd hurt something very quickly. <br><br>Keeping the duty cycle low, may help but you'd end up with LED's that weren't nearly as bright as if you'd used resistors. That said, I'd encourage you to experiment, it's likly that you will blow something up, but if you are quick, you can feel it getting too hot and cut the power first before you let the magic smoke out.
I really like your idea. I looked into a DIY ShiftBrite, but it seemed too difficult and didn't save much $$. Question: couldn't you turn the chips over to get the LEDs closer?
Yes I guess you could get the LED closer, but it would make it much more tricky to solder. I liked the idea of still being able to insert the chip into a breadbiard or socket despite having a big LED sat on top of it.<br>Jim
&quot;If stuff melts or you let the smoke out, then smile and recognise that you've found the lower limits of the resistor you can use. It's all part of the fun.&quot;<br><br>Or it was faulty, congratulations you are a destructive testing expert :)
Nice Project! Well done.<br><br>Jules
yes yes yes. <br>im going to be building these very soon.

About This Instructable

28,494views

97favorites

License:

More by jimthree:Ghetto Pixels - Building an open source BlinkM The Seismic Reflector Mini Greenhouse Irrigation System 
Add instructable to: