So, this is a project that was nearly a month in the making.  I set out to make a sound-reactive EL panel but found that driving EL in such a way is actually kind of difficult.  If you've been following the blog, I've been working on this project in one way or another since my transformers article, and it's actually the reason I wrote that article.

Again, a disclaimer. There are over 8,000 words in this post that document all of my design decisions on this project.  It is not a how-to guide, but if you have some background in EE, I hope that you gain something from it.

Without further ado, let's get down to business.

The Problem With EL

EL materials (wire, tape, panels) are an odd bunch.  No matter where you look, EL panels seem to be always be made very cheaply and with very little documentation.  There doesn't seem to be any "pro" version of the stuff.

Also, because it is primarily used in costume design (and not real lighting applications), there are very few Electrical Engineers tackling the issue of powering/controlling it.  As a result, you get some hilariously bad attempts at doing cool stuff with EL.  My personal favorite is this one where a blogger discovered that blue EL wire turns greenish at lower frequencies.  I'll spare the details of the issues with his design, but this excerpt should tell you everything: "Please note that many audio transformers are potted with a low melting point wax and can get warm enough to leak and fill the holes of your breadboard!" (It's great that he's experimenting around, but when that's one of the better resources out there, that's a problem for rising hobbyists).

So my goal with this project was to try to exert more sophisticated control over EL materials.  So far, everyone can seem to make EL blink fairly easily (like this asshole), but if I know my electronics, fancy gadgets don't have blinking lights, they have pulsing lights that fade in and out gradually. This is usually because blinking a light is much simpler than dimming one.

So I want to make a dimming EL panel driver.  And what the hell, let's make it react to sound too.

Design

So, this design originally started as a commissioned piece from a guitarist who wanted something cool to wear at concerts.  He didn't have any ideas of his own, so I cooked something up for him:

Basically, the idea was to have an EL panel under his shirt that would pulse and light up to music.  All of the "brightness curve over song" stuff ended up flying out the window during the project, but seeing how that would all be controlled by the on board micro controller, it didn't really matter as I could change it at any point.

So I needed a small battery powered EL panel driver that could pulse and dim the panel by software control.

I purchased this panel.  It's exactly half the size of a standard sheet of printer paper.

Just for fun, I tried plugging the panel into one of my standard EL wire drivers and found that it completely failed to light up.  I guess the panel provides too big of a load for the puny wire driver.

Interestingly you can get a faint glow by plugging it straight into a 120V socket.

Electroluminescence

Update:

What follows is an early attempt to model EL materials.  While I still maintain that it's a better model than the one I found, new research brings to light that it too is incredibly wrong.  Most of this article focuses on the creation of a flyback converter DC power supply, so I will leave it as is for now, but expect an update of my EL wire model soon.

So as you might recall, EL wire is powered by a high voltage (120 or so) AC waveform at a few kHz.  Nobody on the internet seems to know exactly how this works.  The best that I found was this video by the lovely Jeri Ellsworth (who I might kind of have a crush on at this point).  It would seem that the changing of direction of the electric field is what causes the EL to glow.  It isn't exactly important that it gets fed a sine wave; a square wave of similar frequency might also do the trick.

So, given this information, I would guess that every time the electric field alternates, a small pulse of light is given off.  At higher frequencies, more pulses of light are given off in a given time period giving you an overall brighter appearance.  The pulse brightness is proportional to the magnitude of the voltage at which you are driving it, but there is a minimum voltage required to get it to light up at all.

It would help further discussion to have a proper electrical model of EL wire to work with.  Looking around the internet, I found this page which describes how to use EL wire and how to model it electrically towards the end.  They include this schematic:

After investigation, I think I determined that this model is wrong.  See, this model would imply that EL wire can pass DC current (it passes through the resistor), but I found the DC resistance of my EL wire to be infinite.

It does correctly predict what happens when EL wire is lengthened though: the capacitance goes up and the series resistance resistance goes down.

A more precise model is something like this:

In the previous model, it's easy to apply the rules of parallel capacitors and resistors to come up with the trends as the wire is lengthened.  With my model though, this would seem to be more difficult because the node between the resistor and capacitor is not common among all resistors and capacitors.

If you consider the situation in which all of the resistors and capacitors are of equal value (which you can do because capacitance and resistance is distributed evenly in the wire), you will notice the the center node is always at the same potential along every branch due to their symmetry.  Because of this, you can "virtually" tie them together and utilize the standard rules for summing resistors and capacitors.

This model explains why you can't drive EL wire too fast.  If you don't offer enough time for the capacitor to fully charge before discharging, then the voltage across the cap won't reach as high of a level.  In image form (with a square wave input for simplicity's sake):

So there is a upper threshold on how bright EL can get.  Drive at too low a frequency, and you don't get enough light pulses per second, but drive too fast and your effective capacitor voltage will drop.  It will eventually drop below the minimum threshold and your EL won't light up at all.

I also found this PDF data sheet that confirms this.  It isn't for the EL panel that I purchased, but it should at least give some ideas about EL panels as a whole.  On the top of page 3, it says "Brightness increases with higher frequency up to 1000Hz".  This also helped to confirm for me that apparently EL panels don't get driven at quite as high of frequency as EL wire (1kHz vs 3kHz).

I have to include a disclaimer here because I do not have the most thorough understanding of the chemistry of EL wire and my explanation here is just what I've gleaned from other websites and what I've researched on my own.  If you find something wrong with my explanation please let me know and I'll be sure to update the post.

So, it would seem that I simply need to find a way to vary the driving frequency in order to vary the brightness.  The only problem is that I also need to keep the voltage of my waveform constant.  This complicates things as just about every single EL wire/panel driver circuit out there uses a resonant driver which doesn't really give you options for variable frequencies.

I could have also just tried using a standard step-up transformer and driving it with a square wave, but this also presented a problem as I would need to have the ability to drop the frequency down as low as 60Hz.  Remember that a transformer is kind of like an inductor which carries the following formula.

$\Large V = L\times \frac{di}{dt}$

Which can be manipulated to give:

$\Large V\times \Delta t = L \times \Delta i$

At lower frequencies (like 60Hz), $\Delta t$ is much larger.  To keep the current ($\Delta i$) from ramping up too much (and making resistive losses a bigger deal), $L$ must be increased a lot.  This will result in a very bulky transformer as you will need a lot of windings and a large core to get a very high inductance.

Because I've decided to drive my EL panel with a square wave, there might be a much easier way to do this.

Seriously, ask any of my friends.  I haven't been able to shut up about this all week.

Disclaimer

What follows is a very math/physics intensive and very dry explanation of some of the unique properties of inductors and transformers.  I originally intended to try to spice things up by making this post into a video "chalk-talk" where I could talk through my math, but after numerous attempts, I have realized that I do not have a concrete enough understanding of these topics to put myself on the spot like that.  Hopefully this post will suffice.

If you find any mistakes in my work, please let me know!  I'll be sure to update it.

A Terrible Discovery

The morning after publishing my EL wire post, I decided it would be fun to check my work.  In the post, I determined the turns ratio of the supply's transformer by measuring the inductances of each winding and taking $\frac{\sqrt{L_{1}}}{\sqrt{L_{2}}}$ to get the turns ratio.  I came up with approximately 1:22.

This seemed to make sense because the input/output voltage ratio was approximately 1:22 as well (5V-ish in, 100V-ish out). Well, I set to work disassembling one of my transformers to count the windings:

There was a layer of protective tape around the wires and of course the inductor core itself. The core was comprised of two E-shaped pieces that were glued together. Unfortunately, I was unable to get to the wire without breaking the core apart. The primary winding came off easily:

I counted about 30-35 windings on each of the two taps. The secondary winding wasn't as easy to unwind.  It was made from extremely thin wire that broke about 15 turns in.  At this point, I was unable to find the end of the wire (like when you lose the end of the scotch tape), and decided to take a different approach:

Nothing a dremel couldn't fix.

Now all I had to do is count how many bits of wire there were.  Sure, it's a little tedious, but I only expected there to be 600-800 (22x30) of them, so it couldn't be too bad.

Ok, that is a lot of wire...

So I started counting, and got a little concerned when I reached 700 and didn't seem to be even close to done.  When I got to 1000, I knew something was wrong.

Okay, so this sucks.  Clearly my ratio is much higher than 1:22.  How high is it?

Bringing in the Big Guns

I needed a better method of measuring inductance.  For this, I turned to an Agilent LCR meter that I borrowed (they usually run around $400).  Here's what it came up with for the secondary winding.

414 mH is not that far away from the 450mH I estimated in the last post.  Not too bad. Now for the primary winding:

98 $\mu$H, that's not too ba-wait.  I got 900$\mu$H last time!

This thing is measuring an order of magnitude lower! At first, I thought I had maybe made a math error seeing how close I was to being exactly an order of magnitude off.  Further examination and re-checking of measurements revealed that my math was sound, so something else had to be wrong. In the short term, this cleared some things up.

Assuming the LCR meter was correct (and it was), my turns ratio is actually $\frac{\sqrt{414mH}}{\sqrt{98\mu H}}$ which works out to 1:64.  This means that because my primary winding was 30 turns, my secondary was 1920!  That seems so much closer to the right number.

So What Did I Do Wrong?

The particularly strange thing is that I was able to find the same erroneous number through two different methods.  This leads me to two main questions:

• If the inductance of the primary coil is actually 1/10 what I measured, how did I repeatedly get the same (wrong) value using my measurement method?
• If the turns ratio is actually much higher, why don't I get a higher voltage at the output?

Parasites

So, let's review my method for determining the inductance of the primary winding.  When a capacitor and inductor are placed in parallel, they set up an LC oscillator.  If the oscillator is excited, current will begin to flow back and forth.  Essentially, energy is moved from the inductor to the capacitor and back again.  When the capacitor is fully charged (maximum energy) there is no current flow (minimum energy in the inductor) and vice versa. The important thing for me is that the frequency of this oscillation is based on this formula:

$\Large F= \frac{1}{2\pi \sqrt{L\times C}}$

The $F$ is the resonant frequency, $C$ is the value of the capacitor I placed in parallel, and $L$ is the inductance which I'm trying to find. Here's a doodle of my oscillator:

There's just one thing wrong with this particular doodle.  It shows my inductor as an ideal inductor.  This is far from true. Inductors usually have some level of parasitic capacitance.  This is a result of having a bunch of insulated copper wound up into a small space, and it's a sometimes undesired effect that isn't easily avoided.

Though my inductor is not an ideal inductor, I can model it as one as long as I throw a parallel parasitic capacitance along with it.

Because these capacitances are in parallel, I can simply add them.  So now my equation becomes.

$\Large F= \frac{1}{2\pi \sqrt{L\times (C+C_{P})}}$

With this in mind, I ran the experiment again a few times.  I also cheated a bit.  Since I already knew what the inductance was, I instead solved for $C_{P}$.  If I didn't know the inductance, I could have found $C_{P}$ and $L$ at the same time using a system of equations and two data points. Here are my results:

So after running the experiment three times at three different capacitor values, I got similar results for parasitic capacitance. That's reassuring. My inductance appeared to be higher because I was making the poor assumption that the capacitance was lower (i.e. $C_{P} = 0$):

$\Large \frac{1}{2\pi \sqrt{L\times (C+C_{P})}} \approx \frac{1}{2\pi \sqrt{(L+L_{error})\times C)}}$

So if you're not careful, the same resonant frequency can get you different values for $L$.

Another cool note is that if you know the inductance (by reading it off a data sheet or something), you can quickly determine the parasitic capacitance by setting up your LC with no C at all!  The parasitic capacitance can be enough to get your inductor to self-resonate.

It's also worth noting that my original measurement for the secondary winding wasn't nearly as far off because the parasitic capacitance on the secondary winding was much smaller (I measured about 1.9nF)

So why didn't this capacitance effect the LCR meter?  Well, because it was $400 obviously.

Set Phasors to Stun

So, having this solution gave me temporary respite, but it still couldn't help to explain why my input/output voltage ratio was wrong. Typically, voltage ratios are determined as follows:

$\Large \frac{V_{2}}{V_{1}} = \frac{N_{2}}{N_{1}}=\frac{I_1}{I_2}$

So, how can it be that my output voltage wasn't 64 times my input voltage?  Again, I was assuming that my components were acting ideally. To solve this problem, I had to do a major refresher course of just about everything I learned in school.  Looking for a solution, I came across my notes for an old power electronics lab class I took.  As it turns out, Lecture 13 was on this very topic, and I still had the handout from that lecture!

Protip: Never throw anything away ever.

What follows is my attempt to work through the explanation offered in the notes.

Stick to Your Ideals

Let's first consider an ideal transformer:

An ideal transformer is one where all of the magnetic fields generated by one winding pass through the other winding.  In reality, magnetic fields will tend to fray out and pass through gaps in the windings.  We can reduce this effect by using special materials in our transformer cores that are said to have a low "Reluctance".

Similar to electricity traveling in the path of least resistance, magnetic fields will travel along the path of least reluctance. So these magnetic cores keep the magnetic fields in line. The total magnetic field passing through a coil is called the Magnetic Flux and is signified with a capital phi ($\Phi$).  This is basically, the magnetic flux density multiplied by the cross sectional area.

$\Large \Phi = B\times A$

Makes sense.  A density times an area gives you a quantity.  The flux passing through a coil (or rate of change of that flux) will determine things like the voltage across the coil, so it's generally good to know.

Keep in mind though that a piece of wire doesn't really know anything about the geometry of the magnetic field. It only cares about how much magnetic flux is passing through the overall loop.  It can't tell if it is wrapped many times around the same small area or once around a much larger area:

So, we usually don't deal with flux for transformers. We instead work with "flux linkage".  Flux linkage ($\lambda$) is simply the magnetic flux through the core multiplied by the number of windings in the inductor:

$\Large \lambda = \Phi \times N$

For a single winding inductor, $\lambda = \Phi$. It also happens that the flux linkage for a component is equal to the time integral of the voltage across it:

$\Large \lambda = \int{V} dt$

So, if we know that all of the flux in one winding of the transformer also passes through the other winding (ideal, remember?) we get:

$\Large \frac{\lambda _{1}}{N_{1}} = \Phi = \frac{\lambda _{2}}{N_{2}}$

$\Large \frac{d}{dt}(\frac{\lambda _{1}}{N_{1}})= \frac{d}{dt}(\frac{\lambda _{2}}{N_{2}})$

$\Large \frac{V_{1}}{N_{1}} = \frac{V_{2}}{N_{2}}$

Hey! Look familiar?

What Makes You So Perfect?

So what exactly gets a transformer closer to an ideal transformer?  Lets first model our transformer as a magnetic circuit.  Just like you can model electric circuits with resistors and voltage sources, you can model magnetic circuits with coils and reluctances.

So what do I mean by magnetic "circuit"?  Well, you've probably been wondering why it seems that transformer and inductor cores always seem to form loops such as in this torroidal inductor:

Or even in the E shaped core of the EL wire transformer:

Where there are actually two loops around the outside of the wire coil.  This isn't always the case though.  There are a number of bar-core inductors that do not produce a loop.  In this case, the bar starts the loop, but the loop is completed by the space surrounding it.  Surely you've seen one of these:

Where magnetic fields travel through air just fine.  As you will see though, this is far from ideal and will create a poor transformer.

So remember how magnetic reluctance ($\mathcal{R}$) is sort of like electrical resistance?  Like resistance, it's a property of the material that is creating the circuit loop.  In this case, it's a property of the core of my inductor or transformer.  The lower the reluctance, the more easily magnetic fields form inside the material.

In the case of an non-looping core, you would take the reluctance of the core along with the reluctance of the air completing the loop and sum them just like summing resistors in series. In fact, even in the looping inductor core, it's safe to say that not all of the magnetic fields pass entirely around the loop inside the core.  Some of them will leak out.  This is similar to having two resistors in parallel.  The core will represent a low-reluctance, and the air surrounding will represent a larger reluctance.  Most of the flux will pass through the lower reluctance path, but not all of it.

The formula for reluctance is:

$\Large \mathcal{R} = \frac{l}{\mu \times A}$

Where $l$ and $A$ are the length and cross sectional area of the magnetic path, and $\mu$ is the permeability of the material.  I'll go into more detail on permeability later.

The only distinction to keep in mind between reluctance and resistance is that magnetic reluctance is non-dissipative.  I.e. unlike a resistor, it will not cause energy loss but will instead store energy.  Not a super important point for this discussion, but something to keep in mind.

Analogous to voltage which is the "Electro-Motive Force" we have the "Magneto-Motive Force" (Yes, I know, it sounds really corny).  The MMF (or $\mathcal{F}$) is measured in Ampere-turns and as its name suggests is equivalent to:

$\Large \mathcal{F} = N\times I$

Where $N$ is the number of turns and $I$ is the current.

So, to tie up our analogy, we need something magnetic that acts like current.  Well if current is the measure of electrons passing through a cross sectional area, we can use flux because it's a measure of magnetic fields passing through a cross-sectional area.  The flux through a wire coil is given by:

$\Large \Phi = B\times A$

Or more specifically:

$\Large \Phi = \frac{\mu NIA}{l}$

Where $l$ is the magnetic path length. So now we can draw a circuit representation of our inductor:

Now as far as the specifics such as what exactly $l$ is is irrelevant for this analysis.  All you need to know is that these values are equal for both turns of the inductor.

So you'll note that the MMF contributions of the primary and secondary windings are in series.  This is because we're assuming that all of the flux passing through one also passes through the other. Now let's test out this model starting with Ohm's law (but with magnetic fields).

$\Large N_{1}I_{1}+N_{2}I_{2} = (\Phi )\times \mathcal{R}$

$\Large N_{1}I_{1}+N_{2}I_{2}= (BA)\times (\frac{l}{\mu A})$

Keep in mind that $B$ is actually the sum of the $B$ fields produced in each coil.

$\Large N_{1}I_{1}+N_{2}I_{2}= ((B_{1}+B_{2})A)\times (\frac{l}{\mu A})$

$\Large N_{1}I_{1}+N_{2}I_{2}= ((\frac{\mu N_{1}I_{1}}{l}+\frac{\mu N_{2}I_{2}}{l})A)\times (\frac{l}{\mu A})$

$\Large N_{1}I_{1}+N_{2}I_{2}= (N_{1}I_{1}+ N_{2}I_{2})$

Alright, so apparently this model holds some water.  Now, we've said before that in an ideal transformer, $\frac{N_{1}}{N_{2}} = \frac{I_{2}}{I_{1}}$. That means:

$\Large N_{1}I_{1}+N_{2}I_{2} = (\Phi )\times \mathcal{R}$

$\Large \Phi \times \mathcal{R} = 0$

There are two possible solutions to this equation.  Either $\Phi = 0$ or $\mathcal{R} =0$.  The former is an obvious solution.  When there is no current in either winding, the magnetic flux is zero, so that's not very interesting.  The latter however is very useful.

$\Large \mathcal{R} =0=\frac{l}{\mu A}$

So if you want your transformer to be ideal, you either need to have $l=0$ or $\mu A=\infty$.  A zero length is going to be very hard to manufacture as is an infinite area.  That leaves $\mu=\infty$.

Let's Talk About Mu

$\mu$ represents the "magnetic permeability" of a material.  Permeability describes the capacity of a space to hold magnetic fields.  A vacuum has a permeability (written $\mu _{\circ}$ or "mu naught") which as it turns out is very close to that of air.

As manufacturers try to make better and better transformers, they try to find better and better materials for the core. They record their $\mu$ usually as a coefficient of $\mu _{\circ}$ sometimes called the "relative permeability" and written as $\mu _{r}$.  The goal is to have an infinite $\mu$, but they usually top off at about 2000 $\mu _{\circ}$ for commonly used materials like the ferrite in my core.

Unfortunately, $\mu$ is not a constant value inside an inductor.  A lot of times, as more and more magnetic field builds up in the core (more current travels around it), the permeability of the material drops.  You can see this happening in this graph:

Which I stole off of this data sheet for powdered metal cores.

This loss of permeability is called "saturation" and is caused by the reorientation of little magnetic dipoles inside the core material.  As a field builds up, dipoles are aligned.  When there are no more dipoles left to align, permeability drops.  I know this is a very vague explanation, but a thorough understanding is not necessary for this discussion.

Without knowing anything really about my transformer core, I want to hypothesize that my odd voltage ratio (lower than the turns ratio) has something to do with the transformer core saturating.  Let's see if I can demonstrate this trend mathematically.

Not So Perfect After All

So, let's go back to our flux linkage equation:

$\Large \lambda = \Phi \times N$

And be a little more explicit about exactly what this means.  There will be two flux linkages (one for each winding) and the flux in each winding is partially due the its own current and partially due to the current in the other winding.

$\Large \lambda_{1} = (\Phi_{1} + \Phi_{2})\times N_{1}$

$\Large \lambda_{1} = (\frac{\mu N_{1}I_{1}A}{l} + \frac{\mu N_{2}I_{2}A}{l})\times N_{1}$

$\Large \lambda_{1} = (\frac{\mu N_{1}^{2}I_{1}A}{l}+\frac{\mu N_{2}N_{1}I_{2}A}{l})$

If you look at the first term, you'll see something familiar:

$\Large L=\frac{\mu N^{2}A}{l}$

It looks like the formula for an inductor!  We can call this "self-inductance".  It's the amount that the first winding acts like an inductor as if the second coil wasn't there.  That leaves the second term where the $N^2$ is actually $N_1N_2$.  We can treat this as an inductor and call it "mutual inductance".  It basically indicates how well linked together the two windings of the transformer are.  So, we can rewrite this as:

$\Large \lambda_{1}=L_{11}I_{1}+L_{21}I_{2}$

Likewise, $\lambda _2$ can be written as:

$\Large \lambda_{2}=L_{12}I_{1}+L_{22}I_{2}$

So, to play with our new formulae, let's set up a fictional scenario where the primary winding is attached to a cosinusoidal current source and the second winding is attached to a resistive load:

In this case, $I$ represents the magnitude of the current wave while $i_1$ represents the actual current.

So, if we want to see what's delivered to the load, we need to find the voltage on the secondary winding.  We can derive this by taking the time derivative of the flux linkage of the secondary winding:

$\Large \frac{d}{dt}(\lambda _{2})=\frac{d}{dt}(L_{12}i_{1}+L_{22}i_{2})$

$\Large V_{2}=L_{12}\frac{di_{1}}{dt}+L_{22}\frac{di_{2}}{dt}$

And if we remember from Ohm's law that $V=IR$, we can set our voltage equal to:

$\Large V_{2}=L_{12}\frac{di_{1}}{dt}+L_{22}\frac{di_{2}}{dt}=-i_2R$

The minus sign is a result of $V_2$ being an induced voltage that must be opposite in sign to $\frac{\Delta \Phi}{\Delta t}$ (Lenz's Law).  That's kind of a weak explanation, but if you're looking for more solid proof, consider the case where $i_1$ is forced to be zero (circuit is opened) and the negative sign isn't there:

$\Large i_2R = L_{22}\frac{di_2}{dt}$

And you solve for $i_2$

$\Large \int i_2R = \int L_{22}\frac{di_2}{dt}$

$\Large \int Rdt=\int L_{22}\frac{di_2}{i_2}$

$\Large RT = L_{22}ln(i_2)$

$\Large i_2=e^{\frac{RT}{L_{22}}}$

This conclusion means that if there was any current in the secondary winding when you disconnected the primary winding, the current in the secondary would spiral out of control and generate infinite energy dissipation through R.  Obviously this is stupid, but if you make the exponent negative, there's exponential decay, and the current dies down in an orderly fashion.

The sign on $i_1$ is less important because it is an isolated system that can be switched around simply by altering the direction of the primary windings.

So, let's see if we can solve for $i_2$ in the more general case.  Let's use the scenario where we are driving our system with a cosinusoidal current source with magnitude $I$:

$\Large i_{1} = Icos(j\omega t)$

We're going to analyze the situation where the system has been running for a very long time and all transient conditions have died off completely.  We call this "steady state", and in steady state, all components are operating at the same frequency.  We can thus model the current in the secondary winding as:

$\Large i_{2} = \hat{i}_{2}cos(\omega t)$

Making the whole system:

$\Large L_{21}\frac{d}{dt}(Icos(\omega t))+L_{22}\frac{d}{dt}(\hat{i}cos(\omega t))= \hat{i}_{2}R$

Where $\hat{i}_{2}$ is the magnitude of the current in the secondary winding.  This kind of setup is a perfect situation in which to use phasors. Phasors utilize Euler's formula:

$\Large e^{jx}=cos(x)+jsin(x)$

where we can replace $cos(\omega t)$ with $Re\{e^{j\omega t}\}$.  We can use $e^{j\omega t}$ for our analysis as long as we make sure to take the real part of both sides at the end.  The idea is that you get all of the exponential terms to cancel out and are left with just relative magnitude and phase information for your system.

(Note, for EEs, $j=\sqrt{-1}$ like it should be)

So we can rewrite our system like this:

$\Large Re\{L_{21}\frac{d}{dt}(Ie^{j\omega t})+L_{22}\frac{d}{dt}(\hat{i}_2e^{j\omega t})= -\hat{i}_{2}Re^{j\omega t}\}$

Now, we can start to solve for $\hat{i}_2$:

$\Large Re\{L_{21}j\omega Ie^{j\omega t}+L_{22}j\omega \hat{i}e^{j\omega t}= -\hat{i}_{2}Re^{j\omega t}\}$

And we can cancel out some terms:

$\Large Re\{L_{21}j\omega I+L_{22}j\omega \hat{i}_2= -\hat{i}_{2}R\}$

$\Large Re\{L_{21}j\omega I=-\hat{i}_2R-L_{22}j\omega \hat{i}_2\}$

Now remember how $L_{22}$ and $L_{21}$ are defined and you can do this:

$\Large Re\{\frac{L_{21}j\omega I}{L_{22}}=-\frac{\hat{i}_2R}{L_{22}}-j\omega \hat{i}_2\}$

$\Large Re\{\frac{N_1}{N_2}j\omega I=-\frac{\hat{i}_2R}{L_{22}}-j\omega \hat{i}_2\}$

Now we can keep manipulating...

$\Large Re\{\frac{N_1}{N_2}I=-\frac{\hat{i}_2R}{L_{22}j\omega }-\hat{i}_2\}$

$\Large Re\{-\frac{N_1}{N_2}I=\hat{i}_2(\frac{R}{L_{22}j\omega }+1)\}$

$\Large Re\{-\frac{N_1}{N_2}I\frac{1}{(\frac{R}{L_{22}j\omega }+1)}=\hat{i}_2\}$

Now, before we bother taking the real part, you can already see some trends.  What happens when $L_{22}=\infty$:

$\Large -\frac{N_1}{N_2}I\frac{1}{(\frac{R}{\infty j\omega }+1)}=\hat{i}_2$

$\Large -\frac{N_1}{N_2}I\frac{1}{(0+1)}=\hat{i}_2$

$\Large -\frac{N_1}{N_2}I\frac{1}{1}=\hat{i}_2$

So, apparently if $L_{22}$ goes to $\infty$, we get an ideal transformer.  So (we're getting really close here) what do we need to do to approach an ideal transformer?  Let's look at the definition of L22:

$\Large L_{22}=\frac{\mu N_{22}^{2}A}{l}$

For this quantity to go to $\infty$, we need $\mu$ to be infinite! This matches our condition from before.  What happens when $\mu$ isn't infinite? The effective turns ratio drops, or:

$\Large \hat{i}_2=-\frac{N_1}{N_2}I\frac{1}{(\frac{R}{\mu j\omega }+1)}=-\frac{(N_1-error)}{N_2}I$

So my 1:64 ratio could drop as low as 1:22 and explain the voltage sag I saw at the output.

Imperfect by Design?

I've stated before that as current through an inductor rises, the $\mu$ of the core drops. Usually, you'd want to have an ideal inductor with infinite $\mu$.

In the case of this cheap power supply, a good non-saturating inductor might have been too big or too expensive, so the designer came up with a better solution. If the core saturates, the input inductance will drop (remember that $L_{12}$ and $L{11}$ also have $\mu$ in them).  This is usually a bad thing as the sudden drop in inductance can cause bad current spikes that can cause the transformer to heat up (imagine the transformer suddenly turning into a piece of wire shorted across a power supply).

This is less of a concern here because the transformer is being driven by a resonant circuit so a drastic change in inductance will result in the system just oscillating at a different frequency. What probably happened during design is that the designer realized that the core was going to saturate and rather than trying to use a more expensive/bulkier core, decided to just super saturate the one they had.  They could use every last ounce of energy storage it had by adding way more turns than necessary.  More copper wire is cheaper than a beefier core.

This also explains why you're never supposed to run these supplies with out a load.  With no current in the secondary winding, you'll end up fully utilizing that 1:66 turns ratio and get one hell of an output voltage!

Conclusion

• I was measuring a higher inductance than was present due to my ignoring the parasitic capacitance.
• The output voltage drooped because of a saturating transformer core.
• My measurement of the turns ratio through the LC oscillator and input/output voltage measurements was self-consistent entirely by chance.

So if you actually made it this far, I'm amazed.  This whole thing just started as a casual review for me and quickly turned into a brief crash course in transformer design.  I wrote it mostly as a reference for myself, but if you acquired anything from it, so much the better.

Again, if you find any errors in my work, please let me know! Shoot me an email or leave a comment.

Thanks for reading!

Boom! 100% safer!

EL Wire

For those of you just joining us, EL wire is basically a simple coaxial wire with a special phosphorescent insulator between the conductors.  When high-voltage, high-frequency AC current is passed down the wire, the insulator fluoresces and lights up.  EL wire is fairly cheap, very flexible, and it comes in a variety of colors.  I bought a pack of five 10-foot sections of colored wire with five power supplies off Amazon for less than $50.

Supplies

Like most things made in China, the power supplies that I got with my wire were incredibly cheap.  One of them was dead on arrival due to a bad solder joint, and all of them were made out of that really crappy PCB material usually reserved for super cheap toys.

So it came as no surprise that they weren't super reliable when I attached wire to my bike and started moving around.  I found that every time I went over a bump, the supplies would shut off and refuse to turn back on again until I removed the batteries.  After what became a very short and very frustrating bike ride, I decided to go home and see what the heck was up with these supplies.

Dissecting The Supplies

Each supply consisted of a simple 2-AA cell battery holder and a small PCB pictured here:

Like any voltage step-up device, there would need to be something to switch current on and off through some kind of transformer.  My original thought was that the small micro-controller on board was responsible for setting the switching frequency, but I was mistaken.

All the micro did was control the four different functions of the EL wire supplies: off, on, blink slow, blink fast (real awesome feature set guys!).  The reason the circuit would not power up after a jolt is probably due to the micro controller browning out after a brief disconnection of the batteries.

To turn on the EL wire, the micro simply had to pull down the gate of the PFET labelled SS8550.  This FET would pass current to the rest of the circuit which as it turns out was an analog oscillator.

Things got a lot more complicated suddenly...

SPICE Up Your Life

I've never been super awesome at purely analog circuits, so bear with me here.  I quickly scribbled the circuit down in LTSpice which is a free circuit simulator made by Linear Technologies.

Bear in mind that the actual transistor used was a D1616, but I used the 2N4401 because it's another generic NPN transistor that LTSpice already makes available.  Also note that the D1616 has a rather unconventional pinout for a TO-92 package.

L1 and L2 make up half of a transformer.  The other half (not pictured) is connected across the conductors of a strand of EL wire.  The idea is that if this circuit can dump a lot of current through L1/L2, it will induce current through the secondary winding.  Because the secondary winding has a much larger number of windings, its output will be at a much higher voltage.

To tell LTSpice that L1 and L2 are wrapped around the same inductor core (and thus share mutual inductance), I added the directive "K L1 L2 1".  This means that L1 and L2 are linked with zero leakage (100%).  I learned a valuable lesson about LTSpice while doing this:

For about the first three hours of my head scratching, I was using a label as a SPICE directive and LTSpice was thus (justifiably) ignoring it.

Measuring Inductance

For my spice model, I simply guessed at the actual values of L1 and L2, but for fun, I decided to a attempt measuring them directly.  More important than knowing the inductance per se is knowing the turns ratio of the transformer.  The turns ratio is literally the ratio between the number of times the primary winding is wound around the inductor core to the number of times the secondary winding is.  The winding ratio is directly proportional to the voltage ratio of the input to output.

The turns ratio was easy to determine once I measured the inductance of the primary and secondary windings.  To do this, I built a simple LC oscillator.  By measuring the period of oscillation, I was able to approximate the inductance of my transformer.

Determining the pinout of an inductor is a pretty easy task.  Basically, although there is no resistor inside an inductor, the windings themselves will have some DC resistance simply because of how long and thin they are.  I measured about 1ohm of resistance between the center and the ends of the center-tap primary winding and about 300 or so ohms across the secondary winding.

To further confirm, I took a look at the windings themselves.  Here's a photo of one of the non-center pins of the primary winding:

And here's the center pin:

Notice the two wires?

Here's a simple schematic of my resonant circuit:

The formula pictured above is the formula for the resonant frequency of my LC filter.  Basically, when the circuit is "flicked" (has a voltage source suddenly connected or disconnected) it will vibrate at that frequency.  If that frequency could be measured, I could use the known value of C (23nF) to determine the value of L (inductance).

First, I measured the secondary winding of the transformer:

Disregarding that the voltage spike was large enough to peak out my oscilloscope, I measured the resonant frequency to be about 1.6kHz.  This corresponds to approximately 450 milliHenries.

The primary winding has two parts (because it is center tapped).  I first measured from the center tap to one of the ends:

This had a resonant frequency of about 35.7 kHz corresponding to about 903uH.  Running the center tap to the other end produced similar results.  Note that in my LTSpice model, I made L2 much much larger than L1.  This is because LTSpice is very finicky about getting oscillators working, so I had to tweak the values to get the desired affect.

Remembering that a transformer is nothing more than two inductors wound around the same core, I had to determine the ratio of the inductances of the two windings.  According to Wikipedia, the formula for the inductance of an air-wound inductor (one without a magnetic core) is as follows:

The only difference between an air-wound inductor and a magnetic core-wound inductor is the value of µo (the "Permeability of Space").  µo is a universal constant which is used when your inductor has a vacuum core.  Otherwise, you use µ which is a ratio between the permeability of the core material and the fundamental value in a vacuum.  As it turns out, µ for air is very close to µo.  µ for ferrite cores is much much higher by design.  µ is a chemical property of the core's material and is much higher for magnetic material cores than air cores.  Chemists are always trying to think up better materials with higher values of µ.  If µ gets larger, everything else (including the size and weight) can go down.

So, in this formula, A is the cross sectional area of the core, l is the length of the core, K is some special coefficient, and N is the number of windings.  With the exception of N, all these values are properties of the inductor core and are therefore the same for both windings.  So my winding ratio is as follows:

Using the values I determined, the winding ratio is approximately 1:22 which seems like a reasonable turns ratio.  If my primary winding is clocking along at 3V or so (battery voltage), the secondary winding will be at around 75 volts.

Update: This is wrong!  See details here.

Dissecting Their Circuit

So, returning to the power supply circuit, I set about understanding exactly how it works.  I believe it's some sort of blocking oscillator, but they might have made a few mistakes when designing it.

The oscillator is first turned on by pulling the gate of M1 low.  This allows current to flow in through R2, the base of Q1, and eventually through L1 to ground:

Because L1 and L2 are coupled together, this ramping up of current through L1 should cause current to flow upwards through L2.  You can think of it as L2 trying to "cancel out" the net change in current through the inductor.

Because we're dealing with high-ish frequency stuff here, current passes right through C1. This current hits the base of Q1 and turns it on even harder acting as a sort of positive feedback loop.

Now, I'm not entirely certain what happens next, but my guess is that eventually the current through L1 reaches some kind of steady state.  Because the current through the inductor is no longer changing, the current through L2 dies off.  With less current supplying its base, Q1 begins to shut off.

As Q1 shuts off, current through L1 also starts to die down.  L2 again tries to fight this change in current and starts inducing its own current downward to compensate.

With current being actively pulled away from its base, Q1 shuts off even harder producing yet another positive feedback loop.  Once the current drops to zero, the whole process restarts.

As far as I know, R1 and C3 are only there to filter out any super high frequencies from hitting the base of Q1 and causing possible issues with EM radiation or whatever.  Still seems odd for two reasons:

1. C3 is tied to the +V rail when usually one would expect it to be tied to the negative rail.  I suppose it really doesn't matter either way and +V was definitely more convenient layout-wise.
2. A 33pF cap and 82 ohm resistor make a filter with a cutoff frequency of 58.82MHz which seems insanely high to actually do anything productive.  Oh well.

Despite my minimal grasp of the tenets of analog circuit design, there's one thing I don't like about this oscillator.  They have an NPN transistor with the emitter tied to a floating line.  This means that they can't really guarantee that a positive voltage at the base will turn on the transistor if there is a large voltage drop across L1.  For all I know, this might be the whole point, but it seems odd to me.

Firing their circuit up produces a fairly clean sine wave at the base of Q1 at about 3.3kHz:

Designing My Own

For my own power supply, I decided to change things around a little bit:

Again, I had to fiddle with the values a bit, but you get the idea.  The function is similar to the original oscillator.  As Q1 turns on, L2 induces current through L1 that turns it on harder and vice versa.  The major difference is that the emitter of Q1 is tied to ground where it belongs.

C2 and R2 were placed to solve an odd problem I was experiencing.  For some reason, my new circuit worked fine without them last night, but when I tried it again this morning, I would get nothing but super high frequency (on the order of 520kHz) oscillation.

Pretty crazy right?  Anyway, at such a high frequency, the EL wire wouldn't light up.  My guess is that at such a high frequency, the inductive action of the secondary winding prevented current from getting delivered to the load (inductors look like open circuits to high frequencies, remember?). Again, I don't know exactly what was going on, but adding that RC pair tidied things up nicely:

The RC pair that I used (10ohm, 1uF) had a cutoff frequency of 16kHz, so this prevented any higher order harmonics from showing up and getting amplified.

Here's a schematic for my oscillator:

The cool part is that the whole circuit is smaller than the inductor itself, so it makes for a pretty compact design:

Efficiency

Given that I didn't exactly design this circuit so much as I guessed and checked, I was interested in finding out exactly how efficient it was.  Firstly, I compared the brightness of my circuit to the brightness provided by one of the original power supplies:

Looks about the same to me!  This was for two sections of the same type of wire that were approximately the same length.  Doing a comparison like this isn't exactly fair though because it's possible that the electric fields from the brighter wire is actually lighting up the dimmer one.  To be sure, I took them into a dark closet to separate them and see if I could tell them apart.  They really appeared to be the same brightness.

I then set about recording the current draw from the batteries of each circuit.  The original circuit clocked in at about 116mA of current while my new one only drew 58mA!  That's close to exactly half the current draw!  Furthermore, my circuit is smaller and doesn't whine quite so loudly.

I really feel kind of odd about that.  Was the Chinese circuit really that bad or did I just completely luck out with my circuit design?

Conclusion

Well, that was a lot more long winded than I was originally planning, but I've been wanting to better understand EL wire since I first bought the stuff, and although I don't fully understand oscillators, I'm definitely better off than I started.

I'll be doing some more stuff with EL wire in the future including making a more compact (and more efficient!) power supply for my shutter shades.  Stay tuned.

So, I spent the last few days tweaking my feedback loop to incorporate phase matching as well as tempo matching.  See, before, my code would simply match the motor speed to a designated speed, but it could be completely off beat otherwise.  I tried a few different methods for achieving phase matching, and I think I found one that works.

Measurement Methods

Earlier, I measured speed by simply starting a timer at the beginning of every cycle and reading it at the end of every cycle.  Similarly, for beat measurement, I start a phase timer as soon as a certain command is sent to the unit and reset it when it runs down to zero.  This timer continuously runs down and resets until I tell it to stop.  The idea is that the circuit keeps a local copy of the song's timing so that it doesn't need constant input from an outside source.

To get it started, I simply let it measure the time elapsed between certain commands that are triggered by my laptop.  If I trigger those commands every song beat, it will have an accurate measurement of the song's BPM.  In the future, the beat-detection circuit will send those signals.

The minimum length of time that the timer can measure (as currently implemented) is around .4 milliseconds.  With this level of granularity, you'd expect that it could measure the BPM of a song accurately enough such that once synced up, it won't drift during the length of the song.  What I found is that it would rapidly drift away such that it was noticeably off beat within 10-20 seconds.

I believe this is due to unpredictable delays that occur somewhere between my laptop and the circuit.  Remember that this signal is being sent through a USB-RS-232 dongle.  There's a lot going on.  RS-232 commands are not considered to be time-critical, so the dongle adding delay is likely not outside of its operation spec.

My future BPM detection circuit will be able to send commands with much higher precision, but in the meantime, I simply sent the timing command every single beat so that I effectively manually reset any drift that the circuit might be experiencing at the start of every beat.  A little bit of a pain, but tapping a button on my keyboard isn't too difficult.

The goal of my feedback control system is to get the period of each cycle as close to the target time as possible and to get the phase timer as synchronized to the cycle timer as possible.  At the beginning of every cycle, my code looks at the phase timer.  If the phase timer is very close to zero, that means that the beat is leading the wipers by a small margin.  If the phase timer is very close to its maximum value, that means that the beat is trailing the wipers by a small margin.

Simple Proportional Feedback

If you remember from my last post, I had a feedback loop that looked something like this:

The idea is to calculate how far you are off your target and adjust proportionally to bring you closer to your target.  Adding phase control makes it look something like this:

Look familiar?

There's an important point to be made about this system.  Because you only care to be on some beat, you always have the option to speed up or slow down to get back on beat.  Because of this, the subtraction of measured phase to desired phase is considered to be subtraction from the closest beat.

Looking at these two loops, you'd expect this problem to be no harder than the previous problem as there are two isolated systems.  The issue is that the systems aren't quite so isolated.

For example, let's say the system's timing is correct, but the phase is trailing by a small amount.  I could compensate by speeding up slightly, but then the system would see that the speed is too high and try to slow it down.  This would throw the phase off again, so the same adjustments will be made again and again.  The result is an oscillatory system.

Here's a graph of the process.  The x axis is cycles and the y axis is period (measured in units of .4-ish milliseconds).

In this plot, the "phase" measurement is actually the absolute value of the phase error and is trying to approach zero.

The speed error gain was a lot higher than the phase error gain, so you can see that the system favors speed to phase especially when it's first starting out and appears to be ignoring phase altogether.  This quickly sets it into oscillation, and the system never really settles down as it continues to oscillate upwards of 30 cycles later.

So, what happens if we lower the gain of the phase by a lot?  I re-wrote the firmware so that it restricts the maximum change the phase gain can effect to either +1 or -1 on the motor's speed setting (a scale from 1 to 255; the first 150 or so are reasonably fast).  This should prevent oscillations as even at its worst, the speed can only be altered a small amount to account for the phase.  Here's a plot:

As you can see, there are a lot fewer oscillations this time around.  You can also see that the phase is being matched very gradually taking tens of cycles.  Keep in mind that each of these cycles takes upwards of a second.  It could take even longer if the phase was further off to begin with.

The plus side of this method is how stable the system is once it finally settles down.

To speed up the settling, I decided to take the advice of a friend who suggested a slightly smarter feedback system.

Match Speed then Phase

The entire point of doing this feedback system is that I don't know exactly how fast the wipers will move when given a certain speed setting command.  There are a lot of variables that can interfere with the wiper speed such as window wetness, battery voltage, wind, dirt, etc.  Because of these, I need to guess a certain speed and then evaluate how good the guess is before guessing again.

If I knew exactly how fast the wipers would move at a certain speed setting before doing any tests, I could create what's called a "feed forward" system where I could basically predict the future.

The thing is, once my code has found the speed setting that brings about the desired wiper speed, it's safe to assume that the same speed setting will produce close to the same speed in the future so long as there aren't any major changes in atmospheric conditions that can interfere.

This lets me do what is essentially a feed-forward system.  I designed my code to take advantage of two facts:

• The wiper setting that produced a speed will likely produce the same speed if used again.
• Wipers take negligible time to accelerate.

Basically, once my wipers are satisfied that their speed is correct enough, they can stop entirely and just wait for the beat to catch up.  As soon as the beat catches up, they can start immediately at the previously determined speed setting and not be two far off in speed or phase.

So my code now has three parts:  First, it completely ignores phase error and tries to match speed.  Second, it pauses and allows the beat to catch up.  Third, once the beat is caught up, it starts again and uses the feedback method described above.  Remember that that method was very stable, it just took too long to get there.  With all of the hard work done, it's perfectly adequate to maintain the already near-perfect beat.

Here's a plot:

As you can see, the phase drifts wildly for the first 13 cycles or so and then rapidly drops to zero and stays at zero.

Testing

It was warm out today, so I had a chance to test my new algorithm on the real thing:

I was excited to find that the far end of the wiper cycle appears to be directly in the center of the ends time-wise.  This came as good news because otherwise, I would need to adjust motor speed mid-cycle and try to guess the location of the far end of the cycle as the wiper motor only provides feedback for the parked position.

I was less excited to see that the parking switch appears to be slightly out of place.  Humans are incredibly perceptive to mismatches in beat, so try as I might to ignore it, I couldn't help but notice that the beat of the song was coming slightly before the beat of the wipers going down.

While it would be convenient if the parking switch were to be moved by a few degrees, I'll probably have to make some considerations in the future to add an appropriate lead or lag to counteract the misalignment of the parking switch.  These considerations could be made on either the motor driver itself or on the device sending the signals to the motor driver.  Either way, I'll deal with it later.

Conclusion

I am very satisfied with how well this all turned out.  Though I'm only part of the way there, getting the motor control down was a major stepping stone and honestly the one I was most worried about.  All I need to do to properly finish up this step is to find a way to securely mount the motor driver in the engine bay and test how well it stands up to hot environmental conditions.

Now that the hardware part is more or less completed, what comes next is a bunch of audio processing and coding.  Not exactly my favorite thing in the world, but at least it can be done from the comfort of my chair rather than in out in the parking lot.

Purpose

Feedback is important when your environment is uncontrolled (or uncontrollable). A familiar example of a feedback system is the cruise control in your car.  You set the desired speed, and it adjusts the gas pedal to account for changing conditions.  When you go up hill, it revs the engine higher; when you go down hill, it lets off the gas.

That's exactly what I need for my wiper driver.  Depending on atmospheric conditions, the same speed setting might produce different wiper speeds.  For example, I found earlier that just wetting the windshield or turning the car off or on can have a drastic impact on the reported speed of the wipers.

With my new code, I only need to send a desired BPM to the driver board and it will attempt to match that BPM by trial and error.  If it detects it's going to fast, it will "let off the gas" and so on.

Method

My wiper system is what you would call a "first-order system".  Basically, it has little to no inertia.  When I change the speed setting of the wipers, they change speed immediately.  Fortunately, first-order systems are pretty easy to control.

In my code, I implemented a very simple feedback loop.  Here is a block diagram:

This might be a little funny to look at, so let's break it down:

changing resistance

This block represents environmental conditions that will change how the motor reacts to its input speed setting (wet windshield, etc)

Previous speed setting

This part is a little confusing.  My system is a discrete system which means that rather than making continuous adjustments, it only makes them at certain points--specifically, once per cycle.  The "Delay" block takes the speed setting from the previous cycle and brings it into the current cycle.  This is the only type of "memory" that the feedback loop has.

With this delay, it is able to base the next cycle's speed setting on the previous cycle's.

Desired acceleration

This signal is the result of subtracting the actual speed from the desired speed and applying a gain.  If the actual speed is lower than the desired speed, positive acceleration is needed and vice versa.

The gain stage is very important.  Applying gain is basically multiplying the incoming signal by a constant.  If the gain is too low, it will take too long for the system to react to change as the desired acceleration will be very small.  If the gain is too high, the system could accelerate way too fast and overshoot its target speed.  Feedback system designers are always playing with gain levels to try to get optimal performance of their system.

in code form

Rather than dealing with speeds, my code deals with time measurements per cycle, so things are a little switched around: higher time -> lower speed.

int32_t diff = targettime-currenttime; //subtract measured speed from current speed.
diff = diff/3; //Apply gain (gain=.333)
nextspeed = diff+OCR0A; //OCR0A is the speed setting currently implemented.

Note that nextspeed and OCR0A are inverted; a higher value means a slower speed. That's why diff is added instead of subtracted.  Also note that the time measurements are not in the same scale as the speed settings.  Time is measured as time elapsed during the cycle while speed is the duty cycle set from 0-255 where 0 is full duty cycle.

Summary

So the idea is that the farther the actual speed is from the target speed, the more abruptly the speed changes.  If actual and target speed are equal, no change is required, and the motor setting from the previous cycle is copied over to the current cycle.

 Performance

I'm very pleased with the performance of my motor under this code.  I put together a little demo video showing it off.

In the video, you will see a live plot of the motor speed as it updates.  Note that the plotted data is the speed of the previous rotation, so there will appear to be some time lag.  You will also see a live output from the Python terminal showing the values that the micro-controller is measuring.  Note that the "diff" value is inverted and not on the same scale as the other two.

You'll also catch a glimpse of my new metal motor driver enclosure.  It's a work in progress at the moment, but I'll post about it when it's finished.

Conclusion

So, I've got code on my micro controller that will match the BPM sent to it.  The next step will be getting it to match the BPM and the phase sent to it.  As is, the wipers might be going the right speed, but they probably won't be reaching the ends of their cycle quite on beat.

All for $30!

Salvage

Firstly, let me say that junkyards are exactly as cool as you might expect.  There were literally piles of cars to pick through organized by brand.  I moseyed over to the Toyota section and set to work.

The first thing I did was grab a bunch of those connectors that I was looking to buy.  They were the easiest part to extract, so I figured I'd grab a few.  I also grabbed a wiper fluid pump because mine broke like six years ago.  I'm not sure if it's compatible with my car, but I can't imagine there are too many different types of wiper fluid pump in a single car brand.

Lastly, I wanted to grab a wiper motor.  The one in my car works fine, but I thought it would be convenient if I could use the motor inside during development rather than having to do all my coding outside in the cold.

Extracting a wiper motor isn't super easy.  It also doesn't help when the bolts are likely to be rusted and you don't own a socket set.  The real issue is maneuvering whatever tool you're using around all of the engine parts.

I found that a rule of junkyards is that there is always a car somewhere that has exactly what you need.  For example, a wiper motor out in the open:

"Where is the engine?" you might ask?

Probably in a number of places.

Everything Old is New

When I got the motor home, I was excited to see that it worked!  I was less excited to see all the caked up grease, rust, and dirt falling off the motor every time I touched it or turned it on.  I suspected this dirt was partly responsible for the spurious data I was getting from the parking switch contacts.  They started out working fine, but after a few hours of testing, I had some really gross looking waveforms coming out.  There was also a squeaking sound that got louder as time wore on.  After years of sitting immobile, a lot of grime had settled that I was suddenly stirring up.

Because I wasn't looking to use this motor in any real application, I figured it'd be safe to take it apart and see if I could clean the contacts.  Using a T-20 Torx driver and careful force from a chisel, I managed to separate the back panel of the motor:

That right section houses the contact brushes and disk.  The plastic part you see has a small plastic nub that hooks on to the rotating section opposing it.  It wasn't super easy to get access to the disk.  Instead of a bolt holding it down, there was some kind of plastic harpoon-tip style piece that looked like it wasn't intended to ever be removed.

This tip isn't needed when both halves are assembled though; everything is held together pretty tightly by the outside housing.  I figured it was safe to remove the tip by boring it out with a drill.

No wonder I was having problems.  That's a pretty gross disk.  Using some dish soap, an old tooth brush, and some elbow grease, I think I cleaned things up pretty nicely.

I took some of the clean grease that never really got spread out properly (the blue blob on the top right) and applied it evenly to the metal disk to prevent the now-clean contacts from wearing out.

After slapping it all back together, I found that not only are the contacts a lot cleaner, but it also stopped squeaking!

I've made some very rapid progress programming with the help of this motor, but it's getting late, so I'll have to clue you in on my new code in another post.

Setup

So I ran two trials under three different conditions.  I forgot to bring my camera with me, so I don't have any photos.  You'll have to rely on my descriptions.  Red is self-explanatory; it's how I've been running all of my tests up to this point.  For green, I carefully made sure that none of my wiring would get in the way of moving parts of the car and started the engine  At the 14.4V supplied by the car's alternator, it had a little more juice to power the motor.  For blue, I carefully wired the driver up and tucked it into my motor so that I could safely shut the hood without crushing it.  My friend held a hose and kept the windshield wet with a slow and steady stream of water while I ran the test.

Issues

Spontaneous reset

I noticed a new issue this afternoon.  After running the test with the car on, I noticed that my circuit kept resetting itself.  At first I was worried that this had something to do with voltage fluctuations in the power supplied by the alternator.  Under further examination, I think I determined it to be just a result of the vibration of the motor.

My circuit was powered by two wires connecting to the battery terminals via alligator clips clipped straight to the bolts that hold the battery terminals on.  These bolts are all caked up with grease and dust from the motor bay, so there was already a lot getting in the way. The added vibrations probably caused short term disconnections that reset the circuit.

I'm still not 100% certain that this is the case.  I noticed the circuit resetting a few times while the car was turned off (after having it on for a while) though after fiddling with the battery terminal connections, the problem went away again.  I'll see if this becomes an issue in the future.

Spurious data

As you can see in my plot, there are a few cases where the curve shoots down to zero.  This is likely due to the same kind of contact bouncing that I thought I had fixed.  While I would rather have no bouncing at all, it's good that there isn't any spurious bouncing in the middle of a frame due to bumps on the disk.  All of the spurious data seems to register a zero second wiper cycle which means that it probably just bounced a bit as the brush was making or breaking contact with the disk and registering it as the end of the wiper cycle.  Making my software debounce timeout a little bit longer should fix this problem entirely.

Conclusion

I was very surprised what a difference wetting the windshield made on the wiper speed.  It's also pretty curious how the wet windshield with the car off lines up so well with the dry windshield with the car on.  This is likely a complete coincidence but still interesting though.  It makes me want to run the wet windshield test with the car on to see how it compares.

Overall, I am very excited to see how consistent the data seems to be.  This means that as long as there aren't sudden changes in conditions, my circuit shouldn't have to worry too much about accounting for variances in drag over the course of a single song.

Also, it looks like the fastest performance I can hope for out of my wipers is on the order of 60 bpm (or 120 if I do half-cycle beats).  It's pretty convenient how gradual the slope gets at the higher settings though.  That means that I'll have the ability to fine tune my wiper speed in the range that really matters.

So today, I learned the importance of preventing things from bouncing.

The Problem

If you'll recall with my windshield wiper project, I am using part of the windshield wiper motor to give me information on the wipers' current location.  Two of the five contacts that the motor provides connect to little metal brushes that run along a rotating metal disk.  One of the brushes is in constant contact while the other passes over a small hole in the disk once per revolution.

The original purpose of this configuration is to allow the intermittent mode of wiper operation to work almost autonomously.  The car will run current into one of these brushes and out the other to power the motor.  When one brush reaches the hole, the motor will lose power and stop.  This is what causes the wipers to stop at the end of a single wipe in intermittent mode.

Now, these brushes are designed for high current applications, not for precise position measurement.  For example, if one of the brushes were to lose contact for 1ms or so, nobody would notice.

Recently, I've been trying to capture accurate information regarding how long it takes the wipers to complete a single cycle when setting them to various speed settings.  I wrote a script that would try the wipers for one cycle at a speed setting, then change speed.  My results look like this: (x axis is speed setting, y is time in seconds)

You get the general gist of what's supposed to be going on by looking at the logarithmic slope you can see along the top.  So what's up with the rest of the data?

Well, I'm fairly certain that the brushes are "bouncing".  This is a common phenomenon with any kind of metal contact switch.  When you smack two pieces of conducting material together, there is a very high probability that they will vibrate and have an intermittent connection for, say, a few hundred microseconds.

Here's an example of one such vibration as the green signal passes from low to high (note the time scale is 20us per division):

This is an inconceivably small amount of time for a human, but it's eons for a micro-controller.  The micro might see a contact and separation happening a few microseconds apart and assume that the windshield wipers have made a full revolution in that time.  It's also possible that there are some bumps along my motor's disk which is causing very brief disconnections in the middle of a cycle.  I believe this is why there are so many quick measurements in the data I retrieved.

So, I needed to find a way to "de-bounce" my signal.

Solution

There are two potential solutions to this problem:

1. Solve it in software
2. Solve it in hardware

Software

De-bouncing is often solved in software by adding short delays after a correct reading.  If you know the bouncing period is about 500us and the shortest time you should ever experience between switching on and off under normal use is on the order of 100ms, then you can have your code just ignore everything for 100ms after it receives a positive on or off.

This solution works very well with buttons (in fact, it's probably what your keyboard is using right now), but it isn't a perfect solution with my configuration because there's a chance that the brushes will bounce at a random point in their cycle.  Remember how they're running along a disk?  It's possible that there are small bumps on this disk that could cause problems.  By contrast, as a button is held down, nothing really changes.

Also, software is a pain.  Hardware is where it's at.

Hardware

What I really need here is a simple low pass filter.  This will essentially smooth out my signal removing any extremely brief bumps.

My original circuit looked something like this:

The idea is that as long as both brushes are touching the disk, the micro-controller input is grounded.  As soon as the outer one goes over the hole, the input is pulled up to 5v by the 1k resistor.

To implement a simple low pass filter, I added a resistor and capacitor as follows:

The 10k resistor and 1uF capacitor will have a time constant of (10,000*1E-6=) 10ms.  This means that it will take about 50ms for the input to switch from high to low or low to high (about 5 time constants).  I changed the 1k to a 470 because I wanted to make sure that the time constant was as close to equal for the pull up and pull down as possible.  Keep in mind that for the pull up, you have to sum the 470 and 10k together when calculating the time constant.  Ideally, I'd go as low as possible, but once you get down to the 100-200 ohm area, you start running into power dissipation issues because you're dropping 5V across this resistor when the disk grounds the input.

Luckily, these reworks were fairly easy to implement because of how my circuit was laid out.  Here's an updated schematic.

Results

Though I haven't had a chance to test it on my car, it definitely worked while testing indoors.  Because I didn't have the wiper motor to play with, I simulated the connections by touching a piece of wire to the ground plane or rubbing it along the ground plane.  Here's an example of the signal passing from low to high (disconnecting the wire from the ground plane):

The green signal is before the low pass filter and the yellow signal is after. As you can see, the green signal appears to bounce a little bit as it is lifted, but the yellow signal takes a while to rise.  Here the time scale is 5ms per division, so the whole rise takes around 25-30ms.  If this turns out to be too long, I can easily tweak it by swapping out the resistor for a smaller one.

And here's a video demonstrating how well the fix worked:

I was being a little unfair towards the end of the first segment in how I was rubbing against the edge of the ground plane, but there are still a few incorrect messages towards the beginning where I'm rubbing on fairly smooth copper.

Anywho, the board is updated, and I'll give it another go on the wipers as soon as I get a chance.

I was a little hasty because of the cold (and because my camera's battery was dying), but I did collect some useful data.  And a video!

Setup

So, as you can see above, I don't really have a case for my circuit yet.  That will probably be my next order of business.  To keep anything from shorting out, I temporarily sat it on the wiper fluid tank which is made of plastic.

I connected the power terminals directly to the battery and the motor terminals straight to the motor.  I didn't bother connecting the car's wiper driver to the circuit because I was only interested to see whether or not my circuit would explode under pressure.

I was surprised to find that my motor connectors weren't quite the right size.  The ones on the outer ends of the connector housing fit fine (after I crushed them a bit to ensure a snug fit), but the plastic insulator was too wide for the center connection.  I had to attack it with a pair of wire cutters for a bit to get it to fit.

Because there's already so much insulation in place between the conductors on account of the shape of the plastic motor housing, I'll probably end up ditching the insulated quick connect terminals for the final version in favor of uninsulated ones.

Data Collection

I wrote a simple Python script that ran through various motor speed settings and recorded how fast the wipers moved.  As you'll recall from my other post, two of the contacts on the motor make up the "parking switch.  They are shorted together for about 90% of the wiper cycle and opened for the last 10%.  When my circuit detects the short, it sends a simple byte command to my laptop over serial (the character 'a') and when the circuit is opened, it sends a 'b'.  The yellow LED also blinks to indicate which state it's in.

Starting with the wipers in the parked position, the Python script started them at a specific speed setting and timed how long they spent with the switch open and closed by waiting for the bytes to come back from my circuit.  After one cycle, it stopped them then started them again with a different speed setting.

My results are in the plot below.  Time is on the Y axis and the X axis shows different speed settings.  Keep in mind that the speed settings range from 2-255 where 255 is stopped and 2 is full speed.  The red line shows how much time the wipers spent with the switch open and the blue line represents time spent with the switch closed.  Adding the two up will give you the time of one complete cycle.

Ok, so it's not the best plot.  My code was hastily written, and as soon as the wipers got too fast, the Python had trouble keeping up with them so the whole thing died at a speed of about 25.

Still though, it does show some interesting information.  It looks like a sort of logarithmic growth as the wipers get slower and slower.  Still though, I really need to do this again to see what happens at the faster settings, because as-is, I'm not even showing anything faster than 30BPM (less than 2 seconds per cycle).

Conclusion

I was definitely in a hurry to get this thing done tonight.  It was uncomfortably cold outside, and my camera's battery was dying.  I'll definitely have to go back and do it again some other time.

Still though, I captured all of the data I really needed.  My circuit took the current draw like a champ and didn't even get warm.  I'll have to spend some time cleaning it up and finding a nice case and mounting point for it before moving forward.

The next step is to get some better data in the >30BPM department.  It looks like the setting/speed relationship is not linear, so I'll definitely need some accurate data to create a proper lookup table.  I'll also have to see how a wet windshield changes things.

And here's the video.  Sorry there isn't any audio.  I had my camera configured wrong, and I didn't realize until it was too late.