Exchanging data with other computers can be a daunting task with Arduino. No matter if you just want to pass some information to Processing, to a Web Service or something else – You always have to encode the data and decode the answer.

There always have been solutions like XML for structured data. But XML is hard to decode, complicated an takes up a lot of space. And then there is JSON. JSON is an easy and efficient way to transfer data. A complex data structure can for example represented as
{
"name": "Jack (\"Bee\") Nimble",
"format": {
"type": "rect",
"width": 1920,
"height": 1080,
"interlace": false,
"frame rate": 24
}
}

aJson is an Arduino library to enable JSON processing with Arduino. It easily enables you to decode, create, manipulate and encode JSON directly from and to data structures. By this you don’t have to bother with data encoding and decoding – this will hand aJson for you. It is based on the cJSON implementation, reduced in size and removing one or two features.

Using aJson

To use aJson get it from the git repository or download the latest version. Unpack the zip file (or the git files) into an Folder ‘aJson’ in the Arduino library directory ‘libraries\’. Due to the early stage of this library you can encounter problems. Simply submit a ticket and it will fix it as soon as possible. On github you will also find a simple Arduino sketch to test the library, or as a starting point.

To parse the above structure with aJson you simply convert it to a object tree:

 aJsonObject* jsonObject = aJson.parse(json_string);

(assuming you got the JSON string in the variable json_string – as a char*). This is an object. We’re in C. We don’t have objects. But we do have structs. Therefore the objects are translated into structs, with all the drawbacks it brings. Now we can e.g. retrieve the value for name:

 aJsonObject* name = aJson.getObjectItem(root, "name");

The value of name can be retrieved via:

Serial.println(name->value.valuestring);

Note that the aJsonObject has a union ‘value’ which holds all possible value types as overlays – you can get only useful data for the type which you have at hand. You can get the type as

 name->type

which can be either aJson_False, aJson_True, aJson_NULL, aJson_Number, aJson_String, aJson_Array or aJson_Object. For aJson_Number you can use value.number.valueint or value.number.valuedouble, for aJson_String you can use value.valuestring, for True or False, you can use value.valuebool.

If you want to change the name, you can do so by

aJson.getObjectItem(jsonObject,"name")->value.valuestring="a new name";

To render the object back to a string you can simply call

 char *json_String=aJson.print(jsonObject);

Finished? Delete the root (this takes care of everything else).

 aJson.delete(root);

This deletes the objects and all values referenced by it. So take care for your string, you directly assigned. They are deleted too.  If you want to see how you’d build this struct in code?

aJsonObject *root,*fmt;
root=aJson.createObject();
aJson.addItemToObject(root, "name", aJson.createString("Jack (\"Bee\") Nimble"));
aJson.addItemToObject(root, "format", fmt = aJson.createObject());
aJson.addStringToObject(fmt,"type",        "rect");
aJson.addNumberToObject(fmt,"width",        1920);
aJson.addNumberToObject(fmt,"height",        1080);
aJson.addFalseToObject (fmt,"interlace");
aJson.addNumberToObject(fmt,"frame rate",    24);

The whole library (nicely provided by cJSON) is optimized for easy usage. You can create and modify the object as easy as possible.

Limitations of aJson

Unfortunately everything comes for a price and complex data structures and text processing is not really the primary domain for Arduino. So some simplifications had to be made:

• aJson is not really suitable for ATmega168 based Arduinos – there is just not enough RAM – and the library itself eats up toe 80% of the flash memory.
• aJson cannot handle Unicode.
• Lists and Objects can only handle up to 256 entries.
• All strings are case sensitive, this is no real problem for values. But if you want to find a name you have keep in mind that it works case sensitive.

A lot of these limitations will be gone in the future versions of aJson.

Further Development of aJson

Currently aJson is considered to be in a beta phase. It is usable, but it can get better. The most important task is to further reduce the memory footprint. Therefore the API may change a bit in next versions. When the library is better tested and more evolved it will be package as real Arduino library.

I hope that many people will use and test the library. So go ahead and download aJson!

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 – Hamburg Tinker Drinkup
• Palo Altona will build Hamburg’s first Makerbot
• 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

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:

• Arduino & Barometric Pressure Sensor BMP085
• BMP085 Barometric Pressure Sensor Breakout Boards arrived!
• 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:

• Filtering Sensor Data with a Kalman Filter
• Arduino & LIS302DL
• Low Voltage RGB LED

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.

Related posts:

• Decoupling LIS302DL – There I fixed it!
• SkatePOV

Unbelievable that this is just the first year of Interactive Matter. But still there happened a lot of things.

Lets have a look on what Interactive Matter has managed to achieve.

The Beginning

It all started with the little idea of having a ‘time replay device’. How was your Day Darling was born. It samples the light levels during the day and if you take in your hand it plays it back.

The first prototype was still a bit rough but functional:

But soon it evolved in perhaps the nicest PCB I have done yet:

The final ‘How was your Day Darling‘ was nice, but till a bit week. I think this is a project I have to come back to.

Gravitron

After the first success of How was your day darling I did something very dumb. After some beers I promised to create some Cylon/KITT like device in half a ping pong ball. Of course the concept got completely out of hand. After thinking how to switch it on I realized that the ‘easiest’ would be to include an accelerometer and detect motion. But if you have a accelerometer in it you can also play around with gravity, implement some minimalistic physics engine and implement a ‘air bubble’ with LEDs:

httpv://www.youtube.com/watch?v=m31_mkeNV3g

The original KITT-like animation was just used to indicate that the device is going to sleep. But this design ultimately got me to SMT. First of all it was hard to solder the ADXL accelerometer. So I bought an hot air rework station. And after that I was able to solder nearly any SMT device. Which is way cool.

Long Term Goal: Space Invaders Button

The idea for my Space Invaders Button is very old. I existed before I started with all this electronics stuff. I promised a friend of mine to get here some button for her jacket, displaying space invaders characters. I thought that it cannot be that easy. In the end it was more complicated than I thought- but at the end I was able to achieve it:

It was a great success, I must admit. People love it so much that I am currently working on a kit. So stay tuned and see what will be coming along. This design has still a lot of potential. It should be still able to use the LEDs as inputs (e.g. to detect touch or ambient light level). And there could also be some easier way to download custom animations on it. Another design which I have to revisit if I got some time.

µTVBG

The µTVBG was just some kind of SMT exercise. I questioned myself how small can you go tu build an TV-B-Gone clone. Ther result was quite nice. A working TV-B-Gone on approximate 2cm²:

Surely you will be able to make it smaller. Lets see how this evolves.

Whats coming up?

There are still a lot of projects in the pipeline. They rank from funny simple pranks to full scale product ideas. Of course all of them are in a much to early state to talk about. But stay tuned. They will be coming.

Another big issue right now is creating kits. Interactive Matter will offer solder-yourself SMT kits for all skill levels. But this topics needs some time too to evolve.

Related posts:

• Interactive Matter goes Kit
• Blinken Button – The LED Matrix Button Kit
• Blinken Buttons for Beginners – a SMT Beginners Kit