Building Open Source Hardware: Making a Derivative

This chapter is from the book

Building Open Source Hardware: DIY Manufacturing for Hackers and Makers

Learn More Buy

This chapter is from the book

This chapter is from the book 

Building Open Source Hardware: DIY Manufacturing for Hackers and Makers

Learn More Buy

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 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:

• Fritzing²
• Eagle³
• KiCad⁴

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 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:

https://github.com/strykeroz/ATTiny85-20-LED-snowflakes/blob/master/ATTiny85_Charlieplex20Snow.ino

*/

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:

current++;
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 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 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

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.

Anecdote: Enclosure Case for Blinky Buildings

Jason Brownstein

An enclosure was made for the supplied Blinky Buildings board (Figure 6.5) in an effort to further illustrate the process of making a derivative including a 3D printed piece. This anecdote describes the design process and materials used. The enclosure described here was made using 3D modeling software, slicing software was used to produce G–code, and finally the enclosure was printed on an open source 3D printer. Chapter 8 provides links to the open source 3D modeling and slicing software packages.

Figure 6.5 3D printing the enclosure.

(Source: Image CC–BY–SA Jason Brownstein)

When stepping through the design process, many iterations were made to the enclosure to improve its functionality, rather than the overall aesthetic. Beginning with the documents and Blinky Buildings board dimensions, constraints were established on the design of the enclosure. The purpose of this enclosure is to extend the current shape profile and complement the blinkiness. The dimension tool in the board’s Eagle file can be used to obtain the exact dimensions of the board, which becomes the minimum dimension of the enclosure and forms the cavity. Keeping with the building theme, the enclosure profile was chosen to match the board dimensions, with a wall thickness of 2 mm or roughly 1/16 inch. This wall thickness allows for a rigid part, but permits some minor flexibility that will be utilized later in the design process.

Several iterations were made to enable the removal of the board from the enclosure, while still accessing the switch. The first iteration of the design had two full–length tabs on the top and bottom of the enclosure to hold the circuit board. However, with a full tab, the switch on the board would not allow the board to tilt into place. A modified route was then taken in the second iteration in which snap–fit features were used on the inner side walls of the enclosure. These lofted extrusions on each wall of the enclosure allow the board to slip over it and be retained. However, the snap–fit features were still too tight to get the circuit board in and out. Thus part of the bottom tab was removed so the board could slide into place.

Figure 6.6 contains three images of the iteration process, moving from the initial model to the final model. The files to print this enclosure for the Blinky Buildings kit are provided at www.bit.ly/blinkybuildings. The print files are licensed as CC–BY–SA Jason Brownstein.

Figure 6.6 (a) First version. (b) Second version. (c) Third version.

(Source: Images CC–BY–SA Jason Brownstein)

To complement the blinkiness of the board, materials selection was considered as part of the design process. Clear plastic filament is available for use on 3D printers but it differs in transparency. A trial print was completed with standard clear PLA available from Lulzbot, and the result was considered acceptable. In the second iteration, T–Glase Nylon clear filament was used. This filament was chosen because of its optical properties, which enable it to carry light in much the same manner as fiber–optic cable. The T–Glase made the PLA look slightly dull in appearance. The appearance of the T–Glase diffused the light much better and provided an almost shiny finish to the enclosure. But with any change in the design process comes consequences, which may cause you to rethink another aspect of the design or manufacture. When using PLA, the settings are relatively standard for the Lulzbot, and the printing operation was executed with a high success rate. By comparison, the T–Glase nylon required reworking the settings, including increasing the extruded temperature, slowing the print head movements down by more than half the PLA speed, increasing additional cooling with use of the onboard fan, and adjusting the extrusion layer height. Each of these settings ensured the print layers fused together well, while minimizing shrinkage and unwanted slanted enclosure walls. Print one off for yourself or make a derivative!

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 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.