Logging temperature using an Arduino and AD7410 sensor

This article is a quick and dirty demonstration to hack yourself a temperature data logger which saves its results to an SD card. The sensor of use is a HTU21D, a I²C temperature and humidity sensor.

hookup

Schematic:

hookup_bb

I hooked up a HTU21D sensor to an Arduino Uno + SD-card shield and let it monitor temperature (and humidity) over an entire day:

24h_log

Here is a close-up of what happens at night:

3h_log

Source code:

/*
 SD card datalogger

This example shows how to log data from three analog sensors
 to an SD card using the SD library.

The circuit:
 * analog sensors on analog ins 0, 1, and 2
 * SD card attached to SPI bus as follows:
 ** MOSI - pin 11
 ** MISO - pin 12
 ** CLK - pin 13
 ** CS - pin 4

created 24 Nov 2010
 modified 9 Apr 2012
 by Tom Igoe

This example code is in the public domain.

*/
 /*
 HTU21D Humidity Sensor Example Code
 By: Nathan Seidle
 SparkFun Electronics
 Date: September 15th, 2013
 License: This code is public domain but you buy me a beer if you use this and we meet someday (Beerware license).

 Uses the HTU21D library to display the current humidity and temperature

 Open serial monitor at 9600 baud to see readings. Errors 998 if not sensor is detected. Error 999 if CRC is bad.

 Hardware Connections (Breakoutboard to Arduino):
 -VCC = 3.3V
 -GND = GND
 -SDA = A4 (use inline 330 ohm resistor if your board is 5V)
 -SCL = A5 (use inline 330 ohm resistor if your board is 5V)

*/

#include <SPI.h>
#include <SD.h>
#include <Wire.h>
#include "SparkFunHTU21D.h"

//Create an instance of the object
HTU21D myHumidity;

const int chipSelect = 4;

// make a string for assembling the data to log:
String dataString = "";

void setup() {
 // Open serial communications and wait for port to open:
 Serial.begin(9600);
 while (!Serial) {
 ; // wait for serial port to connect. Needed for native USB port only
 }

 myHumidity.begin();
 Serial.println("HTU21D ready!");

Serial.print("Initializing SD card...");

// see if the card is present and can be initialized:
 if (!SD.begin(chipSelect)) {
 Serial.println("Card failed, or not present");
 // don't do anything more:
 return;
 }
 Serial.println("card initialized.");
}

void loop() {
 readTemp();

Serial.println("Writing data...");
 // open the file. note that only one file can be open at a time,
 // so you have to close this one before opening another.
 File dataFile = SD.open("datalog.txt", FILE_WRITE);

// if the file is available, write to it:
 if (dataFile) {
 dataFile.println(dataString);
 dataFile.close();
 // print to the serial port too:
 Serial.println(dataString);
 }
 // if the file isn't open, pop up an error:
 else {
 Serial.println("error opening datalog.txt");
 }
 delay(10000);
}

void readTemp() {
 float humd = myHumidity.readHumidity();
 float temp = myHumidity.readTemperature();

 // make a string for assembling the data to log:
 dataString = "Time: ";
 dataString += String(millis());
 dataString += String("; Temperature: ");
 dataString += String(temp);
 dataString += String("; Humidity: ");
 dataString += String(humd);
 dataString += String("%");
}

This was just a quick and dirty hack to get some instant results. I’m planing to do some more logging in the future to get a better understanding of how to approach my self build climate control. Stay tuned for more.

Adafruit 16×32 LED matrix on Arduino Due

Beginning of January I saw a video demonstrating a clock which also plays Game of Life during displaying the clock. This so called Clock of Life uses the Adafruit 16×32 LED matrix and a Arduino Uno microcontroller board. I never came across this LED matrix before but it seems like a nice and popular display to tinkle around with, so off course it was only days later that I owned my own copy of it. As far as the clock goes, I’d very much like to achieve using it as a clock too, but the Game of Life option I’d  like to skip, instead I want it to be wireless connected to the internet so that NTP servers can help me keeping the time more or less correct and thrust worthy over longer periods of time, maybe even years. With this wireless connection of course come a lot more possibilities, like setting a alarm clock to wake you up by using your smart phone, set background images and let the user configure the clock remotely. Well off course there is lots of more features I could add, but let’s not start to think to wide before we can even get it working.

For the wireless connection I opted for using the Adafruit C3300 Wifi adapter. After receiving both this unit and the 16×32 LED matrix I noticed that combining both on a Arduino Uno was going to be pretty hard on pin usage. Furthermore I was also not very sure how processor intensive everything combined was going to be, and keeping in mind I might want to add even more features I opted for a more speedier and advanced solution: the Arduino Due. It’s a 84MHz processor with a lot more in- and outputs. First thing I did back in January was making sure NTP server requests indeed do work using the C3300 on Arduino Due as a standalone solution. Next: make another standalone version where I test the LED matrix, but it was then that I noticed the Adafruit 16×32 LED matrix is currently not supported for Arduino Due. Nooo!

After some googling I found out the display does take quite some processing power to display full colors. Some of the code has been really optimized for using the Arduino Uno/MEGA internal functionality. So it was more or less at this time that I started to notice this project was going to take a lot more time since I’d be writing the display driver myself. The Adafruit tutorial tells you some of the details of how the boards works, and if you read it very carefully you’ll notice it’s not so very difficult to do some basic stuff like lighting some LED in either a red, green, blue or white color, or not light it at all. However, for mixing colors and dimming the display more advanced programming is needed. But first something about the display.

Without getting to much into the details on how the display works electrically here are the available pins we should take care of:

inputidc

A, B, C => row address select pins
R1, B1, G1 => red, green, blue led on/off pin of a pixel of an upper row
R2, B2, G2 => red, green, blue led on/off pin of a pixel of an lower row
CLK => clock pin
OE => output enable pin
LAT => data latch pin

For the display to work you’ll have to send data at a constant rate as the display itself does not have any memory. This implies a lot of other stuff which I’ll get into more detail later. The A, B, C row address pins (3 pins = 3 bits) allow us to select 8 different addresses. For each address not one but two rows are being selected. So setting the bits for address 000 does not only select row 1, it also select another row being it the 9th. The 9th and not the second, because it allows to have less scan rate. For each row we have 32 pixels, so with 2 rows selected each time we set an address we now have 64 pixels available to manipulate (where each pixel has 3 LEDs, for red, green and blue color). Setting the pixel color however happens in a serial way, first one has to set a appropriate signal on the R, G, B pins, but because we have 2 rows selected at the same time we also have these R, G, B pins twofold. R1, B1, G1 for pixels in the upper region, and R2, G2, B2 for pixels in the lower region. Next the CLK (clock pin), LAT (data latch pin) and OE (enable pin) should be used to send the RGB LED’s On/Off state for each of the 32 pixels per line in a serial way.

16x32matrix

While this might not seem to complicated to understand, there is more than meets the eye. For drawing in either red, green, blue or white colors it’s as sample as setting only the correct bits at the RGB pins, though when one wants to set a yellow or purple or any other color more complex methods will be needed because we have only 3 bits per drawing cycle to our disposal. We will have to fool our user by setting a pixel first red, than blue, than red again, than back to blue, … nnd this very quickly so that for the user the different colors mix up into something that might look like purple. So let’s say with 3 bits we can have 8 colors, 2 drawing cycles would make 2 times 2 bits resulting in 6 bit color (= 64 colors), and 3 cycles would result in 9 bit color which represents 512 colors.

But it gets more complicated. What if we want to dim our display? We not only need to mix for the correct color, we also need more drawing cycles for PWM dimming the display (if the goal is to implement it). So Let’s say we mix to get to the correct color in 3 drawing cycles, we’ll probable need another 2-3 drawing cycles where all LEDs per pixel or not illuminating to get to the a 50% duty cycle. This however is a layman implementation because not all colors are evenly bright. Red for example requires only one LED, while white requires all LEDs to be illuminating and thus the white color will always be a lot brighter the full red. For this and other technical difficulties I did not yet think of I still need more time to work it out, for now I can only show you some basic code where the Arduino Due is used to show 3 bit color on the Adafruit 16×32 LED matrix:

2014-03-03 23.00.53

Opel/Vauxhall Vectra CAN interfacing

Since I got this car second hand it has been through a series of faults, failures and repairs (which is actually hard to avoid at a mileage of 150k+ km), but the cost of taking it to the Opel dealer every time pushed me in to the direction of doing some of the car repairs myself lately. The down side, the car being made in 2004, is full of sensors and so whenever a problem arises it is quite hard to make good  diagnosis without proper tools to read out this sensor data. Many times, engine failures are due to malfunctioning sensors for example. And so I started to think about interfacing the cars CAN bus and see what data I can get, unfortunately this is not like opening a serial terminal and watch data appear…

First of all there is this CAN bus which is a two wire (CAN-H, CAN-L) physical layer and on top of that a kind of networking layer which makes CAN look more like a networking protocol than the common RS232 serial link. As I’m not the only one to think of such a project I found quite some info online and also some libraries for Arduino to get me started. I also looked at some of the info I could get out of the Chinese Op-com clone I have around here, but unfortunately the unit had died.

Some Arduino CAN bus projects:

Canduino: https://code.google.com/p/canduino/

Seeed studio CAN-BUS shield: http://www.seeedstudio.com/wiki/CAN-BUS_Shield

Sparkfun CAN-BUS shield: https://www.sparkfun.com/products/10039

SK Pang CAN-BUS shield: http://www.skpang.co.uk/catalog/arduino-canbus-shield-with-usd-card-holder-p-706.html

Furthermore there is also some info regarding making a Raspberry-pi based CAN interface:

http://elinux.org/RPi_CANBus

http://lnxpps.de/rpie/

Another good link is this one with some basic CAN bus functionality explained and a Arduino schematic:

http://modelrail.otenko.com/arduino/arduino-controller-area-network-can

And the “Hacking You Car” article by Marco Guardigli:

http://marco.guardigli.it/2010/10/hacking-your-car.html

All together, most projects use a MCP2551 CAN transceiver and MCP2515 CAN controller so most schematics looks more or less the same and so one can use one schematic and try the different software libraries that are available for Arduino. And so I took the ODB connecter from the broken Op-com unit and used it in my own schematic which looks more or less like this:

schematic

DSC05983 DSC05981

After trying some of these libraries I noticed that the SK Pang library is the easiest one to quickly get some data out of your car. Although the default Arduino code allows to get out some basic engine info easily and in a human readable way, I found not very impressive and so I’m now exploring on how I can modify the code the get more info out of the car. In the latest SAE J1979 OBD standard there are 10 modes of functioning described, where SK Pang uses mode 1 ($01. Show current data) to request and show the engine data.  Requests depend on the PID (packet indentifier) one sends, whenever a ECU responsible for this PID sees the request it will get the data and respond. Standard PIDs can be found online here: http://en.wikipedia.org/wiki/OBD-II_PIDs. And  so I started trying every combination in between 0 and 255 to see which ones I can get a reply to, here is some of the info:

#Reply: 0*152#
#Reply: 1*129#
#Reply: 5*65#
#Reply: 11*103#
#Reply: 12*24#
#Reply: 15*62#
#Reply: 16*11#
#Reply: 32*160#
#Reply: 35*20#

the first number is the PID, the second one is its value, both in decimal form. To get human readable output one has to look up the code and use the appropriate method to convert the data into a correct format. For example, the frame with PID 5 (0x05 in HEX value) contains the engine coolant temperature, the formula is as following: A-40. And so, our engine coolant temperature is 65-40=15°C.

DC motor control (reverse engineering that old toy pt.2)

Since I had the electronics worked out the last time it was now time take this thing one step further and add some control to it. I first made sure the software in the Arduino controlling the DC motors was able to listen to its serial port for incomming commands and afterwards control the motors according to the command that it received. I made sure I had a second Arduino board available and by using XBee modules I could now send commands from my pc wireless over the ZigBee network to my remote Arduino controlling the DC motors.

Next I found myself a XBOX 360 controller and because it has dual joysticks it can control both DC motors, one joystick for each motor. This one I hooked up to my laptop and next I wrote a small interfacing program in Java that translates the XBOX360 code into commands that are being accepted by my Arduino program controlling the motors.

The result:

 

DSC05979Sketch:

sketch_final

DC motor control (reverse engineering that old toy pt.1)

Since my return home I’ve been doing some paperwork and other ridiculous stuff, catching up the last 6 months and off course going to the 10 day festival that is yearly organised in my Belgian home town. But then I stumbled upon one of my first electronic kid toys ever, a Raccoon RC car that was in really bad condition. It has 6 tires/wheels of which only 4 are left over and off course the remote control is missing too. So no fun, unless… And so I decided to revive this toy, not because I like RC cars that much, just because off having something to do during the day-hours of the festival (and to recover from parties the day before).

Because of the remote control missing I had to reverse engineer the current circuit board inside the car. Unfortunately, the toy is like 30 years old and so off course the toy is based upon analogic components instead of digital ones, and off course with the datasheets of some components are missing. Great! Though it did not hold me back to start measuring around and understanding what kind of voltage and current levels are involved in driving the motors, because when you get that there is not much more holding you back from throwing in an Arduino or Raspberry Pi for example to do the rest of the task.

The car architecture is as following: the car has/had 6 wheels, 3 on each side and each side of wheels is driven by one DC motor, so there are 2 motors in total. The car has no wheel that can turn so the only way of making corners is by having different speed on the wheels for each side. If the left wheels are turning slower than those on the right, the car will turn left. Off course!

DSC05950

From my measurements I found the motor control circuit to look something like this:

h-bridge_schematics_old
(click to enlarge)

The two horizontal resistors central in the picture are the motors M1 and M2. From my first drawing things looked way too complicated, but after reading up a bit about DC motor control through H-bridge NPN and PNP transistor configurations I noticed they did exactly the same thing in this circuit. If you’re not common with H-bridge configurations read up a bit:
http://www.instructables.com/id/H-Bridge-on-a-Breadboard/step2/H-Bridge-Theory/

What is so different here to most schematics is that 2 motors are driven from the same circuit. For one motor you need 4 NPN transistors (or 2 NPN + 2 PNP transisotors: http://letsmakerobots.com/node/9450) and probable you would repeat the same configuration for adding a second motor. But the above on is also working, but you must keep in mind two things:
1) both of your motors should always go into the same direction. You can’t make M1 turn your left wheels to the front and make M2 drive your right wheels in the opposite direction because then both transistor in the middle of the schematic (Q7 and Q10) will be made conductive and so you will create a short between Vcc and ground resulting in white smoke and popped transistors!
2) The transistors in the middle need to conduct both the current from M1 and M2 when both motors are used, make sure that the transistors are rated for the expected amount of current. So far example, if you want to drive forward one should make Q6 and Q8 conducting and also Q10 in the middle. While Q6 and Q8 handle the current for their motor only, the current comes together at returns leads from each motor and is than flowing into Q10 which should so be able to handle both currents together.

As far as 1) goes, that is something I can handle in software (Arduino). For 2) I made sure to reuse the original design in some way but adapt it to my own needs. The transistors were rated good enough for the old circuit so they should be good enough now too. Also note in the above schematic the potentiometer on top which allows one to correct the differences in motors speed as one motor will never be exactly the same as the other one.

h-bridge_schematics_new
(click to enlarge)

The main setup didn’t change much, overall the NPN transistor H-bridge remained but now the transistor are controlled by Arduino pins. For each pin I first had 22k resistors connected to the transistor base but later I swapped these to 1k resistors as the transistors that I have never came to conduct. A breadboard sketch would look like this:

sketch

I however soldered mine because my breadboard is still in use for some other project. Note that in the image above the transistor has the base as the center pin. This is however different to the C3279 transistors I’m using where pin 2 is the collector. Also note that the Fritzing drawing tool does not support a socket for 3 batteries so that’s why there are 4 here. In real life 4 batteries would however result in 5,33~6 Volts depending on the batteries you choose resulting in more power from the motors (and more current through the transistors).

Early XBee tests

And so I received some tools to play around with: 3 XBee modules + breakout board, 2 breadboards and 2 Arduino Uno micro-controller boards. I didn’t get enough electrical wires yet to put all at good use, but as far now I’m only trying some basic configuration commands with only one XBee module. You can see the setup below: 3,3V and GND supply voltages are taken from the Arduino board while Arduino’s pin 0 (RX) is connected to XBee’s RX pin and Arduino’s pin 1 (TX) is connected to XBee’s TX pin. This way we can use the Arduino board as a USB to RS232 converter (straight connection), if you would use Arduino in the normal way you would have to make cross connections.

picture003

To talk to the XBee module I first tried Putty and Digi’s X-CTU software, afterwards I wrote my own Java software to send commands and receive data through a console application. So far everything seems to be going great, let’s hope we can keep on going like this.