Translate

Sunday, November 7, 2010

110V Lamp Bulb replacement

With one of the 10 Watt LED lamp kit Roberto sent, I tried to build a bulb replacement.
Here some notes and comments.

First attempt

I started from an old CFL lamp, removing the fluorescent tube and the electronic ballast.
The LED power supply in the kit was round and fit perfectly the old CFL base.












The initial kit included the 10 Watt LED and a small square heat-sink with a fan.











I glued the LED to the heat-sink with a thermal compound and I attached the heat-sink to the CFL base using hot glue.
Unfortunately I don't have pictures of the first bulb replacement attempt.
It worked nicely until one day the fan broke down. Without the fan the temperature of the heat-sink was high enough to melt down the hot glue, detaching the heat-sink and the LED from the bulb base.

Second attempt

I had to rebuild the lamp bulb.
This time I choose to have a passive heat-sink, so I ordered one round and big enough for the 10 Watt LED.



The problem to solve was how to connect the heat-sink to the bulb base.
I decided to try the same method adopted for one of the desk lamp modifications.
Since the bulb base is around 2 inches diameter, I cut a piece of wood with that diameter.
Lee was able to drill and tap a hole in the heat-sink in order to screw it to the round piece of wood.



















I did a hole in the bulb base to have the wires out and then I screwed the wood round piece to the bulb with 4 screws.
Here the lamp assembled and a detail of the attachment to the bulb base :











The only problem so far is that the bigger heat-sink prevent to use the lamp in many of my fixtures !!
Otherwise is working perfectly.




Friday, November 5, 2010

Flood alarm with X10


This simple project was done years ago, it can be an excellent example to show how is easy to integrate X10 in our own projects.
I needed a simple low cost flood alarm, capable to monitor some sensors and notify as soon as possible about flood conditions.

The problem

X10 Universal module
After two floods in the basement, one from the washer and one from the HVAC, I decided to monitor these area to avoid further problems. 
I also needed a way to be informed in the rest of the house about a problem in the basement, where the problem happened.
So I decided to use an X10 transmitter, controlling an X10 Universal module (it has the possibility to generate a sound when triggered).
The the transmitter was modified, in order to control the pushbutton with a rele reed.




Project

Since I needed something simple, quick to build and reliable, I used the usual PIC 16F84, plus some external components (at the time I was using PICs rather then the MSP430).
Before to excite too much who is reading this article, I built the X10 interface hacking a ready-made X10 RF transmitter.
So I didn't designed nothing directly with X10.

I always try to optimize the effort and re-use as much as possible what I have around, so instead to design an X10 transmitter, with all the problems that such design imply (interface the power grid, insulation, ecc.) I choose another way also because the flood alarm is supposed to be placed in areas potentially flooded !

So I choose to use a ready-made X10 RF transmitter, drove it by a reed relay, simulating the pushbutton.
In this way I was able to obtain the requested insulation and safety and also the capability to place the alarm everywhere needed.

Here a block schematic :
h2oalm.jpg


Here a floor map of the basement where the flood alarm was deployed :

zone.jpg



 Hardware


As I said before, the hardware is based on the PIC 16F84 and the code is not critical, so it should be  easy to port it on other PICs or other Micro controller.
As you can see from the schematic, the PIC is handling directly the LCD and the sensor, based on a Cmos port.
There is nothing to add, is almost all standard.

h2o.jpg

The sensor, based on a CMOS 4049, is very simple.
When no water is touching the two terminal of the sensor, the port is forced by the pull-up.
As soon water connect the two sensor entries, the port change state.
The LED was placed just to debug the system, is not necessary for normal operations.
The capacitor between the sensor terminal allowed to stabilize the signal event, removing noise.
Since the flood condition is (hopefully) a rare one, I didn't bother to use an AC signal to prevent sensor corrosion.
This is a flood alarm, not a level indicator so the sensors are supposed to be dry all the time.
To avoid false alarms the software filters out the reading of the sensor, cutting out any possible "spike"

Software

 
The software is written all in C and compiled with the PICC Lite. It's very simple.

h2oalm1.jpg

As you can see, the firmware perform a debounce function for each sensor input, in order to avoid as much as possible, false alarms.
Because the type of events to monitor, 10 seconds to have a positive reading for a flood, are more than acceptable.
That allowed to simplify the sensor electronic design.

h2oalm2.jpg


Sensors

For this project I used two types of sensors :
  • Sensor 1 - in a pipe
  • Sensor 2 - on the floor
 
In order to built the floor sensor, I used a toy container, the ones that is possible to find in some coin machines, at least here in the USA.
I screwed 3 screws on the bottom, connected a wire to one screw and the other wire to the other 2 screws.
Then I added some plastic clay to increase the weight of the sensor (be sure the clay used is not conductive and water resistant) and "glued" the entry wires with other clay.
The pipe sensor, to be placed in the T junction at the output of the HVAC, was built with two brass bars, glued with hot glue, to a pipe cap.

Pictures

Here some pictures of the circuit and the placing.








The box used to host the circuit is a plastic display box for dolls.
Easy to find and work (Plexiglas) it gives an interesting view of the circuit and is easy to seal.
Note the X10 transmitter at the base of the box and the rele reed that controls it.
They are just attached with some velcro.
The X10 transmitter still uses it's own original batteries, they last years in normal use.



Here the sensor for the pipe.
The pipe it was bringing out the water from the HVAC condenser and sometime there were "clogs" in the end of the pipe.
When this was happening, the water generated by the HVAC overflowed from the condenser in the basement.
Quite a mess.



Just in case the pipe sensor was not able to catch the flood, I prepared another sensor and placed just on the bottom fo the HVAC unit, where I noticed the water going first.


Here a modification for watering the plants.
We had a very dry and hot summer, so I decided to collect the HVAC water to water the plants.
I used a big container (actually a paper waste) and created a very fast "sensor" using two PC slot covers attached to one entry of the flood alarm.
In this way when the bucket was almost full the alarm would tell me so, allowing me to empty the bucket and water the plants.



In order to fill up the bucket, I temporarily diverted the pipe coming out the HVAC.


Conclusions 

The flood alarm worked for a couple of years without problems and currently is in some box, since the moving changed the needs.
At least I know to have it if the need arise again :-)

The most critical part, the sensor, was actually extremely reliable even if so simple.
Only one time I had problems, when a sensor wire broken up, because my bad installation (never EVER use uninsulated pins to attach a cable just because you run out of time !).
But other than that the circuit was really stable and reliable, saving me at least from 3 floods.

As usual, if somebody is interested in the source code, just contact me.
I don't have yet set up a public place where to store the code.

Sunday, October 24, 2010

Repairing a Mickey Mouse Lamp - UPDATED !

My daughter has a nice Mickey Mouse lamp.
We bought it years ago and it worked nicely for many years, until "somebody" connected it to an X10 Lamp module.
After few times, the lamp stopped to work completely.
In this article I'm documenting the repairing process.

Sunday, October 17, 2010

Hacking an Infoglobe - part 5

In order to better test the interface permanently connected to the Infoglobe and free up the breadboard for other experiments, I finally I decided to build an Infoglobe interface on a small experiment PCB, with the technique of point-to-point connection, i.e.wired.

I considered to prepare a PCB but since is still a prototype, is better to build it "fast and dirty", i.e.  a point-to-point connection on an experimental board.
Also, I didn't want to spend too much for that, so I looked in the junkyard for components and housing.

I found a nice box I bought years ago for who-remember-now project and I started to collect the components.
I decided that a broken piece of experimental board from Radio Shack was enough for the job, so I collected all the components and started to prepare the first Infoglobe Interface for permanent test.



First I prepared the mechanical part, i.e. drilling the housing to connect a DB9 female, an RJ11 outlet and two holes for the pushbuttons.
With the help of some power-tools I was able to do a "just-barely-decent" work.
No, I'm not really good with the mechanical part.

Then I started to figure out how and where to place the micro-controller PCB.
I picked up a new MSP430F2012 PCB and look in the junkyard to see what I could do.

I started with a straight 7+7 DIL (male and female) but the micro was too hight for the box, so I had to use two 90 degrees 7+7 DIL to obtain a decent hight.
Unfortunately that left very few space for the rest of the components !
Well, will be a very populated board !

With the power tools I beautified (well ...) the broken experimental PCB and started to place some components on.
Here the layout of the experimental PCB I'm working on:


A quick note. The current firmware revision of the code, include the reading of the internal temperature of the MSP430F2012 internal sensor, connected to the ADC.This why the two pushbuttons. They select the operating mode.
More details in future articles.

And here some other pictures of the prototype.


Retrofit a small desk lamp with LED

Among the LED lamp kit I had around, there was a 3W Cree Xlamp 7090 with a small power supply.
For a while I kept it mounted it in a cable clipper, glued under a shelf.
Then, after some renovation in the Athena's room, a small desk lamp caught my attention and I decided to retrofit it with  such kit.
I removed the original lamp socket and rewired the base of the lamp.
Like the electronic  lab lamp I did, I decided to put in the lamp top reflector only the LED with the heat-sink.
The power supply, a very small one, is in the base.
Here some pictures and notes :


This is the small desk lamp retrofitted with the Cree 3Watt LED.

This is the kit used to retrofit the small desk lamp.
Originally I placed the diffuser/lens, but for this application I removed it since the light is better reflected by the lamp diffuser.

The lamp base opened.
The weight is insulated by a plastic bag.
The base material is plastic, so already insulated.

Here the base emptied.

And here the base retrofitted.
The power supply (on the right)  and the new small cable carrying the LED power supply entering in the shaft (on the left).

 Here the LED glued on the heat-sink and  attached to the original lamp support.
 
The lamp on.  A very nice and strong light.
More than enough to replace the original 40W incandescent bulb.

Saturday, October 16, 2010

Hacking an Infoglobe - part 4

The next step, after the  necessary frequency generation and 38 kHz burst management, is to actually be able to send a message, following the specifications defined before.
Basically the next step is to sending out  a buffer (max. 40 bytes) using the 38 kHz burst to send the zero bits, with a 1 ms bit time.

Hardware
The purpose of the second prototype, is to develop a code capable to send messages to the rotating arm of the Infoglobe, driving the Infrared LED.

Because the memory capacity of this specific micro-controller, will not be possible to install a code to handle the Zig-Bee protocol, unless to use a complete external ZigBee module, like the ones MaxStream.

The second prototype is developed in two steps :
  1. send a message to the rotating arm pressing a pushbutton
  2. send a message to the rotating arm, received from a RS232 input 
The specific micro-controller used ( an MSP430F2012) has an internal USART capable to handle an SPI or I2C connection, but NOT a RS232 UART.
So in order to receive an RS232 message, a soft-UART is  developed, using a standard I/O Pin.

Here a basic schematic for the the second prototype

A quick explanation of the circuit.
The transistor enable or disable the signal from the base to the IR.
The two diodes basically forms an OR, mixing the two signals directed to the rotating arm.
One from the base (that can be disabled) and one from the micro.
In theory is possible to leave on  the base generator and send a message from the micro, however since we can not control the messages generated by the base, is possible to end up with some conflicts, obtaining only garbled messages.

The correct sequence to use is to prevent the messages generated by the base to reach the IR diode, and then send out the message from the micro.
As long the messages generated by the base are disabled, the rotating arm will display the last received message.

The RS232 section is optoisolated in order to protect the PC from possible spark from the Infoglobe, that it can be connected to the phone line (it is a caller ID).
The pushbutton allows to select different options or for test purposes.

List of the needed material/tools for the experiment :
  • modified Infoglobe(see previous articles)
  • USB development system for the MSP430F2012
  • C cross compilator for MSP430 - IAR (with the USB spi-by-wire development system)
  • cad Eagle to draw schematics
Electronic components (see schematic)
    • micro MSP430F2012 (on the development kit PCB)
    • male connector DIL 2.54 7+7
    • female connector DIL 2.54 7+7
    • PCB RJ11 connector
    • 3 3k3 Ohm resistors
    • 3 10k Ohm resistors
    • 1 4k7 Ohm resistors
    • 1 2k7 Ohm resistors
    • 2 power supply regulator capacitors
    • 1 power supply regulator 3.3 V Lm1117
    • 1 10uF tantalium capacitor
    • 1 optoisolator 4n35
    • 1 transistor NPN
    • 3 1n4148 diodes
    • 1 pushbutton
    • breadboard
    There are many ways to connect the micro to the development system.
    I prepared a flat cable that brings out the micro pins to a standard DIL plug.



    First test circuit - breadboard

    Connect the 7+7 male Dil connector to the microcontroller PCB, so to be able to have it connected to the test circuit (maybe using a cable to have it on a breadboard).
    The 14 pins are basically in parallel to the micro-controller pins, so for prototyping is perfect.

    On the experimental board, put the female 7+7 DIL, that will be used to connect the micro and the RJ11 outlet, connected to a cable to the Infoglobe, the power supply regulator, to bring down to 3.3 V the 5V coming from the Infoglobe.








    Important Note.
    Before to connect the micro-controller PCB to the test circuit, be sure to REMOVE the SMD resistor R1 from the micro-controller PCB.
    In this way the micro-controller will be powered from the P1 pin instead the USB development system.

    Software

    Here the flow chart of the state machine to be included in the timer interrupt management.
    This state machine will be called every millisecond and if something will be present in the buffer, will be sent.
    The fetch part of the code will run in the main loop.


    I made some measurement using the pin 1.0, the one connected to the LED put on the microcontroller PCB.
    Here some time execution in the interrupt :
    • ~1.4 uSec in IDLE
    • ~3.8 uSec in START/SEND (sending bit)
    • ~6.8 uSec in SEND (loading character/test)
    I also included in the code a couple of defines, to create a test environment, capable to only generate the 38 kHz burst, for fine tuning.
    Simply uncommenting one of the two defines CALL_MODE0 or CALL_MODE1 (not together at the same time) and compiling the code, the basic frequencies will be generated constantly, so to be able to measure and tune the timer.

    In this way there is no need to switch back on the initial test code.

    (note, I'm still deciding if/where/how/when to create a public repository for my code. For the moment if somebody wants the code, just write me)