They are the waterfall plot settings from REW that I used to try and get close to the ARTA plots that mabat showed.
Thanks, I hardly ever used REW and never its waterfall, so I had never seen those plots.
Curious. I am in the process of cleaning up some old code just as an exercise on my new computer. Since I have no longer any use for all the simulation code that I created years ago for my own designs, I was wondering if this would be an interest to the community.
Some months back we tried another route, I was leery at the start. Another programmer was going to interface his code to my numerical calculations. Long story short, we could never get it to work.
What I have is a measurement system based on HolmImpulse. It will take somewhat near field data, usually about a meter sometimes less, and through the same techniques that Klippel uses (except I did them long before he did) it will predict the far field, usually 10 meters. What's the big deal? Its far more accurate than just plotting the raw numbers with noise etc. The system can yield 2 degree angular data with only 13 measurement points and its been shown to match the same data taken at 90 points up to about 10 kHz.
Next step I had planned was to allow two sets of measurements and then simulate the crossover and the far field system data. It also does a LF extrapolation based on the box size and driver details. I used it extensively on all of my later speaker designs.
Is this something that would interest people or are they happy with what they have?
Curious. I am in the process of cleaning up some old code just as an exercise on my new computer. Since I have no longer any use for all the simulation code that I created years ago for my own designs, I was wondering if this would be an interest to the community.
Some months back we tried another route, I was leery at the start. Another programmer was going to interface his code to my numerical calculations. Long story short, we could never get it to work.
What I have is a measurement system based on HolmImpulse. It will take somewhat near field data, usually about a meter sometimes less, and through the same techniques that Klippel uses (except I did them long before he did) it will predict the far field, usually 10 meters. What's the big deal? Its far more accurate than just plotting the raw numbers with noise etc. The system can yield 2 degree angular data with only 13 measurement points and its been shown to match the same data taken at 90 points up to about 10 kHz.
Next step I had planned was to allow two sets of measurements and then simulate the crossover and the far field system data. It also does a LF extrapolation based on the box size and driver details. I used it extensively on all of my later speaker designs.
Is this something that would interest people or are they happy with what they have?
Last edited:
I think this would be an amazing asset. would it allow us to better estimate power response and estimated in room response?
I would be willing to help an effort. only have c/c++ and python skills though. I'm guessing you used a language more suited to academic math work?
the ports makes sense from the horrid resonances they get, but what is the problem with PR's? I thought they where considered generally superior?
obviously its not needed if you're doing a multisub setup. but it can be nice to just have 2 speakers which are full range.
is there a big downside to having a PR setup like this, even if you may have subs? (apart from cost)
Last edited:
It would be a dream come true to have such a system available. What would be the task, actually? I'm only afraid that to pursue this work it would require someone skilled in maths, programming and acoustics - not easy to meet. I know nothing about acoustics, or physics for that matter.
Last edited:
It is
One pair of passive speakers, a good old stereo amp and a pair of cables - I don't need or want anything more. So all of my efforts go in that direction. I can also imagine a three-way with a small midrange in a waveguide I showed earlier, instead of the one large midwoofer.
I'll look at that. I haven't worked with anything asymmetric for a long time...
honestly that seems like such a good idea. lower IM distortion (but not sure it even matters)
and if your over here in Aus, the price of big drivers is really terrible. I feel it could make a LOT of sense to use a 5-8inch pro audio driver (not too expensive here) and really be able to optimize the dispersion
Check this thread out;
DIY 3D Speaker Scanner - the Mathematics and Everything Else | Audio Science Review (ASR) Forum
A lot of good work explaining matters has been done already
I started implementing it in matlab, but couldnt find the time for it.
I would try it with one of these;
UMIK-X - USB audio Multichannel Measurement microphone array set
Real cheap and convienient way to make the inside and outside measurements at the same time.
I have been researching the latest state of the art mems mics, and they are getting really good ( +- 1dB default specs)
Last edited:
This sounds very useful, as you have done the physics already (the hard bit) it should just be a case of implementing the same algorithms perhaps in another language and adapting the data input format.
*does anyone have a link to a good mems microphone for making low cost mic arrays?
Last edited:
has the option to generate vertical Polars been disabled with version 4.7?
In 4.6 I have used the option "ABEC.Polars.Vertical = 1" to generate vertical Polars. This does not seems to work with 4.7 anymore. Has this option been removed?
Maybe I am just using the wrong syntax in 4.7 now because ABEC-Syntax has changed. I have tried:
and old syntax
Both did not work
In 4.6 I have used the option "ABEC.Polars.Vertical = 1" to generate vertical Polars. This does not seems to work with 4.7 anymore. Has this option been removed?
Maybe I am just using the wrong syntax in 4.7 now because ABEC-Syntax has changed. I have tried:
Code:
ABEC.Polars:SPL = {
...
Vertical=1
...
}and old syntax
Code:
ABEC.Polars.Vertical = 1Both did not work
Since, to me, any really great audio system has to have multiple subs, I don't see the need for full range mains (although mine do go down to about 50-60 Hz.) Hence, in that sense no ports or PRs are needed. PRs do have some advantages over ports, but I still contend that a closed box works best with multiple subs and EQ availability. Closed box offers better excursion control than ported.
Room response is beyond the goal of what I am doing and extremely room dependent requiring a room model. But the power response simulation is accurate except at crossover where significant no-lateral lobes pose an issue.
As far as coding goes, all the help that I need is for distribution, people to test that the install package works, etc. The rest I can do.
All the user needs to understand is how to use HolmImpulse. Almost everything beyond that is a black box whose content need not be understood.
That is a really good discussion of the theory. Implementation on real data in a real measurement system turned out to be the biggest problem for me. There were a lot of "gotchas", some of which were addressed others not.
This is not required as it will be a windows app that is fully functional and need not be rewritten in a different language. We tried that and failed.
Let me list my systems pros and cons:
Pros -
1) the implementation is extremely inexpensive - HolmImpulse is free; good mics are <100$; the rotation stand can be built for < 20$ - its an ideal DIY tool
2) The system is very easy to implement, only a single mic is required, The speaker is rotated not the microphone.
3)The data result is highly portable and shared easily
4) it requires only 13 measurements for 10k resolution
Cons -
1) the system is axisymmetric only (although the speaker system can be rotated and done again to gain some information as to lobbing effects in alternate planes.)
2)It takes some practice to get right, but what doesn't?
3)The crossover design would initially only allow for a two way (but the designs in this tread are ideal applications.
4) some assumptions need to be made about the LF features. Monopoles (closed box) work ideal, dipole OK, ported less accurate because of the port/driver interactions.
5) currently only works with Holm data (but this is not a big issue as translators from one package to Holm would be easy to do, I just don't see this as a priority for me.)
The last point is essential here because most of the designs fit ideally into what I have done, there being so similar.
Please E-mail me if you want to be a Beta tester for installation.
Last edited:
I have 100pcs of this one if you want some
https://www.mouser.dk/datasheet/2/218/SPM0687LR5H-1_Product_Brief-1313993.pdf
Then I misunderstood your offer. That sounds even better.
I think the biggest struggle when measuring loudspeakers at home is to capture in detail anything in the range ca. 300 - 1000 Hz, as some of the features can remain hidden if the time window is too short for that. Do I suppose correctly that your software would be able to show this region in virtually unlimited resolution?
Yes, of course, that is true, and yet I have done all my measurements in my living room. That said, my living room has a high ceiling and is larger than a lot of rooms. I get about 6 ms. of clean data, or down to about 250 Hz, below which my radiation model works very well. As the window becomes shorter the assumptions on the LF source become less and less valid and the region of 200-500 becomes less accurate. These are limitations that almost any system has to deal with.
I have not tried to implement the two sphere technique which is ideally suited to the 200-1000 Hz region. I might in the future but for right now I have to assume that 6 ms of clean data is available. But short of a 100k Klippel system everyone is going to have this same problem.
Just to be clear, I have already written all the code and have used it for about 10 years now. I just want to clean it up and make it usable to a more novice user. Current code can be temperamental, which is fine for me as I usually run it in Visual Studio so any fails can easily be surpassed. But a distributed package does not have this advantage and I need to make it so.
I have not tried to implement the two sphere technique which is ideally suited to the 200-1000 Hz region. I might in the future but for right now I have to assume that 6 ms of clean data is available. But short of a 100k Klippel system everyone is going to have this same problem.
Just to be clear, I have already written all the code and have used it for about 10 years now. I just want to clean it up and make it usable to a more novice user. Current code can be temperamental, which is fine for me as I usually run it in Visual Studio so any fails can easily be surpassed. But a distributed package does not have this advantage and I need to make it so.
Last edited:
So it doesn't really help in this regard, that's a pity. I'll give an example - this is a Dayton woofer that seems really smooth at least up to 4 kHz. But the measurement in the datasheet obviously used very short window (450 Hz ~ 2.2 ms). There's a suspicion from some other data that something not so nice happens around 700 - 800 Hz. Without much longer window this is simply not possible to tell. Would 6 ms suffice? I don't know.
In the end we still have to take it in a large hall and lift it up in the air, or at least do some ground plane measurements.
In the end we still have to take it in a large hall and lift it up in the air, or at least do some ground plane measurements.
Last edited: