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.