I plan on using a Raspberry Pi 3 or Raspberry Pi Zero v1.3 (with camera connector) as the base machine. However, there are a number of 3rd party cameras available. As is often the case, I was not able to find a comparison of the options available online, so today I am going to do a quick and dirty look at the following cameras:

In this post, I provide some demonstration photos for outdoor, indoor, and low-light scenarios for the modules.

The basic testing rig uses a Raspberry Pi 3 as the processor. I mounted the cameras onto a piece of cardboard so that they would have roughly the same origin and orientation. Images were captured through an SSH connection to my laptop and transferred via scp. Finally, I strapped on a portable battery (AUKEY 12000mAh powerbank) and the entire setup was portable. Since this is a headless machine, I streamed video from the Raspberry Pi to my laptop with the UV4L package to make sure that the image was sharp, especially for the Waveshare cameras, which required some focusing. Here’s a photo of the “test setup”:

Each module has different specifications and features, so it’s worthwhile to weigh the pros and cons when choosing one for your application. All of the modules are effectively plug-and-play with the CSI connector; however, the Waveshare RPi Camera IR-CUT also has a neat feature where the LED signal toggles a mechanical IR filter. This means that with some creative coding, you can use it as a day and night camera (it even includes high power IR LEDs, which I did not include in the comparison shots). However, the image quality is a bit worse and the IR filter is not terribly effective (meaning colors are washed-out in daytime shots).

All photos were taken with:

raspistill -o photo.jpg --vflip --hflip

Here are all of photos in a mosaic for quick comparison:

Image quality for the Raspberry Pi Camera and the Arducam 5MP RPi Camera were practically identical, which would be expected since they share the same sensor and lens setup. The Waveshare RPi Camera IR-CUT was disappointing and even after dialing in the focus there were still regions that were blurry when the IR filter was enabled. I really liked the field-of-view for the Waveshare RPi Camera (I) and Waveshare RPi Camera (J) and the image was quite sharp once the focus was adjusted. These would be ideal cameras for a home security solution. The Raspberry Pi v2 Camera performance was anti-climactic. Its dynamic range appears to be a bit wider, but it would often under-expose photos. This could probably be corrected by adjusting the parameters in raspistill. Bang for buck, the Arducam 5MP RPi Camera is best, but for shear field-of-view, the Waveshare RPi Camera (J) is pretty awesome.

And here are the full-resolution shots in each of the situations:

Outdoor (day)

Raspberry Pi Camera	Arducam 5MP RPi Camera
Waveshare RPi Camera IR-CUT (on)	Waveshare RPi Camera IR-CUT (off)
Waveshare RPi Camera (I)	Waveshare RPi Camera (J)
Raspberry Pi v2 Camera

Outdoor (night)

Raspberry Pi Camera	Arducam 5MP RPi Camera
Waveshare RPi Camera IR-CUT (on)	Waveshare RPi Camera IR-CUT (off)
Waveshare RPi Camera (I)	Waveshare RPi Camera (J)
Raspberry Pi v2 Camera

Indoor (day)

Raspberry Pi Camera	Arducam 5MP RPi Camera
Waveshare RPi Camera IR-CUT (on)	Waveshare RPi Camera IR-CUT (off)
Waveshare RPi Camera (I)	Waveshare RPi Camera (J)
Raspberry Pi v2 Camera

Indoor (night)

Raspberry Pi Camera	Arducam 5MP RPi Camera
Waveshare RPi Camera IR-CUT (on)	Waveshare RPi Camera IR-CUT (off)
Waveshare RPi Camera (I)	Waveshare RPi Camera (J)
Raspberry Pi v2 Camera

Apple charges $199 (+ tax) to replace a 13-inch/15-inch MacBook Pro with Retina display battery. However there are a number of 3rd party batteries available on Amazon that cost ~$50–$80 with Prime shipping, meaning that I could save $125+ by doing the repair myself. After a very successful SSD transplant, I decided to try out iFixit’s MacBook Pro 13″ Retina Display Late 2012 Battery Replacement guide.

My old batteries are from September 2012 and have gotten some good use out of them, so it’s about time for retirement:

There are a number of batteries available, but all appear to be from no-name 3rd parties:

• LQM New Laptop Battery for Apple MacBook Pro Retina 13″ A1437 A1425,Compatible 020-7652-A MD101 MD101LL/A MD101ZP/A MD102 MD102LL/A MD102ZP/A MD212 MD213 ME662 with Four Free Screwdrivers – $79.99
• Lizone New Laptop Battery for Apple MacBook Pro 13 inch Retina Mid 2012 A1425 MD212 MD213 MD212LL/A MD213CH/A / Apple A1437 Laptop Notebook battery / Li-Polymer 11.21V 74Wh – $69.99
• SIKER11.21V 74WH High Performance Battery for Apple Macbook Pro Retina 13″ A1437 A1425 020-7652-A , fits MD101, MD101LL/A, MD101ZP/A, MD102, MD102LL/A, MD102ZP/A, MD212, MD213, ME662 – $69.99
• Egoway MacBook Pro Retina 13″ Battery for Apple A1437 A1425 (Late 2012, Early 2013 Version) – [Li-Polymer 11.21V 74Wh] – $59.99
• BRTONG® High Performance New Laptop Battery for Apple MacBook Pro Retina 13″ A1437 A1425 020-7652-A 020-7653-A MD212CH/A MD212 MD213 MD212LL/A MD213CH/A [Li-ion 11.21V 74Wh/6600mAh] – 18 Months Warranty – $49.99

Many of the links have the same product photos, so I suspect there are a number of “companies” reselling the same batteries. I ended up purchasing the BRTONG battery for $49.99 with a credit card that offers an additional 1 year extended warranty, so if I have any issues in 30 months (2.5 years), I should be covered for repair/replacement. My one complaint is that the battery I received has a manufacture date from 2013(!). Hopefully there are no issues, but I’ll keep an eye on it.

There are also some oddities with the controller (note the white epoxy and the replacement information sticker), so I am suspecting that the battery may be remanufactured:

One more weird aspect is that the batteries were very difficult to remove from the protective backing, leaving quite a bit of remnants on the protective sheet:

Following the iFixit guide, I disassembled the laptop, carefully removed the old battery, and installed the new one.

And it worked! The hardest part of the procedure was removing the old batteries and the old adhesive from the Macbook’s case. However, it took about 30 minutes to complete, so I would highly recommend this fix for anyone having battery issues with their older Macbook Pro Retina.

Here’s my battery stats from the Apple System Information, with the old battery on the left and the new battery on the right (interesting info highlighted in yellow):

Click through the break for information on the setup and source code to get the Arduino Fio onto the web.

The project uses an Arduino Fio as the microcontroller, a Microchip RN171XV wifi module to connect to the internet (hereafter described using the old part name, RN-XV), and a Mini12864 graphical LCD to show debug information. Here’s a part list for this project (assuming you already have a USB -> Micro USB cable):

• Arduino Fio (available on Amazon & Sparkfun)
• Mini12864 graphical LCD (available on Amazon & DX)
• Microchip RN171XV/Roving Networks RN-XV (available on Amazon & Sparkfun)
• XBee USB adapter – for programming RN-XV (available on Amazon, DX, & SparkFun)
• FTDI 3.3V USB cable – for programming Fio (available on Amazon, DX, & SparkFun)

Want to make it completely wireless? I also used a Lithium Ion Polymer battery (available at Sparkfun).

When you first get the RN-XV, it needs to be updated to the latest firmware. First, it needs to be plugged into the XBee USB adapter and connected to your computer. These days, I’m working on a Mac, so I use CoolTerm to communicate with the RN-XV. Here are the settings (basically 9600 baud serial communication):

Then the RN-XV needs to be connected to your wireless access point and updated. Type in $$$ to enter the command mode and you should see the RN-XV respond CMD. You can then enter the commands one by one (carriage returns after each line) to connect the RN-XV to your WiFi access point. Here is my basic setup (see the RN-XV datasheet for additional information):

[code lang=”text”]
factory RESET
reboot
set wlan auth 4
set wlan ssid XXXX
set wlan phrase XXXX
set wlan join 1
save
reboot
[/code]

The RN-XV should associate (connect) with your wifi network and then you can test the connectivity by pinging the Microchip FTP server:

[code lang=”text”]
ping 198.175.253.161 10
[/code]

Then, update the RN-XV to the latest firmware (4.00.1 as of this article’s publish date):

[code lang=”text”]
set ftp address 198.175.253.161
set ftp user roving
set ftp pass Pass123
save
ftp update
[/code]

Once the update downloads, you can reset the factory defaults and reboot:

[code lang=”text”]
factory RESET
reboot
[/code]

After the RN-XV resets, you should again enter the basic setup information to get the RN-XV connected to your WiFi access point (see above). If all works out, then you can disconnect the serial port and pull the RN-XV out of the XBee adapter for the time being (don’t put it into the Arduino Fio, because the Fio needs to be programmed and the TX/RX lines are shared on the board).

I found a wonderful Arduino library for the RN-XV called WiFlyHQ by harlequin-tech. The author includes a number of great examples, including a HTTP client, HTTP server, TCP client, UDP client, and web socket client. Using the basic setup code in the HTTP client example, I added code from my previous Arduino FIO Graphical LCD Console to make a simple “clock” that updates approximately every 3 seconds using the time-c.nist.gov time server. I used the console code because it allows for very simple debug printing (since the Fio’s serial TX/RX pins are shared with the XBee socket). Here an admittedly boring short video illustrating the “clock” being startup and allowed to run (the value on the far left is an indicator of the wireless signal strength, RSSI):

And finally, here’s the Arduino sketch:

More information on the project, a video of it in operation, and its code after the break.

A little while ago, I picked up an Arduino Fio (available on Amazon.com) and the mini12864 graphical LCD (available on dx.com & Amazon.com) for some microcontroller tinkering. It turned out that a great graphical LCD library was available — u8glib — that supports the mini12864’s controller (the UC1701).

Using u8glib, the Arduino and the GLCD communicate flawlessly. Thankfully, the mini12864 is 3.3V compatible, so there are no issues setting it up with the Arduino Fio and the simple SPI connection makes setup surprisingly easy. As mentioned, I was able to use u8glib to port my oscilloscope code from CCS C to the Arduino:

• Arduino FIO LCD Oscilloscope
• Arduino FIO 2 Channel LCD Oscilloscope

In addition to all of the functions u8glib provides, the library also comes with a nice little serial console/terminal demonstration program. The current u8glib console code can be found here.

I added four functions that would allow me to quickly and easily debug my applications u8g_print, u8g_println, u8g_print_P, and u8g_println_P. u8g_print allows one to print a character array, u8g_println does the same, but then adds a new line to the end of the string, u8g_print_P allows you to print a character array saved in program memory, and u8g_println_P does the same but adds a new line. Here are the new functions:

This allowed me to create this simple demo of the GLCD debug console code:

And last but not least, here is the Arduino Sketch used to produce the above output:

Here’s a short demonstration video of the new two channel project:

Click through the break to check out the code.

The project used an Arduino Fio (available on Amazon.com) and the mini12864 128×64 pixel graphical LCD (available on dx.com & Amazon.com).

The basic modification was to include a second set of variables that is used to store the second channel’s readings. A more elegant solution would have been to make each variable an N-channel array (so that one could easily scale to more channels), but the low-resolution monochrome display really limits the possibilities, unfortunately. In addition, the sampling rate for the single channel oscilloscope was already quite low (with a maximum sampling rate of approximately 28kHz), but two channels could allow for some interesting possibilities as long as one can deal with the slower acquisition speed.

The display refresh is triggered by a rising signal (useThreshold == 1) on the channel A input (analog pin 7, as defined by theAnalogPinA = 7), but you could easily modify the code to make this switchable so that either channel acts as the trigger. The code is very similar to my previous code, including the serial port parameter controls, so I recommend taking a look at that post first, if you have any questions: Arduino FIO LCD Oscilloscope

As with the previous single channel project, you need to make sure that you have the u8glib library installed to compile the code.

Here’s the Arduino sketch for the oscilloscope:

Here’s a short teaser video just to show that, yes, it works (going through a couple different sine wave frequencies, some random noise, etc. just to illustrate it working):

Click through the break to get more information on the setup.

I used an Arduino Fio board that I picked up from SparkFun.com (available at Amazon.com) and a small SPI graphical LCD board that I picked up for a few bucks at dx.com (SKU 153821, also apparently available at Amazon.com). Since I don’t have a soldering iron here, I had to improvise with some female to female cables, also purchased from dx.com (SKU 151650).

Dx.com describes the LCD as a 5V module, but the GLCD board designer’s page (mini12864) states otherwise (translated from Chinese via Google Translate):

Dimensions (L × W × H): 47mm × 38mm × 6mm (excluding pins)
LCD sight (L × W): 33.7mm × 33.5mm
LCD Active Display Area (L × W): 30.7mm × 23mm
Backlight: White LED backlight bracket
Operating voltage: 3.3V ~ 5.5V (built-in booster circuit, without pressure)
Control IC: UC1701
Display format: 128 × 64 rows
Display: Blue on White

(mini12864 datasheet)

So, I ordered one of the graphical LCDs, waited a few weeks for delivery (because dx.com is a notoriously slow shipper), received it, hooked it up, and tried out the following simple “Hello World” script to confirm that that the GLCD/FIO combo functioned:

And it worked!

Thankfully, the code I previously posted was written in C, so porting to the Arduino took only a few minutes. I took advantage of a great open source graphical LCD library (u8glib) to handle the brunt of the work and added a serial port menu for manipulating the various display parameters. One important difference between this project and the previous one: Since the Arduino Fio is a 3.3V device, it can only handle 0-3.3V inputs, limiting its utility as an “oscilloscope” without proper input protection/voltage scaling. However, the code is extremely portable, meaning that you should be able to program any other Arduino and have it up-and-running in no time.

Here’s another 2 videos of the oscilloscope in action:

And finally, here’s the Arduino sketch for the oscilloscope:

Here’s the Arduino sketch for the square wave generator shown in the second video:

These temperature sensors are much more accurate out-of-the-box, so I don’t need to deal with calibration (which I did need to worry about with the internal thermometer). In addition, using separate, discrete components allows for the possibility of putting temperature sensors directly on/in whatever you may want to measure (rather than merely measuring the ambient temperature) and the potential for multiple temperature sensors with a single Arduino Fio (which are available at Amazon.com).

So, the most important addition is the Arduino OneWire.h library. Once we have that, all that’s needed is two simple declarations:

[code lang=”arduino”]
#include <OneWire.h> // Get here: http://www.arduino.cc/playground/Learning/OneWire
OneWire ds(DS18B20Data);
[/code]

And a modified readTemp function:

[code lang=”arduino”]
// See: http://www.arduino.cc/playground/Learning/OneWire
float readTempDS18B20() {
int HighByte, LowByte, TReading, SignBit, Tc_100;
byte i;
byte present = 0;
byte data[12];
byte addr[8];
float resultTempFloat;

digitalWrite(DS18B20Power,HIGH); // Power up the DS18B20
delay(250);

ds.search(addr);
if ( OneWire::crc8( addr, 7) != addr[7]) {
return 0.0; // CRC is not valid!
}

ds.reset();
ds.select(addr);
ds.write(0x44,1); // Start conversion, with parasite power on at the end

delay(1000); // Maybe 750ms is enough, maybe not
// We might do a ds.depower() here,
// but the reset will take care of it.

present = ds.reset();
ds.select(addr);
ds.write(0xBE); // Read Scratchpad

for ( i = 0; i < 9; i++) { // we need 9 bytes
data[i] = ds.read();
}
LowByte = data[0];
HighByte = data[1];
TReading = (HighByte << 8) + LowByte;
SignBit = TReading & 0x8000; // Test most sig bit
if (SignBit) // Negative
{
TReading = (TReading ^ 0xffff) + 1; // Take 2’s comp
}

ds.reset_search();
digitalWrite(DS18B20Power,LOW); // Turn off DS18B20

resultTempFloat = (float) (6 * TReading) + TReading / 4; // Multiply by (100 * 0.0625) or 6.25
resultTempFloat = resultTempFloat/100;
resultTempFloat = resultTempFloat * 1.8 + 32.0; // Convert to F
return resultTempFloat;
}
[/code]

And we are ready to read! Note that the measurement times are a bit longer (I measured ~75 seconds in between transmissions) because of the 1 second settling time for the DS18B20. Here is some example output from TeraTerm (I measured the ambient temperature for measurements 1-10, then put my thumb onto the DS18B20 for measurements 11 & 12, and then allowed the DS18B20 to return to ambient for readings 13-20):

[code gutter=”false”]
ƒƒª 0 0 0
~
Aª 1 3.303 71.70
~
Aª 2 3.303 71.14
~
@ª 3 3.303 71.22
~
@ª 4 3.303 71.07
~
?ª 5 3.303 71.30
~
@ª 6 3.303 70.95
~
@ª 7 3.303 71.26
~
?ª 8 3.303 71.60
~
?ª 9 3.303 71.35
~
0ª 10 3.303 71.01
~
7ª 11 3.303 77.35
~
6ª 12 3.303 77.35
~
Aª 13 3.303 73.72
~
Aª 14 3.303 72.14
~
Aª 15 3.303 71.66
~
Aª 16 3.303 71.49
~
Aª 17 3.303 71.27
~
Aª 18 3.303 71.40
~
Aª 19 3.303 71.23
~
Aª 20 3.303 70.91
[/code]

I stored the data for another 40 readings, cut out all of the trash data between the carriage returns (deliminating the readings) and sync characters (which visually show up as “ª” in TeraTerm), removed the initial sync reading, and plotted the temperature data in Mathematica (voltage was constant):

Compare to the temperature results of the Arduino Fio internal temperature sensor:

Here’s all of the Arduino Fio SuperSleepyDS18B20 code:

[code lang=”arduino”]
/*
* SuperSleepyDS18B20 SuperSleepyDS18B20.ino
* Steven A Cholewiak – www.semifluid.com
*
* This sketch takes advantage of the XBee’s hibernation mode as
* well as the Ardunio Fio’s Power Save Mode to grossly reduce power
* consumption. It impliments a temperature logging IC (DS18B20)
* That has been connected to D3,D4,D5. Provides a much more
* accurate temperature measurement than the internal thermometer
* (see SuperSleepyTempAndVolts.ino).
*
*/

#include <avr/wdt.h>
#include <avr/sleep.h>
#include <avr/interrupt.h>
#include <OneWire.h> // Get here: http://www.arduino.cc/playground/Learning/OneWire

const int ledPin = 13;
const int DS18B20Ground = 3; // DS18B20 Pin 1
const int DS18B20Data = 4; // DS18B20 Pin 2 NOTE: 4.7k pull-up resistor required between data and power
const int DS18B20Power = 5; // DS18B20 Pin 3
const int XBeeSleep = 2; // Connect to XBee DTR
const int waitPeriod = 8; // Number of 8 second cycles before waking
// up XBee and sending data (8*8 = 64 seconds)

OneWire ds(DS18B20Data); // Setup DS18S20 Temperature chip I/O

// See: http://code.google.com/p/tinkerit/wiki/SecretVoltmeter
float readVcc() {
signed long resultVcc;
float resultVccFloat;
// Read 1.1V reference against AVcc
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
delay(10); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // Convert
while (bit_is_set(ADCSRA,ADSC));
resultVcc = ADCL;
resultVcc |= ADCH<<8;
resultVcc = 1126400L / resultVcc; // Back-calculate AVcc in mV
resultVccFloat = (float) resultVcc / 1000.0; // Convert to Float
return resultVccFloat;
}

// See: http://www.arduino.cc/playground/Learning/OneWire
float readTempDS18B20() {
int HighByte, LowByte, TReading, SignBit, Tc_100;
byte i;
byte present = 0;
byte data[12];
byte addr[8];
float resultTempFloat;

digitalWrite(DS18B20Power,HIGH); // Power up the DS18B20
delay(250);

ds.search(addr);
if ( OneWire::crc8( addr, 7) != addr[7]) {
return 0.0; // CRC is not valid!
}

ds.reset();
ds.select(addr);
ds.write(0x44,1); // Start conversion, with parasite power on at the end

delay(1000); // Maybe 750ms is enough, maybe not
// We might do a ds.depower() here,
// but the reset will take care of it.

present = ds.reset();
ds.select(addr);
ds.write(0xBE); // Read Scratchpad

for ( i = 0; i < 9; i++) { // we need 9 bytes
data[i] = ds.read();
}
LowByte = data[0];
HighByte = data[1];
TReading = (HighByte << 8) + LowByte;
SignBit = TReading & 0x8000; // Test most sig bit
if (SignBit) // Negative
{
TReading = (TReading ^ 0xffff) + 1; // Take 2’s comp
}

ds.reset_search();
digitalWrite(DS18B20Power,LOW); // Turn off DS18B20

resultTempFloat = (float) (6 * TReading) + TReading / 4; // Multiply by (100 * 0.0625) or 6.25
resultTempFloat = resultTempFloat/100;
resultTempFloat = resultTempFloat * 1.8 + 32.0; // Convert to F
return resultTempFloat;
}

void sleepNow()
{
/* Now is the time to set the sleep mode. In the Atmega8 datasheet
* http://www.atmel.com/dyn/resources/prod_documents/doc2486.pdf on page 35
* there is a list of sleep modes which explains which clocks and
* wake up sources are available in which sleep modus.
*
* In the avr/sleep.h file, the call names of these sleep modus are to be found:
*
* The 5 different modes are:
* SLEEP_MODE_IDLE -the least power savings
* SLEEP_MODE_ADC
* SLEEP_MODE_PWR_SAVE
* SLEEP_MODE_STANDBY
* SLEEP_MODE_PWR_DOWN -the most power savings
*
* the power reduction management <avr/power.h> is described in
* http://www.nongnu.org/avr-libc/user-manual/group__avr__power.html
*/

set_sleep_mode(SLEEP_MODE_PWR_SAVE); // Sleep mode is set here

sleep_enable(); // Enables the sleep bit in the mcucr register
// so sleep is possible. just a safety pin
sleep_mode(); // Here the device is actually put to sleep!!
// THE PROGRAM CONTINUES FROM HERE AFTER WAKING UP
sleep_disable(); // Dirst thing after waking from sleep:
// disable sleep…
}

ISR (WDT_vect) { // WDT Wakeup
cli();
wdt_disable();
sei();
}

// Variable Definition
volatile int MeasurementID = 1;
volatile int timeKeeper = 0;
volatile float averageVcc = 0.0;
volatile float averageTemp = 0.0;

void setup(void) {
Serial.begin(57600);
pinMode(DS18B20Ground, OUTPUT);
digitalWrite(DS18B20Ground, 0); // Ground the DS18B20 GND pin
pinMode(XBeeSleep, OUTPUT);

digitalWrite(XBeeSleep, 0); // Enable XBee
digitalWrite(ledPin, 1); // Turn on Notification LED
delay(4000); // 4 second LED blink, good for wireless programming
digitalWrite(ledPin, 0); // Turn off Notification LED

Serial.write( 170 ); // Sync Byte
Serial.print( ‘\t’ ); // Tab
Serial.print( ‘0’ ); // Reading # (0)
Serial.print( ‘\t’ ); // Tab
Serial.print( ‘0’ ); // Voltage (unmeasured, so 0)
Serial.print( ‘\t’ ); // Tab
Serial.println( ‘0’ ); // Temperature (unmeasured, so 0)

digitalWrite(XBeeSleep, 1); // Disable XBee
}

void loop(void) {
averageVcc = averageVcc + (float) readVcc();
averageTemp = averageTemp + (float) readTempDS18B20();

if (timeKeeper == (waitPeriod-1)) { // Transmit every 8*8 (64) seconds
digitalWrite(XBeeSleep, 0); // Enable XBee
delay(50); // Wait for XBee Wakeup

Serial.write( 170 );               // Sync Byte
Serial.print( '\t' );
Serial.print( MeasurementID, DEC );
Serial.print( '\t' );
Serial.print( (float) (averageVcc/waitPeriod) , 3);
Serial.print( '\t' );
Serial.println( (float) (averageTemp/waitPeriod) , 2);
MeasurementID++;

digitalWrite(ledPin, 1);           // Turn on Notification LED
delay(50);                         // Blink LED
digitalWrite(ledPin, 0);           // Turn off Notification LED

digitalWrite(XBeeSleep, 1);        // Disable XBee

averageVcc = 0;                    // Reset voltage for new measurements
averageTemp = 0;                   // Reset temperature for new measurements
timeKeeper = 0;

} else { // Add a reading to the average
digitalWrite(ledPin, 1); // Turn on Notification LED
delay(1); // Blink LED very quickly
digitalWrite(ledPin, 0); // Turn off Notification LED

timeKeeper++;

}

wdt_reset(); // Get ready to go to sleep…
watchdogEnable(); // Turn on the watchdog timer
sleepNow(); // Go to sleep, watchdog timer will wake later
}

void watchdogEnable() { // Turn on watchdog timer; interrupt mode every 8.0s
cli();
MCUSR = 0;
WDTCSR |= B00011000;
//WDTCSR = B01000111; // 2 Second Timeout
//WDTCSR = B01100000; // 4 Second Timeout
WDTCSR = B01100001; // 8 Second Timeout
sei();
}
[/code]

So, taking advantage of the available hardware and the code available, I went about creating a wireless temperature logger using an Arduino Fio (available from Amazon.com) and two XBees (one for the Fio and one for the coordinator).

I already have code for a very low power logger setup that takes advantage of the Arduino Fio’s sleep mode as well as the XBee’s hibernation mode (see here).  So, all I needed to do was to add the thermometer and voltmeter code that tinkerit documented.

Here is their internal thermometer example code:

I modified the readTemp() function so that it returned a “human-readable” float in Fahrenheit (my local method of measuring temperature). In addition, I added a small calculation to return a more accurate temperature (calibrated against a thermometer at my house). If you want to calibrate the internal thermometer, put the Arduino Fio into a glass of ice water (I recommend putting it into a plastic bag and vacuuming out as much air as possible!), measure the values it returns, then put it into a cup of hot water, of known temperature, and measure the values it returns. It would be best to have multiple measurements along a series of temperatures, confirmed with a pre-calibrated thermometer (i.e., mercury thermometer). After making the measurements, you can fit a linear model (i.e., best fit line) to the data to get the slope and y-intercept for your device.

I also added their internal voltmeter example code:

The only modification was to convert the decimal to a float for (again) human readable format:

And last, but not least, I’ve been finding “trash data” that can be transmitted when the XBee is woken from hibernation, so I added a sync byte (DEC 170), that allows for easier parsing of the data. Here is some example output from TeraTerm (I measured the ambient temperature for measurements 1-10, then put my thumb onto the ATmega328P for measurements 11 & 12, and then allowed the Arduino to return to ambient for readings 13-20):

[code gutter=”false”]
ª 0 0 0
~
?ª 1 3.303 69.83
~
?ª 2 3.303 69.62
~
?ª 3 3.303 69.62
~
@ª 4 3.303 69.41
~
?ª 5 3.303 69.41
~
?ª 6 3.303 69.83
~
?ª 7 3.303 69.41
~
?ª 8 3.303 68.78
~
?ª 9 3.303 69.20
~
#ª 10 3.303 69.20
~
Ի 11 3.303 72.35
~
(ª 12 3.303 72.77
~
#ª 13 3.303 72.14
~
>ª 14 3.303 72.35
~
?ª 15 3.303 70.88
~
>ª 16 3.303 70.25
~
>ª 17 3.303 69.62
~
>ª 18 3.303 69.41
~
>ª 19 3.303 69.41
~
>ª 20 3.303 68.36
[/code]

Yes, I have poor circulation in my hands (hence only a 3 degree jump). I stored the data for another 30 readings, cut out all of the trash data between the carriage returns (deliminating the readings) and sync characters (which visually show up as “ª” in TeraTerm), removed the initial sync reading, and plotted the temperature data in Mathematica (voltage was constant for the ~50 minutes while I wrote this post):

Nice!

Here’s all of the Arduino Fio SuperSleepyTempAndVolts code: