Audio Line tester (with possibly novel oscillator)

[tomizett]

Hi All,
I put this circuit together as a project for our apprentices at work to build (we have a few who're keen on electronics, and I'm trying to encorage them), and thought I'd put it up here too.
It is a batter-powered pocket device for testing and identifying audio lines, primarilly in a live sound context. You plug the tester into a 3-pin balanced (ie, differential) microphone line, and press the button. If the tester sees an impedance less than a few tens of kOhm it assumes that the line is connected to the mixing console and shows a green light. If no load is detected the red light shows and the operator can go and find what's come unplugged - in this state, the tester switches off as soon as the button is released. While the green light is showing, the device latches "on" (even with the button released) and emits a tone of about 1kHz at (from memory) about -20dB. The operator can then go back to the mixing console and identify which channel the line is plugged in to (and if it is noisy, distorted, intermitent etc). The tester switches off again when unplugged, and also has an LED to indicate phantom power (this is a sytem used to remotely power microphones by placing a common-mode voltage of 48v on the signal conductors wrt the screen).

The oscillator is a standard phase-shift type built around Q2, C2, C3, C4, but with the addition of the self-baising circuitary D2, D3, C1, R4, C5 to give it a Wien bridge action. Although it's a pretty simple scheme, I've not seen this arrangement elsewhere - I was wondering if anyone else had? It manages a distortion of slightly under 1%, which is perfectly addequate for the job.
Since Q2's emitter current is adjusted to keep it oscillating nicely, current sink Q3 is provided to servo the output voltage to a relatively steady couple of volts above 0v.

The oscillator is buffered by Q4 (most of the circuit's current consumption passes through R13) and then passes through the load-sensing resistor R15. Voltage drop caused by load-current through R15 is amplified by long-tailed-pair Q6, Q7 and its current-mirror load Q8, Q9. The use of a current mirror means that variations in tail current through R14 (which varies as R15's common mode voltage varies with the output signal) do not cause an output from the load detector into Q5. A differential voltage accross R15, however, will cause current to be driven into Q5's base whenever the Q4 end of R15 is lower than the R17 end (ie, every negative half cycle).

ZD1 and R16 serve to sink all the tail current from the LTP during turn off - without them the device continues to draw current. R16 can equally well be connected to the wiper of RV1, a trimmer which is adjusted to set the load-detection threshold.

Switching on Q5 pulls the gate of Q1 low, bypassing the pushbutton (and thus keeping power on) as long as a load is connected. D1 ensures that the voltage drop in the LED1 path is higher than the LED2 path and so the red LED is (almost) extinguished when Q1 is on.

ZD2 and R17 serve as some transient protection, while C8 and R19 highpass the startup transient (read "thump"). R18 and LED3 form the phantom detection circiit, remembering that this curcuit is referenced to the -ve ("cold") signal conductor and that when phantom is applied the ground pin appears to be at -48v.

Interestingly, I found that the oscillator refused to oscillate without good decoupling (C9). The entire circuit draws about 2.5mA. Ive also included a varoboard/stripboard layout (this is how we'll be building them); note that in the layout R5 connects to the other end of R6 - either works, it was just more conventient for the layout.

Anyway... long post. Hope this is of interest.

PS. I've built one working prototype - I'll keep you posted as to whether this proves to be a repeatable design!

 

[moffy]

It looks awfully complicated for what it does. I guess that's because you are using discrete devices rather than opamps. Couldn't you use a low current opamp in a Wein Bridge configuration? Be a little simpler. Also couldn't you use the phantom supply as your supply without the need for the 9v battery? It would of course need current management because of its low output current. But perhaps you want it to work with or without phantom power? Excuse my comments if they seem cursory, I haven't had time to absorb the detail, which you have obviously done yourself.

 

[alec_t]

The operator can then go back to the mixing console and identify which channel the line is plugged in to (and if it is noisy, distorted, intermitent etc).

Useful gadget for roadies. How does the operator check for distortion? By ear or with a distortion meter?

 

[tomizett]

moffy: Yep, it did get a bit more complicated than I was expecting, as these things often do... The decision to use discreets was a conscious one though, firstly because I rather like designing that way, and secondly because I've not discussed opamps with our apprentices yet. Probably a low-voltage dual opamp would eliminate a most of the transistors and a bit of the board space. Most of the current goes to lighting the LEDs though, so ultra low-power isn't a concern.
The decision to run from battery was also intentional, so you can use it in a situation where you can't/won't phantom, there's a problem on the line etc... It might be nice to power directly from phantom though, or (even better) charge the battery from it.

alec: Roadies are indeed the target audience... By "check for distortion" I really just meant listen. In these situations you generally just want to know whether the problem is with you (the engineer) or with them (the musician). You can often be left in the position, particularly with keyboards etc, of not knowing whether there is anything actually coming out of the instrument, or if you have a mis-patch or a fault at the desk.

Thanks for the interest.

 

[moffy]

Thanks for explaining your design philosophy, it makes more sense. How long did it take you to design and debug? There's a lot going on in there.

 

[tomizett]

It's been in the pipeline for a few weeks, but not really that long in total. As ever, it progressed quite quickly for a start and then took ages to fine tune. I spent quite a while tuning the time constants to get the osc. to settle quickly and with minimal turn-on transient. And I barked up the wrong tree with the load detector as well I seem to remember...