Harmonic noise introduced when using an iPhone dock extension cable connected to a mic peripheral

I am using a Tascam iM2 stereo mic connected to the dock of an iPhone 4S. When the peripheral device is connected directly, there is no problem. Hoever, when I use a dock extension cable, a strange harmonic noise is introduced. I have tried extension cables from different manufacturers, and even the highly rated dockXtender extension cable made by CableJive introduces the noise.

This is somewhat strange as the analogue-to-digital (bear with my British English) converter is built into the peripheral device. This is not analogue noise picked up in the cable as the signal is pure digital on route to the iPhone. The noise seems to be introduced in the digital domain. I recorded a sample of audio in my office and analysed it using Matlab. The noise fluctuates in amplitude, but it is clearly a harmonic complex with a very precise 1-kHz fundamental frequency. The ADC reportedly samples at 44.1 kHz, so it is particularly strange that the harmonic noise comes in with a periodicity that is not even an intiger multiple of the sampling period. As a side note, I have heard a similar harmonic noise in the past emitted from some laptop sound cards (specifically Vaio C1s models).

Given that the noise never fluctuates in frequency, testing has shown that I can remedy the problem by pre-processing with a fractional delay filter based on the information here . . . http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=951433 . . . but this is a computationally expensive filter to implement.

Prevention is better than cure. My question is, what is the origin of this strange harmonic noise and if possible, how do I remedy it so that I do not have to waste processing power implementing an additional filter?

What you are picking up is EMI from USB frame sync (most probably through the ground wire):

Every millisecond (12000 full-bandwidth bit times), the USB host transmits a special SOF (start of frame) token, containing an 11-bit incrementing frame number in place of a device address. This is used to synchronize isochronous data flows. High-bandwidth USB 2.0 devices receive 7 additional duplicate SOF tokens per frame, each introducing a 125 µs "microframe" (60000 high-bandwidth bit times each).

USB 2.0 added a PING token, which asks a device if it is ready to receive an OUT/DATA packet pair. The device responds with ACK, NAK, or STALL, as appropriate. This avoids the need to send the DATA packet if the device knows that it will just respond with NAK.

This could be avoided with a properly shielded extension cable. Note that even dockXtender only shields some of the wires:

A revolutionary 2-tier shielding system puts all video and audio signals inside a separate shielding to reduce interference from the other signals traveling through the wire.

If you're the DIY type of person it should be quite easy to make your own extension cable using high quality shielded wires. You will probably only need to connect just a few of the 30 pins: USB (power, gnd, data+/-), all GNDs and maybe accessory/serial (enable, rx/tx). Make sure you also shield the soldering on the connector.

Since the A-D conversion is happening at the peripheral end, then the noise must also exist there.

Without access to the device for disassembly, I can only guess at the problem, but it's likely to be due to one or more of the following:

• The peripheral is probably fully shielded internally from the microphones through the ipod connector. When you connect an unshilded extender cable, external environmental noise is coupled into the device through the cable. You might be able to confirm or dismiss this if you perform tests in electrically quiet areas - out in the middle of a field away from powerlines, for instance.

• The peripheral has "just good enough" filtering, but once you add the extra length of wire reflections - which don't affect the USB signal - start to cause ground bounce or other EMI. There's no easy way to test for this without an oscilloscope and/or signal analyzer.

• The peripheral has a 1kHz switching power converter (which may be required if, for instance, it used electrostatic microphones, certain high performance microphones, or provided "phantom power") and the extra cable length on the switching converter's input results in power signal reflections which would normally be clamped by the iOS device's power filters when they are electrically close. This too would require specialized equipment to test for.

• There are high impedance lines usually shorted out in certain configurations in the peripheral to tell the iOS device how it plans to start communicating and what it requires in terms of power and communications. It's possible that lengthening those lines, being high impedance, couples noise into the peripheral.

• This could be a typical ground loop problem. Simply adding a several longer ground wires, if they aren't correctly connected at the peripheral end, will cause odd current flow and may result in ground noise at the far end.

If you know which wires in the cable the peripheral actually uses (probably USB, power, and the serial wires) then you can probably craft a cable that would suit your needs and eliminate most of the above problems. You'd have to short the sense pins correctly at the iOS device end to eliminate the high impedance issue, and shield even the digital pins to eliminate EMI problems. You'll need to short the appropriate ground pins at both ends (be careful here - in some cases you want a separate ground wire - again, a careful analysis would need to be made of the peripheral to determine the correct way to short ground pins).

By eliminating the 20+ wires you don't need, and by shielding the remainder you might be able to eliminate all of the above problems.

However, unless Tascam comes out with their own extension cable, it's a long, difficult process. I'd suggest contacting them, showing them your results, and discussing possible solutions with them.

Given that this is a highly technical question and that you have done considerable work in documenting the problem, I suggest you take this up directly with the Tascam company's technical support staff. At the least, they would appreciate knowing about this problem.