I’ve used a lot of different configurations of Arduino-related gear as datalogging utilities. So here’s a comprehensive guide on what’s possible, how to set up stuff and on what you can expect regarding accuracy, battery life and logging speed.

My Arduino Uno with the datalogger shield both temperature and brightness sensors connected. I used a normal smartphone charger to power it for more than 3 days and placed it in this fireproof baking tray since I felt somewhat unsure about having it running unattended.

I got a small display compatible with my Due for christmas. And since I really wanted to see some arduino-in-the-loop simulations, I decided to use it for exactly this: real-time multibody simulations on the Ardunio and the results displayed on the tft.

It’s been more than a year since I published my post on numerical integration on an Arduino. Since then, the post has been quite popular, recieving a steady stream of visitors (mostly via Google). When I originally wrote it, I only had an Arduino Uno at hand – since then I’ve added a couple of Nanos and lately an Arduino Due to my inventory and decided it would be interesting to do a couple of speed tests to see how they perform. The latest addition to my growing circus of microcontroller boards is a Teensy 3.5 board.

As I pointed out in the original post, numerical integration relies heavily on floating-point math – which is something the Arduino’s 8-bit processor is not particularly good at. The Due features a 32-bit processor, a clock frequency of 84 instead of 16 MHz and the possibility to use double (64 bit) instead of float (32 bit) as a data type – so I was curious to see how it would compare to the Arduino Uno. The Nano is supposed to have more or less the same characteristics as an Uno, but is a lot smaller and cheaper – see below for details.

Now added to the comparison, the Teensy 3.5 includes a 32-bit processor with 120 MHz clock speed and a FPU for speedier floating-point math.

This post is not really about multibody dynamics. Instead of simulating stuff, I’ve actually built something: A glowing, more-or-less-interactive lamp.

We are awaiting our first child and with all the things we bought (mostly used), there was a small, adorable lamp. Unfortunately, it had some weird-looking electrics inside (both looking very old and labeled for 120V – so it wouldn’t work with our 230V here in Germany), so we decided to remove all cables and replace them with LEDs. Actually, WE just decided not to use the existing cables and then I talked my wife into letting me build something with an Arduino.

So I hooked up the lamp with a digital LED-stripe – I found one that came with digitally-adressable LEDs and used the Adafruit Neopixel library to adress those. Now there are 24 RGB-LEDs inside the lamp which I can control direct with the Arduino.

This is just a small update on my experiments with the Arduino. I implemented the runge-kutta-method for solving a multibody system a few weeks ago. So this is a working implementation of the standard 4th-order runge-kutta ODE (ordinary differential equations) solver for the arduino platform, something I haven’t seen elsewhere.

My main goal was to get a better grip on simulation speeds. Why is my simulation so slow? is a question I’m really thinking about a lot. Since I wasn’t able to find a good example of an arduino sketch for ODE solving online, this may be interesting anyway.

Until the beginning of this year, I’ve only been coding in Matlab, GNU Octave and a few other comparable high-level 4th generation programming languages. I’ve long wanted to learn a more basic programming language which allows smaller and faster programs (more on this in another post). Basically, I wanted an answer to the question:

I’m an engineer and want to learn about programming. What can I do to get started?