Well, some good news came from one of the cluster nodes going down at work: I get to replace the totaled node with two new nodes that each take up half the space, have several times the processor cores, and more memory than all the other nodes on the cluster put together.

The parts should arrive soon. I'm psyched! (Except for the fact that I'm stuck with putting CentOS 5.5 on those systems... Gross.)

~ Brad.

I should really start a video blog. I could call it:

"WHY MURPHY, WHY????"

So today I had to fix issues I've been having with our network-attached storage (NAS) at work. The unit mounted just fine on my windoze and gentoo systems, but wouldn't mount on the system we needed to mount it on during backups. Turns out it was a simple command-line issue, and the drive mounted up just fine once i changed \\\\host\\share to //host/share. Easy peasy, right?

Wrong.

I decided to clean up the backup reports directory, and I noticed that the first node of our beowulf cluster wasn't responding to pings. (ping reports are logged before each backup attempt). When I went to reboot the node, I realized it had panicked. No problem. Reboots usually fix this kind of thing, at least for a few months..., I said to myself. And of course, immediately on reboot (i.e. immediately after uncompressing the kernel), the system panicked again. A bigger problem.

Why is this a problem? Well, the installer image for every single node of the cluster is sitting on the hard drive in that node. If this is a hard drive issue, well, you know what happens then.

So cross your fingers, boys and girls! I need all the luck in the world right now!

~ Brad.

P.S.: Thankfully, this isn't a hard drive issue. However, after removing the system from the rack, it no longer POST's. The fans spin and the hard drive spins up, and the voltages I managed to probe off a Molex connector were within specifications, but no mobo... Bad news.

Dreaded Murphy has struck again, and of course, at the worst possible time. I started soldering up my low-noise amplifier board and shortly realized that I'd misplaced an 0805 surface mount resistor. Talk about jelly bean parts. These things are smaller than a grain of rice, and a lot of 500 costs three bucks.

Hear that? That's the sound of my soldering work screeching to a halt until my one stinking resistor comes in the mail. Yup. Murphy's law.

~ Brad.

you can't get away from Murphy. ever.

i'm working on a low-noise measurement preamplifier for a set of experiments i plan to do, and just when the boards come in from advanced circuits, i realize i've made a mistake...

before i go on: yes, i'll post project details once i get the prototype working and tested...:)

as it turns out, the 9v battery holders i ordered are a bit too small to accommodate the bulkier rechargeable 9v batteries. not only that, the holders would backwards-polarize the supply rails, exposing four ten-dollar opamps and eight electrolytic capacitors to -18vdc on startup. i don't have to be a wizard to tell you what kind of sound, light and smell that would've created.

the solution, for the current board, is to order single-terminal battery connectors, a la o2. provided the battery clips will fit the rechargeable batteries, i can tweak the second revision board as needed.

the funny thing is, i've already made two 'supplementary' parts orders for this project. at first, i didn't include any battery charging circuitry, but opted for it once i saw there was space on the board. second, i found out that i'd ordered the wrong enclosure, dc power jack, and dpdt switch. this order will make three extra purchases to two separate suppliers (digikey and mouser, my faves). go figure.

~ brad.

well, when emerge starts telling me i haven't updated my ebuild repository in a while, i always tend to just reinstall from scratch rather than worry about upgrading. with gentoo, you either stay on top of your updates, or you get buried in their blocked package errors. and honestly, each install you do gets easier.

so when i reinstalled, i was yet again delighted to see how advanced gentoo is relative to other distributions. they even have ebuilds for kernel version 3.0 in portage! (masked of course, and i wasn't brave enough to unmask and try them... not yet anyways.) since the install is for an intel atom netbook, i decided to change my M.O. and use Xfce instead of Gnome, wpa_supplicant with a hardcoded conf instead of NetworkManager, and SLiM instead of GDM.

the end result? a time-to-login screen of around 15 seconds, comparable to chromium OS on the same platform. also: 100 MB RAM usage in FULL Xorg GUI. Yep. Xfce is lightweight. finally: thanks to wpa_supplicant, by the time i'm logged into my desktop, the netbook is internet-connected, which is something you can't always say for NetworkManager. all of this and i can ssh and use gnuplot/octave!

yup, gentoo rocks. nerd session over.
~ brad.

i posted a while back about my EDA setup for designing schematics and printed circuit boards. of course, the real majority of the work is done by gEDA gschem and gEDA pcb, but my scripts do a nice job of greatly simplifying the workflow.

i mentioned briefly that i had the same sort of setup for spice simulations, but didn't go into it. well, it's your lucky day.

a quick ls of any one of my spice simulation directories would yield this:

first, notice that the same project file (proj) exists and the schematics are numbered just as before. the edit script is the same as before, of course, and i'll introduce the new scripts soon. :) the only other difference is the lna.spi.in (really ${prj}.spi.in) file, which tells bspice-3f5 what commands to run using the resultant netlist.

second, let's look through the new scripts shown in the directory. you've seen edit before, but now we also have build, run, and view. the first new script generates a netlist (lna.net) and interpreted spice file (lna.spi) from the current input file set:

the next new script (run) is a short script that just runs the currently built spice simulation, generating a raw-file output and textual information:

finally, the last (and even shorter) new script, view, which just runs nutmeg-3f5 to view the contents of the raw-file:

that's all there is to it. this allows me to use gschem to build schematics, and simulate them using bspice in just four easy steps: ./edit; ./build && ./run && ./view

til next time.
~ brad.

p.s.: maybe soon i'll post about the LNA whose directory structure i just divulged, haha.

# /home/brad/.bashrc

alias maek=make
alias ehco=echo


et viola.

say you suspect that twelve source files in your development tree have identical blocks of code centered around a key function. (perhaps they all initialize the same core variables.) instead of looking through all twelve to manually check consistency, use this script:


keyw="util_init_core"; for fname in gen-*.c; do lnum=$(grep -RHn ${keyw} $fname | cut -f 2 -d ':'); start=$(expr $lnum - 3); end=$(expr $lnum + 6); sed -n "${start},${end}p" $fname > $fname.testing; done; for f1 in *.testing; do for f2 in *.testing; do if [ ! "${f1}" == "${f2}" ]; then diff -u $f1 $f2; fi; done; done; rm -f *.testing


see how easy bash is? ;)

~ brad.

i love that song.

but specifically, i was able to salvage (read: desolder) all the useful, rare and/or expensive components from the sub-functional BUFv3b circuit board, saving about a hundred bucks of parts for future projects (read: BUFv4).

always a silver lining.

~ brad.

you might've guessed by now that i'm an advocate for open source software, and that transfers into my hobbies as well.

a perfect case of the existence of powerful free and open source software is the gEDA project, which (most notably) provides tools for schematic capture and printed circuit board design. however, it seems that, while each of the tools in the gEDA suite is powerful in its own right, the linkage between them is far from intimate, leading to confusion among first-time users. i figured i'd post my setup in hopes that maybe someone will stumble upon it when they decide to use open source software to design their hardware.

a quick ls of any one of my audio projects would yield this:

first, notice that the pages of the schematic are numbered such that a simple *.sch expression yields the filenames in page order. this'll ensure that my scripts open and process the schematic files in the proper order.

second, let's look through the scripts that tie schematic capture to printed circuit board design. just three common bash scripts are used to manage all my audio projects: edit, print, and board. the first script edits the schematic and pcb:

the second script generates a pdf file of the schematic files in the project:

the last script translates the schematics into input files for PCB:

all the above scripts read in a small text file called proj:

that describes everything required to set up a design workflow from idea to circuit board. i also have some scripts that integrate the schematics into spice3f5 analyses. they basically rely on gnetlist to do the dirty work, and a little bit of sed/awk to translate outputs into something readable by gnuplot for postscript output. maybe i'll cover those later, since there is a bit of scripting trickery involved.

a few noteworthy points: (a) the edit program opens both the schematic and pcb. if you run it without arguments, it opens up the schematic. if you run it with the 'pcb' argument, it'll edit the pcb. it also automatically handles gerber exports from the PCB program, creating a zip file that is directly uploadable to batchpcb and advanced circuits. (b) you can also use gerbv (a part of gEDA) to examine your exported gerber files, if you wish.

in short, it's pretty simple to use these programs. the learning curve isn't shallow, for sure, but these scripts make my hobby life 1000X easier; maybe they can do the same for you.

~ brad.

p.s. these scripts are provided in the hope that they will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. enjoy. :)