Here is a simple script to remotely take a differential backup of one target server from another.
http://jwcxz.com/other/backup/servernightly.sh

This script is then run from the target server and can be run as a cron job without any modifications. The only caveat is that since this script is only designed to take differential backups, you need to take a full backup first with:

ssh $butgt "dar -c - -z -m 150 -R $butgtdir -q -K :"`cat $bukey` > `date "+$budir/$bupfx-%y-%m-%d_%H-%M.1.dar"`

from the other server.

All of the action happens on the last two lines (they’re just modifications from the recommendations on dar’s notes page). The first of these lines sets up dar_slave, which handles retrieving data from the reference backup to determine which files have been changed. The second is kind of weird since it has an ssh connection within another, but it just tells the backup server to instruct the target server to start taking backups. The backup is named prefix-year-month-day_hour-minute.1.dar. Typically, the differential backups are only a few megs for my home directory.

I’ve pretty much finalized the schematics for the wall lamps. They’re available as a PDF or as a gschem file (with a symbol for the TLC5926).

I chose TI’s TLC5926 to drive the LEDs. It is a constant current sink, so it can drive common anode LEDs. It has 16 output channels, each capable of sinking up to 120mA, and the outputs can be placed in parallel.

I decided to order some professionally-printed boards from ExpressPCB. I used their PCB layout tool (which runs fine in Linux under Wine) to create a board that could handle sinking up to a total of about 6A (roughly 2A per channel):

You can grab the PCB layout file here.

The 5926 is controlled by serial input, which should be a good way to get data over long distances. So, I wired up a DB9 connector with all of the relevant data lines that will come from the FPGA.

The boards should be here in a few days; ExpressPCB has really fast turnaround time for their MiniBoard service. I’ll end up with 6 of them, which will probably be useful if (i.e. when) I mess something up.

Unfortunately, the only ones I could find in stock were in TI’s ultra-small QSOP package (other manufacturers use the term “SSOP”).  After they arrived, I realized that it would be pretty difficult to prototype with them.  Eventually, I planned to order PCBs from ExpressPCB (more on that later), but I wanted a quick way to access one of the drivers I had purchased for testing.  I started by trying some 30-gauge wrapping wire, but neither of my attempts yielded anything decent.

I then began reading about DIY PCB etching.  I’ve wanted to try this for a long time now (I even had a bottle of ferric chloride just waiting to be used).  Unfortunately, I don’t have a laser printer.  We do, however, have an old, half-broken laser copier, which decorates copied documents with ghost images and random streaks.  I couldn’t find any information on manually etching QSOP traces (they’re so small that I was almost positive either the inkjet printer or the copier wouldn’t have the resolution required to print the traces out).  So, I tried it out anyways.  I managed to print a simple breakout design and transfer it onto  the board using glossy photo paper, heating the board with an iron (on its highest temperature) for about 30 seconds, putting the transfer paper onto the board, and then just holding the iron in place for about 5 minutes.  After transferring the toner, part of the paper came off very easily, but the other piece needed to be dissolved away in water.

Next, it was time for the ferric chloride.  It’s pretty nasty stuff, so we did all of the work outside.  After about 45 minutes of swishing the board around (we should have masked more of the PCB to speed up the process), the copper had dissolved, and I washed the masked traces  off with some acetone.

Finally, it was just a matter of soldering the device onto the board.  To do this, I soldered all of the pins together and then used a wick to wipe away all the bridges, leaving nicely soldered joints.  If you saw the pictures above, you probably noticed that the traces aren’t the right size!  This is a result of the old copier we have; it somehow slightly changed the paper size.  Fortunately, it doesn’t matter for this chip, which only uses the first four pins on each side individually, while the rest of the pins are all combined together to act as one big current sink.

Surprisingly, it’s quite possible to etch QSOP-sized traces using the “standard” method of DIY PCB etching.

I’m currently in the process of testing these drivers.  In the meantime, I’ve already made an order with ExpressPCB for the actual driver boards.  I’ll post those, along with schematics for the entire wall lamp soon.

It turns out that one of the most likely causes for this failure is due to leakage of the electrolytic capacitors on the engine control module (ECM), the computer responsible for sparkplug timing. ECMs go for anywhere from $800-$1000, so if you can identify this problem and replace the capacitors, you will have saved quite a bit of money.

So my dad and I took apart the car, following these instructions and extracted the ECM. When we opened it up, we found that two of the caps had pretty heavily leaked on the board, while the other two (yes, there were four in this car — not sure why given that every guide I’ve seen has shown 3) were probably okay. We decided to clean the board replace all of them. Unfortunately, the board was covered in a conformal coating, and we didn’t remove the coating before working, which lead to having to fix things very carefully afterwards. I think that in the end, this would have been the best way to do things.

1. Completely remove the conformal coating in the area surrounding (and under!) the capacitors using alcohol.
2. Desolder the capacitors from the board and use a solder sucker to clear the barrels. Note that you need a fairly powerful iron — a standard microelectronics iron won’t work as effectively as a larger iron with a chisel tip.
3. Clean the board with more alcohol to remove the fluid that has leaked from the capacitors. In our case, it hadn’t actually corroded the board yet, so it wasn’t necessary to repair the underlying PCB. But, it was important to ensure that all of the electrolyte was removed.
4. Ensure that the barrels are okay. It might even be a good idea to very gently sand them to reveal a fresh layer of copper.
5. Solder new capacitors onto the board. On our board, there were two 47uF @ 50V caps, one 100uF @ 16V, and one 22uF @ 50V. We used caps that were rated up to 105C. Use lots of flux.
6. Ensure that all electrical connections are good. Then, inspect to make sure that the caps are mechanically sound.
7. Clean off the flux with alcohol.
8. Apply a new conformal coating. We used acrylic coating, but maybe urethane or silicon coating would be better. As you can see below, I inspected the coating with a blu-ray laser (UV light works well too). I chose not to coat the capacitors entirely, but that probably would have been a good idea.

Removing the conformal coating before doing anything else really is a necessary first step. I thought it wasn’t, and that heat from my iron would lift the coating easily, but it didn’t. Otherwise, we were able to create pretty decent solder joints.

Here are a few pictures of the process. Unfortunately, I forgot to take more in order to really illustrate the removal of the conformal coating, but these are sufficient. In the first two pictures, we see the leakage of the electrolyte. Next, we see the result of cleaning the area around the capacitor (again, I didn’t remove the conformal coating before desoldering like I should have). Finally, in the last two pictures, the new capacitors are safely in place and the board is ready to be installed back into the car.

Anyways, I recently received four RGB LEDs from DealExtreme.  DX sells two types, so I bought two of each to determine which one to buy for my lighting project.  The first one I saw is on a star board and is cheaper than the second, which is enclosed in its own casing.

First, a few pictures:

These pictures were taken while the LEDs were being driven with very little current.  The star emitter is supposedly rated at 350mA for each channel and when each color is driven at this current, the LED is extremely bright.  I initially anticipated needing around 20-25 LEDs for each wall lamp, but I can see that 5-10 will definitely suffice.

I think I know why the star emitter is so cheap.  It’s labeled incorrectly.  The emitter, like most others, is common anode, meaning that the + terminal is common to all three colors.  The markings on the board are indeed wrong.  The enclosed emitter is also common anode.

Here’s a graph of some preliminary tests of driving the diodes at different voltages.  I pushed the enclosed one a lot harder, so I will need to set up a more rigorous test for complete characterization of the diode.  Also, I wasn’t able to heatsink the encased emitter, but stuck the star emitter on a big block of aluminum with some thermal compound.

As is fairly easy to see, the voltage curves look very similar between the two emitter models, except for the green channel.  However, it is also important to note that at 350mA, the first LED did not get anywhere near its rated operating voltage.  I haven’t pushed it far enough to see just how much current is necessary for it to be at is operating voltage, but the diode is certainly bright enough at 350mA.  I don’t want to overly degrade the diode by pushing it too far, or my wall lights will keep breaking.

I’ll probably go with the star emitter because it’s easier to attach a bunch of them to a heatsink block.  I’ll definitely need some kind of diffuser for the lamp, though.

The enclosed diodes are great for custom LED projects where you only need one or two of them; I wouldn’t recommend it for creating a compact array, though.  I might use them in my computer case or something; I could make them change color depending on processor load.

To me, that seemed like counterintuitive behavior, so I wrote up a quick patch that breaks out the window-status-alert-* style into three new styles: -activity, -content, and -bell.

You can grab the patch here.  If you run Arch Linux, you can get the PKGBUILD for tmux-cvs with the patch applied in the AUR instead.  I will also submit this patch to the tmux devs.

The problem was that I didn’t have an LCD to play with, so I had to settle for something slightly different; I wrote up a quick block to display the FFT data on my trusty Tektronix 335 oscilloscope.

There are basically two parts to the modification: first, I created an 8-bit DAC resistor ladder so that I could represent the intensity of each frequency of an FFT as an analog value.  Secondly, I created a low-frequency clock line that changed with each transition to a new frequency.  Finally, I just needed to trigger on the clock line with the oscilloscope to be able to view the full FFT.  This is easier to explain with a picture:

This FFT from an audio clip shows a large low-frequency component and a smaller mid-range component.  I tried playing some sine waves, sawtooth waves, etc. as well and the output was pretty accurate.  Here are a few pics of my setup (yes, I’m really bad at board layouts):

There are still a few major problems that I need to work through.  The biggest one is due some pretty painful noise coming from the clock lines and what looks to be my computer.  The latter can probably be solved by implementing a decent filter, though I’m not sure how the other project’s designer had so much success with his setup.  The other sources of noise seem to be coming from the clock lines and other lines around the board.  These can be solved by properly implementing this circuit on a PCB like the author did.  I’m seeing a lot of strange low-frequency noise in the FFT as well (the quick fix was to just remove the lowest few bars from the FFT output).  In addition to solving the noise problem, I need to fine tune some of the delay values I have for oscilloscope output to make it look better.

I’ll have code and schematics up in a few days.

Work on my lighting system begins tomorrow. 

Getting free VoIP

You need three things: a Google Voice account, an Antisip account, and an IPKALL phone number.  Go to each of these websites to create them.  For Antisip, you can use your Google Voice number for the PSTN Phone.  For IPKALL, you’ll need to provide the following information:

SIP Phone Number: [antisip username]
SIP Proxy: sip.antisip.com

After some time, you’ll receive a Washington state phone number.

Now, open up Linphone using either the GUI or the CLI client (probably easier with the GUI).  In the preferences of the GUI, there is a tab called “Manage SIP Accounts;” go there.  Add a proxy account with the following information:

Your SIP identity: sip:[antisip username]@sip.antisip.com
SIP Proxy address: sip:sip.antisip.com
Register at startup: yes

Now, Linphone should register.  You can try calling a SIP echoline at sip:*010600@ekiga.net to see if things are working.

Putting it all together

Lastly, we want to be able to make free calls to regular phones, too.  This is where the IPKALL number and Google Voice come in.  Antisip only allows incoming calls.  When you call a number from Google Voice, it first calls you and then calls the other person, thereby acting as a link between the two connections.

So, add the phone number you got from IPKALL to Google Voice and try calling a phone number from the Google Voice interface.  It should call your SIP client first and then call the other number.

CLI App

To make this process quick and painless, I wrote a quick Python script called gvcall.  Basically, it makes the process of calling a number from your computer as painless as gvcall 5555555555.  You can also use your non-VoIP numbers as well.

And then there was this little fella today: