sun, 15-may-2011, 11:25

Battery, Arduino, XBee

Several years ago when I started messing around with Arduino and building my own weather station, I bought a few XBee radio chips with the idea of setting up some more remote sites without having to run wires out to the sensor stations. I spend several frustrating hours trying to get the radios to talk to each other, but couldn’t get them to work (I think this was because they were in API mode instead of AT mode). Then I got Building Wireless Sensor Networks and Arduino Cookbook and finally got everything working.

At the same time, the batteries in our UPS at work needed to be replaced, and rather than immediately recycling them, I took a couple home to see if they still had enough juice in them to work in a remote sensing capacity. They’re 12 volt lead-acid batteries (which may make them unsuitable for winter) that were rated for 5 Amp-hours when they were new. That should be plenty of power to drive an Arduino, XBee and a couple sensors. The XBee chips have some data pins on them, so I may be able to eliminate the Arduino from each sensor station, depending on the type of sensor I use.

The current setup, shown in the photo at the top, is designed to see how long a remote station can run on one of the batteries without any sensors and at springtime temperatures (typically between 20°F and 60°F at our house). The Arduino is reading the input voltage and sending it wirelessly to an XBee coordinator plugged into a SparkFun explorer board and connected to my small eeeBox computer.

Here’s the circuit diagram:

The analog input pins on the Arduino board are expecting voltages between 0 and 5 volts, so I’m using three resistors as a voltage divider to reduce the input voltage (nominally 12 volts, but potentially as high as 15V) to a range safe for the board. The sketch looks like this (almost identical to the sketch in the Arduino Cookbook except that the formula for resistorFactor is incorrect in the book):

```const float referenceVolts = 5;

const float R1 = 2000; // A0 to V+
const float R2 = 1000; // A0 to GND

const float resistorFactor = 1023.0 * (R2/(R1 + R2));

const int batteryPin = 0; // A0

void setup() {
Serial.begin(9600); // to XBee
}

void loop() {
float volts =
(val / resistorFactor) * referenceVolts * 10;
Serial.println(volts);
delay(1000);
}
```

Because the Arduino transmit pin (D1) is connected to the XBee receive pin (DIN) and the Arduino receive (D0) is connected to the XBee send (DOUT), anything the Arduino sends to the serial port is redirected to the XBee, which immediately transmits it wirelessly to the XBee receiver chip in the house.

At the moment, I’m only able to have the sender and receiver about 50 feet from each other before losing the signal, but I think that a pair of boards with whip antennas will work better than the chip antennas I’m currently using. I also set up my network such that the XBee Pro board (which has a supposed range of a mile) is the coordinator receiving messages, but I think it will work better as the sender. When the battery experiment is over, I’ll reverse the position of the XBee boards and see if I get better performance. I’d like to have a station out at the red cabin and potentially somewhere on the hillside, and for that to work the radios will need to be able to communicate over several hundred feet.

The circuit diagram was generated using circuit macros, which take circuit diagrams written in the m4 language and turn them into PIC files which are converted into LaTeX code using dpic. That sounds complicated (and it sort of is), but I much prefer describing the circuits in a text file than to trying to draw them using XCircuits or some other graphical tool. If you’re curious, you can download the code and a Makefile for generating the images.

Here’s what the data looks like so far:

So far all I can see is a diurnal pattern associated with temperature: it was about 56°F at 6:30 PM last night when the data started, dropped to a minimum of 27°F at around 5:30 AM, and it’s been rising since, hitting 50°F at the end of the period shown on the plot.

fri, 06-may-2011, 09:07

Caslon playing

This year Andrea got invited to speak at the Kachemak Bay Shorebird Festival. It would have been the sixth or seventh time we’ve been to the Festival, and it’s always a great time and a nice vacation for both of us. Because of all the dogs and cats, it’s hard for us to travel together, so most of our vacations are solo affairs while the other person takes care of the animals.

Unfortunately, as we were packing to leave, we discovered that our cat Caslon was sick with some form of feline lower urinary tract disease. That’s another way to say “a cat that can’t pee.” He got antibiotic and anti-inflammatory shots in the hopes that it’s an infection causing a bladder inflammation. We also need to keep him isolated so we can monitor what’s happening, and give him twice daily 100 ml subcutaneous fluid injections to hopefully keep things moving. As you can imagine, this isn’t the way I’d imagined spending the next four days.

The good news is I already took the time off from work, so it’ll give me a chance to catch up on some projects. The arctic entryway needs trim above the tile and around the windows and doors, and I’d like to build a more permanent setup for my standing desk at work.

And Andrea will have fun in Homer. We keep our database of animal observations on line, so I can track what she sees by looking at the 2011 Homer observations page.

wed, 04-may-2011, 15:37

Temporary standing desk

Last Thursday afternoon, I set up a laptop on the side of my desk, at a height reasonably comfortable for working while standing (see the photo on the right). Over the past couple years I’ve seen several articles on the Internet advocating standind desks as a way to keep a person awake and alert throughout the day. Two weeks ago there was a story in the New York Times Magazine entitled Is Sitting a Lethal Activity?, and the Internets (and NPR on Monday) have been all over the story. The punchline from the Times Magazine story:

Sitting, it would seem, is an independent pathology. Being sedentary for nine hours a day at the office is bad for your health whether you go home and watch television afterward or hit the gym. It is bad whether you are morbidly obese or marathon-runner thin. “Excessive sitting,” Dr. Levine says, “is a lethal activity.”

Last Friday was my first full day at my temporary standing desk. I worked from 6:30 until around 12:30 primarily standing (I’d say around 80 - 90% of the time), and after that I started sitting around half the time because my feet and lower back started to hurt.

Day number two was similar to the first day: after about six hours on my feet, my heels and lower back started hurting. I continued standing until I’d been on my feet for a full eight hours and then spent an hour or so sitting. My neck, shoulders, and right wrist were a little tired at the end of the day, but I think all of this has more to do with using a laptop than standing. The screen is at arm level, so I’m looking down on it all day, and because it’s smaller than my normal monitor, I think there is a bit more hunching to get close. I don’t have my usual trackball either, which probably contributes to the wrist discomfort.

Temporary standing desk, v0.2

The third day (Tuesday) was rough. I stood the entire day, and migrated off the laptop setup to using my regular computer (v0.2). I also rode my bicycle to work, so my legs were already tired. I made it through the first four hours without any issues, but my back started hurting about then, and by the end of the day the heels of my feet were really killing me. Part of the issue may be that I was in my slippers, and standing on the anti-static mat rather than the carpet because of the new setup. Hopefully shoes with some padding, and possibly an anti-fatigue mat will lessen the pain on my feet.

On day four I wore running shoes and removed the anti-static mat so I was standing directly on the carpet (over concrete). Both of these things helped, but again, between four and six hours into the day, my lower back started to hurt, as did the heels of my feet. But it really didn’t seem as bad as Tuesday, so I may be getting used to it. The new setup with the monitor at an appropriate height, plus a real keyboard and trackball also helps.

Thursday I woke up with a stiff neck and rode my bike to work, so I expected that standing all day would be pretty brutal, but it really is getting easier. The heels of my feet are still a little tired for the last couple hours of work, and my lower back hasn’t quite gotten used to the additional load, but it’s not affecting my concentration like it was in the beginning and I’m starting to be pretty comfortable working at the computer in this position.

Update: It’s now been a couple weeks since I started this experiment. The heels of my feet still hurt a little after a full day of work, and I occasionally experience some lower back pain during the day, but I can feel the benefits already. I’m less tired outside of work, I feel like I’m more productive at work because I am always moving around, and I don’t doubt that the setup will provide long term health benefits over sitting at work and at home for most of my waking hours. The other thing I’ve noticed is that my posture is much better in a standing position and that’s helping to relieve some of the neck stiffness I’d been living with for the past several years. It seems much easier to keep good posture while standing, than having to think about sitting up while in a chair.

All that’s really left to do is make the setup more permanent by building something to set things at the right height and getting an anti-fatigue mat for the floor in front of my keyboard.

sun, 01-may-2011, 09:01

I recently purchased Building Wireless Sensor Networks in electronic form. O’Reilly offered it for download in several electronic formats, including ePub (for my iPhone) and PDF formats. After looking at the content, I decided I wanted to print out the first couple chapters to make it easier to work with the devices without having to continually fiddle around with my phone.

I used the following commands. psresize enlarges each page, in this case by 20%, and pstops is used to move the right-side page to the left by an inch. For the cover page, and other full-bleed content, this will cause the right-side page to overlap the left, but because of the margins around the text block throughout the majority of the book, this overlap doesn’t matter and it allows us to make the text bigger when it’s printed two pages per side.

```\$ pdftops Building_Wireless_Sensor_Networks.pdf
\$ cat Building_Wireless_Sensor_Networks.ps           \
| psresize -W8.5in -H11in -w10.20in -h13.20in  \
| pstops "2:0(0,0),1(-72,0)"                   \
| psnup -2 > wireless_networks_nup.ps
\$ ps2pdf wireless_networks_nup.ps
```

To print, choose double-sided, flip on short edge.

fri, 22-apr-2011, 07:06

I’m trying out a standing desk at work and I discovered that when I went to my blog (and our internal wiki) that for some reason, Chrome on the laptop I’m using wasn’t displaying monospace fonts the way I expected. In Chrome’s preferences I could set the font size for all the other fonts, but it only let me choose the monospace font, not it’s default size. I’d never noticed this before.

A quick Internet search revealed this very helpful page: http://meyerweb.com/eric/thoughts/2010/02/12/fixed-monospace-sizing/

It turns out that monospace sizing is a common problem, and even worse, how they’re sized is browser dependent. The hack is to define the tt, pre, and code elements in your CSS as follows:

 ```1 2 3 4``` ```pre, tt, code { font-family: monospace, sans-serif; font-size: 1em; } ```

It seems wrong to have monospace and then sans-serif, but including sans-serif (or any other font-family category besides monospace) causes browsers to respect the following font-size declaration. Without it, the browser assumes that the 1em sizing is relative to the default monospace font size (which is too large and unchangable) rather than relative to the size of the rest of the content on the page.

Anyway, it works. For now.

Update: Actually, it doesn't work. Firefox, Safari and Chrome on a Mac let you choose the monospace font size, and tweak it until it matches the body text size. When this hack is applied, the monospace fonts become the same size as the body font, which is typically too large.

Meta Photolog Archives