The aim of this article is to consider the mode of operation, the far-reaching possibilities and, ultimately, the reliability of software-supported crossover development. It will exclusively the use of the computer as virtual crossover considered. No housing simulation, no frequency deviation simulation according to data sheets, TSP or any other parameters that are not based on real measurements on the object ⇒ All relevant data is obtained from real measurements!
The concrete approach in software-based crossover development is usually the following
- Concept creation (driver / housing / baffle geometry) taking into account all possible factors, which will not be discussed here
- Structure of the speaker: Case construction, absorption / insulation, cabling, bass tuning (BR / CB etc.) ⇒ Without crossover
- Measurement of the individual, unfiltered drivers: Amplitude frequency response including relative acoustic phase under all desired angles and impedance response
- Import of measurement data into the software, in this case Xover 2.04A
At this point a note: The measurement of a 2-way speaker under eg. 22 angles (+ -90 ° horizontal in 15 ° steps and + -20 ° vertical in 5 ° steps) including impedance measurements takes ~ 15 minutes
Let's imagine the following measurement setup
- A cascade of "n" identical measuring microphones in a horizontal and vertical plane around the speaker, which do not influence each other
- A measuring device for detecting the impedance paths of the individual drivers and the whole loudspeaker simultaneouslywithout affecting the results
- Hardware that can process and output all measurement results in real time
- Software that can process and output all measurement results in real time
- All required components without deviation from the setpoint ... Components that can be set to any value via the controller
- A transparent translator that changes / adjusts parts on instructions 😉
Everything is not really feasible, but should illustrate what is possible if we collect all the data one after the other and then let the software work with it.
Here is an example of the course of a crossover development with Xover 2.04a
The program is on the pages of the interest group DIY Hifi (IGDH eV) as download available.
Top left: 0-90 ° Horizontal, sum / branches and phase Top right: 0 ° and + -15 ° vertical, sum / branches and phase Middle bottom: Impedazgänge branches and total Bottom right: Voltage frequency response
Quiz question: What's going on at 1kHz? Use the comment function :)
We have a virtual crossover board on the screen, and see the effects of each component change on the amplitude frequency responses (horizontal and vertical), phase, impedance, and voltage response in real time. We can simultaneously Things that the on-foot developer thinks if any, only one after the other.
There is usually "on foot". on Microphone, one Impedance measuring stripe and on Component that is changed. Then you can a Zweig or the sums, or look at the impedance frequency response. Everything under one Corner. The effects of a component change can basically only one aspect to be viewed as. The effects on other aspects have to be "anticipated" ...
If I change the slope of the tweeter in favor of a better phase angle, how does this affect the radiation behavior horizontally and - or vertically?
Of course, even very good speakers can be created. Direct-HA is the last speaker I've ever designed ... The results are very good, but it took hours for things to go in minutes or seconds. Meanwhile, I find it very questionable if the last bit of detail can really be achieved in an on-foot development.
Is there still the question of accuracy ...
In order not to anticipate it quite unprovokativ: The virtual, - is more accurate than the real development ... 😉 ...
We have real measured values of the drivers (amplitude frequency response including rel. Phase and impedance response) and put them in a (virtual) AC circuit with frequency-dependent (L / C) and frequency-independent (R) impedances. The mode of action of capacitors, coils and resistors can be detected by formula. There are no relevant unknowns.
In contrast to the "real" development turnout, there are virtually no sources of error. The components have no deviations, there are no increased contact resistance, no cabling errors, no component confusion, no cold solder joints.
So that Reality In the end, there are really only a few possibilities:
- Measurement conditions have changed (measurement setup, temperature, ...)
- Components deviate from the standard value
- Errors in the structure (crossover, cabling, faulty components ...)
If we trust our measurements, we can look at differences between reality and simulation, the error on the real object. Often the simulation can help here as well. We carry out targeted changes as long as the results correspond to the error. So I have often found out which component differs from the norm, where a contact resistance is too large, or where two components were confused. It will not be published until the simulation and final measurements of the speaker are practically the same. The virtual crossover as a reliable fault diagnosis tool!
Here's an example of the match between simulation and measurement on the finished speaker:
In Jumping simulation and final measurements of a speaker at horizontal angles of 0-90 ° in 15 ° steps
It can be practically talked of congruence at all angles. The minimal deviations are due to slight deviations in the final measurement setup and possibly tolerances in the components.
The advantages of a software-supported crossover development summarized once again
- Material: No cabinet with components needed.
- More efficient crossovers: "On foot" as well as in the simulation, a "filter finding" runs like this: You start with one, let's say high-pass 2. Order and a voltage divider. Then an elevation disturbs, which is then smoothed out with a barrier, - or absorption circle. So now everything looks good you're done "on foot". In the simulation you can now try to find a filter function that delivers an identical result with fewer and / or less expensive components ... works frequently!
- The simulation as a fault diagnosis tool. If simulation and final measurements match, it can almost certainly be assumed that they are faultless. Very good in terms of "replica security"
- Steep learning curve in terms of filter design, certainly synonymous with experienced developers ...
- Variability: Variations of a loudspeaker can also be created retrospectively, because a complete and verified simulation model exists.
"Trial & Error Soft" until it fits=> predefined acoustic filter edges
- The cascade of "n" identical measuring microphones ⇒ An extremely practical way to the "controlled directivity" loudspeaker
The art of developing a good loudspeaker should not be primarily in the design of the frequency softening, but rather in finding a coherent overall concept for the intended work area. Find very good drivers and define a meaningful workspace. A good case design (inside and outside) and the often overlooked baffle geometry. How the drivers ultimately want to be filtered is, in my opinion, largely predetermined by the overall concept. Theoretically we could leave the crossover development entirely to the computer ... A good switch optimizer, fed with 360 ° measurements horizontally, vertically and diagonally, to which we make specifications regarding the energy behavior of the loudspeaker and the application area of the drivers, will find better / more effective course than we can , Except of course is "the first litter of the experienced developer" 😉