Wireless temperature picture frame mashup
This is the latest geeky addition to our home decor. It’s a Kodak W820 digital picture frame, showing a graph of real-time temperature data collected from around the house: upstairs and downstairs, garage, outdoors, and even inside the refrigerator.
More photos on Flickr, implementation details below…
Temperature Sensors
Most of my friends probably know that back in 2004, when I was still in college, I built a set of wireless temperature sensors. Each one is an Altoids tin containing a 9V battery, a Dallas 1-wire temperature sensor, PIC microcontroller, and a little 315 MHz AM radio transmitter. I built several of these indoor wireless sensors, plus one outdoor sensor which I built out of PVC pipe.
The PIC spends most of its time sleeping, but every 20 seconds or so it wakes up to read the current temperature from the 1-wire sensor. Most of the indoor sensors have the 1-wire temperature probe soldered to the side of the Altoids tin, for the best thermal conductivity. The refrigerator sensor has a length of 30-gauge wire that leads the 1-wire sensor itself into the fridge.
Every couple of minutes, each sensor transmits a burst of packets back to the base station. The base station is another piece of custom hardware: a matching AM radio receiver, some LEDs, and a TUSB3210 microcontroller to do protocol decoding and to interface back to a server machine over USB. In this case, the host machine is a little NSLU2 embedded Linux box which also acts as our home network’s file server.
As usual, microcontroller firmware for the transmitter and receiver is open source.
Software
The software running on the server machine has had a rough history. My original implementation was ridiculously complicated: The receiver unit connected to an NSLU2 embedded Linux box over USB. That machine ran a daemon, written in C, which listened for packets over USB and stored their contents in a remote MySQL database. The MySQL database was running on a more powerful server (a 1 GHz Athlon at the time) which had plenty of disk space. That server also ran a web application using mod_python, which pulled data from MySQL, generated graphs on demand using rrdtool, and generally looked really pretty.
My reasons were mostly historical. I wanted to save all of the temperature data (for another project I had at the time), so instead of sending data directly to a lossy RRD file, I just used rrdtool as a cache for the data I was about to graph. As you can imagine, if the cache ever had to be rebuilt, the server would come crashing to its knees. This implementation was plagued with performance and reliability issues.
So, I recently reimplemented a simpler server software solution. I hacked up the C daemon so that instead of writing to a MySQL database, it forks off an rrdtool process to store the data directly into an RRD database. Instead of generating graphs on-demand, I have a small update-graphs shell script which uses rrdtool to generate all of the graphs. This scripts is run from cron every 5 minutes. The resulting graphs aren’t nearly as intricate as the ones that my mod_python app used to generate, but anything looks pretty if you antialias it 
The digital picture frame
This frame is a Kodak W820, an amazingly featureful little gadget that I picked up at the local Fry’s for $180. It has an very pretty 8″ 800×480 display and a rather unique touch-based user interface. It also does a pretty ridiculously good job at playing video, considering it’s a picture frame.
But anyway, the real reason to buy this frame is for its Wi-fi connectivity. If you connect it to your network, you get a range of useful and “useful” services:
- The frame runs its own HTTP server on port 80, with a web interface you can use for managing settings. You can’t upload pictures via this interface, but it does mean that you can configure the picture frame entirely without using Kodak’s silly Windows software.
- It’s a uPnP media server and a client. The software that comes with it uses uPnP to browse an upload/download files on the frame’s internal memory or memory card, and the frame itself can use uPnP to stream images from your PC. This is a really interesting feature that could be exploited for more dynamic applications…
- It has a Flickr client. Yes, the frame itself actually speaks the Flickr API.
- There’s some fancy-pants Kodak online service, which looks like it’s probably little more than an RSS feed in disguise.
- And best of all, you can give it custom RSS feeds. Like, say, real-time temperature graphs!
The only snag I hit in setting this up was in trying to keep the frame from caching old versions of the temperature graph. It seems to ignore HTTP cache control headers, and the cache seems to be able to hold quite a nontrivial amount of image data!
The best solution I’ve found so far: Use the RSS <ttl> tag to force the frame to reload the RSS feed itself pretty frequently. Then, in my update-graphs script, I dynamically generate an RSS file which includes a timestamp in the URL and GUID for each image. This seems to do the trick.
What next?
I’m really interested in graphing my home power usage, using a receiver circuit based on the one I built for The Kilowatt Clock. I’m currently waiting for some parts from Digi-key, but I’ll definitely blog about this when it’s done.
If you’re at all interested in displaying real-time stats around the home or office, I’d definitely encourage you to play with this picture frame. It has some great hacking potential, and I’m really excited to see what kinds of uses others come up with.
design schmatics ?
Do you have the design schmatics for the transmitter and receiver anywhere ? I did not see them with the code.
Re: design schmatics ?
I don’t think I ever bothered making schematics, because they were so simple. The transmitter wiring is explained in the source code comments, if I remember correctly. Each transmitter is:
– A low-dropout 5V regulator
– A resistor voltage divider, for the battery voltage sensor
– A 0.1uf capacitor (power filtering)
– PIC microcontroller
– Dallas 1-wire temperature sensor
– Off-the-shelf ASK transmitter module (I think I paid about $5 each)
The receiver module is the matching ASK receiver for the transmitters I used, plus a TUSB3210 microcontroller in the form of a modified Keyspan USA-19HS usb-to-serial adapter. It’s literally just a USB to serial dongle with new firmware, and the RX pin attached to the radio receiver. My receiver module has some extra circuitry for the front panel LEDs, but that’s totally optional.
–Micah
Re: design schmatics ?
I am using Virtual Weather Station for my weather software. It generates jpg’s of graphs and gauges. Can I do the same thing with the Kodak Frame ? You said there was a problem with the frame cache’ing files. Anyway to force a refresh from the folder where VWS puts the graphs ? Give me some hints. I would love to do this.
Re: design schmatics ?
The solution turned out to be relatively simple- you’ll need to create an RSS feed that points to all the images you want it to display, then you can use the element to control how often the RSS feed is refreshed. The images themselves still might be cached, so I use a cron job to generate a new RSS feed file every few minutes which has a unique query portion after each image. In other words, my image URLs look like “http://host/file.png?123456″ where 123456 is a random number.
Good luck!
–Micah
This is exactly the kind of project I’ve been thinking about doing for a while. Thanks for the inspiration to get started on it. I think I’m going to start reading some temp sensor datasheets
Actually using it in a similiar fashion with my weather station pics. I found that TVersity works too with it so a I publish a set of pics from the HA server (also using 1-Wire temp sensors) over to the TVersity server. The Kodak frame picks up the pictures from one directory. A bit primitive. Looking to create a non touch screen touchscreen with the Kodak frame.
Very cool project!
Do you have any pictures of the insides of the receiver unit? Did you hook up the extra leds to the TUSB3210 or do you have another microcontroller in there?
What resistors did you use in the voltage divider?
I know they seem very simple to you, but I would *love* to see the schematics for these
Sorry, I don’t have any pictures or schematics for the receiver handy. I didn’t bother making a schematic, since it’s really just a modified USB-to-serial adapter, not something I built from scratch.
I started out with a Keyspan USA-19HS serial adapter. It’s mostly just a TUSB3210 chip, EEPROM, voltage regulator, and serial level-shifter. I used some tweezers to short out the data lines on the EEPROM so I could start it up in bootstrapping mode, then I used that to erase the EEPROM and reprogram it with my own USB descriptors.
The LEDs are connected via an I/O expander chip. I think I used a MAX7300 attached to the TUSB3210′s I2C bus.
There is some more information about the hardware in the comments for the firmware source. For example, the transmitter firmware comments describe the voltage divider: “GP0: Battery voltage sensor (470Kohms to battery+, 470K to ground)”
Hmm, so you left the eeprom on the adapter? Is it necessary or would it work if I’ve already removed the eeprom from the circuit
I would love to see the rrd code for making the
# Name – temp
lines on the graph. How do you do that? I know how to get the
# Name
But I just can’t figure out how to get the temp value there. I have them below with new lines, not that nice. =)
It will definitely work without the EEPROM- the TUSB chip will start up in bootloader mode, with a default USB vendor and product ID, and default USB descriptors.
The only reason I kept the EEPROM was so that I could customize the USB descriptors and set my own vendor and product IDs.
Man, I’d LOVE to have a few of these! I’m not technically advanced enough to build one, with the information I see in the mashup notes.. I could probably build one if I actually had one to ‘copy’. I do have other 1-wire sensors in my house (for a weather station) but they all came put together for me.. I don’t suppose you would consider selling a transmitter and receiver would you? I use Weather-Display for my software, which natively supports 1-wire data via USB or Serial.. would I even need any software other than that if I had the transmitter and receiver built, like those you display?
Hi, perhaps you still can provide a schema of transmitter and reciever. I’m very interested of this project. Can you contact me?
^ What they said..
Could we nag you with some sorta schematics?-)
I got ages old DS18S20 sensors here which I finally thought would be good to be put into use.. I have no problems pulling out cable for some of them, but I’ve been thinkin of putting few elsewhere, where the cable isnt really ideal and there your wireless setup would come handy
Providing schematics would be great
Please help us
M.