I’ve been working a bit with KiCad lately and have run into a problem in PCBnew with “stitching” (i.e., adding vias between) filled zones on top and bottom layers. This is something you typically do if you have flooded the unused spaces on both top and bottom of your board with copper and have connected the floods to ground or some other reference.

The KiCad FAQ outlines a process for doing this, and it works fine until you refill (i.e., re-pour) the zones — or the DRC refills them for you. When the zones are refilled, the vias you added for stitching become isolated from the zones and end up as little pads floating in space.

I do a fair amount of open source code development, yet I am not (yet?) against the idea of software patents. I think there are significant problems with the way software patents are implemented in the US, but I don’t find the concept fundamentally odious.

However, I do find corporate bullying using patent infringement as a pretext quite reprehensible. A recent example–to which I will not link so that I don’t make things worse for the coder–really has me annoyed.

In essence, an independent coder reimplemented from scratch and for no commercial gain a program to duplicate the functionality of a commercial product. The coder then published her/his work with the intent of releasing the code under an open source license. I am not a lawyer, but I think the general gist of a patent is that it is illegal to distribute a product that is under patent protection without first obtaining a license from the patent holder. As far as I know, it is not illegal in the USA to discuss patents in public nor to publish, for example, plans for making a better or different patent-protected Hovercraft Eel Sensor. It only becomes an issue if you try to distribute a product based on those ideas without a license. The ideas and discussion thereof are public. The use of ideas in products is protected.

The coder in our story has simply published plans (i.e., source code) for making a different version of a (possibly) patent-protected product. Nowhere does the coder indicate her/his intent to distribute a product (i.e., executable code) based on the plans. In spite of this, our coder gets a threatening email from the V.P. of the corporation that makes the commercial product citing (without specificity) that the published work infringes on their patents.

It may also be worth noting that the coder does not appear to have done any reverse engineering to discover how the software works. So if the V.P. actually means “trade secret” when he actually says, “patent,” then there’s nothing there either.

I am not a lawyer, but I utterly fail to see the grounds for the corporate entity’s gripe in this and similar cases. Also, in the particular case in question, you cannot help but notice the extreme vagueness in the communications from the corporate entity. Under these circumstances, one would easily be forgiven for thinking that the corporate entity knows it has nothing to stand on and that its strategy is simply to threaten a costly legal process against the coder. They know that lone coders will almost certainly comply with threatening requests to spare themselves the burdens of the situation. I am not a lawyer, but in common-person speak we sometimes use the word “extortion” for this strategy.

You can’t have it both ways: patent protection and protection from public scrutiny. Patents are public.

A short time ago, I wanted to find a simple code generator that would run on Windows for helping me to maintain hand-rolled SPICE models files. I was a bit surprised to find none that were no-brainers to install or use. However, I did figure out that OpenOffice‘s mail merge feature can be used as a poor-man’s code generator. There’s more than one way to do it, but the process described at Worldlabel.com is the most straightforward for my brain. The key is to “print out” to several files or a single file–depending on what you are generating.

I am trying to keep my SPICE modeling as platform and vendor-neutral as possible. To help with this, I have come up with the following structure for managing libraries. The idea is to have a file system, e.g.:

and in each category (i.e., subdirectory) store your individual model files. The file system, in addition to providing a structure to manage different kinds of parts from of different places, also helps to differentiate models for the same part from different sources.

Now here’s the fun part. So that I don’t have to have a million different .inc or .lib commands in the SPICE simulation’s source (one for each part I use, e.g.,

.lib C:\SpiceDev\models_raw\fairchild\transistors\MMBT2907A.lib

), I aggregate all the models in a given subdirectory into a single library file. Thus, C:\SpiceDev\models_raw\fairchild\transistors in addition to having several individual model files also has the file C:\SpiceDev\models_raw\fairchild\transistors\transistors.lib in it that is an aggregation of all the other files ending in .lib, .mod, or .sp3. So now if I want to use a Farchild transistors, I only need to include a single file:

.lib C:\SpiceDev\models_raw\fairchild\transistors\transistors.lib

Of course I don’t maintain the aggregate library file by hand. Instead I have written an AutoHotkey script that does the job. I place the script in a fixed place and then create links (i.e., shortcuts) to it from the directories containing the model files; but it will also work if you drop the script itself into the directory in which you want to make an aggregate library.

The script goes through each file in a directory (non-recursively) and if the file has a .lib, .mod, or .sp extension it appends its contents to a file named {directory-name}.lib . Both the extension of the output file and the list of aggregated input file extensions can be easily changed in the source code.

One important note: If you want to call the script using a shortcut, make sure the SetWorkingDir command in the code is commented out (as it is below) and also make sure the ‘Start In’ field for the shortcut is blank or points to the desired directory. Enjoy.

Linear Technology’s LTspice is becoming quite popular among audio circuit designers, both professional and amateur. There is a lot to recommend it, but there is at least one issue that is crucial to be aware of if you are planning to use vacuum tube or other third-party models based on arbitrary behavioral voltage or current sources. And that is: LTspice’s implementation of arbitrary behavioral voltage or current sources is not completely SPICE 3 compatible.

In particular (from the LTspice help files),

LTspice uses the caret character, ^, for Boolean XOR and “**” for exponentiation. … This means that when you import a 3rd party model that was targeted at a 3rd party simulator, you may need to translate the syntax such as x^y to x**y or even pwr(x,y).

I ran into exactly this issue when experimenting with SPICE 3 versions of my own tube models.

The aspect of cloud computing that’s the most attractive for me is being able to access all your stuff no matter where you are–provided you have a computer with a decent Internet connection and a fairly standard browser. However, there are two very bothersome aspects of cloud computing. First, if you cannot connect to the provider of your cloud service (e.g., your ISP is flaky, the service’s servers are ill, the site has been banned in the country you are in, etc.), you are screwed. Second, no matter what guarantees the provider gives you, your stuff is in someone else’s hands–meaning the provider can legally sniff your stuff for more effective marketing (Google) or it may be illegally hacked into.

However, there is a fairly easy approach to ameliorating both these problems, especially now that capable server hardware has become soprofoundlycheap. The idea is simple: instead of having Google, Google Apps, Zoho or whomever host your Cloud apps, host them in your own home on a dedicated computer. As long as you don’t plan to open your Home Cloud to tons of users, the performance demands on the hardware will be pretty small.

When you host your Cloud apps from home, if your ISP goes nuts you will still be able to access your stuff from within your home LAN. While this won’t help you if you need to access your stuff from Starbucks, it is better than not being able to access it from anywhere. Also, when you host your Cloud apps from home, your data stays at home. It still may be open to hacking, but it won’t be available for other purposes. In addition, a would-be hacker would have to specifically target your server, whereas in a hosted situation one breach of the server may make all users’ data available to the hacker.

One downside to the Home Cloud concept is that it places the burden of backing up data on the home user. But this can be greatly simplified by appropriate Home Cloud software.

A bigger problem with the Home Cloud is what all the cool people are now calling “monetization”. In other words, how do you make money off it? End users are becoming increasingly accustomed to getting services for free. Google makes money feeding you ads. Zoho makes money by selling premium services mostly to businesses. Are users willing to pay for Home Cloud software? One possible way forward is to adopt the media server model: dedicated server hardware that’s preloaded with everything needed to make it go and that requires a minimum of user configuration. We may be living in a time where it may actually be easier to sell hardware that encapsulates a task than software.

I’m aware of only a few projects that have a Home Cloud spirit. eyeOS and Lucid Desktop are OSS home-hostable apps that give the user a virtual Web-based desktop. Another project to keep an eye on is Tiny Tiny RSS–essentially a home hostable replacement for Google Reader. All three of these projects are open source software, and it will be interesting to see where all three of these projects go.