Arduinos from Scratch

In the last meetup, Dan Hienzsch presented his latest series of blog posts about designing an Arduino from Scratch. The results of this series were full schematics with BOM (Bill of Materials) of an Arduino UNO in KiCAD.

Dan started his talk by giving a short overview about the building blocks of an Arduino UNO. Arduino is open-source hardware and this means, that you can download its schematic. (By the way, many years ago, schematics came often as form of documentation when you purchased a product, this site has still a nice collection.)

An Arduino board has mainly 3 parts: A power supply, a USB-to-serial converter for programming, and a microcontroller. All blocks consume power. As Dan measured, a lot of current is consumed by the peripherals of an Arduino. If you want to run an ATmega on a battery, it can make sense, to only use the Arduino UNO board for programming, and have the MCU running in a different board for the “real” application. As it looks from the schematics, the Arduino UNO was mainly engineered for manufacturing instead of power consumption or number of parts.

After the overview on the different design decisions of the building blocks, Dan explained the 2 usages of Opamps on the Arduino: Comparators and buffers. Learning more details on Opamps was interesting to many, and it feels like it would make a good topic for another meetup. To work with Opamps, you often need resistors for biasing. One option is to use resistors from a resistor network or array.

Last, Dan got more into details of using a microcontroller on a PCB. The hardest thing to learn is about using crystals to provide a stable clock to the controller. Then, providing a reset pulse for programming a board is not easy too. On the Arduino a circuit with a capacitance is used.

Nodebotsday in Munich

Nodebots combine JavaScript with simple electronics and robots. Building robots should be “simple”, and this is an important reason for exploring JavaScript. This talk by Chris Williams provides a good overview.

Before anything can move, you must be able to communicate with hardware. Libraries for serial communication are essential for this, for example the serialport library by Chris Williams.

Once you can send bytes and bits to hardware, you can think how to build abstractions for components with JavaScript. Libraries such as Johnny-Five provide a nice starting point. Rick Waldron first presented ideas behind Johnny-five at NodeConf 2012. Also, Raquel Valez has presented Vektor a library for kinematics in JavaScript. Raquel discusses the general idea of JavaScript robotics in her talk at LXJS 2013.

Theory is nice, but practice is equally important. And, this is the idea of the Nodebots day. During this day, you can learn about the multi-disciplinary approach that building robots requires. In Munich, we organized a meetup as a joint-event between the Arduino and Robotics enthousiasts meetup.

Andrey who works on the Veterobot and who organizes the Robotics meetup started explaining some concepts on getting started with robots.

Elements of a Nodebot

There are three aspects to building a robot:

1) Electronics

PCB for power and motor control

The heard of a robot can be as simple as an Arduino. However, to program it with JavaScript, boards such as an Intel Edison, Raspberry Pi or Beaglebone are quickly more fun. These boards allow to easily work with a network, and use Node.js libraries to talk with hardware via I2C for example.

During the electronics sessions, we looked at some typical problems of integration. First, Andrey mentioned some thoughts about chosing batteries. Andrey’s favorite batteries are 12V batteries that have enough power to drive larger motors. Next, it might be important to think about a strategy for charging a battery. Andrey showed some simple circuit with a switch to attach a robot to a charger unit.

Since motors, microprocessors and sensor run on different voltages, you must then think about converting voltages from one domain into another. For example, a Raspberry Pi runs on 3.3V, sensors might require 5V and the motors then 12V. To generate these voltages, Andrey designed a small PCB board.

2) Mechanics

If your robot should move, you need to know how to make basic constructions to mount motors and gears. Also, a bit of sketching and CAD support for sending a blueprint to a 3D printer is nice
Attaching Motors

3) Software

A large part of what makes robots tick is software. With software, you can control processes and react to inputs from sensors. Last, you can transform a plan of actions again into motions of motors and wheels.

Andrey released the code for running his robot here:

Working with sensors

When building a robot, sensing the environment is important too. For example, you can use the SFR-10 ultrasonic distance sensors to detect obstacles in a path. To illustrate some ideas of working with data from sensors, we mainly looked at a setup with an Intel Edison and the I2C Learning shield.

With this setup, we could monitor the temperature inside the fridge. Especially, the wireless aspects of the Edison were fun, and more meetups will be led in that directions. For example, multiple serial ports can be used to receive and send instructions via bluetooth to a robot. We did not yet follow that route, but might in the future.

Edison on Radler

JavaScript is certainly an interesting approach to programming hardware. In Bavaria, there is no Nodebot meetup so far. But there is one across the border in Switzerland. Maybe you want to present or explore robots with JavaScript in Munich too?

Next meetup

We are planning the next Arduino Meetup at 21st of October about “Advanced Arduino” boards.

Exploring i2c

The summary of the “Exploring I2C” meetup? Good times!

As a start, Patrick provided some slides about I2C basics with Arduino. Most examples came from the hackaday blog that has tags for I2C. To get started with I2C, it turns out that temperature sensors are the simplest components to learn about the multi-master multiple-slave bus protocol. Displays, real-time clocks and EEProms are other popular examples.

We started by exploring the Eduction shield from Rheingoldheavy. On that board, you’ll find and AT30TS750A temperature sensor and a MCP7940N real time clock among other components.

So, the first step to get going was finding the right I2C library for Arduino. Arduino comes with its own Wire library for I2C. But that API is not very nice, and the code can even result into freezing the controller. This is why we directly looked into the I2C library as was suggested in this blog post by

The I2C library has a nice “scan” command that returns the slaves on the bus. A simple sketch to get started looked as follows:

void setup() {




void loop() {}

On the Learning shield it returned 0x48 and 0x60 for the temp sensor and RTC respectively. Running the code on an Wii Nunchuck gave:

So, you see that the Wii Nunchuck has quite a number of I2C slaves on its board. Once that basic code was running, we delved more into interactions with slave devices. First, you’ll program the configuration of a device. In the case of the temp sensor, you can set the resolution. This requires you the read the datasheet a bit. The resolution we liked was:

   I2c.write(0x48, 0x01, 0x60);

Last comes the readout of the actual data. In the API docs, we found several ways to readout registers. Well, here comes a bit C an C++ syntax into play as you need to deal with a pointer to a buffer. At the end, we came up with this code to readout the registers:o

uint8_t status1, status2;
void loop() {, 0x00, 2);
    status1 = I2c.receive();
    status2 = I2c.receive();
    Serial.print(" ");

But you could also look at the code from Rheingoldheavy that is much cleaner to read. See the I2C Display+Temp sensor code or the Display+RTC code. With that code it is not too difficult to arrive at a working example as shown below:

Extra: We tried to compare the value from the Atmel temp sensor with the TC74 that communicates with I2C as well. Not too much luck this time. Our TC74 sensor seemed to be broken, but it might also be a problem with the wires and breadboard setup. Too much bus capacitance or too low pull resistances can quickly give problems.

Plug and Play Feedback Systems with Modularis

In the last meetup, Dr. Mathias Bachmayer presented his Modularis platform. Modularis is all about making control theory and feedback work. Especially, if you want to build robots or mechatronic devices, control theory will play an important role.


According to Wikipedia, control theory “deals with the behavior of dynamical systems with inputs, and how their behavior is modified by feedback.” To simplify the development of these systems, Mathias investigated a number of patterns and electronic building blocks. This is the background of the Modularis project, which has its roots in Mathias’ dissertation research going back to 2005 (way back before Arduino became popular.)

Modularis provides a number of sensors and actuators that can be easily connected as shown below. While the early Modularis boards had rather large connectors, the newer boards became tinier and friendler for advanced integrations.


An important feature of Modularis is the use of the I2C bus. You can easily connect sensors and actuators with ribbon cables. And, you can connect a microcontroller for system control too. Currently, Modularis supports Atmega168 and Atmega328 microcontrollers which are easy to program with the common AVR tools. Mathias is experimenting with other microcontrollers such as ARM Cortex based devices too. But contact Mathias for more information on this.

We then had an overview of common Modularis boards, such as bridges for CAN and LIN, as well as Wifi. The Modularis system also works with a Raspberry Pi. The highlight of the evening was a demo of a plotter that was built with Modularis.

After the talk, we had some discussions about differences between Modularis and Arduino. Mathias explained that while Arduino is nice for basic electronics, he thinks that Modularis provides a much better entry point for learning about control theory and systems. We are planning to have some more meetups about teaching system design with Modularis soon.

A note about getting a Modularis Kit: Mathias is still working on the online shop, opening around 1st of July at You will be able to buy the basic module MOD000 with a USB programmer. Code and libraries will be available at Github.

Learning about the Arduino toolchain

The question “What does Arduino mean?” is rather important. Even more so, in the light of the ongoing Arduino vs. Arduino conflict. But, what would Arduino without “Arduino” mean? Discussing the technical aspects of this question was the topic of the meetup yesterday. While you may be using “Arduino” to label some electronic components, Arduino also means software, libraries, a user experience and a community.

Assuming Arduino means something to blink a LED, Elliot Williams gave his view on tinkering with 8-bit AVR microcontrollers. Elliot is author of the book “AVR Programming - Learning to Write Software for Hardware” and a contributor to the Hacakday blog.

Before discussing blinking LEDs, Elliot had some general advice for Arduino beginners.

First, always include a slider or potentiometer in your electronic projects. The moment will come when digital 0’s and 1’s are not enough to make your users happy. And you better think about analog inputs soon.

The second advice was to solder a resistor on a LED for learning purposes. With this “LEDresistor”, you can easily try out pin functions of a microcontroller. Now, you can plug this component easily into any board or try out software, with or without “Arduino”.

led resistor

In the main part of this talk, he showed us a bit of reverse engineering of the Arduino IDE. For example, on how to log everything with a script when you press the compile and upload buttons. The IDE basically wraps a GCC build process, and it is not too difficult to build some blink code from scratch.

However, the question now is: Why you would like to tinker with “Arduino”? The Arduino IDE does its job quite well. Being able to run the tools yourself, gives you a bit smaller code but at a cost of a rather bulky, complicated setup.

But knowing your tools has advantages too. If you have to flash many boards for example, you could use a custom build script to include things as serial numbers. And, you can configure code for different devices easier. Portability to other hardware (e.g. ARM based chips) might be another reason to start a custom build process. And, last but not least, you finally could learn “real” C programming instead of the “.ino” programming style from “Arduino”. Knowing your build tools can also influence you working with an IDE. For example, you can more easily include arbitrary C code in your Arduino projects.

Now, get a LED and try to get it blink. And then, judge for yourself, what “Arduino” stands for!

Thanks Elliot for the talk and MuMaLab for hosting the meetup.


I2C meetup with Dan Hienzsch

In March, we were lucky to host Dan Hienzsch from Rheingold Heavvy in our meetup.

I2C is about communication between multiple components. Dan provided a number of examples how I2C applies to the usage of the real-time clock, a temperature sensor or a display.

Dan explained how he designed the I2C and SPI Education Shield. First, we got insights into PCB design and some common calculations when designing I2C signal lines on a PCB. A good place to learn about these things is ContextualElectronics.

After a better feeling for signal physics, we had discussions about pins for I2C on Arduino and the code in the Arduino Wire Library. For I2C, the internal pull-up resistors are enabled by default, so it is important to check if they must be disabled or not. If there are pullup resistors on the circuit board, disable the internal pull up resistors.

Then here is addressing of nodes on the bus. Many components have their I2C address hardcoded by the manufacturer, but some components can be configured to take a certain address by so-called “configuration pins”. The address is always listed in the datasheet for the component for reference.

When it comes to sending addresses, there is the question about timing of bits. I2C has a clock line (SCL), and a data line (SDA). A bit is clocked in from the data line during the full pulse of the clock. Transitions between high and low on the data line must happen between clock pulses.

Signals on the SCL and SDA lines follow certain rules. And Dan taught us a number of them. First, components (= slaves) on the bus can be idling in the Free State. To announce a new message, the master pulls the SDA line LOW to create the Start Condition. Then comes the address, and then, whether the master expects to READ data, or to WRITE data to the slaves.

After the R/W bit, the master listens for an acknowledgement from the slave component that everything was understood. This is the ninth bit, the ACK/NACK bit. With I2C it is often necessary to write data first, before data is read. This, and the fact that every message frame contains some address bytes, make I2C communication inefficient.

With only 2 signal lines, I2C is easy to debug however and great for learning more about advanced electronic communication. And the I2C and SPI Education Shield will provide a great learning device, maybe for another meetup.

The write up on I2C is available on Dan’s website at

Thanks to Dan for the great and entertaining I2C introduction!

PS Robert also shared a link about hacking a flipdot display.

IDEO invited to discuss Magnficent Machines

Yesterday, there was the discussion about Magnificent Machines with Massimo Banzi, Dario Buzzini and Anne Pascual at IDEO Munich.

The evening and discussions were great.

Some quotes from Twitter:

Next events

In February, IDEO will host events about interaction design and IoT with Massimo Banzi. You must sign up for the IoT Arduino workshop.

Then, we have a visit from Rheingold Heavy who will introduce us to I2C.

The preliminary talk outline is:

  • Introduction and origins of Rheingold Heavy
  • Turning code into electronic messages
  • Architecture of I2C
  • I2C Signaling Specifics
  • The Arduino Wire Library
  • Demo of ICs on the I2C shield

Also, there will possibly be an event with an application engineer from Infineon who will talk about their motor and light control shields.

January meetup

For the first meetup of the year we were lucky to have a number of TI connected Launchpad boards including some sensor boards (“Boosterpacks”). TI sponsored those to MunichMakeS.

The goal of the TivaC platform is to enable IoT applications. The MPUs are mostly ARM based. The best TM4C123x based boards had an impressive clock speed of 120 MHz.

First contact

Some of the meetup members liked the sensor boards, even more than the network capabilites of the boards. For example, there was a booster pack with Motion sensors which many tried out at first, and via serial communication, it was quickly possible to read out data from body motion.

But we had a bit of problems too, the Wifi of the Makerspace was a bit shakey to maintain WLAN connection of many devices. So, the stopped at a bit the exploration into the IoT direction.

Also, at least 50% of the meetup members are used to working with MacOS and/or Linux. While Energia supports those, some had problems with the Java version of Energia. For example, Marten had to downgrade his installed Java version.

Board pinouts

We had a bit trouble decyphering the pinouts of the boards. On one hand, this could be due to he many functions on the board. There are several push buttons mapped to pins, but not every input worked as expected compared to Arduino code. I found the header file: pins_energia.h very helpful to decode those. Also, the TMC4123x provides pull-up/pull-down input configurations, which are helpful, but it must be known where to look.


All in all, a very interesting hacking adventure. This meetup was certainly a bit more for advanced users. Some members borrowed a board for playing at home, and we are expecting to see more TivaC details soon.

Please help us making the Arduino & Co meetup better by answering again some questions in a survey.

Results from December Survey

Here are the results from last week’s survey about the first 6 months of the Arduino & Co. The survey was sent to our 120 members right now and we had a small 10% respond rate.

What topics at Arduino & Co do interest you most?

So, interestingly, the meetup members mostly enjoy classical talks about microcontoller basics or projects.

What is the best place for the meetup?

The most popular locations arte the Munich FabLab and MCSM/MunichMakes. In contrast to most web meetups, hacker spaces seem to provide a better context than companies.

What discoveries did you make at the meetup?

Currently, the meetup provides most value in combining online and offline worlds. So, maybe the meetup should provide more pointers to online conent. Or, as with this website, further develop online and offline content. Last, there was a remark that teaching Arduino to kids should play an important role.

Take part.

The survey is still open for a while. It would be great if you take part too. Thanks in any case!