In this article, the working method, the wide-ranging possibilities and ultimately the reliability of software-supported crossover development are to be considered. 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 measurement microphones in a horizontal and vertical plane around the loudspeaker, 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 deviating from the target value ... or Components that can be set to any value using a 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 is available for storage, management and analysis.
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 every component change on the amplitude frequency response (horizontal and vertical), phase, impedance response & voltage frequency response in real time. We can simultaneously Things that the on-foot developer thinks if any, only one after the other.
"On foot" is usually there. a Microphone, Impedance measuring stripe and a Component that is changed. Then you can 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 must be "guessed" ...
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 loudspeaker that I developed ... The results are very good, but it took hours to do things that now take minutes or seconds. In the meantime I consider it very questionable whether the last bit of detail can really be achieved in a walking development.
The question of accuracy still arises ...
In order not to anticipate it quite unprovocatively: The virtual one - is more precise than the real development switch 😉 ...
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 switch, there are practically no sources of error. The components do not have any deviations, there are no increased contact resistances, no wiring errors, no component mix-ups, no cold soldering points.
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 construction (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: Both “on foot” and in the simulation, a “filter finding” takes place as follows, for example: You start with a, say, 2nd order high-pass filter and a voltage divider. Then there is an increase in the air, which is then ironed out with a blocking or suction circuit. As soon as everything looks good you are finished "on foot". In the simulation you can now try to find a filter function that delivers an identical result with fewer and / or cheaper components ... often works!
- The simulation as an error diagnosis tool. If the simulation and the final measurements agree, it can be assumed with a probability bordering on certainty that the structure is error-free. Very good in terms of "replica security"
- Steep learning curve when it comes to filter design, even with experienced developers ...
- Variability: Variations of a loudspeaker can also be created in retrospect because a complete and verified simulation model exists.
"Trial & error switch" until it fits=> pre-defined acoustic filter edges
- The cascade of "n" identical measurement microphones ⇒ an extremely practical way to "controlled directivity" loudspeakers
The art of developing a good loudspeaker should not primarily lie in the crossover design, but rather in finding an overall concept that is coherent for the intended work area. Find very good drivers and define a meaningful work area. A good housing design (inside and outside) and the baffle geometry that is so often ignored. How the drivers ultimately want to be filtered is, in my opinion, largely predetermined by the overall concept. Theoretically, we could leave the development of the crossover completely to the computer ... A good crossover optimizer, fed with 360 ° measurements horizontally, vertically and diagonally, to which we make specifications regarding the energy behavior of the loudspeaker and the area of application of the drivers, will find better / more effective crossovers than we can . An exception is of course "the first litter of the experienced developer" 😉