Rebuilding an Astatic D104 Microphone

Written 2014-12-07

Tags:Microphone Astatic Electret Ham Radio 


At a recent Hamfest, I picked up an Astatic D104 microphone. As it turns out, there are two main models of these microphones - those with an internal amplifier and those without it. Internally the crystal microphone module has an impedance around 500k to some megaohms, which works well with older vacuum-tube radios, but for newer transistor radios a lower output impedance is desired. This is where the amplifier is useful. However, my crystal module appeared broken, so I needed a replacement and opted for a modern, low-impedance electret condenser.

Parts List

Tools List

Disposables List

Component Testing

Before starting, verify each component works.
  1. Test the audio recorder using the internal or a known good microphone.
  2. Attach electret condenser to computer, referring to the manufacturer's datasheet for the wiring diagram. Use the alligator clips to connect it to the 3.5mm pigtail. Use your audio recorder to test it.
  3. Double check twinax and PTT wire using the ohmmeter

Replace wiring on the head

The D104 comes in two main parts - the head and the stand. The head contains the microphone element.
  1. Unscrew the head from the stand.
  2. Remove 4 head plate screws to reveal the crystal module. You'll need two screwdrivers, one at each end, to do so. If you're a little OCD, remove each screw at a time, and reinsert it into the bolt so that the screws and bolts remain paired.
  3. Desolder the two wires from the crystal module
  4. (Optional)remove hidden screw from neck, and clean it. This screw will connect the twinax shield to the conductive body of the microphone.
  5. Solder in new condenser. For now, make sure you connect the condenser ground to the common microphone ground.
  6. Pack with sound-insulating material.
  7. Replace screws.

Choose your own Adventure

At this point, you could trace out the wiring through the stand, add your microphone connector, and be done. Or, you could entirely rewire the stand yielding superior shielding and noise immunity over the original design. Up to you, but plenty of these microphones work without differential shielded audio feeds. Also, rewiring the base will give you the opportunity to clean the PTT switch, but I suspect it rarely gets dirty.

Rewiring the stand

Since my radio supports a separate audio ground than the digital one, and my existing base wiring only had one ground, I went ahead and rewired the base.
  1. Open up microphone base by removing three screws.
  2. Desolder all wires from wiring hub.
  3. Remove existing wire going outside of the mic.
  4. Remove flathead screw at top of tube
  5. Desolder 3-pin connector at top of tube.
  6. Remove two flathead screws from base of tube to remove lever.
  7. Remove two smaller flatheads from tube. This disconnects the switch.
  8. Remove last screw from base of tube.
  9. Remove stand tube, may be a little sticky on the base. Pull the switch out the base.
  10. Remove existing wire going up the tube.
  11. Solder control cable to normally-open pins of switch.
  12. Install twinax+switch into tube. Slide twinax and switch into base of tube. Install two small flathead screws.
  13. Install connector on twinax.
    1. Strip insulation from twinax.
    2. Lay tube on side, so you don't drop any metal into it.
    3. Use pick to unwrap shielding from twinax.
    4. Solder twinax shield to head connector.
    5. Solder two audio lines. Take note of which go to which pins noted in head rework.
  14. Pull slack twinax back through tube, screw head connector in place, double-check PTT.
  15. Route wires into base, place tube on base, install lever and opposite screw.

Assembly Testing

Testing PTT
  1. Connect PTT and PTT ground to an ohm/beeper meter.
  2. Press and hold button. Beeper should beep or meter should read close to zero.
  3. Hold button down while moving wires, reading should not change.
  4. Give them a bit of a tug, reading should not change.
  5. Release button. Beeper should stop or meter should read open circuit.
Testing Audio
  1. Connect Ohmmeter from mic pins. Mic should measure part of an ohm to a few ohms.
  2. Connect mic pins to 3.5mm pigtail with alligator jumpers, test with computer or walkman.
Testing Crosstalk
  1. Use ohmmeter to verify mic ground and PTT ground are disconnected.
  2. Use ohmmeter to verify the only two non-open pins are the mic pins.
  3. Using audio recorder, start recording. Press and release PTT several times. You should only hear the mechanical sound of the switch closing and not any pops or crackles.

Attach a radio connector

Connect up the connector corresponding to your radio. You may also need a transistor or resistor added to your PTT lines, but this is specific to your radio, not to the mic.

Apple Laptop LED PWM Frequencies

Written 2014-12-07

Tags:PWM LED MacBook PowerBook 

Although the LED on the lid latch of an Apple Laptop is a simple device, there's a little more complexity than would be expected. Since the LED is lit while the laptop is suspended, it is important that it be efficient to avoid draining the battery unneccessarily while suspended.

One trick to driving LEDs more efficiently is to use pulse-width modulation(PWM) to temporarily overdrive the LED for a short period of time, then underdrive or not drive it at all for another period of time. This works due to something called the flicker fusion, where you perceive small enough pulses of light to be a single, continuous light.

But, it's possible to see behind the curtain. When you move a PWM'd light source, the human vision system tends to see each strobe individually, like a stroboscope, but only if the light is being moved fast enough for the strobes to occur at different locations - otherwise you won't see the strobes and the pulses will blur together.

It turns out, if you move a PowerBook(6,8) and a MacBook together, you'll see that the strobes from the PowerBook LED are further apart than the MacBook LED. This indicates that the PowerBook strobes its LED at a lower frequency than the MacBook's LED. If both laptops used the same led it would be possible to estimate the duty cycle by comparing the perceived length of each strobe, but since the MacBook has a much smaller LED, the results would be skewed.

Debian Wheezy on a ThinkPad 365X

Written 2014-08-06

Tags:Linux Open source Debian ThinkPad 


I've had this old ThinkPad for quite a while. I used to run Linux 2.6.8, but after the libata rewrite, debian wouldn't boot due to a missing root partition. Until today. Today I run debian stable.


Hardware - Thinkpad 365X

  • Intel Pentium@120MHz(f00f bug and everything)
  • 8MB Integrated RAM(This can't do it alone)
  • 64MB expansion RAM(32MB should also work, 16MB would be sketchy)
  • 35MB total RAM recognized(try bios upgrade?)
  • 2GB CF card(super-cheap, much faster than contemporary spinny-disks)
  • IDE44<->CF adapter, approx $5 from Shenzen

Hardware - Other

  • USB<->CF adapter or USB<->IDE44 adapter, approx $5 from Shenzen
  • Computer with kvm/qemu


Inserting the Disk in the VM Host

Since we're going to be working with raw disk IO, you'll need to unmount any automounting done when you connect the disk over USB to the VM host. Simply put, we don't want two OS kernels fighting for the same block device.

Creating a Virtual Machine image(optional, but recommended)

First, create a VM image of exactly the same size as your CF card or target hard disk. For QEMU/KVM, a file full of garbage is fine, or you can just rip the disk with dd using `dd if=/dev/sdX of=~/vmfilename.img bs=1M`.

Installing Debian in a Virtual Machine

KVM(or QEMU in a pinch) can be used to simulate a classic Pentium system, but not directly the one in the Thinkpad. `sudo {qemu or kvm} -hda {path to VM image or /dev/sdX} -cdrom {path to debian} -boot d -m 1024 -cpu pentium` Breaking it down:
  • sudo - run the command as root to allow qemu raw disk access. May also be needed for KVM(but not QEMU). Skip if using VM image with QEMU.
  • kvm - run a kernel-virtual-machine. Basically QEMU + hardware virtualization
  • qemu - run the old-school cpu emulator. Slower, but works on any host CPU, doesn't require root access
  • -hda - tell qemu/kvm where to find the disk image.
  • -cdrom - tell qemu/kvm where to find the CD image.
  • -boot d - tell qemu/kvm to boot from CDROM this time.
  • -m - Set VM RAM. In my case I used 1GB because it makes the installer a bit faster, but default also works.
  • -cpu - Set VM core type. In my case I set it to Pentium. This will cause the Wheezy installer to pick an i486-compatible kernel+libc
While working through the normal installer, here are some things to consider:
  • Old spinning disks are slow. Mounting partitions with 'noatime' or 'relatime' is quite helpful for this.
  • If you are low on disk space / ram, you will likely wish to install zero additional packages; I unchecked all the boxes. The complete desktop environment isn't really an option here either.
A note - if you use the advanced installer, we're going to rebuild an initrd anyways, and since qemu/kvm won't emulate the ThinkPad's IDE chipset, it doesn't make sense to strip it down in the installer because the virtualized installer will pick the wrong hardware. Once the install is complete, you may need to restart kvm/qemu, but changing "-boot d" to "-boot c", which will now boot from the emulated or USB disk.

Removing The Extras

This topic is best handled elsewhere. Removing daemons will save RAM, removing things in general will save disk space. The 365X is very limited by today's standards.

Install Your Favorite Packages

Now(while we have an emulated ethernet connection) is a good time to pull down any WiFi firmware you might need, as well as the pcmciautils package, and any other tools. Here's my list(455MB used/2GB total), less than 9MB RAM used after bootup:
  • sudo
  • cupt
  • htop
  • nload
  • hexedit
  • pcmciautils
  • linux-firmware-free
  • linux-firmware-nonfree
  • linux-wlan-ng
  • openssh-client
After installing everything, use "sudo apt-cache clean" to remove downloaded package installer files.

Building a New, Smaller Initrd

At least with 35MB of usable RAM, the default initrd won't fit. You might be able to do it with bios support for a 64MB stick. The last time debian had an initrd that did fit, it no longer contained the required ATA drivers for the 365X. So, to rebuild:
  1. Copy+rename the existing initrd alongside the current one. You'll find it in /boot/initrd-{somethingorother}
  2. edit /etc/initramfs-tools/modules to add "pata_legacy". If you want to be able to reboot in the VM, also add ata_piix.
  3. edit /etc/initramfs-tools/initramfs.conf to set "MODULES" to "dep"
  4. sudo update-initramfs -u
A word of warning for upgrades - the Jessie i686 kernel doesn't seem to have pata_legacy module, and I suspect the i486 kernel may not either.

Burning the Image to Target(required if using VM image, otherwise skip)

Burning the image back to the disk is just the reverse of ripping it. Flip the arguments on dd, taking care not to use the partition number.

Ejecting the Disk

Just run `sync`, then `eject /dev/sdX`, then wait for any lights to stop blinking, then unplug.

Booting up the 365X

Unplug power and battery, click the power button to make sure the board is drained, insert the card, replug power, hit switch.
It should just work. However, here's some of the problems I had along the way, in the order I had them, that should've been fixed by following the above instructions:
  1. Hung up in Grub - turns out Grub is just really slow on this box.
  2. Hung up loading initramfs - caused by initramfs too large for current RAM. The kernel used to give a nicer message about this. Fixed by removing unused modules in initramfs rebuild above.
  3. Hung up in (initramfs) prompt - caused by missing ATA driver pata_legacy. Fixed by initramfs rebuild above.

Volume of Spheres to Cubes Over Varying Dimensions.

Written 2014-07-06

Tags:Math n-Ball Hypercube Dimension Hypersphere 

As James Jolly said(approximately) to me, as the number of dimensions goes up, a normally-distributed dataset's points become closer together. To approximate it, draw a circle in a square, followed by a sphere in a cube, followed by a hypersphere in a hypercube. This relationship wasn't intuitively apparent to me, so I plotted it out.
polydimrat output

Some Intuition

To think recursively, each next-higher dimension contains an infinitely thin slice of the current dimension. For example, in three dimensions, a the area of a circle cut through a unit sphere by a plane of z=0 is the same area as a 2-dimesional unit circle. This is true all the way down - a 1-dimensional circle fills the 1-dimensional space from the leftmost to the righmost points on the 2-dimensional circle.

Intuition at the Equator


Intuition at z=-0.75


But, we may notice that the ratio of circle-to-square in our slice is highest only in the middle(z=0). By varying from the center of our dimension-splitting subregion that ratio in the slice is always smaller. This is also true for the ratio of sphere-to-square in any two neighboring dimension sets(n->n+1). By approximating an integral, if the highest ratio in a dimensional space is the ratio in the lower dimensional space, and our integral averages over all the current space, then the ratio in the current space must go down, as being an average of ranges between 0 and the ratio of the previous space.


Written 2014-06-21

Tags:SPARC benchmark STREAM computing 

Today, I ran STREAM on my old router(Sun V210, 2x UltraSPARC IIIi) and my new one(Sun T2000, 1xNiagara T1).

Benchmark Overview

STREAM is a simple memory bandwidth benchmark. It conducts a series of operations on large vectors of variables and reports back on how long the operations took, as well as a double-check to ensure the results are correct. The tests are:
  • Copy: Y[] = X[]
  • Scale: Y[] = X[]*n
  • Add: Y[] = X[]+Z[]
  • Triad: Y[] = X[]*n+Z[]
The Copy test almost always gets optimized to a memcpy, which serves as a good reference for systems with weak FPU performance, or with no FPU at all. All other tests tend to make heavy use of any available FPU.

System Overview


The V210 uses two UltraSPARC IIIi CPUs attached to DDR memory. Each IIIi supports a single core with FPU.


The T2000 uses a single UltraSPARC T1 CPU attached to DDR2 memory. The T1 supports four cores each with eight threads, but with only a single FPU. Effectively up to 32 independently schedulable threads. The T1 is also known for slow single-threaded performance, a design corrected in the T4 and newer CPUs.

STREAM Results in Megabytes/Second

Box: V210x1V210x2T2000x1T2000x32
Copy: 496.7 577.5 429.6 3492.9
Scale:498.3 568.0 261.2 1558.7
Add: 494.1 597.1 282.8 2133.4
Triad:419.3 579.5 220.9 1176.8

Single-Threaded Results


What can I say? This router is getting old.


The T1's single-threaded results are bad - even worse than the IIIi(a 4 year older design). This could prove to be a problem, as in addition to routing, I'll need it to run a few mostly single-threaded game servers as well. More measurements required.

Relative Multi-Threading Improvement over Single-Threading

Box: V210x2T2000x32
Copy: 1.16 8.13
Scale:1.14 5.97
Add: 1.21 7.54
Triad:1.38 5.33

Multi-Threaded Results


A little bit faster, but not a whole lot. This usually means that one thread is capable of nearly saturating the memory bus/controller, which is good - it implies that the penalty for the extra multithreading hardware is relatively cheap, although it could also mean your memory controller or cache just isn't very good.


This is where the T1 shines, with between 5.3x and 8.1x more bandwidth usage spread over 32 threads. What's interesting here, is that the overall improvement was greater than 4x(number of cores). This means that a hardware thread isn't capable of saturating the bandwidth for the local core, and so 8 or more threads will be required for saturating the chip's bandwidth and that may only occur if the kernel schedules them 2-to-a-core.