Close
0%
0%

192:LED

Extreme tiny (0,68'‘ x 0,68’‘ or 17mm x 17mm) smart RGB LED display/matrix

Similar projects worth following
What do you do with left over 0404 RGB LEDs? Well, I made this board. And also tested four Layer PCBs for the first time.

192:LED

The goal of this Project is to build a very tiny 8x8 RGB LED Matrix. This Matrix will be controlled by UART and/or i2c (not decided yet). Beside this there will be some "demo-Modes" for a standalone operation. The PCB for the LEDs and the firmware of the used Microcontroller are part of this project. There will be also documentation available about the the protocol used to control this Matrix.

[Image: Rendered project idea on a US quarter Dollar coin. made with sketchup]

For another of my projects ( #384:LED) I did order the wrong LEDs. So I do have now some of these tiny 0404 RGB LEDs left over:

These LEDs and my wish to design a four Layer board was the motivation to start this project. On the board there will be at least a microcontroller to control all LEDs and perhaps some other stuff to make it smarter.

Hardware

To control all 192 LED chips individually I use normal multiplexing. The Matrix is divided into 16 row with 16 (=3*4) columns. Both a directly connected to the Microcontroller (yes I know this is NOT the best way, but very space effective). There is also no current limiting for the LEDs so the on pulses are to be short.

As mentioned the Matrix is organize in 16 lines and 4 columns. The order of the columns are inverted for the lower half of the rows. In the following figure you can see how the physical 8x8 Matrix is mapped.

Organisation of pixels [ROW, COL]:
[0,0] [0,1] [0,2] [0,3] [ 8,3] [ 8,2] [ 8,1] [ 8,0] 
[1,0] [1,1] [1,2] [1,3] [ 9,3] [ 9,2] [ 9,1] [ 9,0] 
[2,0] [2,1] [2,2] [2,3] [10,3] [10,2] [10,1] [10,0] 
[3,0] [3,1] [3,2] [3,3] [11,3] [11,2] [11,1] [11,0]  
[4,0] [4,1] [4,2] [4,3] [12,3] [12,2] [12,1] [12,0] 
[5,0] [5,1] [5,2] [5,3] [13,3] [13,2] [13,1] [13,0]  
[6,0] [6,1] [6,2] [6,3] [14,3] [14,2] [14,1] [14,0]  
[7,0] [7,1] [7,2] [7,3] [15,3] [15,2] [15,1] [15,0]
This is looking a little Bit strange but made the layouting much easier (or maybe also possible).

Beside the Microcontroller and the LEDs there are not much more Parts:

  • A 2016 sized Crystal, which can be used if the the internal oscillator is too inaccurate or too slow. There are also two 0201 Capacitors for the Crystal.
  • three Buffer Capacitors for Vcc ( all 0402)
  • one solder bridge (R1) to disconnect MOSI for programming

Talking about programming: All pins needed for the ISP are break out on test pads. For programming R1 (more a solder bride than a resistor) needs to be open, other wise the Programming signals could drive some LEDs. This could disturb the programming. But with R1 open all programming signal are not connected to anything or just to a cathode of a LED.

PCB Design

The PCB is square with 677,5 mil or 17,2085mm edges. This makes the PCB fit nearly on a quarter US-Dollar coin as seen in the image at the top ( I will also make test with Euro-coins, but there were not available as models in Sketchup). The LEDS are in a 85 mil (~2,16 mm) grid. The dimension are measured in a way that multiple PCBs can get used to built bigger display. On the backside is the microcontroller. I am planning to use a ATmega 16/32 or compatible newer AVR like the ATmega 324.

Interface

I am planing to use UART for controlling this Matrix from some Master Device, but first I will run it stand alone. There are also both pins of the i2c bus as test pads available.

Software

Well, this is still to do....

License

I will publish the whole project under the CC BY-NC-SA 4.0 license. So this project qualifies not as open Hardware as the OSHWA defines it, because I decided to add the NC (=non commercial) tag. I wanted to publish it only for non commercial use. If you would like to use this in any commercial way, please contact me.

Further Information

In the Github repository you will find additional files for this project.


schematic_rev0.png

higher quality and black/white Schematic of rev0

Portable Network Graphics (PNG) - 111.50 kB - 05/03/2016 at 18:33

Preview
Download

  • idea for rev2

    Alex09/03/2016 at 14:28 0 comments

    Today I saw a new chip: The IS31FL3733. It is a 192 Led matrix driver. So far it looks like designed for 192:LED. The big improvement over the microcontroller would be: Some real current limiting, which would end up in more consistent brightness; not programming needed (i2c interface to main/host controller); simpler circuit maybe. And you could control more than one 192:LED-module over the same i2c Bus.

    I am thinking of changing the PCB design to fit with this driver IC.

  • load images over uart on the display - the simple way

    Alex07/02/2016 at 16:19 0 comments

    In the last log I wrote about a quite complicated way to load images to the display. I now have improved the octave script. it no loads the image itself to the display:

    This is done by using the instrument-control package of octave:

    function IMG_test
    
      pkg load instrument-control
      if (exist("serial") != 3)
        disp("No Serial Support");
      endif
      
      myImage = imread("image.png");  #read 8x8 pixel image
      # the image is vreatet with MS paint. At least there each
      # pixel is encoded into three bytes (R,G,B) this could be
      # normal for png. At least I hope so
     
      # now to the conversation magic 
      red   = uint8(bitshift(myImage(:,:,1), -5));  
      green = uint8(bitshift(myImage(:,:,2), -5));
      blue  = uint8(bitshift(myImage(:,:,3), -5));
      
      #add the three colors to one byte togehter 
      img8trueColor= bitshift(red,5) + bitshift(green,2) + blue;
      #transpose the image - needed to save it correctly
      img8trueColor=img8trueColor.';
      
      #write it to display direct in octave no more a file output
      s1 = serial("\\\\.\\COM12");
      set(s1, 'baudrate', 38400);
      srl_flush(s1);
      srl_write(s1, img8trueColor);
      
    endfunction
    The source code is also in the github repository.

    helpful links for octave and uart:

    http://wiki.octave.org/Instrument_control_package

    http://www.edn.com/design/analog/4440674/Read-serial-data-directly-into-Octave

    http://projectsfromtech.blogspot.de/2015/03/serial-port-communication-with-gnu.html

  • load images over uart on the display

    Alex06/28/2016 at 20:38 0 comments

    WARNING: This will get some more and complicated...

    I did broke out the RX pin on the PCB to get the possibility to sent images over UART to the display. And this is now also working. I also want to offload most of the processing to the UART sender (now just a PC with USB-UART bridge, but later perhaps some master Microcontroller/FPGA) . So I decided to just send the image as it is also coded internally:

    • 8 Byte per pixel
    • In the byte all three colors like RRRGGGBB (sometimes this is called 8 bit true color, it is not my idea)
    • so I need 64 Byte per image
    • The Byte order is chosen by me the first byte is the top right pixel an than follow the first line and so on

    The UART part was made fast and easy, but getting the needed data was complicated. I found no graphic program which saves images in 8 bit true color. So I decided to script some matlab/octave to that:

    function IMG_test
      
      myImage = imread("image.png");  #read 8x8 pixel image
      # the image is vreatet with MS paint. At least there each
      # pixel is encoded into three bytes (R,G,B) this could be
      # normal for png. At least I hope so
     
      # now to the conversation magic 
      red   = uint8(bitshift(myImage(:,:,1), -5));  
      green = uint8(bitshift(myImage(:,:,2), -5));
      blue  = uint8(bitshift(myImage(:,:,3), -5));
      
      #add the three colors to one byte togehter 
      img8trueColor= bitshift(red,5) + bitshift(green,2) + blue;
      #show the reult (just for visual inspection)
      imshow(img8trueColor);
      #transpose the image - needed to save it correctly
      img8trueColor=img8trueColor.';
      myFile=fopen("out.txt", "w");
      fwrite(myFile,img8trueColor);
      fclose(myFile);
      #{
        The out put file now should look like this: 
        07 E0 00 1A 1A 1A E0 1C 
        07 E0 00 1A 00 1A E0 1C 
        07 00 00 1A 1A 1A 00 1C 
        07 00 00 1A 00 1A 00 1C 
        07 00 23 00 F2 F2 00 1C 
        07 00 23 00 00 F2 00 1C 
        07 00 23 00 00 F2 00 1C 
        07 E0 23 23 00 F2 E0 1C
        The first eigt bytes (first line) are the top line of the
        display also. 
      #}
    endfunction
    This small script is some kin of user unfriendly, but working. My workflow now is:
    1. create some 8x8 pixel image (I used just MS paint)
    2. save it as png
    3. store it in the directory of the octave script
    4. run the octave script
    5. now you have a 64Byte big file named "out.txt"
    6. sent "out.txt" with Realterm over the UART to the display ( the file is *.txt because this is the only supported filetype by Realterm)

    So now some result and images:

    This is my in step 1 created image:

    My octave script create me now this file:

    07 E0 00 1A 1A 1A E0 1C 
    07 E0 00 1A 00 1A E0 1C 
    07 00 00 1A 1A 1A 00 1C 
    07 00 00 1A 00 1A 00 1C 
    07 00 23 00 F2 F2 00 1C 
    07 00 23 00 00 F2 00 1C 
    07 00 23 00 00 F2 00 1C 
    07 E0 23 23 00 F2 E0 1C
    00 is black; 07 is blue; 1C is green and so on.....

    After sending this to the display the display looks like this:

    The colors are at least similar as in the original image. Maybe I will add some kind of color correction to the octave script.

    So with a fas enough master device, which has lots of (or multiplexed) UART outputs and some more image (or video) software on it, I could now build big displays with this.

  • rainbow animation now also on 192:LED

    Alex06/26/2016 at 20:25 0 comments

    If you follow my other led display project ( #384:LED) you could already know this animation. I is know also running on this display:

  • 192:LED is alive

    Alex05/28/2016 at 19:58 1 comment

    After some rework it is now working. There was also something wrong with the 0201 Capacitors. They are the load capacitors for the crystal. Maybe just the value was wrong. But it also works without them, so I did no further investigation yet.

    The missing red LEDs on the picture are because the one red column is not connected. This is because the IO pin is shared with MOSI. To activate them I have to bridge a jumper and this is not done.

    Next will be to add some annimations or adding a controll interface.

  • (extreme) soldering Part Two

    Alex05/28/2016 at 11:56 1 comment

    Just a quick update. The top side with it's 64 RGB LEDs is also soldered:

    The Grid in the background is 1mm. I hope it will work. But to test that I have to write some firmware first. I made A video while placing and soldering, maybe I will made a Timelapse video of that.

  • (extreme) soldering Part One

    Alex05/25/2016 at 19:25 8 comments

    The bottom side is soldered. It was quite difficult to get the 0201 capacitors (the two next to the crystal) soldered correctly. The dimension of crystal is 2 x 1.6 mm.

    Next Task is to solder the to side with its 64 RGB Leds. But I will not do that today. One side a day extreme soldering is enough. And then I hope it will also work.

  • Getting Parts - Recycle a Microcontroller

    Alex05/19/2016 at 17:33 1 comment

    What is the cheapest way to get Microcontrollers? Well desolder them from other boards is often quite cheap. A suitable Controller is also on the MMMR-70 radio Modules. I bought ten of them some time ago (see #Yet another MMR-70 project). And for 0.7€ you can not get a new ATmega32.

    You should only take care about the fuse settings of the controller. I did reprogrammed them to default before desolder the ATmega from the MMR-70 board.

  • Boards and stencils are in

    Alex05/18/2016 at 16:28 0 comments

    Both was in the mail today:

    The board does look really similar (beside of the color) to the rendering a made before:On the left is a photo the right is the rendering. Luckily I found a real ¼US$ coin at home.

  • Boards, stencil and parts ordered

    Alex05/02/2016 at 20:47 9 comments

    I did ordered a first batch of three prototype boards from OSH-Park. Compared to the last log there where not many changes, but I made some nice renders of this "rev0" board:

    I did order stencils from OSH stencils and all missing parts as this tiny 2016 crystal. This crystal is also a optional part. The internal oscillator of the ATmega could be also used for first tests. But if using UART and high baud rates it was never reliable in earlier circuits.

    I will soon publish at least the gerber files int the github repository.

View all 13 project logs

Enjoy this project?

Share

Discussions

CLamb wrote 06/12/2016 at 20:48 point

How is the current limiting for the LEDs done?

  Are you sure? yes | no

Alex wrote 06/13/2016 at 14:59 point

There is is no real current limiting. Because of the multiplexing the LEDs are pulsed. In this way they are also capable of more current. There will be also some current limiting caused by the maximal drive strength of the IO-pins of the Microcontroller.    

  Are you sure? yes | no

[deleted]

[this comment has been deleted]

Alex wrote 05/12/2016 at 13:35 point

well, that could be a problem, if you run it at full brightness over longer time. I am planning to dim the LEDs so far down, so that heat is not a problem.

  Are you sure? yes | no

K.C. Lee wrote 04/24/2016 at 22:20 point

You want to be careful on the break out as the solder mask is less accurate especially for cheaper board houses.  So they use a larger solder mask opening around the pads to compensate for it.  Parts of the breakout traces might also be exposed.  If your breakout are off at an angle, that might pull the LED off a bit during reflow due to surface tension. e.g. There are a few that have a via off at the corner.

  Are you sure? yes | no

Alex wrote 04/24/2016 at 22:38 point

Thanks for your advice!
I will consider this during the further design progress. If I understand you right it would be better to place a via in the centre of a pad than in a corner. For some vias it will be also possible to place them off the the pad, because the vias will get smaller.

  Are you sure? yes | no

K.C. Lee wrote 04/24/2016 at 22:48 point

Don't put vias in pads.  Solder can get sucked into vias or flux trapped in vias and they bubble off the solder.   Also leave 10 mils tracks (or whatever board house say) between the via and pad.  They need a minimum width of stop mask.

You want all the breakouts traces to be the same.  Either go out diagonally or 90 degrees.  Choose one and be consistent so that the all pull the same way.  Any of them off at an angle, then the force is not balance and your LED might not line up with the others.

For a display project, that wouldn't look good.

  Are you sure? yes | no

Alex wrote 04/24/2016 at 23:07 point

Thanks again

  Are you sure? yes | no

davedarko wrote 04/24/2016 at 15:48 point

I'll take 4 :D 

  Are you sure? yes | no

davedarko wrote 04/24/2016 at 15:53 point

or wait for the 7u8:led

  Are you sure? yes | no

Alex wrote 04/24/2016 at 19:55 point

if you are talking about 768:LED, this will be possible with using four 192:LED. I am planing to make them so small that you can attach multiples together without disturbing the grid of the LEDs.
Well and I think I can bring you four till the next Berlin Maker Faire. 

  Are you sure? yes | no

davedarko wrote 04/24/2016 at 22:07 point

yesssss :)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/24/2016 at 13:41 point

Om nom nom I love leftovers :-D

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates