A Not So Simple Headphone Amplifier (Part 2)

So I had previously started to lay out a bit of background information in order to begin designing a simple amplifier for a pair of headphones.  Well.... the requirements changed a little.  Now I'm going to power it via Phantom Power.  Most, if not all of the things I brought up in the previous article still apply; but now there's a small catch.  Here's the story:

Someone needs to be able to sit in a room listening to a live speaker in an auditorium and translate for an audio feed for non-native listeners.  The translator person will need both a microphone and a way to listen to the speaker.  And if they have a mic, they can have Phantom Power.  Now it is not typically good practice to use that mixer power for anything other than the mic it's connected to, but I'll make an exception for myself.  I have a good understanding of their scenario, existing sound equipment, and their procedures.  So the trick here is going to be making an amp that has some a small amount of gain, can pump of few mW of power into some headphones, and pulls its power from a mic signal without affecting that mic signal.

Why an Amplifier?

Back to the main problem at hand.  Why do this at all?  Why not plug headphones into whatever aux out and go with it?

If it's an unbalanced output, the first thing you'll notice is you only get one ear's worth of sound.  But ignoring that you'll also find that the volume is rather lacking.  If you recall, we looked at the output impedance of the mixer as well as the impedance of the headphones last time.  I'm showing the basic circuit above.  Calculating voltages we can see that for a 100mV of audio signal, only 21mV is dropped across the headphones ($V_{HEADPHONE}=\frac{R_{HEADPHONE}}{R_{HEADPHONE}+R_{MIXER}}*V_{MIXER}$).  That's a 13.5dB loss ($20*log{\frac{V_{HEADPHONES}}{V_{MIXER}}}$).  If you do manage to parallel each ear of the phones, we're looking at another 5dB down from there as the load will total $16\Omega$ instead of $32\Omega$.

While you will be able to hear the audio, it may only be "loud enough" when the mixer output is really dialed up.  For a number of reasons, the mixed audio will never be near the top of the mixer's abilities.  We're gonna want the ability to add extra volume.

Initial Design

Originally I was going to power the amplifier with a typical wall wort.  This would have provided "unlimited" power for the application and made life easy.  And as such, I was simply going to use the good ol' op amp.

Not a ton of parts really.  You may notice that this layout has no gain, and that was because I thought that just dealing with the impedance mismatch would be good enough at first.  Let's look at the individual sections: the input, amplification, and output driver.

Input

This part includes everything left of the op amp.  Those diodes are provide some input protection.  For both the listener and the op amp(I don't necessarily know that the op amp needs any protection, but it's still best to keep the signal within the rails).  Any input swing above or below 0.7V of ground gets trimmed off.  The potentiometer should be obvious, it's the volume control.  Rather than alter the gain or output, it's more advantageous to affect this input.  If the signal is clipping, the input is the only place to fix that.  R3 I only had to add to protect the mixer output.  If the signal is clipping quite a bit, and the pot is turned all the way up, there isn't much to limit current thru the D3 and D4.

R2, R7, and C2 form a DC bias for the incoming audio.  This is point I've always been a little bitter about.  In no point during my college career were we shown any single supply op amp circuits.  Never.  And since college, I've never used an op amp with dual supplies.  The differences are minimal and not complicated, but only in retrospect.  I just wish they would have pointed us in the right direction.....

But anyhow, the bias circuit.  C2 allows the audio signal, which is AC, thru, while blocking our DC from feeding into the mixer output.  R2 & R7 set the bias at half our supply voltage to allow for the most voltage swing.

Amplification

Very little to say here.  Just the op amp really(a Microchip MCP601).  The feedback comes from the audio output, so the op amp will try to make that voltage match the input voltage, giving us a gain of one.  So why use it?  Well, it has very high input impedance.  The only other input impedance comes from R2, R7, and the potentiometer, which are all large compared to the output of the mixer.  Most of the signal will be seen at the op amp input.  Since it will adjust it's output from the voltage seen over the headphones, it's like there is little or no output impedance.  This gives us direct control over the voltage over the headphones.

Output Driver

I first drove the headphones directly from the op amp.  For reasons I haven't fully sussed out, it didn't quite have enough oomph (likely the headphones were too low an impedance).  So I added Q1, Q2, and all the related components which comprise push-pull driver.  Q1 pushes the top half of the signal and Q2 pulls the lower half of the signal.  Because these transistors are tied directly to the power rails, they can supply a lot of current and achieve a wide voltage swing.  R4 & R6 are small enough to not limit the desired output voltage range, but large enough to safely limit the current thru the transistors if the output is shorted directly to ground.

I had to add diodes D1 & D2 because I noticed there was some distortion on the output, especially at lower volumes.  As it was most noticeable at low audio levels, i.e. near the zero crossing of the signal, I was able to recall back to a college lecture and pluck out the phrase "crossover distortion".  We typically say that a bipolar junction transistor turns on when $V_{BE}$ is greater than 0.6V or 0.7V.  In reality they do turn on a little bit before that, but the operation in that area is very non-linear.  In any case, around what we could consider the middle of the signal (where it would cross zero), the transistors don't quite turn on creating distortion.  The diodes pre-bias the transistors by that 0.6-ish volts we need to turn them on.  With the op amp trying to track the output, it'll adjust for that bias and smooth things out.

An exaggerated example of crossover distortion

Although this circuit worked plenty well with an ample power supply, it struggled when using the phantom power.  I'll show how it was done in the next post.

PS3 Cooling Fan Part 4

Last time we saw the the 555 PWM circuit wasn't so good.  But I did recall a technique a professor mentioned as an anecdote.  Generate a saw or ramp wave of your necessary frequency, and compare it to a voltage representing the desired duty cycle.  First let's make our oscillator.

This neat little circuit is one I modified from this YouTube video: Saw Generator Circuit.  It's worth watching for the explanation which I will repeat in less detail here.  R16, R17, R18, & Q1 form a constant current source which charge C3 in a linear fashion (as opposed to the logarithmic fashion a constant voltage source would produce).  R11, R19, R20, Q2, & Q3 form the discharge circuit.  When the voltage on C3 is about a diode drop above the base voltage of Q2 (which is set by the R19 & R20 voltage divider, so VCC*10/11), Q2 will turn on, consequently turning on Q3.  At this point the base voltage on Q2 is predominantly set by the voltage divider of R11 & R19, which is VCC*1/11.  C3 will continue to discharge until that threshold is met and Q2 turns off, resetting the cycle.  Q5 and the 10k pot form a voltage follower output buffer that can scale the resulting waveform and minimizes any parasitic effects on the generator itself.  "Saw" represents the signal that would feed a comparator.
I can't really vouch for the values I show in the rest of the circuit, they were tweaked as needed to get the frequency I needed.

Now you may notice that my fan driver differs from our previous discussion.  This is what I drew at the time and I don't entirely recall why.  Maybe so as not to invert the PWM signal?  So I'm just using the Op Amp as a comparater between "Saw" and "TEMP_SET", which is some voltage reference.  Below shows how the duty cycle changes relative to temperature changes.  You can see how the output wave changes wherever the saw wave and the temperature level intersect (blue = temperature, red = saw).

Blue = TEMP_SET, Red = Saw, Green = PWM Fan Drive

So I ended up building this up and trying it out.  I believe I started off around 18--20KHz before figuring out that a 100Hz was more appropriate.  And it did work....  Ish.  I could blast the diode with ;heat and the fan would speed up and slow down, however it had a loud and distracting kicking sound related to the PWM frequency.  Awful in fact.

Time for another approach.

PS3 Cooling Fan Part 3

It looks like we're going to work backwards here, because now we're going to look at the PWM generator.  I'm actually just going to discuss my first (bad) idea here as best I can and revisit this part one or more times in the future.  Unfortunately I can't recall all the details of my initial circuit, only that it didn't work well and why.  This post won't have many pictures and will be mostly anecdotal.
My first thought was to use a 555 timer.  And why not?  There are tons of PWM application examples in datasheets and around the internet.  However, most of these circuits are just variations on the astable multivibrator circuit where a potentiometer is used to vary the duty cycle.  We do have a start though.

Astable Multivibrator from TI NE555 datasheet

Our temperature sensor will be providing us a control voltage, so the pot is out.  The "Control Voltage" (or "CV" or "CONT" on some drawings) looks interesting though.  Perhaps I can just throw my sensor output in there and see what happens.
Before going any farther I'll mention a little research that led me astray.  I had wanted to find an appropriate PWM frequency so I searched the internet for something like "atx fan pwm".  I found several articles by hobbyists as well as some white papers by control IC vendors on the subject.  It quickly seemed apparent that something around 20kHz was common, as it was outside the audible spectrum.  I'll fast forward to the end and tell you that higher frequencies only works on 4-wire fans, and that your typical 3-wire fans need something lower, like 30-200Hz.  But that wasn't the only reason my 555 circuit sucked.
So I tuned my 555 circuit for close to 20kHz, fed my sensor voltage (we'll discuss it later, let's just pretend it works for now) into the "Control Voltage" pin of the 555 and powered it up.  I'll apologize for not having oscilloscope captures before describing the waveforms...... sorry.
First of all, rather than spinning, the fan kinda kicked a little and gave off a high pitched squeal.  Blasting the the sensor (again, a diode) with a heat gun illuminated another problem.  I mocked up a 555 circuit in LTSPICE to show what happened:

This one I kinda saw coming.  The duty cycle is changed by leaving the off time constant and just extending the on time.  And as a consequence, the frequency changes too.  All around, not a good plan.
We'll try another circuit in the next part.

Testing with a heat gun.  Probably shouldn't leave it on the papers.

Daylight Logger for Gardening Part 3

Now that we've covered the function and design of the logger device, let's look at a few of the obstacles.

Unexpected Data:

One of the functions that needed to be coded and tested early on was dumping the light data to a PC.  I used a C# program that I wrote for doing two way serial communication and added features to have to send and show data in either ASCII or hex.

So the issue I ran into was that data seemed to be getting distorted, specifically for sunny conditions.  I wasn't seeing any values greater than 0x7F, which is the maximum ASCII value (7 bits).  However this wasn't immediately noticeable as most of the values I was receiving were 0x3F.  It almost looked like maybe there was a memory issue and that was a default value of some sort.  My other thought was that maybe there was a baud rate issue and I kept losing that first bit somehow.  I was pulling at straws.  I spent a whole bunch of time looking at scope captures of the data and measuring pulses manually to compute the baud error to no avail.  Then I took note of how the ASCII value of 0x3F is a '?'.  Maybe there was something to that.

So I started poking around in my C# code for a reason that portions of my data was being converted to '?'s.  I was using hte built-in SerialPort object that is part of .NET and upon received data used the "ReadChar()" method because it returned printable characters.  I had added the ability to print hex as an afterthought, and as such, simply formatted the returned value as a hex byte when printing to the window.  Seeing as the "ReadChar" method actually returns an integer value, I assumed I was getting the raw data.

Turns out I was wrong.  The SerialPort object allows for the setting of a text encoder, which I believe by default is ASCII.  And ASCII does not support values over 0x7F.  A little code rewrite using the "ReadByte()" and all was good.  My firmware or circuit were fine from the start.  Admittedly, the PC side of things is usually much easier to develop and debug, which gave me a false sense of security.  I assumed my debug tool worked because it didn't fail catastrophically (as embedded software often can).  But it usually helps to know what goes on under the hood, otherwise some issues are seemingly impossible.

Small Optomizations:
Seeing as the logger was going to run off of batteries, I took some care to reduce power draw.  I only had so many I/O pins which meant I had to be mindful of idle states when combining functions.  So for instance, I used a PNP for both the TX and the power to the ambient light sensor and buffer amp in order that they both share the same off state.  I only turn the sensor and amp on for a very short period of time, which does turn on the TX transistor (Q4), but the TX resistor is sized to reduce current draw.  It's a compromise, but at least they are both off for the vast majority of the time.  The op amp was even chosen amongst the ones I had (and ones I would have preferred to use up) because of its lower supply current.  Fortunately the memory chip only draws a 1uA while idle, leaving it power on all the time is inconsequential.  And the RX transistor is stuck off unless something unless a com port is attached.

But hardware isn't the only place to save on power.  Efficient code and good use of microcontroller features helps a lot.  The most obvious features is the SLEEP function.  In a 24 hour logging period, the device is inactive 99.9945% of the time.  By putting the MCU in a lower power state, the circuit hardly draws any power (my secondary multimeter of suspect accuracy claims around 60uA, which actually seems a little high).  This amounts to about 1.5mA hours spent idling over 24 hours.  Not too bad.

But some code efficiency can also help.  Ideally, you don't want to be waiting for anything if it can be helped.  In my case, it took a certain amount of time for the sensor output and internal voltage reference to settle when the MCU woke up and turned everything on.

Green line shows the sensor being turned on and off once sampled.  Yellow line is the data signal going to the memory (clock signal would have been better, but you get the idea of  the time it takes).  MCU turns on at the start of green signal and off and the end of the yellow signal.

I didn't like the extra waiting and realized I could save a bit of on time by writing the next address to the memory while things settled.  This knocked the system on time from about 10ms to 7ms.  It may not seem like much, but that's a 30% reduction in total awake time for the microcontroller over the whole 24 hour cycle.

Should have captured the same signals as before.... Green line is the clock signal to the memory, and Yellow line is the light sensor output.  The important thing is that the signals overlap instead of happening in sequence.

Another savings in power is running the MCU at a lower frequency.  Nothing going on here is that time critical, and even at my 500KHz clock, the micro is still fast compared to the analog sensor setup time.  But if running slower also means running longer, it may not net you a total power savings, keep that in mind.

Improvements:
There are of course other improvements to be made on this device though I'm not unhappy with its current state.  Larger resistors can be used for both the I2C pull-ups and for the TX and RX bits of the circuit as the data rates for both are rather slow.  Mechanically I can shade the light sensor so that the sense resistor can be made larger reducing its current draw.  It'd also be nice to slap in a bluetooth module making connection to a computer easier.  Maybe some day....

Phantom Powered Bass Buffer Box Part 3

We're already up to part 3 for such a simple device.  That's engineering though.  A thousand little interconnected details and considerations so that a design can work all the time, every time.  Without even realizing it, we have very high expectations of the products we use.  As the complexity of a device increases, so does the work necessary to make sure all the pieces work together over a broad range of conditions.  Moving on....

Click to enlarge.

The new and improved buffer box requires no external power but the sound sucks.  And hardly unexpected.  That 100nF output cap just doesn't cut it.  We have a first order high pass RC filter when plugged into the mixer.

For those familiar with RC circuits, the cutoff frequency is determined by Fc = 1/(2*PI*R*C).  Just by observation we can see that as R or C get smaller, the cutoff frequency goes up.  Plugging R_Out, R_In, and C_Out (ignore C_In for now) into the equation gives us 578Hz.  The low E on a bass is about 41Hz.  The series combination of C_In and C_Out will yield an overall smaller capacitance meaning that the actual cutoff frequency will be higher.  So I did some empirical tests using different output capacitor values:

The solid lines are of most interest as they show the frequency response thru the mixer.  It took a 100uF cap to get that flat green line.  With both the 100nF and 4.7uF caps, the cutoff was above 1000Hz.  That explains the bright sound.  It is kind of interesting that the no load response wasn't flat like the green line, considering the large input resistance of the scope probes,  Perhaps the AC coupling cap inside the oscilloscope in series with the output cap had an effect?  Not entirely sure, nor is it as critical as the loaded response.

So why did this circuit work prior to the phantom power modification?  As it turns out, the original design still had to go thru a 1/4" to XLR adapter.  And the particular adapter being used was more than just a couple of point to point wires, it had a transformer inside.  The transformer presented a higher impedance (something like 40K ohm) which brought that cutoff frequency down quite a bit.  Not enough impedance for a bass or guitar to drive directly, but a keyboard, effect pedal, or even buffer box would have no problem.  By adding the XLR connector directly to my buffer box, I removed the adapter and exposed a design flaw.  With a 100uF cap in there, things are sounding good with very low noise.

Measuring sin waves

I would have done a little more tweaking, but they don't have a lot of down time (the bass is used twice a week).  This was a scenario where the details mattered in a very obvious way.  Engineers have to learn to recognize the causes for certain outcomes, and sometimes it's only one component that makes for all the problems.

Added a piece of an iron spike to give it a little weight.  Otherwise
it felt like an empty box.  I wanted people to take it seriously....

Phantom Powered Bass Buffer Box Part 2

The buffer amp I built up from the last post served well for awhile, but I never liked having a power supply involved.  After the addition of a few parts I was able to take advantage of the phantom power supplied by the mixing console.

A couple of things to note in this design.  First, there is that middle contact on J1 that I connected to ground.  This keeps things nice and quiet when nothing is hooked up.  When a cable is inserted, the plug physically breaks the connection between the grounded contact and the signal contact.

The next item to look at is the signal output.  The audio is being carried over pin 2 of the XLR connector, but what's is with the stuff connected on pin 3?  If we look at the mixer side, we see that whatever signals are carried on pins 2 & 3 will be subtracted from each other via an op amp.  When a microphone is used, it will actually present a differential signal to the mixer input.  Any signals present on both pins will cancel out, and the difference between the signals becomes the amp output.  But I only have one signal, right?  Ideally yes.  However, the cable carrying the two signal lines will be subject to all sorts of noise.  So pin 2 will carry the desired audio signal plus some noise, while pin 3 will only carry the same noise as pin 2.  When they get subtracted, all that is left is the audio.  C4 & R7 are chose to match the frequency response of the JFET buffer output, which essentially makes a high pass filter (this ensures that the noise on both lines is filtered similarly).  C4 can just be made equal to C2, but R7 has to be calculated.  I did this by running a 1KHz tone through the buffer with no load and with a dummy load to determine the voltage drop internal to the buffer.  I took the measurement prior to C2 so that I would not get any reactive component to my values.

Simplified circuit showing only power related parts.

Lastly, there is the phantom power circuit.  It's pretty simple and ingenious.  The mixer applies a DC bias to both audio carrying conductors, which the device just has to tap off thru a pair of equal resistors.  Capacitors at the inputs and outputs block that DC from the signal drivers and receivers, making the rest of the circuit none the wiser.  You do have to be careful though, as the more current you draw, the less voltage you will have to bias your circuitry.  That's where the zener diode comes in.  It will draw whatever current is needed to get the voltage drop across the 6.8K and 10K resistors to leave us with 12V.  As long as the current thru the zener is greater than any current your device needs, we'll have a steady enough voltage rail.

So after the solder smoke cleared I plugged the buffer amp into the mixer and happily watched the LED light up.  I hooked up an electric guitar and..... well..... it was punchy enough, but piercingly bright as well.  This wasn't a huge surprise, but I had gotten away with the circuit up until now so wasn't going to change it at first.  C2 is the problem.  It's too small.  It was creating a high pass filter with the mixer input that didn't include any of the bass.  Or mid tones.  But it had worked well for years right?  Yes, and I found out why, and I'll tell you all about it in the next post.

Phantom Powered Bass Buffer Box

It may seem like a lot a lot of projects going in parallel, and that is partially cause I do, and partially cause it takes a lot of time to do a write up.  I'm hoping this project doesn't go more than one or two posts as it's already completed and pretty small.

Backstory:
A few years ago I made a little signal buffer for a church as I saw that they were plugging their bass guitar directly into their mixing console (almost directly, but more on that later).  And to make it worse, they were using the XLR mic inputs instead of the line inputs.  To be fair, they didn't have much choice.  A cable snake ran from the sound booth in the back of the room under the floor and to the stage, where several panels of XLR connectors at the stage allowed for the connecting of mic's and instruments.  The problem here is that the bass is a single ended high impedance output, and the mixer mic inputs are quite low impedance.  The result is a weak and unenthusiastic tone, susceptible to noise (the passive pickups are pushing a signal over about 100 feet of cable).

A simplified model.

As a rule of thumb (at least for guitars), the input impedance of a device should be at least 10 times greater than the output impedance of the thing driving it.  This will ensure that the audio signal is preserved with little or no effect on tone.  As an example, a guitar might have around a 10K$\Omega$ output impedance, and a mixer line input is often around 10K$\Omega$ as well.  That's a 1:1 ratio.  The XLR mic inputs go down closer to 1K to 2K$\Omega$.  If we look at this as a voltage divider, we can see that much of the signal seen by the mixer is attenuated.  By half if using the line input, and only around 20% or so of the voltage appears over the mic inputs.  There are also reactive elements in the guitar too; ultimately, the larger the input resistance, the less impact there will be on the guitar circuit.

So what can be done?  Well generally you'd use a direct box.  These passive devices(though there are active ones too) use a transformer to well.... transform the impedance.  These things can range in price and performance.  Also, pretty much any guitar effect pedal or amplifier with a preamp output solves the problem too.  But what fun would that be?  So I built them a JFET based source follower out of parts I had and called it a day.  It has high input impedance, and low output impedance, problem solved.

JFET Q1 as well as R1 & R2 all present high impedance paths for incoming signals.  J3 plugs into a 9V wall transformer.

And despite an inherent design flaw, it worked well.  But recently I was designing phantom power into a headphone amplifier and that got me thinking: why not do the same for this project.  So I did, and I'll continue this in another post.