Recently I got more and more fed up by EAGLE CAD. It is a good EDA tool. But the restrictions are really starting to bother me. I need to do more 4 layer boards. Perhaps bigger boards. And I do not want to invest some thousand Euros just to be able to design bigger boards or more layers on the PCB. And since I am unhappy with my libraries anyway it was a good point to try out a new tool.

As you may remember the Mac OS X support in KiCAD is experimental. And from my first impression: Yes it is.Getting it up and running is a major task by itself. So I am writing down my experiences. Perhaps this helps anybody.

Downloading KiCAD

This is the easiest part. I went to the KiCAD wiki download section and checked the experimental builds. I settled for the builds by Brokentoaster since they got some fine installation package for Mac OS X. Just for the records: The version number while doing this was v3052 as the latest stable build. That’s what I grabbed.

Installing KiCAD

After the installation I checked what it installed – and was not very pleased. It just created an Folder /Applications/kicad/ with some demo files in it. No binary, no documentation, no nothing. I tried the second download link on broken toaster for the .tgz of the same build. And there it was. The application folder by the installation routine still belonged to my user. Not as I expected it to be, but very handy to add the files from the .tgz archive. Finally a complete installation. Starting KiCAD was easy and it worked out of the box. I was a bit puzzled that the first project was created in the Application directory. But nothing a new project in another location could fix. Fine!

But running eeschma showed me that I was not nearly there. All necessary libraries where missing. A good sign that the installation was not complete. After some googling I found an file INSTALL.txt. in /Applications/Kicad/share/doc/kicad/INSTALL.txt. It’s content completely solved the mystery:

The parts of KiCad
------------------
KiCad consists of 3 packages:

kicad         - KiCad programs and core files.
kicad-doc     - Documentation and interactive help (optional package).
kicad-library - KiCad schematic, pcb & 3D-model libraries (optional package).

Obviously the package for Mac OS X contains only the KiCAD program and core files. But neither the documentation nor the essential libraries – hence the error messages. Some lines below there was some super secret hint where to put the libraries and documentation:

Mac OS X KiCad tree
 -------------------

System wide files

 /Library/Application Support/kicad/demos
 /Library/Application Support/kicad/internat
 /Library/Application Support/kicad/library
 /Library/Application Support/kicad/modules
 /Library/Application Support/kicad/modules/packages3d

User files can be the same as the system wide files but only inside the users home directory.

$HOME/Library/Application Support/kicad

Warning:
 These paths are hardcoded into KiCad, if you put them somewhere else KiCad will not find them when a new
 project is created.

So back to the download page and get a complete Linux package to extract the documentation. I went for the complete Ubuntu installation. It was nearly the same version and had ‘complete’ on the cover. Downloading and unzipping it it showed me a beautiful Linux file tree with all the needed files. Since I am the only person on this computer using KiCAD I created ~/Library/Application Support/kicad and copied the directories ‘demos‘, ‘internat‘, ‘library‘ and ‘modules‘.

The Result

After copying all the necessary files in all the necessary locations gave me complete and functional KiCAD installation. There are some graphics glitches in the schematic editor. But I hope that those are gone in one of the next versions.

So off to check the tutorial to do something useful with my fresh installation!

There is nothing better than happy and even creative customers! At 27C3 Johannes and Gabe were one of the first customers for the Blinken Button Kit. After some minor issues they managed to assemble their kit. But that was positively not enough for them.  They wanted to use the Blinken Button as SPI slave, so that they can use them as a display. To control the animation and texts from other microcontrollers, e.g. an Arduino. So they sat down, hacked the software and hacked the hardware until they succeeded. The even got their first SPI Blinken Button ready on the 27c3!

Congratulation!

Right now their solution looks as hacked as it is. But you have to blame me for this since I did not break out all the pins for the SPI connector.

I am reviewing the Blinken button design anyway. So I think I will follow their recommendations and find a way to break out the SPI pins as optional connectors. Let’s see how it will look in the end. But I think it is good to have those pins available.

So check their Blinken Button Code over at Github and see if you can also repurpose your Blinken Button. And if you got other Blinken Button hacks be sure to leave a comment!

Related posts:

• Blinken Button – The LED Matrix Button Kit
• Blinken Button for Beginners Version 2
• Blinken Buttons for Beginners – a SMT Beginners Kit

A short German sumary, English version after the click:

Auf zur Palo Altonale! Zusammen mit Tinkerlog, Palo Altona und Interactive Matter bietet die Good School einen Kurs zu Physical Computing & Tinkering in Hamburg an. Ziel des Workshop ist es Kreativen in 2 Tagen die Umsetzung von interaktiven Physical-Computing-Projekten auf Basis von Arduino zu vermitteln.Wer immer schon mal interaktive, elektronische Spielereien selber basteln wollte ist bei uns bestens aufgehoben.

Wir geben nicht nur eine Einführung in die Programmierung mit Arduino sondern helfen jedem ein eigenes kleines Projekt umszusetzen! Jeder Teilnehmer erhält einen Arduino mit Netzwerkverbindung, notwendige Bauteile und Sensoren. Grundkentnisse sind eigentlich keine erforderlich (OK, Computer bedienen istsollte drin sein). Wer dann schon mal eine Programmiersprache gesehen hat (ActionScript, JavaScript, oder was auch immer) kann mitmachen. Wer denkt er könne keinen Arduino programmieren wird eines Besseren belehrt.

Der Workshop findet am 29. & 30.10.2010 statt. Weitere Informationen gibt es bei der Good School oder Facebook. Wer Interesse hat innerhalb des Workshops spezielle Themen umzusetzen will (MIDI, Robotik, …) meldet sich frühzeitig bei der Good School – dann können wir darauf gerne eingehen.

And now for the English description …

Tinkerlog, Palo Altona and Interactive Matter will help Good School to offer a Arduino workshop in Hamburg. The idea of the workshop is to bring creative professional in touch with physical computing. Every participant will build a physical project interacting with the internet. The basic concept of the workshop is pretty simple. Every participant gets an Arduino with a network connection and some physical interface sensors.  We will give a short introduction into the Arduino platform and how to program it. Everybody who had a look at ActionScript or any other programming language will be able to programm his Arduino. Don’t be shy, since you think you cannot program – nobody will be left behind. The most important part of the workshop will be free tinkering. You can design and realize your project. We will help you with any question, programming or sensors that you need! We will bring a plethora of stuff and experience! If you are in Hamburg on the 29. & 30.10.2010 contact the Good School and register! Uhmm, the course will be held in German.

Related posts:

• Palo Altona will build Hamburg’s first Makerbot
• Palo Altona – Hamburg Tinker Drinkup
• Tinkering with ADJD-S371-Q999

Developing software – or better firmware – for the Atmel AVR can be quite easy or quite complicated. A lot of people like to just use vi, some source files and a make file. Here at Interactive Matter we are a tad lazy and want a fully fledged IDE, with code completion, one click building, no make files and buttons to flash the AVR. The easiest was is to achieve this with Open Source Software, using avr-gcc, avrdude and avr-eclipse.

To help anybody who wants to use this very convenient package Interactive Matter offers a complete guide on how to install and use avr-gcc, avrdude, Eclipse and the avr-eclipse plugin.

Palo Altona is happy to announce that we will build the first MakerBot Cupcake CNC in Hamburg (at least according to Google). Good School approached Alex of Tinkerlog, me and Palo Altona in general, if we want to help to build their MakerBot. And yes we are happy to help.

The weekend project will be documented over at Palo Altona (mostly in German). Some updates will be posted here too.

If this weekend is successful the good boys and girls at Good School will have a nice functional MakerBot Cupcake CNC (probably the first in Hamburg) and I am looking forward to it!

Related posts:

• Palo Altona – Hamburg Tinker Drinkup
• Palo Altonale – Learn Tinkering at the Good School

Die deutsche Version gibt es nach dem Klick (und dann weiter unten).

This time it is all non-technical (technically not – but that starts to get complicated). To further encourage tinkering in Hamburg, Alex and I have established a regularly tinker drinkup every Thursday (nearly) at Saal II.

Currently it is a very cosy drinkup, just a few guests. Hopefully this will change. We post announcements with very short notice on Twitter via #palo_altona. If you want to join to discuss some tinker stuff or present your Arduino or tinker projects, just tell Alex or me and we will tell when the next #palo_altona takes place.

Update: There is now an official Palo Altona site for further references.

Und nun zur deutschen Version:

Um auch in Hamburg einen regelmäßige Austauch zu Arduino, Tinkern und Open Source Hardware zu etablieren haben Alex und ich ‘Palo Altona’ gegründet. Ein regelmäßiges, manchmal auch unregelmäßiges, Treffen, jeden Donnerstag, im Saal II in der Schanze. Gäste sind gerne willkommen!

Die Koordination erfolgt recht kurzfristig (leider bisher meist erst am selben Tag) über Twitter (#palo_atona). Meldet euch bei Alex oder mir und wir geben Bescheid ob und wann das nächste Treffen ist. Wir freuen uns über jeden Gast.

Update: Es gibt inzwischen eine offizielle Palo Altona Site für weitere Informationen & Koordinierung.

Related posts:

• Palo Altona will build Hamburg’s first Makerbot
• Palo Altonale – Learn Tinkering at the Good School
• Twitballoon – a Twitter Trend Visualizer

This is definitively the last post for this year. So I wish everybody Merry Christmas or whatever you want to celebrate and a pleasant & successful new year!

Even I stopped tinkering and went on to hacking cookies. Have fun & take care!

Related posts:

• Last year in electronics

Some days ago I wrote about noise with a LIS302DL accelerometer. There is obviously something wrong with my hardware. But before I get a new version out I need to implement some software filtering.

After some unsuccessful results with low pass filters I choose the Kalman Filter. The Kalman Filter involves an awful lot of complicated mathematics. But fortunately I just needed a simple one dimensional Kalman Filter without any driving information, which makes the filter much easier.

Implementing the Kalman Filter

If you check the Kalman Filter formulas, you will encounter a lot of complicated matrix and vector math. But after some research on the application domain for an LIS302DL accelerometer I found out that a simple one dimensional filter will do the job. The accelerometer puts out three dimensional acceleration data. But if you just want to get clean acceleration data from it all formulas simply deal with one dimension. So it was easier to use three different one dimensional Kalman filters. It all ended in a small set of formulas:

x = x
p = p + q;

k = p / (p + r);
x = x + k * (measurement – x);
p = (1 – k) * p;

The first two formulas represent the prediction of the Kalman Filter. And since there is no information about the driving forces it is very simple. The second three formulas calculate the measurement update. The variables are x for the filtered value,  q for the process noise, r for the sensor noise, p for the estimated error and k for the Kalman Gain. The state of the filter is defined by the values of these variables.

The filter is applied with each measurement and initialized with the process noise q, the sensor noise r, the initial estimated error p and the initial value x. The initial values for p is not very important since it is adjusted during the process. It must be just high enough to narrow down. The initial value for the readout is also not very important, since it is updated during the process.

But tweaking the values for the process noise and sensor noise is essential to get clear readouts.

Tweaking the Kalman Filter

The first results were less than ideal. So I decided to use processing and my good old LIS302DL breakout board to get some insight of the optimal values of the different parameters:

First I looked into the importance of the process noise q, starting by a very high value of 128 (which is the maximum output of the accelerometer):

You see there is nearly no difference between the filtered data (white) and the original data (grey) – since you just see the white line.
If you turn down the process noise, e.g. to a value of 4 things start to change:

If you look closely you see that the sensor data often overshoots the filtered value. The filtered value is pretty close to the real value, but is missing a lot of noise. For my application I needed a more static output, smoothing out nearly all of the noise, giving a clean an steady signal. So lets turn down the process noise value a bit more, e.g. something like 0.125:

Now we got a quite a clean signal from quite a noisy source. It lags a bit behind the real data, but that is not critical for my application. Compared to the amount of noise reduction it is still quite fast.
After this is set let’s play a bit around with the sensor noise r:
We start back at r=1:

As expected if we turn down the assumed noise of the sensor the Kalman filter ‘relies’ more on the sensor data and gives more noisy results. If we increase the noise factor of the sensor to 4 we get a more stable result again:

If we go up extreme and assume a noise level of 32 we get the expected steady result:

As expected the filtered value lags significantly behind the real measurement. But it is a much cleaner signal. But  it is questionable if this is still useful.

Implementing Kalman in C

Implementing this filter in C code (e.g. for an Arduino) is quite simple. First of all we define a state for a kalman filter:

typedef struct {
  double q; //process noise covariance
  double r; //measurement noise covariance
  double x; //value
  double p; //estimation error covariance
  double k; //kalman gain
} kalman_state;

Next we need a function to initialize the kalman filter:

kalman_state
kalman_init(double q, double r, double p, double intial_value)
{
  kalman_state result;
  result.q = q;
  result.r = r;
  result.p = p;
  result.x = intial_value;
 
  return result;
}

And a function to update the kalman state, by calculating a prediction and verifying that against the real measurement:

void
kalman_update(kalman_state* state, double measurement)
{
  //prediction update
  //omit x = x
  state->p = state->p + state->q;
 
  //measurement update
  state->k = state->p / (state->p + state->r);
  state->x = state->x + state->k * (measurement - state->x);
  state->p = (1 - state->k) * state->p;
}

What did we learn from this?

First of all the Kalman filter can be much easier to implement if the underlying model is simple. We had not several dimensions, nor different sensor data to combine. The results are pretty good, but it is a challenge to find the right values for the process and sensor noise. Instead of just coming up with some guesses for the values, they can of course be estimated, but than we have to live with the result of the estimation.

In the end it is a good, robust, simple filter (in one dimension).

I think that in lack of several sensors we throw out the most advantage of the filter to combine several sensor data to a combined result. I think going a bit more in this direction can lead to real interesting results.

Or is there a much easier filter to use for my problem, leading to better results?

Related posts:

• BMP085 Barometric Pressure Sensor Breakout Boards arrived!
• Arduino & Barometric Pressure Sensor BMP085
• Decoupling LIS302DL – There I fixed it!

As you probably know, I really like I2C sensors and especially the LIS302DL. But adding this accelerometer to your circuit is not as straight forward as I thought. But in the end I got it quite right.

It all started out with a 0.1µF ceramic capacitor. For good measure I put a ferrite bead in front. But this lead to terrible readouts. So I threw in a 10µF 0805 ceramic capacitor and a 4.7µF tantalum capacitor. It does not look nice, nor does it look terribly solid, but it works fine.
So read on, what my analysis of the situation is.
My original layout had just a small ferrite bead and a way too small capacitor. And this on a board hosting a ATmega168 and four alphanumeric displays, drawing from 0 to 300mA, from a step up voltage controller. Of course I had about 400µF decoupling capacitors on board, but the direct power supply of the LIS302DL had still about 0.1 Volts of noise on the power supply line. And the readouts were extremely noisy (>10%).

Not good.

Throwing in some capacitance was a good idea and reduced the noise by something like factor 2. But still it is very noisy. The LIS302DL datasheet suggest using at least a 10µF and a 0.1µF capacitor of different types (e.g. ceramic and tantalum) – I think it is just some minimum requirements. Proper voltage supply with as less noise as possible is a must.

So my next try will be:

• Redoing the complete layout so that the power supply of the LEDs is uses separate VCC and ground paths than the digital circuit.
• Redoing the same for both chips, so that I got some star like grounding and supply system. Or some carefully laid out power planes.
• Adding bigger ferrite beads in the supply line of the LEDs and both chips, so that each component has its own supply line with ferrite beads and capacitors, to reduce cross talk.
• Perhaps adding some LDO regulator to drive the digital circuitry from 3V instead of 3.3V to reduce the noise of the LEDs or power supply.

I alwayys thought good power supply design is just for audio stuff or other high quality applications, but I learned (the hard way) that you also need it for just some basic tinkering.

So off to the next design.

Related posts:

• Arduino & LIS302DL
• Filtering Sensor Data with a Kalman Filter

Just another good example of ‘lesson learned’. I often use the very common CR2032 coin cell batteries to drive my circuits. Small, cheap, easy to get and there is a quite a range of good and cheap battery holders.

But recently I have tested an complete over the top design which pushed the poor little CR2032 far beyond its limits. Time to grab a few facts from the datasheet for further reference.

To get a good example I found a quite elaborate CR2032 datasheet from Duracell. I think other batteries behave quite similar to this.

The Issue

The general key fact of an CR2032 are obvious and quite easy to grab from the datasheet:

Voltage: 3V

Capacity: 240mAh (to 2.0V)

If you study the datasheet more closely you will see that the voltages drop sharply after it reaches 2.8V (after it has delivered about 170mAh).

ESR (Equivalent Series Resistor):about 18 to 20 Ohms.

The ESR (Equivalent Series Resistor) or IR (Internal Resistance) is quite flat up to 150mAh of capacitance – there it reaches about 20 Ohms. At 170mAh it reaches something like 30 Ohms. This is quite hefty. In comparison good capacitors have a series resistance from some Ohms to a fraction of an Ohm – so it is always good to put some (even electrolytic) capacitors in parallel to the battery. If you are concerned that switching on or of of your circuits discharges the battery to much by charging up the capacitors – there is a simple trick to prevent it: put the capacitors in front of the ‘on’ switch so that are always charged and will not charge after your circuit is switched on. The leakage current will be so small that it will be neglectable in most cases.

But if you want to calculate how much constant current you can draw from these batteries you have to use Ohm’s law:

V = R * I or I = V /R

If you take the later and say you want no voltage drop higher that 1.2 Volts – because after that your circuit reaches 1.8 Volts which makes your microcontroller most probably going brown out. Applying these with the ESR of 20 Ohms, you will get something like 60 mA you can draw by them (I = 1.2V/20Ohm). You if calculate more conservative and do not want to go below 2.8V – which gives you some 0.2 Volts head room  – you will only be able to draw 10 mA (I = 0.2V/20Ohm) – just enough for an LED. These calculations do not consider the voltage drop of the battery of its life time.

In the bottom line: If you use those batteries you have to consider the 20-30 Ohms series resistance. Especially if you draw some constant current (spikes can be easily removed using capacitors). Yo have to assume 170mAh as maximum capacitance because then the CR2032 reaches 2.8Volts and the ESR goes up to a whopping 30 Ohms – going up from there very steep. Because of the high ESR of the CR2032 you will most probably not be able to draw more than 20-30 mAh safely (as constant current).

Perhaps it is even better to get a boost converter to 3 or 3.3V – to suck out all the juice in the battery. This should should be good for the environment too. Or even better get rechargeable Lithium Cells.

So driving an RGB with an 5V boost op converter is impossible. At white (all three LEDs draw 20mA) it is 60mA current at 5V, considering a efficiency of 80% this will give you more than 120 mAh at 3.3V. Impossible or the CR2032. So my intended design will never work. I wish I had done those calculations before I designed it and not after I saw that the prototype does not work.

You live and learn!

Some Closer Look

As we see the higher the current is the more loss we get by the ESR of 20 Ohms. So the question is how much power we can get from an CR2032. If we want to draw the maximum amount of power over a short time we simply take the power:

P=V*I

And we know that the voltage is

v=3-20*I

And we get

P=(3-20*I)*I

If we create a little graph from it we get

So we see that the maximum is somewhere at 75mA and somwhere at 0,1125 Watts. Perhaps the real theoretical value is a bit off – but most real batteries will be a bit off too, so it is a good enough aproximation.

So that is somewhat consistent to our previous calculations to not exceed 80mA to avoid a too big voltage drop.

But how many energy can we draw from an CR2032? For this we simply calculate the watt hour of the battery:

e=P*t and t=0,24A/I

so we get

e=(0,24/I)*P

or

But this is not very astonishing. The less current you draw the less loss you got at the internal resistor. But I am unsure if there is this resistor, which burns energy to heat. But since the batteries get hot if you draw too much power you will get some loss. But I do not think that the loss is equal to a 20 Ohm resistor. But the main finding is clear – the more current you draw the more loss you have.

What to do?

From the comments I got the tip to put the lithium coin cells in series to get a higher coltage at the current draw. But this will enlarge the voltage swing at different current levels (from 6V at 0mA to 3V at 150mA). This can be dangerous for your circuit. A better approach would be to put the batteries in parallel to half the internal ESR – so you would still get 1.5 Volts at 150mA.

Of course to counter current spikes you should allways put sufficiently sized capacitors in parallel. Sufficiently sized depends on the level of current spikes and there time. Just check out how a Farad is defined and you can derrive the needed value (which is the product of voltage change and time).

But in most of my designs space is a rare good. So no parallel batteries and no big capacitor banks.

Something that could work is sucking the power with a boost converter to get a steady output voltage independent of the current draw. This would of course enhance the loss but at least we get the voltage we want at an expense of the efficiency. Right now the calculations are a bit too complicated for this evening. But updates will follow

Lets see how that works.