Software supported crossover development ... or simulation vs. "Reality"


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 an 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

  • Time
  • 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

In conclusion:

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" 😉

14 thoughts too "Software supported crossover development ... or simulation vs. "Reality""

  1. Hello, thank you first for the successful article!
    Before 1kHz the TMT starts to bundle. The increase of the sound level around 1kHz would be attributed to the geometry of the baffle. I suspect it is edge aberrations.



    1. Hello Bernhard
      No ... Both drivers have practically no problems with edge diffraction. The point of interference around 1kHz does not come from the drivers, not even from the baffle. It's also easy to fix ...
      One more try?

      1. So then is it the impedance? What if you adjusted the crossover frequency or made an impadance correction? But that the disturbance around 1 kHz only occurs so strongly at an angle should then have something to do with the radiation behavior of the drivers! I am curious what the solution to the riddle is….

        1. Hello Bernhard

          It is the longitudinal resonance of the bass reflex tube which is not adequately treated (at this time), which radiates to the rear, and thus comes to bear stronger with increasing angle


          1. OK, because I would never have come on it, except maybe I would have measured / developed the box myself. I'm not very experienced in that.
            I was thinking all the time why it only occurs so strongly at angles…. Now I understand!
            How would the resonance be treated?
            Simply absorb the radiated mid-tone component of the TMT with insulating material?

            When will we finish the Cinetor Evo?

  2. The disruption was treated through a combination of port position / port length & modifications to the insulation material.

    Cinetor EVO is actually finished ... only has to finish the article and the construction folder 🙂

    Kind regards

  3. Hallo,

    I love the concept of the software. Unfortunately, I can not find any information about the file format that the import files must have.
    With .txt from ARTA does not work for me.


    1. Hello Mario
      I quote from the instructions that can be found on the pages of the IGDH:
      "LsSoft accepts the" txt "formats when importing
      or "frd" or "zma". Both formats can
      be exported from ARTA, as a rule
      but also from other measuring programs. "
      I suspect, you have the frequency response without the phase information exported?
      You have to make that visible in ARTA, and then export it.


          1. Hi Alexander,
            I have the same problem with the ATB Pc Pro program. Unfortunately does not work. I tried txt or frd format..not possible. As described, I adjusted the Y-axis and put the path in the same directory as the program (Windows 7) ... does not work. I would also be thrilled not to have to do everything “on foot”.
            Excellent site, especially the basics ...

  4. Hello Reinhard,
    I always get the message that the network is INACTIVE!
    Can you give me a solution for this?

    Best Regards

Leave a Comment

Your e-mail address will not be published. Required fields are marked with * marked

Blue Captcha Image