Hornresp

1.17E-04 is 0.000117 expressed in scientific notation. It is the same as 1.17 x 10^-4 or 1.17 / 10000.

Scientific notation is mainly used by physicists and engineers, to express very large or very small values in a more convenient form.

Yes I suddenly just remembered that E stood for exponent not error, which I originally thought (memory like a sieve). With a very quick search worked out how many decimal places and which direction and I was back on track.
 
If the BassBox Thiele-Small parameter values shown in your example are entered into Hornresp, all values remain the same except for Vas, which changes from 240.7 litres in BassBox to 240.28 litres in Hornresp. The difference is 0.17 percent, which has no material effect on the results.

The very small discrepancy is due to rounding errors introduced when Hornresp converts the entered Thiele-Small parameter values to their electro-mechanical equivalents for use in the simulation models. The electro-mechanical parameter values are converted back to Thiele-Small values when displayed in the Driver Parameters input form.

Xmax is rounded to one decimal place when entered into Hornresp, so the BassBox value of 33.66 mm becomes 33.7 mm, a difference of 0.04 mm, which is not significant.

The Sd values should always be the same - you must have entered a slightly different value in Hornresp to that shown in BassBox.

The rounding didn't worry me that was easy to figure out what had happened.

I put all the correct parameters as provided by manufacturer in the txt file and imported it. They showed up fine on the screen at first. Then I clicked the Sd to check the parameters and several of them were wrong (Pic 1)

I corrected them back to what the manufacturer said (VAS was 244.19 instead of 240.7, Fs was 19.75 instead of 20.5 etc. etc) then I pressed ok and the figures on the main screen were wrong. (Pic 2)

I tried to manual correct them but each time I clicked on the Sd and fixed the numbers up again it changed them again. Leaving me with the only real option of leaving them wrong.
 

Attachments

  • Pic 1.jpg
    Pic 1.jpg
    145.9 KB · Views: 178
  • Pic 2.jpg
    Pic 2.jpg
    146.2 KB · Views: 146
  • TS Parameters.jpg
    TS Parameters.jpg
    116.8 KB · Views: 139
Last edited:
Glad to see you have started to use Hornresp :)

There can be several reasons for the differences you see, but it basically comes down to two things: rounding error (the manufacturer's data is of course also rounded, f.ex. Fs is probably not exactly 20.50000Hz, but can range from 20.45 to 20.54), and difference in the sound speed used.

The conversion between the electromechanical parameters that Hornresp uses and TS parameters involves air density and the speed of sound, which both varies with temperature, static pressure and humidity. In some of the conversion equations, sound speed appears squared, so small changes can have noticeable impact. If the manufacturer uses different values for air density and sound speed from Hornresp, there will be a small difference in how the two sets of parameters line up. That does not mean they are "wrong".

It is also important to understand what the parameters actually describe. The electromechanical parameters describe the physical parts of the driver: the physical mass, the stiffness of the suspension, the strength of the motor. TS parameters are derived, and they describe how the driver behaves as a resonant circuit, in terms of resonance frequency and Q values. Vas is in between: it is the volume of air that has the same stiffness as the driver suspension. Since the properties of air changes with temperature etc, Vas will also change with temperature, even if the physical suspension stiffness stays the same. Is Vas now "wrong"?

I base my simulations on the electromechanical parameters, as they are more constant than the derived parameters. As an example, if you change the suspension stiffness a little, all the TS parameters change, because you change Fs (as the mass is unchanged), and the Q-values depend on Fs, so they will change.

It is also important to keep in mind that these parameters are small signal parameters, they change with displacement and heating of the driver: BL and Cms decrease as the cone move away from the rest position, the suspension softens as it is worked, and Re increases when the coil gets hot. But they still give a reasonably good description of the driver performance at low levels.

Parameters will vary within a production batch, and a new driver is stiffer than a used one. Manufacturer's data is a guide, and probably close to the middle of the bell curve, i.e. represents an average driver. But it is good practice to measure the driver parameters if you are comparing an actual build to a simulation.

My point is that the small variations you see between entering electromechanical and TS parameters will be small compared to the variations you will see between different drivers of the same type, and between the driver before and after it has been playing music for a few hours. Driver parameters are not comparable to resistor values or box dimensions, they are not exact and static. If you see large variations in the response with such small variations in driver parameters, the design is too sensitive, and will probably not work in real life.
 
The rounding didn't worry me that was easy to figure out what had happened.

I put all the correct parameters as provided by manufacturer in the txt file and imported it. They showed up fine on the screen at first. Then I clicked the Sd to check the parameters and several of them were wrong (Pic 1)

I corrected them back to what the manufacturer said (VAS was 244.19 instead of 240.7, Fs was 19.75 instead of 20.5 etc. etc) then I pressed ok and the figures on the main screen were wrong. (Pic 2)

I tried to manual correct them but each time I clicked on the Sd and fixed the numbers up again it changed them again. Leaving me with the only real option of leaving them wrong.


Your "corrections" are actually rounding errors. If this level of driver parameter precision is your goal trusting in the manufacturers specifications is a bit of folly. Test your drivers T/S parameters and you will have something to rely on. If you are on a budget, REW is a good way to do comprehensive testing that is accurate and cost effective. The software is free. And the test rig is under $10 in cost.
 
Glad to see you have started to use Hornresp :)

I base my simulations on the electromechanical parameters, as they are more constant than the derived parameters.

Thanks for that detailed explanation it was very helpful...

I wouldn't say I am using Hornresp, as much as I am attempting to use it to verify box details TC Sounds provided. If I can roughly match the box volumes provided, it is a backwards / reverse way of letting me know if I slightly understand the program.

So what I got from your info is that we are basically trying to herd cats here. Because of the constant variables associated with the driver. I get that some will alter with temp and somethings are not really a constant when you think they are.

Also things like the speed of sound may not be consistent between what TC Sounds used versus what David used because temperature plays a part in that value.

Wouldn't there be generic values used for things like speed (unless you are offering a option in your code to specify the temp to come up with a derived speed)?

It still doesn't make me feel at ease when the program is changing values I set even if those values are being transposed to a different scale or used differently in the formulas. I would prefer it let me enter what the manufacturer says and correct and change them in the code without me knowing.

To me the GUI is the users domain, what happens in the code at the back end is the programmers domain.
 
Last edited:
Your "corrections" are actually rounding errors. If this level of driver parameter precision is your goal trusting in the manufacturers specifications is a bit of folly. Test your drivers T/S parameters and you will have something to rely on. If you are on a budget, REW is a good way to do comprehensive testing that is accurate and cost effective. The software is free. And the test rig is under $10 in cost.

Thought I had a copy of REW but it was True RTA I bought and never used. Just found a copy of Loudspeaker Design Cookbook 7th Edition on CD, should have a look at it too since I have paid for it.

Edit: It is a companion CD so that must mean I have the book around here somewhere.
 
Last edited:
Another possible approach to the BP6S. I think I'll try to build an optimization spreadsheet around this layout this weekend.

Hi Brian,

Just letting you know that I think I have found a way to reduce the amount of work required to implement the offset driver option, without compromising the accuracy of the results. A considerable amount of work will still be necessary, but I am prepared to give it a go. If all goes according to plan, the option will be provided for BP4, BP6S and BP6P type enclosures (but not for BP8, DBR or ABC types). Not sure how long it will take...

Kind regards,

David
 
Wouldn't there be generic values used for things like speed (unless you are offering a option in your code to specify the temp to come up with a derived speed)?

I think David uses 344m/s for c (speed of sound) and 1.205kg/m3 for rho (air density). These are generic values, but I have seen "generic" values for c ranging from 340 to 345m/s, and sometimes rho is rounded to 1.21 or 1.2. There is no "ISO standard sound speed".

It still doesn't make me feel at ease when the program is changing values I set even if those values are being transposed to a different scale or used differently in the formulas. I would prefer it let me enter what the manufacturer says and correct and change them in the code without me knowing.

There would be some extra storage involved of course, which is cheap nowadays, but also a lot of extra logic to decide what to display and what to use in the simulations when the two representations are not consistent. Since the small differences should not make a significant difference to the results, I can't imagine David would want to spend hours designing that logic.

To me the GUI is the users domain, what happens in the code at the back end is the programmers domain.

I see your point. But if the program showed the values exactly as the user entered them, hiding the inconsistencies between the parameters from the user, the user could never be sure what the exact values used in the simulation were. This could make it difficult to track down differences between simulations and measurements of the finished design, and also make it difficult to compare the results to other programs.

The way it currently works also makes it possible to catch typos in the data sheet, as a typo in a value may cause a large inconsistency.
 
I like the elegance of the design. But please tell me that the vents are pipes and not shelf ports. Cuz not so easy to nail a shelf port calculation.

Definitely shelf vents, LOL. Hopefuly I've positioned them in a way that makes it a bit easier to fine-tune their length to achieve the target resonance frequencies.

Vents can also be difficult to get right in a bandpass design, if you make the vents large enough for subwoofer duty. Have a look at my project to see what I ran into - The Subwoofer DIY Page - Projects : An INF10 Bandpass Subwoofer
 
Hi Brian,

Just letting you know that I think I have found a way to reduce the amount of work required to implement the offset driver option, without compromising the accuracy of the results. A considerable amount of work will still be necessary, but I am prepared to give it a go. If all goes according to plan, the option will be provided for BP4, BP6S and BP6P type enclosures (but not for BP8, DBR or ABC types). Not sure how long it will take...

Kind regards,

David


That's great news. I'll definitely start working on that spreadsheet that weekend... :)
 
Definitely shelf vents, LOL. Hopefuly I've positioned them in a way that makes it a bit easier to fine-tune their length to achieve the target resonance frequencies.

Vents can also be difficult to get right in a bandpass design, if you make the vents large enough for subwoofer duty. Have a look at my project to see what I ran into - The Subwoofer DIY Page - Projects : An INF10 Bandpass Subwoofer


Nice write up of your adventures. Welcome to the heck if I know school of making higher level enclosures. As much as we rely on mathematics to help us design this stuff, there are so many variables that are just not properly described in the mathematics. Keeps us on our toes!
I've been working the past couple of weeks on magnetics design for drivers and it to is a bit of hunting and pecking. Keeps me humble as to what I think I know will happen that's for sure. I get close, occasionally spot on. But more times than not I have to rework a design.
 
Definitely shelf vents, LOL. Hopefuly I've positioned them in a way that makes it a bit easier to fine-tune their length to achieve the target resonance frequencies.

Vents can also be difficult to get right in a bandpass design, if you make the vents large enough for subwoofer duty. Have a look at my project to see what I ran into - The Subwoofer DIY Page - Projects : An INF10 Bandpass Subwoofer

BP4 FTW! Great project Brian! I really like the look of the finished enclosure!

Have you ever thought about designing the BP4 with the magnet in the vented section? That situation promotes voice coil cooling.
 
Have you ever thought about designing the BP4 with the magnet in the vented section? That situation promotes voice coil cooling.

The original design had the magnet in the vented section, with the driver mounted through the baffle. However during the build I realised that I needed more bracing in the sealed section, which would have made that arrangement impossible, and if I mounted the driver on top of the baffle with its magnet in the vented section, there wouldn't be enough room for the two 3" flared vents.