April 2014 Archives

Quick and Dirty Aviation Headset Interfacing

There are about three different styles of headsets, generally speaking.

A PC- or phone-style headset will use an electret mic and have one or more low-impedance earphones. Typically, a bias voltage is expected and provided by the device for the electret microphone, and an impedance or load on the MIC line of about 18 kohms. Earphones may be 8 ohms to 64 ohms, typically 16 - 32 ohms. Higher impedances are common in newer equipment at either or both ends of the earphone circuit.

A General Aviation headset will typically use an electret microphone and one or more high-impedance earphones. This electret microphone will also expect a bias voltage to be provided by the radio, but the microphone impedance will be lower, approximately 50 ohms. The radio microphone input impedance may be 50 ohms to 300 ohms. The earphones will be 150 to 600 ohms, often 300 ohm earphones are used and the two earphones wired in parallel to halve the impedance to 150 ohms.

A Military Aviation headset will typically use a low-impedance dynamic microphone and one or more low-impedance earphones. This type of microphone does NOT require a DC bias voltage, nor should one be provided for the microphone, nor is a DC bias voltage expected. These microphones typically have low impedances; five ohms is not unheard of and rather common. Impedances may be up to 50 ohms or so. The earphones are much more conventional, 4 ohms to 16 ohms, wired appropriately to arrive at about 8 ohms.

In summary:

PC style headset:
Mic Load: ~18 Kohms
Mic Impedance: ~10 to 40+ Kohms
Earphones, stereo: 8 to 32 ohms each
Tip: Mic
Ring: Mic Bias Voltage
Sleeve: Mic return

GA headset:
Mic Load: 50 to 600 ohms
Mic Impedance: 50 ohms
Earphones, mono: 150 - 600 ohms, typically wired to 150 - 300 ohms

Military headset:
Mic Load: ~5 - 50 ohms
Mic Impedance: ~ 5 - 8 ohms
Earphones, mono: 4 - 32 ohms, typically wired to 8 ohms.

The military headset can be wired directly to a 3.5 mm plug and connected to a computer. The microphone side will require a transformer to convert the impedance, and a blocking capacitor to keep DC from going through the transformer coil and magnetizing it.

The General Aviation headset can be interface with by using common audio interface methods associated with telephony. Most telephone interface equipment expects a nominal impedance of 600 ohms. Older audio equipment may use this impedance as well for "line" connections. Most "line" inputs today are 10 Kohm or higher.

 DC blocking capacitors are a must (0.068 uF, 0.1 uF and/or 1uF) as well as RF bypass capacitors. Motorola has used 1500uF capacitors on the output of bridged audio amplifiers. Values such as 10uF may cause filter effects to the audio. Remember that audio distortion is comprised of even and/or odd harmonics of the fundamental. Therefore, filtering above 5KHz will not cause problems for your audio in either direction. The RC formula for resonance (Xc) will give the resulting curve.

There are a lot of transformers to choose from on the surplus market and from electronics houses. A transformer that goes from 1 Kohms to 8 ohms is the same as a transformer that goes from 625 ohms to 5 ohms. Similarly, some 600-ohm transformers, repeat coils, and older microphone / audio transformers can be wired to go from 50, 150, 250, 300, 500, 600, or 1200 ohms.

The important thing to keep in mind is the turns ratio. A transformer with a 1 Kohm primary and an 8 ohm secondary is also equivalent to a 625 ohm primary and a 5 ohm secondary (125:1). Likewise, a center-tapped 600-ohm transformer primary can be connected as two 300-ohm windings in series, however the phasing of those windings determines how they can be used. Two independent windings that make up 600 ohms can be placed in parallel with each other, giving 150 ohms.  Don't worry about power handling capability since most headphones and ears can't take more than about a half-watt of power without taking damage. Two of these transformers, coupled one after the other from low impedance to high impedance to low impedance to high-impedance should transform from 5 ohms to 312.5 ohms to about 39062.5 ohms, which should be enough to interface with any modern gear.

There are small audio transformers that can be obtained from the parts houses. I recommend checking with Mouser, Jameco, All Electronics, Surplus Sales of Nebraska, Fair Radio Sales, Electronics Goldmine, Electronic Surplus, Mendelson's, and any other outlets you may be able to locate for surplus equipment.

Don't go audiophile to the nth degree on this one. Audio is rather forgiving, and transformers and capacitors are the only way out. A low-impedance dynamic microphone behaves just like the element in a ribbon microphone (which is often in the milliohms). A transformer will work best here. These headsets were only designed to do 300 - 4000 Hz for voice. Some were designed for loud environments, and function well there. They were not designed for HiFi audio. Don't worry about audio response above 5KHz.

Crystal mics and carbon mics are another topic altogether. If there is interest, I will try to cover them here.

If you need more information or don't understand something, feel free to email me at the address given in the registration information for this domain.

buffer, or writing to tape more efficiently

During a recent recovery project, I found myself using dd(1) to copy hard drive images to a tape drive. Due to the speed/generation of the tape drive and the overall abysmal I/O performance of the PC (~34 MB/s), the tape drive, capable of 120 - 140 MB/s to tape and upwards of 200 MB/s when compressing data on the fly, was constantly shoe-shining the tape -- or worse -- and strange things were happening to the drive such as constant retensioning and eject/reload cycles.  I run a quick web search, and found that there is a utility named buffer available on some Linux distributions to buffer to tape drives using Shared Memory.

Due to distro specific kernel parameters, it was necessary to reset the kernel's shared memory parameters.

For reference:
https://www.zabbix.org/wiki/How_to/configure_shared_memory

First, one must determine the page size:
# getconf PAGE_SIZE
4096
Then check to see what the limits are:

# sysctl -a | grep -E "shmall|shmmax"
kernel.shmall = 2097152 kernel.shmmax = 33554432
Explanation of cryptic names:

kernel.shmall: Maximum total size of shared memory in pages (normally 4096 bytes)
kernel.shmmax: Maximum size of shared memory segment in bytes

Next, the limit should be moved up in /etc/sysctl.conf.

# echo "kernel.shmmax = 2147483648" >> /etc/sysctl.conf
Finally, issue 'sysctl -p' to force re-reading of /etc/sysctl.conf and to make the parameters effective.

# sysctl -p
kernel.shmmax = 134217728
Since buffer(1) was run was the root user, ulimit was not a factor.  buffer(1) has a hard buffer size limit of one gigabyte. The limit is a combination of 2048 blocks of 512 kB each. 512 kB is the largest blocksize buffer can deal with, and it has a limit of 2048 blocks. Much like dd(1), buffer(1) supports multiple blocksizes up to 512kB. Typically hard drive performance maxes out at 64 kB and above. This is because historically the maximum size of a DMA transfer was 64 kB. Transfers of larger blocksizes will be broken into smaller blocks as necessary by the kernel, but smaller blocksizes will result in poor performance. In order to buffer the maximum amount possible, it is necessary to use 2048 blocks of 512 kB. A 512 kB block is still larger than the default blocksize for tar, which is 10 kB.

# buffer -i /dev/sdX -o /dev/nst0 -S 512m -s 512k -b 2048 -m 1025m -p 80 -u 100 -B -t -d
debugging turned on
buffer: setting handlers
buffer pbuffer is 0x7ff6721c5000, buffer_size is 1073774623 [2048 x 524288]
R: Entering reader
buffer (writer): setting handlers
W: Entering writer
blocks = 2048
maxfilled = 1638
186122240K, 33944K/s
buffer (writer): write of data failed: No space left on device
bytes to write=524288, bytes written=-1, total written 430263808K
buffer (reader): removing semaphores and buffer
writer died badly: 0xff00
#
An explanation of options:
-i: input device or file
-o: output device or file
-S: after this many blocks are transferred print a status line with throughput (consider that some tapes have a gigabyte capacity in the hundreds and thousands)
-s: blocksize
-b: number of blocks
-m: memory to allocate (optional, but must be larger than actually memory used)
-p: percent of buffer full to start writing to output device
-u: sleep X microseconds after write to allow tape drive to settle
-B: pad out partial blocks to full blocksize; should only matter for last block written.
-t: print total bytes written to stderr on exit
-d: print debugging information

To translate the KB written into dd-ese, divide the amount written by the blocksize. Note that you can use dd before buffer to block data from a different size, for instance 64K blocks. In this case, one would divide 430263808K by 64K, giving 6722872. Then one need only execute:

dd if=/dev/sdX skip=6722872 bs=64k | buffer  -o /dev/nst0 -S 512m -s 512k -b 2048 -m 1025m -p 100 -u 100 -B -t -d

Here I've reset the buffer highwatermark to start writing at to 100%; I'm not worried about the amount of time lost pulling data from USB, as it's important to keep the tape drive streaming if possible.

Using buffer improves throughput on most modern tape drives, particularly if the drive has difficulty adjusting to data as presented by the kernel. A modern LTO4 tape drive only has a buffer of 32 MB, which during tape writes at high speed is a fraction of a second. By comparison, striping over multiple hard drives would be necessary to sustain the write capabilities of this tape drive.

I miss having an AMI MegaRAID 493 with a single 128MB 72-pin SIMM on it. PCI bus bandwidth being 133MB/s, the operating system would report a speed of 128MB/s for the first second, then fall off as the controller started writing. In comparison, this would be equivalent to having a smart caching disk controller with one-quarter of the RAM of the system installed to as much RAM as the system has installed.   

sshd, X-Windows, and IPv6

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422327

If you find that xauth (ssh -X -Y) over ssh isn't working on RHEL or CentOS6, look for a disabled IPv6 system with the ipv6 module loaded. Make sure the module is disabled from loading by putting:

options ipv6 disable = 1

into /etc/modprobe.conf or /etc/modprobe.d/<filename>. 

About this Archive

This page is an archive of entries from April 2014 listed from newest to oldest.

February 2014 is the previous archive.

May 2014 is the next archive.

Find recent content on the main index or look in the archives to find all content.