Archive for the 'General' Category

Setting up Remote Nightly Backups

Published on August 25, 2010 in General. 0 Comments

Unfortunately, my hosting provider had a hardware failure and I lost quite a bit of data (everything got rolled back to an 8/17 backup), so I decided to use dar to take nightly differential backups of my home directory (as well as regular backups of various other dirs and databases).

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.

DIY Etching of QSOP Traces

Published on August 16, 2010 in General and Projects. 0 Comments Tags: , , , .

Last week, I finally found some current sinking LED drivers that would work well with the LEDs that I chose for the wall lamps.  The TLC5926 has pretty much exactly the capability that I need to power these LED arrays.  Because the LEDs have a common anode instead of a common cathode, it is necessary to use constant current sinks instead of sources because they sit between the LED and ground.

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.

Replacing Leaky Caps in a 1992 Dodge Stealth

Published on August 11, 2010 in General and Tutorials. 0 Comments Tags: , , , , , , , , , .

My mom drives a 1992 Dodge Stealth (Mitsubishi 3000GT). Despite the fact that the car is almost 20 years old, it still runs pretty well, with the occasional exception. For example, recently, the window regulator (on the driver’s side) broke and had to be fixed. Then, a few weeks later, the car would stall shortly after starting it, making a clicking noise in the process.

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.

Free VoIP Calling using Google Voice, Antisip, and IPKALL (and a CLI utility)

Published on July 18, 2010 in General, Projects and Tutorials. 7 Comments Tags: , , , , , , , , , , , .

I’ve been experimenting with my FreeRunner recently and came across some articles about free VoIP.  As it turns out, thanks to Google Voice and a few extra services, it’s possible to both receive incoming and make outgoing calls completely for free.  After setting these services up, I wrote a CLI utility that combines a Python Google Voice framework with Linphone in order to make the task of placing a call easy.

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.

Backyard Wildlife

Published on July 11, 2010 in General. 2 Comments

There was a chipmunk outside the window today, so I decided to start a new an album of animals in my backyard.  Not too much there yet… there’s a photo of some birds and another of the black squirrel I took back in January.  Last week, there was a rabbit sitting on the walkway.

And then there was this little fella today:

Installing Linux on the MSI X-Slim X340

Published on June 23, 2010 in General. 1 Comment

MSI’s X-Slim laptops are slowly gaining popularity because they are affordable, lightweight, and very mobile.  I purchased an X340 from TigerDirect recently because I couldn’t pass up the great price   Mostly, I purchased this laptop for the excellent battery life — the laptop uses a high-density lithium polymer battery and has a ton of power-saving features that shut off peripherals when you don’t want them.  It’s an excellent 13″ laptop with plenty of power for my mobile computing needs (SSH and Firefox).

Installing Linux on just about any hardware nowadays is easy.  Things have changed a lot since I first started with kernel 2.4 — I remember spending countless hours trying to configure my hardware to work properly.  But now, you rarely need to get under the hood to get your hardware running flawlessly, no matter the distribution that you run.  The thing is, I like getting under the hood and fortunately, this laptop has given me a chance to do a little bit of that.

MSI is just enough of an off-brand name that some of the hardware they use is only partially supported by Linux.  The laptop is built on an Intel platform, so all the most important devices work perfectly well out of the box, but a few things: ACPI, the touchpad, and the keyboard, need a little tweaking to work effectively.

This is a short guide with scripts, configs, etc. attached that aims to get as much of the hardware on the X340 working as possible.  I’ll start by describing the really broken stuff and then later provide suggestions for improving battery performance, etc.  I’m writing from the Arch Linux point of view (BSD-style init vs. SysV-style, etc.), but everything should apply to all distributions, possibly with some minor changes.

Brightness

Immediately after installing Linux, you’ll probably notice that the brightness keys don’t work.  I think what’s happening is that when your computer boots up, ACPI hands over brightness control to the operating system.  Some laptops (e.g. Dell) still have hardware support for changing brightness, so no matter what OS you’re running, you can always press the brightness up/down keys to adjust your screen.  The X340 doesn’t seem to support that, so we’ll have to create a script to adjust the brightness from within the operating system.

You can get and set the current brightness setting in /sys/class/backlight/acpi_video0/brightness.  So, I wrote a quick script that sets the brightness in different ways:

http://jwcxz.com/other/msi/brightness.sh

I stuck this script in /etc/brightness/brightness.sh.  Supported functions: bup (increase brightness level by 1), bdn (decrease it), blo (set to minimum brightness), bhi (maximum brightness), bset # (set to some value #), badj # (increase or decrease by #), bget (return the current brightness).  You could source this file as root and run the functions, or you can just give them as arguments to the script.

I’ll get to configuring the brightness keys to work with this script in a minute, but if you would also like to be able to use the functions as a regular user, you can modify sudo to let you issue brightness commands without a password by doing sudo visudo and adding the following line:

yourusername ALL = NOPASSWD: /etc/brightness/brightness.sh

Then, you can define some aliases in your profile:

alias bup="sudo /etc/brightness/brightness.sh bup"
alias bdn="sudo /etc/brightness/brightness.sh bdn"
alias blo="sudo /etc/brightness/brightness.sh blo"
alias bhi="sudo /etc/brightness/brightness.sh bhi"
alias bset="sudo /etc/brightness/brightness.sh bset"
alias badj="sudo /etc/brightness/brightness.sh badj"
alias bget="sudo /etc/brightness/brightness.sh bget"

Keyboard

The keyboard is a bit trickier — there are several things to do.  First, we need to get HAL to recognize the extra keys on the keyboard.  For example, if you press the brightness up key (Fn-Up) and then do dmesg | tail, you’ll see an error message telling you that the scancode hasn’t been mapped to a keycode.

Working off of the keymap entries for other MSI computers, I built an almost-fully-working keymap for the X340.  It might work for other X-Slim laptops too, especially for the X320, X350, and X360.  You can grab that here:

http://jwcxz.com/other/msi/10-keymap-msi.fdi

Stick that in /etc/hal/fdi/information/10-keymap-msi.fdi and restart HAL.  I was able to get all of the special keys working with a few caveats:

  1. The keys labeled with [hw] have a hardware action.  For example, the bluetooth key actually turns the bluetooth module on and off.  So, if you choose to bind something to that key, make sure that you are willing to toggle bluetooth on and off.  A good thing to bind to these keys are status indicators so that when you toggle bluetooth on, an icon or something lights up.
  2. The same thing applies to WLAN.  It toggles the RFKILL bit in hardware.
  3. Fn-F2 (video mode switch) and Fn-F11 (some other WiFi button — maybe for bringing up the connection window?) seem to be “missing” — when I press either one of them, I don’t get an error about a missing keycode, but I don’t get a keycode either.  After I look into this issue, I plan to submit a patch to HAL in order to get this keymap included.
  4. Fn-F5 (economy mode) currently maps to keycode 126, which is plusminus.  I need to remap that scancode to “battery” when I find it.

The next thing to do is to install some software to handle system-wide key bindings.  I like actkbd (AUR package) because it operates as a system service and therefore works even when you aren’t using X.  My /etc/actkbd.conf file is here:

http://jwcxz.com/other/msi/actkbd.conf

Finally, you may want to define some user-level keybindings.  For example, I switch escape with caps-lock and I also define the \| key (which is really less than/greater than when you press the key) that’s right next to the Alt key to be Super_R because I use the Windows key a lot and I think it’s more comfortable next to the space bar.  The xmodmap configuration file I use is as follows.

remove Lock = Caps_Lock
keysym Escape = Caps_Lock
keysym Caps_Lock = Escape
add Lock = Caps_Lock

keycode 94 = Super_R

I’ve also turned the menu key into left-click, but I’ll get to that in the next section.

Touchpad

I have to say, the touchpad sucks.  It really sucks.  I thought it wouldn’t be as bad as the reviews said — I assumed it would be possible to fine-tune things and so forth — but I was completely wrong.  First of all, it’s not made by Synaptics, but rather by a company called Sentelic.  The touchpad’s operation is really ugly.  Unlike with the Synaptics touchpads, you cannot move your finger on the sides of the touchpad to scroll; you have to place your finger at the corners and hold it.  That wouldn’t be so bad, but it’s not accurate at all; I can’t scroll for more than a few seconds even when holding my finger perfectly still.  Also, there seems to be no control over the sensitivity of the pad, and there’s definitely no “palm check” feature.  Supposedly, you can adjust the acceleration rate, but I haven’t been able to do that yet in Linux.

What I have been able to do is get rid of tap-to-click.  I didn’t want to get rid of it because I use it a lot–it’s much easier than pressing the mouse button.  But, because the touchpad is big and very sensitive, it’s easy to accidentally start clicking when you’re typing.

To get rid of tap-to-click, issue the following command as root:

echo 'c' > /sys/devices/platform/i8042/serio1/flags

I put this in /etc/rc.local so that it runs every time I start my system up.

I also used xbindkeys and xmacroplay (AUR package) to rebind the menu key to left-click by creating the following ~/.xbindkeysrc:

http://jwcxz.com/other/msi/xbindkeysrc

Other Stuff

The brightness settings, keyboard, and touchpad are the three big things to fix on the X340.  Everything else pretty much works out of the box.  A few minor points:

  • You’ll probably want to install and configure laptop-mode-tools.  This, along with the standard cpufreq and acpi packages can provide really nice battery performance improvements.
  • I recommend taking a look at Arch Linux’s laptop article on their wiki.  There’s lots of useful information there.
  • I had to add video=1366×768 to my kernel parameters list in /boot/grub/menu.lst because sometimes, my system would boot up and stay in 640×480.  I think the actual parameter string should actually be something like video=LVDS-1:1366×768 in case you keep an external monitor attached.
  • /etc/acpi/handler.sh is a good place to add hooks based on various ACPI events.  For example, when I plug the power cord in, I run cpufreq -g performance and when I unplug it, I run cpufreq -g ondemand.  I also have the following code in the lid change state: 
    if grep -q closed /proc/acpi/button/lid/LID0/state; then pm-suspend; fi
  • Unfortunately, unlike many other laptops, this one doesn’t trigger an ACPI event when you open the lid and the system is suspended.  So, you have to press the power button to wake the system up.

And that’s about it.  Everything else is just a matter of minor configuration to your preferences.  It’s not like the old days when you had to research all sorts of minor points in the kernel configuration and build your own kernels to support the hardware you needed, but for almost everyone, it’s probably best that those days are behind us.  Still, the opportunity to contribute even a few small improvements or findings to the open-source community is quite a valuable experience.

Up next: I finally start describing the plans for my FPGA-based audio visualization project.  I have them all written down in my notebook; I just need to formalize them a bit and start building.

Back from Spain

Published on June 5, 2010 in General. 0 Comments

Just a few days after getting out of school, I was off to Spain to see Madrid, Toledo, Seville, Córdoba, and Barcelona.  I took about 1000 pictures in total, but here are the halfway-decent ones (77 of them).

http://jwcxz.com/photos/es10

More Photos from Mem. Drive

Published on April 20, 2010 in General. 0 Comments

I know… boring and repetitive, but I took another walk along Memorial Drive today and brought my camera again.

Full Set

Next time, I’ll take a different route.  :)

Staffen SRX Fountain Pen

Published on March 29, 2010 in General. 0 Comments

I was feeling old-fashioned recently, so I decided to buy a fountain pen.  After a little research, I found xFountainPens, a retail site that promises high quality pens and ink for low prices.  For a grand total of $28 for a pen and a bottle of ink, I decided to take a chance.  I purchased a Staffen SRX Galaxie pen and a bottle of black ink.  I ordered it last week and it arrived, so the shipping was fairly quick (and free); it was also packaged well.  For $20, I wasn’t expecting too much; a pack of ballpoint pens costs almost as much nowadays.  What few reviews I could find for this pen were generally positive.

I was extremely impressed.  The ink flow is extremely smooth and even and the pen is a good weight–very comfortable to write with.  I’m a lefty (the curséd breed, I know), so my writing usually involves scratching up pages (because lefties have to push the pen across the paper and not pull it), but I had no trouble writing with it.  The ink is also quite nice: it flows smoothly, dries quickly, and doesn’t bleed.  One of the older reviews that I read mentioned a few weakness with the pen, including a loose cap, but I did not find any.  It was a $28 well-spent.

I decided to keep the pictures at their original 4000×3000 resolution to show off some of the amazing macro capabilities of my camera…

None of my classes this term really require writing…  The assignments are all accomplished via computer, whether they’re labs for my courses in communications and computer architecture, problem sets for my CS theory course, or the research paper for my class in urban history.  Yet, I still take notes by hand for the most part, because I find it’s faster.  And I also have lots of scratch paper in case I need to review my work later.

The other day, I got bored and tried to see what it would be like to write like a righty.  So, I did the obvious thing and started writing backwards (right-to-left with mirrored characters) with my left hand and I picked it up very quickly.  I’m still trying to develop the spatial skills that will allow me to mirror diagrams intuitively, but my right-to-left writing speed is now very nearly as fast as my left-to-right speed.  Yes, I do get this bored sometimes.

Anyways, the tl;dr is that this pen is really fantastic and I’m quite happy with the service from xFountainPens.

Photos from Memorial Dr.

Published on March 6, 2010 in General and MIT. 1 Comment Tags: , , , , , , , , , , , , .

Today was the first warm day in quite a while here in Cambridge, so I decided to go out (*gasp!*) and walk along Memorial Drive and shoot a few pictures with my camera.

For some pictures, I used my Tiffen Sky filter (blocks UV).  On others, I used my polarizing filter (also from Tiffen) to get bluer skies.  On some, I used both, but the vignetting was particularly bad…  I have to zoom in quite a bit (~3x) to prevent it, or I can just crop the picture later.

View the Full Set