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