Using KiCad

I have been exper­i­ment­ing this week with cir­cuit design and pcb lay­out tools. My exper­i­ence is with Altium but the price is rather hefty for my fairly simple require­ments and while I have used Altium for a few years I never actu­ally liked it, there are a lot of issues with the sys­tem. I con­sidered the vari­ous online tools and Eagle before decid­ing to give KiCad a go.

KiCad is an open source bundle of tools which has been rap­idly increas­ing in qual­ity over the last few years. CERN is provid­ing pro­fes­sional devel­op­ment sup­port and they have recently trans­ferred from a ‘build the source’ release struc­ture to stand­ard point releases.

I have played with KiCad for most of the week. It is good, I could do everything I needed to for the basic board I was doing, but some of it was a struggle. There are a lot of rough edges, how­ever the com­munity seems strong and most of the issues I encountered are in the pro­cess of being fixed.

There are sev­eral pro­jects under the KiCad ban­ner which loosely inter­op­er­ate, it seems they have had vary­ing amounts of coordin­a­tion over the years. Kicad itself is a pro­ject man­ager and applic­a­tion laucher. Ees­chema is the schem­atic design soft­ware. Pcb­new does the PCB lay­out. There are other tools I haven’t played with yet, such as a ger­ber viewer.

One of the issues is the cooper­a­tion between these applic­a­tions. For example the con­trols such as key­board short­cuts and mouse beha­viour are incon­sist­ent (This is flagged to be fixed by intro­du­cing a global short­cut man­ager). For a while (since fixed) pcb­new had pan­el­iz­a­tion fea­tures avail­able when launched stan­dalone but not when launched from within kicad . These sort of prob­lems mean that it feels more like using sev­eral dif­fer­ent pro­grams than a uni­fied suite.

Break­ing news

I have pub­lished a writeup of the board I designed, at https://​david​.tul​loh​.id​.au/​g​r​i​d​e​y​e​-​u​sb/.


Eeschema screenshot

Eeschema is nice and familiar, you can place parts, connect wires, create named nets etc. I had a very simple five component board so had no need of the advanced features. However there was obvious functionality for buses and a fair bit of support for nested sheets. There is annotation tool to name your parts and a basic rule checker to catch mistakes.


A nice bonus for Eeschema is the ability to have two names on a net. This is a bit controversial, Altium forbids it but I like it. Some times a line has two roles, such as being the MISO communication line during programming and the I2C interrupt line during normal operation. I like being able to create a named net for each role and connect both to the pin of the chip. The PCB layout program needs a single name, Eeschema handles this by arbitrarily picking one of them.

Missing Feature

Altium has a feature they call directives. This allows a pair of wires to be identified to be routed as a differential pair. You can also specify net classes, so as to specify increased track widths for the power rail or the required clearance on a high voltage track. KiCad does allow this to be done in Pcbnew but I feel the schematic, as the documentation for the design, should contain this information. This is particularly important if the layout and design are performed by different people.


Eeschema's use of dragging with the left mouse button is odd. In most applications this would perform a group select, in eeschema it selects and begins to move the components. Copy/paste is done by holding down shift before doing a selection. The oddness and learning curve aside, this doesn't scale well. There is no way of selecting a group of objects so you can't do a group delete, you can't change the properties of a group or resize multiple wires together. Using the copy/paste you can't double check what you have selected before doing a copy, multiple pastes require the full process to be run again and you can't change sheets. The move is still the action regardless of the tool selected, so dragging with the wire tool actually does a select/move and placing a box like a sub-sheet must be done with two clicks not a drag.

I suspect the select behaviour will be changed in the same batch of work as the shortcut improvements.


I should open by saying I couldn't really get my head around the schematic libraries. My understanding is that a library file can hold multiple components but I couldn't figure out how to put a second component into a library file. I did see notes suggesting that you merge two libraries by editing them by hand.

Several people have created their own tools to try and assist managing libraries. The existence of these tools indicates that many others have also encountered problems.

There is hidden magic behind the library process. For example to create a power component, basically a power net flag, the pin must be hidden. The pin still gets a wire connected to it but if it is not hidden it doesn't connect to the power net and you get unconnected errors when running the rule check. This isn't documented, the nice folks in the IRC channel explained it to me.

There is also documented hidden magic where some parts, fortunately none I used, have hidden VCC pins so they magically get the power rail without cluttering your schematic. Which is not so useful in the modern environment of multiple signal levels.

The developers are well aware of all of these issues, half the roadmap entries for eeschema are related to component editing. The plan seems to be to migrate the backend of the schematic library to the pcb library file format and work. Then build better editing tools on top. The PCB library tool is a significant step forward.


Eeschema screenshot

It took me a while to real­ise that there are actu­ally three dif­fer­ent PCB pro­grams bundled into Pcb­new. They are lis­ted in the view menu as three dif­fer­ent dis­play modes: default, OpenGL, and Cairo. This is not, as you might expect, just a dif­fer­ent dis­play engine. Some fea­tures are not avail­able in all modes and some fea­tures work dif­fer­ently depend­ing which mode you are in. I found Cairo ran very slowly on my poor ancient laptop so I just used default and OpenGL.

Dif­fer­en­tial rout­ing is a rel­at­ively new fea­ture and is only imple­men­ted in OpenGL. In the default view the fea­ture on the menu is simply dis­abled, grayed out, no feed­back is provided as to how to enable it.

There are other, lesser issues:

  • In GL mode the scroll bar arrows don’t work, drag­ging does.
  • Rub­ber band drag mode only works in default mode.
  • In nor­mal mode delet­ing a track deletes the attached via, in GL mode it does not.
  • In nor­mal mode the start track short­cut starts a track imme­di­ately, in GL mode it waits for a click.

There is a 3D model fea­ture which uses VRML world files for each part. How­ever it only sup­ports the sub­set gen­er­ated by wings3d, more com­plex files silently fail. Extend­ing this to other model types is on the roadmap.

Some other stuff feels a bit incomplete:

  • Hid­ing a cop­per layer still shows the pads.
  • There is a “Hide all cop­per lay­ers but act­ive” option for single sided work but it doesn’t hide the other side’s silkscreen.
  • The rule-check doesn’t enforce track width.

Finally the lib­rary man­age­ment is bet­ter than Eescheema’s but still needs a lot of work.

  • Rel­at­ive paths require manu­ally using an envir­on­ment vari­able, which was lis­ted in the Ees­chema lib­rary man­ager but not Pcbnew’s.
  • There is a plu­gin to add git­hub based repos­it­or­ies, but the option is lis­ted even if the plu­gin is not installed.
  • There is a plu­gin to add git­hub based repos­it­or­ies, not git based, it uses a git­hub webpage URL.
  • Adding a lib­rary doesn’t check that the lib­rary exists, works or is valid. An error is shown later when you try and use it.

linux​.conf​.au 2016 talk

Down­load Watch on Youtube

A few weeks ago I did a talk on my Microwave pro­ject at linux​.conf​.au it took me a while to be brave enough to watch myself and it wasn’t as bad as I thought. The talk was cer­tainly well received, the feed­back was pos­it­ive and use­ful, there were about 150 people in the room and the you­tube copy has clocked almost 400 views so far. I also got a writeup pub­lished by Linux Weekly News.

There is a lot I am tak­ing away from the pro­cess, I don’t think I have been so unpre­pared in my life but man­aged to get away with it. The response from people was far more favour­able than I expec­ted, in par­tic­u­lar I was sur­prised that most of the ques­tions have engaged at the concept level rather than the imple­ment­a­tion details. A few people com­men­ted that they saw me settle and become less nervous a short way into the talk, in real­ity I real­ised I was blow­ing through the mater­ial far too quickly and just tried to slow down, I think I did settle a bit once the ques­tions star­ted flow­ing though. I also did not under­stand the real­it­ies of a large group prac­tising pass­ive listen­ing, for example people listen­ing while play­ing with their laptop or phone, rather dis­con­cert­ing when you look up and feel that nobody is pay­ing attention.


Some inter­est­ing feed­back was people see­ing pos­sib­il­it­ies to use the microwave for things that microwaves are not cus­tom­ar­ily used for, I con­fess I had been blind to this. In par­tic­u­lar tem­per­ing chocol­ate and sous-vide cook­ing both require hold­ing the tem­per­at­ure to set level for a pro­longed period. Other pre­cise heat­ing pro­cesses like heat­ing sugar are also inter­est­ing options.

Sev­eral people sug­ges­ted just doing the elec­tronic work and abandon­ing or delay­ing the mech­an­ical modi­fic­a­tions until the next model. This was some­thing I looked at early on and decided against but the argu­ments are cer­tainly strong enough that I will be recon­sid­er­ing it.

At the end of the talk I con­duc­ted a price point sur­vey which showed that many people felt the product was worth $500 AUD but baulked and $1000 AUD. Which doesn’t mean that I wouldn’t find sales at the higher level but life is easier closer to $500. These prices include com­pens­a­tion for the increased risk of the kick­starter process.

Dis­cus­sions on eevb­log raised that solid state microwaves are com­ing. I thought that they would be about ten years out but it looks like it will prob­ably be two to three years, man­u­fac­tur­ers are advert­ising that com­mer­cial units will be avail­able at the end of the year. This is inter­est­ing and sets a time limit to the pro­ject but I don’t feel it is a huge threat at this point. It may actu­ally be a bene­fit in the long run.

Most of the imple­ment­a­tion feed­back was pos­it­ive. One LWN com­menter spe­cific­ally noted that they gen­er­ally dis­liked the IOT trend but felt that I was doing in the right way. Other LWN com­ments talked about how the modi­fic­a­tions seemed well planned rather than a trend of adding “smarts” for no real benefit.

And com­pletely unre­lated to the talk, I also stumbled across an inter­est­ing red­dit topic wish­ing that the microwave could recog­nise QR or bar codes and they auto­mat­ic­ally apply the proper heat­ing process.

Next steps

My next step is a review pro­cess, one I am rather trep­id­a­tious about.

When I star­ted the pro­ject I recog­nised the real­ity that only 1/10 pro­jects suc­ceeds. In prac­tice the stats only count pro­jects that get fairly big and on the government’s radar, a stage I am not yet at. So suc­cess is prob­ably no more than a 1% chance.

Nat­ur­ally my pro­ject is bet­ter than those that failed, I have a real­istic pro­ject, good mar­ket etc. etc… factors that I am sure the 99% had in their favour too.

The real­ity is that like poker it is very easy to let emo­tions dom­in­ate and com­mit you to play on well bey­ond when you should fold. To try and counter this I have set up pre-established fold points to step back and review.

This is prob­ably my biggest re-evaluation point so more dry plan­ning posts com­ing up, I will prob­ably also get some inde­pend­ent eval­u­ation to help dis­tance myself.

Packaging an automated login


Hav­ing a Linux sys­tem auto­mat­ic­ally log in to a graph­ical pro­gram on boot is sur­pris­ingly dif­fi­cult. Com­mon solu­tions involve set­ting up a dis­play man­ager with cus­tom con­fig­ur­a­tion and it gets messier from there. For­tu­nately there is a bet­ter way, xlo­gin uses sys­temd to launch X for a given user.

The developer describes it as a stop-gap work­around but after four years it is still a lead­ing solu­tion. xlo­gin con­sists of two sys­temd ser­vices, a launch­ing wrap­per script, and a xinitrc con­fig tweak. If it is a hack it is a very eleg­ant one, the four files together come to just forty lines (31 if you remove com­ments and whitespace).

Unfor­tu­nately it’s not pack­aged for Debian, while shov­el­ling some files on to the disk works as a short term meas­ure in the long run I really need it to be pack­aged, it greatly helps the image gen­er­a­tion and allows long term main­ten­ance. So I pre­pared a quick ugly pack­age. It cur­rently has some issues that like bad source pack­age gen­er­a­tion don’t impact me but need to be fixed, I’ll clean it up and look and sub­mit­ting it in a few weeks.

Pack­age Managing

To feed the pack­ages in to multistrap requires a Debian repos­it­ory. Fun­da­ment­ally this is a http or ftp dir­ect­ory tree with a few spe­cially format­ted files. There are a pleth­ora of tools to assist cre­at­ing this but as is com­mon when there are lots of tools doing the same job, none of them stand out as been con­sid­er­ably bet­ter than the oth­ers. I chose to use reprepro, it isn’t easy to set up but blindly fol­low­ing online guides worked for me.

Keyring Man­aging

Debian signs all of it’s pack­ages as a basic assur­ance meas­ure. The Debian tools take some con­vin­cing to run unsigned pack­ages so it is easier when build­ing your own pack­ages to sign them too.

Sign­ing is the easy half. You gen­er­ate a gpg key, feed it to reprepro and it signs all the pack­ages it delivers.

Where things get a bit more com­plex is get­ting the pub­lic key in to the cli­ent com­puter so that it can verify the key. The quick solu­tion is to push the key in to apt-key when gen­er­at­ing the image. This works but is dif­fi­cult to maintain.

The more com­plete solu­tion, which Debian uses for it’s own pack­ages, is to cre­ate a keyring con­tain­ing all the valid keys. This keyring is then pack­aged and dis­trib­uted through the pack­age man­age­ment sys­tem. Struc­tur­ing it this ways allows keys to be added or revoked as required by push­ing a pack­age update. Doub­ling down the com­plex­ity, man­aging the keyring pack­age is a cluster of pro­grams called jet­ring which provide tracab­il­ity of changes.

I built my own keyring pack­age, lodlabs-keyring based on debian-archive-keyring which I dis­trib­ute through my devel­op­ment pack­age man­ager. With this setup I can feed multistrap cus­tom pack­ages at will.

A quick note, using this tech­nique multistrap must be able to acquire the keyring pack­age itself. So the image gen­er­at­ing machine must tie apt in to the private repos­it­ory and have the keyring installed.

Cre­at­ing your own keyring package

For a very small simple pack­age cre­at­ing your own keyring is a bit of work.

For starters, you need the basics:

apt-get build-depends debian-archive-keyring
apt-get source debian-archive-keyring

The debian-archive-keyring has a few directories:

  • keyrings:
    This con­tains the gen­er­ated keyrings, the end products. They are cre­ated by the Makefile.
  • active-keys, removed-keys, team-members:
    Each of these dir­ect­or­ies con­tains a col­lec­tion of keys.
    The keys are of a cus­tom file format, gen­er­ated by jet­ring from a gpg key.
    Instruc­tions for cre­at­ing a key are in README.maintainer.
    There is also an index file with a check­sum for each key, this can be gen­er­ated by jetring-accept.
    Finally there is an index.gpg file which signs the index, this can be gen­er­ated by jetring-signindex.

    • active-keys:
      This keyring is used to verify the archive pack­ages and is dis­trib­uted in the gen­er­ated package.
    • removed-keys:
      This keyring is used to revoke pre­vi­ous act­ive keys and is dis­trib­uted in the gen­er­ated package.
    • team-members:
      This keyring is used by the pack­age gen­er­a­tion to verify the act­ive and removed keyrings. It is not dis­trib­uted out­side the package.

To pro­ceed you are going to need two gpg keys, you con prob­ably use the same key twice but it wouldn’t be advis­able. I gen­er­ated two dif­fer­ent sub­keys fol­low­ing the instruc­tions here. The act­ive sub­key is the one used to set up reprepro and sign your pack­ages. The team sub­key is your per­sonal sign­ing key.

Push the per­sonal key into the team key­chain, then the reprepro key into the act­ive key­chain by fol­low­ing the instruc­tions in debian-archive-keyring’s README.maintainer.

Once your keys are in the pack­aging key dir­ect­or­ies, delete all the other keys in active-keys and team-members. Edit the index files so that only your key entry remains. Then resign the index by run­ning jetring-signindex over each folder.

You can also delete all the keys in removed-keys, cre­ate an empty index file and sign it with jetring-signindex.

Now if you run ‘make‘ it should gen­er­ate new keyring files only con­tain­ing your keys.

To com­plete the pack­age it will need to be renamed. Edit all the debian files, chan­ging every instance of debian-archive-keyring to your-keyring. The changelog, copy­right and con­trol files will all need to have por­tions par­tially rewrit­ten. The debian-archive-keyring script files in the debian folder will need to be renamed and the debian-archive-keyring instances in the Make­file will all need to be changed.

The gen­er­ated keyring files must be signed, run
gpg --armor --detach-sign keyrings/your-removed-keys.gpg

Finally invok­ing ‘debuild –b –uc –us‘ should spit out your-keyring_<year>.<month>_all.deb.

Return top