Ribbon Tweeters in Car Application

Many home audio enthusiasts mention the ribbon tweeters (RT), how amazing they are. Yet in car audio, this tweeters are still not widely used, Some car audio enthusiast and professional don’t recommend RT because they are relative hard to install and adjust. From many articles i read about RT usage in car audio and my experience in using this tweeters in my car, i will try to elaborate the advantages, disadvantages and some notes for these tweeters application.

First off, what is a ribbon tweeter and how are they different from regular tweeters? Here’s a look at my VRT18 ribbon tweeter with the factory passive crossover:

Imagine your regular old dome tweeter and voice coil. With a ribbon tweeter, there is no separate dome and voice coil. The aluminum ribbon element acts as both the radiating element (the dome) and the voice coil together. Also, the ribbon element is much thinner, lighter, and faster to respond than your typical coupled voice coil and dome tweeter.

So what are the advantages of a ribbon over a regular dome?

• High sensitivity and superb dynamics. Less than few watts are needed to yield high spl levels.
• Great horizontal off-axis response resulting more detailed frequency and wider soundstage.
• Limited vertical dispersion resulting in reduced car reflections effect.

Disadvantages:

• Limited vertical dispersion. While this can be advantage, it can also be a disadvantage. Tweeter must be aimed directly to listening vertical position, otherwise the spl will drop off. Can be a pain to work with if there are 2 people of different height sitting in the car.
• Fragile ribbon element. You do not want to blow directly on them, and they require steep crossovers usually 18db (3rd order) or above to protect them from over excursion.
• Size. Tweeter is pretty big and deep.

This is an example of vertical dispersion of 3.8 ribbon tweeter:

Some tips for using ribbons in cars

• Kick panel mounting is generally best because these tweeters are big. But if this placement is not available for your car,  like mine, you can try head level A-pillar for placement and you can experiment for the angling. I recommend to try a windshield toward angle or listener toward angle. Just make sure you get the best stereo imaging and sound stage.
• 1-5 watts is plenty of power, and will easily play at painful listening levels.
• Always use the factory crossover or an inline capacitor to protect the ribbon. A Solen 27uF poly cap works fine.
• Make sure to vertically aim the tweeter at your head level.
• Use a steep 18db (3rd order) or higher highpass crossover, if you want to use active crossover.

AES 2009 Audio Myths Workshop

I found this video linked in the FL Studio forum. I say this should be a mandatory content to watch for anyone interested in audio/video or a professional in this subject. I learned more in an hour from this video than i read audiophile forums in five years.

Audio Myths Workshop ~ 60 minutes
At the beginning of the video, JJ talks a little about human hearing, and Poppy gives a very humorous demonstration on the power of suggestion. The remainder of the video is Ethan giving demonstrations of what can actually be heard with respect to things like dither, equalizer, re-sampling, consumer versus pro consumer sound cards, microphones, amplifiers, etc.

When Should We Refactor?

My friend asked me about when is actually a good time for refactoring, or even what are the signs. According to several books i have read and my experiences in several projects, i’ll try to elaborate this thing.

Right time for refactoring is ASAP: refactor early, refactor often , i strongly believed in broken windows theory. BUT, don’t let this right thing sucks us really hard, so i think this is best-for-me practices:

Keep track of the things that need to be refactored. If you can’t refactor something immediately, make sure that it gets placed on the schedule. Make sure that people of the affected code know that it is scheduled to be refactored and how this might affect them. Remember that we’re coding for people, not the opposite. And also, according to Martin Fowler ‘s simple tips on how to refactor without doing more harm than good:

Don’t try to refactor and add functionality at the same time.

Maybe u will say: “Hey! ok i knew it, but what should i look first for refactor? i often stuck with no idea”.

Considering clean code definition, i realize that any number of things may cause code to qualify for refactoring:

• Duplication. Remember the DRY or DIE principle, duplication is bad, really bad, trust me.
• Nonorthogonal design. You’ve discovered some code or design that could be made more orthogonal. In my experience, this step is the toughest one. If you are familiar with this, i believe that you’re such a good (maybe great!) programmer.
• Outdated knowledge. Things change, you know something better for your code, you know there are new better solution for your code. This is the time for you to keep up the code.
• Performance. It’s the most common enforcement for programmer to look back to his code. You will be rarely concerned with this problem in aftertime if you’re a really good programmer.