Fixing a TDS754D

For those that don't know, a TDS754D is a pretty cool oscilloscope - when it works. Mine died this week so after being quoted $4300 to fix a $5000 machine (according to current prices) I decided to pop the lid and take a look. That and the fact that no else but Tektronix was willing to service it.

The problem was that the scope would randomly reboot and the screen would go black after a while. It would also not reboot once it had been running for awhile. But once it had cooled off for a while it would start up and promptly reboot a short time later. I managed to find a service manual on the web and started to work my way though it but I quickly decided that the steps outlined in the manual were going to work in my case.

I was pretty sure it was a power supply issue so I started to probe the power supply voltages and found that the 5.1V VA and VB supplies were 4.7V or 0.3V below the allowable limit. So now I'm thinking that the power supply is shot but I figured that I'd give it another try by reseating all of the cable connectors for the power supply. Powered it back on and like magic the voltage rails were now at 5.0V! The scope is stable now but I'm pretty sure that I'm going to replace the cable and maybe the connectors too. But if I start replacing connectors then I might as well fix the power supply too. I'll report back when I have more details.

Backing Up Subversion to Rsync.net

I've started using subversion to store all of my data, documents, photos, etc and I wanted a secure offsite backup that was easy to implement. After a bunch of trial and error, here's what I came up with:

1. Create a subversion respository at .
2. Create a post-commit hook to dump the current revision, gzip it and encrypt it.
3. Rsync the encrypted files to an offsite backup provider like rsync.net nightly.

Here's the post commit hook script I use:

REPOS="$1"
REV="$2"

# dump the repository, bzip it and encrypt it
/usr/local/bin/svnadmin dump "$REPOS" --revision "$REV" --incremental \
| /usr/bin/gzip -c \
| /usr/bin/openssl aes-256-cbc -salt -pass pass: [password] \
> [backup directory]/commit-$REV.gz.aes

Some points worth mentioning:

1. This backup method probably isn't suitable for a busy subversion server.
2. Use gzip instead of bzip2. I tried bzip2 at first, but it was waaaay to slow.
3. openssl encrypts data way faster than gpg (which I also tried at first).
4. Change [password] to something long and tricky - I specified it on the command line to keep things simple and because I trust this host (I'm the only user). However, in a multiuser scenario ps will show your password so you should use an environment variable or something.
5. You end up storing data twice which sucks. If you don't like that you could scp the encrypted file at every commit, but then every checkin will stall for the upload. I regularly checking 10MB+ files which take awhile to upload over DSL, which is why I rsync the data in a cronjob instead.

When you need to restore the server, all you need to do is download each commit, decrypt it and concatenate all of the files into 1 big dump file or load each dump file in sequence. Because I used dump files you don't have to worry about OS or CPU compatibilities when restoring.