Home > Articles > Hardware

  • Print
  • + Share This
This chapter is from the book

Blinky Buildings Project

The Blinky Buildings project is a simple kit that you can use as an example of how to create an open source hardware derivative. My intention in creating this kit was to ensure that the community has something to experiment with and gives you the rights to create your own derivative. The goal of this kit is to inspire different derivatives of buildings, which together create a whole world of Blinky Building kits. My Blinky Building kit is shaped like the Empire State Building (Figure 6.1a); in its enclosure (Figure 6.1b), yours can be shaped like a different building, city, or landscape structure. Your derivative Blinky Building may include any of the four alterations discussed earlier: modify the shape of the original, modify the function of the original, modify the economics, modify the DFM, or make your own copy.

Figure 6.1

Figure 6.1 Blinky Buildings: Empire State Building (b) with enclosure.

(Source: Image CC–BY–SA Alicia Gibb)

Source Files

This section walks through which pieces of other people’s open source material I used to create my kit; it also explores my source files that are shared with you. The source files include a circuit board created with the free version of Eagle and a 3D printing file for the enclosure. You can find all these files at www.bit.ly/blinkybuildings or in Appendix F. You will need PCB layout software, such as the following options, to be able to replicate or build off the derivative file:

  • Fritzing2
  • Eagle3
  • KiCad4

You will also need a 3D printing software if you choose to print out or modify the enclosure, such as:

  • Blender (reviewed in Chapter 8)
  • OpenSCAD
  • SketchUp

When making an open source hardware project, the most important thing to consider is whether people can rebuild the project from your source files. If so, you have a successful open source hardware project! If not, you need to release more source code or include more documentation.

As described in Chapter 5, I started my project by laying out the design process. My design purpose was to elegantly blink 20 LEDs in the shape of the Empire State Building. Given the scope and the specifications and requirements, I decided I would need a small, low–cost chip and would have to charlieplex the LEDs to drive 20 of them.

I discovered a project close to my needs that charlieplexed 20 LEDs in a falling snowflake pattern. The file was licensed as CC–BY–SA. This designation means the schematic can be copied or used for a derivative, but the new schematic must give attribution to the original and must also share alike with the same terms. In addition, this schematic came with recommended code, also licensed as CC–BY–SA. Before I did anything else, I contacted both of the original designers—the hardware schematic designer and the code author—and asked if it would be okay to make a derivative of their work and include that derivative in my book. The open source hardware definition does not require this step, but the best practices recommend it.

I started with the schematic in Figure 6.2, which was created by Davy Uittenbogerd (daaf84). The file can be opened with Fritzing: fritzing.org/projects/charlieplex-snowfallshooting-star-20-leds.

Figure 6.2

Figure 6.2 Schematic by Davy Uittenbogerd drawn in Fritzing.

(Source: Image CC–BY–SA Davy Uittenbogerd)

A link to the code to run this circuit is included on the Fritzing page. The code was written by Geoff Steele (strykeroz). This code can be found in this GitHub repository: github.com/strykeroz/ATTiny85-20-LED-snowflakes.

When I copied and altered the code, I added a statement at the top of the code (known as the comment block) explaining where the original code was downloaded from and who the original author was: Geoff Steele. This gives Geoff attribution. I added a brief statement about which parts of Geoff’s code I altered. I included comments throughout the code when I changed something as well. Geoff included which pin numbers correlate with which color of wire on the Fritzing schematic in the code. It is good practice to include basic instructions for the hardware pinouts in the comment block.

Here are the altered chunks of code, including the attribution in the comment block. To view the full code, refer to www.bit.ly/blinkybuildings.

----> /* downloaded from http://code.google.com/p/avr-hardware-random-number-
generation/ Original code by Geoff Steele. Alicia Gibb altered the code by 
commenting out the fade functions so the building blinks LEDs on and off rather
than fade LEDs on and off.

The original code is still all there if others wanted to keep playing with it; just take out the duty cycle comments.

The delays have also been changed, but can easily be reinstated by looking at the original code:



I explained each of my code alterations by commenting that I altered the code from the original. I used a charlieOFF command rather than the original charlieON command in line 121.

   if (current > 19) charlieOFF(19); //This is altered from the original code, to turn LEDs off once the blink is over

I explained in another portion of the code that I commented out the time delays for fading an LED so it blinks rather than fades:

if(current==23) { //// start over
   //Alicia commented out the below code to make the LEDs blink on and off rather than fade out.
  //// now fade out the snowflake in that final position #19
 for(int dutyCycle = 3; dutyCycle <= 15; dutyCycle += 3) {
    //loopCount = 0;
    //timeNow = millis();
    //while(millis() - timeNow < (displayTime+current*2)) { //// fade out as slow as animation has achieved by now
    // loopCount++;
     if(!(loopCount % dutyCycle)) charlieON(19);
    else charlieOFF(19);
   // }

Once I had the code working on a bread-boarded prototype, I drew the schematic in Eagle following the Fritzing diagram. My schematic in Figure 6.3 is licensed as Creative Commons-By-Share Alike (CC–BY–SA), because the original schematic was licensed as CC–BY–SA. Due to the share-alike license, I must share it the same way. Any derivatives of this kit must also be shared alike as well, with the same Creative Commons license (CC–BY–SA) attached to the source files.

Figure 6.3

Figure 6.3 Schematic drawn in Eagle.

(Source: Image CC–BY–SA Alicia Gibb, derived from Davy Uittenbogerd’s Fritzing diagram)

From the schematic, I created a board layout in Eagle (Figure 6.4) to be shaped like the Empire State Building. For instructions on how to give PCB boards an interesting shape, read Chapter 7. This board file is covered by a CC–BY–SA license: Because the schematic was posted under a share-alike license, and the board file is generated from the schematic, I must share it the same way. Note, however, that because Davy Uittenbogerd did not create this particular Eagle schematic or board file, it is licensed as CC–BY–SA Alicia Gibb and I will give him attribution in the README file and the product description. Labeling Davy as the creator at this point would cause confusion as to who produced and manufactured this product.

Figure 6.4

Figure 6.4 Blinky Buildings Board file in Eagle.

(Source: Image CC–BY–SA Alicia Gibb)

Bill of Materials

I am creating a kit for my Blinky Building that users will put together themselves. Since this is a kit, the bill of materials (BOM) will not go to a manufacturer, and it is not as detailed as the examples in Chapter 14. Generally, for a simple do-it-yourself (DIY) kit, the BOM serves the purpose of telling people what is in each kit. If the parts are standard, general parts that you could find at any hackerspace, there is no need to go into greater detail than the information shown in Table 6.1. In other documentation, it is advisable to include the data sheet of your chip as well.

Table 6.1 BOM List




Vendor Part Number

Manufacturer Part Number


Empire State PCB

Dimensions 1.7" × 2.95"

Golden Phoenix


Round white diffused LED 8K MCD

3 mm



RES 680 ohm 1/4W 5% carbon film


Digikey CF14JT680 RTR-ND



8-bit microcontroller: MCU 8kB Flash 0.512kB EEPROM 6 I/O pins


Mouser 556-ATTINY85-20PU



Switch micro-mini slide 30V

Through hole

Digikey 679-1854-ND



Holder cell 2032 w/gold pins

Through hole


BH32 T-C-G


Battery lithium coin 3V 20 mm


Digikey P189-ND

BH32 T-C-G

In addition to my README file in Appendix F, this concludes the source files for this kit. With the schematic, board layout, BOM, and README file, others should be able to reproduce my Blinky Buildings Empire State kit.

Cost–Benefit Analysis of Suppliers

For complete transparency, the following lists include the suppliers from which I received quotes for each item listed on the BOM. Listing the results of the cost–benefit analysis of supplies is not required for open source hardware, but in teaching people how to make a derivative, it is important to know some economics behind what is created. As stated in Chapter 15: Business, typical mark-up on hardware is between 2.6 to 4 times your BOM costs. I went with the cheapest possible BOM and marked up the Blinky Buildings kit 2.6 times the BOM.

Board Manufacturer


100 Pieces


Gold Phoenix PCB



5 day turn + 8 day shipping




4 week turn + shipping

Advanced Circuits



4 week turn + shipping

Parts: ATtiny85


100 Pieces





3–4 day shipping




3–4 day shipping

Parts: Resistors


500 Pieces





3–4 day shipping




3–4 day shipping

Parts: LEDs


2000 Pieces





3–4 day shipping

Evil Mad Scientist



3–4 day shipping

EBay: LED shop 2010



2–4 weeks

Parts: Batteries Holders


100 Pieces





3–4 day shipping




5–7 day shipping

Parts: Batteries


100 Pieces





3–4 day shipping




5–7 day shipping

Parts: Switch


100 Pieces





3–4 day shipping




Pick up in CO or 3–4 day shipping

Making a Derivative of This Kit

All of the files to re-create this kit or make a derivative of this kit live at www.bit.ly/blinkybuildings. These files are licensed as CC–BY–SA Alicia Gibb. (Remember, if you make a derivative of this project, you cannot include a noncommercial or no-derivatives clause to the source files or hardware.) Whether you change functions in the schematic, change the board form factor, or change the economics of the project, feel free to make derivatives! Turn your board into another building in your city or a landmark that is near and dear to your heart. Make the building roll away on wheels or create a glow-in-the-dark version by 3D printing a new case. Use it as a nightlight, a flashy model train landscape, or just a means to impress your friends!

Giving Correct Attribution: An Example

Earlier in this chapter, the “Giving Correct Attribution” section discussed what giving correct attribution means. This section shows you what correct attribution looks like.

Blinky Buildings is a communal descriptive title of this product that you can use—but be aware that having a communal project name is not always the norm. However, the same is not true of my name, Alicia Gibb; my company, Lunchbox Electronics; or my logo. Only I can use my name, along with other people named Alicia Gibb. But I’m the only person who can use my company name or my logo; even other people named Alicia Gibb cannot use my company name or logo. This is why the board contains the following text: By Alicia Gibb ← remove my name for derivatives and put your name, logo, or trademark in its place. Follow these instructions and place your own name or logo here and move my name (and the names of the other original creators) to an attribution section in the README.txt for your derivative.

When working on my Blinky Buildings projects, I leaned heavily on what has already been created within the open source hardware community. I have no idea how to figure out the code and schematics for charlieplexing, but I wanted to drive 20 LEDs off a small, low-cost chip. When I discovered a project close to my needs, I looked at the licensing to ensure I could use it openly, and I looked at who was behind the project to give correct attribution. I had to do a little Internet digging, but found both of the respective creators on Twitter and contacted them to ask permission to use their work (even though it was already licensed as CC–BY–SA, I wanted to ensure it would be okay to write about in a book) and for their preferred name/handle. When you contact someone to tell them you’re using their open source hardware, you’ll probably make their day. One reason to open source your hardware is to allow it to grow and change in ways you never expected.

Here is an example of how to correctly give another creator attribution on your project. This is the attribution section of the README.txt for my project:

Attribution –

The code for this project was downloaded from http://code.google.com/p/avr-
hardware-random-number-generation/ Original code by Geoff Steele, altered by 
commenting some code out to blink LEDs on and off by Alicia Gibb.

The original Fritzing design of charlieplexing 20 LEDs was downloaded from 
http://fritzing.org/projects/charlieplex-snowfallshooting-star-20-leds by Davy 
Uittenbogerd. Alicia Gibb drew this schematic in Eagle and altered it into the 
Empire State Blinky Building form factor.

The original code and the hardware files are both under a CC–BY–SA creative commons license.

Code: CC–BY–SA: Geoff Steele

Fritzing layout: CC–BY–SA: Davy Uittenbogerd

Blinky Building schematic, board file, and BOM: CC–BY–SA: Alicia Gibb

I didn’t take either source’s names, logos, or trademarks and pass them off as my own. Instead, I gave credit for their work by acknowledging the work they created. The standard procedure for open source hardware is to include attribution both in the README.txt and in the software comment block. (For more information on README files, refer to Chapter 14, Taxonomy of Hardware Documentation.)

Onboard Byline

The physical board carries only my name, because putting the entire README file, or two other names, on the board file would take up too much space. Physical objects have a footprint with limited space for attribution, a fact that is well understood by the hardware community. There is usually not enough room on the piece of hardware itself to write the names of everyone who worked on it, including the original creators.

Figure 6.7 shows the open source hardware logo front and center on my board, so everyone who sees it will know it follows the Open Source Hardware Definition and can be copied under those terms. My board has the attribution text reflected in Figure 6.7: “By Alicia Gibb ← remove my name for derivatives and put your name, logo, or trademark in its place.” These are instructions on what to do when creating your derivative. In other words, the attribution on the board you create should read: “By: [Insert Your name here].” But unless you are Alicia Gibb, do not use that name!

Figure 6.7

Figure 6.7 Byline on the board file in Eagle.

(Source: Figure CC–BY–SA Alicia Gibb)

Notice that on the board I used the open source hardware logo and the word “By” instead of CC–BY–SA. This usage is meant to alleviate any confusion about copyright claims. The physical hardware is not under copyright, so a CC license would not be applicable. CC licenses can be applied only to the source files and documentation, so I did not reflect the CC–BY–SA terms on my board for clarity of separating the IP that protects written documents and hardware. The term “By” does not close down my board, but patenting it would. Generally, creators do not bother to include “By” on their boards, but for the exercise of creating derivatives I wanted to spell out all the elements associated with attribution.

The open source hardware community does not yet have a standard for applying an attribution icon with the open source hardware logo. Over time, the community will most likely come to some sort of consensus as to how the open source hardware logo and other terms should be displayed, along with other conditions such as attribution.

  • + Share This
  • 🔖 Save To Your Account