I strongly agree with keeping everything in Octave, it already exists and can be used to do what's needed for this project (especially the math part!) and is open sourced. If someone can write software that does all that with a slick UI, that would be cool, but I really don't see it as necessary at this point.
I would love for that to be the end result.
There is a practical element to the data processing that should be discussed, and that is, for the data processing, how high in frequency to operate the near field holography? In other words, sampling points of the sound field to reconstruct its actual shape. This is worth talking about because the higher in frequency you go, the finer the measurement mesh needs to be otherwise spatial aliasing will occur in the results. But then the number of measurement points goes up. Potentially by quite a lot. The mesh and distribution of measurement points can apparently be optimized, but that adds another layer of complexity because the system would need to "pre-measure" to ascertain the optimum mesh, otherwise you could end up with a lot of time spent on an unnecessarily large data set or a data set with incorrect high frequency information.
Alternatively, only using NFH up to 1-2kHz and "traditional" methods above that would result in an easier mesh size and processing (proposed by @fluid over at ASR). Using the hardware concept proposed by @Dave Zan and adjusting the dimensions to what will fit in the space I have, it could be possible to still obtain a full 20Hz to 20kHz balloon plot using this alternative. Admittedly spatial resolution would likely be less than the <1 degree that Klippel's NFS can do.
Keep in mind that I'm referring to measuring/reconstructing the sound field from the speaker, separating that from room reflections is a separate component (in case there was confusion).
I have a simple CAD sketch I can share soon.
How does the Klippel machine do that?
No matter what, I guess your suggestion of using the Klippel method for the frequency range where room echoes are problematic with conventional gated measurement makes a lot of sense.
After discussion with NTK I have come to the conclusion that an automated turntable that moves the mic fixture combined with manual movement of height to 5 or so vertical positions should be enough for 1K (nearfield to farfield reconstruction and sound field separation), dual layers by running the whole thing again at a separate position of the mic tube.
It remains to be seen if that works and the top and bottom layers are really needed if the frequency is kept low enough.
I personally think this is a practical proposition that trades complexity in automation for a little bit of time.
It seems that ARTA is capable of collecting the required measurements and naming conventions and can be processed to work with NTK's existing code.
I already have the software to move the turntable that Tom wrote at my request. I have tested the hardware for the turntable and it gives a very easy and quick way to capture a radial set of measurements.
I have stared long and hard at close up images of Klippel's hardware. The more you look and think it through the more sense it makes if you want to have a reliable fully automated robot positioning system. Nothing there is superfluous for their use everything has a purpose and reason for being that way.
I don't have a want or need for that complexity, what I want is better resolution between 200Hz and 1K and a good look at the directivity of the speaker in that region. For what I want to do needs an automated rotating arm, stiff vertical structure that attaches to the arm and can have a mic tube moved up and down it at fixed increments. That could be automated too but there are lots of little gotchas that make it unattractive to me at the moment. A simple sliding mechanism that can be fixed in place at the required vertical distances is where I will start.
If it turns out that many more points are needed then working out the automation for the vertical would be worth the effort.
I personally never found much benefits with an automated turn table vs just turning that table by hand.
It maybe saved me 10-15 min more.
For a Klippel approach that's obviously a different story.
The averaging for higher frequencies beats me a little?
Even in a small appartement it's possible to measure from about 200Hz (170Hz also still doable).
Which will give plenty of resolution.
I even doubt if those details wouldn't be "averaged away or gone" , with averaging techniques.
There are even anechoic rooms that sometimes still give problematic results with errors above 800Hz.
The problematic area is around 80Hz to 400Hz.
Where we don't have much resolution, or we can't have a longer time window.
Both are problematic for 3-way systems or (active) systems with a low high pass filter.
It maybe saved me 10-15 min more.
For a Klippel approach that's obviously a different story.
The averaging for higher frequencies beats me a little?
Even in a small appartement it's possible to measure from about 200Hz (170Hz also still doable).
Which will give plenty of resolution.
I even doubt if those details wouldn't be "averaged away or gone" , with averaging techniques.
There are even anechoic rooms that sometimes still give problematic results with errors above 800Hz.
The problematic area is around 80Hz to 400Hz.
Where we don't have much resolution, or we can't have a longer time window.
Both are problematic for 3-way systems or (active) systems with a low high pass filter.
Could you point me to NTK's code? I vaguely remember something, was it in python? I've been away from diyaudio for quite a way, was just lurking...
Contrary to some other people, I hate repetative jobs. I rather spend a day automating it, than do a one hour job twice
So for me it would be worthwhile to have the data acquisition under control (scriptable) and couple it to NTK's code.
Think big, act small, start somewhere.
What about this:
So we have some base. Attach a plateau (?) to it. Put one of these on top:
and mount the microphone to that so it can rotate around the pole. The servo motor can use the teeth on it to control the rotation of the microphone around the speaker (mounted on top of the pole).
What about this:
So we have some base. Attach a plateau (?) to it. Put one of these on top:
and mount the microphone to that so it can rotate around the pole. The servo motor can use the teeth on it to control the rotation of the microphone around the speaker (mounted on top of the pole).
The user name of a member at Audio Science Review who has written code based on the same principles as the near field scanner uses
Use dual, spaced, mics to record simultaneous sweeps, reducing manual work to only three heights?
Klippel's approach is a direct implementation of the Weinreich paper. I suggest getting that paper to see how complex the math can get. It is not trivial even before one gets into numerical problems with convergence. It is not clear to me that MatLab could do this problem. Mathcad couldn't. Mathematica probably could (but only later when they added some functions.) You need very obscure functions (spherical harmonics both angular and radial) that are not readily available in most programs. When I started they were not available in public at all. I had to write my own. My system took almost a decade to complete and it is only horizontal.
I would strongly suggest that the data taking part and the mathematical calculations part be seperate programs. That's the way I did which allowed for any data taking program to be used. I use HolmImpulse.
This is not true. It takes exactly the same number of field points as the number of radiation modes, which are finite. Typically only about 20 modes (horizontal, maybe double that for full sphere.) More points are actually superfluous. I showed how my system could do with 20 points exactly the same as 90 points done without my calculations - even at 20 kHz.
"Code against interfaces, not implementations"
Matlab has a lot of built-in mathematical functions. It also has a file exchange on the internet where users can put their own contributions. There I found this: https://nl.mathworks.com/matlabcentral/fileexchange/69262-spherical-harmonics Is that what you need? They look like the images I've seen in some of the papers I've read.
If you need something no-one has done before, you can always write your own functions.
I've seen similar 'balloons' in NTK's documents and it has the spherical Hankel function of the first and second kind.
What do you mean by "the Weinreich paper"? The one in the attachment? If so, the maths seem to be in equations (1) and (2) on the first page of that paper. I don't see why GNU Octave or Matlab wouldn't want to do that.
As long as the mics are closely phase matched... or widely spaced. But the wider they are spaced, the lower the highest frequency the method is usable to is. As it relates to low frequency, quoting this B&K document (page 32) on the topic of using a pressure gradient to calculate particle velocity: "For accuracy to within 1 dB the phase change over the [microphone spacing] distance should be more than five times the phase mismatch" That is, of course, assuming that velocity will be used to performing sound field separation... it seems reasonable to me given the method of capture, but I don't know for sure.
I don't see how my statement was not true. The number of radiation modes contributing to the sound field goes down as frequency goes down, does it not? Therefore, if you are only using that method of analysis up to 1kHz, you would need less field points than if you are going to use it up to 20kHz because there are less contributing radiation modes. Unless you are saying that it takes 20 modes to describe the sound field at 20kHz and at 20Hz?
From what I've seen in Klippel's examples, 20 modes may be enough for a full sphere as well.
As I recall, your method uses a measurement point distribution optimized based on certain assumptions about the speaker's sound field (i.e. a speaker that's a forward facing monopole). If measuring a speaker where those assumptions are not valid, I imagine that more points would be needed.
I wish I knew. I think it takes a couple specifically located measurements to figure out how to optimize the scan. @bikinpunk may be able to give some insight.
But optimization of the scan seems useful when using NFH, as can be seen with Earl's optimization of his system, doing with 20 measurements what would otherwise take 90.