Vacuum Tube Headphone Amp

History of my hybrid tube headphone amp based on Millet "Starving Student" design.


I have a good pair of headphones, but my notebook lacks the power to drive the high-impedance of the HP speakers. I needed a new music listening device.

I spotted this web-page, and liked the design. Cheap too, so let's build it:

First, I got the 19J6 double-triodes from a collector, these components are older than me:



Then, I followed the schematics using a prototype board, and Point-to-point soldering:



The design is almost the same, switched some resistors, the capacitors are bigger for better bass response and used an IRF520 FET instead of the IRF510, because is hard to get them here in Argentina. The holes for the tubes were hard to make, but the end-result was fine:



The final assembly, using cat-5 wires for the connections:




Switched on and...only one channel work! fuck...lets do some hardware debugging then:



It turns out that the input cable was bad. The amp worked flawlessly from the start!

But the heat sinks were too hot. Lets do some calculations to see how many watts there are in each FET:

Each tube needs 19 V, .15 A (2.85 watts only for the heater!), the power supply is at 48 V, so the FET are dissipating the rest, (48V-19V)*.15A=4.35 Watts. There is no way that the small heat sinks that I installed the first time are going to dissipate that heat:



So I replaced them with a couple of motherboard north-bridge heat sinks:



Now they are still very hot, but will not catch fire... And they look bad-ass IMHO.

The amp sounded pretty good, zero noise and no distortion that I can hear. Drives my HD-650 very nicely. In this project I spent less than 300 pesos (u$s 80 dollars) and took me about 6 hours.

Power consumption: This amp is a beast, a relic from the past. Class-A, about 15 watts consumed *idle* for a total of maybe 100 mW max output. This machine pisses all over the environmental hippies:



Yeah, feel the heat whale! fuck global warming, I want my music. Why I don't just get an Ipod for my headphones? because ipods are for girls:



No way. Aqua sounds much better on my new tube amp, a machine for men.

PIC18/dsPIC30 Reed Solomon

This is a error correction code useful in wireless comunications. I have ported the excellent Phil Karn (ka9q) FEC Library to this tiny devices. The perfomance is aceptable for some applications.

Technical specs:

dsPIC30 Port:

* Encoding and decoding of a 255/223 Reed Solomon code.
* 2.2 Kb of ROM, 150 bytes of RAM used (For both Encoding and decoding)
* 10 Kbytes/s of encoding speed, 3 Kb/s of decoding speed at 30 Mips
* No need for a dynamic memory manager (malloc)
* LGPL License

Pic18 Port:

* Only encoding is ported (Decoding should be too slow to be useful anyway)
* 1.2 Kb of ROM, 200 bytes of RAM used
* Aprox. 2 Kbytes/s of encoding speed at 10 Mips (40 Mhz)
* LGPL License

Download zipped source and .HEX

PIC18/dsPIC30 RSA

Here you can download the implementation of the RSA Public-key encryption algorithm, for PIC18 and dsPIC30 microcontrollers.

The source can be compiled with Microchip's C18 C compiler, V3.00 or better. and MPLAB C30. Please don't expect very good perfomance as it's a complex algorithm on a slow CPU.

Technical specs:

* Stripped down and plataform-optimized version of David Ireland's BigDigits Library.
* Estandard RSA encryption/decryption/signing algorithm (No key generation, please use OpenSSL, Lockbox, etc.).
* No need for a dynamic memory manager (malloc)
* Aprox. 5 Kb of ROM.
* Aprox. 700 bytes of RAM for 512 bits operation.
* Measured speed of a single block of data, 512 bits key :
# PIC18F452@40Mhz: Encryption: 2 s. Decryption: 120 s.
# dsPIC30F3013@30Mhz:Encryption: 0.2 s. Decryption: 15 s.
* Key size limited by free RAM only.
* Endianess independent.
* Permissive Non-GPL Licence (Check BigDigits Site)

The Assembly optimizations can be turned off, and it's Ansi C so it should compile on other 8/16/32/64-bit architectures.
Download zipped source and .HEX

GDB patches

Patches to add commands to the gdb debugger

GDB is a very portable and useful debugger, but it lacks some basic funcionality like search for a pattern of memory and fill regions with a value. In this page i will be publishing a series of patches to add that funcionality to the GDB debugger, hopefully in a portable way.

1. Search and Fill

Update 12-7-2008:

I found a much better and simpler way to search and fill in gdb without patching if you are using a modern libc:

Search any byte sequence:
(gdb) call memmem (addr,lenght,bytesequence,length_bytesequence)

That's all, it will return the address if the sequence was found.

The same about filling:

(gdb) call memset(bla bla)

you get the idea...


BTW, this is the older version: is a patch to the gdb and is slower, but it can search over the entire address space:
The patch is very small and only adds the "search" and "fill" command. Should be applied to the GDB 6.6 source:

Old Search and fill patch

2. Breakpoint commands external editor

This is a patch to allow editing the commands attached to a breakpoint using an external editor. The editor follows the behavior of the "edit" command, using /bin/ex, or the content of the enviroment variable "EDITOR". Should be used like this:

(gdb) command 1

Edits in the old way, but:

(gdb) command 1 edit

spawns the external editor. (I recommend setting EDITOR to 'vi')

The patch should be applied to the gdb 6.8 source tree.

Commands patch

(under review)

3. Show breakpoints in source listing

This simple patch allows breakpoints to be displayed when using the "list" command. The breakpont number is displayed in the corresponding line. This patch should be applied to the gdb 6.8 source tree:

Breakpoints in listing patch (Not submitted yet)

4. ptracediff

Not really a patch but a simple tool for a "contest": ptracediff.c

test

blabla moving my old site

Google Android Debugging Utilities

Here are some gnu apps that I have compiled to ease the debugging of binary files on the android platform. I am making available the pre-compiled binaries, the source for this apps are already available and the compilation process is pretty straightforward, once you have the cross-compiler, I used the codesourcery arm-none-linux toolchain http://www.codesourcery.com/sgpp/lite/arm/portal/release644:

Steps to crosscompile gdb:

export PATH=$PATH:/home/alfred/android/arm-2008q3/bin/
./configure --target=arm-none-linux-gnueabi --host=arm-none-linux-gnueabi
make

gdb 6.8 will compile without any patching.

Android binaries:

strace, gdb and gdb-server (6.7), bash

gdb and gdb-server (6.8)


I have found that having a native gdb is much more convenient than having to connect to gdbserver, and the other utilities (strace and bash) are also useful while debugging.

You can upload the files using a command like:

$adb push gdb /data/bin

then:

$adb shell

# /data/bin/gdb
dlopen failed on 'libthread_db.so.1' - libthread_db.so.1: cannot open shared object file: No such file or directory
GDB will not be able to debug pthreads.

GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=arm-none-linux-gnueabi --target=".
(gdb)


Disregard the "libthread" error, you can attach to threads directly on android, using their pid.

I rule.



UPDATE 3-5-2009:


The default gdb can't debug binaries, only attach to them. Therefore I don't rule, more like I suck.

This is the error showed:

Starting program: /data/gdb
Cannot exec /bin/sh: No such file or directory.


WORKARROUND:

Android doesn't have /bin/sh, so lets make one. First, make / writable:

# mount -o remount / /

Then mkdir /bin and copy the 'bash' shell provided in this page as /bin/sh

Now gdb is ready to go. This works on android sdk 1.1r1 and before.

Or you can use the alternative method, (thanks Oren Poleg !):

export SHELL=/system/bin/sh