Wednesday, October 12, 2011

Solar Powered Wireless Radiation Monitor


Like the Geiger Kit in the previous post, this project is going to get too big to properly handle in a blog format.


So it's introduced here, but the function and build details are posted on this website.


Listening to what people want in the way of radiation detection, it appeared that there are 3 types of needs:
1.       a portable device that gives instant readings - the classic Geiger Counter
2.       a portable device that logs readings, and maybe location
3.       a stationary monitoring device that is always displaying, and logging readings

I think I’ve covered the first two with the Geiger Kit and the Geiger Logging Shield. So this project is intended to cover the 3rd need - a stationary monitoring device.

The idea is simple – a box outside with a Geiger counter and radio transceiver (solar powered as an option) talking wirelessly to a box inside with a display and an SD card.

the outside piece . . .

the outside piece outside . . .


the inside piece . . .

Again, you can find all the details on this website. However, I'd appreciate any comments you'd like to leave here.

Wednesday, March 23, 2011

Geiger Counter Kit - Part 3


Please visit this web site if you want to purchase or learn more about the Geiger kit I am offering. 

I'll leave the pics and video here, but you'll find all the details about the kit through the link above. However, you can leave a comment here if you like.

Geiger Kit PCB  . . .


The video below is a bit dated, but gives a pretty good introduction


Monday, February 14, 2011

Accelerometer & Compass



No, it's not a B/W TV from the 50's. However Felix the Cat was one of the very first images transmitted to a TV screen.



I wanted to mess around with an accelerometer and this is what I came up with - before getting waylaid making Geiger Counter Kits.

From the beginning, I have to say that this was one of the most frustrating projects I've ever worked on. I consider myself a "completer" but several times, I had the desire to just dump the damn thing in a box, and say to hell with it. I'll try to spare the details of that side of the project.

I had a few goals in mind:
  • to learn about accelerometer and compass modules
  • to make a LiPo battery operated project
  • to use a graphic LCD and a menu system
  • and maybe make something I could put in my car
Lets start with the battery side of the thing. I wanted to be able to charge the LiPo, and I also wanted a constant 3.3V for Vcc and the Aref voltage. For the LiPo charger I used a MAX1555 wired per the datasheet.

Since the voltage on a LiPo can vary on both sides of 3.3V (3.0-3.7V), I decided I needed a "buck-boost regulating charge pump". (It's possible I didn't need one, but the name was so cool . . ..) I discovered the MAX1759 and also wired it per the datasheet. Soldering the tiny uMax package to a piece of proto board was an exercise in tedium.

I didn't want a toggle or slide power switch. I wanted a push button On/Off and I also wanted to automatically power it off from the uC if there was no movement for awhile. And of course, I didn't want to use much power to monitor the switch when the power was off. The solution was the Pololu Pushbutton Power Switch - it does all those things. I am working on a homemade version of this switch using an ATtiny85 that I will post here soon.  I added an ATmega328, with all pins broken out, and LCD and FTDI connectors.

At last! A shield that actually looks like a shield! This round board fits over this square board. After cutting two notches in it to access the LCD and FTDI connectors it was actually fit for a Gladiator - at least until I added the HMC6352 compass (I2C), MMA7361 accelerometer (analog) and DS1621 temperature sensor (I2C).

Finally, the graphic LCD and joystick. After a few flaky Nokia cell phone faceplates, I got a less flaky version of the Nokia 5110 graphic LCD. For the joystick I used a neat trick I learned from nuelectronics that switches resistors with the joystick so the 5 positions can be sensed by only one analogue input.

A wise man once told me "a project is only as good as it's case". (Actually no one told me that.) Long ago, I made a faceplate out of copper clad PCB board. Why not a whole case? 3D soldering! I also had some vintage phenolic board and some copper foil. I cut the copper clad board and mitered the edges. I soldered the box up from the inside. It solders very well. (I cranked up the iron to 425C.) I used the copper foil to attach and solder the phenolic board on the bottom. In a lot of ways, the case was the most rewarding part of the project. If there's anything worth learning here, this technique might be it.

So that's the hardware side. I'm less proud of the software side. I discovered that coding for the accelerometer and compass quickly make you wish you didn't sleep on your desk during geometry. In addition there's the low pass filtering, running average and . . . the dreaded Kalman filter (actually I didn't use one). I'll post the code at the end here, but if your smart, you won't download it. The menu system is sorta nice though. I got the basis from nuelectronics. I also wrote some simple graphic utilities.

Functionally - well, it needs some work, but he's a rundown of the screens . . .


The main menu . . .
(The accelerometer screen is boring. So is Debug.) The calibrate screen calibrates the compass - 2 revolutions in 20sec.

The compass screen shows degrees and ordinals.
There is also a temperature display.


The performance screen shows acceleration (right of center) and deceleration (left of center.)
The line through the bar sticks at the max recorded.

The roll and pitch screen shows, you know what.



Here's the sketch.


Saturday, January 22, 2011

X10 Remote Temperature - Redo

I became interested in the ATtiny85 processor recently. Up till now, my projects were based on the ATmega328 or the ATmega644. The  ATtiny85 is just that, tiny - only 8 pins vs. 28 on the ATmega328. The photo on the left shows the new  X10 temperature transmitter, with the DS1621 temperature chip on the left and the ATtiny85 on the right.
(The CM17A X10 RF transmitter is not shown.)

This board replaces what I had in the original X10 Wireless Temperature Transmitter which I've been using for the past year and a half.  (post is here)

So why the redo? The rational part of the answer is that I wanted the batteries to last longer.

The original temperature transmitter drew a whopping 2.2mA while in sleep mode. It was powered by 2 NiMH AA batts stepped up to 5V with a boost inverter. I'd change the batteries every month or so.

The redo board draws about .07mA while in sleep mode. It's running directly on 4 NiMH AA batts.  I'm guessing I'll change the batteries every 1.5 years or so. I choose AA batts over a 3.7V LiPo because it's easier to replace the NiMH batts with fresh ones, and I wanted the higher voltage for better range on the X10 transmitter. However, it's worth noting that the processor draws less current at lower voltages.

Most of the power savings can not be attributed to using the ATtiny, however. Along the way, I discovered a few things.

The first had to do with how I was reading the temperature on the DS1621. I was using "continuous mode" (most examples use this mode) which would give me a reading as soon as I asked for it, but at the cost of almost 1mA! I switched to "one-shot" mode which makes me wait ~750ms for a reading, but at a huge savings.

The second thing I found is that the CM17A library I made left the RTS & DTR lines high after transmitting. Setting them low, results in about a .5mA savings. Note that if you are using this lib and want to try it, be sure to give a nice delay before transmitting after you set the lines high. (There's always a trade off!)

I always use sleep mode for the lowest power usage when not transmitting. It's set to transmit about once every 6 minutes. There are several sleep mode routines for the ATmega processors, but the ATtiny needs entirely different registers set. I found good info on sleep mode, and good tutorials for the ATtiny at brownsofa.org and Inside Gadgets.

The way to do the things mentioned above will be much clearer when you look at the the example code, which will be provided later in this post. But now, I would like to describe how to go about using the Arduino environment to work with the ATtiny85 chip, and most of all, how to get I2C working on them so you can communicate with the DS1621, real time clocks, and even 2x16 displays - all with an 8 pin chip!

The first thing you must do is to get the ATtiny "core files" for the Arduino environment. There are several out there - each supporting more or less of the standard Arduino features. Core files, and instructions on how to get started with the Tiny85 can be found here, however, I prefer the core files from here.

You can use the ArduinoISP as a way of downloading the sketch into the ATtiny. I've used it and it works fine - just be sure to disable the automatic reboot after load! For me, an easy way to do that is to use a serial cable instead of the USB cable. However, there are other ways to do it. Keep in mind, you only need to hit reset when you load the ArduinoISP on to your Arduino. Once it's an ISP, change the Board type to ATTiny85, and just hit "Upload" (don't press "reset"). After you work with the ArduinoISP a while, I think you will want a real ISP Programmer to load the ATtiny. They are cheap and much easier!

Finally, get at least the TinyWireM "master" library for this project. I made a Playground article that explains this library and has a link to download it. The Playground article is here.

OK, almost done. To get the source code for the new X10 Remote Temperature Transmitter, you can download it here. (a new version as of 3/13/11)


Saturday, October 16, 2010

Receiving X10 RF Transmissions (Updated 11/21/10)

For me, at least, this was the last piece of the open hardware X10 puzzle. In this blog you'll find open hardware projects that receive and transmit PLC (powerline) signals, as well as transmitting X10 RF signals (via the CM17A). Now sitting in front of me, is an off the shelf 315MHz receiver (detuned to 310Mhz), happily beeping away each time a warm body crosses an X10 motion detector.

The receiver is from Sparkfun, but any similar receiver should work. The key is to get one with a tuning slug as opposed to a crystal. The software that interfaces the receiver to the Arduino is from a suite of X10 libraries written by ThomasM. You can find the whole suite (PLC transmit & receive, RF receive, and IR receive) here. Having written an earlier version of PLC receive, I'd recommend his version for PLC receive and transmit as well.

So lets get started. Get a  315MHz receiver, wire it up per the data sheet, get Thomas's libraries and his example sketch, (or get the "test & calibrate" sketch I made here). Press a key on an X10 RF remote. It should work right away, but only at close range.

So the next step is to tune this receiver closer to 310MHz. You'll want to start by adding an antenna. This page gave me the following lengths (in inches) for a vertical wire antenna at 310MHz:

  • 1/4 wave - 9 1/16"
  • 1/2 wave - 18 1/8"
  • full wave - 36 1/4"
I started with 1/4 wave whip antenna, but the ultimate may be the "egg beater" antenna posted by Dave Houston.

Now it's time to tune the receiver to 310Mhz. I don't have a scope, and I found that a sound card scope was of little help, since the signal is clipped to soundcard inputs, so I came up with two alternate methods.

The first method I tried was to simply connect the output (data pin) of the receiver to the Aux-in on my PC. You will hear a lot of noise! (This is due to the AGC built into the receiver.) However you will clearly hear the RF signal when you push a button on an X10 RF remote - as long as it's close and pointing at the antenna. Pointing the remote away from the antenna gave a fainter signal, and moving it further away made it even fainter. So with the faint signal, I simply turned the tuning slug until I got a clearer sound in the speakers when I pushed a button on the remote. Not very scientific, but it seemed to do the job. (I started by turning the slug CCW - this post said ~160° CCW.)

Later I used a different method which seemed to be more "real word". I made the "test & calibrate sketch" linked above. It simply beeps a piezo and outputs to serial whenever the receiver has a good read. Then I clamped a button down on an X10 RF Remote (HR12A) so it would continuously transmit,  and located it at varying distances from the receiver. While listening for the beeps, I adjusted the tuning slug for good reads at the furthest distance.

While using the second method, I also played around with antennas.  The 1/4 wave whip antenna really didn't seem to do much, and I couldn't pick up signals if the transmitter was outside my house. Then I tried a 36 1/4"  piece of twisted pair from a phone cable. One wire to the ANT pin on the receiver and the other to GND. This made a big difference, and the grounded lead contributed to the difference.

That's about where I am at this point. Interfaced to the example sketch I can receive RF signals from the motion sensors on my front and back doors. There's more about this in last half of this thread in the Arduino forum. [4-3-13] (There were changes to X10rf.h - here is the modified version I used.)

Not sure at this point where I want to go with this - perhaps a "whole house" X10 receiver with some other goodies, or some little dedicated device. We'll see.

Sunday, April 4, 2010

Geiger Counter - Part 2 (complete)

[Edit 4/10/11] This project is now available in kit form - with PCB and parts. Please click here for more information.

This post describes how I went about integrating the circuit described in the previous post with an Arduino and a LCD display.

I put it all into an old laptop power supply case - not my best work, but as we said in Arkansas, "it ain't no piano". It does have a nice sturdy feel though.

After experimenting with an LED bar graph and a Nokia 3310 cell phone display, I settled on a simple and cheap 8x2 LCD display from Sure Electronics.

First I moved the Geiger circuit off the breadboard and on to a proto board.
I kept things fairly tight which left a little room for future expansion. The piezo is mounted on the bottom of the board. I cut an opening in the bottom of the case under the tube.

On the other side of the case, I added the batteries, display and a small board for the Arduino MCU. It's just a simple stand-alone Arduino circuit using a resonator.
There are also 2 slide switches on the bottom - one to turn off the piezo, and the other to turn off the Arduino and display to save batteries. A salvaged push button on top turns the whole thing on and off.




The code counts the interrupts from the tube for a period of time, and displays the counts / minute as a value on the 1st line and as a bar graph on the second. I adapted the code for the bar graph from DeFex . It's nice because it uses custom characters to make partial blocks.

I used two different counting periods - a longer period when the CPM is below 100 (counting background radiation) and a shorter period when there is more activity. You can download the code here.

Here is the obligatory short movie . . .


It was a nice surprise to find our bathroom tile was hot. (Should help kill the germs!) Since the house was built in the '20s, I imagine it's uranium green glaze.

Sunday, February 28, 2010

Geiger Counter - Part 1

[Edit 4/10/11] This project is now available in kit form - with PCB and parts. Please click here for more information.


I guess I'm a "metroholic".
I've always been fascinated with measurement tools, so building a Geiger counter seemed like a logical thing to do. I will describe the build process here - even though the Arduino only plays small part, and that only a truly sick person (which I guess I am) would consider a Geiger counter as part of a Home Automation project.

"All work is derivative" and I owe the basic HV circuit to Jim Remington's Pololu article (where he mentions he derived the circuit from Tom Napier). To this, I contributed a nice "click" circuit, but more importantly, the sources, tips, and background that is helpful when building your own.

If you don't have a Geiger tube laying around in your junk drawer, you will have to order one. But the important thing is that you can build and test your circuit while you are waiting for that package from Russia.

The Geiger tube I settled on was the SBM-20. I ordered mine on eBay. You can also get it at the Electronic Goldmine (and even a whole kit). Later, I found this source for all tubes Russian, (and the best specs and prices on Geiger tubes). I am very happy with the SSBM-20. I originally tried a smaller glass tube - the CI-3BG - but found it much less sensitive - especially to beta particles.

There are 2 types of tubes. Those that have a mica window are the most sensitive. They will detect alpha and beta particles as well a gamma rays. Because of the mica, they are more fragile and generally are more expensive. The other type, like the SSBM-20 which I used, have only the metal jacket. They will detect gamma rays (the most penetrating) and some beta particles (more easily stopped). Considering the SSBM-20 is all metal, it does a good job with beta - as long as you put the sample right on the tube. Uranium is a big beta emitter, so some sensitivity to beta is a good thing.

As far as the circuit goes, you'll find several types on the internet. (One I also liked is here.) The first circuit I tried used a 1:1 transformer, but I preferred to go with a simple inductor instead. I also liked Jim's circuit because it works with a range supply voltages and uses very little current from the battery. Originally, I wanted the Arduino to be the oscillator instead of the 555, however, later I decided that I preferred the Geiger to run independently, and use the Arduino only for counting and display purposes. For the audio output, I had a good time designing my own based on what I learned on-line.

OK, you've been patient, here's the schematic . . .
You can download the image, and you can also get the Eagle files here.

On the left is pretty much Jim's circuit without the extra HV shutdown transistor. The 555 is used in an unusual way - it varies the duty cycle based on the input voltage. I tested 4-9V on input. The oscillator (~4KHz) is used with the inductor as a charge pump.

Q2 and D2 are the only critical type components. Q2 must be a high voltage transistor - the MPSA42 is a common type and works nicely. D2 is a "high efficency" or "ultra fast" diode. A regular diode will not work. On the schematic, I have listed some substitutions I've tried that worked. You might find a diode of this type in a PC switching power supply. R7 adjusts the high voltage, and seems to be pretty touchy about it's value - too low or too high and no HV. I bought most of the parts at Electronic Goldmine including the inductor.
[Edit 4/2/11] Also note that I used the CMOS version of the 555 timer - TLC555CP. If you use the bipolor version (uses more current) LM555 or NE555 you will need to adjust some values.

I labeled a HV Test Point. You want about 500VDC through the tube. But here's the rub, it's only a few micro amps, so most DMM's will load the circuit too much to measure it. If you measure around 200VDC you're doing fine. Don't even bother trying to measure across the tube - the 5.7M will drop everything.

Another tip is that the Geiger tube won't work if you leave your DMM connected to the HV test point. In short, you need a very good DMM or faith.

Finally, I wouldn't advise soldering leads directly to the ends of the tube. You run the risk of loosing the vacuum or otherwise damaging the tube. Use some sort of clip, or wrap several turns of wire around the ends.

While waiting for my tube, I tested by touching the wires that would go to it. (Two fingers on the same hand.) It's 500V but just a tiny amount of current. I could not even feel the voltage, but heard the click and got the interrupt. For obvious reasons, I can not recommend this procedure, and I'm just describing what I did. 


You will probably need to tweak the click circuit based on what type of "click" you like, and the resonant frequency of your particular piezo. R14/C7 controls the length of the click and R15/C6 controls the frequency of the click. The phase inverter (IC2B and IC2C) is used to get the most deflection out of the piezo and hence the loudest sound. For the inverters, be sure to use a logic family that provides enough current at the outputs. I had bad luck with the "LS" family and used the "ACT" family (i.e. SN74ACT14N) but the "HC" family should  also work (i.e. 74HC14N).

Once the circuit is built it's fun to play around with. With mine, I get around 35 CPM (Counts / Minute) background - a basement in Colorado, probably with Radon gas. Of course you will likely tear open a smoke detector and get the Am241 pellet out of it (600 CPM) and buy some Uraninite on eBay (350 CPM). [Edit 11/2010: Just tested some lantern mantles (Thorium-238) I got from this guy - got up to 6000 CPM.] The entire circuit consumes less than 3mA @ 5V in normal background.

The interrupt (before D3) goes low for about 150uS for each event. I made a simple Arduino sketch to count the events and calculate CPM. You can download it here. Later, I'll involve the Arduino more - building it into the case, and running a little 8x2 LCD display. Note that the Geiger counter module is totally standalone, so you can stop with that if you want.

For Home Automation, I picture it sitting on my roof with a CM17A periodically transmitting the current background radiation to the Nex10 box in my house (similar to the Wireless Temperature Transmitter). Then, if the radiation exceeds a threshold, I can dim the lights in the living room!



See Part II post above with added MCU board, display, and finished enclosure. But here is an intermediate step with just the Geiger circuit in a case . . .


A quick movie in it's intermediate state . . .

Wednesday, December 9, 2009

Telephone Interface (updated 12/30/09)

This project describes an Arduino/MCU interface to a telephone land-line. It's only been tested on a US version of the telephone system, but hopefully it will apply to the phone system in other countries.

The basic idea was to allow the MCU to make calls by transmitting DTMF tones, and to receive and decode DTMF tones (keystrokes) made on the phone that was called.

There are other possibilities however. Using the complete interface, it should be possible for the MCU to answer calls, and to transmit "room sounds" picked up by a microphone to the other phone.

If you're only interested in sending and receiving DTMF tones and not interfacing to a phone line, you can skip the next dozen or so paragraphs. The schematics and code samples will still apply. 

It all begins with the interface to the actual telephone line. Unfortunately this is trickiest part!

There are two reasons for this:
  1. Phone lines require a 600 Ohm "balanced line". You can't just slap any old circuit between your "TIP" and "Ring".
  2. It's illegal!

Lets start with #2. Here I'm speaking from a US and Canadian perspective, but I'm sure it's similar in many countries. In the US, it's FCC Part 68 that makes it illegal to connect any unapproved device across your phone lines. So what can they do? Well, I'm sure it's much worse than tearing off that tag on your mattress.  I've read that if you create a problem that must be investigated by the phone company, and it's due to a little circuit you whipped together - your financially liable to cover the cost of the phone companies time. And it's relatively easy to do horrible things to your phone line during the process of creating an interface, and that leads to point #1.

When you Google "phone interface" you'll be drinking from a fire hose of circuits, methods, and projects. I spent a lot of time researching them, and did indeed come up with an interface that "worked". However, what I ended up with, struck me as being sensitive to component values, and somewhat "fragile". By this I mean, for example, that the correct "polarity" for TIP and RING was required. Given that the line should be "balanced" I felt like I disturbed the balance of the force. In short, after all of my experience with electronics, I felt like I was over my head with the interface I came up with. Ironic considering you're dealing with a system that has been around for so long.

For those who want to ignore points 1 & 2 above, here are some of the best resources I found, as well as the schematic for the "working" interface I was using. Big disclaimer here! I do not recommend building your own unapproved interface. Furthermore, I am not responsible for anything you do with any information I am providing. Everything here you use at your own risk.

Some of the telephone interface links I found helpful are:
Just looking at the variety of this information should give you an idea what your up against when rolling your own POTS interface. The interface that I tried is here.

Not a very encouraging beginning is it?

Enter the "Direct Access ArrangementDAA. This little module is an FCC Part 68 approved interface. Does it make everything OK? I don't think so - it really just makes it a lot easier for you to get your device FCC approved. Will it give you peace of mind? You bet. After switching to a DAA, the TIP and RING polarity did not matter, and everything seems to be much more solid - calls go through 100% of the time. The DAA also saves you from buying an isolation transformer, relay, transistor, and a large capacitor.

The problem is getting your hands on one without having to special order 54 of them from Mouser, etc. After a lot of searching, the best deal I found, for my use, was for a Cermetek CH1817-LM (discontinued) on eBay - here. It will cost you $15-$18 shipped.

Note: If your interested in capturing caller ID, I don't think this is the DAA for you. However, while searching I did see some that will output CID. I also ran across the Holtek HT9032C which looks like an interesting CID chip, but they seem to be hard to find.

Sorry if the above was long and detailed. I wrote it in the interest of saving you a lot of time. However, as always, YMMV.

Once connected to the phone line, I wanted to do several things:
  • Have the Nex10 dial my cell when an event ("macro") was triggered.
  • Leave a message - a series of beeps.
  • Optionally be able to listen in on the room noise from the called phone. (work in progress)
  • Capture any key presses I made from my cell. (Not sure how I want to use this yet.)
Note that currently all the communication is initiated by the Nex10. In fact, it is possible to use the RI (ring indicator) on the DAA to answer calls with the Nex10. (No plans yet for this.)

To do the things above, I used 2 chips from Holtek - an HT9200B DTMF generator to dial the call, and a HT9170B DTMF receiver to read the key presses once connected. Both are less than 70¢ each at Futurlec.

I wired both chips per the datasheets and ran the HT9240B in serial mode. Here is my schematic and an Arduino example sketch for for the project at that point.

I could have stopped there, but even with serial mode, the interface to the MCU required 8 pins + power. I also want the Nex10 to accept "plug-in modules" - so an I2C interface seemed like the way to go.

I picked the PCF8574 I2C GPIO chip to go between the MCU and the DTMF chips. It's also available at Futurlec and is also wired per the datasheet. (Note: the PCA8574 is a newer version and runs at the faster I2C speed but was not carried by Futurlec.)

Both the DTMF receiver and the I2C GPIO have a nice feature that sets an interrupt line when new data is received. I wanted to use the INT line on the GPIO. However, because the DTMF receiver latches it's output, there was no easy way to read multiple presses of the same key. So, I am currently using the interrupt on the DTMF receiver (DV). Either way an external interrupt is triggered when new tones are received. This saves me from having to poll for changes.

Using the I2C GPIO with the interrupt line saves 5 pins on the MCU. Here is the current schematic and Eagle files. And here is the current example sketch for the completed project using the DAA, DTMF, and GPIO.

The short movie below discribes the state of the project before adding the GPIO. (Looks the same now - only less wires to the Arduino.)

Enjoy




Monday, October 19, 2009

Building a Case for the Nex10

Sounds like something a lawyer would say.

Building this case took a solid weekend.

The wood is walnut. I know this wood well because 25 years ago it was a tree on our land in Arkansas. We had to cut down some walnuts to make room for the house and we hauled them to the mill and had them cut into boards. For me, it's a nice mix of the past and present.

I planned a board down to 5/16", cut it up, and mitered the ends. Then I glued up a box.

The board was wide enough to make 2 boxes. I also made the acrylic front using acetone to chemically wield two black strips that hold the 8x32 matrix in place. The IR sensor is glued over a small hole drilled in the top black strip.

I got a few gaps in the wield which show up as shinny spots on the black strips. Next time a little more acetone and better clamping. I used tripoli abrasive on a buffing wheel to finish the edges.

To make the box stronger, and more interesting, I added ebony splines in the corners. I do this with a jig I made for my router table. Its kind of a sled that holds the box at 45° (photo).

After cutting off the excess ebony (photo), I rounded all the corners with the router.

On the inside of the box there's a platform that holds the board in position to line up the SD socket with a slot in the side of the case (photo). I used the router to cut the slot, and a little sanding drum to make the recess in the case for fingers to get at the card (photo).

A back cover of clear acrylic was made to fit into a rabbet cut around the back of the box. A power jack and an RJ14 jack for the PSC05 was added to the back. There's also a hole for the USB cable when I'm developing (photo). (Later I added a wood dowel with a hole that fits over the stem of the reset button to bring it out to the back of the case (photo).

The box was finished with a light coat of tung oil varnish. (photo)

Finally, the obligatory video . . .


Friday, October 16, 2009

Nex10 Functionality

Almost all of the functionality of the "X10 Book" is included in this project and new features have been added.

What's missing is the ability to drive relays and LED's. My thinking is to include such things as optional "add-ons". So a "relay pack" could be designed for lawn sprinklers. I'm currently working on a phone dialer (see above), and I'm considering other ad-on modules like a Bluetooth PC interface. But I've gotten ahead of myself.

One of the biggest advantages over the X10 Book is the ability to read in configuration files that are put on the SD card. So far there are 4:
  1. TIMEDATE.TXT - enter the time and date on a single line, put the card in the Nex10, restart, and the time and date are set. (Then the file is deleted from the card.)
  2. SETUP.TXT - this file is loaded into the external EEPROM and deleted after loading. It has several sections where you can define;
    Messages - like names of the weekdays, full moon names, etc.
    Reminders - yearly reminders like birthdays, scheduled salary reviews, etc.
    X10 Events - timers to send X10 commands at certain times.
    X10 Profiles - Friendly names for House / Unit codes so instead of "A-5" "Desk Lamp" is displayed. Other parameters in each Profile control beep type, display and logging options.
    X10 Macros - (work in progress) "IF A-5 ON - Send G-2 and G-3 OFF" is a simple example. They should be pretty powerful - stay tuned.
  3. PARAMS.TXT - This file contains user defined parameters such as the date and time format, the house code for the remote temp sensor, high / low temp alarms, various delay times, etc.I've pretty much replaced all "hard coded" settings with these parameters.
  4. FONTS.TXT - Since we're using an LED display, a set of fonts must be defined. All characters from ASCII 32 to 127 are included. Additionally about 20 or so "sprites" like the moon phases are defined. This file is loaded to the ATmega644P EEPROM instead of the external EEPROM. It is deleted after it is read in.
So what's it do? We'll you should have some idea from the above, but here's the list in all it's gory detail . . .

Clock Features:
  • Time - set by writing it to a file on the SD card, automatically adjusts for DST. The clock has a battery backup.
  • Day of the week is displayed with a user defined message for each day.
  • The current phase of the moon is displayed as an animated sprite. The number of days to the next full moon, and name of the full moon, is displayed as a scrolling message.
  • The times for sunrise and sunset are displayed.
  • Yearly reminders will display a day in advance and on the day.
X10 Features:
  • All X10 signals that come across the powerline are displayed and optionally logged. If a "profile" was set up for the house and unit code, a friendly name will display - i.e. "Desk Lamp". The profile also has options for 3 levels of "beep", no display, and no logging.
  • Logs are written to the SD card as a text file readable by a PC. A new log file is automatically created each month.
  • The current status of all 255 devices is kept. The status table can be written to the SD card or cleared using the TV remote. The table will be used for one type of "macro" command.
  • A TV remote may be used to manually send X10 commands.
  • X10 commands can be set up to be automatically sent at certain times during the day.
  • X10 Macros are defined in a section of the setup file. Current types supported are; "if cmnd-then cmnds" (up to 5 thens), "if cmnd and time > x or < y then cmnd, if cmnd - display time, temp, etc. I am working on more types like "if temperature".
  • Nex10 will receive the temperature from a remote wireless sensor on a dedicated House Code. (See this.) The time and temperature is logged to a separate file on the SD card. The current temperature and the low and high temperature for the day is displayed in the display loop.
  • Alarms may be set to provide an audible warning if, for example, the the garage door has not closed in a certain time.
  • There's a good chance I forgot something.
Most of the time, the device is just listening for X10 commands coming from the PSC05. Once every 5 minutes or so, it goes into it's display routine and shows all the things listed above under clock features. The display routine can also be activated via the remote, or from a macro.

Credit and thanks to Bill Westfield, Andrew Hedges, and Bill Ho for the ht1632 code that writes to the Sure matrix, Bill Greiman for the fantastic SD card library fat16lib, B. Hagman for a slick non-blocking Tone library, and Mike Rice for a great little sunrise / sunset time calc. library.

Sunday, October 11, 2009

Nex10 Begins

I'm far enough along that I can be posting about this thing.

To the left is a PCB board I designed to be the platform for the "Nex10" - the next level of the "X10 Book".

The goal is to create an X10 controller that is user configurable without the need to change the software. The Nex10 is configured through text files copied to it's SD card. More on the functionality later. This post is about the hardware!

A larger picture of the board is here.

In order to support reads and writes of the SD card, I went with a larger microcontroller - the ATmega644P. This has twice the program space of the ATmega328 used in the X10 Book. The board also has an external EEPROM, RTC (real time clock), piezo, and IR detector. It also has a difficult to solder FTDI chip that allows it to be programmed via USB. I see this as totally optional. I just wanted one to make my development easier. Besides, it's pretty cool!

Other little goodies include a resettable fuse, ISP header, and jumpers for power, auto-reset, and ARef. It runs on regulated 5V and has a voltage regulator that supplies 3.3V for the SD card. It uses a 16MHz crystal or resonator.

I used CadSoft's Eagle to create the schematic and lay out the board and BatchPCB to fabricate it. This is Rev. 1, and amazingly everything worked. If I decide to make a Rev. 2 there are a few changes I'd make, but basically I'm pretty happy. (Eagle files here.)

This board will drive an 8x32 LED Matrix from Sure Electronics. This display is very easy to read, cheap, and uses SPI so no additional hardware is needed on the board.

There is nothing about the board that is dedicated to Nex10 application - it can be used for just about any microcontroller project.

If you'd like a board very similar to this one (with a serial interface), a fellow maker, Florin, sells an easy to solder kit. You can read about it here.

Thursday, September 17, 2009

Is the Garage Door Closed?


After the second time my neighbor had to tell me that I left my garage door open, I thought I'd throw a little technology at my senility.


I could have gone the route of using a PSC01 "PowerFlash" but I had a few problems with that:

  • It requires a "normally closed" reed switch (which opens when the door is closed and next to the magnet. 
  • It only sends the X10 command one time. 
  • It would plug into the same outlet as the door opener - not a good time or place to send X10 signals on the power line. 
  • I wanted to make my own. :-) 
So this ugly little board above was my solution. It consists of an ATmega168 (running on it's internal oscillator), and a CM17A "Firecracker" (removed from it's jacket). It's wire-tied to it's wall wart.

When the normally open reed switch closes - because the door is open - it causes a pin based interrupt in the ATmega168. The CM17A then sends a preset House + Unit + ON wirelessly to a TM751 receiver and it's put on the power line and picked up by the X10 Book (see below). The command is sent 3 times with a delay in between to make sure the signal gets through. When the door closes, an OFF signal is sent 3 times.

(get Arduino sketch)

On the X10 Book side, a timer is started when the first door open signal arrives. After a preset time, the X10 Book beeps every few seconds until it receives a door closed signal.

If the door is open late at night, the X10 Book will also turn on lights near the garage. (I could have it wake me up, but I'd be too tired and too scared to want that!)