This is the continuation of a series of articles demonstrating how to Create A PCB In Everything. In this series, we take a standard reference circuit and PCB layout — a simple ATtiny85 board — and build it with different PCB design tools. Already, we’ve taken a look at the pre-history of PCB design with Protel Autotrax, we learned Fritzing is a joke for PCB design, and we’ve done a deep dive into Eagle. Each of these tutorials serves two purposes. First, it is a very quick introduction to each PCB design tool. Second, this series provides an overall comparison between different PCB design tools.

Now, finally, and after many complaints, it’s time for the tutorial everyone has been waiting for. It’s time for KiCad.

No, like the head of the Bajoran clergy

Although KiCad (pronounced ‘Kai-Cad’ like the head of the Bajoran clergy, not ‘Key-Cad’ like the thing that goes in a lock) is the new hotness when it comes to PCB design. The amazing growth of KiCad installations over the past few years is a long time coming. In development since 1992, KiCad has cemented itself as the premier Open Source PCB design suite, and since 2013 CERN has been making contributions to the project. More recently, the KiCad project has been showing off some amazing new features. These include 3D rendering of boards, interactive routing, push-and-shove, simulation, and dozens of other features that put it on a path to being on par with the top of the line EDA suites. Add in some great community contributions, and you have something really, really amazing. All of this is wrapped up in an Open Source license, free as in speech and beer. If you’re looking for the future of PCB design, Eagle is going to get very good but KiCad is almost there now while being Open Source.

The KiCad Overview

As I said in the introduction to this series of posts, this tutorial will be broken down into three main parts. The first will be how to create a part — specifically a DIP8 ATtiny85 — as a schematic symbol and how to create the schematic we need. The second part of this KiCad tutorial will assign footprints to our symbols and turn the schematic into a board you can send off to a fab house. Finally, we’ll take a look at the cool features of KiCad, such as push and shove routing and 3D rendering.

For this part of the KiCad tutorial, we will only concern ourselves with making a part for a DIP8 ATtiny85. Download KiCad and let’s get started.

Just like Eagle – and every other PCB design tool, for that matter – there are several different editors in KiCad. They are:

Eeschema – the schematic editor

The Schematic library editor – used for editing part libraries

Pcbnew – the ‘board’ editor

The PCB footprint editor – used for editing footprints (the physical package) of parts

An introduction to the terminology of PCB design might be in order. A schematic is the abstract design file, showing the electrical connections between all the components in your circuit. The schematic is not sent to the fab house.

A PCB or board describes the layout of the components, holes, pads, traces, connections, mechanical design, and silkscreen. Designing a board is the end game of all PCB design work, and it is this file that gets sent off to a fab house for manufacturing.

Before we put together a schematic and design a board, we must learn how to build our own parts. To start, install KiCad, select File -> New Project, and name it ‘Nanite’, or ‘Some Trash I’ll Never Do’

Making A Part

All of these tutorials demand making a part from scratch. Right now, that means making a part and footprint for a DIP8 ATtiny85. From the main KiCad window, open up the Part Library Editor, and you have a window that looks like this:

When you first open the Part Library Editor, no libraries are loaded. You would think it would be possible to simply create a new library, and design some parts, but KiCad is weird. To make your own library in KiCad, you must first select an existing library and save it as your own. Yes, it’s a bit weird and one of the many oddities of the KiCad UX, but at least it’s better than Fritzing.

Save this library you just ‘created’, select File -> Current Library, and select the library you just saved. Now we can begin to make a part.

Click the ‘Create a new component’ opamp icon, and you’re presented with a window asking you to name your part. For small, simple, jellybean components, you won’t have to bother with anything except for the name. Name your part ATtiny85 and click okay. The name and designator of the part will be dropped into the window. Now we’re ready to add pins to our part.

Oh God Everything Is Backwards And My Mouse Doesn’t Do Anything

If you’re following along with this tutorial, this is the first time you’ll actually use the KiCad interface. KiCad has a reputation for being incomprehensible for the beginner. Want some proof of that? Click on the ‘ATtiny85’ label and try to move it. You would think just clicking it would do something, but that only opens up some options (bold, italic, size, justification) for the text. If the ‘ATtiny85’ and ‘U?’ overlap, clicking on both of them opens up a dialog box.

There’s a reason for this: KiCad, like almost every other PCB design tool, is based on hotkeys. This is the reason KiCad gets the reputation for not being user-friendly, but there’s a solution: just type a question mark. The list of hotkeys will pop up, and now you’ll always know what keys you need to hit to do what you want to do. To move the ‘ATtiny85’ and ‘U?’ label off to the side, hit ‘M’ while hovering the mouse over each label.

Now it’s time to add pins. Click the ‘Add pins to Component’ button on the right side of the window. Next, click anywhere on the Part Library Editor window.

The Pin Properties window is where you assign a name, number, and graphical style to all of the pins in the schematic representation of your part. We’re doing a very simple part with power and ground on one side, and all the IO on the other side. As long as the pin names are correct, and all the pins correspond to the correct numbers on the footprint, you shouldn’t have much trouble. The only thing that might trip you up is the orientation of the pins; here, the circle at the end of each pin designates where the pin connects to a net on the schematic.

Drop eight pins down and make your part look something like what we made in the Eagle tutorial. You’ll end up with something like this:

With the pins dropped into the window and correctly labeled, all we need to do to finish the part is to draw a rectangle. Click on the ‘draw a rectangle’ icon, click once in the corner, drag, and click again to finish the rectangle. Hit File -> Save Current Library, and we’re done making the schematic symbol for this part.

From Symbol To Schematic

Now that we have a symbol for the ATtiny85 we’re going to use in this board, it’s time to make a schematic. From the main KiCad window, open up the Electronic Schematic Editor, and you’ll be presented with the following window:

Again, the hotkeys are going to kill you. To add a component, press ‘A’. You might also want to hit ‘?’ and bring up the list of hotkeys.

At this stage, we’re not concerned with footprints, or the physical dimensions of the components we’re eventually going to place on the board. All we want are symbols. There are hundreds of different varieties of USB connectors, but right now we don’t care. All we need to do is drop a few resistors, diodes, connectors, and other parts onto the schematic. To do that, press ‘A’, and the window below will pop up.

Since we’re directly copying the reference schematic from the introduction to this series, we need the following components:

• Two 1×4 connectors
• Two Zener diodes
• Four resistors
• One LED
• One USB port (OTG)
• One unpolarized cap
• One ATtiny85
• A smattering of +5V and GND symbols

For each of those components, press ‘A’ to add a part, search for the part, and drop it onto the schematic. If you’re really good, you can use the ‘P’ hotkey to add power and ground parts. When you’re done, you should have something that looks like this:

The important hotkeys to know are ‘A’ to add a part, ‘M’ to move a part, and now ‘W’ to add a wire between parts. Again, pressing ‘?’ displays a list of hotkeys. Of special interest is the ‘K’ hotkey to stop drawing a wire.

With all the wires drawn, it’s time to label these wires to connect them into ‘nets’ Check out the reference schematic to the right. The wires coming off the USB/Zener/resistor chunk of the schematic are labeled ‘PB4’ and ‘PB3’. These are nets connected to the PB4 and PB3 pins on the ATtiny, and are used for USB communications. The 1×4 headers are connected directly to every pin on the ATtiny, so we label them accordingly.

To label these wires and turn them into nets, use the ‘L’ hotkey, and select a name for each of your nets. Drop this label over the open connection on each wire to turn them into nets. When you’re done, you’ll have something that looks like this:

We’re almost done with the schematic. All we need to do now is add values to the relevant parts. The resistors must be labeled with the right value, the capacitor should 22nF or thereabouts, and the Zeners should have a ‘3.6’ label. It’s time for hotkeys again, this time brought to you by the letter ‘V’. Press ‘V’ over all the caps, resistors, diodes, and the LED and assign values. This takes care of the values for each part, but we still need to give each part a name. To do this, we’re going to use the ‘Annotate Schematic’ tool available in the top toolbar.

The Annotate Schematic tool automatically assigns a letter (D for diodes, L for inductors, R for resistors, Q for transistors…) to each part, along with a number. There are options to set how these numbers are assigned, but this is a very simple circuit and simply pressing the ‘annotate’ will suffice.

With that, our schematic is done. We haven’t set any footprints up for each part, and we haven’t even started on the board yet. This post is already two thousand words long, though, and Hackaday readers have the entire Internet has no attention span.

In the next part of this KiCad tutorial, we’re going to take a look at assigning footprints (the physical representation of components) to the parts in our schematic. We’re going to make a board, after which we’ll take a look at DRC, and a few of the neat tricks in KiCad including 3D rendering, turning the board into a bunch of Gerbers, and send off to a fab house.

This is the continuation of a series where I create a PCB in every software suite imaginable. Last week, I took a look at KiCad, made the schematic representation for a component, and made a schematic for the standard reference PCB I’ve been using for these tutorials. Now it’s time to take that schematic, assign footprints to parts, and design a circuit board.

All PCB design tools have different methods of associating the schematic view of a component with how it will be represented on the finished board. Eagle uses libraries that contain both a schematic view and PCB view of a component. In the prehistory of PCB design software, Autotrax simply ignored the schematic view.

KiCad has a clear separation between a symbol (the schematic view) and a footprint (the PCB view). If we were to take our schematic and create a new PCB by running PCBnew, nothing would happen – our symbols aren’t associated with any footprints.

To associate symbols with footprints, we need to run CvPCB. This sub-program tucked inside KiCad gives us the ability to associate footprints with our schematic symbols.

It’s like the cloud, only not completely worthless

CvPCB is a new feature for KiCad 4.0. Instead of every other PCB design tool we’ve taken a look at so far, KiCad effectively stores all of the footprints in Github. In the Github repo for KiCad, you’ll find a bunch of files with a .pretty file name. These are the footprints for nearly every component you can imagine. If you’re running a fresh install of KiCad, everything shows up in CvPCB automagically – there’s nothing you need to worry about, and footprints just happen.

There’s a subtle brilliance about this implementation. It’s like the cloud, only it’s completely verifiable, and if a part doesn’t work, you can fix it and submit a pull request. Already, this is phenomenally better than the Eagle paradigm, where millions of footprints are available in thousands of different libraries scattered around the Internet. If you’re reading through this series in order, take note: this ‘Github as the cloud’ will be a major point of comparison when we get to other cloud-based PCB design tools.

With that said, we need to associate footprints with the symbols on our schematic. To do that, go down the list in the center of the CvPCB window that contains a list of all the components in our schematic and associate a footprint with each part. Footprints are on the right, libraries (or categories) are on the left. To view the selected footprint in a new window, click the ‘view selected footprint’ button.

Getting Libraries In Order

This project is using (mostly) all through-hole parts, and as such, I could easily select a DIP8 footprint for the ATtiny85 and be done with the whole thing. This is a tutorial, though, and I need to demonstrate how to make a part – schematic and PCB view – from scratch.

To make a footprint, KiCad offers a Footprint Editor. This can be accessed from either PCBnew or the launcher. Click on that, select File -> New Footprint, enter a name for this footprint (‘ATtiny85’ will do), the name of the footprint and a reference designator is placed onto the footprint editing window.

Libraries are important, and since KiCad is now running on ‘not-worthless cloud technology’, we have to create a library for this project that won’t be saved along with our copies of the standard Github libraries. Select File -> Save Footprint In New Library, save this library wherever the rest of the files are for this project, and give the library a name.

We have just created a new library, but that doesn’t mean KiCad knows what library we’re working with. In the Footprint Editor, select Preferences -> Footprint Libraries Manager, and click on the ‘Project Specific Libraries’ tab. Hit the ‘Append Library’ button, and drop the path to the library we just created in the ‘Library Path’ field. That’s more KiCad weirdness, but once we’re done we can finally create a footprint.

Making The Footprint

Now that we have the Footprint Editor open, a part name and a reference for the footprint, and the library all set up, it’s time to actually put some pads down. There are a few relevant buttons on the screen:

The most important, obviously, is the ‘Add a pad’ button. Click that and drop some pads down where they should be. This is a standard DIP8, or two rows of four pins 0.3″ apart. The default grid, as you may have noticed, is 50mils.

After placing the pads, use the hotkey ‘E’ to edit the properties of each pad. Here, you can change a through-hole part to an SMD, change the dimensions of the pad, hole, and shape of everything. Importantly, the Pad Properties window allows you to change the number of the pad. The number of the pad is how KiCad connects the schematic representation of a part with the footprint. Get this right, or else nothing will work.

Add a few lines to the footprint, save your work in the project library, and go back to the schematic. You’re done. That’s how you make a footprint.

From Schematic To Board

Now that the schematic has footprints associated to everything, it’s time to open up PCBnew, move parts around, and put some traces between parts. Do that. Oh, nothing shows up. Why is that? You need to generate a netlist in the schematic view, and import it in PCBnew. There’s a button with ‘NET’ written on it in both programs. Click those. Now, what do we get when the netlist is successfully imported into PCBnew? The worst mess you’ve ever seen in any sort of design program:

We end up with a gigantic mess on our hands. No worries, ‘M’ is the hotkey to move the parts around. You can also use the ‘Move Footprint’ mode to automagically place these parts. Reference the PCB we designed for the introduction to this series and move some parts around until we get something resembling the board below. The relevant hokeys are ‘M’ for move and ‘R’ for rotate. As always, there’s the ‘?’ hotkey that tells you everything you need to know.

That’s close, but it looks horrible. Deselect Footprint mode, use your cursor, and move all those labels and references around. We don’t need “CONN-01×04” on the board, and it’s really helpful to have the values of resistors inside their own footprint. With a little bit of work and deleting those labels, you’ll have something that looks like this:

Holy crap, that actually looks like something. All the resistors and diodes are labeled with their value, all the superfluous references are gone, and this actually looks good. You can’t do this in Eagle easily.

With the layout pretty much figured out, it’s time to finally draw some traces. This requires a description of the layers.

• F.Cu and B.Cu are the top and bottom copper layers. The hotkeys for these layers are PgUp and PgDn
• Edge.Cuts is the equivalent of the ‘Milling’ layer in Eagle. This is the outline of your board.
• F.SilkS and B.SilkS is the silkscreen – the text and outlines of your components.
• F.Mask and B.Mask is the soldermask. It’s usually green, or purple from OSHPark.
• F.Adhes and B.Adhes is glue applied to SMD components.
• F.Paste and B.Paste is where solder paste will be applied.

For a simple board that won’t be sent off to an assembly house, the only layers you need to worry about are the copper layers, the Edge.Cuts, and the silkscreen.

The first thing to do to complete the board is to draw the ‘edge’ or milling layer. Select the ‘Add a graphic line’ button on the right hand toolbar, and draw a rectangle around all our parts. That’s simple enough.

Now it’s time to actually put some traces down. You can select which copper layer to use in the top toolbar, and the relevant hotkey is ‘X’. Hit ‘X’, click on a few airwires, and route them just like the reference PCB. Don’t worry about power or ground traces – we’re going to do those with copper fills. When you’re done, you should have something like this:

That’s pretty much all there is to it, save for the copper fills. To do that, we need to add a ‘filled zone’ or ‘copper pour’ or a ‘polygon’. By any other name, it’s just a big area of copper that is connected to a single net in the schematic.

Click on the ‘Add filled zones’ button, and a ‘Copper Zone Properties’ window will show up. Here, you can assign a layer of copper to a specific signal. Our board puts +5V on the back copper, and GND on the front copper. In the Copper Zone Properties, select the B.Cu layer, the +5V net, hit Ok, and trace around the edge of the board. Do the same with the F.Cu layer and the GND net. When those fills become hatches around the edges of the board, hit the ‘B’ hotkey to render the copper fills.

That’s it. We are technically done. If you save and drag the .kicad_pcb file onto the OSHPark web page you’ll get a pretty purple PCB in a week or two. That’s not to say this PCB actually works – I screwed up the USB signals in the schematic, and that propagated over to the PCB. No matter, because no one is actually going to build one of these boards.

This just about concludes the ‘Creating A PCB in Everything’ tutorial for KiCad. If you’ve been reading along for the last five thousand words, you have an excellent introduction to KiCad, and should at least be able to build a breakout board. This doesn’t mean I’m done with KiCad quite yet – there are a few more tricks to go over including DRC and ERC, a demo of how freakin’ awesome the routing in KiCad is, and I need to put a keepout on the decoupling cap in on the board, anyway. Creating a PCB in Everything: KiCad Part 3 (the optional part) will be out sometime next week.

Thoughts on KiCad

This series of posts serves two purposes. First, it is a quick tutorial for various PCB design tools. After reading these posts, you should be able to guess your way through a PCB design tool and build a simple PCB. Second, each of these tutorials serves as a pseudo-review of each PCB design tool. Each of these posts serves to illuminate the quirks of a PCB design tool, and serves as a notice that I still have an unclaimed bounty for the first person to create a part for an ATtiny85 from scratch in Fritzing. Don’t use Fritzing, it sucks.

Coming from Eagle, KiCad is downright weird. That’s not to say it’s difficult, though – it’s generally the same as any other PCB design tool. The interface, like nearly every Open Source project, is obtuse, and there are five non-obvious ways to complete any task. There is zero reason why parts imported from a netlist into a board are squished together. Custom libraries can and should be automatically imported. The KiCad community especially rancorous. The UI suffers from an intangible wrongness about it, although that seems to lessen after working with it for a few hours. In a sense, KiCad is exactly what you would expect from an Open Source project that is decades old, very mature, and has features packed to the gills: it’s very powerful, but not friendly to the beginner.

Although the KiCad beginner will struggle to wrap their heads around the interface, it will be one of the most powerful PCB design tools I’ll use in this series of posts. No other free (beer) program will give you 32 copper layers and unlimited routing space. Nothing else uses the cloud/GitHub like KiCad. It’s brilliant.

A few months ago, if someone asked me to suggest a PCB design tool, I’d give Eagle or KiCad as suggestions. Eagle is easy enough to learn, and will be getting better since the Autodesk acquisition. KiCad is robust, and even in the best case of Eagle development, Autodesk may only ever reach parity with what KiCad can do.

Now, KiCad is growing on me. I have a secret project where I need to build and manufacture a thousand relatively complex boards. My previous go-to was Eagle, but I think I’m going to do this board in KiCad.

This is the third and final installment of a series of posts on how to create a PCB in KiCad, and part of an overarching series where I make the same schematic and board in dozens of different software tools. A few weeks ago, we took a look at making a schematic in KiCad, and more recently turned that schematic into a board ready for fabrication.

For our KiCad tutorials, we’ve already done the basics. We know how to create a PCB, make a part from scratch, and turn that into a board. This is the bare minimum to be considered competent with KiCad, but there’s so much more this amazing tool has to offer.

In part three of this KiCad tutorial, we’re going to take a look at turning our board into Gerbers. This will allow us to send the board off to any fab house. We’re going to take a look at DRC, so we can make sure the board will work once we receive it from the fab. We’re also going to take a look at some of the cooler features KiCad has to offer, including push and shove routing (as best as we can with our very minimalist board) and 3D rendering.

DRC

DRC, or Design Rule Check, is an automated process where the software checks the design of a board file. If traces are too close together, DRC will flag that. If holes are too small, DRC will notice that, too. If nets should be connected but aren’t, DRC is going to find that and tell you. The last time we took a look at DRC was with Eagle. Yes, Eagle has DRC, and here are two magnificent examples of it:

On the left, you see one of the problems with a specific Eagle library. Notice how all the pads for that component are touching? No, that won’t work, and no, Eagle didn’t catch that. On the right, you see what happens when you don’t run DRC in Eagle.

KiCad is more forgiving than Eagle. You simply can’t connect traces on different nets. KiCad will not allow you to move a trace onto a pad it shouldn’t be connected to like [Quinn]’s above example. That doesn’t mean you can get away with anything when designing a PCB; fab houses still have design rules, like a minimum track width of 6mil, minimum drill diameters, and support for blind, buried, and micro vias.

Before you start laying out your PCB, it’s a good idea to check out the design rules for a board house before placing parts and drawing traces. The design rules for Seeed Studio can be considered the least common denominator — if you can make a design with these rules, you can have your board manufactured everywhere. Practically, this means a minimum trace width of 10mil, a minimum separation of 10mil, and a minimum hole size of 0.3mm.

Once the design rules are set, build your board and run a DRC before generating your Gerbers from the Tools -> DRC menu. Any problems will automagically show up.

Exporting Gerbers

For the last few months, OSHPark has accepted native KiCad uploads. If you want to send your board off to OSHPark, all you need to do is drop your board file right onto their upload interface. What happens if you’re sending your board off to Seeed Studio, DirtyPCB, or any other board house? There, you’re going to have trouble. You’ll need to generate Gerber files for these board houses.

Gerbers are vector files for 2D images, and each individual file represents one layer of the board. A single Gerber file tells the board house exactly how to build the top copper layer, while another tells the board house where to put the bottom silkscreen and so on. The standard names (more precisely, the file extention) for each of these layers are:

• Top Layer     filename.GTL
• Top Solder Mask     filename.GTS
• Top Silkscreen     filename.GTO
• Bottom Layer     filename.GBL
• Bottom Solder Mask     filename.GBS
• Bottom Silk Screen     filename.GBO
• Board Outline     filename.GKO
• Drills     filename.TXT

That’s all well and good, but how do you create these files? From PCBnew, go to File -> Plot, and check out the window that pops up.

The plot window gives you a few options. To generate your Gerbers, select the following layers for a two-layer board:

• F.Cu and B.Cu – these are your front and back copper layers, and will have the file extension .GTL and .GBL.
• F.SilkS and B.SilkS – this is the front and back silk screen, with file extensions .GTO and .GBO.
• F.Mask and B.Mask – this is the front and back soldermask.  What is the difference between a silk screen and soldermask? Go look at a Raspberry Pi or an Arduino. The silk screen is white, the solder mask is green or blue. The silk screen is (mostly) for outlines of footprints and names of components. The soldermask protects the copper layer from corrosion and (surprise) keeps solder off the traces. The file extentions are .GTS and .GBS.
• Edge.Cuts – this is the board outline, with the file extension .GKO.

Select all of these layers, then take a look at the options you have. If you want to plot the values and references for each part on the silk screen layer, select ‘Plot footprint values’ and ‘Plot footprint references’. To save one email between you and your fab house, select ‘Use Protel filename extensions’ under the Gerber Options box. Select the output directory for your Gerbers and hit ‘Plot’.

That’s not quite all there is to do, because you still need the drill file. The Drill file is the black sheep of the Gerber format. I’m not even sure it is part of the Gerber format, but like language, reality is defined by common parlance so we’ll just say the drill file is also a Gerber.

The Drill file is simply a gigantic file telling a CNC router where all the holes for the vias need to go. Press the ‘Generate Drill File’ button, don’t worry about the options, and save a drill file with the rest of your Gerbers.

To the right is what you’ll end up with: a bunch of files with weird file extensions. Put all of these files in a ZIP archive, and drop them onto the upload page for OSHPark, DirtyPCB, or Seeed Studio. Even Advanced Circuits will take Gerbers.

Additionally, there are a few more interesting options to select when generating Gerbers. The ‘Subtract soldermask from silkscreen’ gives more definition to the silkscreen itself, and if you’re ever going to experiment with the artistic side of PCB manufacturing, you would do well to hit that option for one of your board revisions.

Also, KiCad has built-in support for tented and untented vias. What are tented vias? Check this out:

The standard Arduino Leonardo is actually a very pretty board with visible traces snaking around under the soldermask. The vias for these traces are covered with soldermask. This is called a tented via. The reason for doing this is to prevent an accidental short with the via’s annular ring. The value of tented vias is obvious on an Arduino board — kids are going to stick pins in vias and generally make a mess of things. Untented vias, on the other hand, don’t have soldermask over the annular ring. This is good for reworking boards, but the finished product isn’t as pretty.

Yes, you can do tented or untented vias in other PCB design programs. I’ve done them in Eagle, but the process there is a little backwards and doesn’t make a whole lot of sense. A single button to tent (or untent) vias in KiCad is a really neat feature.

Interactive Router And 3D

KiCad has a lot of features that are well outside the usual workflow that goes into ‘creating a PCB’, but some of these tools are really, really cool. From the Pcbnew window, select View -> 3D Viewer, and you’ll get something that looks like this:

That’s a 3D model of the board we’ve been making, with most of the parts automatically placed in their respective positions. With this model, you can export to VRML, import into OpenSCAD, and turn your electronic design into a mechanical design. The intersection of PCB and mechanical design is sort of a holy grail for engineers, and very few tools have the ability to model electronic components in physical space like KiCad. Altium can do it (and can do it well), and Eagle will be getting this ability soon (because Autodesk). If you ever need to make an enclosure for one of your PCBs, this is how you do it.

There is one trick I would like to mention regarding the 3D view. Some parts won’t have 3D models when you first open up the 3D view. That’s easily fixed – just click on the part in Pcbnew and use the hotkey ‘E’. This opens up the Footprint Properties window, with a tab for 3D settings. Here, you can select a 3D shape from the standard KiCad VRML files, and scale and offset these shapes to fit your board.

Lastly, let’s take a look at KiCad’s interactive router. This is an extremely powerful feature of KiCad that makes laying out huge boards a lot easier. By selecting a single trace and moving it around the board, the interactive router will move other traces out of the way. It will also route a trace from point A to point B using the most efficient path, without intersecting other traces. The best example of this comes from one of the KiCad devs:

I would demonstrate this on my tiny, simple board but there simply aren’t that many traces for the interactive router to be interesting.

That’s it for KiCad

In part one of this KiCad tutorial, I went over how to create a schematic. Part two covered how to make a part from scratch and turn that schematic into a PCB that’s ready to head off to fabrication. Now, after six thousand words you know how to make a schematic, a footprint, a package, a PCB, and make sure everything is correct.

We’re done with KiCad, fulfilling the constant requests I’ve gotten since starting this series of posts. Now, finally, I can turn my efforts to Open Source PCB design tools you shouldn’t use. In the next post of this series, I’m going to be covering something unprecedented. I will have a tutorial on how to create a part in Fritzing from scratch. This has never been documented before, and even the Fritzing devs say it’s impossible. If you’re wondering, yes, the bounty I placed on a tutorial for creating a part from scratch has been claimed. Until then, keep not using Fritzing because it’s still terrible. Use KiCad.

SKiDL is very, very cool. It’s a bit of Python code that outputs a circuit netlist for KiCAD.

Why is this cool? If you design a PCB in KiCAD, you go through three steps: draw the schematic, assign footprints to the symbolic parts, and then place them. The netlist ties all of these phases together: it’s a list of which parts are connected to which, the output of schematic capture and the input for layout. The ability to generate this programmatically should be useful.

For instance, you could write a filter circuit generator that would take the order, cutoff, and type of filter as inputs, and give you a spec’ed netlist as output. Bam! In your next design, when you need a different filter, you just change a couple of variables. Writing your circuits as code would make arranging the little sub-circuits modular and flexible, like functions in code.

At the very least, it’s an interesting alternative to the mouse, click, drag, click paradigm that currently dominates the schematic capture phase. Just as some of you like OpenSCAD for 3D modelling, some of you will like SKiDL for circuit design.

We’ve become so accustomed to the circuit diagram as the means of thinking about circuits that we’re not sure that we can ever give up the visual representation entirely. Maybe designing with SKiDL will be like sketching out block diagrams, where each block is a bit of Python code that generates a circuit module? Who knows? All we know is that it sounds potentially interesting, and that it’ll certainly be mind-expanding to give it a try.

Give it a shot and leave feedback down in the comments!

KiCad is the premiere open source electronics design automation suite. It’s used by professionals and amateurs alike to design circuits and layout out printed circuit boards. In recent years we’ve seen some incredible features added to KiCad like an improved 3D viewer and push-and-shove routing. This Friday at 10 am PST, join in a Hack Chat with KiCad lead developer [Wayne Stambaugh] to talk about recent improvements and what the team has planned for KiCad in the future.

[Wayne] has been an electronics engineer for over 30 years with a wide range of experience in analog and digital hardware design and embedded and application software design. He started hacking on KiCad ten years ago when the project was first opened to public development and a little over two years ago became the project leader. This is an excellent opportunity to learn how the development team works, what their current goals are, and to talk all things KiCad.

Don’t miss this Hack Chat! Here’s a handy web tool to help convert Jan. 20 at 10:00 am PST to your local time.

Wait, There’s Tindie Too!

Also on Friday, taking place just an hour before the KiCad chat, is a Tindie Hack Chat. All are welcome as the 9:00 am PST discussion gets under way. Discussion will focus on all aspects of selling unique hardware on Tindie.

Here’s How to Take Part:

Hack Chat are live community events that take place in the Hackaday.io Hack Chat group messaging. Visit that page (make sure you are logged in) and look for the “Join this Project Button” in the upper right. Once you are part of the project, that button will change to “Team Messaging” which takes you to the Hack Chat.

You don’t have to wait for Friday, join Hack Chat whenever you like and see what the community is currently talking about.

 Join Us Next Week Too for CircuitPython

Block out your calendar for noon PST on Friday the 27th for next week’s Hack Chat. Joining us are Adafruit’s Ladyada, Tony DiCola, and Scott Shawcoft. They’ll be leading a discussion about CircuitPython Beta, Adafruits new extension to MicroPython that adds SAMD21 support and other enhancements.

EAGLE user? We hope you like subscription fees.

Autodesk has announced that EAGLE is now only available for purchase as a subscription. Previous, users purchased EAGLE once, and used the software indefinitely (often for years) before deciding to move to a new version with another one-time purchase. Now, they’ll be paying Autodesk on a monthly or yearly basis.

Lets break down the costs. Before Autodesk purchased EAGLE from CadSoft, a Standard license would run you $69, paid once. The next level up was Premium, at $820, paid once. The new pricing tiers from Autodesk are a bit different. Standard will cost $15/month or $100/year, and gives similar functionality to the old Premium level, but with only 2 signal layers. If you need more layers, or more than 160 cm^2 of board space, you’ll need the new Premium level, at $65/month or $500/year.

This is a bad deal for the pocket book of many users. If you could have made do with the old Standard option, you’re now paying $100/year instead of the one-time $69 payment. If you need more space or layers, you’ll likely be up to $500/year. Autodesk also killed the lower cost options for non-commercial use, what used to be a $169 version that was positioned for hobbyists.

The free version still exists, but for anyone using Eagle for commercial purposes (from Tindie sellers to engineering firms) this is a big change. Even if you agree with the new pricing, a subscription model means you never actually own the software. This model will require licensing software that needs to phone home periodically and can be killed remotely. If you need to look back at a design a few years from now, you better hope that your subscription is valid, that Autodesk is still running the license server, and that you have an active internet connection.

On the flip side of the coin, we can assume that Eagle was sold partly because the existing pricing model wasn’t doing all it should. Autodesk is justifying these changes with a promise of more frequent updates and features which will be included in all subscriptions. But sadly, Autodesk couldn’t admit that the new pricing has downsides for users:

“We know it’s not easy paying a lump sum for software updates every few years. It can be hard on your budget, and you never know when you need to have funds ready for the next upgrade.”

In their press release, they claim the move is only good for customers. Their marketing speak even makes the cliche comparison to the price of a coffee every day. Seriously.

[Garrett Mace] summarized his view on this nicely on Twitter: “previously paid $1591.21 for 88 months == $18.08/mo. Moving to $65/mo? KICAD looks better.”

We agree [Garrett]. KiCad has been improving steadily in the past years, and now is definitely a good time for EAGLE users to consider it before signing on to the Autodesk Subscription Plan™.

[Jeff Tranter] has done a number of retrocomputing projects. But he wanted to tackle something more substantial. So he set out to build a 68000-based single board computer called the TS2 that he found in a textbook. He’s documented it in a series of blog posts (about 30 posts, by our count) and a video that you can see below.

The 68000 had a very rational architecture for its day. A flat memory space was refreshing compared to other similar processors, and the asynchronous bus made hardware design easier, too. While most CPUs of the era assumed bus devices could perform their service in a fixed amount of time, the 68000 used a handshake with devices to allow them to take the time they needed. Most other CPUs had to provide a mechanism for a slow device to stall the bus which was complicated and, in many cases, less efficient.

[Jeff] used KiCAD with an autorouter to lay out some PCBs and all his files are available on GitHub. [Jeff] is actually on his second version, and has substituted some hard-to-find parts with easier-to-source replacements. The detail in the postings is impressive, and the TS2 recalls a time when you couldn’t get your entire system in one IC package.

You didn’t hear it here, but a lot of 68000s escaped into the wild with some defects that affected very particular instructions. For example, if you have one, try doing a long quick add (ADDQ.L) to any indirect address register. It might work, but there is a reasonable chance the CPU will hang mysteriously. In those days, there was no firmware upgrading, either.

We’ve seen 68000s on a breadboard. We’ve even seen the 8-bit version dominated by an Arduino. It would be interesting to see what a modern PC would be like if the 68000 architecture had won the day back them. But we’ll never know.

We love custom clocks here at Hackaday, and are always thrilled to see each inventive means of time-keeping. In a seldom-seen take on the familiar device, the [Bastel Brothers]’s LED Strip Clock’s sleek profile finds itself in good company.

The clock is a two-metre strip of 60 LEDs; every minute past the current hour corresponds to one lit LED, every fifth LED is turned to red in order to make reading minutes easier. So 3 red LEDs +3 green LEDs=18 minutes, with the hour marked by a third color. Sounds complex, but the [Brothers] are quick to say you get used to it quickly, especially when the 6 o’clock LED is centered at some noticeable object or feature.

A custom and home-etched PCB using an ATtiny4313 instead of an Arduino are the clock’s brains, a Maxim DS1307 for time-keeping, and a simple rotary encoder as the input for setting the time. The processor was seen as excessive at the time, but looking back the [Bastels] say it hasn’t left much room for upgrades or future tinkering, so it wasn’t really worth saving a few bucks in this case. The code is available here but, as the [Brothers] admit —  use it at your own risk since it’s a bit of a mess. Still, it works and looks damn good at the same time.

We recently featured a different kind of linear clock, but really, you could spend days browsing our archives of many magical and wondrous clocks.

One common complaint we hear from most new KiCAD users relates to schematic and footprint libraries. The trick is to use just one schematic symbol and footprint library each with your project. This way any changes to the default schematic libraries will not affect your project and it will be easy to share your project with others without breaking it. I’ve spent some time refining this technique and I’ll walk you through the process in this article.

We have covered KiCAD (as well as other) Electronic Design Automation (EDA) tools several times in the past. [Brian Benchoff] did a whole series on building a project from start to finish using all the various EDA packages he could lay his hands on. No CAD or EDA software is perfect, and a user has to learn to get to grips with the idiosyncrasies of whichever program they decide to use. This usually leads to a lot of cussing and hair pulling during the initial stages when one can’t figure out “How the hell do I do that?”, especially from new converts who are used to doing things differently.

Read on to learn the best practices to use when using KiCAD and its library management.

Project Management

KiCAD keeps schematic symbols and component footprints in separate libraries and you need to link a symbol to a footprint using one of several different methods. This puts off a lot of folks, but it works quite well once you get used to it.

In the old days before computers, most designers would first quickly draw out a schematic, then create a “bill of materials” where they flesh out the specifications of the components to be used. This would then help them to choose the component footprints, leading to the board layout phase. KiCAD tries to follow this work-flow. Here’s a typical folder structure I use to organize a KiCAD project, having refined this technique over many years of working with the software.

doodad
 ↳3d_models     // .STEP and .WRL model files for all footprints
 ↳datasheets    // data sheets for components used
 ↳gerber        // final production files
 ↳images        // SVG images and 3D board renders
 ↳lib_sch       // schematic symbols
 ↳lib_fp.pretty // footprints
 ↳pdf           // schematics, board layouts, dimension drawings

Managing Schematic Libraries

When you draw a schematic using symbols from the built-in libraries bundled with KiCAD, EESCHEMA creates a local backup library — doodad-cache.lib. Once you’re done drawing your schematic, copy this file to the ↳lib_sch folder  and rename it to doodad.lib.

Next, go to ↳PREFERENCES↳Component Libraries , select “CURRENT SEARCH PATH LIST” to point to your local project folder ~/doodad/, click the ADD button at the TOP of the pop up window (NOT the Add button in the middle of the pop up), and finally select doodad.lib. It gets added below the currently selected library in the list.

KiCAD reads these libraries in sequential order, so you need to select doodad.lib and bring it to the top of the list using the UP button. If there’s a symbol with the same name in different libraries, then the first instance of it gets used. At this point, you can either remove all the other listed libraries, or just ignore them as long as you ensure that every symbol you use gets added to doodad.lib and get’s called only from that file.

Your project now uses just one schematic symbol library — ~/doodad/lib_sch/doodad.lib — and any changes to the default schematic libraries will not affect your project. Moreover, using the above defined folder structure, it’s easy to share your project on GitHub. When your project gets cloned or downloaded, this ensures there are no library conflicts.

All of the above may change when KiCAD implements s-expression formats in EESCHEMA and schematic libraries (already implemented in PCBnew), so we’ll revisit this at that time.

Assigning Footprints to Symbols

There’s several ways of doing this, but essentially, you select a schematic symbol, and assign it a footprint from one of the default libraries. Ever since KiCAD moved footprint libraries to GitHub, this has been a cause of heartburn for many. For one, all libraries are hosted online, and KiCAD needs to look them up every time you fire it up. For those who don’t change this behaviour, it slows down the program during startup, if you’re not connected to the web. Online libraries are a good idea because footprints stay updated, but it is a sure fire way to break your designs should one of the footprints used in your design change. This won’t show up for you immediately, because you will have to explicitly re-read the net-list and get KiCAD to replace changed footprints. But for someone else who clones your design, and their KiCAD version loads up the updated footprint, it WILL break things.

The solution is to clone all the KiCAD libraries to a local location on your computer, and then point KiCAD to this location. But when you do this, it negates the advantage of having access to updated libraries. I don’t think there’s an ideal way to make it work, but here’s what works for me.

I clone the GitHub libraries to my local computer, and keep them updated by regular pulls. This helps me use existing footprints or modify them to suit my requirements. But my project does not use any of those cloned libraries directly. Instead, I generate a project specific footprint library that contains all of the footprints (~/doodad/lib_fp.pretty) used in the project. Once again, this ensures that when the project gets cloned, all of the right footprints are already available without depending on external source libraries.

How to Make KiCAD Footprints Local and Project-Unique

Start by cloning (from GitHub) the KiCAD footprint repository to your computer. This is best done using the ‘Footprint Libraries Wizard‘ from within PCBnew. In my case, I have cloned it to ~/kicad_sources/library-repos. In KiCAD’s PCBnew, select ↳PREFERENCES ↳CONFIGURE PATHS and edit KISYSMOD to point to the local footprint library path (~/kicad_sources/library-repos).

In some cases, additional steps may be required to make things work. Select  ↳PREFERENCES ↳FOOTPRINT LIBRARIES MANAGER and determine the location of the “fp-lib-table” file used by PCBnew. This is a text file that tells PCBnew where to look for footprint libraries – on Github, local path etc. Open this file in a text editor, and check if it uses KISYSMOD as the path. If not, do a search and replace for all instances of current path and replace it with KISYSMOD.

Now, you can edit each schematic symbol, and add a footprint to it — either from within EESCHEMA, or using the stand alone Cvpcb module. Once all footprints have been assigned, make sure you re-generate the netlist before moving on to PCBnew.

You can now start PCBnew and read the netlist, which dumps all the footprints in a pile on the canvas. Select the Mode : footprint icon, then context-click on any ONE footprint, select ↳Global Spread and Place ↳Spread out all footprints.

This spreads out all the footprints making it easier to select and move them around. Once you’re done with your board layout, and all of your footprints are locked in, select FILE ↳Archive Footprints↳Create Library and Archive Footprints and provide the path/name to the .pretty folder in your project (~/doodad/lib_fp.pretty). This copies all the footprints used in your layout to the target folder.

Then, Preferences↳Footprint Libraries Wizard↳Files on my computer↳(navigate to ~/doodad/lib_fp.pretty) and make sure you select “To the Current Project Only” before hitting Finish. At this point, you have used footprints from KiCAD’s global libraries and applied them to schematic symbols, made a netlist, imported netlist in PCBnew, placed the footprints and routed the board, made an archive of all the footprints used, and configured PCBnew to use that archive library.

Next, return back to EESCHEMA, and edit the footprint association of each symbol to point to the new lib_fp.pretty folder instead of the local GitHub repository on your computer. The easiest way to do this is to open the .SCH file in a text editor and do a search/replace. In our present example, we will replace instances such as “Capacitors_ThroughHole” or “Resistors_ThroughHole” or “LEDs” with our local project library folder “lib_fp”

Open the schematic one last time, save a fresh netlist, open PCBnew, read this netlist, but this time select the CHANGE option under Exchange Footprint. Your board layout will now be using footprints saved in your lib_fp.pretty folder, and changes to the KiCAD global libraries will not affect the layout.

Wrapup

This may sound a bit convoluted in the beginning, but over time it becomes quite easy, and you can eliminate some steps as you get better. For example, I already have my own library for most of the common parts that I use, and copy these footprints before starting off on a new project. Over time, as you get better at it, you will start building your own schematic symbols and footprints from component data sheets instead of using external versions. Like I said at the beginning, it’s not perfect, and for me this process works very well. If you have comments or suggestions on making this better, chime in and let us know.

Google’s voice assistant has been around for a while now and when Amazon released its Alexa API and ported the PaaS Cloud code to the Raspberry Pi 2 it was just a matter of time before everyone else jumped on the fast train to maker kingdom. Google just did it in style.

Few know that the Google Assistant API for the Raspberry Pi 3 has been out there for some time now but when they decided to give away a free kit with the May 2017 issues of MagPi magazine, they made an impression on everyone. Unfortunately the world has more makers and hackers and the number of copies of the magazine are limited.

In this writeup, I layout the DIY version of the AIY kit for everyone else who wants to talk to a cardboard box. I take a closer look at the free kit, take it apart, put it together and replace it with DIY magic. To make things more convenient, I also designed an enclosure that you can 3D print to complete the kit. Lets get started.

The Teardown

A shout out to my friend [Shabaz] in the UK for sending me a copy of the MagPi. The “Google AIY Projects Voice Kit”(henceforth known as the kit) contains two PCBs and a bunch of other stuff. The Voice HAT which looks like a Sound-Card-On-A-Diet has very limited number of components. I will detail each section and draw the KiCAD schematic for the same one by one

Servos

Starting from the left side, there are 6 sets of 3-pin headers that are labelled ‘Servos’. The intended servo control is made possible using the Raspberry Pi 3’s on-board PWM module. Each set has a GPIO pin, 5V and GND connection. The GPIO pin does not connect directly to the Raspberry Pi 3’s header but rather through 220Ohm current limiting resistors (labelled R1-R6).

Power Supply

Just south of these are devices labeled Q5 and Q6 which I am assuming are part of a power supply selection circuit. Correct me if I am wrong but here is my estimate. The working is simple where Q5 only turns ON when the input voltage is greater than the 5V from the USB port. A simple comparator should do so I am using the LM393 for reference.

Communication Interfaces

North of the ‘Servo’ headers is J15 labelled I2C that directly connect to the Raspberry Pi 3 header. That means these should not be connected to anything with 5V pull-ups. They are not being used on the board but we will discuss more on this later. Right next to it is the SPI and 2-pin UART headers. Again these connect directly to the main header and serve only as a breakout.

The DAC and EEPROM

A little lower and we arrive at the boxed circuit with a 16-Pin QFN marked ‘AKK BDQ’. This is the Maxim MAX98357A(PDF) which is an I2S DAC with a class D amplifier. It drives the speaker directly however since there is only one output, it can only be mono or combined stereo. It’s still pretty rocking for the budget.

The interesting thing is the presence of JP6 which seems to have all the I2S connections from the Maxim MAX98357A and a few other select lines. Combined with the two vias that connect to the second speaker output, you could possibly fit another Maxim MAX98357A breakout board on top to get stereo sound. I am going to do the schematic and make it downloadable and if you want to give it a shot let me know the results. Consider it optional homework.

Next to the DAC is an 8-pin SSOP which is a 24C32 (PDF) I2C EEPROM. It’s not connected to the I2C header I talked about earlier but rather to pins 27 and 28 of the Raspberry Pi 3 header. According to the Raspberry Pi Foundation’s blog.

“The EEPROM holds the board manufacturer information, GPIO setup and a thing called a ‘device tree‘ fragment – basically a description of the attached hardware that allows Linux to automatically load the required drivers.”

So its got some extra sauce that makes things tick and I could use a BusPirate to Dump the data but I am not sure if Google considers it Intellectual Property so I won’t. I have an alternative for it as well so read on.

Drivers

Moving towards the right, we find 4 headers marked ‘Drivers’. These are MOSFET circuits for controlling loads such as relays. [Shabaz] did a great job tracing out the components on this one and the 3 pins are GPIO, 5V and Driver.

The MOSFETs can drive loads of up to 500mA each thanks to a polyswitch however the GPIOs are available for use directly as well. Loads to be driven should be connected between the pins marked ‘+’ and ‘-‘. The header pin on the left is a direct access to GPIOs header pins from the Raspberry Pi 3 and the schematic reflects the same.

Use these to connect LEDs or similar devices to indicate the operation of the relays or loads.

Microphone and Button Connectors

More interesting stuff is happening on the right side’s upper right with a push button and two JST connectors. The 4 pin connector is meant for the push button that sits on top of the assembled enclosure. The small PCB mounted push button is wired in parallel with the external switch and can be used in its place while setting up and testing. The 5 pin JST is for the microphone connector and has all the I2S pins.

The Microphones

Lastly, the microphone board is marked 432 QDF21G, and has Knowles SPH0645LM4H MEMs digital microphones that talk I2S directly.

That’s It!

That about wraps up the teardown and all the information required to make your own AIY Kit. The KiCAD schematic files are available for download from GitHub however I leave you with the fun part which is the layout and routing.

Here is some food for thought. Some parts can be omitted and the size of the hat can be shrunk down to the Pi Zero pHat.

For simplicity reasons, I am using the preconfigured OS image from the Google AIY page. It is a tad short of 900MB and can be downloaded directly from Goolge (huge file).

Add A Shutdown Button

You probably noticed the small golden button next to the big green button in the image above and that is the first part of the exercise. It is a shutdown button and is added because I don’t want to SSH to the box every time I want to turn it off safely.

Get the button you want to use and add two wires with female headers. This bit works even without the Voice Hat so feel free to try it out. Next if you have a voice hat, add male headers to the I2C part. You may choose any other pins and it will still work. Connect the button to the SDA or GPIO 2 and boot the Pi 3 up.

Open up your favourite text editor and copy-paste the following code into it.

#!/bin/python
# Simple script for shutting down the raspberry Pi at the press of a button.
# by Inderpreet Singh

import RPi.GPIO as GPIO
import time
import os

# Use the Broadcom SOC Pin numbers
# Setup the Pin with Internal pullups enabled and PIN in reading mode.
GPIO.setmode(GPIO.BCM)
GPIO.setup(02, GPIO.IN, pull_up_down = GPIO.PUD_UP)

# Our function on what to do when the button is pressed
def Shutdown(channel):
    os.system("sudo shutdown -h now")

# Add our function to execute when the button pressed event happens
GPIO.add_event_detect(02, GPIO.FALLING, callback = Shutdown, bouncetime = 2000)

# Now wait!
while 1:
    time.sleep(1)

Save the files in your /home/pi folder as shutdown.py

In a terminal type the following commands

 chmod +x shutdown.py python shutdown.py & 

This should make the script run in the background. If you press the button, the Pi should shutdown immediately. You may choose to add a delay by uncommenting the sleep call in the example code. Alternatively, you may also change the GPIO by replacing the appropriate number in the python script.

Cool! Now we can shutdown by pressing a button.

Add a USB Sound Card

The obvious alternative to the Google AIY Voice Hat is to use any USB Sound Cards that are available from a number of sources. The simplest way is to just plug one in and configure the software to use that instead of the Hat but when there two drivers installed, the python scripts need to be reconfigured to make everything seamless.

Once you plug in the soundcard, the first thing to do is check if it was recognized or not. In the terminal window, type in:

 aplay - l 

‘aplay’ is used by the scripts to speak out the replies so you should be able to see two sound devices. Note that the onboard sound has been disabled from within the config.txt (see device tree reference) and can be enabled if you plan to use a USB microphone instead of the sound card. The windows output should look like the image below.

I would like to set the USB sound card as the default audio, and for that we need to modify the /etc/asound.conf .

sudo nano /etc/asound.conf

Delete the existing content and replace it with text as shown below. Though this sets the default input and output device to the USB device, there is one more step to make things work. (To exit nano, use Ctrl+x, y, return)

Next we edit to audio.py file that handles all the audio playing and recording functionality. For that, open up the file in your favourite text editor; mine is nano:

 sudo nano /home/pi/voice-recognizer-raspi/src/audio.py 

Scroll down to the part that says ‘arecord’ which is in the __init__ function. Apparently there is a dedicated process that keeps the recorder running as I will show in the video. For now, we want to edit the arguments so that it uses the USB Card to capture audio instead of the original Voice Hat. A simple modification to use ‘-D’, ‘sysdefault:CARD=1’ should suffice as shown in the image below.

A similar change is require for the aplay function a little further in the code.

With that, the hack is complete! Double click the ‘test_audio.py’ to check if audio works. We are missing just one part of the puzzle though — the ‘listen’ button! So simply wire a push button between GPIO23 and the adjacent ground pin and then run ‘src/main.py’ to start playing with a DIY Google AIY.

A Demo

A small video demo of the proposed hack with a USB sound card, external speaker and a cheap microphone.

An Enclosure

The 3D printed enclosure is designed in Fusion360 and the STL files are part of the GitHub repository. You can use the same enclosure for a number of projects since there are standoffs for the Raspberry Pi and the ports are brought out for convenience. There is a lot of space inside to add hats and additional circuits.

I made the enclosure split from the middle so that it becomes easy to access the GPIOs. The whole thing will press fit including the top cap which has holes for three buttons. I though it would make sense to have smaller buttons since the result is expected to be tougher than cardboard. There is ample space for the speaker should you choose to include one that is slightly different.

I have not had a chance to print one out and will update this page once there is any progress in the topic. Here is the render of the design.

Summary

Google has already had their APIs open to the public, but the preconfigured Raspbian image will help a lot of people to get started. I have tried to layout the basics of the sound card as well as give out the plans for an equivalent card if you want to make one. For others the option to use an external sound card is explained and demonstrated and I hope it inspires people to really get into such projects. The world needs more AIY and here is your chance to get started, so what are you waiting for? Get hacking.

For anyone with interest in electric vehicles, especially drives and control systems for EV’s, the Endless-Sphere forum is the place to frequent. It’s full of some amazing projects covering electric skateboards to cars and everything in between. [Marcos Chaparro] recently posted details of his controller project — the VESC-controller, an open source controller capable of driving motors up to 200 hp.

[Marcos]’s controller is a fork of the VESC by [Benjamin Vedder] who has an almost cult following among the forum for “creating something that all DIY electric skateboard builders have been longing for, an open source, highly programmable, high voltage, reliable speed controller to use in DIY eboard projects”. We’ve covered several VESC projects here at Hackaday.

While [Vedder]’s controller is aimed at low power applications such as skate board motors, [Marcos]’s version amps it up several notches. It uses 600 V 600 A IGBT modules and 460 A current sensors capable of powering BLDC motors up to 150 kW. Since the control logic is seperated from the gate drivers and IGBT’s, it’s possible to adapt it for high power applications. All design files are available on the Github repository. The feature list of this amazing build is so long, it’s best to head over to the forum to check out the nitty-gritty details. And [Marcos] is already thinking about removing all the analog sensing in favour of using voltage and current sensors with digital outputs for the next revision. He reckons using a FPGA plus flash memory can replace a big chunk of the analog parts from the bill of materials. This would eliminate tolerance, drift and noise issues associated with the analog parts.

[Marcos] is also working on refining a reference design for a power interface board that includes gate drivers, power mosfets, DC link and differential voltage/current sensing. Design files for this interface board are available from his GitHub repo too. According to [Marcos], with better sensors and a beefier power stage, the same control board should work for motors in excess of 500 hp. Check out the video after the break showing the VESC-controller being put through its paces for an initial trial.

The Nokia 3210 is the greatest cell phone ever made. The battery lasted for days, custom color covers were available at every mall kiosk, it had the Snake game, and the chassis for this phone was finely crafted out of the crust of neutron stars. It was indestructible; it is the reason we now appreciate technology over more impermanent concepts like relationships and love.

For his Hackaday Prize entry, [Bastian] is bringing the Nokia 3210 into this century. He’s designing a circuit board with the same footprint, the same button layout, and a better screen that drops right into the lovely plastic enclosure of the 3210.

The current BOM for the upgraded 3210 includes an STM32 F7 microcontroller, which is more or less the current top of the line ARM micro you can get. For wireless, [Bastian] is using an A7 GSM/GPRS module and an ESP8266 for a little bit of WiFi. For a dumbphone, this is ludicrously overpowered. Provided [Bastian] gets a prototype up and running, there will be some interesting applications for a device this powerful in a package this indestructible.

One of the things [Bastian] has been butting his head against with this project is KiCad. Microvias don’t work like they should in KiCad — they’re restricted to the outer layers only. This is a problem for routing a complex board like this, so [Bastian] wrote a patch that gives KiCad an ‘I know what I’m doing mode’ for microvias everywhere.

This is truly the spirit of The Hackaday Prize: not only is [Bastian] building something ridiculous, he’s also creating the tools to do it.

Musicians have an array of electronic tools at their disposal to help make music these days. Some of these are instruments in and of themselves, and [Wai Lun] — inspired by the likes of Choke and Shawn Wasabi — built himself a midi fighter

Midi fighters are programmable instruments where each button can be either a note, sound byte, effect, or anything else which can be triggered by a button. [Lun]’s is controlled by an ATmega32u4 running Arduino libraries — flashed to be recognized as a Leonardo — and is compatible with a number of music production programs. He opted for anodized aluminum PCBs to eliminate flex when plugging away and give the device a more refined look. Check it out in action after the break!

[Lun] designed the project in Fusion 360 and KiCad with plenty of room to spare for some electronic art — gotta love Daft Punk. He’s using Sanwa OBSC 24mm arcade buttons for their premium quality and two SK6812 mini LEDs apiece for a slick lighting effect when they’re pressed.

After receiving the manufactured boards and parts, a quick test fit flowed right into final assembly. With the ATmega32u4 flashed and programmed, he was ready to rock. Down the line, [Lun] wants to have a GUI to configure the notes each button plays without tinkering around in the code, but it works great for now.

For an astounding acoustic to electronic instrument conversion, check out this MIDI accordion!

[Sean Hodgins]’s calls his three-part video series an Arduino Neural Network Robot but we’d rather call it an enjoyable series on prototyping, designing a board with surface mount parts, assembling it, and oh yeah, putting a neural network on it, all the while offering plenty of useful tips.

In part one, prototype and design, he starts us out with a prototype using a breadboard. The final robot isn’t on an Arduino, but instead is on a custom-made board built around an ARM Cortex-M0+ processor. However, for the prototype, he uses a SparkFun SAM21 Arduino-sized board, a Pololu DRV8835 dual motor driver board, four photoresistors, two motors, a battery, and sundry other parts.

Once he’s proven the prototype works, he creates the schematic for his custom board. Rather than start from scratch, he goes to SparkFun’s and Pololu’s websites for the schematics of their boards and incorporates those into his design. From there he talks about how and why he starts out in a CAD program, then moves on to KiCad where he talks about his approach to layout.

Part two is about soldering and assembly, from how he sorts the components while still in their shipping packages, to tips on doing the reflow in a toaster oven, and fixing bridges and parts that aren’t on all their pads, including the microprocessor.

In Part three he writes the code. The robot’s objective is simple, run away from the light. He first tests the photoresistors without the motors and then writes a procedural program to make the robot afraid of the light, this time with the motors. Finally, he writes the neural network code, but not before first giving a decent explanation of how the neural network works. He admits that you don’t really need a neural network to make the robot run away from the light. But from his comparisons of the robot running using the procedural approach and then the neural network approach, we think the neural network one responds better to what would be the in-between cases for the procedural approach. Admittedly, it could be that a better procedural version could be written, but having the neural network saved him the trouble and he’s shown us a lot that can be reused from the effort.

In case you want to replicate this, [Sean]’s provided a GitHub page with BOM, code and so on. Check out all three parts below, or watch just the parts that interest you.

[Sean]’s neural network is one that learns using supervised learning, an approach where you iterate through a table of inputs and expected outputs. If you instead want your robot to learn from experimenting in its environment, called unsupervised learning, then check out [Basti]’s four-legged walking robot.

Since Autodesk’s acquisition, Eagle has been making waves in the community. The de facto standard for Open Hardware PCB design is now getting push-and-shove routing, a button that flips the board over to the back (genius!), integration with Fusion360, automated 3D renderings of components, and a bunch of other neat tools. However, Eagle is not without its warts, and there is a desire to port those innumerable Eagle board layouts and libraries to other PCB design packages. This tool does just that.

The tool is an extension of pcb-rnd, a FOSS tool for circuit board editing, and this update massively extends support for Eagle boards and libraries. As an example, [VK5HSE] loaded up an Eagle .brd file of a transceiver, selected a pin header, and exported that component to a KiCad library. It worked the first time. For another experiment, the ever popular TV-B-Gone .brd file was exported directly to pcb-rnd. This is a mostly complete solution for Eagle to KiCad, Eagle to Autotrax, and Eagle to gEDA PCB, with a few minimal caveats relating to copper pours and silkscreen — nothing that can’t be dealt with if you’re not mindlessly using the tool.

While it must be noted that most Open Hardware projects fit inside a 80 cm² board area, and can therefore be opened and modified with the free-to-use version of Autodesk’s Eagle, this is a very capable tool to turn Eagle boards and libraries into designs that can be built with FOSS tools.

Thanks [Erich] for the tip.

KiCad is twenty-five years old — like most PCB design software — and right now it’s the best Open Source tool to lay out your circuits, plop down a few resistors, and create a PCB from scratch. Over the last few years, a lot of people have been turning to KiCad to design some very impressive boards, something no doubt related to the fact that KiCad is free in both the beer and speech senses.

Join us this Friday for Hack Chat, we’re talking all about KiCad. If you have grievances or praise to heave onto the developers, this is the place to do it. Our guest for this week’s Hack Chat will be Wayne Stambaugh, project lead for KiCad. Among other things, Wayne is responsible for leading the KiCad product roadmap and he’s also one of the authors of the CvPcb Reference Manual

During this Hack Chat, we’ll discuss current and future features in everyone’s favorite Open Source EDA suite. This is a great chance to make suggestions and put forth wish list items. Wondering if KiCad is pronounced ‘Kai-CAD’ or ‘Key-CAD’? It’s the latter, but don’t let that stop you from asking Wayne to change that.

Items up for discussion include:

• The new features on the 2018 roadmap
• What’s happened in KiCad since the last KiCad Hack Chat
• What goes on under the hood, and why should you never trust the autorouter?
• Where do you turn when you’re just starting out in KiCad?

If you have something you’d like to ask the KiCad devs, make sure to add it to our discussion sheet. To do that, just leave a comment on the Hack Chat Event Page.

Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. This Hack Chat is going down Friday, January 5th at noon, Pacific time. Time Zones got you down? Here’s a handy countdown timer!

Click that speech bubble to the left, and you’ll be taken directly to the Hack Chat group on Hackaday.io.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.

Look through the last two decades of electronics project built on perfboard, and you’ll notice a trend. Perfboard is designed for through-hole parts, but ever more frequently, the parts we need are only available as surface mount devices. What does this mean for the future of all those protoboard, veroboard, and tagboard designs? It’s not good, but fortunately, there may be an answer. It’s perfboard designed for mounting SOICs, SOTs, and other surface mount devices.

Perfboard is an extremely simple concept. Most through-hole electronic components are built around 0.1″ or 2.54 mm spacing between pins. Yes, there are exceptions, but you can always bend the middle pin of a transistor and put it in a hole. SMT devices are different. You can’t really bend the pins, and the pin pitch is too small for the 0.1″ holes in traditional perfboard.

[electronic_eel] is changing that game up with his own design for perfboard. This perfboard has the traditional 0.1″ holes, but there are SMD pads sprinkled about between these holes. The result is being able to solder SOIC, SOT23-6, SOT23 and SOT363 devices directly to a board alongside 0603 and 0805 devices. Connect everything with a few beads of solder and you have a functional circuit made out of surface mount devices on something that’s still compatible with the old protoboard designs.

This isn’t the first time we’ve seen a new type of protoboard make it into production. A few years ago, Perf+, a bizarre ‘bus-based’ protoboard solution came onto the scene, although that wasn’t really designed for SMD parts. While [electronic_eel] doesn’t have any plans to sell his protoboard, the files are available, and you can easily design your own small piece of perfboard.

Way back in the day, at least five years ago, if you wanted to design a printed circuit board your best option was Eagle. Now, Eagle is an Autodesk property, the licensing model has changed (although there’s still a free version, people) and the Open Source EDA suite KiCad is getting better and better. New developers are contributing to the project, and by some measures, KiCad is now the most popular tool to develop Open Source hardware.

At FOSDEM last week, [Wayne Stambaugh], project lead of KiCad laid out what features are due in the upcoming release of version 5. KiCad just keeps improving, and these new features are really killer features that will make everyone (unjustly) annoyed with Eagle’s new licensing very happy.

Although recent versions of KiCad have made improvements to the way part and footprint libraries are handled, the big upcoming change is that footprint libraries will be installed locally. The Github plugin for library management — a good idea in theory — is no longer the default. Spice simulation is also coming to KiCad. The best demo of the upcoming Spice integration is this relatively old video demonstrating how KiCad turns a schematic into graphs of voltage and current.

The biggest news, however, is the new ability to import Eagle projects. [Wayne] demoed this live on stage, importing an Eagle board and schematic of an Arduino Mega and turning it into a KiCad board and schematic in a matter of seconds. It’s not quite perfect yet, but it’s close and very, very good.

There are, of course, other fancy features that make designing schematics and PCBs easier. Eeschema is getting a better configuration dialog, improved bus and wire dragging, and improved junction handling. Pcbnew is getting rounded rectangle and complex pad shape support, direct export to STEP files, and you’ll soon be able to update the board from the schematic without updating the netlist file. Read that last feature again, slowly. It’s the best news we’ve ever heard.

Additionally, this is one of the rare times you get to hear [Wayne] speak. This means the argument over the pronunciation of KiCad is over. It’s ‘Key-CAD‘ not ‘Kai-CAD‘. You can check out the entirety of [Wayne]’s State of the KiCad talk below.

Model rocketry hobbyists are familiar with the need to roll their own solutions when putting high-tech features into rockets, and a desire to include a microcontroller in a rocket while still keeping things flexible and modular is what led [concretedog] to design a system using 22 mm diameter stackable PCBs designed to easily fit inside rocket bodies. The system uses a couple of 2 mm threaded rods for robust mounting and provides an ATTiny85 microcontroller, power control, and an optional small prototyping area. Making self-contained modular sleds that fit easily into rocket bodies (or any tube with a roughly one-inch inner diameter) is much easier as a result.

The original goal was to ease the prototyping of microcontroller-driven functions like delayed ignition or altimeter triggers in small Estes rockets, but [concretedog] felt there were probably other uses for the boards as well and made the design files available on GitHub. (Thanks!)

We have seen stackable PCBs for rocketry before with the amazingly polished M3 Avionics project, but [concretedog]’s design is much more accessible to some hobbyist-level tinkering; especially since the ATTiny85 can be programmed using the Arduino IDE and the boards themselves are just an order from OSH Park away.

[via Dangerous Prototypes Blog]

Hipster hardware! [Bunnie] found something interesting in Tokyo. It’s a LED matrix display, with a few PDIP chips glued onto the front. There are no through-holes or vias, and these PDIPs can’t be seen through on the back side of the board. Someone is gluing retro-looking chips onto boards so it looks cool. It’s the ‘gluing gears to everything therefore steampunk’ aesthetic. What does this mean for the future? Our tubes and boxes of 74-series chips will be ruined by a dumb kid with a hot glue gun when we’re dead.

Is it Kai-CAD or Key-CAD? Now you can share your troubles with the greatest problem in Electronic Design Automation with others.

Speaking of unimaginable problems in EDA suites and PCB design tools, here’s a Git-based visual version control thingy for Eagle. Cadlab.io is a version control system for Github and Eagle that offers visual diff of PCB layouts and schematics. Neat? Yes, especially if you have more than one person working on a board.

How about a 3D printed business card embosser? [Taekyeom] designed and printed a pair of 3D rollers, one of which is embossed with the ‘negative’ of a design, the other with the ‘positive’ of a design. When rolled against each other, these rollers mesh and putting a piece of paper through the pinky pinching machine embosses paper. Add a frame, a handle, and a few zip ties for belts, and you have a fully 3D printed paper embosser.

There’s a new ransomware that encrypts your files and won’t allow you to access them until you pay someone some crypto. Big news, huh? Well, yes, actually. The HC7 Planetary ransomware is apparently the first bit of ransomware that accepts Etherium. ETH is all grown up now.

Aw, snap, 3D printers with automatic tool changing. This is a project from E3D that shows off magnetic (?) extruders and hot ends for 3D printers. You can change your hot end (and nozzle, and filament) in mid-print. What does this mean? Well, swapping filament is the most obvious use case, but the Prusa system might have this nailed down. What is more interesting is swapping hotends, allowing you to print in multiple temperatures (and different materials), and maybe even different nozzle sizes. This is coming to MRRF, the greatest 3D printing con on the planet. MRRF is happening in March 23-25th in beautiful scenic Goshen, Indiana.

A hardware demoscene? Yes, it’s true! #badgelife is a hardware demoscene wrapped up around wearable conference badges. We just had a meetup in San Francisco this week, and the talks were amazing. [Kerry Scharfglass] talked about scaling one Diamond Age badge to one hundred Diamond Age badges. [Whitney Merrill] talked about building badges for the Crypto and Privacy village at Defcon. If you’re into electronics, you are, by default, into manufacturing and this is the best education in manufacturing and logistics you will ever get. The true pros know how to reduce air freight costs by two hundred percent!