RF Remote Control v2

Made another remote control for my RF light switch. Pretty much the same as before but on a smaller PCB. Also ended up putting it in an old Maxim sample box.

I found a couple of button nubs in my junk box so decided to go with those. Even so I had to raise the buttons with pieces of rubber. A piece of tape keeps the buttons from falling out when the box is opened and also adds some tolerance for misalignment.

PCB made with PnP Blue, the 12v battery is soldered.

Here it is working:

Board: here

ATTINY13 source: here (set framesize:8, softstack:16 in bascom compiler settings, fusebits configured to 9.6mhz internal OSC)

Parts:

D6, D3, VCCZNR = 5.1V Zeners

R1 = 100ohm 1k

R3,R4 = 2.2k

R5,R7 = 10K

R11 = 10K

Q1 = some small RF transistor (I used MPSH10)

C1 = 1pF

C2= 2pF (these are not critical)

C3 = Trimmer cap ideally 1-5pF

C4= 2200pF

D1,D2 = 1n4148 or similar

L1 = 1uH

L2 = swapped out for 4pF cap

RF Remote Control Emulation

A few weeks ago I got one of these:


It's a remote controllable light switch that comes with an RF remote. The only light switch is across the room from my PC and it's a pretty large room. (The building's basically a 1-room apartment) so this works out great with the remote. Of course since I'm using the remote to cut the lights when I go to bed I'm basically using the remote from two places which brings with it the unavoidable annoyance of the remote being in the wrong place all the time. Which means I have to get up and look for it which is effectively as much of an annoyance as it was meant to solve. So I wanted a second controller that would basically be a stationary switch by my bed so I could leave the portable remote around the desk.
Call me lazy I won't even deny it.

I popped the original remote open to see what I was dealing with.


After some research I concluded that LP801B is a PT2262 clone which is a remote control encoder chip. Has a few address and data pins and generates a signal on the output pin based on the configuration of those at the time the enable pin is connected to ground.
At first I didn't think much of it and ordered some PT2262s and made a PCB which is basically a clone of the original remote adapted for components I had lying around (or just stupidly large pads where I had no idea what I was going to use when I made the board)


Not being patient enough however I started looking around to see if anyone's emulated this chip on a microcontroller before. Turns out, several people did.
So I took the code at http://www.mikroe.com/forum/viewtopic.php?f=13&t=10832 and ported it over to BASCOM for the ATTINY13.
I think that code has a bug though as the logic low component of the syncbit should be 31 times the short-pulse duration according to the datasheet not 7. (He's basically divided the datasheet units by 4 in case anyone actually looks into this) The decoders may not care as It seems to have worked for him. When I got mine to work I was using the datasheet-correct count so I didn't test with that. It took several modifications to my original board to get it working with the attiny. Had to put in 3 zeners as the PT2262 operates directly from 12v which the attiny can't do. I actually fried an ATTINY2313 the first time around because I forgot the two selector/power buttons that were still at 12v. If I knew in advance that I'd be able to do this I would've designed a much smaller board..

I was trying random numbers for the pulse duration and randomly tuning the white variable capacitor but with none of the parameters actually being correct this method was never going to work. After some wasted time I caved and connected the original remote's encoder chip data output pin to the microphone input of my netbook.
Then with the cool Soundcard Oscilloscope from http://www.zeitnitz.de/Christian/scope_en got this:
To which I could adapt my pulse duration.
At this point I tested my board and while tuning the variable cap it suddenly became dark in the room :) It took a few more iterations to get the delay "just right" but now it works perfectly.
I put it in a small electrical box with 2 push-buttons and installed it in an easy to reach location from the bed.


Some component leg that I forgot to cut (probably a resistor) must have punctured the battery wire though as it drained to 10v by that night and since the circuit is basically open when none of the buttons are pressed that shouldn't happen at all. I did find a puncture mark on the positive lead so that must have been it.. damn. After reseating the board in the box and making sure the battery wires don't pass under any component legs it hasn't happened again.

Project files:

Board
Very large. But the (somewhat smaller, by about 20%, still fairly large) version is on the browsing/printing PC upstairs and I'm too lazy to get it :) Note below on the jumper blocks:
[1] [2] [3]
No connection: FLOAT bit
1+3: Bit 0
2+3: Bit 1
1+2: Short out the battery
And that this PCB is for the PT2262 (and clones) so it needs modifications to be used with an AVR. At least 1 5.1V zener for the CHIPPWR and 1 per button.

The board runs off a 23A (12 volt) stack battery. Running from lower voltages may be possible but the RF circuit definitely needs to be retuned.

Schematic
Messy. The seemingly unconnected wires from the diodes on the data pins are actually connected to CHIPPWR.

PT2262 emulation code in BASCOM

Water Heater Thermostat

I have a small(50L) electric water heater in my apartment. It was a cheapo and came with a mechanical thermostat. Just a few days after this was installed (and construction work still going on) I looked at the external thermometer and realized that the water temperature has dropped to a uselessly low level. So I went ahead and set the thermostat to 4 (out of 5). This made it go up to about 65C but in a day or so it was already below 50. I had to conclude that either the thermostat is broken or (what still seemed unlikely at the time) this type of thermostat either works completely unreliably when the cooling is slow or has a huge hysteresis gap that can't be changed or maybe both. So I bought one from a different manufacturer, installed it and got the exact same results. This is actually why I started looking into thermostats in the first place. Changing the pipe heater's was just a side-project. At first I considered just buying a capillary thermostat that higher-end water heaters use but decided against it because I've stumbled on the DS1821s.

It was important for this to a be a drop-in replacement for the original mechanical thermostat.
It was also important for it to be safe(ish) with at least one thermal overrun protection that isn't electronic. So I've designed a board that is essentially a relay driver adapter that the 1821 can control with a terminal block for connecting a thermal fuse. The first version looked this like:




The measuring tube in the tank turned out to actually be really narrow so I had to throw out that chrome rod and use smaller wire for the thermal fuse. It doesn't look as nice or tidy now but it fits. Here's a test fitting with the thick wire still and no fuse at the end:


The relay is an 8A DPDT. I was unsure about the reliability of the 1821 at higher temperatures so at first I've built an ATTiny13 based "debugger" that reported the temperature and the config register to a PC that I checked on from time to time. It seemed stable enough so I've been using this for a few days now and water temperature is pretty much constant :)

Board Eagle here
R6 - 2.2k
R8 - 10k

The board requires 5v and 12v DC and the AC for the water heater. Currently I'm using an external power supply in a modified wall adapter box.


Notes on soldering thermal fuses:

For a project like this a 98C or 104C SEFUSE or ThermoDisc G4 works nicely. They're small (size of a larger resistor) and can do 10A. They should be cooled (spray from some alcohol-based cleaner should do) and their leads held in a clamp or larger pair of pliers while soldering to keep them from reaching their cutoff point. Being quick also helps.

UPDATE: Safety modification

I've reencountered the problem that initially prompted me to build the ATTINY based debugging board. Apparently the 1821 can fail to enter thermostat mode when powering up.

Maybe it has to do with noise on the PSU during the initial stages of powerup and connection to mains that may be erroneously triggering Sensor-mode reset. I have no oscilloscope to see what's going on but the end result is that If the sensor fails to enter thermostat mode the boiler will overheat. Which is decidedly not a good thing. I can't reliably reproduce the problem but I'm going to assume that it's uninfluenced by the POL register and just basically makes the thermostat output stick at logic high. I've added an inverter and changed POL to 1. This way the 1821 is logic high once the upper threshold is reached, which is inverted to 0 turning off the heater. If it decides not to start up correctly sticking at logic high it just won't start heating.

UPDATE:

The above modification seems to have fixed the issue. I've had no problems with the system since.

UPDATE several years later: R.I.P
In hindsight.. this really wasn't a project worth doing. It was a good learning experience and it worked fine for years but then it started smelling worse and worse. My contacts weren't the right thickness for the heating element and it started to heat up and melt the plastic around it. I retired it and went back to the mechanical unit in the end. I'm not sure if it's just my imagination or if spending a few winters and summers outside helped smooth out the operation of the bimetallic switch but the thing seems to work better now.

Standalone DS1821 thermostat programmer

As a continuation of the previous project I decided to make a standalone gadget to program DS1821 thermostats. As mentioned before these devices are non-MicroLan 1wire thermometers capable of standalone thermostat operation. After configuration for thermostat mode the center (1Wire DQ) pin becomes a thermostat output pin. Since it's still an open collector pin it needs a pull up resistor, and since it's still basically a 4mA GPIO a transistor at least is needed to switch anything meaningful with it.

I've used the ATMega8 "devboard" that I used in the v1 heating cable thermostat. Made a plug in board for that (don't call it shield) with a couple of TIL311s, 3 buttons, some pullup resistors and a socket for the 1821s.


On the underside is an incredible mess of cables that I'm not going to show.
Buttons are Up, Down and OK

First it asks for the TL, then the TH 1 digit each (settable 0-9).
Then it'll display A0. with the 0 being switchable between 0 or 1. This is the POL (0 for heating 1 for cooling thermostat)
B0 similarly is the thermostat mode (0 = 1wire sensor 1= thermostat)
C0 is the negative setting. Since I'm only using 2 displays this is how I'm handling negative entry.
C0 = neither value is negative
C1 = TL is negative
C2 = TH is negative
C3 = Both are negative

Once OK is pushed here it'll program the settings and display 00
That's it!

Spaghetti BASCOM code can be found here

Any latching BCD display could be used in place of the TILs, these are just what I had lying around. Hookup can be determined from the source code. I have no schematics or pcb as I was just hooking stuff up on the fly and coding to adapt. Pullups needed for buttons and the 1wpwr and DQ pins. Most delays in the code are probably not needed.

UPDATE:

Congrats if you've read this far. Two things I'd like to add. This is a sideproject from the more useful application of the DS1821: Keeping my pipes from freezing in during the winter.

And I actually made two videos during the making of this that I didn't include because well.. They're dark and boring and I didn't think another blog(HackedGadgets) would pick up this particular project. Thanks Alan.

Well, here they are. If you're wondering no I didn't record it in the dark. Actually, the room was blasted with four 40W CFL tubes. This is just how bad my point-and-shoot is.

First one's just testing out the TILs counting 0-F on each. (and I called it shield.. d'oh!)

Second one shows the programmer working

Water Pipe Anti-Freeze Heating Take 2

With winter approaching I decided to simplify my water pipe anti-freeze system. The initial project here used an ATMega8 and an I2C thermometer. I replaced that with a single DS1821. This small device looks like a transistor but is actually a thermometer chip capable of standalone thermostat operation once configured via 1Wire.

The DQ pin becomes a thermostat output pin, which in my case is then used to control a transistor which switches the Heating On LED and an optocoupler which then switches the ATX PSU. The system looks exactly the same from the outside and I'm not taking pictures of the inside as it's basically just the schematic above implemented on a piece of stripboard with the DS1821 at the end of some telephone cable running a few meters under the insulation putting the thermostat where the yellow tape is on the picture below.

Note that the DS1821 is NOT a MicroLAN capable device, it doesn't support the protocol required for MicroLan enumeration/operation. It also cannot be connected to my 1-Wire MicroLan modded Fonera. To program it I used an ATTiny2313 and some ugly hacked-together piece of BASCOM code. The 1821 has to be hooked up according to the pins configured in the code (the bottom 3 pins on the left side of the chip by the way, I basically just put 3 pins from an ic socket there to hot-swap the devices.) pullups then need to be added to DQ and Vcc(4.7kohm will do). Also configure the fusebits to use the internal osc of the ATTiny with the clock divider disabled, setting it to run at 8MHz.

The ATTiny's UART then needs to be connected to a PC. To program first issue a read command.

>read
temp:0
conf:84
TH:10
TL:5

This device is already configured for my pipe-heater. The temp will be 0 because we haven't issued a Start command to the chip. For info on the conf register byte consult the datasheet.
TL is the low threshold TH is the high threshold.

the set command configures the device. It'll just ask for TL and TH, then print out the read-back values for verification.

>set
TL:5
TH:10
5
10

deploy then ends the configuration of the device

>deploy
POL1
Thermo1

POL is the POL bit in the config register. It determines whether the Thermostat output is active-low or active-high. Simply put: you use POL0 for heating and POL1 for cooling.

Thermo1 actually switches the device over into standalone thermostat mode. If you set 0 here the device will remain in 1Wire mode.

When the device is in thermostat mode it can't communicate over 1Wire anymore unless a specific reset sequence is performed. The read command in the code automatically performs this sequence if the device doesn't respond. It will mark this with ".." so if you see .. .. .. .. it means the device isn't responding despite that and you should check your connections :)

As always, leave a comment if you end up building this.

USBasp

Just made an USBasp. It's a USB AVR in-system programmer project by Thomas Fischl. Used the PCB by J.A. de Groot found on the USBasp project page. Had to add 2 missing zeners, but other than that the build was straightforward and problem-free.
This programmer handles USB communication in firmware on an AtMega8 or 48.


Tested with ATTiny2313 and ATMega8 sofar. Works fine.



No need to bother with the LPT port anymore.

Overcomplicated Battery Protector Take 2.

My second take on the battery protector.
The way it works now is: I added a simple monostable relay. The protection circuit itself is powered through that relay. Basically when connected to the battery, nothing happens. There's a push button switch between Battery + and the relay coil end designated to be the positive. When the button is pushed the relay switches on momentarily, the circuit becomes active and if the voltage is above threshold the FET continues to hold the relay on when the button is released. If not then there's nothing to keep the relay on so it just switches off.
Since the FET is only driving the relay coil there's no heat dissipated there.
Also no chance of oscillation: When the voltage dips below threshold the relay cuts out and that's that.
Possible unnecessary and overkill, but whatever. It works.
According to my cheapo DMM It consumes 50milliamps when holding the relay on, which translates to about a 0.6W average. I can live with that.

DIY Speakers Part 2.

Done with them for now. Got a Tripath TA2020-based Chinese (Lepai) amp off eBay to use with these. Should get here in a couple of weeks. I chose this amp because: 1, The amplifier chip itself it worthy to be one of the 25 chips that shook the world according to IEEE Spectrum. 2, There is a thread on diyAudio detailing several all-around improvement mods for this particular amp. But most people seem to agree that it sound at least "pretty good" even without them (Though that certainly won't stop me from doing them). 3, It was cheap ($20 shipped)

Should be interesting to compare to the TDA2004 board I used for testing. Which I could describe in one word as: unspectacular.

DIY Speakers Part 1.

Housing made out of scrap (not to mention low quality, and pretty old) MDF from some trashy office furniture. Cut the boards out with a jigsaw, screwed them together, filled the gaps with wood putty. Gave it a run with a power sander for good measure.


Upholstered them with some white fabric. (I know it's a bad choice, but it's what I could get for free and I don't intend to spend much on this ) I haven't decided yet whether I'll paint it over black.

These are the speakers that will go in there. They're some leftover "5way" car speakers with a "ProAudio" brand.

Lead-Acid Battery Overdischarge Protector

Don't really have a schematic for this small project. I had an MC34161 (datasheet PDF link) glorified comparator voltage monitor IC in an old inverter PSU that I decided to re-use to protect a single SLA battery against over-discharge. Only one voltage monitor channel is used, and the chip is configured to be an overvoltage detector. The open collector output it pulled high with a random resistor and it's connected to the gate input of a random N channel FET. The MC34161 is calibrated with a precision trim-pot (not the one in the picture, I replaced that because the threshold would crawl 0.5V just by blowing on it :) ) to detect overvoltage at around 10.6V. At which point it'll switch the FET enabling the output terminals. If the voltage sinks below 10.6V it'll disconnect the battery from the output. (overvoltage condition disappears)

I actually haven't tested whether the chip's built-in hysteresis is enough to prevent oscillation yet (large load on battery -> battery discharges below 10.6V -> battery is disconnected -> battery voltage rebounds ? -> ? above hysteresis threshold -> repeat until something melts/breaks/explodes)
This is obviously something to avoid. It's probably not a issue for me because it doesn't matter for the devices I'll be powering off this battery. (I'd just realize what's going on and power them off) but it's something to keep in mind in case anyone builds something similar based on this chip.

UPDATE: Ok, you probably shouldn't build this unless you use an extremely low RDS-on FET or something. I'll be modifying this to work as an undervoltage detector and to use a bistable relay when I have the time. This'll also have the advantage of solving the hysteresis issue (the relay will just switch off when the undervoltage detector triggers it). If I set up the chip as a dual detector I could use it to switch the relay back on when the voltage rises above say.. 13 volts. I'll either do that, or just add a "reset protection" button if I'm lazy. (I'll probably just do that)

Fonera 1-wire continued... The Display

OWFS supports HD44780 character LCDs on the 1-wire bus. The most common interface is with a DS2408 8-pin GPIO to 1-Wire chip. The interface from hobby-boards runs the display in 4-bit mode, so 3 GPIO lines are left over for buttons and whatnot. I based my design on their schematic.


The SOIC8 is an NE555 in monostable mode. It provides timed backlight control. When a button is pressed the backlight will stay on for about 20 seconds then turn off.

OWFS (theoretically) supports this interface with the LCD_H module.
In ideal-land I'd hook up my hobby-boards clone and type
printf "Hello World">/ow/29.xxxxxxxxxx/LCD_H/message
and that would actually work. Well, as it turns out: Not so much.

It would seem that OWFS 2.7p13-1 has a broken LCD_H module. I've tested with 2.6.5 in an Ubuntu VM where it worked fine. With 2.7p13-1 however, all I got was garbage for the output.
There's a bug report here, that may or may not describe the same issue. If it does then it would seem that the bug has been ignored for several years. Nice!

Problem is I'm not ready to devote days to building a crosscompile environment for mips/OpenWrt because of some random bug. Since byte-based access to the GPIO-port worked it was faster to just re-implement the protocol. Which I did.. in PHP.. (it's just a testing script at this point, so adapt as needed if you wish to use it. Should be easy to figure out.)

Fonera 1-wire continued.. The Hub

5port dumb 1-Wire hub. Made from a 5-way RJ11 splitter.
I also added a DC connector to allow powering non bus-powered devices from the same RJ connectors.
PIN1 is external Power
PIN2 & 3 are 1-Wire and GND

Hot wire glass bottle cutter

In a surge of boredom I did a search for glass bottle cutting. I found this page. That shows a hot-wire bottle cutter. I cloned the design. It's basically a laminate board with a couple of screws and nuts, a spring and some NiChrome wire.

I used an old AT PSU to heat up the wire. The 5v rail is loaded with a 20-something ohm 10W resistor that can't be seen on the photo. (A load on 5V is needed to stabilize the 12V rail)

It works reasonably well.

Precision depends on how straight you can get the wire around the bottle without shorting it. The rim still needs a lot of tedious work to complete a viable drinking glass which I'm definitely too lazy to do. But it was worth the 5 minutes it took to build it.

I might come up with a rim auto-sanding contraption in the future.

Fonera 1-wire MicroLAN extension

I wanted to add a 1-wire bus to one of my Foneras. I already flashed it to DD-WRT some time ago, but realized that I can't disable the serial system console or the shell so there's no way to use the serial port for anything else. I searched around and it seemed like Gargoyle might be a better solution. It's a firmware based on OpenWRT. I flashed it, only to realize that the same restriction applies to the system console part. It seems all Fonera firmwares ignore the kernel command string set in RedBoot and just work with a hardcoded one. Which usually contains console=/dev/ttyS0 making the serial port useless.
A post on the Gargoyle forums refers me to setconsole, which isn't included in either version (stable/testing) anymore. I tried with several setconsole compiles of my own only to get an assortment of error messages. Because compiling a whole new firmware is entirely too much of a pain for something as simple as freeing up a serial port i ended up unpacking the kernel image and modifying the hardcoded string with a hex editor. Then repacking, padding, and flashing the modified image to the Fonera. (modify the string to console=/dev/null)
The LZMA SDK from 7zip can be used for the compression.
Make note of the kernel image size before unpacking, and pad with null bytes to that exact size after repack. This is not optional. Flashing will fail otherwise.

This worked, so I proceeded to disable the shell in /etc/inittab making the serial port usable again.
Thanks to the OpenWRT roots the rest was pretty easy on the software side.
the commands
opkg update
opkg install owfs
opkg install owhttpd
gave me all the tools I needed to work with 1-wire.
And ..
opkg install php4-cli
opkg install php4-mod-gd
gave me what I needed to code up web interfaces.

The CLI compile is required because the CGI one is Apache specific. Gargoyle has a small httpd lacking most of Apache's features. The CGI compile will error out however the CLI release can be made to work. There are certain annoyances like a missing $_GET/$_POST and the requirement to send a \n before page content and after headers, but they are not that serious.
( to fix get: parse_str($SERVER["QUERY_STRING"],$_GET) )

On the hardware side I opted to use a DS2480B 1-Wire Line Driver chip. This chip is used in the DS9097U adapters so it's basically the standard in UART to 1-Wire interfacing. I wanted to include fancy things on the board like a software controlled power switch and an activity LED, but in the end I abandoned both. The power switch didn't work out, and the LED was pretty useless due to the low activity on the bus. Because of this the original board is ugly and overkill. It is however extremely simple to hook this chip up. There are no external component requirements. POL VPP and VDD needs to be connected to together. Rest is obvious. (TXD,RXD, 1-w DQ and GNDs to appropriate holes/solderpads on the interface board, then TXD,RXD,GND to Fonera, and DQ and GND to some sort of connector for the 1-Wire bus. You can also get the 5V for the interface board by soldering to the Fonera's PSU connector)
Here's a simplified interface board:

eagle brd here

I opted to use an RJ9 connector simply because I had one on hand, and because it fit right next to the Ethernet's RJ45.

You might want to consider including the Fonera's 5V on your connector. It could become handy if you want to attach non-parasitic devices in the future. I opted not to do so. I will be building a "powered hub" out of a 5way phone-line splitter later.

For testing I used iButtons hooked up as seen below.
RJ11 Blue dot receptor -> Ghetto RJ9<->RJ11 cable -> Fonera


Simple OWFS testing: (connecting and removing iButton)


Success!
Now I have a LAN/WLAN/MicroLAN router :)

EEE Car Charger

I have an Eee 701 that I find extremely practical to have around. About a week ago I needed a car charger for the machine, and decided to buy one. There doesn't seem to be much choice in the matter. You either go with Asus's $50+ thing or get a chinese one. I got a chinese one, which lasted all of 30 minutes. It got extremely hot, then blew the fuse. I replaced it with a new one, which it immediately blew out as well. When I got home after some considerable trouble I took the damn thing apart (It was partly glued, yay.) and was staring down at a switch-mode DC DC converter.

I tried replacing pretty much every component besides the PWM controller chip but it still kept blowing the fuse.

I gave up shortly afterward and decided to build a PSU myself. I wanted to use things I had on hand so I went with the MAX668 that I used in the Laptop powered from SLA project. This is a Step-Up converter but it supports a SEPIC topology which would make it work in both Step-Up and Step-Down modes.

I designed the board, carefully hand-wound the SEPIC dual-power inductor, soldered it all together




And failed miserably in my attempts to get it working right.

I've tried 3 different FETs, 5 different inductors (both dual windings and separate cores), 4 different filter cap configurations, 3 different SEPIC coupling capacitors and 3 different Schottky diodes. I've replaced ALL of the components at least three times, yet my best result was an over 4Volt drop with a 2 Amp load. To sum it up in one word "Useless". At this point I wasted 2 days trying to track down the problem. I've compared the board layout to the schematic, and the schematic to example designs about a dozen times and I couldn't find the reason for the drop. I was not ready to waste any more time on it.

Determined to not waste more money either, especially on a chinese charger that might last under an hour again I asked around and managed to get a UA78HGASC part. This blast from the past is an adjustable 5 Amp Low-Drop-Out Linear Regulator in the TO-3 package. I've seen it mentioned in hobby electronics publications from 1987. From what I understand it's also a relatively rare part.

For anyone who'd slam this because LDOs are inefficient consider the following.
According to this LDO efficiency equation:
% Efficiency = [(V_OUT) / (V_IN)] * 100
The efficiency of this circuit, if we use 13V for Vin (as a voltage average for SLA) and 9.8V for Vout, is around 75%.
Theoretically a 90% efficiency can be achieved with switching regulators. A measured efficiency of around 80% was achieved by the good people who've come up with the reference designs for MAX668 SEPIC configurations. (The efficiency also declines as the load increases, but let's not think about that) So around 80% using Ultra Low RDS-On FETs, Ultra-Low ESR capacitors and taking all board design rules and recommendations into account. I have neither of those custom components, and buying them would cost more than a chinese car charger. Not to mention that I can't even BUY the kinds of ceramic caps that most of the reference designs require. It is because of this that I probably can't achieve efficiency even close to 80% with a home-built switching regulator. BUT let's say I did. Even then is 5% worth all the extra trouble/time/components?

So back to the LDO.
I had the perfect project box for this. The heat sink fit perfectly on top of it. I soldered it all together. It only needs 2 small caps and 2 resistors, as opposed to all the things a switching circuit does. I just put those on a piece of stripboard. Set the voltage. Did a load test at 50Watts. Voltage Drop.. 0.06 Volts. Things were looking great. I plug it in and... the Eee doesn't charge.

At this point I was close to setting both attempts and the Chinese charger on fire but on a whim I measured the voltage on the SLA battery I was using for testing and I got 14 Volts. Wait.. what? 14Volts is too much even for a fully charged AGM SLA, and this one was nowhere near fully charged.

So after the inevitable realization that my multimeter is measuring around 1.5volts more than the actual voltage of things because it's battery was dead, and raising the output voltage of the regulator accordingly the Eee gave in and started charging like it should. Finally.. after several days I had a car-charger. I don't know about other laptops or netbooks but the Eee 701s can run off their chargers with the battery removed. This also effectively turns this charger into a way to run the Eee off an SLA battery directly.

I feel that I should add a little bit of info on the Eee charging voltage.
On the sticker, and on the AC charger it says 9.5V @ 2.135A.
This is wrong. In fact something around 9.8 is preferred, and that's still 0.2Volts LESS than the AC charger outputs while running the Eee directly off it, without a battery.
Other people have also confirmed that their AC chargers drop only to around 9.8 - 10 Volts while powering the Eee. In fact, it seems like anything below 9.8 is insufficient (Eee shuts down, charging led blinks on-off). Best way to make sure is to measure the charger voltage while running the machine off it. YMMV but 9.8 worked out perfectly for me.

The end result:

Water Pipe Anti-Freeze Heating

UPDATE:

Check out V2 of this project here. Simpler and much less overkill :)

---

We have 2 buildings on our property: the house and an office building. Between the two is a semi-open garage. Through this garage runs the water pipe to the office building which is exposed to outside temperatures.
The usual procedure for this pipe during winter was to completely drain and disconnect it so that it doesn't freeze in. This has become somewhat of a pain as I needed the water during winter so solving this has become a project of mine.
I managed to acquire a bit of heating cable that I could run in pair along the length of the pipe.
One "channel" at 12volts came out to about 47ish Watts for the entire length of the cable.
I wasn't sure at first if this would suffice, but I gave it a try. The heating cable was taped to the underside of the pipe with PVC tape and copper tape where I assumed it would matter (I would've done it with copper tape along the entire length but it's expensive :) ) The pipe was then covered in foam insulation.


A DS1621 temp. probe was installed (marked with yellow tape on the picture) on the top of the pipe. (The heating cable running at the bottom should ensure that the probe isn't being heated directly by the cable, which would make measurements useless.)
Both the cable for the probe and the heating cable go into the boiler room that is accessible from the garage.
I designed a controller from what I had on hand. An old ATX PSU and an ATMega8(overkill). The AtMega is powered by the standby voltage of the PSU (5VSB). PSON is connected to PORTB.0 so the AtMega can switch the ATX PSU ON or OFF depending on temperature. (The PSU turns on when PSON is pulled low). The heating cables are hooked up to a 4pin Molex Connector.

I admit I didn't make exact measurements of the pipe temperature with the heating on, but the day after I finished this project we had -16 degrees Celsius and the pipe didn't freeze in. Good enough test for me, as we didn't have anything colder in the past 10 years. The controller sits on top of the ATX psu
in a cheap electrical box. 2 LEDs were installed, one shows that there's standby voltage, the other is a heating status / error led.



I use only 1 channel for now, since it seems to have been enough to keep the pipe from freezing in at -16C. The other channel is used as a load for the 5v rail of the PSU (at 5V it doesn't provide much in terms of heating) As it turns out, the 5V rail has to be loaded to stabilize the 12V rail, otherwise there will be huge voltage drop.

The DS1621 was actually a thermostat IC and I was considering using it in a standalone configuration but sadly that can't be done as the thermostat
functionality doesn't start until a "Start Convert" command is sent to the chip through I2c. That meant a microcontroller was mandatory, so instead of
relying on the internal functionality of the chip I just implemented the thermostat function in code. This also meant I only had to run 4 wires from the
temp probe instead of 5, and I had 4 wire telephone cable lying around.

One could use an Arduino for this, or any other dev board. Since I had an ATmega8 lying around, and my 2051 programmer was out of commission I used that. If I need the Mega8 in the future I'll probably end up replacing the controller with a 2051.

Update Feb. 01:

A few days ago I noticed some weirdness while running the tap, so I checked on the controller. The LED was flashing meaning there was an error condition, and the heating was off. The pipe was beginning to freeze in. There were 2 possible places in the code that could produce that. Either the temp. probe didn't respond or a measurement returned a value greater than 25C (which would be a bad measurement as temperatures were mostly sub-zero that day). It was probably a random hiccup as it continued to work fine after a power cycle. This however convinced me that the code needed to be more resilient. So now it retries if the temp. probe doesn't answer or if the measurement is out of bounds. Only after 3 subsequent failures does it go into the error condition. I also added a speaker that beeps out an error code if that happens, making it easier to notice. I took a picture of the controller after I reflashed it with the new version. It has become somewhat of wiring chaos, especially now that the speaker was added. The board design is a modification of this project. I didn't intend to use it here. It just happened to be the easiest solution at the time.


And the speaker on a strip of mounting tape:


You can find the controller code here. (BASCOM/AVR)

SATA Power Switch

There is a useful project at this site that I duplicated. It's a switch that selects between 2 SATA HDDs (it switches power between two SATA power connectors so that only 1 is active).
It's great for testing alternative operating systems or having a quick-boot surfing system on one hdd and a work related system on the other for example.

The build process is pretty much outlined on the site. Here's how mine looks using a big old 2 deck rotary switch


I had to saw quite a bit off the shaft and spraypaint the knob for it look passable. This is how it looked beforehand:

Chromium Silver: UI Tweaks for Chromium

I believe browser UI should be all about choice, as there is no singular solution that will fit everyone's needs. Power users will usually have their own preferences and tend to set up their browsers a specific way to suit their needs, and allow for more comfortable use. This is something that is sadly lacking in Chrome / Chromium. Even in my FireFox session I have completely customized tab handling, installed an extension to remove unified navigation buttons, (that Mozilla thought each and every one of the their users will like, and decided not to include a disable setting in about:config for), and another one to disable the newfangled location bar, that I found to be pretty useless as well. With 45-55 thousand downloads for each of those extensions there are obviously quite a few people around who agree with me on this matter. These numbers may be relatively small compared to the entire browser user-base, but ignoring the preferences of 50 thousand users may not be that wise of a choice either. On the other hand there are probably users who've come to like these new features and this is fine. It's exactly why users should be allowed to enable/disable features that impact user experience, and customize behavior as they like. Doing this should not be seen as the inability of the UI designer to create the "Perfect UI" (there is no such thing), as this Chromium blog entry seems to imply.

Chromium, by default has close buttons on every tab, unless the tabs reach a certain minimum width, then the buttons are removed except from the active tab. The user can't change anything on this behavior, however for me on-tab close buttons are an irritating annoyance. The first thing I do in FireFox if I set up a new session is disable them. Not being able to do so in Chromium, was really frustrating. I've asked around and for example, a friend of mine prefers on-hover close buttons, and another likes it the way it is. It seems people like different things! Pretty shocking... :) So I've decided to pull a Chromium source tree, add some tweaks and recompile. The end result is what I named Silver tweaks. This allows users to

• enable/disable the new tab button
• enable/disable an FF-style close tab button at the end of the tabstrip
• customize tab close button behavior
• customize "Open Link in New Tab" behavior
  

Tab close button behavior options are:

• default Chromium (as explained above)
• close buttons on every tab, always
• no close buttons on tabs, ever (my preference)
• close button on active tab only
• no close buttons unless hovering over tab with the mouse

Another thing is when you choose "Open Link in New Tab" in Chromium, it will insert a new tab after the current one. I also found this to be really irritating, as I tend to have blocks of tabs that I don't wish to alter, at the front of my tab strip, one being my RSS reader, and I'm used to opening links from there at the end of tab strip, so I've also added an option to change this.

"Open Link in New Tab" placement options:

• default Chromium (insert after originating tab)
• add at end of tab strip

This should cover a wide range of preferences, and make using the browser a lot more comfortable, for "nitpicky" people like me.
Configuring the tweaks isn't really user-friendly (you need to edit a file with notepad) and I don't really intend to change that myself, but please feel free to, I've included my source patches inside the archive.

The settings used for the screenshot at the top are:

"silver": {

"close_tab_button": true,

"link_new_tab_autoactivate": false,

"link_new_tab_place": 1,

"new_tab_button": false,

"tab_behaviour": 1,

"tab_grouping": false

}

After unpacking please actually READ readme.txt, otherwise you won't find where to change the settings :) !! Everything's in the readme !!

Last stable build: --> DOWNLOAD <--

Updates:

Project Abandoned as of May 2011. Moved back to FireFox a couple of months ago. Haven't regretted it.

Nov 28 2010 : Updated patches for current git pull. Did not test anything besides the settings I use. No binary release. Patch can be downloaded here

Feb 4.: Build based on a Feb 4 pull. Found out that a patch on Jan16th that was later thrown out of WebKit fixed a crash bug. Reintroduced the pertinent part of said patch to the build. (or more simply put.. commented out a line) with that, the build seems rock solid. Link updated.


Feb 1.: Rebuilt from a GIT pull on Feb 1st, fixed closetab button jumping around in certain conditions. Link NOT updated. Build NOT as stable as previous one. Link for testing is here.
Jan 17.: Rebuilt from a GIT pull on Jan 16th, Main link is for this release. (Build solid and stable on XP) (link)

Aug 9. : Rebuilt from SVN 22737, link updated (I see some speed improvement in this build) (link for this older release)

Aug 2. : Added new-tab autofocus setting, rebuilt from SVN 22243, link updated

If you found this useful, please leave a comment.

Chromium Silver now uses the default Chromium theme due to general laziness.