Arduino + Raspberry= Weather station with webcam (Part Two: the meteo data acquisition)

Hi geek boys and girls!

I hope you passed a very nice Easter holidays. Unfortunately I had the flu during these days…so no great funny time for me! 😦

…But I spent some time developing my weather station (I wrot the code for meteo data acquisition, and then I succesfully connected to the Raspberry a webcam and also a internet dongle for the remote access to the weather station).


In this post I will talk about the meteo data acquisition from Arduino and the consequent data trasmission from Arduino to Raspberry via I2C (see my previous post in order to activate the I2C link).

I decided, after some unfruitful (or simply too diffcult to implement) experiment with analog sensors, to use only digital sensors to acquire with Arduino temperature, barometric pressure and relative umidity. So I bought these sensors from Robot Italy (my preferred online store for embedded resources… as you know I love all italian products/services 😉 ):


This is the final circuit I’ve realized after some very basic integration test (click on the image for the zoom):

Centralina_meteo_v2_bbNote that I used a resistor of 4.7 KOhm instead 5 KOhm, as suggested on the DHT11 datasheet.

Ok, now it’s time to code some litttle skecth. Let’s start with Arduino.

In order to communicate with DHT11 and with MPL115A1 I used two well known libraries.

I took the DHT11 library from Arduino Playground and I took the MPL115A1 lib from the github of SMacarena (great appreciation for these very good works, and my sincere thanks to the authors 😉 ).

After some cut/paste/washing/ironing/rewashing and some other (not too many,you know me! ;-)) tests, this is the final Arduino code for the meteo data acquisition from sensors:


#include <SPI.h>
#include <MPL115A1.h>
#include <dht11.h>
#include <Wire.h> //I2C library

#define __DEBUG__ //note: I used for debug a ht1632c led display
                  //If you can't/don't use it, undef this macro! :-)
#ifdef __DEBUG__
#include <ht1632c.h>

//debug display
ht1632c dotmatrix = ht1632c(&PORTD, 7, 6, 4, 5, GEOM_32x16, 2);

//i2c settings
#define SLAVE_ADDRESS 0x04
int number_command = 0;
float value_to_send=0.0;

//I2C commands
#define TEMP 1
#define HUMI 2
#define PRES 3
#define DEW 4

//out pint for DHT11 sensor
#define DHT11PIN 2

MPL115A1 Pressure_sensor;
dht11 DHT11_sensor;

//current atmo values
float current_pressure=0.0;
float current_humidity=0.0;
float current_temperature=0.0;
double current_dewpoint=0.0;

void setup() {
  //serial setup
  //initialize pressure sensor

  // initialize i2c as slave

  // define callbacks for i2c communication
#ifdef __DEBUG__

void loop() {
  //take & save pressure values
  current_pressure = GetPressure();

  //print current valueson serial ...debug (remove it if you want)!
  Serial.print(" hPa\n");

  Serial.print (current_humidity);
  Serial.print(" % Humidity\n");

  Serial.print (current_temperature);
  Serial.print(" °C\n");

  Serial.print (current_dewpoint);
  Serial.print(" Dew point (°C)\n");
#ifdef __DEBUG__
  char tmp[20] = "";
  sprintf(tmp, "P=%dhPa", (int)current_pressure);
  byte len = strlen(tmp);
  for (int i = 0; i < len; i++)
    dotmatrix.putchar(5*i, 0, tmp[i], ORANGE);

  sprintf(tmp, "T=%dC", (int)current_temperature);
  len = strlen(tmp);
  for (int i = 0; i < len; i++)
  dotmatrix.putchar(5*i, 8, tmp[i], RED);
  sprintf(tmp, "H=%d%%", (int)current_humidity);
  len = strlen(tmp);
  for (int i = 0; i < len; i++)
     dotmatrix.putchar(32+5*i, 8, tmp[i], GREEN);


//Acquisition functions
//from sensors
float GetPressure()
  float hPa = Pressure_sensor.pressure();
  return hPa;

void GetTemp_Humidity_DewPoint()
  //take & save DHT11 values (temp + rel. humidity)
  int chk =;
  switch (chk) //check errors
    case DHTLIB_OK:
      Serial.println("read OK");

      //read values

      //dew point
      current_dewpoint=dewPoint(DHT11_sensor.temperature, DHT11_sensor.humidity);

      Serial.println("Checksum error");
      Serial.println("Time out error");

     Serial.println("Unknown error");

//dewpoint function (taken from
// dewPoint function NOAA
// reference (1) :
// reference (2) :
double dewPoint(double celsius, double humidity)
  // (1) Saturation Vapor Pressure = ESGG(T)
  double RATIO = 373.15 / (273.15 + celsius);
  double RHS = -7.90298 * (RATIO - 1);
  RHS += 5.02808 * log10(RATIO);
  RHS += -1.3816e-7 * (pow(10, (11.344 * (1 - 1/RATIO ))) - 1) ;
  RHS += 8.1328e-3 * (pow(10, (-3.49149 * (RATIO - 1))) - 1) ;
  RHS += log10(1013.246);
  // factor -3 is to adjust units - Vapor Pressure SVP * humidity
  double VP = pow(10, RHS - 3) * humidity;
  // (2) DEWPOINT = F(Vapor Pressure)
  double T = log(VP/0.61078); // temp var
  return (241.88 * T) / (17.558 - T);

//I2C callbacks

// callback for received command
void receiveData(int byteCount)
  while(Wire.available()) {
    number_command =;

    if(number_command==TEMP) { //request temperature
      value_to_send = current_temperature;
    if(number_command==HUMI) { //request humidity
      value_to_send = current_humidity;

    if(number_command==PRES) { //request humidity
      value_to_send = current_pressure;

    if(number_command==DEW) { //request dewpoint
     value_to_send = current_dewpoint;

// callback for sending data via I2C
void sendData()
  //convert the float values in a vector of 4 bytes to send via i2c bus
  char vector_to_send[4];


Write the above skecth on the Arduino UNO and power on it….on the serial shell (and/or on the led display) you will see the vaues taken from the sensors.

Ok, let’s go ahead with the correspondant Raspberry PI code (at the moment it is implemented in an interactive way). It is a little more simple than the Arduino one (it is derived from the original one, but in thsi case I manage the transmission via I2C of float numbers, mapped each one on 4 bytes):

//ML meteo lab station v2.0 Raspi side
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <linux/i2c-dev.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <unistd.h>

// The PiWeather board i2c address
#define ADDRESS 0x04

#define TEMP 1
#define HUMI 2
#define PRES 3
#define DEW 4

// The I2C bus: This is for V2 pi's. For V1 Model B you need i2c-0
static const char *devName = "/dev/i2c-1";

int main(int argc, char** argv) 
  printf("I2C: Connecting\n");
  int file;

  if ((file = open(devName, O_RDWR))< 0) {
    fprintf(stderr, "I2C: Failed to access %d\n", devName);

  printf("I2C: acquiring buss to 0x%x\n", ADDRESS);

  if (ioctl(file, I2C_SLAVE, ADDRESS) < 0) {
    fprintf(stderr, "I2C: Failed to acquire bus access/talk to slave 0x%x\n", ADDRESS);

  int command;

  for (command= 1; command<=4; command++) {
    int val;
    unsigned char cmd[16];
    //printf("Sending %d\n", val);

    cmd[0] = command;
    if (write(file, cmd, 1) == 1) {

      // As we are not talking to direct hardware but a microcontroller we
      // need to wait a short while so that it can respond.
      // 1ms seems to be enough but it depends on what workload it has

      char buf[5];
      if (read(file, buf, 4) == 4) { //read 4 byte from i2c (a float -temp, humidity etc.-)
        float value_received;

      //convert 4 bytes received into a float
      //print the results
      if (command==TEMP)
        printf("Temperature (°C)= %f\n", value_received );
      if (command==HUMI)
        printf("Humidity (%)= %f\n", value_received );
      if (command==PRES)
        printf("Pressure (hPa)= %f\n", value_received );
      if (command==DEW)
        printf("Dew Point (°C)= %f\n", value_received );

   // Now wait else you could crash the arduino by sending requests too fast

  return (EXIT_SUCCESS);

Compile the Raspberry program with the same old gcc -o meteo_lab meteo_lab.c , then, if Arduino is already powered on, launch the program with ./meteo_lab

You will see on the Raspberry shell the current values for temperature, relative humidity, pressure and dew point temperature acquired (and calculated, in case of the dew point temperature) by our two sensors.

….So, you can monitor in each moment your lab weather condition! 🙂

Ok, I think you are thinking it is not too much….So, in the next posts we will see how to visualize these data (with a good webcam image on the side) on a web page accessed from internet… this is much more interesting or not? 😉

Bye bye geeks, c ya soon!



Arduino + Raspberry= Weather station with webcam (Part One: the I2C link)

Hi geek boys and girls!

After few more technical and obscure posts, finally I give some (original? I don’t think so…but it’s funny!) creative idea for your *ware open source projects.

With this post I would like to start building a open source meteo weather station.

In order to do this task I think you could connect together, such as a great cup of Mojito 🙂 :

  • A set of sensors (i.e. humidity, barometric pressure, temperature)
  • One little camera (i.e. we could start with an inexpensive webcam…if the weather conditions would permit its use!)
  • One Arduino UNO (or one Intel Galileo ;-))
  • One Raspberry PI Model B
  • One GSM module, or more simply, one less expensive USB internet key (to access via internet to your station)

Ok, first question: why Raspberry AND Arduino (and not only one board)?

Well… I would like to use Arduino to manage all sensors (especially if they would be analog sensors, since Raspberry doesn’t have analog inputs), and I would like to use Raspberry to manage the webcam and the communication with the external world via the GSM module (since it has  high-level functiona).

So I will use Arduino as acquisition board and Raspberry as data collector and as webserver.

Raspberry and Arduino can talk to each other using some different approaches, but I would like to use the I2C protocol, because it’s very simple and very well supported by Raspbian distribution and by native Arduino libraries.

I found this interesting post by Peter Mount in order to safely connect Arduino (as slave) and Raspberry (as master) using I2C.

In order to activate the I2C bus on Raspberry Peter reports five step on Raspbian:

  1. Open /etc/modprobe.d/raspi-blacklist.conf and comment the line reporting  i2c-bcm2708 (so, I2C is removed from blacklist)
  2. Add i2c-dev to the /etc/modules in order to activate the I2C driver at boot
  3. Install i2c-tools using thje well known apt-get install command
  4. Add the “pi” user to the i2c group (using the adduser pi i2c command) in order to let the user “pi” can access to I2C
  5. Reboot the Raspberry board.

In order to phisically connect Arduino and Raspberry via I2C:

  1. Connect SDA Raspberry pin (GPIO0) to SDA Arduino UNO pin (Digital IO 4)
  2. Connect SCL Raspberry pin (GPIO1) to SCL Arduino UNO pin (Digital IO 5)
  3. Connect the ground pins fo the two boards

Remember that Raspberry uses 3.3V as base voltage and Arduino UNO uses 5V…so pay attention: OR if you use a voltage converter in the I2C connection OR you are sure that you are using Arduino as slave I2C device and Raspberry as master I2C device. The first one choice is the best…but I love the risks (the risk in this cas is to have a “Raspberry flambé” 😉 ).

Ok, let’s go ahead. I used a little analog temperature sensor (the one provided in all starter kits by Analog Devices! 😉 ) connected to Arduino UNO (in the Analog input A0)  and then I modified the code provided on the Peter Mount blog in order to read the ambient temperature using Arduino and send it to Raspberry via I2C bus.

This is the simple circuit I used (zoom to better view the links):


The code on Raspberry is the following (it’s directly taken from Peter Mount Blog, except for only one correction: I defined file as FILE* since declared as int raised a segmentation fault on fclose call….):

#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <linux/i2c-dev.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <unistd.h>

// The Arduino board i2c address
#define ADDRESS 0x04

//For V1 Model B you need i2c-0
//For V2 you need i2c-1( my case I have a V2 Raspberry Pi! :-) )
static const char *devName = "/dev/i2c-1"; //)

int main(int argc, char** argv) {
 if (argc == 1) {
   printf("Supply one or more commands to send to the Arduino\n");

 printf("I2C: Connecting\n");
 FILE* file;
 if ((file = open(devName, O_RDWR)) < 0) {
   fprintf(stderr, "I2C: Failed to access %d\n", devName);

 printf("I2C: acquiring buss to 0x%x\n", ADDRESS);
 if (ioctl(file, I2C_SLAVE, ADDRESS) < 0) {
   fprintf(stderr, "I2C: Failed to acquire bus access/talk to slave 0x%x\n", ADDRESS);

 int arg;
 for (arg = 1; arg < argc; arg++) {
   int val;
   unsigned char cmd[16];
   if (0 == sscanf(argv[arg], "%d", &val)) {
     fprintf(stderr, "Invalid parameter %d \"%s\"\n", arg, argv[arg]);

   printf("Sending %d\n", val);
   cmd[0] = val;
   if (write(file, cmd, 1) == 1) {
    // As we are not talking to direct hardware but a microcontroller we
    // need to wait a short while so that it can respond.
    // 1ms seems to be enough but it depends on what workload it has
    char buf[1];
    if (read(file, buf, 1) == 1) {
      int temp = (int) buf[0];
      printf("Received %d\n", temp);

   // Now wait else you could crash the arduino by sending requests too fast
  return (EXIT_SUCCESS);


The code on Arduino UNO  is very simple and it is derived from the code taken from Peter Mount Blog:

#include <Wire.h>

#define SLAVE_ADDRESS 0x04

int number = 0; //command identifier (sent by Raspberry)
double temp; //variable used to store the temperature
const int sensorPin = A0; //pin where we read the temperature from the sensor
void setup() {
 // initialize i2c as slave
 // define callbacks for i2c 
void loop() {
 temp = GetTemp();
// callback for received data from I2C
void receiveData(int byteCount){
 while(Wire.available()) {
 number =;
 //"2" is the command sent by Raspberry Pi in order to have the 
 // temperature as answer on I2C from Arduino
 if(number==2) { 
     number = (int)temp; //Arduino in this case sends the integer value of temperature
// callback for sending data on I2C
void sendData(){

float GetTemp(){
 // read the value on AnalogIn pin 0 
 // and store it in a variable
 int sensorVal = analogRead(sensorPin);

 // convert the ADC reading to voltage
 double voltage = (sensorVal/1024.0) * 5.0;
 // convert the voltage to temperature in degrees C
 // the sensor changes 10 mV per degree
 // the datasheet says there's a 500 mV offset
 // ((voltage - 500mV) times 100)
 double temperature = (voltage - .5) * 100;
 return temperature;

Ok… we can now download the cvode on Arduino and we can compile the client software on Raspberry Pi using the good old command:

gcc -o TakeTemp main.c

So, once powered on Arduino and verified using the Raspberry command

i2cdetect -y 1

that Arduino is correctly detected with I2C address 0x04, write in the Raspberry command line

./TakeTemp 2

Note that “2” is the I2C command used to receive from Arduino the acquired temperature (see the Arduino code above).

…If all will work correctly, you will read as output the integer value of the sensor temperature, acquired by Arduino and sent to Raspberry via I2C!

Yeah geek guys (and obviously geek gals)…”this is one small step for the human race”, but it’s also a good start to develop an open source meteo station. 😉

And now… a good relax!:-) That’s all folks (for this time)! 😉

…Bye bye!

The dark side of porting Arduino sketches on Intel Galileo (part two)

Hi geek friends ( female & male)!

This is the post of the “real dark side” of porting external hardware control from Arduino to Intel Galileo. And, it’s just an example, a little sketch of the real work.

…Are you ready? Before starting this dangerous “trip” I want you send a first warning: unfortunately the x86 (the architecture of Intel Quark, the CPU inside the Intel Galileo) is very different from the architecture of the AVR (the Arduino MCU). So, registers, memory spaces etc. are completely different (Monty Python docet!).

My (insane, very insane 🙂 ) idea was to port some “lower level” code from Arduino Mega to Intel Galileo, in order to verify on my skin the real hardware differences between the two platforms and also in order to compare the “hardware level” performances.

I opened the “Arduino on Android kit” (a very appreciated gift from Monica! ;-)) and I found two very interesting hardware components: two ht1632c bicolor (red/green) led displays.

What a cool find! 😉 I love the shifting dysplays in the chinese stuff stores! 😀

So… I googled for already working driver on Arduino for these devices. I found some very interesting solution. The first one library is here, and it is very powerful and fast in my little opinion.

I tried on the Arduino Mega all the library demo sketches and I verified the correct work for my two displays. Looking inside the code I saw that all the library is based on AVR registers programming (using in every instruction all the possible bit-field functions, bit masks, bitwise operators and so on…).

Weahhhh…ok, I know this is the correct mode to write a driver, and it’s true that I wanted to go to a “lower level”…. but not so low! 😀

Indeed, once ported the code inside the Intel Galileo IDE, a so high number of “undefined references”  gave me the real proof that NOT ALL the AVR architecture has been ported by the Intel team in the Galileo development environment…. so we have two natural choices: the first one is to rewrite all the library using the Quark registers instead the AVR registers (but we are inside a Linux environment, it’s no so simple to manipulate the low level hardware without interact with the Linux kernel) or, the second choice is try to write a library at an higher level, using only the basic functionalities  (so using the native APIs) of Arduino.

I preferred the second oprion (…you suspected it, I know! :-)), so  I started looking for a little simpler (and without too many functionalities) library working directly on Arduino GPIOs, in order to simplify the porting phases (and possibly without losing my love in microelectronics 😉 )

I found the code  and the circuit reported on Arduino Playground (I love this site…because it’s a made in Italy product. You know, we don’t have only corruption, not-so-effordable persons & politicants… and soccer 😉 )….and -oh, oh- it was exactly what I was looking for. 😀

I took all the code and, after I removed the parts (code and hardware) related to the real time clock (because actually I don’t have a RTC!), I compiled the code in the Arduino IDE and I flashed it on my Arduino Mega. I obtained a “fixed hours and day” red and green clock on my two led displays. The draw of the displays is very fast (approx. immediate).

Ok, I ported the same code in the Galileo IDE and I obtained some compilation errors, tied to the hardware differences between Arduino and Galileo. This is the pinout for display I used:


Mainly Galileo IDE doesn’t have the <avr/pgmspace.h>… it’s natural since it’s a x86 CPU…but it is also a problem, because the great majority of third party lins use this file and its definitions (especially to declare some variable directly in the program flash, since Arduino doesn’t have so much RAM).

But since Galileo has a lot of RAM, it isn’t necessary to save data in the flash program space.

So, following the defines reported in avr/pgmspace.h , I changed in the file font1.h definitions:


in a simple

char* CHL[] = [...] .

After this, I removed the #include <avr/pgmspace.h> in the main .ino file,  and in the same file (function set_buffer()) I changed the line :

memcpy_P(buffer[j], (PGM_P)pgm_read_word(&(CHL[j+pos])), 8);


memcpy(buffer[j], (const char *)(&(CHL[j+pos])), 8);

Once resolved the errors, I compiled and flashed the code on Galileo.

I obtained a strange behavior: instead of the clock some strange character appeared on the two displays, with a very very (very! 😦 ) slow draw rate.

Ok, I think the strange characters are tied on a non perfect alignment on the memory in the x86 respect to the AVR  or to different sizes of some data type, especially due to the above memcpy porting  (but I didn’t investigated so much because I was worried by the displays slow draw rate). So, I changed the initial code in order to write a text on display pixel by pixel (note that this is the same approach of the original code), starting from drawing a single pixel in a certain (x,y) coordinate.

The differences between the initial code and my modified code can be easily found comparing the code in the page of Arduino Playground and the attached the zip file.

I attach the complete code as zip file since the code is too long for a blog post…and I think this post is already too long. But remember this is a “difficult” post. It MUST be long! 😉 Please excuse any commented code and some commentsin Italian…I know this is a lab “spaghetti code” . 😉

Ok, using this code the text is shown in the correct way on Intel Galileo (….to be investigated the strange drawing with the original code! 😉 ), but using Galileo the draw process took approx. 20 seconds (versus the Arduino result, which is minor than 1 second!!!) and with some different delay times between one pixel draw and the subsequent.

This is the final result (sorry for the up-down text, but I have very short wires between Galileo and the display…;-) ). In the background of the photo you can see two beautiful italian progressive rock cds by Maurizio di Tollo and by La Maschera di Cera (both my good friends), which have been the inspiration for my porting work. 🙂


Any ideas for this behavior (the slow drawing process)? I have one…but I don’t know if it is the correct idea.

As you know, Intel Galileo runs the Arduino sketches as Linux user processes (so, all kernel calls, interrupts, threads etc. have a higher priority  than a user process and so they can interrupt the execution of the Arduino skecth), whereas in Arduino no operating system is used (the sketch is a well-known “bare metal” code), so a real time behavior is a “true real time” behavior, and the sketch runs at the highest speed without interruptions.

So… what can I say? Intel Galileo is a really fast machine (compared to Arduino Mega or UNO) but in my little opinion it has some little “real time” problem when using the Arduino IOs (also I know my code is not optimized at all!!! 😉 ). And you? What do you think? 😉

Please, express your geek thinkings, and find al my errors! I will appreciate each contribution, especially  tied to my errors….the knowledge is always a mindstorm! 😉

Bye bye folks, now I go on my sofa to drink my brandy.

Another day is passed…another post is written. 🙂



Intel Galileo: I can’t live without a shell…

Hi ,

as promised in my last post, it’s time to write some code and to create some solded part! 🙂 So…let’s start.

An embedded Linux board without a shell has no sense in my opinion. I think this after many, many, toooooo many experience with embedded boards, so similar to black boxes! 😦

You know, I prefer the old style serial shell (the original RS-232 one!), but since Intel Galileo has a fast ethernet plug one can use also a telnet or ssh connection.

So, if you prefer the RS-232 shell, you must build a simple cable in the following way:


  • One jack 3.5” stereo male connector (you can reuse it form an old pair of earphones!)
  • One DE-9 pin standard female connector for RS-232
  • Three not too long wires
  • Some basic soldering skill 🙂

Schema (drawn by myself ):

serial Galileo

The cable will be connected to the Galileo using a devoted female jack 3.5” connector (right, you can’t use it to plug in your earphones! ^__^) and to the host pc via a native RS-232 male connector or (more probably) using a ten-euros Usb-to-Serial converter.

At this point you will connect to the Galileo using a shell program (in Linux and Mac I use Minicom, on Windows I use PuTTY) with the following (I know, you know… they are always the same) parameters:

  • Serial Port: the identifier of the connected port on the host pc (i.e. COMxx, /dev/ttyUsbx etc. depending on your operating system)
  • Speed: 115200 bps
  • Flow Control: None
  • Parity: None
  • Stop bits: 1
  • Data bits: 8

If you prefere a more “network oriented” solutyion, you can use a telnet shell.

In order to do this, you must download a particular sketch via Arduino IDE for Intel Galileo. This sketch will call some Linux system shell commands (yes, you can launch Linux shell scripts using the Arduino skecth programming…it’s very interesting and it is one of the more celebrated features of Intel Galileo!!!).

You can connect the host pc and the Galileo board via cross-patch network cable or using a Fast Ethernet switch between the host pc and the board.

This is the sketch I used . You can copy/paste it on the Arduino IDE then you will download it on Galileo after his boot, lastly open the IDE serial terminal to see the output of linux commands.

//Sketch to connect a PC host to Linux Galileo via telnet 
// Written by M. Lastri fo
//The sketch will:
//1. set the Galileo IP to 
//2. start telnet server
//------>>>>>After this the user can:
//3. From the pc host (i.e. with IP = send ping and verify the answer
//4. From the host send the famous command "telnet"...and the Linux Galileo shell should appear (user: root, no password)!
//5. Enjoy!
void setup() 
  system("ifconfig > /dev/ttyGS0");
  system("ifconfig eth0 netmask up");
  system("ifconfig > /dev/ttyGS0");
  system("telnetd -l /bin/sh");
void loop() 
  //nothing here 

Important note: someone on internet verified that if Galileo starts without the ethernet cable connected, the telnet server will not start properly, so, ensure that you will power on the Galileo board with the ethernet link connected (directy to the host pc or to the switch).

Another important thing: if using for Galileo and for host pc the well known LAN addresses 192.168.1.x with mask, the connection between pc and Galileo doesn’t seem to work in my setup. It is a very strange behavior in my opinion…so we should investigate on it! 😉

In the next post dedicated to Galileo I will start to play with porting sketches (and their problems) from Arduino UNO/Mega ADK  to the Intel platform. Well’ verify that it’s no so simple… or, better,as we say in Italy, “It isn’t all gold which is brilliant” ! 🙂

…Bye (male & female) geeks!

Galileo, Galileo… and me.

…Gooooood morning people!!!

My name is Marco Lastri (ML), I am an italian pro system-software engineer and also a pro-am musician.

I work as software engineering manager in scientific areas tied to artificial satellites. I have approx. 25 years of experience in computer science, algorithms, architectures and programming (I started to program my first computer at 12)…and I play any kind of software and hardware synthesizer. And also a little of drums! 🙂

I am interested in the music-electronics-software interaction (because I am not a good piano player! 🙂 ), so I tried to study Arduino (Intel Galileo), Raspberry PI platform and some other ARM based boards in order to create projects often tied to wearable musical instruments (yes, I love all old-style “keytars” such as Moog Liberation!!! 🙂 ).

2014-02-24 07.45.14

So I decided to try this experience: a personal blog dedicated to my projects and to my ideas, based on open source hardware and software solutions.

…You will find here also tips’n’tricks found during my studies on these “black boxes” (damn’ lack of documentation!) called “embedded boards” !

This blog has been created in collaboration with the SirsLab of Università di Siena and with SirsLab official blog (many thanks to professors Domenico Prattichizzo and Monica Malvezzi), in order to share with the SirsLab people experiences on the wearable controller devices.

Firstly… why Arduino? Because it’s an italian product, an italian (good) idea. Because Italia is not only “spaghetti, pizza, mandolinoand corruption. 😉

…Why open source? Because I think it is the only way to create low price new ideas, also created by unexperienced people (but with great mental strenght!).

…Why an english blog? Beacuse, also if my english is poor, I think it’s a simpler way to share with the internet my ideas and my experience.

…Finally, why this blog is called “ML Garret Labs“? Because at the moment my lab is  in my garret…. 🙂

Bye bye tech-geeks…and stay tuned!

PS: in the photo with Galileo, Galileo and me…  there was also Figaro Magnifico (cit. Queen), but it was too on the right 🙂